Greg Stein <gstein@lyra.org> writes:
> Why wait for commit_txn? That occurs *after* all the data has been delivered
> to the server. On my poor little 56k modem, that could be 15 minutes later.
> Then, *one* file is out of date, I say "fuck!", update that one file, and
> recommit the whole bloody thing.
+1 :-)
I think this is a case where the filesystem has to have code to make a
guarantee (the merge guarantee, that commits will error with conflict
rather than commit against out-of-date data), and ra_dav wants to have
some very similar code in order to achieve a network optimization.
Yes, the codes are similar, but each exists for a good reason,
independent of the other.
> Now, let's get back to the original question. Is there a *problem* with
> using the latest revision for the transaction root, rather than an arbitrary
> revision (i.e. the one passed to replace_root).
I don't see a problem with it. You're able to make the guarantees you
need. The one potential problem case you mentioned:
> 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" :-)
...doesn't seem like much of a problem; if the commit succeeds, it's
not like the merge rule has been violated. If someone got the
revision tree into that odd state, it means they've managed to do a
totally clean reversion back to REV3 for BAR, in which case it's
reasonable to consider someone committing from REV3 as "up-to-date".
Go for it, I say. :-)
-K
Received on Sat Oct 21 14:36:26 2006