On Fri, Jan 05, 2007 at 05:05:27PM -0800, Daniel Rall wrote:
> > Is it fair to say that we're making a policy decision to version the
> > mergeinfo database separately from the filesystem or repository version
> > numbers?
> > [or tightly couple the mergeinfo schema to the existing format
> > numbers]
> I'm in favor of this, but thought that it means we need a way to
> smuggle the FS backend-specific format number into the libsvn_fs_util.
> While I didn't see a way to do this already, my FS-fu is not strong --
> perhaps there is one?
>
> However, I forgot that there's also a repository format number. Could
> we use it instead?
>
The simple answer to this depends upon what happens to downlevel clients.
Can a 1.4.x client legitimately write to a 1.5.x-with-mergeinfo
repository? (unfortunately we have no compatibility mechanism to say
'you can read, but you can't write').
If the answer is yes, then we don't need to update either number.
[Perhaps we can update the index on the next access by a 1.5.x client;
consider the 1.4.x dump/load scenario as one where we'd need to do that.
Alternatively we may not care about this scenario and merges done by
downlevel clients.]
If the answer is no, then we just need to bump the filesystem format
number (to 3, meaning 'allows svndiff1, may contain a mergeinfo index')
and set the repository format number to 5 (checking filesystem format
number required).
The latter choice means that pre-1.5.x clients won't be able to access
'with mergeinfo' repositories because the repository or filesystem format
number is too old. A dump/load or online update (see below) would
be required to make the repository fully-featured wrt merge tracking,
and we'd also require a switch to create 1.4.x-compatible repositories
(--pre-1.5-compatible?).
> ...
> > should we be able to upgrade a non-mergeinfo repository to a
> > mergeinfo-capable one?
>
> We need some format of this for Merge Tracking migration -> 1.5.
>
I should perhaps have asked "does running a 1.5.x client automatically
'upgrade' an existing repository?" (by creating a new index; perhaps
populating it from svnmerge data, if that's your plan)
And if so, at what point? When we use the feature (run 'svn merge'?),
or whenever we write to the repository?
Some comparison with the approach taken for the lock work in 1.2 might
be worth making.
> > Does doing so bump either of the existing format numbers? If not,
> > what happens if we use a pre-1.5 client on the repository?
>
> If we go as-implemented, I'd say no. But I'd prefer to tie the merge
> info schema format number to the repos or FS backend format number,
> for simplicity's sake. The main argument I see against this route --
> other than code possibly needing to be written -- is that a merge info
> index schema change's need to bump the repos format number might be
> seen by users as requiring a dump/load when that is not necessary.
>
I'm not sure I follow - you're worried that people may think they need
to dump/load because the repository format number is changing, or you
think that because the format number is changing, we'd need to tell
people to dump/load? If the latter, there's no reason that we can't do
an online upgrade and bump the number.
[Well, there is: IIRC we don't have a way to get an exclusive lock on
the repository if it's backed by FSFS filesystem. But I need to work
out how to do that in order to implement 'svnadmin setuuid', so it's
something we need to look at anyway.]
> Dan Berlin feels we should use the merge info sqlite database as only
> an index, storing svn:mergeinfo both in it and in the FS. While I was
> originally thinking that we should normalize the svn:mergeinfo data to
> only one location to avoid potential synchronicity problems, I've been
> feeling more ambivalent recently. (Of course, I'm sure that'll change
> the first time the data gets out of sync... ;-)
>
I agree with Dan. Since we've decided to implement the mergeinfo data
as regular properties (from the point-of-view of the caller), albeit
properties with an additional specialised API for querying, I would be
happier if we just use the additional indexes for answering the special
API functions (rather than hit the index in addition to the FS whenever
someone requests the proplist etc).
Any point the data could go out of sync is a point we need to consider
compatibility as well, if we're allowing old clients to continue to use
the repository.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Mon Jan 8 18:11:59 2007