I’m going to start two different reply forks: I’ll reply to the Pollack article here, then send another message later to chime in on your proposal, drh.
On Mar 2, 2015, at 5:30 AM, Richard Hipp <d...@sqlite.org> wrote: > > Ben Pollack's essay at > http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ > succinctly points up some of the problems with DVCS versus centralized > VCS (like subversion). Thanks for the pointer. It sums up most of my problems with the Git and GitHub models. It’s too bad Pollack doesn’t include Fossil in his comparison. I don’t think all of his points apply to Fossil: 1. “Sanely track renames.” In this respect, I think Fossil offers one step forward, one back relative to Subversion. While Fossil does seem to realize that a rename isn’t the same thing as add+delete *most* of the time — I have managed to confuse it a few times into seeing a rename as add+delete — it doesn’t backtrace through a rename in finfo output: f new x.fossil mkdir x cd x f open ../x.fossil touch a f add a f ci -m ‘initial' f mv a b mv a b f ci -m ‘renamed a to b’ f finfo b 2015-03-03 [bc09e28048] .. (user: warren, artifact: [da39a3ee5e], branch: trunk) Point being, I usually end up having to go into “fossil ui” to trace the ancestry of a file back through a rename. Doubtless it is possible to do this from the command line somehow, but I miss the behavior of “svn log” which did the backtrace for you. 2. Explosion of manuals and tutorials. To some extent, the relative paucity of Fossil training material is a consequence of its…ummm… unpopularity? But, it is also the case that it doesn’t *need* as much training material. I read the Red Bean Book, and I still don’t quite understand how svn branching and merging is supposed to work in practice. We ended up ignoring about half of the mechanics proposed therein, which made our conversion to Fossil more difficult, but it worked at the time for us. With Fossil, though, I’m branching and merging for the first time without difficulty. The hardest part was getting past the scar tissue laid down by svn. “It’s that simple, really? No way, can’t be. There’s got to be more to it than that!” Partly this is due to the ability to create a branch as part of a checkin with "f ci --branch”. Partly it is due to the branch structure being made visible in f ui. These are genuine advances over Subversion, and I thank you for them, drh. 3. “fossil bundle” makes Fossil nearly as easy to use as Subversion for drive-by patches. I believe the equivalent Fossil sequence is: a. Clone the master repo b. Open a copy of the repo c. Make your change d. Check it in on a branch; ignore the auto-sync complaint e. Bundle the new branch f. Send the bundle to the project maintainer g. Watch it get ignored So, just two more steps than svn, rather than 4, as with git. One of the two extra steps is due to the fact that clone is separate from open in Fossil, which I consider a feature. It allows multiple opens on a local clone. I absolutely hate the Git alternative where you have to keep switching the local checkout/repo to see different branches. The checkout operation itself is time consuming, then it eats more time due to the forced rebuilds, since it must rebuild the objects to match the changed sources. With Fossil, I can keep not only multiple source checkouts from a single repo clone, but also multiple build trees. The other extra step is the apparent necessity to check your changes in. This is also a feature since it’s how Fossil records the checkin comment, the user info, etc. If the project maintainer accepts the bundle without changes, this step saves him work that he’d otherwise have to do manually in the patch(1) case. If someone wants to tie “fossil bundle” into the ticketing system, we can save a step here by bypassing the email step. (fossil bundle submit?) Perhaps we could save the other step by offering a clone-and-open mode, perhaps by storing the Fossil repo file inside the opened tree? I propose “fossil hack,” so named because it would be used by people who just want to do a quick hack on your repo, not seriously spend a lot of time with it. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
