Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-03-20 07:03:57

To be honest I'm a bit wary of this discussion, but I think some 
important arguments are overlooked while other, less important 
arguments are being exaggerated.

Thomas Heller wrote:

> Let me try to wrap my head around all this...
> So essentially, the argument is to choose git over whatever is because of its marketshare, right?

I don't think this is the only argument, but you do agree that 
marketshare can make a difference, right?

> The only reason behind this i can think of is to attract new boost contributors [...]
> Ok, I can see that as a possible advantage for git. Especially since a lot of people expressed themselves that svn is _the_ major blocker for not contributing.
> So far so good, this is the argument for people already familiar with git. Let's check the statistics again:
> https://github.com/languages
> Right ... so many potential new developers ... Maybe we should provide Javascript bindings ...

This is a false comparison. The first line on boost.org is literally 
"Boost provides free peer-reviewed portable C++ source libraries". 
So it's not among the goals of Boost to provide Java, JavaScript or 
even Intercal bindings. Using any kind of VCS, on the other hand, is 
a means to the end of producing free peer-reviewed portable C++ 
source libraries.

> So, what about persons who are infected by their favorite poison and have to learn the VCS tool of choice. I keep reading about git having a steep learning curve, so maybe we won't attract those developers either ...

I really don't see why there's such a fuss about git having a steep 
learning curve. Basic usage of git isn't any harder than basic usage 
of svn -- or probably any other VCS; you always need to cover about 
eight commands, two configuration files and a bunch of options. 
People tend to learn only basic usage at first (whatever VCS they're 
learning) and the more advanced stuff is only covered when we feel we 
need it. Perhaps the learning curve is steep if you want to become a 
black belt git master, but that's irrelevant for most Boost 
developers.

Basic usage of git is different from basic usage of svn in some 
crucial aspects, but similar enough for anyone to be able to adjust 
even if you don't like it. It can definitely be learnt within a day. 
Why don't you just give it a try? It never hurts to learn something 
new.

> I'd argue that writing code is not done in the VCS. Be it writing a patch for an existing software or a completely new library. The complexity is in writing the code itself. Or applying the patch and verify it.

I think I'm missing your point here. Is it just an aside, or did you 
mean to argue for or against a particular VCS?

> FWIW, I am the last person who will oppose such a change.
> But currently, noone presented a fair reasoning in favor for git,

Well, allow me to present some fair reasoning to you.

With regard to git versus svn: I think enough fair reasons have been 
given why git (or a DVCS in general) is better than svn. I'm not 
going to repeat those arguments here.

With regard to git versus mercurial: given that it's probably a good 
idea to switch to a DVCS, git and mercurial seem to be the primary 
candidates. I think everyone in this thread should be more willing to 
admit that they're close competitors. In many ways they're about 
equally "good", and when they aren't the differences are quite moot:

- mercurial has native support for Windows, but git is also fairly 
  well supported on Windows and seems to be rapidly improving;
- git allows you to edit history while mercurial doesn't, but which 
  you like better is a matter of preference;
- they seem to treat heads and branches differently, but again that 
  appears to be mostly a matter of preference;
- git seems to be more "powerful" and less susceptible to errors, 
  while mercurial is said to have better documentation -- while this 
  doesn't make either objectively better than the other in the first 
  place, they're also both catching up on their weaker side;
- they are built with very different architectures (many executables 
  written in C versus a monolithic program in Python), but in the end 
  both work well enough and both seem extensible enough for most 
  purposes.

At this point one could say that it doesn't matter whether we pick 
git or mercurial, as long as we actually do it and move away from svn 
(preferably as soon as possible). However, as far as popularity and 
enthousiasm is concerned git seems to win:

- Within the existing Boost community, git seems to be more popular 
  than mercurial. I've seen several library proposals pass by that 
  were versioned with git. I'm also sure that at least one existing 
  Boost library is being maintained in a GitHub repository. AFAICT 
  mercurial scores a solid zero on both of those.
- A lot of work has already been done in order to transition Boost 
  from svn to git. From what I read in the "neglected aspects" 
  thread, John Wiegley's subconvert tool seems to be almost ready and 
  that also seems to be the last (only?) thing we need in order to 
  switch. For mercurial no work has been done yet.
- Git is also more popular than mercurial outside Boost. Like it or 
  not, this simply means that git is a better bet.

> or how such a transition could be done.

To me, that doesn't seem like a hard problem. With some more thought 
one could probably produce a more robust plan, but basically I think 
it would be something like this:

1. Finish the subconvert tool.
2. Verify that everything builds and that all unit tests run as 
   expected.
3. Give library maintainers a grace period in which they can switch 
   development from svn to git. Keep syncing with subconvert in the 
   meanwhile.
4. Once all libraries have transitioned, we can probably establish 
   that the switch was successful and abandon the svn repository.

> [...] Somehow people tend to forget in their Git crusade that other people didn't go through the transition yet, and are searching for arguments to actually make such a change.

Here's an argument for just learning the basics of git: most people 
who tried both svn and git seem to agree that git is sufficiently 
better than svn to make the switch. Surely you want to have a look?

I recommend that you try the tutorial at http://gitimmersion.com/ . 
It doesn't have to take much of your time.

-Julian