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 21:58 +0100, Gustavo J. A. M. Carneiro wrote:
> 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.

Your changelog text file will be intact in each revision log node. svn 
can give the log in XML format, meaning that you can style it how the heck 
you please. This could easily be an identity type transformation that just 
put the changelog messages in order and dumped them out without touching
the format of the actual text.

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

But wait, if they aren't going to give up on manually written
ChangeLogs, won't merge problems still apply? I thought the point of
bzr/git was that you could micro-commit and side step the need for
changelogs, preventing merge problems?

As i explained above, we can (ab)use the log property very effectively.
The Changelog will still exist, but broken into chunks...

r1-----------------------------------------------
Blah blah blah
  Blah blah blah
    Blah blah blah
r2-----------------------------------------------
Blah blah blah
  Blah blah blah
    Blah blah blah
-------------------------------------------------

It's quite easy to just stick plain text after plain text....

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

It's a one time thing, and isnt that slow. You can ctrl+c and resume
later with bzr-svn too. It would be nice if we could get svndump output,
as bzr-svn can use that too i think.

If you branch from svn constantly i see the problem, but it works nice
if you clone once and branch from the clone.

It's probably better these days, but cloning from a bzr branch used to
take an age too.