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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-29 18:30:52 CET