On Mon, Sep 15, 2008 at 09:03:44PM +0300, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, 15 Sep 2008 at 19:43 +0200:
> > I fail to see what's wrong with a mandatory .svn at the root of
> > a working copy
> +1 on this part of the sentence...
> > pointing to a meta data store to handle the
> > moved-working-copy use case.
> Moving the wc won't update the reference in the centralised metadata
> storage to the wc?
Huh. I must admit that I actually don't have a waterproof idea
how to automatically update the central store in this case :(
Trail of thought:
If we wanted to automatically tie moved and copied working
copies back to a central meta data store, we could have some
API function all callers have to go through to get at the
working copy (such a function might even already exist).
We would need UUIDs for working copies to make this work.
Keying working copies by their absolute path alone wouldn't
When a working copy which points to a meta data store that
expects the working copy to be at a different path than it
currently occupies, and there is no working copy anymore at
the old path, then the meta data store can remember the new
location of the working copy automatically.
In case of a UUID clash, i.e. when a working copy with a
matching UUID is still present at the old location, we could
generate a new UUID for the new (and presumably copied) working
The only problem I'm seeing here is that needing access to
another working copy to determine whether the current working
copy is a copy is quite fragile. The other working copy
may be on a drive that's unmounted or horribly slow... :-/
Hmmm... so maybe requiring user interaction to sync working
copies with the central meta data store is indeed the way to go?
I don't like this, but I acknowledge that automatically managing
moved/copied working copies may be non-trivial to implement.
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-15 21:07:09 CEST