Greg Stein <gstein@lyra.org> writes:
> I guess it is conceivable for something like this to happen:
>
> REV3/
> FOO/
> BAR(4.1)
>
> REV4/
> FOO/
> BAR(71.6)
>
> REV5/
> FOO/
> BAR(4.1)
>
> If a user has 3:/FOO/BAR, and the latest rev is 5, then a commit to BAR will
> actually succeed since it is "up to date" :-)
The old way of doing this won't detect this case either. One would
have to scan every revision between your base and youngest to catch
these; it doesn't seem worth it.
> Can anybody see a problem with creating transactions based on the latest,
> and verifying that the base of each desired change matches that within the
> latest tree?
I don't think so. I think you're just folding together the working
tree construction phase and the merge phase. If you have some way of
knowing the base revision of each node being changed, then there's no
point in actually going back to the base revision to find it.
Of course, a merge will still necessary, to handle other transactions
people have committed while you've been building yours, so this
doesn't simplify the filesystem's needs. But it's nice to be able to
catch conflicts earlier, and the merge will usually need to do less
work when it does happen.
If our server-side merging were doing something fancier, then your
approach might interfere, but, well, we're not doing anything more
sophisticated. And Karl has made pretty good arguments that one
shouldn't, anyway.
If I were really looking for something to complain about, I'd say that
this reminds me of folding together two loops into one loop with a
more complex body. It makes the process harder to follow overall.
But we're getting good behaviour out of it, and probably better
locality.
Received on Sat Oct 21 14:36:26 2006