The concept of the committed revision on a given path turns out to be not so
useful. Examining two different paths and their CRs, you can't tell if the
paths reflect the same line of history, you can't assume that changes in the
path with the higher revision number are also included in the other path. Even
if the two paths *do* reflect the same line of history, you have no idea how
much churn has occured between the two revisions (there could be any number from
0 to N-M commits to a path between revisions M and N). And people seem to
really want, on a per path basis, a monitonically increasing count of committed
changes to that path.
And this isn't even touching the wealth of issues that occur when trying to
maintain a committed rev in light of our "cheap-copy" FS model. *Shudder*.
No, CR ain't the way to go.
But in a relatively recent brainstorming session of myself, jackr, sussman, and
kfogel, I stumbled across this idea of an "entity ID" (though that might not
have been what we called it -- could have been "resource version string" or
something). Anyway, this thing consists of the tuple (NodeId, BranchId,
ChangeCount), where:
- (NodeId) uniquely identifies a line of history,
- (NodeId, BranchId) unique identifies a particular branch of a line
history,
- (NodeId, BranchId, ChangeCount) uniquely identifies a particular
version along a particular branch of a line of history, and
- ChangeCount increases monotonically with each commit to that line
of history.
We think we can generate this thing using the filesystem's NodeId, CopyId, and
(get this) the PredecessorCount (from the skip-delta code!). The idea would be
to replace the client-side CR with this puppy, including an expandable
svn:keyword for it, so that you could, say, look at two printouts of various
versions of a document that are lying on a table and, presuming you know they
are from the same repository (perhaps we should toss the UUID into the tuple?
Hm...), say with confidence, "These are two versions of the same document, along
the same line of history, *this* one is the youngest one, and there were X
revision between the two versions."
New Feature
Critical
SVN-620 wc inconsistency bug in copies
