would SVK be an option? This would allow to re-use the already existing SVN infrastracture.
No need for changes to the ASF infrastructure... On Thu, Feb 14, 2008 at 1:55 PM, Santiago Gala <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
