6 ms·

> I never could get anonymous push/user registration to work smoothly.... We are always trying to make Fossil better. Can you explain what you mean by "anonym

by SQLite 10y ago

> I never could get anonymous push/user registration to work smoothly.... We are always trying to make Fossil better. Can you explain what you mean by "anonymous push/user registeration" and provide more information on why it was a problem for you? Private email to drh@sqlite.org is ok for this.

e12e 10y ago
The easiest way to explain this is probably through my scenario (and an example of how gogs worked, where Fossil fell a little short): I have 26 students, for whom I have no account information or central auth server (eg a typical "pop-up" workshop). As everyone is new to programming and (d)Vcs, I would prefer some authorization help from the system (Fossil is pretty good here, afaik "git push --force" isn't really an issue). Everyone are on Windows, and while ssh is available, it's not a great fit for the platform. Fossil has "fossil gui" and "fossil serve" which allow users to clone - but I never could get either: plain http (no ssl, as this isn't a public ip which complicates settling up a trusted cert a bit) with push from clients to work - with or without password. With gogs, I could turn off the CAPTCHA and enable registration in the Web ui, and users could push with auth from git and visual studio code, using user/passwords. As far as I got with Fossil was registering users that worked with the Web ui (eg: edit wiki) -- but I couldn't get sync (push to the server) to work (neither from Linux, nor Windows). At first I thought it was an issue with a mix of Fossil versions, but in the end I think that ad-hoc LAN deployments just isn't all that we'll tested? Perhaps especially on/with Windows clients? As far as I gather when cloning a repo, Fossil is supposed to get a copy of the user database, and so everyone should be able to a) use "fossil gui" and edit wiki pages etc and have changes auto-sync out of the box (assuming the upstream Fossil instance is up) and b) use "fossil serve" and have other registered users be able to push changes? I was able to pull, and sync/push over ssh, but (auto)sync over http always failed. From the docs, it looks like it is supposed work, with a bit tuning of auth/authz settings in the administration Web ui).
- dmitry-k 10y ago
  @e12e Try RhodeCode (https://rhodecode.com https://rhodecode.com), we have quite a few educational users (e.g. Carnegie Mellon University) using RhodeCode in the way you described. RhodeCode also has secure authorization, user permission management and a web interface. One can even edit/commit directly from within a built-in web editor.
  - e12e 10y ago
    Is it Free/open source software and does it work off-line (on lan with sometimes intermittent Internet connection and/or can clients commit while offline, eg on a train journey with many tunnels[1], or on an airplane)? [1] "The construction was exceptionally challenging, at high altitudes in a region without roads and with a climate that saw many meters of snow in the winter and temperatures far below freezing. 113 tunnels, totaling 28 kilometres (17 mi) had to be built; the longest being the 5,311 metres (17,425 ft) Gravehalsen Tunnel, alone costing NOK 3 million and the longest tunnel north of the Alps. It took six years to build, and had to be excavated manually through solid gneiss." https://en.m.wikipedia.org/wiki/Bergen_Line https://en.m.wikipedia.org/wiki/Bergen_Line
- nomadbyte 10y ago
  Seems like you were trying to create a centralized server, akin to GitHub or ChiselApp to serve as a main repo and registration site, allowing users to self-register. Fossil as such does not need a central server; each user may just as well be self-sufficient, and if needed, to share his/her repo to other users (fossil server). Still one easy way to accomplish the centralized setup is to designate one Fossil instance as the main/origin, create a repo, and launch 'fossil server', it will show the port on which it listens. Then make other users connect to the main by http://hostname:port http://hostname:port. To allow users to self-register, you need to log-in as admin-user and check an option in Admin::Access:Allow users to register themselves. Keep it checked at least until all of your users have registered. Make sure users have a Developer privilege, so that they can push the changes to the main repo. This will add user names to the central repo, and will prompt for authorization at clone/commit/pull/push/update. In case the registered username is different from local login username, the users may need to make it as local fossil admin (`fossil clone <url> --admin-user <username>`). Then after `fossil open`, make this username as cloned repo default (`fossil user default <username> --user <username>`) HTTP connect is fairly robust, with additional layer of security added on the Fossil's side to somewhat compensate for the clear-text login. Should suffice in trusted environment. Your LAN should have no problems routing this as it's indeed a local traffic. BTW, Fossil has a nice convenience feature called "autosync" which makes login/password use transparent, only enter it once and then all commits would automatically attempt to sync to origin repo. It can be turned-off in settings if not needed, on per-clone basis (fossil set autosync off) Hope this helps.
  - e12e 10y ago
    I very much wanted/needed a "distributed/centralised" model - everyone is working on the same repo. I never did get sync/push to work - I could pull down repo and wiki, but neither code nor wiki changes would auto-sync over http - I forget the exact error I got, but it seemed others had come across the issue in older versions - the suggested fix was to make sure server and client was on the same version of Fossil - due to some change in handling of storing usernames and password hashes - but this was in a version quite a few point-releases older than the oldest binary I tried. And I also tried with latest stable with a pristine repo. I only ever got sync/push to work over ssh. I might have tried having users pull changes from each other - but with 25+ students a central server/repo for resolving merge conflicts becomes necessary - not to mention that it would be hopeless for people new to the concept of version control in general and distributed vcs in particular. Has anyone actually got auto-sync to work over http with Fossil of late?

by SQLite 10y ago

e12e 10y ago

The easiest way to explain this is probably through my scenario (and an example of how gogs worked, where Fossil fell a little short): I have 26 students, for whom I have no account information or central auth server (eg a typical "pop-up" workshop). As everyone is new to programming and (d)Vcs, I would prefer some authorization help from the system (Fossil is pretty good here, afaik "git push --force" isn't really an issue). Everyone are on Windows, and while ssh is available, it's not a great fit for the platform. Fossil has "fossil gui" and "fossil serve" which allow users to clone - but I never could get either: plain http (no ssl, as this isn't a public ip which complicates settling up a trusted cert a bit) with push from clients to work - with or without password. With gogs, I could turn off the CAPTCHA and enable registration in the Web ui, and users could push with auth from git and visual studio code, using user/passwords. As far as I got with Fossil was registering users that worked with the Web ui (eg: edit wiki) -- but I couldn't get sync (push to the server) to work (neither from Linux, nor Windows). At first I thought it was an issue with a mix of Fossil versions, but in the end I think that ad-hoc LAN deployments just isn't all that we'll tested? Perhaps especially on/with Windows clients? As far as I gather when cloning a repo, Fossil is supposed to get a copy of the user database, and so everyone should be able to a) use "fossil gui" and edit wiki pages etc and have changes auto-sync out of the box (assuming the upstream Fossil instance is up) and b) use "fossil serve" and have other registered users be able to push changes? I was able to pull, and sync/push over ssh, but (auto)sync over http always failed. From the docs, it looks like it is supposed work, with a bit tuning of auth/authz settings in the administration Web ui).

