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

On Mon, Jan 31, 2011 at 7:38 AM, Steven Watanabe wrote:

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.

Sure, if you choose to look at it that way and ignore all the other good things DVCSes bring to the table.

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.

With subversion, each commit is a different revision number right? Therefore that means there's only one state of the entire repository including private branches, etc. What then happens when you have two people trying to merge from two different branches into one branch. Can you do this incrementally? How would you track the single repository's state? How do you avoid clobbering each other's incremental merges? Remember you're assuming that you're the only one trying to do the merge on the same code in a single repository. Consider the case where you have more than just you merging from different branches into the same branch. In git, merging N remote-tracking branches into a single branch is possible with a single command on a local repo -- if you really wanted to do it that way. Of course you already stated that you don't want automated tools so if you *really* wanted to inspect the merge one commit at a time you can actually do it interactively as well.

b) If I want to merge something and I get conflicts,   I'm probably going to resolve them instead of   reverting the changeset.

Sure in which way there's largely no problem whether you're using git or subversion. But in git with a multi-developer project, since you're only basically touching your own repo most of the time and synchronizing a canonical repo is mostly a matter of policy (who does it, when, etc.). In the context of merging this means you can fix the merge locally and then push to the canonical repo if you have the rights to do it so that others can pull from that again and continue on with their work (at their own pace). With subversion what happens is everyone absolutely has to be on the same page all the time and that's a problem.

...

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

Why is it not relevant? In subversion, one commit can only happen if your working copy's version is up to date with the repo's version of the same checked out branch. In git, because you have a local repo, well your commits are basically just on your repo -- if something changes upstream and you want to get up to date, then you pull and merge the stuff locally. This means you can still commit changes without clobbering others' work (or clobbering others' work but locally) and then 1) if you're the maintainer push to the canonical publicly accessible repo or if you're not the maintainer 2) ask the maintainer to pull your changes in via a merge that the maintainer does for you. The maintainer can then do the adjustments on the history of the repo -- things like consolidating commits, etc. -- which largely is really what maintainers do, only with git it's just a lot easier. Of course I realize that's a matter of taste and paradigm though so I think YMMV depending on whether you can wrap your head around it or not.

...

...

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.

Of course you're looking at the whole thing with centralized VCS in mind. Consider the case that you have multiple remote branches you can pull from. If you're the maintainer and you want to basically consolidate the effort of multiple developers working on different parts of the same system, then you can do this piece-meal. For example, you, Dave Abrahams, and I are working on some extensions to MPL. Let's just say for the sake of example. I can have published changes up on my github fork of the MPL library, and Dave would be the maintainer, and you would have your published changes up on your github fork as well. Now let's say I'm not done yet with what I'm working on but the changes are available already from my fork. Let's say you tell Dave "hey Dave, I'm done, here's a pull request". Dave can then basically do a number of things: 1.) Just merge in what you've done because you're already finished and there's a pull request waiting. He does this on his local repo first to run tests locally -- once he's done with that he can push the changes to the canonical repo. 2.) Pull in my (not yet complete) changes first before he tries to merge your stuff in to see if there's something that I've touched that could potentially break what you've done. In this case Dave can notify you to pull the changes I've already made and see if you can work it out to get things fixed again. Or he can notify me and say "hey fix this!". 3.) Ask me to pull your stuff and ask me to finish up what I'm doing so that I can send a pull request that actually already incorporates your changes when I'm done. ... ad infinitum. With subversion, there's no way for something like this to happen with little friction. First we can't be working on the same code anyway because every time we try to commit we could be stomping on each other's changes and be spending our time just cursing subversion as we wait for the network traffic and spend most of our time just trying to merge changes when all we want to do is commit our changes so that we can record progress. Second we're going to have to use branches and have "rebasing" done manually anyway just so that we can all stay synchronized all the time -- which is sometimes largely unnecessary until it's time to actually integrate changes. I can list more but this reply is already taking longer than I expected so I'll stop it short there.

...

...

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?

Yes, that's exactly what I mean. Because merging is easy with git and is largely an automated process anyway, merging changes from multiple sources when integrating for example to do a "feature freeze" and "stabilization" by the release engineering group is actually made *fun* and easier than if you had to merge every time you had to commit in an actively changing codebase.

...

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.

And have you tried merging in changes from N different branches into your private branch in Subversion to get the latest from other developers working on the same code? Because I have done this with git and it's *trivial*. Also are you really suggesting that Linux development would work with thousands of developers using subversion to do branches? Do you expect anybody to get anything done in that situation? And no that's not a rhetorical question. HTH -- Dean Michael Berris about.me/deanberris