On Saturday, June 7, 2014, Andy Bradford < amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org> wrote:
> Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: > > > I should add that it's not always possible or desirable to test all > > commits in a bundle that will be pushed together. A goal of breaking > > up large commits into smaller ones is to make it easier to understand > > and backport them, but an engineer working on a backport will have to > > retest anyways. > > This workflow certainly seems like a lot of time spent playing with the > tool and less time working on code. Do Git users typically make such > large commits? Why don't they just use branches to separate different > lines (as in tracks) of development rather than bundling a bunch of > unrelated checkins all at once? > Not git users. Engineers who work on codebases with maintenance releases. For example: Solaris, Windows, ... but also a number of smaller projects, like MIT Kerberos, Heimdal, and so on. When you have a bug that needs to be fixed in older releases, you want to be able to cherry-pick it, and sometimes you don't know this until after you've integrated a fix for it in the main trunk. This is one reason that clean history is appreciated. And when investigating a bug it's also nice to be able to look back through the history and understand what was done (as opposed to how a programmer got there, which is ticket/comment fodder). (For years i worked on codebases where we used Teamware -an ancient, ancient VCS now- and we'd worked out how to implement a rebase-heavy workflow, in a team of thousands. This isn't about git. Git just happens to be the first modern VCS that made this workflow possible with little pain. If i had to use Fossil in such a workflow, I'd do the sorts of things i was used to doing with Teamware, as meantioned earlier in this thread.) The first case is easy to drop: never keep maintenance releases. Mostly that's the right thing to do, especially if in the process you can train your users to stay on the bleeding edge instead of worrying about upgrading with every critical security bugfix. But it's not always possible or easy to do this, or perhaps having older releases on maintenance is part of the vendor's business model. Either way, there's still the matter of clean, comprehensible history -- reasonable people can disagree about this, of course, and precisely because of that there are codebases where the gatekeeprs force a rebase heavy workflow on contributors. I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. I also want the power of SQL for history, and so on. So I can get this neither from Fossil nor git. Well, so be it. I won't be adding writing a VCS to my bucket list, we each have our priorities, and I wouldn't likely do a very good job of it; at most I will pursue minor extensions (or hooks) to git to get me the query power and recovery semantics I need. I think it best now for me to let this poor dead horse be. Thanks for listening and engaging me on this subject, and my apologies for taking so much of your time (especially since I love SQLite and want to do nothing to slow down your efforts there), Nico --
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
