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

[Behdad Esfahbod <behdad behdad org>]

On Sun, 2007-09-16 at 19:11 +0100, John Carr wrote:
> 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.

Depends on how you look at it.  From far, yes, it looks like just
s/svn/git, but from near, you see developers hosting their own trees for
various experimental features, etc.  This is how kernel works, and how
cairo and other fd.o modules work.  This is the central cairo repo for
example:

  git+ssh://git.cairographics.org/git/cairo

And this is my cairo tree:

  git://people.freedesktop.org/~behdad/cairo

Carl Worth's:

  git://people.freedesktop.org/~cworth/cairo

Chris Wilson:

  git://people.freedesktop.org/~ickle/cairo

Mathias Hasselmann:

  git://people.freedesktop.org/~hasselmm/cairo

and so on...

> 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?)

git-svn and bzr-svn are broken.  They are good to get some benefits of
git/bzr with svn, but shouldn't be thought of as a long-term plan.  You
have to flatten all the 20 micro-commits you made before pushing a
branch out to SVN, and that undoes all the nice properties of
micro-commits and git.  Next time you track a bug down to that commit
good luck figuring out what's going on...

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

So, you looked at the wrong place.  I never ran any of those commands
(ok, I did git-repack a couple times, but I don't normally do it).  Call
me noob, whatever.  Check out excellent git howtos Shaun and Federico
has written for GNOME users.

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

Which syntax?

git revert commit-id

doesn't look anything to not like to me.  Please be specific.

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

The trick is to not look at all the scary things that is possible with
git.  Ask for what you need and see scream if that looks hard to handle.
To me, tagging in svn is the hardest thing I had to ever learn.  And it
was so insane that I wrote a script for it.

> 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"?

The only git script I use is one for the combination of "git fetch; git
rebase".  That's more because I'm lazy than anything else.  I'm also
thinking of putting things like that in Makefile.am.

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

They do.  Only central repo needs a slight chmod a+x.

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

I've tried to give you various killer features, you seem like not
wanting to see it.  But no matter how much people say, you don't get it
until you try one.  And try one in a real project with multiple active
developers.  Otherwise for a commit in a while, sure it doesn't make any
difference what you use.


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

Not sure what you are talking about.  I've not tried bzr-svn.  If we
want to use git-svn/bzr-svn, I don't see why we are having this
discussion in the first place.  My argument is that with git-svn/bzr-svn
one cannot fully utilize the power of git/bzr.

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

So your response to my "SVN sucks" reasons is bzr-svn/git-svn don't have
that problem.  Fine.  Next time please ask the correct question of
"what's wrong with bzr-svn/git-svn" if that's what you really mean.

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


Getting frustrated of this endless debate.  Not sure how long before I
take the projects I maintain out and maintain a GIT repo in my
gnome.org/~behdad account.  Many people opposing git do not commit to
those modules after all (or any GNOME module FWIW).  I believe
maintainers and developers have a tad more bit of say over what they
want to use.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759