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

On Sun, Jan 30, 2011 at 11:49 PM, Steven Watanabe wrote:

AMDG

On 1/29/2011 11:36 PM, Dean Michael Berris wrote:

...

On Sun, Jan 30, 2011 at 6:22 AM, Steven Watanabe  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