I'm back to emailing via iPhone while driving... livin' dangerously :-
P ... but abbreviated responses for now.
Each wc will already have a uuid as a natural outgrowth of a SQL table
that records all wc's. It is just the auto-generated primary key.
I had already planned to drop that into .svn/wc-id at the wcroot to
identify the wc.
Rather than add new subcommands, I think a flag like --wc-local to mv/
cp/rm.
Cheers,
-g
On Sep 15, 2008, at 15:21, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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
>
---------------------------------------------------------------------
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:43:08 CEST