SVN, .SVN, and other meta-data directorys

[Thom Wood <th...@collab.net>]

sorry if this sound ignorant, but why do we need to store the
meta-data in the source tree at all, for example perforce (see preforce.com)
names the meta-data (in a env-var) and stores it in the server, one could
to something similar and store the meta-data in a known place on the local file system.

--thom wood
--p.s. i just started a collab.net this week so i am new to subversion.

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

[Zack Weinberg <za...@wolery.cumb.org>]

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

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

[Zack Weinberg <za...@wolery.cumb.org>]

On Sun, Aug 13, 2000 at 12:42:00PM -0400, Greg Hudson wrote:
> > However, I do wonder if a single directory in a well-defined
> > location relative to the working area might not be a reasonable
> > alternative. I'm not compelled by the ".. you can just copy this
> > subdir" line of reasoning, because non-trivial projects have
> > cross-subdir dependencies anyway. If you want a consistent build,
> > you either dup the whole tree or nothing.
> 
> "There might be cross-subdir dependencies in the versioned data" is a
> lame reason to rule out having independent subdirs.  There are lots of
> cases where subdirs are independent, at least for particular uses.

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.

Bitkeeper went down a series of rabbit holes trying to do change sets
and detachable subdirs at the same time.  It simply doesn't work.  If
you need detachable subdirs, you should create separate 'projects' for
each directory, and accept that there won't be a link between all the
components of a change that touches multiple directories.

zw

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

["Jonathan S. Shapiro" <sh...@eros-os.org>]

> Storing in a canonical place on the local filesystem makes the client
> dependent on the permissions of some random location on the filesystem
> [in addition to the checkout directory], and also violates the
> principle that the meta-data should disappear when the real data does.

Storing *anywhere* in the file system has this property.

I agree that storing in a fixed location in the file system is bad.
$HOME/.svn-info, for example, would be a lousy choice. Also /tmp/blurbus
would be bad.

However, I do wonder if a single directory in a well-defined location
relative to the working area might not be a reasonable alternative. I'm not
compelled by the ".. you can just copy this subdir" line of reasoning,
because non-trivial projects have cross-subdir dependencies anyway. If you
want a consistent build, you either dup the whole tree or nothing.


shap

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

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

Thom Wood <th...@collab.net> writes:
> sorry if this sound ignorant, but why do we need to store the
> meta-data in the source tree at all, for example perforce (see preforce.com)
> names the meta-data (in a env-var) and stores it in the server, one could
> to something similar and store the meta-data in a known place on the
> local file system.

Storing on the server doesn't scale to zillions on anonymous
checkouts.

Storing in a canonical place on the local filesystem makes the client
dependent on the permissions of some random location on the filesystem
[in addition to the checkout directory], and also violates the
principle that the meta-data should disappear when the real data does.
If people don't clean up carefully, you'd end up with lots of stale
metadata sitting around, right next to still-valid metadata.  Makes
for confusing debugging.

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

[Peter Schneider-Kamp <no...@nowonder.de>]

Thom Wood wrote:
> 
> sorry if this sound ignorant, but why do we need to store the
> meta-data in the source tree at all, for example perforce (see preforce.com)
> names the meta-data (in a env-var) and stores it in the server, one could
> to something similar and store the meta-data in a known place on the local file system.

I guess the reason is the same as why it is convenient in
CVS to have meta-data in the working directory:
You can copy the working directory (or any part of it)
somewhere and continue working with that.

Peter
-- 
Peter Schneider-Kamp          ++47-7388-7331
Herman Krags veg 51-11        mailto:peter@schneider-kamp.de
N-7050 Trondheim              http://schneider-kamp.de