Re: [PATCH] Issue #2287 - Make svn_client_log() take a peg revision

"S.Ramaswamy" <srsy70@gmail.com> writes:
> I tried this patch to get an idea about peg revisions.
> .While the tests pass, and log is now able to follow files
> across renames, I am not sure about the approach.
>
> A couple of the log tests fail that run 'svn log' on older
> revisions of the repos url fail:
> FAIL: log_tests.py 7: 'svn log -r N URL' when URL is not in HEAD
> FAIL: log_tests.py 8: 'svn log TGT' with copyfrom history
>
> That could be because a peg revision is now required by log, when
> listing files not in HEAD
>
> Any suggestions ?

Ben and I just talked this over, and decided the old behavior
(succeeding) was a "bug", and that the new failure is correct. The
URL does not exist in HEAD, period. Therefore, this command

$ svn log -rN url_not_present_in_head

which has an implied peg rev

$ svn log -rN url_not_present_in_head@HEAD

should fail.

However, this is an incompatible change that users are likely to
notice. I think we should have a separate discussion about it. In
order to do so, I will follow up to this mail with another mail, one
with a more attention-getting subject, and refer people back to this
thread.

Since we're already taking a parameter called 'peg_revision', a
comment here explaining what 'revision' is and how it differs would be
helpful. Also, a comment could explain the relationship of 'rev' to
these two. You can see how things start to get confusing pretty
quickly! :-)

The old code was able to get away with checking just the first target
because it checked the other targets for inconsistencies against the
first target: if the first target was a URL, then everything had to be
a URL, or else error. Or if it was a wc path, everything had to be a
wc path.

But here, you're parsing off a peg rev from the first target, while
not addressing the question of what happens if there are peg revs on
other targets.