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

[John Carr <john carr unrouted co uk>]

On Sun, 2007-09-16 at 12:27 -0400, Behdad Esfahbod wrote:
> On Sun, 2007-09-16 at 09:10 +0100, John Carr wrote:
> > On Sat, 2007-09-15 at 18:26 -0400, Behdad Esfahbod wrote:
> > > On Fri, 2007-09-14 at 21:31 +0200, Ali Sabil wrote:
> > > > I am wondering why discussion is continuing in the "Git vs SVN (was:
> > > > Can we improve things?)" thread, why the discussion is not happening
> > > > here instead ?!
> > > > 
> > > > I don't want to offend anyone (so take it lightly), but I am afraid
> > > > that many of us are subject to a "Confirmation bias" ... Can't we just
> > > > continue the discussion in this thread comparing svn to DRCS in
> > > > general before deciding on which DRCS would be the most appropriate to
> > > > use within the GNOME project ?
> > > 
> > > Because you can't talk about some abstract concept.  I can't imagine
> > > anyone having any remotely legitimate reason to discuss that DSCM
> > > systems are not good for GNOME.  This is simply a corollary of the fact
> > > that DSCMs provide all functionality that the SCSMs do.  So,
> > > theoretically, you don't lose anything, and gain some.
> > 
> > How do you set up a master repository with GIT/BZR? Generally it seems
> > to involve pushing over ssh/sftp? Does that integrate with GNOME
> > accounts? Does letting people push mean they could push other crap and
> > hurt the repo? Or have they both gained daemons? Do they have logins
> > that integrate with gnome accounts? Can one daemon handle multiple
> > repos?
> 
> These are all no problem at all.  See fd.o for example.  We are already
> using ssh with SVN.  It's the same with git. 

How do you see the workflow working though. This isn't simply
s/svn/git/. Are you looking to implement centralised VCS powered by GIT,
in effect giving you SVN but with offline/merge powers? Or do you want
something else out of it.

