I have recently looked into issue 3830 (forward revision range) and thereby found issue 3931 (returning log of unrelated path).

While implementing support for forward revision ranges i came across various cases, where i would like to resolve what is actually expected/desired:

- what "svn log" currently does

- what "svn log" should do to better support a common use case

- what does this imply for other "svn log" commands?

To better illustrate the following use cases lets define a simple timeline for one specific path (e.g. /file).

The items X and Y are both at the same path - but clearly for SVN they are considered unrelated:

Item Action

Rev

1 - -

2 - -

3 X add X

4 X modify X

5 X - (no change to X)

6 - delete X

7 - -

8 Y add Y

Set A: 1,2,6,7

Set B: 3,4,5

Obvious cases:

- "svn log" with peg revision from set A returns the error "path not found"

- "svn log" with peg revision from set B returns the same log, when the same revision range is used

Case (1): simple backward revision range

- "svn log peg=B" with "-r M:N" where M >= N and e.g. M = 5

-- N from set B, returns all revisions from [M,..,N] where X has been added/modified

-- DOES work with N = 1, even if path_at_N is not a valid path

--> path_at_N must NOT be a valid path when using backward revision range

-- DOES work with M = 2, even if path_at_M is not a valid path, returns an empty log

--> path_at_M must NOT be a valid path when using backward revision range

Case (2.1): simple forward revision range

- "svn log peg=B" with "-r M:N" where N >= M and e.g. M = 3

-- N from set B, returns all revisions from [M,..,N] where X has been added/modified (same as (1))

-- does NOT work with N = 6, since path_at_N is not a valid path

-- does NOT work with N = 8, since path_at_N is an unrelated path

--> path_at_N MUST be a valid path when using forward revision range

--> likewise it does NOT work with M > 5 since also path_at_M MUST be a valid path

But this is a common use case - showing the forward log of a known item:

- "svn log -r B:HEAD path_at_B" e.g. what has been changed since initially branching "branches/1.x"?

This command fails when "branches/1.x" has been removed in recent revision.

Issue 3830 is about permitting case (2.1) even when path_at_N is not a valid path.

-- expected result is: revisions from [M,..,N] where X has been added/modified

-- patch has been implemented and sent to the mailing list (see subject "[PATCH] possible improvement to svn log with "forward" revision range (issue 3830)")

-- what the patch does: the revision range is reduced if a deletion is found in the range between PEG an upper range boundary

But in the meantime i thought about further cases (all resulting in an error with current SVN):

Case (2.2): "empty" forward revision range

- "svn log peg=B" with "-r M:N" where e.g. M = 4 and N > M

-- could return an empty log, since X has not been modified in these revisions

-- would be very reasonable result and consistent to (1)

Case (2.3): "degenerated" forward revision range

- "svn log peg=B" with "-r M:N" where e.g. M = 6 and N > M

-- (a) could return an empty log, since the range does not cover any revision where X even exists

--> this looks like a very odd case, returning an error seems to be the better choice

-- (b) could return an error if M is equal or greater than deletion revision and therefore the range does not cover the lifetime of X

--> seems to be more appropriate, but is inconsistent to (1)

The current implementation for issue 3830 enabled (2.1), (2.2) and (2.3.a).

The question is:

- which of the described behavior for the cases (especially 2.3) is reasonable?

-- if (2.3.b) should be preferred, should (1) be modified to also return an error when e.g. N < 3?

I hope i was not too verbose.

I am looking forward for your opinions and feedback.

Dirk

Received on 2011-06-24 02:57:48 CEST