[
https://issues.apache.org/jira/browse/SVN-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Foad updated SVN-1525:
-----------------------------
Component/s: (was: src)
> Use new "entity ID" notion instead of "committed rev"
> -----------------------------------------------------
>
> Key: SVN-1525
> URL: https://issues.apache.org/jira/browse/SVN-1525
> Project: Subversion
> Issue Type: New Feature
> Affects Versions: all
> Reporter: C. Michael Pilato
> Priority: Critical
> Fix For: 2.0-consider
>
>
> {noformat:nopanel=true}
> 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."
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
