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

AMDG On 1/30/2011 9:05 AM, Dean Michael Berris wrote:

On Sun, Jan 30, 2011 at 11:49 PM, Steven Watanabe 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