incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject RE: Subversion vs other source control systems
Date Sun, 17 Feb 2008 23:26:04 GMT

El dom, 17-02-2008 a las 10:58 -0500, Noel J. Bergman escribió:
> Dirk-Willem van Gulik wrote:
> > Ross Gardler wrote:
> > > 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.
> The issue isn't git as an SVN client.  No one (as far as I know) cares what
> SVN client(s) you use, so long as they don't abuse our SVN server.

I think git-svn abuses the server a lot, as the subversion server is not
designed for copying of the whole history. 

I agree that exporting svn to git/bazaar/mercurial, etc is a way
forward, but it will cause strain to the svn server, for sure. As seen
elsewhere, Jason took this path, and I'm actually using this technique
in a number of places, both with git-svn and bzr-svn. I will keep

> > I am a bit lost here as well -- what does GiT add to the processes/
> > workflows common in the ASF ?

I already answered to this one in the thread. 

- faster commits, branch switching, pulls and pushs
- merges, good and persistent merges
- offline work, offline history diffs
- rebasing is not such a "feature", but it can be useful sometimes
- publishing lots of repositories helps surfacing patches that are
currently hidden until ready for sending/committing

I hope helping each and every developer/contributor counts as helping
the ASF.

> > 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;
> > 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.

huh? every "vendor" keeping patches against apache repositories is
merging often. I don't follow your reasoning, anybody keeping patches is
merging repeatedly against a moving HEAD (for active projects). In my
view, every developer that maintains patches is in effect having a
*private, unpublished* branch. With git and a setup like the one in, all those patches are suddenly public, visible. Think about

> And most importantly, we want our development to be visible to the
> Community, not done in private and committed when finished.  Developers can
> always make more or less transient branches to work on code, still in public
> view, and merge back to shared locations.  The key point here that I believe
> you, I, William and others are all making isn't about technology, it is
> about practice.

The inability of subversion to remember merged results makes working in
a branch unpractical. Been there, done that, very tricky.

Personal repositories can be kept in public, you just can look into the
different branches in to see how a
number of those are updated a lot.

Turning your "key poing" upside down: "We should not try to impose our
practices using a technological tool, specially when doing so impairs

> Now, if there is an SCM that substantially improves the ASF's ability to
> perform *our* practices, that is a separate discussion item.

I'm quite sure currently any one of git, bazaar, mercurial or even darcs
would improve our practices.

Just to make sure, my view of the discussion: 

people *against* changes in SCM is blaming a hypothetical introduction
of git of breaking the ASF practices

I don't think the discussion is, and never was presented as:

evil revolutionaries wanting to break the practices by introduction of
sneaky "solipsistic" tools.

I don't think git will break ASF practices more than keeping quilt
patches, or several repositories, to survive "svn up" without nasty


> 	--- Noel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message