David Glasser wrote:
> On Jan 29, 2008 9:30 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> David Glasser wrote:
>>> On Jan 29, 2008 8:22 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>>> I'd like to avoid dump/load, but we can't retroactively prevent users of 1.4
>>>> clients from setting the svn:mergeinfo property on their 1.4-pedigreed
>>>> repositories. And I'm not confident that our 1.5 codebase would prevent the
>>>> same, either. So then they upgrade the repository and find themselves with
>>>> schema inconsistencies (svn:mergeinfo property set, but node-rev's
>>>> has_mergeinfo is not, and its mergeinfo_count is all wrong, etc.)
>>> Well, one detail here: I'm pretty sure that the various
>>> self-consistency checks on the has_mergeinfo/mergeinfo_count fields
>>> (at least in FSFS) will *not* get triggered in this case.
>>> Specifically, if you have an existing svn:mergeinfo property, it won't
>>> be *found* by svn_fs_get_mergeinfo, but neither should it lead to any
>>> errors being thrown; and as soon as you modify the mergeinfo property
>>> once, the fields will be set and svn_fs_get_mergeinfo will be able to
>>> find it.
>>>
>>> This isn't a great story, but it's not completely horrid either.
>> Right, the self-consistency won't fire. (Now, whether or not that's a
>> *good* thing could be a whole 'nuther matter.) But does it not strike you
>> as wrong that you could have a whole tree chock full of mergeinfo, then
>> change a single file with a 1.4 client, and suddenly that node *and all its
>> parents* are written such that they -- and all their descendents -- appear
>> to have no info when queried via svn_fs_get_mergeinfo()? Repairing that
>> situation is a task that *no one* will happily endure.
>
> Er, client? The server version is what's relevant there.
>
> Sorry, I was just trying to address the point of "if we require a
> version bump to write mergeinfo metadata, what happens if the
> repository that you run a constant-time 'svnadmin upgrade' command on
> already has some svn:mergeinfo properties?" I don't think what you
> describe here is relevant to that case. It would certainly be
> relevant if we don't require a version bump for merge tracking
> support, but that's why we should...
Doh! Yeah, we were talking around each other. If we do the version bump
thing, then I think we're fine. Pre-existing svn:mergeinfo will be
sometimes ignored, sometimes not (which might cause confusion), but there
shouldn't be pre-existing svn:mergeinfo anyway. Shame on the user.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-29 18:49:51 CET