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

Re: svn commit: r35578 - trunk/subversion/libsvn_client

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 30 Jan 2009 09:35:34 -0500

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

Received on 2009-01-30 15:41:31 CET

This is an archived mail posted to the Subversion Dev mailing list.