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

["Kevin Kubasik" <kevin kubasik net>]

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

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:

mkdir projdir && cd projdir
git clone ssh://kkubasik git gnome org/git/coolproject/kkubasik
git branch newcoolfeature
git checkout newcoolfeature
<write an awesome feature>
git commit -a

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


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

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
speed at which cloning a repo (even an enormous one) happens, its
completely realistic (from my limited understanding of the translators
workflow).

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?


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

> > 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
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.
>
> > My proposal is centered around Gnome maintaining its centralized
> > development style, while capitalizing on the availability of tools
> > that make collaboration in such an environment much easier.
> > 1) We establish a 'central' git repository, providing remote access
> > via the native git client, and webdav or ftp (a firewall friendly
> > protocol) and if the server can handle the load, rsync. Well call this
> > setup git.gnome.org. It is important to note, that upon
> > git.gnome.org's conception, there has been no formal migration of
> > anything. This is simply a central place for the sharing of git
> > repositories and branches.
>
> Small nit: FTP is never going to be allowed. It has to be secure (webdav
> -- with client certificates which nobody has currently, SSH, SFTP,
> etc).. so in practice it will be SSH.
>
Works for me, I use SSH for everything else ;)

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

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

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?

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

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

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.
>
> > * Doesn't address the translators learning new software component. -
> > Yes, it does, the beauty of forcing the SVN repos to stay active,
>
> No it doesn't. You are keeping SVN alive to avoid it and it is up to
> maintainers to merge between SVN and Git (back and forth). If we want to
> go 'Git', then translators have to be able to use it. Or we'd need the
> theoretical non-existing no-progress-made-yet web interface that handles
> the issue.
>
Agreed, this is a difficult point, maybe its just because I have used
bzr and git both in this very fashion svn->git and back to svn. I
think it sounds a lot worse then it actually is, we have to remember,
these merges and commits are always 1 way.

For example:
Devs 1, 2 and 3 have updated gnomeapp, at somewhat regular intervals
(much like normal commits to a revision control system) the changes
are pushed to subversion. Because the developers are never changing
the po directory, and the translators aren't touching the code, there
aren't conflicts. Yes, the dev would have to type
git merge <svnalias>
occasionally, but the merge algorithms in distributed systems are much
better, and especially in git (the whole tracking content, not the
files) means conflicts only happen when someone stepped into someone
else's yard.

> > * It's half-assed and doesn't accomplish anything that people couldn't
> > do on their own with some webspace, or even just a half decent
> > upstream connection.  - I believe that without some unifying
>
> You are ignoring the central place. You need somewhere all GNOME devs
> are able to commit. This is what is so wrong about
> www.gnome.org/~foo/git/.
>
Sorry, this paragraph didn't really emphasize the point I wanted to
make as well as it should, which is precisely that. We need the
central component, or its all just a wrapper around a subversion
backend, which works fine, its how I do most of my development now.
But to make it a true change we need the central location.

> > place/effort, no module or development team as a whole will actually
> > take advantage of a distributed system while still maintaining their
> > gnome SVN repo. By offering something relatively simple (and low-cost)
> > service, we could offer something that is not only of great interest
> > to the community, but the productivity enhancements etc. that come
> > from allowing free-form branching etc as provided by git.
> >
> > 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_.
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.

>
> > 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
merge with head before 0.16) which builds nativly using windows
compilers. While performance will never be the same, 0.15 adds
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.

See here for more details on Win32 and git
http://code.google.com/p/msysgit
>
> > 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.

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

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

One thing though. I don't remember who or in what mail it was, but
there was the growing sentiment that Centralized SCM is stupid, and so
is anyone who advocates us staying with it. I know Linus is an ass
like that and get's away with it (in his defense, pretty much every
opinion he states gets the most absurd amount of attention, and
ridicule,  most of it completely unwarranted) However, we are a
community, so feel free to laugh hysterically at your screen or
whatever, but please, be nice.

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.

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


Cheers,
Kevin Kubasik


>
> --
> Regards,
> Olav
> _______________________________________________
> foundation-list mailing list
> foundation-list gnome org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>


-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog