On Fri, 2004-04-02 at 15:50, Branko Èibej wrote:
> Let me understand this: are you both saying that you'd rather have yet
> another API for full histiry tracking instead of having this one at
> least support the concept, even if the inital implementation doesn't do
> everything?
More or less. I'm saying that this particular function, which is the
function that gets used to calculate the <peg-rev, path> X op-rev ->
path transform, should:
* Follow copies and renames, going backwards
* Follow renames but not copies, going forwards
Since we have neither rename tracking nor forward pointers in our FS, we
cannot currently follow renames going forwards; so for now, we should
only allow forward movement when the node-copy is in the same place
within the operative rev.
We should never follow copies going forwards because:
* Getting multiple results is an uncomfortable exceptional case.
* In the presence of rename tracking, the answer involving only
renames (or the one involving neither copies nor renames) is
better than the answer involving copies, so we might generate
an exception unnecessarily.
* A copy may indicate a branch, which is not generally appropriate
to follow going forwards.
* A copy may indicate a file split or other code operation which
is not appropriate to follow going forwards.
I have no objections to a future, separate API which allows searching
for all the copies of a node, or all the copies derived from a
node-copy, or both. (I have concerns about my ability to implement such
an API within my planned libsvn_fs_fs architecture. One of the key
design points of libsvn_fs_fs is that, once a revision is committed, it
never changes, except of course for the rev props. So we can't go back
and add forward pointers to the data within earlier revs. Still, that's
an implementation issue, not an API correctness issue.)
C.A.T.Magic wrote:
> if you do not traverse copies forward,
> will you be able to skip over files that
> are deleted from a revision but resurrected
> through a copy at a later time?
Ideally, I'd say there should be an operation which lets a file be
resurrected without generating a new node-copy. I don't know offhand
what the UI for that operation should be, though.
> why should a new copy of a file be handled differently
> than a rename of the file or a cp/rm pair?
Because it's a different operation. A rename preserves the identity of
the object while changing its location, while a copy produces a new (but
related) object. You're only used to the result being the same because
you're used to a filesystem without history.
Imagine for a moment that we had really good merge support. Say I want
to perform the following merge:
BASELINE: contains file "foo"
MAINLINE: copies "foo" to "bar"; renames "foo" to "baz"
BRANCH: modifies file "foo"
The best merge result we can expect from a version control tool has the
branch's modifications to "foo" merged into "baz", with "bar"
unchanged. To get this result, we have to distinguish the rename from
the copy.
(That kind of merge support isn't a total pipe dream; arch has it,
although it doesn't track copies at all.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 3 02:29:35 2004