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

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-28 15:33:02

On Sat, Jan 29, 2011 at 4:10 AM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 1/28/2011 1:46 PM, John Maddock wrote:
>>
>> I still haven't heard from the git proponents, what's wrong with using
>> git-svn to manage a local - i.e. distributed - git repository, and then
>> periodically pushing changes to SVN. In other words working with git
>> just as you normally would, except for having to type "git svn" from
>> time to time? This isn't a rhetorical question BTW, I've never used
>> either git or git-svn, so I clearly don't know what I'm missing ;-)
>
> The arguments of Git's superiority as a distributed VCS over SVN's
> centralized VCS do not convince me either. I understand them but I wonder if
> the switch from SVN to Git is worth it just so end-users can make their own
> changes to a local Git repository and then push their entire repository to a
> centralized location some time later. This is as opposed to SVN users making
> periodic changes by committing to a centralized SVN repository periodically.
> I just do not see the big deal in the difference.
>

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". 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.

Explain to me now then how you will enable this kind of workflow with
a centralized SCM.

> I do not see Boost's possible need to become less centralized and go from a
> monolithic distribution to possible individual distributions as dependent on
> using a distributed repository model versus a centralized repository model.
> I believe many other issues are much more important, as brought up by Robert
> Ramey and others.
>

How about that try above?

> I would much rather Boost have a discussion of those other issues than focus
> on Git versus SVN, which I think of as just another red herring.
>

How about the workflow, is that something you'd like to see discussed as well?

-- 
Dean Michael Berris
about.me/deanberris