On Mon 2003-01-20 at 21:02:57 +0000, Philip Martin wrote:
Karl Fogel kfogel@newton.ch.collab.net writes:
Benjamin Pflugmann benjamin-svn-dev@pflugmann.de writes:
Given that using COMMITTED makes only sense with network access, why
don't query the server for that info? I do not think that it makes
much sense to have a COMMITTED that is fetched from a place that can
be out of date (I realize that this only affects dirs, but my point
stands anyhow).
COMMITTED is *not* the most recent committed revision on the server,
it is the last change at or before the BASE revision in the working
copy.
Probably my fault: I got confused by the description COMMITTED: The
last revision in which an item changed. in the docbook.
So I suppose to update the description a bit. It wouldn't hurt to
mention the WC like in the description of BASE. I would suggest
something, but I am still not 100% sure what exactly COMMITTED is
meant to be.
What you see is a consequence of Subversions mixed revision
policy,
I was aware of that.
the COMMITTED value is not out of date,
I did not say that. I did say that it can be fetched from a place that
can be out of date, namely the reference to the lazy base revision.
it still has the correct value given the base revision of the
directory.
Well, the The last revision in which an item changed. has no
reference to base revisions. So if your defintion is correct, the docs
are lacking.
The real issue is that '-r COMMITTED' isn't really meaningful for
directories.
[snip]
Frankly, I think we should either error when it is used with a
directory, or treat it like HEAD. Thoughts?
According to the docs, I would have expected the last change at or
before HEAD, as you probably already understood from my mail. An
error would be fine with me (as I did not use that feature yet), but
maybe others have a use case for it.
Regards,
Benjamin.
- application/pgp-signature attachment: stored
Received on Sat Oct 14 02:03:19 2006