On Sat, Mar 15, 2014 at 3:03 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
> > -----Original Message-----
> > From: Bert Huijben [mailto:bert_at_qqmail.nl]
> > > -----Original Message-----
> > > From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> > >
> > > SVN_INVALID_REVNUM is less than the baseline revision but the check
> > > makes no sense.
> > I haven't gotten to the full details yet, but...
> > The check would make sense for a 'checkout' that is required before any
> > change in a subtree, which is exactly what happens in http v1.
> > And it also works for leaves of the tree, BUT NOT for parent directories
> > when one of its descendants is already modified... which is what happens
> > v2.
> > I added a python test for this issue in r1577739.
> > (Based on Brane's script, but using just one working copy)
> One additional thought.
> Editor V2 aims to remove the depth first restriction for the other RA
> (opening the intermediate dirs; which allows the out of date checks), which
> is exactly what currently catches this class of out of date error on the
> other ra layers.
> Is there some way the FS layer could still deliver that original revision
> after making parts of the transaction mutable?
The information is trivially available inside FSFS, FSX
and probably BDB (e.g. via noderev predecessor ID) -
as long as the respective path has not been deleted
within that transaction. So far, there is no API for it.
> That would make this easy to fix and I think we will also need it for a
> editor v2 commit.
> Without it the EditorV2 commit won't be able to trigger this out of date
> error in even more of the scenarios, it was designed for...
> Interesting thought that this matches the problems with the tree conflict
> handling on the client side... I didn't think of that before this issue.
Received on 2014-03-15 16:16:46 CET