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-31 16:20:05

AMDG

On 1/30/2011 4:35 PM, Dean Michael Berris wrote:
> On Mon, Jan 31, 2011 at 7:38 AM, Steven Watanabe<watanabesj_at_[hidden]>  wrote:
>> 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.
>

Yes, but I don't see how that's relevant.
How can the repository be in more than one state?
Now if only we had quantum repositories...

> What then happens when you have two people trying to merge from two
> different branches into one branch. Can you do this incrementally?

What do you mean by that?  I can merge any subset
of the changes, so I can split it up if I want to,
or I can merge everything at once.

> How
> would you track the single repository's state?

Each commit is guaranteed to be atomic.

> How do you avoid
> clobbering each other's incremental merges?

If the merges touch the same files, the
second person's commit will fail.  This is
a good thing because /someone/ has to resolve
the conflict.  Updating and retrying the commit
will work if the tool can handle the merge
automatically.  (I personally always re-run
the tests after updating, to make sure that
I've tested what will be the new state of
the branch even if there were no merge conflicts.).

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

This would require N svn commands.  (Of course
if I did it a lot I could script it.  It really
isn't a big deal.).

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

I didn't say that I didn't want automated tools.
I said that I didn't trust them.  With svn that
means that, before I commit I always
a) run all the relevant tests
b) review the full diff

This is regardless of whether I'm committing
new changes or merging from somewhere else.

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

It isn't a problem unless you're editing the same
piece of code in parallel.  If you find that you're
stomping on each other's changes a lot

a) The situation is best avoided to begin with.  The
    version control tool can only help you so much, no
    matter how cool it is.  No tool is ever going to
    be able to resolve true merge conflicts for you.
b) Working in branches will buy you about as much as
    using a DVCS as far as putting off resolving
    conflicts is concerned.

Honestly, if you assume the worst case, and
don't use the tool intelligently, you're bound
to get in trouble.  I'm sure that I could invent
cases where I get myself in trouble (mis-)using
git that work fine with svn.

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

Is it?  I personally don't want to spend a lot of
time dealing with version control--and I don't.
The vast majority of my time is spent writing code
or reviewing patches or running tests.  All of
which are largely unaffected by the version control
tool.

> only with git it's just a lot easier.

It isn't just easier with git, it's basically impossible
with svn.  In svn, the history is strictly append only.
(Of course, some including me see this as a good thing...)

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

4.) Dave isn't paying attention, so nothing happens.  A couple
     years later, after we've both moved on to other things, he
     notices my changes and decides that they're good and merges
     them.  ...More time passes...  He sees your changes and
     they look reasonable, so he tries to merge them.  He gets
     a merge conflict and then notifies you asking you to update
     your feature.  You are no longer following Boost development,
     so the changes get dropped on the floor.  ...A few more years
     go by...  Another developer finds that he needs your stuff.
     He resolves the conflicts with the current version and the
     changes eventually go into the official version.

This is something like how things seem to work in practice now,
and I don't see how using a different tool is going to change it.

> With subversion, there's no way for something like this to happen with
> little friction.

Why not?  Replace "github fork" with "branch" and
subversion supports everything that you've described.

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

What do you mean by "rebasing."  Subversion has no
such concept.  If you want to stay synchronized
constantly, you can.  If you want to ignore everyone
else's changes, you can.  If you want to synchronize
periodically, you can.  If you want to take specific
changes, you can.  What's the problem?

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

Apparently not, since your answer flips around
what I said.

> Because merging is easy with git and
> is largely an automated process anyway,

If you will recall, the question I started out with
is: "What about a distributed version control system
makes merging easier?"  That question remains unanswered.
The best I've gotten is "git's automated merge is smart,"
but it seems to me that this is orthogonal to the fact
that git is a DVCS.

> 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've never run into this issue.
a) Boost code in general isn't changing that fast.
b) My commits are generally "medium-sized."  i.e.
    Each commit is a single unit that I consider
    ready to publish to the world.  For smaller units,
    I've found that my memory and my editor's undo
    are good enough.  Now, please don't tell me that
    I'm thinking like a centralized VCS user.  I know
    I am, and I don't see a problem with it, when I'm
    using a centralized VCS.
c) There's nothing stopping you from using a branch to
    avoid this problem.  If you're unwilling to use
    the means that the tool provides to solve your
    issue, then the problem is not with the tool.

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

I've never wanted to do this, but unless there
are conflicts, it should work just fine.  If
there are conflicts, you're going to have to
resolve them one way or another regardless of
the version control tool.

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

It might overload the server.   That's a legitimate
concern.  But other than that, I don't see why not.
(However, since I have nothing to do with Linux
development, I may be totally wrong.)

In Christ,
Steven Watanabe