incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@apache.org>
Subject Re: Subversion vs other source control systems
Date Thu, 14 Feb 2008 12:55:47 GMT

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 community@apache.org thread)

> Thanks,
> 
> Dw
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message