Greg Stein wrote on Fri, 30 Jan 2009 at 14:43 +0100:
> 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.
>
Agreed, of course. But that's not what I asked...
Assume that the foreign repos has an entry in the REPOSITORY table.
Then, if you ask libsvn_wc for the foreign repos's UUID, it would
happily grab the UUID from that entry and return it to you.
Now, how do you know that the UUID in that entry is current? Maybe you
don't even have a wc of the foreign repos any longer (you rm -rf'd it
months ago, but the table entry remained because you didn't tell svn
that you killed that repos's last wc).
> Cheers,
> -g
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1074916
Received on 2009-01-30 18:42:06 CET