Re: A concern about mergeinfo and compatability.

On Jan 29, 2008 11:22 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Yesterday in IRC, we wrestled a bit with questions of filesystem schema
> versions and such. We ran into the same debate we've run into before
> regarding do we or don't we auto-upgrade filesystems to a new version.
> Those sympathetic to folks using file:// access against
> network-share-mounted repositories said auto-upgrades are evil; those
> sympathetic to companies running hundreds of repositories said dump/load
> requirements are evil. Somewhere in the middle we stumbled across the idea
> of *not* auto-upgrading, but providing 'svnadmin upgrade' as a tool which
> could either upgrade a filesystem to the latest (as of that version of
> 'svnadmin') release level, or complain that a dump/load was required if the
> underlying FS implementation indicated that a quicky version bump wasn't
> available. Some dev-list feedback on that idea would be fantastic.
>
> Walk with me, if you will, as I look specifically at the two back-end
> changes we made in 1.5 -- node-origins and mergeinfo -- and examine how
> those play out in a mixed-version-of-Subversion scenario like is common on
> university campuses. The general statement of the problem is this, "How
> should a Subversion 1.4 client behave when acting on a 1.5 repository that
> contains node-origins or mergeinfo records?"
>
> I ask this because in the BDB backend, the node-origins stuff can happily
> co-exist for both 1.4 and 1.5 clients. It lives in a table that we can
> create (in 1.5) if missing and use, and which will be completely ignored by
> 1.4 clients. And I think I can rework the mergeinfo stuff to have that same
> basic property.
>
> But doing this for mergeinfo gives me pause, because I don't think that
> having 1.5 clients writing mergeinfo to the repository and then having that
> info being ignored by 1.4 clients is actually good. As 1.4 clients clone,
> tweak, and write node-revision information in the course of doing the whole
> version control thang, I think this will have the effect of disturbing the
> integrity of the data. As such, it seems we pretty much need to
>
> a) bump the BDB backend version number in 1.5
> b) use that new version when creating repositories in 1.5 without the
> --pre-1.5-compatible flag to 'svnadmin create'
> c) *not* auto-upgrade previously existing repositories
> d) disallow mergeinfo/node-origins stuff -- even by 1.5 clients --
> when the filesystem format doesn't support it.
>
> Sadly, there's another necessary complication, I think. That is:
>
> e) teach our new RA feature negotiation stuff to be aware of the
> backend filesystem's supported features.
>
> And then, we have to deal with the upgrade path. Do we implement 'svnadmin
> upgrade', or do we require a dump and load?
>
> 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.)
>
> It would appear that dump/load is the only safe way to do this particular
> repository format change.
>
> Am I missing something? Is there a better route we can safely take here?

I am against requiring a dump/load. I think it is way more painful
for the user base as a whole then the advocates of this approach are
allowing. (Please do not explain all the ways it can be manageable,
most of our users are not skilled admins). That being said, I also
trust you all to do what is necessary. If the ultimate conclusion is
that this is going to require a dump/load, then I guess that is what
it has to be.

All I ask, is that you give the options a second, third and fourth
think-over before concluding this is how it has to be.

Please update the list once the a "final" choice is made.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org