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