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-29 06:02:01

On Sat, Jan 29, 2011 at 6:08 PM, John Maddock <boost.regex_at_[hidden]> wrote:
>> I think you're looking at it as a purely tool vs tool comparison which
>> doesn't amount to much. Consider then what the workflow a distributed
>> version control system enables and you might see the difference
>> clearer.
>>
>> Consider a library being worked on by N different people concurrently.
>> Each one can work on exactly the same code locally, making their
>> changes locally. Then say someone pushes their changes to the
>> "canonical" repository. Each person can then pull these changes
>> locally, stabilizing their own local repository, and fixing things
>> until it's stable. You can keep doing this every time without any one
>> of these N people waiting on anybody to "finish".
>
> That's exactly what we do now with SVN.
>

Something was missing in translation there: making changes, means
committing locally. That's not what we do now with SVN.

See, when you're using git, committing locally and making changes are
equivalent. It's something you don't think about as something
different -- as opposed to how you think about it in SVN where "making
changes" is not equivalent to "committing". Therefore were you see git
users say 'making changes' that really means 'committing changes
locally'.

>> Now then imagine
>> that there's only one person who has push capabilities/rights to that
>> "canonical" repository and that person's called a maintainer.
>>
>> All the N-1 people then ask this maintainer to pull changes in or
>> merge patches submitted by them. If the maintainer is willing and
>> capable, that's fine and dandy changes get merged. Now consider when
>> maintainer is unwilling or incapable, what happens to the changes
>> these N-1 people make? Simple, they publish their repository somewhere
>> accessible and all the N-2 people can congregate around that
>> repository instead. MIA maintainer out of the way, release managers
>> can choose to pull from someone else's published version of the
>> library. Easy as pie.
>
> OK, if forking is a good thing then I can see how that helps.
>

Is there any question that forking is a good thing? I thought that was
kinda assumed with open source development. ;-)

> Question: what's to stop you from right now, building a better and greater
> version of library X in the sandbox, and then asking the Boost community to
> consider that the new Trunk and you the new maintainer? Â Different tool,
> same process.
>

Because doing that requires permission to get sandbox access. And
because doing that is largely more steps than just clicking a 'fork'
button on a web UI on something like github. And also because doing
that means that you have to work with a single repository that has
potentially other people clobbering it. :)

> I still think there are pros and cons though:
>
> * As I see it Git encourages developers to keep their changes local for
> longer and then merge when stable. Â That's cool, and I can see some
> advantages especially for developers wanting to get involved, but I predict
> more work for maintainers of the canonical repro trying to figure out how to
> resolve all those conflicts.

What gives the impression that resolving conflicts is hard on git?
It's easily one of the easiest things to do with git along with
branching. And because branching is so light-weight in git (meaning
you don't have to pull the branch everytime you're switching between
branches on your local repo) these conflict resolution and
feature-development isolation is part of the daily work that comes
with software development on Git.

And having multiple maintainers maintaining a single "canonical" git
repo is the sweetest thing ever. Merging changes from many different
sources into a single "master" is actually *fun* as opposed to painful
with a centralized VCS.

> Obviously with SVN we still get conflicts -
> for example Paul and I often step on each others toes editing the Math lib
> docs - but these issues tend to crop up sooner rather than later which at
> least makes the issue manageable to some level.

See, imagine how that would scale if you added 2 more people working
on the same library with SVN. Just updating everytime you need to
commit anything is a pain with the potentially huge conflicts you get
precisely because you can't commit changes more granularly locally in
your repository. Note that there's no notion of a "working copy"
because your local repository is what you work on directly.

The "pull-merge-push" workflow is so simple with git that it's largely
not something you *ever* have to deal with in any special manner. It's
just part of everyday development with git.

A suggestion would be maybe someone ought to run a workshop or a
tutorial IRL on how the git workflow looks like. I think there are
tons of videos out there already along with countless books written on
the subject already.

> * I happen to like the fact that SVN stores things *not on my hard drive*,
> it means I just don't have to worry about what happens if my laptop goes
> belly up, gets lost, stolen, dropped, or heaven forbid "coffeed". Â On the
> other hand the "instant" commits and version history from a local copy would
> be nice...
>

See, git does the same thing if you're using github as a publicly
accessible repo. You can duplicate the same to gitorious. You can even
put it on sourceforge for good measure. Synchronizing each one is a
scriptable manner and is not rocket science. The fact that this is
even possible with git is something that gives it much more appeal for
disaster recovery.

With SVN, if you're working on something locally (not committed yet)
and your hard-drive goes belly up, I don't see why it's better than if
you were working on git and have local commits and your hard-drive
goes belly up. With SVN though the question is what happens when your
server gets wiped out, what value is the data on your hard-drive then?
How do you reconstitute the history of the project from what you do
have with you? With git the risk mitigation options are a lot more
accessible and largely trivial. With SVN, not so much.

HTH

-- 
Dean Michael Berris
about.me/deanberris