SVN vs Mercurial vs Git
13 views
Skip to first unread message
Kyle Wheeler
Aug 18, 2012, 4:44:29 PM8/18/12
to qthr...@googlegroups.com
Hi all,
I've been thinking about our repository needs, because it's recently
been made pretty clear that SVN just doesn't have the chops.
Particularly as we increase our collaboration network, researchers
have valid needs to develop software - and track revisions and
continue to pull down updates from mainline - that isn't public. One
example of such a concern is that some of our collaborators prefer to
keep their software private up until they've published a paper on it.
As such, SVN's feature-set just doesn't cut it. It seems we need real
distributed revision control.
The two big options we have, based solely on what Googlecode supports
(i.e. to avoid having to deal with a rehosting problem), are Git and
Mercurial. I'm not intimately familiar with either of them, so I'm
soliciting opinions.
Git, as I understand, has the advantage of speed, fanatical
developers, and a larger user base. This is what Trilinos uses. The
biggest problem with it is that Git developers do not believe in
authority, and so there's no way to set policy or to even define a
single branch as authoritative. This leads to a certain amount of
unnecessary complexity to otherwise simple behaviors, but allows you
to do things that would otherwise be impossible (e.g. merge two
partially overlapping packages into a single repository while
maintaining both full revision histories), and there's nothing
preventing anyone from implementing hierarchical structure as
gentlemen's agreements. Mercurial is the competition. This is, for
example, what the mutt mail client uses. Mercurial has a growing user
base, is written in Python, and has most of the same features that Git
has. However, it has a strictly hierarchical view of distributed
revision control, so there is a definite *root* that is authoritative.
This provides a level of simplicity because it increases the number of
assumptions that the software gets to make.
Assuming that's a fair summary of the two, does anyone have any
opinions about the possibility of a software revision control switch?
Opinions about the timing? Or whether it should be undertaken at all?
Or which one we should use?
I suppose I should admit to a slight lean toward Mercurial, because of
the hierarchical thing, but otherwise... opinions?
--
If there's anything more important than my ego around, I want it
caught and shot. Now.
—Zaphod Beeblebrox
I've been thinking about our repository needs, because it's recently
been made pretty clear that SVN just doesn't have the chops.
Particularly as we increase our collaboration network, researchers
have valid needs to develop software - and track revisions and
continue to pull down updates from mainline - that isn't public. One
example of such a concern is that some of our collaborators prefer to
keep their software private up until they've published a paper on it.
As such, SVN's feature-set just doesn't cut it. It seems we need real
distributed revision control.
The two big options we have, based solely on what Googlecode supports
(i.e. to avoid having to deal with a rehosting problem), are Git and
Mercurial. I'm not intimately familiar with either of them, so I'm
soliciting opinions.
Git, as I understand, has the advantage of speed, fanatical
developers, and a larger user base. This is what Trilinos uses. The
biggest problem with it is that Git developers do not believe in
authority, and so there's no way to set policy or to even define a
single branch as authoritative. This leads to a certain amount of
unnecessary complexity to otherwise simple behaviors, but allows you
to do things that would otherwise be impossible (e.g. merge two
partially overlapping packages into a single repository while
maintaining both full revision histories), and there's nothing
preventing anyone from implementing hierarchical structure as
gentlemen's agreements. Mercurial is the competition. This is, for
example, what the mutt mail client uses. Mercurial has a growing user
base, is written in Python, and has most of the same features that Git
has. However, it has a strictly hierarchical view of distributed
revision control, so there is a definite *root* that is authoritative.
This provides a level of simplicity because it increases the number of
assumptions that the software gets to make.
Assuming that's a fair summary of the two, does anyone have any
opinions about the possibility of a software revision control switch?
Opinions about the timing? Or whether it should be undertaken at all?
Or which one we should use?
I suppose I should admit to a slight lean toward Mercurial, because of
the hierarchical thing, but otherwise... opinions?
--
If there's anything more important than my ego around, I want it
caught and shot. Now.
—Zaphod Beeblebrox
Raphael 'kena' Poss
Aug 20, 2012, 7:09:29 AM8/20/12
to qthr...@googlegroups.com
Hi Kyle,
to answer/comment on some of your points:
Op 18 aug 2012, om 22:44 heeft Kyle Wheeler het volgende geschreven:
> The two big options we have, based solely on what Googlecode supports
> (i.e. to avoid having to deal with a rehosting problem), are Git and
> Mercurial. [...]
If you think about it, once you go to the DVCS route, re-hosting is a non-issue. From the moment you would decide to have two repository providers, synchronization would be seamless. That's the point of DVCS.
This to say that you should really consider GitHub; its features for team work and collaboration are quite higher quality and more developed than those on Google code.
> The biggest problem with it is that Git developers do not believe in
> authority, and so there's no way to set policy or to even define a
> single branch as authoritative.
Wrong: you can set up server-side commit hooks that enforce whichever policy you wish to implement. Although I haven't found that necessary myself yet, since you can just as easily rollback unwanted changes.
> Mercurial has a growing user
> base, is written in Python, and has most of the same features that Git
> has.
You forget the #1 advertised advantage of hg over git: its command set is more consistent and its documentation more easy to digest for newcomers.
> Assuming that's a fair summary of the two, does anyone have any
> opinions about the possibility of a software revision control switch?
Yes, it would be a good idea.
> Opinions about the timing?
Whenever: you could start with moving developers to a DVCS repo, but keep the SVN in sync for a while.
> Or which one we should use?
Based on some experience with both I would seriously suggest git for hosting, but advertise both git and hg to prospective (and current) developers:
1) why: hg's ease of use really competes client-side against git, whereas git's flexibility repo-wise allows you to restructure/fix your repo more easily. Again as stated above you can enforce policy with git if really needed.
2) how: the hg-git gateway that allows hg clients to operate over git repos (http://hg-git.github.com/) is really excellent stuff.
--
Raphael 'kena' Poss · r.c....@uva.nl
http://staff.science.uva.nl/~poss/
to answer/comment on some of your points:
Op 18 aug 2012, om 22:44 heeft Kyle Wheeler het volgende geschreven:
> The two big options we have, based solely on what Googlecode supports
> (i.e. to avoid having to deal with a rehosting problem), are Git and
If you think about it, once you go to the DVCS route, re-hosting is a non-issue. From the moment you would decide to have two repository providers, synchronization would be seamless. That's the point of DVCS.
This to say that you should really consider GitHub; its features for team work and collaboration are quite higher quality and more developed than those on Google code.
> The biggest problem with it is that Git developers do not believe in
> authority, and so there's no way to set policy or to even define a
> single branch as authoritative.
> Mercurial has a growing user
> base, is written in Python, and has most of the same features that Git
> has.
> Assuming that's a fair summary of the two, does anyone have any
> opinions about the possibility of a software revision control switch?
> Opinions about the timing?
Whenever: you could start with moving developers to a DVCS repo, but keep the SVN in sync for a while.
> Or which one we should use?
1) why: hg's ease of use really competes client-side against git, whereas git's flexibility repo-wise allows you to restructure/fix your repo more easily. Again as stated above you can enforce policy with git if really needed.
2) how: the hg-git gateway that allows hg clients to operate over git repos (http://hg-git.github.com/) is really excellent stuff.
--
Raphael 'kena' Poss · r.c....@uva.nl
http://staff.science.uva.nl/~poss/
Wheeler, Kyle Bruce
Aug 20, 2012, 11:50:22 AM8/20/12
to <qthreads@googlegroups.com>
Hi Raphael,
On Aug 20, 2012, at 5:09 AM, Raphael 'kena' Poss wrote:
> If you think about it, once you go to the DVCS route, re-hosting is a non-issue. From the moment you would decide to have two repository providers, synchronization would be seamless. That's the point of DVCS.
Ahh, interesting… I would have thought that would exacerbate the "which one is authoritative" problem (I'm assuming synchronizing between the two would be a manual process).
>> The biggest problem with it is that Git developers do not believe in
>> authority, and so there's no way to set policy or to even define a
>> single branch as authoritative.
>
> Wrong: you can set up server-side commit hooks that enforce whichever policy you wish to implement. Although I haven't found that necessary myself yet, since you can just as easily rollback unwanted changes.
I say that because of what I'd heard (or thought I heard) from the Trilinos folks. I just checked with the guy in charge of Trilinos' repository for details. Apparently, while you CAN set up commit hooks (i.e. on the server), they *cannot* be propagated through a clone operation (the scripts aren't even propagated unless you have redundant copies in the body of the checkout). Because of this, it's annoying to even add commit scripts to clones when the cloner *wants* to have them. It *can* be done, obviously - the best way to do it is to maintain scripts to set up the hooks that friendly and conscientious users have to remember to run after a clone operation (easy to forget). In practice, consistent policy enforcement can only be done on the so-called "authoritative" repository (which has no real claim to authority other than "we all agree this one is authoritative"), and can only be done at the "push" granularity (the pre-receive hook). This makes it reasonably easy to report "your entire 3-month push fails the check", and particularly labor-intensive (and potentially VERY complex, depending on the shape of the commit tree you're pushing) to say things like "commit X in your push doesn't meet spec, and that's the reason your push is being rejected".
> You forget the #1 advertised advantage of hg over git: its command set is more consistent and its documentation more easy to digest for newcomers.
Good to know!
> Whenever: you could start with moving developers to a DVCS repo, but keep the SVN in sync for a while.
Hmmm. OK, good possibility to keep in mind.
Thanks for responding! Gave me some stuff to think about.
--
Kyle B. Wheeler
Dept. 1423: Scalable System Software
Sandia National Laboratories
505-844-0394
On Aug 20, 2012, at 5:09 AM, Raphael 'kena' Poss wrote:
> If you think about it, once you go to the DVCS route, re-hosting is a non-issue. From the moment you would decide to have two repository providers, synchronization would be seamless. That's the point of DVCS.
>> The biggest problem with it is that Git developers do not believe in
>> authority, and so there's no way to set policy or to even define a
>> single branch as authoritative.
>
> Wrong: you can set up server-side commit hooks that enforce whichever policy you wish to implement. Although I haven't found that necessary myself yet, since you can just as easily rollback unwanted changes.
> You forget the #1 advertised advantage of hg over git: its command set is more consistent and its documentation more easy to digest for newcomers.
> Whenever: you could start with moving developers to a DVCS repo, but keep the SVN in sync for a while.
Thanks for responding! Gave me some stuff to think about.
--
Kyle B. Wheeler
Dept. 1423: Scalable System Software
Sandia National Laboratories
505-844-0394
Raphael 'kena' Poss
Aug 20, 2012, 2:44:01 PM8/20/12
to qthr...@googlegroups.com
Op 20 aug 2012, om 17:50 heeft Wheeler, Kyle Bruce het volgende geschreven:
> I say that because of what I'd heard (or thought I heard) from the Trilinos folks. [...]
Oh, I see.
Well here I would only share my appreciation of github's system of "pull requests". With this system a "main" project repo is administered and can be committed to by only a few core developers. Any further developer would fork their own clone of the repo, make their changes there, and then submit their changes towards the main repo via a "pull request" via the web interface. This informs the core developers of a proposed change, and lets them review the code before accepting it. If the change is satisfying it can then be merged in one click.
Cheers,
Stark, Dylan
Aug 20, 2012, 6:25:30 PM8/20/12
to <qthreads@googlegroups.com>
I would certainly favor a move to a DVCS - I'm actually using git-svn to manage my Qthreads checkouts as a Git repository locally. That said, you can imagine that I'd be in favor of going with Git vs Mercurial. One more consideration not yet highlighted: availability.
I don't have any numbers or references to back it up, but my perception is that Git is the more widely available package on the different systems where I checkout Qthreads.
Dylan
Dylan Stark
Scalable Computer Architectures Dept
Sandia National Laboratories
Reply all
Reply to author
Forward
0 new messages