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

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Wed, 2007-09-12 at 21:40 +0100, John Carr wrote:
> 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.

It's not the same.  You don't want your ChangeLog messages to have
bulleted items including a list of changed files, because if you do that
then when you generate a full ChangeLog from the stored commit messages
things will appear all unaligned.

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

Like I tried to explain, no maintainer will want to give up on manually
written ChangeLog files because:
	1- bundling lots of changes in a single commit log message will make
the generated changelog look really bad;
	2- not "bundling lots of changes in a single commit log message"
implies making lots small commits (i call it micro commits), which is
very slow with subversion due to network roundtrips.

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

Cloning from svn to bzr (or git or whatever) takes ages, so you want to
have an official bzr branch version of your project to make branching
fast and easy for everyone else.  Hence you want hosting of bzr branches
in a GNOME server, and all my remaining reasons still apply.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
"The universe is always one step beyond logic" -- Frank Herbert