stop on copy

[Peter Johansson]

related ticket: #277 #387

For time being svndigest uses blame without stopping on copy and thereby it mimicks the cmd version of svn. It would (perhaps) be useful to be able to configure svndigest to stop on copy. Additionally, it would be even more nice if we could separate svn copy from svn move. The latter does not really exist but is a combination of svn copy and svn delete. Yet the separation should be possible (I think).

Note, in the moment of submitting this ticket, I consider this ticket more of a base for discussion than a request for code.

[Peter Johansson]

See also issue in subverion about true renaming

​http://subversion.tigris.org/issues/show_bug.cgi?id=898

[Peter Johansson]

I think this important enough to be placed in 0.x

[Peter Johansson]

As I see it, there are three different kinds of copies:

1. An external copy, i.e., source is outside of the hierarchy defined by --root.
2. An internal copy in which source is deleted (e.g. issued by svn move).
3. An internal copy in which source is not deleted.

These three different kinds of copies should be treated independently, which means that for each of them one should be able to configure whether statistics should follow them or not.

Also, we have to think through what different combinations imply, and how they, e.g., effect copyright updates.

[Peter Johansson]

ticket:277 has been marked as related

[Peter Johansson]

Maybe we should allow the different StatsType to be configured individually. This adds more flexibility to the user.

[Peter Johansson]

Just to remind myself: stop-on-copy means that statistics are only calculated on changes done after the last copy. There is the border case when changes and the copy is done in the same commit. We should probably count that as well, so I rephrase myself: ..calculated on changes done after or in the same revision as the last copying.

[Peter Johansson]

Typically the source of a copy is at HEAD but we should also think about what happens when copying from a previous revision. In that case the three categories above still apply. However, it is no longer obvious how to differentiate between 2) and 3). If the source file still exists at HEAD it is clearly a 3), but what if the file was deleted at an intermediate stage. An important special case is when resurrecting files, i.e., say that we delete a file at rev 12 and then at rev 27 we do svn copy -r 12 File File. How should such a case be reported? Does it make sense to treat that deletion in the same way as though we emptied the file (at rev 12)? But again there is this tricky case if the file was not deleted at rev 12, but only renamed...

[Peter Johansson]

ticket:387 was marked as related

[Peter Johansson]

Replying to peter:

As I see it, there are three different kinds of copies:

1. An external copy, i.e., source is outside of the hierarchy defined by --root.
2. An internal copy in which source is deleted (e.g. issued by svn move).
3. An internal copy in which source is not deleted.

An interesting case is test/copyright_test2.sh.in which keeps its history all the way through the 0.7-stable branch. The last copy, from to 0.7-stable to trunk, is obviously a category 1. The copy before that is not as obvious. Well it is not a move and I would say it is a 3) because it is internal in its context. However, it is not that easy to define what external internal means. It is easy to define if we assume the standard structure with branches because then external is simply when you copy from one branch to another. If we are gonna be agnostic with regards to the bracnh structure it is not as easy anymore. It is easy for the first copy when we walk back the log because we can define based on <ROOT> but when we comes to the second copy we are in another branch and <ROOT> has lost its meaning. Remember this last branch is not necessarily a mirror of the branch we are running svndigest on. Take, for example, [baseplugins.thep.lu.se baseplugins] that has a structure where differnt branches of the tree are not similar at all but corresponds to different plugins.

[Peter Johansson]

A not very unusual case is splitting one file into two.

For example before the split we have file1:

a
b
c
d

and after the split

file1:

a
b

and file2:

x
c
d
y
z

Then I would like the committer to get ownership on lines x, y, and z, while previous owner keeps ownership on c and d (and obviously on a and b in original file).

[Peter Johansson]

For the record, when I prepared r1479 I used the following algorithm:

1. If src is outside trunk, do not ignore/stop
2. If src was Deleted in same changeset, do not ignore/stop
3. Else set ignore to rev-1 where rev is the revision in which copy occurs.

Interesting case is README.developer, which was copied from README.svn in r386. README.svn was actually deleted in r386 so it was a move. README.svn was copied from README in r281, so I set ignore to r280 so history as README.svn is reflected but history shared with README is ignored.

[Peter Johansson]

what if, in one changeset, one file is forked into two files:

svn copy foo bar
svn copy foo baz
svn remove foo

Who should own lines in foo's history and what happens when bar and baz are modified? How to break the symmetry? As now the lines are double counted, which seems sub-optimal. For StatType? Blame and Add it's less of a problem because when modifying bar and baz does not change the statistics for earlier revisions. Classic is the tricky one.