Re: Self-introduction

[Karl Fogel <kf...@galois.collab.net>]

"Eric S. Raymond" <es...@snark.thyrsus.com> writes:
> Eric S. Raymond here.  Some of you know me of old.

Welcome to Subversion!

> I've signed up because I want to help head BitKeeper off at the pass.
> McVoy's design looks good but his license is insidious.  Having
> surveyed the alternatives, (a) the CVS codebase is too brittle, (b)
> PRCS doesn't handle distributed development well enough, and (c) Aegis
> may be a fundamentally better design than any CVS workalike, but
> prospects of migrating the world to it from CVS seem dim.  That's my
> present evaluation, anyway.

Agree about the Bitkeeper thing.  Excellent technology, unacceptable
license.  Sigh. :-(

> Anyway.  Since I signed up, I've seen a lot of relatively low-level
> conversation about implementation.  What's happening architecturally?
> How many months do you think you are from being able to field a
> drop-in CVS replacement?  Are there migration tools?  The design
> document is out of date, which is a bad sign -- is anyone responsible
> for fixing that.

Why is the design document being out of date a bad sign?  It just
means we're all busy coding :-).  (It's actually not all that out of
date, but yeah, one does have to read the header files right now to
know what's really going on).  No one has volunteered their time to
keep the design document 100% up-to-date as we code, and the paid
full-timers, myself included, have decided to update it only
infrequently until the code stabilizes.

Fortunately, developers seem to be able to figure out what's going on
anyway.

We're aiming to have basic commits and updates happening over the
network by April 1.  Having announced and then bled over milestone
dates in the past, I'm a bit shy now about saying them on the list,
especially when everyone's coding as fast as they can anyway. :-) But
April 1st is pretty much our big day, and at this rate of progress I
think we'll make it.

Note that "basic commits and updates" does not mean a drop-in CVS
replacement.  A lot of polishing and testing will have to happen
before that, including completion of the CVS->SVN repository
conversion program.  End of May or mid-June would be more like it.
You can help make it happen faster. :-)  (You knew I was going to say
that, didn't you?)

> (One way I *can* help directly is with document editing.  I'm pretty
> good with English, and it's the kind of task that can be done in small
> pieces between coding runs.)

Wow, that would be great.  Any time you could spare for the docs would
be most welcome.  Of course, the more familiar you are with the state
of the code the better, but whatever you can spare would help.  It's
not that we don't think the docs are important, it's just a matter of
where it's most useful for people to allocate their time right now.

Best,
-Karl

Re: Self-introduction

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

"Eric S. Raymond" <es...@thyrsus.com> writes:

> > Wow, that would be great.  Any time you could spare for the docs would
> > be most welcome.  Of course, the more familiar you are with the state
> > of the code the better, but whatever you can spare would help.  It's
> > not that we don't think the docs are important, it's just a matter of
> > where it's most useful for people to allocate their time right now.
> 
> How do I get access?  Are you CVSes, or should I just download a tarball
> and ship back patches?

The texinfo "design" doc lives right in our CVS tree.  Just go ahead
and do an anonymous checkout of the project:

    http://subversion.tigris.org/cvs_help.html

If you want to contribute, post patches to this list.  (Read the file
HACKING at the top of the source tree before anything else.)

Other important design docs in our tree:

       * subversion/libsvn_fs/structure      <-- filesystem design
       * subversion/tests/TEST-FRAMEWORK     <-- automated tests
       * STACK, TASKS, IDEAS                 <-- notes from discussions
       * tools/cvs2svn              <-- start of a repository converter

Re: Self-introduction

[Sam TH <sa...@uchicago.edu>]

On Mon, Feb 26, 2001 at 02:56:17PM -0500, Eric S. Raymond wrote:
> 
> How do I get access?  Are you CVSes, or should I just download a tarball
> and ship back patches?

http://subversion.tigris.org/cvs_help.html

The docs are in doc/, the web stuff in wwww/.
          
	sam th		     
	sam@uchicago.edu
	http://www.abisource.com/~sam/
	GnuPG Key:  
	http://www.abisource.com/~sam/key

Re: Self-introduction

[Brian Behlendorf <br...@collab.net>]

On Mon, 26 Feb 2001, Eric S. Raymond wrote:
> What's he got that you don't?  Offhand, it looks to me like you have
> changesets and LODs covered fairly well but you're weaker than Bitkeeper
> on the distributed-depositories front.  Is that a fair summation, in your
> view?

We don't handle changesets using a formal changeset engine as BK (and some
other products I've seen) do, and it won't happen in the 1.x time frame,
so that's one big difference.

We are also "weaker" on the distributed-repositories front, but the
network performance optimizations should be enough to address most
people's concerns about latency, plus the fact that we use DAV over HTTP
should allow for caching of updates on HTTP proxies, hopefully without
even requiring changes to the proxies themselves.

There's another aspect to the distributed-repositories front, though,
which is allowing for "private" branches on another repository, and that
is a harder problem.  Another thing not likely to be addressed in the 1.x
timeframe.  But, I suspect that the need for it goes partially away if we
can implement some really flexible access control stuff, allowing for
user perms to be set on branches, so we emulate that distribution.  I
don't know, though.

> How do I get access?  Are you CVSes, or should I just download a tarball
> and ship back patches?

set your CVSROOT to :pserver:guest@cvs.tigris.org:/cvs password "guest".
Commit privs are granted based on quality of patches submitted.  =)

	Brian

