Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters <olav bkor dhs org>]

On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote:
> I should start by saying, I used the word 'git' here to really mean
> most any dscm. I personally use Mercurial for my school stuff, (small

Ok. I think if we choose something, it should something we want to
switch to. E.g., if we try out Git, it means we'll move to Git (barring
nasty problems). This is what I did not like about your previous mail
(too much Git).

> 3-4 person development teams on shorter term projects) and I use bzr
> with Launchpad daily. I would recommend against choosing bzr simply
> because the performance issue is so pervasive, otherwise, any DSCM
> really would fit the order. Although, in practice the only realistic
> choices are probably bzr, hg, git, or mtn.

What is the speed of bzr v0.90 like compared to SVN? SVN is said to be
slow as well. Is Bzr noticeably slower?

All the popular (in usage.. except CVS) (D-)SCM evolve. Before GNOME is
ready to switch a lot of development will have happened in the various
tools. So if Git had Windows as a priority, I'd expect Windows to be
solved soon enough.
Another point for SVN is that everything seems to integrate with it.

> On 9/8/07, Olav Vitters <olav bkor dhs org> wrote:
> > On Fri, Sep 07, 2007 at 10:35:55PM -0400, Kevin Kubasik wrote:
> > > While I don't wish to sound trite, I do think almost everyone here
> > > knows what everyone else is going to say, and maybe trying to
> > > headstart the discussion is a bad move, and presumptuous, but allow me
> > > to throw out an idea.
> > >
> > > I think we are more or less in agreement that:
> > > 1) git would lower the barrier of entry for new developers,
> > > 2) git offers some significant benefits  when it comes to sharing and
> > > tracking patches, specifically in the realm of testing and/or release
> > > branching.
> >
> > And so does most of every D-SCM out there. I really don't like Git
> > (windows not being a priority, too complicated, SHA1 collision, etc).
> I don't want to sounds preachy and contradictory, but before I wrote
> this I agreed very strongly with you. I have experimented with git on
> several occasions but before the latest release never considered it a
> real possibility because it was so overly complicated. The new
> interface is almost the exact same as every other distributed system,
> the only real difference is that you don't change directories for each
> branch you make. The 5 seconds primer for working from a centralized
> system would be:

Let's summarize it as: I don't know any D-SCM :-) (only investigate by
checking out docs)
(but I am also not interested in learning a SCM)

For me, I consider the "you don't change directories for each branch you
make" a drawback. I find directories as branches easier to understand (I
hated this in CVS).

> mkdir projdir && cd projdir
> git clone ssh://kkubasik git gnome org/git/coolproject/kkubasik
> git branch newcoolfeature
> git checkout newcoolfeature

I don't like this checkout step.

> <write an awesome feature>
> git commit -a

Is the confusing way removed? If I do git-<TAB> I see 'Display all 144
possibilities'. Why so many? Easy stuff should be easy, hard stuff
should be harder (otherwise the easy stuff is confusing). I never liked
CVS, but I like SVN.. easy to understand.

Anyway, I think you forgot the 'push'.

> Now you have 2 branches (the original, and newcoolfeature) where new
> cool feature has your changes.

Is it easy enough if you want to avoid branches? I usually work on
trunk, nothing else (I do understand people want better merging than
available in SVN).

> > > 4) A complete migration at this point is foolhardy, we just did a big
> > > one, the sysadmin team is strained, and simply put, Subversion isn't
> > > all that bad.
> > > 5) Asking that translators and documenters learn a new (and radially
> > > different) version control system is unreasonable. While the concepts
> > > behind git may work and make great sense for a Computer Science major,
> > > we would probably lose not only a lot of productive translator time
> > > (which is unbelievably valuable as it is), but we might even lose
> > > translators to the frustration of an overly complicated system.
> >
> > You have haven't investigated if Git is ok in the end for them in this
> > proposal.
> >
> > E.g. can git checkout just one file, or just one directory? And be able
> > to commit a new version back (I don't mean a 'svn cat' equivalent). Is
> > there a GUI? Is it available on most distros (a version that will be
> > ok), in the distro versions most translators/documenters have installed?
> > etc.
> 
> This was discussed over at Debian,
> http://www.mail-archive.com/debian-dpkg lists debian org/msg11777.html

I'll check it out later. Probably translators need to
investigate/comment anyway. D-SCM should hopefully be better for
translators though (currently only the coordinator of a language has SVN
and has to commit the patches from other translators.. D-SCM should
help.. if all translators could use it without needing fast internet /
more than a /po dir, etc)

> and they came to the conclusion that I realize isn't nearly as clear
> as I hoped it would be. That distributed development in general is not
> conducive to translation (at least in our current model)  the best bet
> would probably be that for our 'main' repo there is a 'main-trans' or
> similar that would only represent changes going into head. (Much the
> same role as the subversion server would serve in the transition
> period, only completed/accepted changesets would be pushed there.)
> 
> As for git being able to perform all the same tasks as Subversion
> (like single file manipulations/checkouts) it can and does most of it
> well. It's all available as a remote repo, however, given the size and

Good!

> speed at which cloning a repo (even an enormous one) happens, its
> completely realistic (from my limited understanding of the translators
> workflow).

Cloning a repo requires far more space than the .po file they are
interested in. Translators sometimes are only interested in helping out,
while running Windows with 100MB of space free (this is what I heard).
Personally, I don't care if a checkout uses either 500MB or 5GB. I do
care about others.
However, you said it works.. please list it in the wiki though (I wanted
it tested + checked on every D-SCM :).

> However, I am not a translator, or a wizard of Git or Subversion, but
> this qualms a lot of those concerns, while raising some greater
> implementation questions (like how realistic is it to require/ask that
> devs keep a 'static' branch up to date for translations alone?

IMO that is a migration question. I want to move to more the
investigation of the different options.

> > > 6) 3rd party tools and build systems (including our own, like jhbuild)
> > > will suffer from a change, and even moreso from a half-assed one. This
> > > swings both ways, we don't want to implement a change to please some
> > > that leaves the Gnome code hopelessly divided, but at the same time,
> > > we don't want to end up with new projects that are close to gnome, or
> > > indeed even officially part of it, moving their development away from
> > > Gnome.
> >
> > It isn't 3rd party tools. Our tools will suffer badly. There are various
> > (sysadmin, etc) things that depend on SVN. Those all have to be
> > rewritten. That took a few months to complete last time (CVS->SVN).
> >
> Agreed, and it is for this reason that I propose a system which holds on to a
> svn.gnome.org <---> git tip revision until we are completely prepared
> to move. During that period, subversion would still have an accurate
> trunk at all times, it would just lose its branches, which given how
> much versioning history is currently lost when working with branches
> in Subversion, I didn't think that would be a serious concern. _IF_ we
> were to consider this.

I don't mean private/personal branches.. but more a branch of a version
+ related tags. E.g. modules branch for a GNOME versions. Those you do
want to see. That I don't see 'feature-801', that is ok.

> > > That being said, I see the following as a bordering-on-sanity approach
> > > to use as a starting point for a realistic debate over weather Gnome
> > > should go distributed or not.
> >
> > And then you go off on picking only one D-SCM system. IMO, I'd rather
> > setup something else.
> I'm not 100% sure I follow this sentence. I apologize for how 'git is
> awesome and the only solution' my original proposal sounded. As I

Simple explanation? It seems all hype, no real investigation. If it
turns out that Git is best, ok. But not, first Git, then Git and maybe
otherwise SVN.

> mentioned, I have used several D-SCM systems, and in the end I think
> the choice is very individual, and case specific.  The reason git
> seems like a good choice is its stellar Subversion integration, making
> our migration slower and smoother.

It (a D-SCM) will always be a drawback for some; too bad. But ehr,
doesn't every D-SCM have good SVN support?

[..]
> > Main point: Why Git? It seems only because we have a few people
> > screaming 'Git!' the loudest. From what I've learned a few systems will
> > not be good enough: darcs (due to not being able to scale), monotone
> > (IIRC like Git, but worse), arch (obsolete).
> >
> > I'd like a practical discussion between Bzr / Git / Hg for people who do
> > understand all the requirements.
> I agree whole heartedly, I want to emphasize that my inital plan is
> really quite implementation agnostic. (at this level at least, since
> Bzr, Git and Hg all have decent support for SVN)
> >
> > > 2) Even with the addition of git.gnome.org, at this point, Subversion
> > > remains the final and master copy of all Gnome source. Individual
> > > projects are free to branch and merge and frolic as they please, but
> > > it is imperative that the Subversion trunk remain the tip of active
> > > development. Be that through the forwarding of patches through git
> > > systems, or as it always has taken place. However, new projects are
> > > asked to use git, and simply treat Subversion as the master branch,
> > > where all changes are eventually pushed at release time.
> >
> > I disagree with 'new projects are asked to use git'. If such a thing is
> > setup, it'll be a test setup. If it breaks down, too bad.
> Conceded.
> kkubasik--;

I meant this only for git.gnome.org. If we make a choice regarding a
D-SCM, then I'm all for moving projects to the new system. But IMO we
should first do a try out with a smaller project, then move on a project
basis.

> Also somewhat irrelevant, as I feel like we aren't adding new projects
> and modules that incredibly often, but again, I'm not involved with
> the creation of those things, so its possible that we handle far more
> of that then I know.

They are added when asked. Quick check shows we have 31 new SVN repos
since 1 Jan (ignoring those part of SVN migration that were converted
later). Higher rate of new projects would be nice, but GNOME isn't meant
to replace sourceforge.

> > > 3) At this point, if all has gone well, we allow evangelist project
> > > maintainers to move to git exclusively if they so desire, this will
> > > help us asses the migration tools and times for a realistic assessment
> > > of the next step.
> >
> > You've ignored all the other possible D-SCM systems out there. Really, I
> > could do s/git/hg/ and have the same story. I'd really like someone to
> > use the latest version of git/bzr/hg for the first time, and write down
> > all the annoyances. Then use each tool for ~3 months, documenting the
> > process the whole time.
> > After that, we would have a more useful discussion than
> > 'git!'/'bzr'!/'hg' (nobody seems to scream Hg).
> hahaa, true. I think this is a great idea. Granted, we are a little
> low on people new to D-SCM, and committed to Gnome, and with 3 months
> to spare, but I would think that we could amass a small committee (say
> 3-4 developers) to come up with a coherent analysis of each tools
> ability to fit our needs.
> 
> Of course, that also implies that we know what our needs are, and
> thats another step, clearly defining them.

Yeah, I have no idea how all the different D-SCMs are in merging. I sum
it up as D-SCM='good enough', while SVN='not good enough'. I have no
idea if that is reality.

> > > Known Issues:
> > > * Potentially long 'split-code' period - Agreed, this could happen,
> > > but the reason that we still require that subversion trunk represent
> > > an accurate snapshot of development is so that the code can always be
> > > found, and we have the full revision history, we are just embracing
> > > the advantages of a distributed system, and encouraging the Gnome
> > > community to embrace recent advances in technology.
> >
> > So if I understand correctly (hope not) the branch info is in one system
> > (Git) and other parts are in another (SVN). IMO, that is a mess.
> Not as bad as it would seem, we have to remember that with a
> distributed control system, most of the branches we see would never
> exist in a central solution. And even when we do use branches in SVN,
> its generally because we have a version freeze on a release, then
> merge the changes in, almost more of a tag with some bugfixing
> revisions. This isn't a bad thing, its just a difference. Given how
> linear our current system is, I would imagine it being pretty clear
> and clean.

Version freeze? You mean for 2.20.x (1,2,3,) ? Anyway, you need to see
that branch.

> Granted this is all in hypothetical lovely perfectville, I could see
> this getting horrendously messy very fast. I think this is a point
> where the need for a clear and defined set of requirements will help,
> as whats more important? The conversion too, or the ability to go
> back?

IMO that it satisfies most of the requirements from everyone who use it.

> > > **Fact Alert** This is not at all dissimilar from what Mozilla has
> > > started doing with mercurial and CVS, by all reports, its working
> > > quite well, and developers that where panicked over the complete move
> > > to hg[1], have learned the tool, and are comfortable with it, if not
> > > excited (Revision control isn't really something one can ever get to
> > > happy about, its always 'in the way' to some extent)
> >
> > Ehr? Are you sure about this? While Mozilla will support CVS
> > 'indefinitely', if you move a project to Hg, you move it. There is no
> > CVS && Hg period for the same project (which is what you propose).
> 
> http://wiki.mozilla.org/Using_Mercurial_locally_with_CVS

This is regarding having Mozilla stay in CVS, while using Hg locally
(e.g. like git-svn). I meant that Bugzilla (upstream, not the GNOME one)
will switch to Hg, then you need to use GNOME locally and your CVS
loving days are over.

meaning: if project goes Git, there is no SVN for people anymore
(mozilla way translated to GNOME possibly using Git if hell freezes
over;).

> http://hg.mozilla.org/cvs-trunk-mirror/

Same as before. All commits end up in CVS, but you use a 'hg-cvs' thing.
Not too sure about this one though. If the server actually does it, then
it would be more interesting.

> It wasn't planned, but as I understand it, they have (or still are to
> some extent) operating in said limbo. I merely proposed it as a step,
> The more it examined, I think the migration would just have to be by
> project, in the 100% old school migration style fashion.

Per project makes sense. And then have $DSCM-svn thingy available for
projects still in SVN.

[..]
> > > A discussion of the actual merits of Git vs. SVN in an abstract won't
> > > get us anywhere, we have to evaluate Gnome's need (is there one? or is
> >
> > You'll end up comparing between distributed and client-server systems. I
> > did not see any argument why I shouldn't setup a Hg system at this point
> > (which I'll soon be introduced to as Bugzilla will probably test it
> > out).
> That's where I wanted to really lead this discussion, _do we want to
> go distributed_.

