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

Re: Base text files, re: IRC chat

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 15 Sep 2008 22:21:46 +0300 (Jerusalem Daylight Time)

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
> copy.
> 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.

> Stefan

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

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.