[Ben and Fitz, your hard-earned wisdom from implementing 'lock' is
needed in the discussion below.]
On Mon, 08 Jan 2007, Malcolm Rowe wrote:
> 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').
As far as Merge Tracking is concerned, 1.4.x and lower clients should
be able to interact with a 1.5.x repository, including reading/writing
directly to the FS by way of ra_local.
While interaction of 1.4.x and lower clients with a 1.5.x repository
has the downside of potentially losing -- by way of not recording --
merge info for any 'merge' operations performed, to me this seems like
the lesser of two evils. Subsequent merges involving the unrecorded
merge info put us no worse off than today, and in the same position
you'd be in if you had an old repository -- obviously with no merge
info -- which was upgraded to 1.5, where you simply don't have a
record of meta data for merges which occurred pre-upgrade (since the
merges can't be differentiated from regular commits).
> 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.]
...
> > > 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)
Yes.
> And if so, at what point? When we use the feature (run 'svn merge'?),
> or whenever we write to the repository?
As implemented today, any attempt to retrieve or write new merge info
will create the index (an empty sqlite database with a merge info
schema).
This translates to (at least) any 'move'/'copy' or any 'merge' (1.5.x
client -> 1.5.x repos), and any commit including the 'svn:mergeinfo'
property (any client over network RA -> 1.5.x repos, or 1.5.x client
over ra_local).
> Some comparison with the approach taken for the lock work in 1.2 might
> be worth making.
I've CC'd Ben and Fitz to get their take on the parallels, and what
worked/didn't work during the implementation of locking.
> > > 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,
...
Yup. In the past, hasn't this often meant a dump/load was necessary?
> > 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.
Okay.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 8 19:54:48 2007