Then just start it the discussion that way :)

> If we decide (outside of the realms of specific design flaws in git,
> hg, or bzr  or our SVN setup, if its just a matter of planning and
> logistics, then we plan. If its a lot of planning and logistics, we
> plan longer.
> 
> I see this discussion in no way related to the Account creation
> discussion that started it, and this is not a rush order, we are in
> the pre-planning stages, just discussing if its worth discussing to a
> degree. I just find the best way to really get a good read on the
> situation, is to give us a solid plan or proposal to reference and/or
> work against.

Short proposal:
 * investigate options for different 'users' (devs/translators/etc)
 * choose best of the options
 * see if best options has drawbacks that are unacceptable for a type of user
 * make plan for switch

e.g., perhaps Git will accelerate the work for some type of user (more
than any other D-SCM). This is not a requirement, but would be nice to
have.
Perhaps some things are better in SVN. That should be noted as well.

> > > it a want?). I fully expect (and look forward to) the no doubt heated
> > > discussion that will probably evolve in this thread. However, in the
> > > spirit of actually getting something done, please focus on what
> > > _Gnome_ needs or what you as a _Gnome Developer_ need, not just what
> > > you think would be cool and fun to play with for a while (no doubt
> > > that git has plenty of that appeal).
> >
> > Plus translators, documentation people, sysadmins. E.g. ignoring the
> > need for good windows tools is not an option (means easy to use&install
> > GUI).
> This was something I was unsure of. The general attitude that Windows
> must be a second class citizen is frustrating, but a lot of people
> agree with us on that, and have started to do something about it.
> There are 'stable' MingW builds, and there is a branch (slated for

I knew about MingW, but for Windows you really want an integrated GUI. I
don't think MingW itself is easy enough to install (for translators --
not saying they won't figure it out -- it is that I don't want any
hurdles).

> merge with head before 0.16) which builds nativly using windows
> compilers. While performance will never be the same, 0.15 adds

As long as it is workable, performance is my problem with the Windows
support.

> intelligent support for line endings, and usable windows builds. I'm
> not saying it good support, but its functioal enough that tasks short
> of major merges or repo repair actions wouldn't be impossible.

I don't expect too much people actually doing merges. More 

> See here for more details on Win32 and git
> http://code.google.com/p/msysgit

Haven't checked it out yet. Does it have a good GUI (something like
tortoisesvn.. easy checkout+commit).

> > > I'll try to keep a healthy record of valid proposals/arguments/concerns etc at:
> > > http://live.gnome.org/gitMigration (that includes links to mail
> > > threads when they are up)
> >
> >
> > > [1](I believe that all upstream work after FF 3.0 and Gecko 1.9 will
> > > be in hg, but correct me if I'm wrong)
> >
> > Don't know. But I know it won't be CVS && Hg.
> Agreed ;)
> 
> I think that all we have managed to prove/decide so far is:
>  * These e-mails are long
>  * There is a lot to be considered in such a move, but it appears that
> there is interest in doing so, should it not be too difficult.
> 
> My loose brain-fart of a thought would be to ask the Foundation to
> assign/ask someone to get together
>  1) The Requirements of another migration/shift in development paradigm.
>  2) An accurate evaluation of the D-SCM tools, and which one fits
> those requirements.

A (objective) coordinator, yes. The difficulty in choosing is that there
is a lot of bias (e.g., problems are undervalued).

> On that train of thought, these e-mails are way to big, what are the
> feelings on a 20 minute IRC (Or even something a little snazzier like
> a Jabber conference ;) ) sometime Sunday afternoon/evening (I'm
> talking EST, -4 GMT).

My experience with IRC meetings is that I tend to go watch a movie at
the same time. Email is nicer because it allows me to form some coherent
sentence and you don't have the 'speaking all at the same time' mess.

These emails are long, but that is why you are summarizing it on the
Wiki.

> Anyways, I think its a topic that a 'real' discussion could clarify a lot on.

A small group discussing this should be best though (with different
people from different 'stakeholders' .. dev/translator/sysadmin/...).
Otherwise a choice will never be made. And some things are solvable. I'd
expect Bzr performance to be ok within a year.. probably the timeframe
it takes to fully evaluate the different options.

[..]
> And I dunno if everyone actually read this link, but its not some page
> just touting Git, its somewhat balanced, and the second half of the
> page is reasons why we might just be keeping Subversion around that
> much longer.

Yeah, this page is far from advocacy.

> http://git.or.cz/gitwiki/GitSvnComparsion

-- 
Regards,
Olav