[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: Greg Stein <gstein_at_gmail.com>
Date: Fri, 30 Jan 2009 16:44:19 +0100

On Fri, Jan 30, 2009 at 16:14, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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).

Ah. Well, if you're talking about WC-NG, then we can easily validate
the UUID each time we connect. The repository is going to send us the
UUID in the very first response. We can always double-check right
then.

(sounds like a nice TODO)

In any case, I'm not quite sure what scenario you're talking about
here. The original point was "are these the same repository?" And for
the case where we merge/copy nodes into a working copy, we record the
copyfrom info, but that doesn't survive commit-time. So... I'm not
quite seeing the problem here. Help?

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1075059
Received on 2009-01-30 16:45:43 CET

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.