Greg Stein wrote on Fri, 30 Jan 2009 at 16:44 +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.  But if the UUID of a given URL changed, how
> >> > would libsvn_wc's cached URL <-> UUID mapping get updated?
> >> >
> >> > Daniel
> >> >
> >> >  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,
Yes, I'm talking about wc-ng, since in current wc you can only get from
the .svn/ tree the UUID of the wc's repos, and I don't see how to cause
a problem with *that*, because...
> 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)
... we already do this (compare the uuid in .svn/entries to the repos's
uuid). See svn_ra_open3().
However, this only addresses validating that the UUID of the repository
the wc belongs to matches our expectations. My scenario involved
changing the UUID of the *foreign* repository --- one for which we *had*
a wc long ago (because it has an entry in the REPOSITORY table), but for
which we no longer have a wc.
> 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?
We had three repositories: the first foreign repos, the second foreign
repos, and our wc's repos. During the merge, you need to obtain the
UUID of the foreign repos; so you obtain *either* the UUID of the "first
foreign repos" or the UUID of the "second foreign repos". Now, assume
that exactly one of them is equal to the UUID of "our wc's repos". See
And before you say that it's a pathological case that assumes two
repositories with the same UUID: I fully agree with you. But notice that
if you replace the question "Are these the same repository?" by the action
"Store the UUID of the foreign repos in a revprop", then can still get
a problem (the revprop set to the "wrong" value) without assuming two
repositories with the same UUID.
 The first two had the same URL at different points in time. The
third one *never* changed either its UUID or its URL.
 You get the first by asking libsvn_wc's cache, and the second by
Received on 2009-01-30 18:42:57 CET