2

Suppose I have such svn structure:

svn://myhost/repository_main
svn://myhost/repository_ext

The revision numbers of these two repositories are isolated.

Now I have set a svn:externals on svn://myhost/repository_main/foo:

svn://myhost/repository_main/foo --> svn://myhost/repository_ext/bar

Then in the Jenkins I have a job which uses the svn://myhost/repository_main and I could specify the revision number to update like:

svn://myhost/repository_main@REVISION

When the Jenkins is going to update the /repository_main/foo at revision REVISION, it always update to the HEAD revision of the repository_ext/bar.

Is there any way I could specify not only the revision of the main but also the ext?

jayatubi
  • 1,972
  • 1
  • 21
  • 51

1 Answers1

3

The externals mechanism uses it's own specified revision. This is nothing to do with Jenkins. Even without Jenkins (through browser or your SVN client), if you try to checkout from your repository_main with specified revision, it will take the HEAD for repository_ext

externals is an SVN property. It specifies 2 things:

  1. The remote (external) location
  2. The revision of that location

If you configured that property to remote HEAD, it will always be HEAD of remote location, even when you go to previous revision of your main. Think of it as a local file with a value. If the file had a value remote@HEAD at main revision 100 and hasn't changed since then, when you are at main revision 200, the value of the file is still remote@HEAD. And when you go to main at revision 199, that file still points to remote@HEAD

Your other option is to lock the external to a specific revision, i.e remote@123, but then it will always be at that ext revision, again regardless of the main revision.

If you have a hard dependency between the revision of code in main and the appropriate ext revision, then your externals property should not be pointing at HEAD of remote, but at specified revision. You would need some process to keep the property updated with latest required revision. If you do that, your external property may be remote@123 at main revision 100, and then remote@456 at main revision 150 and then remote@789 at main revision 200.

Only in that case, specifying a main revision would affect the revision of the external repository that is fetched up.

Alternative:
As a complete workaround (what is described above is how SVN expects you to work with it), you can have a Jenkins parameter for "externals revision". Then in SCM steps, tell Jenkins to ignore externals. Then in your Build steps, manually parse the value of the externals property, figure out the remote location, and manually check out from that location with the revision that you specified in parameters.

Slav
  • 27,057
  • 11
  • 80
  • 104