Stefan Sperling wrote on Mon, 15 Sep 2008 at 21:06 +0200:
> 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
> cut it.
> 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... :-/
We don't need access to the other working copy -- we can store both its
path and its wcuuid in the centralised store.
> 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.
Agreed, I conjecture we'll want manual control anyway (even if some sort
of magic wcuuid system is used). With all of us (except Greg :)) moving
and rsyncing wc's all the time, keeping track of it might not be easy.
I don't view this as an extension to 'svn mv/cp', though -- I consider
a separate command that just tells svn "Here is a wc, add it" or "Here
was a wc, forget it". That's so I can use tar or rsync or ... to move
or duplicate my wc's.
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:22:12 CEST