Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Stephan Menzel (stephan.menzel_at_[hidden])
Date: 2012-03-27 04:08:55

Joel,

I was following this discussion for quite some time now and didn't
want to get involved. Just one point here.

On Tue, Mar 27, 2012 at 5:57 AM, Joel de Guzman
<joel_at_[hidden]> wrote:
> All I want to do is to extract a modular Spirit repo from the
> monolithic Boost repo, with the ability to easily do upstream/
> downstream merges. But I can't do it *easily* with any of
> the DVCS mentioned.

This can be done with git submodules really well. I was actually doing
this in a major project (the size of which outmatches boost) quite
recently. There was a massive code base hosted in svn and I
transitioned to bgit and at least partially I broke it down into
submodules (using subtree by the way, which works like a charm) and
assembled a new "main tree" out of those submodules while maintaining
a build system that enables build, dependency management and testing
of either seperate submodules (that pull in their dependencies) or the
whole tree. Essentially assuming identity of "entity you can depend
on" and "submodule". Boost strikes me as a textbook use case of this
procedure. Especially since modularity is already inherent in the code
base and only needs to be cast into physical form.

All in all, this was incredibly cool and I enjoy working with the
resulting system every day. The only small downside that is left is
the fact that I haven't gotten around to automatically generating the
main tree by parsing a dependency graph in a little python script that
puts the right submodules in the right refs at the right places. Which
would work nice with the git python bindings.

With all this being said, the reason why I didn't bring all this up in
this discussion is the unfortunate fact that all this is fruitless in
large project as long as there are sentiments against it.

> I guess it's back to SVN. The amount of hair pulling is the same
> whatever D/VCS I try. Oh well...

This is just what I have learned from all this. I have spent years
trying to craft the perfect system for this but at the end of the day,
the quaility and power of the system doesn't matter as much as you'd
think it would. Emotion is key. You have to have everyone (or at least
90%) of the contibutors ready and eager to give it a shot. As soon as
you have to discuss it and convince people, it is doomed. People
emotionally rejecting it will always find reasons why they can't work
with it properly. No matter what technology attempts in terms of
power, performance, security, ease of use, safety and so on, emotional
sentiment will triumph. I have learned this the hard way. The simple
fact that there is a heated discussion about this here which is going
on for almost a year now means that it's not gonna work. As simple as
that. You should not try it.
If you have a small project with a few people all in for it then of
course it's a great way to work and it makes so many everyday things
so much nicer but as soon as you have a substantial amount of users
not buying into it, then the mere trial will only cause bad blood.

it just isn't possible to actually really convince somebody else of
this. Everyone has different feelings of what is ease of use, what is
power, what is quality. And then there is a huge amount of fear among
those who have no experience with DVCS and don't want to admit to it.
So they will argue against it using undefineable terms and emotional
responses. Or, even worse, not use it or circumvent usage. Been there,
seen that. Stick with SVN. Forget about all this.

Plus, as many have pointed out during this discussion, there are ways
of using the power of git without going the whole nine yards. git-svn
and friends. Even though this is just a shadow of what could be done,
it's still a great way of actually getting folks to try it and
therefore lose their sentiment.

Cheers, and excuse my wandering slightly off topic...

Stephan