Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-01-29 05:08:47

> I think you're looking at it as a purely tool vs tool comparison which
> doesn't amount to much. Consider then what the workflow a distributed
> version control system enables and you might see the difference
> clearer.
>
> Consider a library being worked on by N different people concurrently.
> Each one can work on exactly the same code locally, making their
> changes locally. Then say someone pushes their changes to the
> "canonical" repository. Each person can then pull these changes
> locally, stabilizing their own local repository, and fixing things
> until it's stable. You can keep doing this every time without any one
> of these N people waiting on anybody to "finish".

That's exactly what we do now with SVN.

> Now then imagine
> that there's only one person who has push capabilities/rights to that
> "canonical" repository and that person's called a maintainer.
>
> All the N-1 people then ask this maintainer to pull changes in or
> merge patches submitted by them. If the maintainer is willing and
> capable, that's fine and dandy changes get merged. Now consider when
> maintainer is unwilling or incapable, what happens to the changes
> these N-1 people make? Simple, they publish their repository somewhere
> accessible and all the N-2 people can congregate around that
> repository instead. MIA maintainer out of the way, release managers
> can choose to pull from someone else's published version of the
> library. Easy as pie.

OK, if forking is a good thing then I can see how that helps.

Question: what's to stop you from right now, building a better and greater 
version of library X in the sandbox, and then asking the Boost community to 
consider that the new Trunk and you the new maintainer?  Different tool, 
same process.

I still think there are pros and cons though:

* As I see it Git encourages developers to keep their changes local for 
longer and then merge when stable.  That's cool, and I can see some 
advantages especially for developers wanting to get involved, but I predict 
more work for maintainers of the canonical repro trying to figure out how to 
resolve all those conflicts.  Obviously with SVN we still get conflicts - 
for example Paul and I often step on each others toes editing the Math lib 
docs - but these issues tend to crop up sooner rather than later which at 
least makes the issue manageable to some level.
* I happen to like the fact that SVN stores things *not on my hard drive*, 
it means I just don't have to worry about what happens if my laptop goes 
belly up, gets lost, stolen, dropped, or heaven forbid "coffeed".  On the 
other hand the "instant" commits and version history from a local copy would 
be nice...

Regards, John.