Re: Subversion documentation for the FreeBSD project?

On Tue, Jun 3, 2008 at 11:15 AM, Ulrich Spoerlein <uspoerlein_at_gmail.com> wrote:
> On Tue, 03.06.2008 at 13:28:01 -0400, Garance A Drosehn wrote:
>> At 6:45 PM +0200 6/3/08, Ulrich Spoerlein wrote:
>> > Hi all,
>> >
>> > seems like I totally missed the effort to port the FreeBSD CVS to SVN.
>> > Is there some documentation around, that describes the New Way for us
>> > mere mortals? Specific questions that come to my mind:
>> >
>> > - How will repository propagation be done in the future? rsync?
>> > - Is there one big svn tree or src/ ports/ doc/ seperately?
>> > - Did you fixup the CVS repo-copies into real SVN renames?
>> > - Will svn(1) ever be part of the base system?
>> > - Some statistics about repo-size would be nice :)
>>
>> It is still a work in progress, and people who do not need commit
>> access should (for now) not do anything special.  All the CVS-based
>> services should still be working, and it is probably best to continue
>> to use those for now.  It is still possible that we'll hit some
>> unexpected cases in subversion, and find that we have to switch right
>> back to CVS.
>
> Ok then, no burned bridges yet :)

Correct.....  and I thought for a while yesterday that we were going
to have to use it.

>> Please realize that a LOT of work was involved in making this switch
>> (none of which was done by me... ahem).  So we don't mean to dismiss
>> your request or your interest, but we're just not ready with all the
>> answers that you would like to see.
>
> No problem, I'm not in a hurry and applaud the effort in general. I'm
> only curious why the "switch" (test?) was/is done in "secret" and no
> HEADSUP has been sent so far (or did I miss it?)

It wasn't intentionally hidden.  It is more a case that it hasn't been
publicized yet.  We weren't even sure if the first attempt was going
to succeed.  Heck, I'm still not 100% sure we've made it to the commit
point.

Some background for perspective:

First email thread on cvs replacement:  July 31st, 1999. (latest and
greatest thing: BitKeeper)
Between then and Jan 4th, 2008: 124 email threads that I've been a
party to.  (Does not include any on -core this last two years. I'm
sure there have been a few.)
2416 messages in those 124 threads.
Longest thread: 128 messages ("Subject: Lipstick on a pig?")

We've argued about everything from tree layout, to models, to choice
of system, to workflow, to splitting into components, to using 3rd
party systems, you name it.  Several systems have come and gone in
that time.  There has been the BitKeeper fiasco.  For every person who
wanted to change the way something was done, there was another who was
strongly opposed.  The only thing that everybody agreed on was that
there was very little agreement.

The short ultimately list boiled down to svn, git, hg (mercurial) and
staying put with cvs.

Staying with cvs really wasn't an option.  As one of the people in
charge of keeping our cvs zombie on life support, I was painfully
aware of how much metadata we were losing.

svn was the lowest common denominator of the alternatives.  We could
ease into using it as an evolutionary thing rather than a revolution.
Some complain that it is the uninspired choice.  It does have the
advantage of having interfaces with both git and hg.  It could do
everything that we need.

There's Mercurial (hg).  It is a distributed system from the ground up
and its user interface is an easy transition for many cvs users.

And then there's git.  Definitely flavour of the month and seems to be
stealing mercurial's limelight lately.  It too, is an aggressively
distributed system.  And there lies the problem.  Git is very well
suited to the Linux community's way of doing things.  For better or
worse, we've never done things the same way as the Linux folk.  We can
argue all day about whether an integrated system is better than the
Linux-style free-for-all.  But, it's what we have, and we're not
Linux.  Many of our users run FreeBSD *because* it is integrated.

There's a number of fundamental architectural design choices in git
(and hg) that really don't suit FreeBSD's model comfortably.  To make
really *effective* use of Git, we'd need to make radical changes to
our entire way of doing things.    (Sure, we could get by. But to get
all the benefits, we'd have to make big changes).

And that's the rub.  Switching VCS's is bad enough, but if you want to
mix in changing models at the same time.. it is never going to get off
the ground.  Meanwhile, we keep suffering from the limitations of cvs.

So, I foolishly volunteered to do an evolutionary step and make the
``uninspired'' choice.  I know svn can work for us.  We don't have to
deal with the whole workflow model at the same time.

At this point, I'm sure somebody will add a Cc: to Linus so that he
can "educate" me.  Don't bother.  I've watched his talks, read his
email and posting.  I've read hundreds of other blog posts on the
subject of why Git is the best thing since sliced bread.  I understand
Linus's view.  I understand the model he's advocating.  Heck, I *like*
the model he's advocating.  I use git at home for a few things, so I
am familiar with it.  I just don't think it is the right choice for
FreeBSD.org yet.

I fully expect this to change over time.  At some point, git (or the
next latest and greatest thing) will be compelling and will either
support our models or we'll have changed ours.  We'll be in a heck of
a lot better shape for switching with svn as a starting point than
with cvs.

Meanwhile, there is git-svn, hgsvn, svk and friends.  (I expect that
many freebsd.org committers will use git-svn or svk for doing
development and commits.)

If you want to use git to manage your freebsd work, please, go right
ahead.  It should be easy now that git-svn has something to pull from
(and push to).  Go and build a git-based ecosystem and prove me wrong.
 Demonstrate a compelling case that we should be using a git-based
model.  Show that git can deal with sharing changes from multiple
origins on a tree our size or that it is worth fragmenting our tree as
a concession to git's tree-as-a-unit model.

It has just been made significantly easier to prove your point.  Now
go do it.  Well, in a few days when we have public infrastructure,
that is. :)   FWIW, we'll probably even offer a publically reachable
git server that folks can clone from to make it easier still.

Meanwhile.. we are exporting identical commits to cvs.  Everybody who
is using cvs or cvsup or csup or cvsweb will be able to keep on doing
what they've been doing.   The odds are good that the rest of the 7.x
releases will be cut from cvs rather than svn.   As we make the svn
(and other) infrastructure more public we'll give people more choices
about how they want to get freebsd.

-- 
Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell