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

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-01-30 18:38:42

AMDG

On 1/30/2011 9:05 AM, Dean Michael Berris wrote:
> On Sun, Jan 30, 2011 at 11:49 PM, Steven Watanabe<watanabesj_at_[hidden]>  wrote:
>> 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

Okay, so this is just an instance of using
local commits--which as far as I can tell
is the only actual advantage of a DVCS.
I can understand someone wanting this although
it would probably not affect me personally,
since,
a) If I'm merging a lot of changes at once,
    it's only because I'm synching 2 branches.
    If I were trying to combine independent changes,
    each one would get a separate commit anyway.
b) If I want to merge something and I get conflicts,
    I'm probably going to resolve them instead of
    reverting the changeset.

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

In svn, one commit is still one commit, no matter
how many changes you merge to create it.  The notion
of editing the history to clean it up is not relevant.

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

This doesn't answer the question I asked.

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

So, what I'm hearing is the fact that you
have more things to merge makes merging
easier.  But that can't be what you mean,
because it's obviously nonsense.  Come again?

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

Have you ever heard of branches?  Subversion
does support them, you know.

In Christ,
Steven Watanabe