Re: Subversion presentation at Silicon Valley Linux Users Group

>> The #1 message I'd say we got out of it is that quite a few people
>> want distributed repository functionality. Not 1.0, obviously, but
>> it's something people are hungry for.

> Do you think this need might be a result of cvs being too slow for
> people to use in a truly distributed fashion because of all of the
> network stuff it has to deal with?

I suspect not. I think the need is mostly due to derivatives of a
project being worked on in different administrative domains.

The three big use cases I know of are:

        * Project A relies on tools from Project B. (Subversion and
          APR would be a prime example.)

        * An organization wants to make a privative derivative of a
          project to accomodate local needs.

        * A developer wants to be able to work on big changes (big
          enough to require a branch with periodic checkins), and
          wants to be able to work offline.

"cvs import" handles these cases to varying degrees of success, but it
has some serious weakness, the chief ones being:

        * It doesn't take into account the revision history of the
          external sources, only the contents at the times imports are
          done.

        * As implemented in CVS, you can't import a new version
          without breaking your mainline (unless you go to each file
          after every import and either force-commit on the mainline
          or reset the default branch, and suffer a 2x space penalty
          on the deltas for each future import).

I'm concerned that Subversion is not suited to distributed
repositories because of our policy that one version number applies to
the whole project. We might instead be better off addressing the
chief weaknesses in "cvs import". I'm not sure.
Received on Sat Oct 21 14:36:28 2006