[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN, .SVN, and other meta-data directorys

From: Zack Weinberg <zack_at_wolery.cumb.org>
Date: 2000-08-13 23:42:15 CEST

On Sun, Aug 13, 2000 at 04:36:30PM -0400, Greg Hudson wrote:
> > Note that SVN has globally serialized revision numbers (change
> > sets). Which means that there has to be a chunk of metadata that
> > does the serializing, and it has to be per tree.
>
> In the repository, yes. I don't see why there has to be any such
> thing in the working directory.

Hmm... good point. But think about update operations. If you save
the last serial number client-side, a CVS-semantic update is trivial:

(1) save diffs between revision N and working copy
(2) back out all the changes
(3) request diffs between rev N and rev N+M from the server
(4) apply those diffs
(5) reapply the diff saved in (1), resolving conflicts

Only operation (3) touches the network, and it transmits very little
information upstream.

(There are better update semantics than CVS, but we can worry about
that when we have local repositories.)

> There is no issue of central versus distributed metadata in the
> repository because we're planning to shove the whole repository into
> a database anyway.

I don't see what shoving it in a database has to do with what data is
stored client-side.

> > Bitkeeper went down a series of rabbit holes trying to do change
> > sets and detachable subdirs at the same time.
>
> I don't recall that Bitkeeper separated the concept of working
> directories and repositories.

It didn't. A checkout in CVS terms got you a private copy of the
repository. (Then you did RCSish per-file checkouts when you wanted
to edit something, which was lame.) I always thought this was one of
Bitkeeper's best ideas, and I hope we don't rule out doing it in SVN
in the future.

zw
Received on Sat Oct 21 14:36:06 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.