Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))

[John Carr <john carr unrouted co uk>]

On Wed, 2007-09-12 at 20:47 +0100, Gustavo J. A. M. Carneiro wrote:
> On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote:
> > On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote:
> > > 2007/9/11, Bryan Clark <bclark redhat com>:
> > > > GNOME is not in need of a DSCM or any other kind of new SCM.  For source
> > > > control, SVN works fine, just like CVS worked fine.  I'm not looking to
> > > > argue the features of one DSCM above another or what we have now, but really
> > > > the controlling of the source code isn't the problem this DSCM debate is
> > > > circling.
> > > 
> > > The problem which prompted this debate again was the infamous SVN
> > > accounts lag. DSCM allows people to comfortably work with "their repo"
> > > and easily get a subset of their current work to a patch for
> > > submitting to eg. bugzilla. Currently, you'd need to take a checkout
> > > for each "line of work" you start unless you want to backup your work
> > > manually with svn diff (urgh). Not so hot, specially since if you are
> > > not on the net all the time.
> > > 
> > > If you can comfortably work without access to the central repo, the
> > > need for the access becomes less of an issue. Thus helping people keep
> > > patient with the accounts lag, possibly even making it unneccessary
> > > for some.
> > > 
> > > So, in my opinion, GNOME does need DSCM as a *part* of the solution
> > > for the current problems.
> > 
> > Both Git and Bzr have svn interoperability. Are these implementations so
> > broken as to not be useable by the DSCM-desiring people?
> > 
> > I've had a quick play with bzr-svn and it feels like quite a natural
> > step up from svn. It has the advantage that people who want DSCM get it,
> > it doesn't involve learning lots of new commands (very similar to svn
> > commands wise). And of course, for those of us that don't need it, we
> > don't have to use it. Finally, no infrastructure changes are needed to
> > take advantge of it either.
> > 
> > I presume the same is true with git-svn, thus avoiding git/bzr wars?
> 
> If a developer wants to use e.g. bzr, he can use it behind the scenes,
> but:
> 
> 	1. With a manually written ChangeLog file, you can't easily branch and
> merge even with bzr, or you can but every time you merge you'll get
> conflicts in the ChangeLog file;
> 
> 	2. Unless the bzr branch is official, you can't get rid the manually
> written ChangeLog file because you have to support svn users who can't
> easily do micro commits (due to network lag) thus need a ChangeLog file
> to work around this limitation;
> 
> 	3. It is unthinkable to make a bzr branch official branch for a project
> unless it's hosted in a GNOME server;
> 
> 	4. To host a bzr branch in a GNOME server you need official support
> from the GNOME admin team because:
> 
> 		a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not
> appropriate for that, or so they tell us;
> 
> 		b) You need to allow multiple commiters to the same user-neutral
> branch;
> 
> 		c) you need to run a bzr smart server on the server side or else
> network performance is going to be rather bad.
> 
> Bottom line, unless GNOME supports a DSCM, it "kind of works", but
> things will never go very smoothly and developers will not take full
> advantage of the DSCM.
> 

I don't see the problem with creating your Changelog and attaching it to
the revision log with "svn ci -F SomeChangelogFile". With this you can
build up a revision log message as you go. And your changelog data is
now in the revision log (where it belongs IMHO) and doesn't conflict
anymore. Pretty easy.

Once the Changelog is removed, or no longer updated, this argument goes
away.

So what other problems are there with bzr-svn / git-svn?

John