Opened 14 years ago

Last modified 8 years ago

#204 new task

stop on copy

Reported by: Peter Johansson Owned by: Jari Häkkinen
Priority: critical Milestone: svndigest 0.x+
Component: core Version: trunk
Keywords: Cc:

Description (last modified by 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.

Change History (15)

comment:1 Changed 14 years ago by Peter Johansson

See also issue in subverion about true renaming

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

comment:2 Changed 14 years ago by Peter Johansson

Milestone: 1.00.8
Priority: minorcritical

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

comment:3 Changed 14 years ago by 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.

comment:4 Changed 14 years ago by Peter Johansson

Description: modified (diff)

ticket:277 has been marked as related

comment:5 Changed 13 years ago by Peter Johansson

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

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by 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...

comment:8 Changed 12 years ago by Peter Johansson

Description: modified (diff)

ticket:387 was marked as related

comment:9 Changed 12 years ago by Peter Johansson

Milestone: svndigest 0.8svndigest 0.9

comment:10 in reply to:  3 Changed 12 years ago by 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.

comment:11 Changed 11 years ago by 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).

comment:12 Changed 11 years ago by Peter Johansson

Milestone: svndigest 0.9svndigest 0.10

comment:13 Changed 10 years ago by Peter Johansson

Milestone: svndigest 0.10svndigest 0.x+

comment:14 Changed 9 years ago by 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.

comment:15 Changed 8 years ago by 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.

Note: See TracTickets for help on using tickets.