Use 'revision' as the SVN's 'peg_revision' (broken for an edge case)

[jgsogo]

Changelog: Fix: Use revision as the SVN's peg_revision (broken for an edge case)
Docs: omit

closes #5017

@tags: svn, slow

[jgsogo]

Motivated by #5017 we are thinking about changing get_last_changed_revision by get_revision to retrieve the peg_revision for the URL. It is required for a use-case where it is being checked out a subtree of a tag to create the package (more details in the issue, and the test in this PR).

IMO, although it could lead to a different peg_revision it would still be valid, and we will solve this use case. I'm pinging our SVN users @climblinne, @Aalmann, just in case they can point out some unexpected behavior due to this change. Thanks!

[climblinne]

Looks good to me.

[lasote]

@Aalmann could you take a look? Thanks!

[Aalmann]

Looks good to me.
@ahauan4 can you test it with one of your repos? #5017 describes a similar layout to yours.

[ahauan4]

@Aalmann We had not a problem so far, because we check out the trunk/branches/tag directory directly on Jenkins.
Our setup is: repo_root/category_name/module_name/<trunk|branches|tags>/conanfile.py

One disadvantage of using get_revision instead of get_last_changed_revision could be, that if we build the same thing twice after the revision counter increased (because of checkins in a different module), we would get different revisions published in the final package. But as long as this won't affect the hash, it would be ok from my side.

[lasote]

@Aalmann @ahauan4 Are you using the package revisions mechanism? In that case, if you export the recipe again you will get new package revision because of the captured URL with change with the new (svn) revision counter. But the package_id won't change in any case.
Are you ok then?

[jgsogo]

The change from get_last_changed_revision to get_revision is done only for the peg_revision but not for the revision to checkout, so in your case, @ahauan4, the problem was there and will still be.

About the hash: each time the recipe is exported (if there is any "auto" in the SCM dictionary) those "auto" will be resolved and substituted. If there are new commits, then the peg_revision and the revision will change (the second one for sure, and the first one since this PR) and the hash of the recipe will change (but it was changing before too).

[ahauan4]

@lasote @jgsogo We don't use the package revisions feature.
I meant package_id instead of hash. Sorry for beeing unclear.
So as long as the package_id won't change, we should be ok.

[Aalmann]

@lasote and @jgsogo
We are not using the package revisions at the moment. So everything is fine. Go for it.

[jgsogo]

Thanks all for your feedback! 😸

@keithrob91, if it is not blocking you, we will release it with 1.16, is it ok?

[keithrob91]

That is fine. Thank you.