Conan: svn scm bug when using a tag

[keithrob91]

conan 1.14.3

We have a component that has a recipe called 'conanfile_policy.py' in a sub directory called 'policy'. See:

As part of our test build process this component gets tagged at the component root level ie above the policy dir, after the recipe was changed so a build can be done from the tag. The SVN revision graph showing this is:

As part of our build process, Jenkins checks out the policy subdir using the tag and exports the recipe, this is preparation for doing a conan create on our 'product' recipe to build our entire product.

The url gets deduced incorrectly by scm auto in this export, which means Jenkins can’t conan create from the recipe for this component breaking the build. The exported recipe looks like:

scm = {"revision": "126",
           "type": "svn",
           "url": "svn+ssh://svnserver/svncmake/sophosmanager/tags/CONAN_REL_3.0.0-2/policy@125"}

The conan create fails because the tag does not exist at rev 125, only 126.

I think the issue might be how scm auto deduces the svn revision to create the url, it appears to use Last Changed Rev rather than the Revision attribute from the svn info. With a subdir under the tag, the Last Changed Rev doesn’t include the tag, as the tag didn’t occur in the subdir, but at the level above it.

[jgsogo]

Hi @keithrob91!

I'm trying to reproduce your issue inside a test, but I will probably need some help from your side. You can have a look at the test in this commit:

1. I create a repo with the level1 subfolder and the tags one
2. I create a tag for level1: svn copy {url}/level1 {url}/tags/level1-1.0 -m .... This command creates the commit number 2.
3. I check out the tag: svn co "{url}/tags/level1-1.0" "{path}"
4. I export the recipe, and I get for the scm attributes:
   
   
   
   • revision = 2
   
   
   • url = ....@2
   
   
5. I call conan install ... --build and it works, the _url@peg_revision_ to clone exists.

There is something different in your workflow if you are getting a different revision and peg_revision, can you spot the difference?

Thanks!

[keithrob91]

Assuming we start from trunk. Then there should be a sub-dir called "level1" that contains a recipe that uses the scm feature.

1. Check out a working copy from trunk, the working copy should have a sub-dir called 'level1' with the recipe within it.
2. Edit the recipe within 'level1' - add a comment or something simple
3. Commit the change
4. Create the tag at the toplevel. e.g. svn copy {url}/trunk {url}/tags/reltag-1.0
   4.1 This is where you may have gone wrong
5. svn co "{url}/tags/reltag-1.0" "{path}"
6. conan export path/level1/conanfile.py dev/dev
   6.1 Check what the deduced values are within the recipe within the cache

This should hopefully reproduce the issue.

[jgsogo]

Thanks, but still not able to reproduce the error :/

If you have a look at the updated test, now I have:

• setup stage: I'm modifying the conanfile.py file (I'm adding all the required content, before it was just an invalid file)

        # Modify the recipe file and commit in trunk
        t = TestClient()
        t.runner('svn co "{url}/trunk" "{path}"'.format(url=self.project_url, path=t.current_folder))
        t.save({"level1/conanfile.py": conanfile})
        t.runner('svn commit -m "created the conanfile"', cwd=t.current_folder)

        # Create a tag for 'release 1.0'
        t.runner('svn copy {url}/trunk {url}/tags/release-1.0'
                 ' -m "Release 1.0"'.format(url=self.project_url), cwd=t.current_folder)

• test stage: I'm checking out the tag, exporting the recipe file and checking that I get the revision=3 and peg_revision=3 for the resolved scm "auto" fields.

        # Clone the tag to local folder
        url = os.path.join(self.project_url, "tags/release-1.0")
        t.runner('svn co "{url}" "{path}"'.format(url=url, path=t.current_folder))

        # Export the recipe (be sure sources are retrieved from the repository)
        t.run("export level1/conanfile.py {ref}".format(ref=ref))
        package_layout = t.cache.package_layout(ref)
        exported_conanfile = load(package_layout.conanfile())
        self.assertNotIn("auto", exported_conanfile)
        self.assertIn('"revision": "3",', exported_conanfile)
        self.assertIn('tags/release-1.0/level1@3', exported_conanfile)

---

Having a look at the source code, we are using:

• last-changed-revision for the peg_revision inside the URL
• revision for the revision field

I don't know why you get for the last-changed-revision a revision number (125) which correspond to the moment before creating the tag (because we are asking the tag itself about this revision number...). So, you were right in your first comment

I think the issue might be how scm auto deduces the svn revision to create the url, it appears to use Last Changed Rev rather than the Revision attribute from the svn info. With a subdir under the tag, the Last Changed Rev doesn’t include the tag, as the tag didn’t occur in the subdir, but at the level above it.

...but I'm not able to reproduce the _"With a subdir under the tag, the Last Changed Rev doesn’t include the tag, as the tag didn’t occur in the subdir"_.

[keithrob91]

That is annoying! I'll take a look and see if I can spot anything.

Can I ask what version of svn you are testing against? We are using (the prehistoric) 1.7.14

[jgsogo]

I'm using 1.10.3... let's see if I can go back in time to run this test

[jgsogo]

I've tried with this docker image https://github.com/KaiHofstetter/docker-svn-client and the test works as expected. This image has SVN 1.7.14:

svn --version
svn, version 1.7.14 (r1542130)
   compiled Jan  6 2014, 22:58:18

[keithrob91]

Appreciate that. I'll try and work out what we are doing differently to you.

[keithrob91]

After telling you to tag the toplevel directory, I should have also re-stated that the checkout (in the test phase) should be done on the sub directory. i.e.:
url = os.path.join(self.project_url, "tags/release-1.0/level1")

[jgsogo]

Now I'm getting the error, 👍 . I'll try to pass all the tests with the revision instead of last-changed-revision, let's see what happens.

[keithrob91]

Hi there. How is the testing going on this?

[jgsogo]

Let's run the CI again (it was broken), and maybe we can consider it for next release (ping @lasote)

[keithrob91]

Sorry to bother you again, but is there any further news on this one? We have worked around the bug in our setup, but it isn't ideal.

[lasote]

@keithrob91 We are gathering feedback until we plan the release. I'm still not sure if it should be an opt-in behavior. I'm not 100% sure that fixing this (changing the behavior) won't break other users.
I'm assigning to 1.16.