Peru/SVN: Can not import files from a repo-path that existed in the past but has been moved

Hi, I just started using peru (Version V1.2.0, Windows 10) and did various tests in order to get some experiences with it. For the time being, I use SVN only (I am not familiar with git).

The issue I experienced is, that I can not import files from svn repository paths, that have been moved to a different location within the same repository and do not exist in the head revision. I explicitly specify the corresponding revision of when the path still existed in the past.

The corresponding peru.yaml file looks like this:

imports:
    txtTest: common

#This does not work although it should
svn module txtTest:
    rev: "32"
    url: https://<someRepoPath>/dir1_bornRev32

someRepoPath is obviously just a place holder. The sub directory dir1_bornRev32 exists in Revision 32 at the specified location, but it does not exist in the head (latest) revision, because it has been moved elsewhere.

However, if I start peru, peru sync the operation can not be completed successfully. Peru passes the following error message to the command shell:

svn: E160013: '<someRepoPath>/!svn/rvr/35/trunk/dir1_bornRev32' path not found

What meets the eye, is that the Revision that is passed back is not the one explicitly specified (32), but the head revision (35). So the information in the error message is correct: that path does not exist in revision 35 (head).

I assume that at some point the specified revision is not explicitly passed to SVN.

It would be great, if you could try to reproduce the issue. My colleague was able to reproduce the issue (with the same repository).

Thank you in advance.

Best Regards, Tweakbert

[Tweakbert]

Thank you both for your replies, Sean and Jack.

Sean: Yes, in my specific example, it does work with pick, because the rest of the path in “someRepoPath” is still valid in the head-revision.

But I see the issue somewhere else. I take it, that the primary goal is the reproducibility of source/builds and I did not get, that either pick or export are required in order to make the source reproducible, I rather understood them as something like filters. I specified modules in peru.yaml that could be synced and built fine in one revision. When I re-organized directories in the next revision, I was not able to sync / build anymore, although all the necessary information was in peru.yaml and in the repository. The paths were not found anymore, although they existed in the revisions I explicitly specified in peru.yaml. This is not desireable.

Jack: I checked the parameters that peru passes to svn. Hope I did not get it wrong, I don’t have any python experience, nor did I use svn from the command line before. I tried the parameters that I understand peru passes to svn in the command shell - and I got the same result / error message from svn. I took a closer look at svn export and noticed an important detail: the peg revision, which is currently not passed to SVN. To my understanding: the peg revision defines path, that existed at a certain point (specific revision) in the history of an svn repository.

I guess it is crucial, to pass this peg revision, which shall be the same as the module revision in order to enable SVN to export from the specified path, that might not exist in the head revision anymore (I guess this is what it defaults to, if not specified).

Here is more information about it: https://edoras.sdsu.edu/doc/svn-book-html-chunk/svn.advanced.pegrevs.html

Currently, peru passes the following parameters (I use the example from before): svn export --force --revision 32 https://<someRepoPath>/dir1_bornRev32 common But as mentioned before, that does not work, when the specified path to dir1_bornRev32 has been moved and does not exist anymore in the head revision.

Here is a proposal that fixed the issue in my attempts: svn export --force --revision 32 https://<someRepoPath>/dir1_bornRev32@32 common

Please pay attention to the @32 appended to the url (no spaces between url and peg revision). When the optional peg revision is added like this, it works and the files can be retrieved from the path that existed for this specific revision.

[oconnor663]

(Apologies for leaving this hanging for a while. I’m still leaning towards keeping the current behavior, but I want to think more carefully about this and maybe play around with both before we make a final call, and I might not find time to do that soon.)