[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: Greg Stein <gstein_at_gmail.com>
Date: Mon, 15 Sep 2008 16:22:00 -0400

The datastore (wc_db.h) already has a function you must call to open a
handle for datastore operations. That is the point where we locate the
metadata corresponding to the specified wc directory. It can easily
deal with apparent changes to wc's.

On Sep 15, 2008, at 15:06, Stefan Sperling <stsp_at_elego.de> wrote:

> 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... :-/
> 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.
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org

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 22:22:33 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.