A concern about mergeinfo and compatability.

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?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand