Re: [fossil-users] autosync with fossil merge
On Fri, Jul 19, 2013 at 8:39 AM, Richard Hipp d...@sqlite.org wrote: On Fri, Jul 19, 2013 at 11:24 AM, Matt Welland estifo...@gmail.comwrote: For anyone training a large team on using Fossil I can't emphasis enough how important it is to get your users comfortable with the distributed nature of Fossil *before* allowing them to enjoy the benefits of the connected sync. I would like to hear more about your experiences in this area. Please feel free to elaborate this, as time permits. Sure, here are some comments on our experience. The context here is a fairly large team well versed in using tools such as Subversion, DesignSync and CVS. Growth in release frequency resulted in overlapping releases leading to a need for better parallel development methodology (i.e. diverge for a while then converge). Many tools were evaluated including fossil, after evaluation we decided to take a risk and give fossil a chance. Autosync along with the svn like behaviour was a big selling point for fossil. The training we put together briefly covered the distributed nature of fossil, including the local vs. remote copies of the database and how deltas were synced back and forth. However in the training we quickly moved on to the gritty details of committing, merging, adding, removing etc. as the focus was on getting folks up to speed quickly. A wrapper script, fsl, was written to enable us to shield users from some aspects of fossil deemed less relevant to our needs. For example instead of having to do mkdir training; fossil clone file://path/to/common/training.fossil training.fossil;cd training;fossil open ../training.fossil the fsl wrapper enables a single command, fsl repo get common training. The problems that came up fell roughly into three buckets; general problems related to learning a new tool, problems with fossil itself (most of which were addressed amazingly promptly IMHO), and problems related to the distributed nature of fossil. The first two categories tapered off in frequency fairly quickly and were for the most part not a huge deal. The problems related to the distributed nature of fossil took much longer to come to peace with. Forks were a big problem for two reasons. First, they were invisible to the users. We have quite a few power users who were accustomed to getting things done at the command line. When a fork occurred mysterious things happened. Example: User A does a commit and tells user B, the code is ready, please do an update. User B does an update and the code is not there. They check the branch, timeline (from the command line), status, all to no avail. Only by checking the UI timeline could you see and fix a fork. The syncing of tags was a similar problem. User A tags the repo and lets others know to get the tagged code but ... there is no tag if you didn't manually sync. After that happened a few times we added an auto sync to the tag command and code to detect a fork and warn users in the fsl wrapper. Note that some forks were happening because the automated sync between remote sites was taking several minutes and overlapping commits would result in the silent creation of a fork (I believe that the latest version of fossil detects this and notifies the user that a fork has occurred). It is impossible to prevent all forks in this setup. This is obvious to anyone who gets fossil's distributed nature. userA =autosync= centralSiteX ===slow sync=== centralSiteY =autosync= userB I believe that the fork and tag (and a couple times merge) behaviour was exceedingly confusing to folks because even though the distributed nature of fossil was taught in the training it was not emphasized enough for people to grasp fully the implications. In most users minds the new system they were using was like svn but with way easier branch and merge. Any new training I do would start out with extensive practice in using raw fossil commands for cloning etc. so that people get a gut feel for the fact that it takes time (and a sync) to get changes, tags etc. back and forth from their private repo to the central repo. At this point the frequency of problems with forks and sync that get brought to my attention is almost zero. People have learned how to fix the fork themselves or are seeking out others on the team for support. After all this experience with Fossil I feel I can recommend it to other teams because it really does make diverging and converging code easy and it is relatively easy to learn and administer. The caveat again is, get comfortable with the distributed nature first, turn off autosync for the first hour of hands on training :) I hope this write up helps anyone else seeking to ramp up a large team on fossil. Thanks, Matt -=- -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations
Re: [fossil-users] Shared SSH account consideration.
Thus said Martin Gagnon on Wed, 17 Jul 2013 08:04:10 -0400: I propose to add a kind of -l|--login option to the clone command, so when the username@ is present but don't match the repo username, we could specify repo username with -l. After giving this additional thought, I went ahead and took a stab at it: http://www.fossil-scm.org/index.html/info/9dd4a935e8 Please note, however, that there are significant changes to make this work---as I suspected there would be. Probably the biggest noticeable change will be on Windows. It no longer prompts for your SSH password (which actually makes it behave the same as it does on *nix). I'm not sure why it ever did prompt for the SSH password (seems a bad idea to print a *nix account password in the command). If the change for Windows does not work out, we'll have to figure out something else to do on Windows. At any rate, it is now possible to specify a Fossil SSH user that is different from the URL user: local$ fossil clone -l amb ssh://guest@remote//tmp/shared.fossil my.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http /tmp/shared.fossil Round-trips: 2 Artifacts sent: 0 received: 1 ssh -e none -T guest@remote fossil http /tmp/shared.fossil Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 548 bytes sent, 1163 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 2ee3868b26efd6e77532f0a7133f1e67eb2ac189 The guest account on remote has my SSH key installed, restricting me to just that fossil repository. Please test this as much as possible. It works in my environment (OpenBSD) but I would like to know how well it works in other environments, and specifically Windows. Oh, and here is making a change: local$ mkdir open local$ cd open local$ fossil open ../my.fossil local$ echo $RANDOM file local$ fossil add file ADDED file local$ fossil ci -m first Autosync: ssh://guest:*@remote//tmp/shared.fossil Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http /tmp/shared.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 349 bytes sent, 285 bytes received New_Version: 8efef71512ae129821f5ca035d9c33e722aa75cb Autosync: ssh://guest:*@remote//tmp/shared.fossil Round-trips: 1 Artifacts sent: 2 received: 0 ssh -e none -T guest@remote fossil http /tmp/shared.fossil Round-trips: 1 Artifacts sent: 2 received: 0 Sync finished with 541 bytes sent, 339 bytes received Let me know how it works out for you or if you have additional suggestions. Cheers, Andy -- TAI64 timestamp: 400051ea5667 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] By week-of-year statistics
On Wed, Jul 17, 2013 at 3:53 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jul 17, 2013 at 3:00 PM, Richard Hipp d...@sqlite.org wrote: While you are on the subject of the stats_report page, could you look into possibly scaling the line lengths if they grow to large. See, for example http://core.tcl.tk/tcl/stats_report?view=byuser Andreas K pointed that repo out to me a few weeks ago. They're literally... off the charts. Yes, i'll look into a solution for that. (Ideas are of course welcomed - i was hoping to avoid traversing the data twice in order to calculate relative sizes.) Fixed and much improved: http://www.fossil-scm.org/index.html/vdiff?from=47ee082a75d42263to=674a24a3603ed201sbs=1 the bars now use a relative width based on the maximum event count for the current report's query and the longest bar (most events) has a width of 100%, so resizing the browser window resizes the bars. This requires running through the queries twice, but the effect is much nicer than the absolute values used before. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] By week-of-year statistics
On Sat, Jul 20, 2013 at 6:45 PM, Stephan Beal sgb...@googlemail.com wrote: Fixed and much improved: http://www.fossil-scm.org/index.html/vdiff?from=47ee082a75d42263to=674a24a3603ed201sbs=1 Demo: http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report?view=byweek try resizing your browser in that view. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] By week-of-year statistics
Thus said Stephan Beal on Sat, 20 Jul 2013 18:48:44 +0200: http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report?view=byweek try resizing your browser in that view. Looks like it works great. Just one observation; I find that the alternating row colors are distracting in the bar graph area. I edited the CSS locally and just commented out the row1 background-color and I thought it looked better. Andy -- TAI64 timestamp: 400051ead348 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] By week-of-year statistics
On Sat, Jul 20, 2013 at 8:12 PM, Andy Bradford amb-sendok-1376935974.nbhjmboafacidibep...@bradfords.org wrote: Thus said Stephan Beal on Sat, 20 Jul 2013 18:48:44 +0200: http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report?view=byweek try resizing your browser in that view. Looks like it works great. :) Just one observation; I find that the alternating row colors are distracting in the bar graph area. That's CSS. IIRC the core fossil repo (or default style) does not have colors for the CSS classes tr.row0 and tr.row1 by default. I edited the CSS locally and just commented out the row1 background-color and I thought it looked better. Personal preference - that's why it's in CSS :). Thanks for the feedback! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New command proposal?
Hello, I've been working on a simple fossil command that will integrate with SSH accounts where SSH keys are in use and wonder if there is a formal process for coming up with new subcommand names? Here is what I have at the moment: $ fossil help gate Usage: fossil gate ?FILENAME? fossil gate ?FILENAME? Scans filename for the requested fossil path found in the SSH_ORIGINAL_COMMAND environment variable and runs fossil http path if found. If filename is not present, just run fossil http with the requested path and the operating system will impose restrictions. Any suggestions? Thanks, Andy -- TAI64 timestamp: 400051eafbf8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New command proposal?
On 2013-07-20 23:06, Andy Bradford wrote: Hello, I've been working on a simple fossil command that will integrate with SSH accounts where SSH keys are in use and wonder if there is a formal process for coming up with new subcommand names? Here is what I have at the moment: $ fossil help gate Usage: fossil gate ?FILENAME? fossil gate ?FILENAME? Scans filename for the requested fossil path found in the SSH_ORIGINAL_COMMAND environment variable and runs fossil http path if found. If filename is not present, just run fossil http with the requested path and the operating system will impose restrictions. Any suggestions? Thanks, Andy -- TAI64 timestamp: 400051eafbf8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users I don not understand this. A forced command is in place and it can only be fossil http.This will check if it is started via ssh and then look in the environment to see if the request was fossil gate myotherdb. what are you trying to archive? -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New command proposal?
Thus said Rene on Sun, 21 Jul 2013 00:00:01 +0200: A forced command is in place and it can only be fossil http.This will check if it is started via ssh and then look in the environment to see if the request was fossil gate myotherdb. what are you trying to archive? I'm trying to accomplish what I believe Matt Welland was suggesting it do, which I did like. Basically, if I have an SSH account named ``fossil'' on my server, I can use it to server out as many fossils as I like to any given SSH key connecting to the ``fossil'' account. The forced command on the server will be: command=/usr/bin/fossil gate /tmp/allowed-fossils ssh-rsa ... fossil gate will then inspect SSH_ORIGINAL_COMMAND and extract the requested fossil repo. If the FILENAME contains the requested repo (and perhaps if it is executable and returns successfully), fossil gate will then exec ``fossil http /path/to/repo'' otherwise it will exit with an error. This allows you to use the same client SSH key to access multiple remote fossil accounts using the same remote SSH account. This allows for a 1 to many as opposed to 1 to 1 relationship. It will still be possible for a forced command to be: command=/usr/bin/fossil http /tmp/file.fossil ssh-rsa ... However, this means that you can only ever access that single fossil file using that SSH key and SSH account combination. Thoughts? Andy -- TAI64 timestamp: 400051eb0e0f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Happy Birthday, Fossil!
Hi, all, Six years ago today, the first commits were made... http://www.fossil-scm.org/index.html/timeline?yw=2007-29n=4 http://www.fossil-scm.org/index.html/stat says: Duration Of Project:2192 days or approximately 6.00 years. No idea how long before that work was ongoing, but the src dir already contained a bunch of stuff: http://www.fossil-scm.org/index.html/dir?ci=dbda8d6ce9ddf01aname=src Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
