Greg Stein wrote:
> On Fri, Jan 30, 2009 at 14:17, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> Greg Stein wrote on Fri, 30 Jan 2009 at 13:39 +0100:
>>> Seems like the right answer is:
>>>
>>> * compare URLs
>>> * if that fails, get the zero, one, or two UUIDs from the WC
>>> * fetch any missing UUIDs from the server
>>> * shove the UUIDs back into the WC if a write-lock exists
>>> * compare the two UUIDs
>>>
>> So, you first use the cache maintained (globally) by libsvn_wc, and only
>> then ask the server. [1] But if the UUID of a given URL changed, how
>> would libsvn_wc's cached URL <-> UUID mapping get updated?
>>
>> Daniel
>>
>> [1] Presumably, when you ask the server, you also try to re-use existing
>> sessions, since those should have the UUID cached.
>
> IMO, if the server changes its UUID, then you need to check out a
> whole new working copy.
>
> For all intents and purposes, that means you're talking to a
> *different* repository. Nothing holds.
Yep. Or at least, that should be the default. I've recently found myself
wishing that 'svn switch --relocate' could take an --ignore-uuid-change flag
(moved a repository to Google Code hosting via svnsync, UUID changed,
nothing else). But checking out again didn't kill me. Obviously.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1074730
Received on 2009-01-30 15:41:31 CET