On Mon 2003-01-20 at 21:02:57 +0000, Philip Martin wrote:
Karl Fogel firstname.lastname@example.org writes:
Benjamin Pflugmann email@example.com 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
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
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
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
Well, the The last revision in which an item changed. has no
reference to base revisions. So if your defintion is correct, the docs
The real issue is that '-r COMMITTED' isn't really meaningful for
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.
Received on Sat Oct 14 02:03:19 2006
- application/pgp-signature attachment: stored