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. [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,
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.[1] 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".[2] Now, assume
that exactly one of them is equal to the UUID of "our wc's repos". See
the problem?
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.
Clearer?
Daniel
[1] The first two had the same URL at different points in time. The
third one *never* changed either its UUID or its URL.
[2] You get the first by asking libsvn_wc's cache, and the second by
asking libsvn_ra.
> Cheers,
> -g
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1075472
Received on 2009-01-30 18:42:57 CET