If we are still using the same accounts infrastructure, then this does
nothing to improve the situation RE: new accounts. Which was the whole
starting point of this discussion. (You'll probably argue that the win
here is that people can maintain local branches to work from if we move
to git, but git-svn and bzr-svn don't rule it out either do they?)

> 
> > Perhaps a legitimate reason is that moving to a DSCM won't be a benefit
> > to everyone, yet everyone will have to learn another set of tools. Even
> > just last month someone didnt know how to link to a file in SVN. And in
> > order to make happy The GIT Crowd (and piss off all the people that just
> > want to get on with their project) a sugar load of infrastructure needs
> > to be tossed away.
> 
> Who was that someone?  Lets say we install a web application for
> translators.  Who else can't be bothered to learn the new tool?  If they
> can't, they can always submit patches.

It was on DDL, not too long back. And he wasn't alone.

I just decided to look at some git notes on kernel.org [1]. One of the
first things it advised me (in its "20 commands or so" version) that i
should:

git fsck
git count-objects
git repack
git gc

4 commands out of the 20 basic ones i should now are commands to make
sure my repository doesnt expand and expand and then corrupt/collapse on
itself? 

I don't like the syntax for reverting changes either. 

Quite frankly after looking at those notes (and from my previous battles
with this tool, and others ["git was beyond unreasonably complex to
attempt to learn"]), then I might be one of those people!

Yes, you can make a nice wrapper script. But is that as you said
yesterday, "using one tool to try and fix a broken one"?

> 
> > Does CIA.vc have bzr/git support? I guess a few GNOME projects must use
> > it as GNOME is the third most active project today.
> 
> Yes, at least for git, but I'm pretty sure it does bzr too.  You could
> have took a look and tell too.  Do your homework.

I had a quick look at one CIA script and it /looked/ like it had to be
installed by each git user locally. It's a post-commit hook.. I wonder
if post-receive would be better for this kind of script (in our
theoretical distributed-centralised setup..)? Or do post-commit hooks
get fired when you push to a central server as well?

> 
> > How does buildbot work with bzr/git? The project looks a bit stalled,
> > but the GNOME buildbot was a great idea that I was hoping to see gain
> > ground.
> 
> jhbuild supports both.

I was talking about buildbot. Which apparently it does \o/. I hope the
build brigade can change their setup easily though...

I only mentioned these specific points because I want people to consider
that this change isn't just apt-get remove; apt-get install. In all of
my cases, support exists. That doesnt mean migration will be smooth or
easy though. We are asking for a lot of work from the server guys and
also asking devs to move to something new as well. Give me a killer
feature that absolutely cannot happen the way things are that will make
this all work worthwhile.

> > > In practice however, git is too hard and confusing to learn.  *That* is
> > > a reason against this specific DSCM system.
> > 
> > This is the reason i've been using bzr-svn. Its "svn with benefits"
> > style suits me very well. The fact is, i'm happy with svn until i'm
> > stranded without an internet connection, thats with bzr steps in. And
> > its brilliant.
> 
> We should get past all this git-svn and bzr-svn if we really are to
> decide anything.

You said talking in abstracts was bad. So i don't understand. If bzr-svn
can cope with a situation and git-svn cannot then it should be
mentioned. If bzr-svn/git-svn can cope with a situation that is
portrayed as a reason to move wholly to git, then it should be
mentioned.

> > > > I am also afraid that we might be just becoming nothing more but "geek
> > > > fashion" addicts trying to follow the latest RCS tendency without
> > > > really building solid and constructive arguments !
> > > 
> > > I was going to be offended, but you warned :).  Now that most probably
> > > means that you don't hack on the more crowded projects that much...
> > > Many Gtk+ developers for example could not have been as productive as
> > > they are right now if it wasn't for git-svn.  And that's only a
> > > half-arsed solution.
> > 
> > Again, its ok to say something is crap, but please tell us why! "SVN
> > SUCKS!!" and "GIT FTW!!" aren't very compelling reasons.
> 
> No idea how to write it down in short...
> Because branches are not designed for easy merging.

I'll concede this point. In its favor, the new version does a lot to
address this. 

svnmerge.py is also an excellent tool, from personal experience it was a
dream to maintain an experimental branch of an internal project. I'm not
sure, but I think it was built to expirement with how better merging in
SVN might work. Which fills me with hope for the next SVN version.

bzr-svn seems to do well in this case as well. Can't speak for git-svn.

> Because I don't get the entire history at my fingertips.
bzr-svn is fine, presume git-svn is fine.

> Because bisecting is not an option.
bzr-svn is fine, heard git-svn is fine.

> Because even committing is slow.
Does commiting get slower as repo size increases? Commiting for me takes
just a few seconds. Added delays are incurred for hooks, so on an
repository i maintained i made sure the hooks were non blocking.

I don't expect pushing to the server to take < SVN in any case, but with
the bzr-svn/git-svn tools you can have your micro-commits and only have
to suffer for 5-20 seconds when you are ready for the feature to hit
trunk.

> Because I can't commit locally, so have to finish a patch before pushing
> it out and I have to do my own "svn diff > x.patch" to have some kind of
> backup in case I screw up.
Haven't tried in a while, but i did have 3 branches on the go at once
with bzr-svn. This was interesting, but worked. I could commit locally
and just "bzr branch" the master if i wanted to look at something else.

>From what i've looked at, git-svn can handle this as well.

I'm still confused by arguments on here regarading commit logs. Why are
the log properties of DSCM better than SVN? I don't see how
micro-commits lead to people dropping the Changelog file? Or how pure
DSCM deals with Changelogs any better than git-svn/bzr-svn? Do these
tools pollute the commitlog with flattened log messages? (This doesnt
seem to happen with my bzr-svn, but im not sure for all cases or for
git-svn).

John

[1] http://www.kernel.org/pub/software/scm/git/docs/everyday.html