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

Re: .svn directories

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2003-08-26 09:41:07 CEST

--On Tuesday, August 26, 2003 12:05 AM -0700 Kumaran Santhanam
<kumaran@tigris.org> wrote:

> I would love to have a branch to submit these changes into.
> Branches are, after all, good for experimental features and such.
> How would I go about getting this set up?

I, for one, would want to see a fleshed out design (stating new subcommands
and their syntax and complete WC behavior) and proof-of-concept implementation
(mostly working, but perhaps not edge-case complete) before a branch is
created on svn.collab.net for this.

Your ~/.subversion/adm/index proposal worries me in that corruption in that
one file leads to loss of all WCs on that machine. I would like to know if
that file is either corrupted or accidentally deleted (both are realistic
expectations to occur at some point), how the system is expected to recover.
I dislike the single point of failure that would cause it to globally trash
the user's WCs across the system if the mapping isn't recoverable.

A hunch is a one-way hash of the directory path. But, then, what about
symlinks (multiple access points to the same working copy)? Are we going to
disallow the user from using those? How do we discover they are identical?
But, what if the sysadmin rearranges the disk layout and redoes symlinks
(moves home directories to another partition)? How do you plan to balance
these needs?

If you do store this metadata in a user's homedir, what about the 'shared
working copy' model? How can a user import the definition of a working copy?
This is usually a valid model for websites who have content under revision
control (like the ASF). Ideally, they wouldn't want a meta-directory on the
public site, but you also can't guarantee that the same user will do every
operation. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 26 09:41:59 2003

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.