Re: Self-introduction

["Eric S. Raymond" <es...@thyrsus.com>]

Karl Fogel <kf...@galois.ch.collab.net>:
> Agree about the Bitkeeper thing.  Excellent technology, unacceptable
> license.  Sigh. :-(

What's he got that you don't?  Offhand, it looks to me like you have 
changesets and LODs covered fairly well but you're weaker than Bitkeeper
on the distributed-depositories front.  Is that a fair summation, in your
view?

> Why is the design document being out of date a bad sign?  It just
> means we're all busy coding :-).

It may also mean you're too busy coding to maintain a a coherent and
documented model of the architecture.  Not that I'm saying this has
happened -- I don't know enough to judge that yet -- but the possibility
causes me concern.

> Note that "basic commits and updates" does not mean a drop-in CVS
> replacement.  A lot of polishing and testing will have to happen
> before that, including completion of the CVS->SVN repository
> conversion program.  End of May or mid-June would be more like it.
> You can help make it happen faster. :-)  (You knew I was going to say
> that, didn't you?)

The migration tools will be important.  I just got through telling Peter
Miller (the Aegis guy) this:

|> [W]hat influenced that decision?  What would it have taken for you to
|> say ``hell, let's install this sucker and try it on a live project
|> for a few months''?  Opportunity cost?  Something else?
|
|Ah.  *That* question I can answer.  For me, it would take
|import-export tools that I believed in.  That is, I'd try Aegis if I
|believed that there were a pair of tools that could import a RCS/CVS
|project into Aegis, and export an Aegis project to RCS/CVS, in such a
|way that RCS/CVS metadata tunnels through without loss.  Not only
|that, the documentation would have to convince me this true by
|detailing the mapping exactly.
|
|Note: such a pair of tools need not necessarily handle all of CVS's
|weird edge cases -- but it would have to document everything the
|transformation breaks with accuracy and honesty.
|
|The biggest opportunity cost in switching to a system like Aegis is
|the fear that you won't be able to fall back to what you know if it
|turns out to be unsuitable or confining.  If you nailed that, I'll bet
|your adoption rate would rocket.

> > (One way I *can* help directly is with document editing.  I'm pretty
> > good with English, and it's the kind of task that can be done in small
> > pieces between coding runs.)
> 
> Wow, that would be great.  Any time you could spare for the docs would
> be most welcome.  Of course, the more familiar you are with the state
> of the code the better, but whatever you can spare would help.  It's
> not that we don't think the docs are important, it's just a matter of
> where it's most useful for people to allocate their time right now.

How do I get access?  Are you CVSes, or should I just download a tarball
and ship back patches?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances ..
	-- IRS Strategic Plan, (May 1984)