> 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.
Fair enough - I will have a working patch ready in a few days.
As it stands right now, I have the index working, and
v_extend_with_adm_name() is able to locate the admin directories
in either .svn/ or ~/.subversion/. Checkout performs the
appropriate directory creation, and the config option is able to
turn off the feature.
I'm trying to resolve a hairy problem with the logger.
Apparently, it has some issues with absolute versus relative
paths and there are some interesting pieces of logic in
svn_wc__merge_prop_diffs() to take care of this. Once I have
those fixed, I believe I'll have a pretty good proof-of-concept
for phase 1.
> 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.
I'll need to think about this more - it was a tradeoff between
reading the ~/.subversion/meta directory (as it's now called,
unless anybody has any objections) or reading a single index file
in ~/.subversion/meta/index. Let me think about this more, since
I might be able to come up with a way to eliminate the index
altogether.
> 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?
With the index file, this would already work. The index simply
contains multiple entries for the same directory alias. This is
how it looks right now:
~/.subversion/meta/index:
# Subversion meta-data index
# Each line represents a mapping between working copy
# paths and the meta-data cache. The line is parsed
# as follows:
#
# dirname(line) = working copy path
# basename(line) = key
#
# These scheme is used so that there are no special
# reserved characters disallowed from path names.
/home/user/projects/subversion/3f4b01aa
/home/user/projects/rapidsvn/3f4b01bb
If a symlink were created:
/home/user/svn -> /home/user/projects/subversion
Then, an additional line would be appended to the index:
/home/user/svn/3f4b01aa
Note that the trailing key is the same as /home/user/project/subversion
As such, this would work seamlessly.
> 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
Shared working copy is sticky. Unless the meta data is shared
also, this is of course impossible. So, either the meta data has
to be shared somehow, or the current method of putting .svn/
directories everywhere might be renamed to "shared working copy"
feature.
Pure speculation here, but it might make sense to have the
external meta data feature be default, but allow users to
explicitly use the embedded .svn/ directory model if they want to
share repositories. That way, they are also aware of what they
are doing.
My current prototype already seamlessly detects the .svn/
directories and behaves correctly. In other words, you can turn
on the external meta data option and still use SVN with both
types of working copies.
As for importing a working copy, can you please expound on this a
little more. I don't quite understand what you have in mind.
Cheers,
Kumaran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 26 17:56:25 2003