dmitry-k 10y ago
@e12e Try RhodeCode (https://rhodecode.com https://rhodecode.com), we have quite a few educational users (e.g. Carnegie Mellon University) using RhodeCode in the way you described. RhodeCode also has secure authorization, user permission management and a web interface. One can even edit/commit directly from within a built-in web editor.
- e12e 10y ago
  Is it Free/open source software and does it work off-line (on lan with sometimes intermittent Internet connection and/or can clients commit while offline, eg on a train journey with many tunnels[1], or on an airplane)? [1] "The construction was exceptionally challenging, at high altitudes in a region without roads and with a climate that saw many meters of snow in the winter and temperatures far below freezing. 113 tunnels, totaling 28 kilometres (17 mi) had to be built; the longest being the 5,311 metres (17,425 ft) Gravehalsen Tunnel, alone costing NOK 3 million and the longest tunnel north of the Alps. It took six years to build, and had to be excavated manually through solid gneiss." https://en.m.wikipedia.org/wiki/Bergen_Line https://en.m.wikipedia.org/wiki/Bergen_Line
nomadbyte 10y ago
Seems like you were trying to create a centralized server, akin to GitHub or ChiselApp to serve as a main repo and registration site, allowing users to self-register. Fossil as such does not need a central server; each user may just as well be self-sufficient, and if needed, to share his/her repo to other users (fossil server). Still one easy way to accomplish the centralized setup is to designate one Fossil instance as the main/origin, create a repo, and launch 'fossil server', it will show the port on which it listens. Then make other users connect to the main by http://hostname:port http://hostname:port. To allow users to self-register, you need to log-in as admin-user and check an option in Admin::Access:Allow users to register themselves. Keep it checked at least until all of your users have registered. Make sure users have a Developer privilege, so that they can push the changes to the main repo. This will add user names to the central repo, and will prompt for authorization at clone/commit/pull/push/update. In case the registered username is different from local login username, the users may need to make it as local fossil admin (`fossil clone <url> --admin-user <username>`). Then after `fossil open`, make this username as cloned repo default (`fossil user default <username> --user <username>`) HTTP connect is fairly robust, with additional layer of security added on the Fossil's side to somewhat compensate for the clear-text login. Should suffice in trusted environment. Your LAN should have no problems routing this as it's indeed a local traffic. BTW, Fossil has a nice convenience feature called "autosync" which makes login/password use transparent, only enter it once and then all commits would automatically attempt to sync to origin repo. It can be turned-off in settings if not needed, on per-clone basis (fossil set autosync off) Hope this helps.
- e12e 10y ago
  I very much wanted/needed a "distributed/centralised" model - everyone is working on the same repo. I never did get sync/push to work - I could pull down repo and wiki, but neither code nor wiki changes would auto-sync over http - I forget the exact error I got, but it seemed others had come across the issue in older versions - the suggested fix was to make sure server and client was on the same version of Fossil - due to some change in handling of storing usernames and password hashes - but this was in a version quite a few point-releases older than the oldest binary I tried. And I also tried with latest stable with a pristine repo. I only ever got sync/push to work over ssh. I might have tried having users pull changes from each other - but with 25+ students a central server/repo for resolving merge conflicts becomes necessary - not to mention that it would be hopeless for people new to the concept of version control in general and distributed vcs in particular. Has anyone actually got auto-sync to work over http with Fossil of late?