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...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-29 18:36:44 CET