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 19:35:36

On Mon, Jan 31, 2011 at 7:38 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> 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.

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