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

["Kevin Kubasik" <kevin kubasik net>]

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.
3) git-svn is an acceptable and stable program, while we should not
base a system off of it, asking that developers do use it is not out
of the question.

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


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.

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.

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.

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.

4) The final step would be the introduction of git clones of every
Subversion module. Luckily, if done over a fast LAN (or ideally,
harddisk) this can be done very quickly, even for long-history'ed
projects. In addition, these git clones would be updated at some
regular interval (say hourly... really depends on the realistic cost
of the operation, and how active SVN still is)

At this point we have something not dissimilar from launchpad's
vcs-imports component. In short, projects are free to work in either
system, the goal would be (in my mind) that most development happened
in git, revolving around its distributed and free flowing development
model. However, since with git all the changes going upstream can just
be merged into the maintainers branch, and (s)he can push those
changes to subversion, so we still have all our source history in one
format and one place, should we choose to not stick with git.

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.
**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)
* Doesn't address the translators learning new software component. -
Yes, it does, the beauty of forcing the SVN repos to stay active,
while using them with git is that as long as the git->svn action only
involves one git branch and one subversion branch, things are neat and
cheery. Now using git to manage branches in subversion is just plain
stupid, but translators could continue to work in the old system as
long as the developers remember to occasionally fetch any changes.
This reflects a serious change in mentality that DRCS' can enable.
Merging is not the devil, its cheap, easy, reliable, clean, and part
of distributed development.

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

Holy Crud, thats a long e-mail. My apologies, I seem to have rambled
myself a bit /me *blushes*

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)

Cheers,
Kevin Kubasik


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



On 9/7/07, Zeeshan Ali <zeenix gstreamer net> wrote:
> Hi!
>
> On 9/7/07, Olav Vitters <olav bkor dhs org> wrote:
> > On Fri, Sep 07, 2007 at 11:57:19AM +0300, Zeeshan Ali wrote:
> > >    About the svn access, all centralized VCS's are meant for
> > > dictatorships. If the gnome foundation really wants to improve the
> > > situation, i recommend moving to git or some other non-distributed VCS
> > > instead of brain-dead centralized svn for the following reason:
> >
> > This will take 12x longer than fixing the problem. We'll end up with a
> > workaround (as someone still finally has to commit).
>
>    How come? The developer with write-access to the main repo (who is
> acting as the proxy) would get the commits pushed to his repo from the
> other developer and he would just push them upstream along with his
> commits. As me and Kalle tried to point out, with git you have a lot
> of freedom to do things in many different ways, which isn't true about
> SVN.
>
> > Finally, people can
> > already use a D-SCM together with SVN (git/bzr/.. support SVN). So if
> > D-SCM would solve things, there wouldn't be an issue currently.
>
>   As I mentioned in one of my previous emails, the problem would have
> been far too small to make a big fuss about it if either A. it was a
> matter of a git repo instead of an SVN repo or B. the proxy developer
> and the developer needing write access, had decided to use git
> together with git-svn at their end.
>
> > > 1. Developers can clone the main repo and the maintainers (people with
> > > write-access) can just pull from their cloned repos. This way a
> > > developer won't really need write access and he'll just keep on
> > > committing his changes to his repo and inform the maintainer(s) about
> > > his newest cool changes and the maintainer(s) can pull those changes
> > > if they like/need them.
> >
> > I call that a workaround. The problem is the access to the main repos.
> > If the maintainer doesn't pull from every developer you end up with the
> > same problem. At one point someone needs to do something (give access to
> > something / pull).
>
>    The developer doesn't necessarily need to 'pull'. What you are
> addressing is just one of the many ways things can operate when Git is
> being used. Please read above. I mentioned at least two different
> modes of operation which are not mutually exclusive.
>
> > > 2. #1 is a generic advantage of using a non-distributed VCS but the
> > > reason i would go for git is speed: it's amazingly super fast in all
> > > it's operations and will save a lot of precious developer time.
> >
> > You are ignoring the drawbacks and that it won't solve this issue.
>
>    For example?
>
> > I am all for D-SCM, but it is not a hammer.
>
>   That might be but they are much better than centralized SCMs, at
> least git is quite obviously superior to SVN.
>
> > > 3. No need to maintain two levels of changelog.
> >
> > That is not true. The ChangeLog requirement has been discussed before.
> > Suggest to read the archives for that discussion (here / d-d-l).
>
>    I searched the archive and topics of the mails i found, didn't seem
> relevant so it would be nice if you either provide me a link to the
> thread or summarize the conclusion. We are using SVN so ChangeLog
> requirement obviously makes sense but I can't imagine it making any
> sense at all in D-SCMs especially git since i can always get the
> changelog using `git log`.
>
> > > For details on why a good and
> > > self-respecting developer wouldn't ever consider using svn over git,
> > > you have to watch this presentation by Linus:
> > > http://video.google.com/videoplay?docid=-2199332044603874737 .
> >
> > Last time I watched this it only talked about the benefits of a
> > distributed SCM vs non-distributed SCM. Further, the style of presenting
> > is very flame-ish. It only serves as advocacy to perhaps try some other
> > D-SCM.
>
>   You need to look at it a bit objectively. Linus says "you are stupid
> and ugly" because you truly are stupid if you prefer to use SVN or any
> centralized SCM and he clearly points out most of the reason why this
> it the honest truth.
>
> > Btw, generalising my arguments against git to 'sucky UI' is
> > a misrepresentation.
>
>    I won't commit that mistake but i didn't really see any other
> convincing argument either. :)
>
> --
> Regards,
>
> Zeeshan Ali
> FSF member#5124
> _______________________________________________
> foundation-list mailing list
> foundation-list gnome org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>


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