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

[John Carr <john carr unrouted co uk>]

On Tue, 2007-09-18 at 18:15 -0400, Behdad Esfahbod wrote:
> 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

I was more interested in whether this was a case of upgrading the
existing GNOME 'way', or reinventing it. 

For example, in the linux case (as far as i can tell) the workflow is
based around the mailing list, a branch each for the core devs and then
the Linus branch. It's this gatekeeper approach which I would have been
most concerned about in GNOME.

>From your description, i take it as an upgrade to a "fixed" SVN with
better branches.

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

I can't speak for git-svn. But bzr-svn is certainly not that broken. I
branched earlier and made a couple of bug fixes on the train. On
returning i did "bzr push". The fixes arrived in the parent svn tree as
individual commits.

(Also, from what I am told I could publish my branch somewhere (not SVN)
and someone could merge my changes into their branch of the parent SVN.
So I could pull John S's work into my branch before either set of work
is ready for trunk. Basically, it goes to extreme lengths to ensure that
a remote SVN branch is like a remote BZR branch. On a related note, they
are even working on exposing an SVN server that pushes commits to a BZR
backend).

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

Ahh, I thought kernel.org one would be pretty authorative. Yes, I saw
Shauns blog post - its excellent. Well written, and really showed how
(from a developer point of view) this is all potentially going to work.
Federico's notes at http://live.gnome.org/GitForGnomeDevelopers. I saw
those and they are nice too, and decided to have a go...

I wimped out. While the git specific parts aren't too out of the
ordinary, I can see why you are not fond of git-svn. At the time, thats
why I was inspired to create the page
http://live.gnome.org/BzrForGnomeDevelopers. Unfortunately my writing
style isn't awesome. Hopefully i'll have time to finish...

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

I was referring to the kernel.org notes again (maybe we should send them
doc patches!?), and it said i should:

git checkout -- curses/ux_audio_oss.c

to reverse botched changes to curses/ux_audo_oss.c. While i grok the
basic sentiment, git revert curse/ux_audio_oss.c just feels more
natural. Picky, i know.

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

That was a grumpy dig at something I read saying that a script could be
made to make git easy for idiots like me. Although Shaun's blog post has
done a lot to alleviete my misgivings about the learning curve for devs.

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

I know you've tried and i'm not conciously trying to be a stubbon
whiner, and I know how I must be annoying like a broken record... but I
honestly can't see one that isn't possible with bzr-svn. The branching,
sharing branches, bisecting, micro local commits, pushing to svn without
losing commits, workflow with patch "bundles". It's a pretty good
experience from the eyes of a simpleton.

And fun interactions with other bzr tools too. I can happily browse my
svn history, diffs and logs galore, with bzr-gtk.

http://samba.org/~jelmer/bzr/bzrsvn-merge.png

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

Will agree on git-svn. Though having seen Jelmer's work on bzr-svn, I
can't help but disagree on your playing down of bzr-svn. See above...

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

I'm sorry, my response wasn't clearly worded. Your response has always
been that GIT is the superior system to everything else. I'm asking lots
of questions to try and understand that position better.

It would seem the current community situation is this:

It seems that git-svn is insufficent. Whilst bzr-svn is a whole let
better (and workable, unless someone presents a specific case), it will
never make a git hacker happy. Git people will still be unhappy, and
everything is OK for svn / bzr-svn users. Mercurial people are lacking
in number.

Now for the bzr-svn using people, what is their lure to git? Speed? its
more "pure"?

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

Indeed. I'm surprised how much discussion has centered around the
changelog of all things.

Shaun did a good job with his blog post. In all honesty, it was the
first piece of GNOME and GIT reading throughout this discussion that
didnt make me bit my tongue. Theres not really even a hint of a "side"
in his piece.

John