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@boost-consulting.com> 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