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-30 12:05:48

On Sun, Jan 30, 2011 at 11:49 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> AMDG
>
> On 1/29/2011 11:36 PM, Dean Michael Berris wrote:
>>
>> On Sun, Jan 30, 2011 at 6:22 AM, Steven Watanabe<watanabesj_at_[hidden]>
>> Â wrote:
>>>
>>> On 1/29/2011 1:50 PM, Dave Abrahams wrote:
>>>>
>>>>
>>>> The fact that you can quickly try doing it several different ways
>>>> without affecting the "official repo" is a big plus.
>>>
>>> I don't understand. Â Quickly try doing what?
>>>
>>
>> The merge.
>>
>
> That's what I thought, but it didn't make sense
> to me.
>
> a) Merges in svn are always done locally first.
> Â  It doesn't change the repository until you
> Â  commit.

That's the same in git, except locally it's a repository too. So that
means you can back out individual commits that cause conflicts, choose
which ones you actually want to commit locally -- largely because the
local copy is a repository you can re-order commits, glob together
multiple commits into a single commit, edit the history to make it
nice and clean and manageable (i.e. globbing together small related
changes into a single commit). All these things you cannot do with
subversion because there's only ever one repository version.

> b) Why would I want to try it several different ways?
> Â  I always know exactly what I want to merge before
> Â  I start.

Which is also the point with git -- because you can choose which
changesets exactly you want to take from where into your local
repository. The fact that you *can* do this is a life saver for
multi-developer projects -- and because it's easy it's something you
largely don't have to avoid doing.

> c) Even if I were merging by trial and error, I
> Â  still don't understand what makes a distributed
> Â  system so much better. Â It doesn't seem like it
> Â  should matter.
>

Because in a distributed system, you can have multiple sources to
choose from and many different ways of globbing things together.

I don't know if you follow how the Linux development model works, but
the short of it is that it won't work if they had a single repo that
everybody (as in 1000s of developers) touched. Even in an environment
where you had just 2 developers, by not having to synchronize
everything you're lowering the chance of friction -- and when friction
does occur, the "mess" only happens on the local repository, which you
can fix locally, and then have the changes reflected in a different
"canonical" repository.

For that matter, which repository is the "canonical" repository is
largely a matter of policy. In the Linux case it's the Linus
repository that is the "de facto, canonical" repository. If Linus'
repo is gone or suddenly the community stops trusting him and his
published repo, then the community can congregate around a different
repo.

-- 
Dean Michael Berris
about.me/deanberris