El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribió: > On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote: > > > Noel J. Bergman wrote: > >> J Aaron Farr wrote: > >>> J Aaron Farr wrote: > >>>>> git could be an issue. > >>>> Can you explain what the issue is with Git? > >>> Leo already gave a decent explanation. > >>> Basically, it comes down to two aspects: > >>> 1) infrastructure support > >>> 2) cultural bias > >> Only the first one is marginally correct, IMO. > >> Santiago wrote: > >>>> 1. You have to use subversion. > > > > > > Sorry, I've missed the thread that led to this, so sorry if I'm > > repeating others. > > > > I understand that GiT can be used locally as a layer on top of SVN. > > I believe this gives you most of the perceived benefits of GiT > > locally without the need for a project itself to switch to GiT. > > I am a bit lost here as well -- what does GiT add to the processes/ > workflows common in the ASF ? >
It adds: - ability to have offline commits - much faster repository diff, status, etc. that works offline - (git-specific) ability to reorder and aggregate several private commits to deliver a consistent patch. This can only be simulated with other tools - ability to publish (push/pull) branches easily for tests without compromising the main line. Subversion branches, while easy to create, are awful to maintain and rarely used. - clean and remembered merges: patches with clear attribution that can be merged multiple times which, again, makes easy maintenance of several branches running in parallel.Backports, etc. > One of the great things about GiT is that you can can have lots of > parallel and non-linear merges (every developer their own branch; lots > of people merging the same patch into different sequences) -- and as > such I can see it being perfectly tuned for, say, Linux. > Precisely the fact that patches are accepted in just 'one' or 'a few' points make invaluable having good maintenance of in-progress work. > However in the ASF most groups work roughly along fairly linear lines; > with 'one' or just a 'few' points at which a patch is accepted - and > essentially few, or just one, merge point (or a single line of merge > points when backported). Rarely do we merge multiple 'HEAD's. > Not in my experience, it is common to have in-progress work in parallel with bugfixes, etc. subversion is awful for tracking multiple branches in parallel, to the point that I have been using quilt for patch management of top of subversion. This is clearly a kludge that reveals the deficiencies of the workflow. You see? "rarely do we merge multiple HEADs" is seen from the point of view of the repository. If you have 10 developers working on patches, you have 10 people merging continuously their branch with the "official" one. Rarely applies only to the subversion repo. > And I'd almost argue that SVN is a useful framework which helps us > stay on the paved roads - where a single head progresses with group > consensus and generally agreed merit. > I've seen plenty of times where having in-progress patches were consistently conflicted by commits, which multiplied the work implied in keeping them to the point of dropping them (personal). This is trivially easy to do with bazaar or git, and I'm quite sure that darcs or mercurial will offer the same comfort level. At least for my development style, distributed SCM offers one order of magnitude more comfortable environment than centralized SCM. As for your concrete sentence, I'd say that if you need a technical tool as a framework to impose a work flow, then the work flow is possibly broken. If the work flow is sound, having a tool that eases the work won't break it. Regards Santiago (who was working to deliver this and more info on technical merits in the [EMAIL PROTECTED] thread) > Thanks, > > Dw > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
