[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: The "follow copy history" initiative

From: John Peacock <jpeacock_at_rowman.com>
Date: 2004-04-06 04:38:15 CEST

Folker Schamel wrote:
> It's not only "one scenario", its the standard case:
> If a file has the history of another file,
> this means per definition that it has the same content
> plus modifications, and merging is necessary
> in the same way as for normal modified files.

I disagree almost completely. A copy with history, in the sense that Subversion
understands it, is a bifurcation. Two files can share the same ancestor, but
there is nothing in the system that requires that they continue to share the
same content. In fact, that would be a disaster for many situations.

For example, I branch my mainline to provide a bug fix, so I make a copy of a
file. Once I am happy with that branch, I release the bug fix, but then decide
not to make that same change to the trunk and fix it another way. There is no
way for the tool to know which way to merge these two changes, and in fact it
would be outright wrong to automate any merge.

> But if the content of the copied file is fundametally different
> from its original, it makes no sense to talk about / keep the history,
> and it should be treated as new file.

But it is _not_ a new file; it shares a common ancestor with the other file.
This is a good thing, since the common parts of both files share the same
development path (so I can do a blame analysis on either file to see when a
given common line was added).

> If you say that because of implementation issues
> this is too complicated, then the right solution is
> to support moves, but no copies at all.
> Copy with history but without merge support makes no sense.

There are no moves in Subversion; only copies and deletes.

The normal copy in Subversion copies only the pointer to the original file (and
it's history). If I then change the copy, Subversion actually copies the file
and creates a new node (with the same history as the previous), so that the two
files are no longer sharing the same node, but have diverged.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 04:38:23 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.