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

[Olav Vitters <olav bkor dhs org>]

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

-- 
Regards,
Olav