Subversion plugin: revision number semantics

Hi folks,

I have a question  concerning the subversion plugin and its handling of the revision  numbers.

The  problem:
The subversion  plugin uses as the revision number of a vcsRoot the global revision number of  the repository, rather than the HEAD of the given vcsRoot. If the vcsRoot is a  branch, the revision number of a build is the current revision of the HEAD of  the whole repository. I would prefer the revision number of the latest change of  the branch since this clarifies which changes are included.
As I understand the  definition of a Version as described  in
does not fit with  the current implementation of the subversion plugin.

Main Question:
What is the intergretation of the community? Which semantics for the revision numbers help more?

Suggested  solution:
The subversion  plugin uses the latest change revision of the full path provided by a vcsRoot  rather than the HEAD of the whole repo.

More Questions:

Does it make sense  to fix this in future? Or to provide a variable {build.vcs.latestChangeNumber}  wich contains the latest change revision?
Are the sources of the plugin available (for Enterprise  users)?Or is there a change to fix this by providing a wrapper  around the original plugin?

Have fun,

Comment actions Permalink

Hello Alex,

  Please check TW-4527 issue. Is it what are you asking for?


Comment actions Permalink


thanx, this issue describes the problem, so I voted for it.
For a short term solution, Yegor suggested the Groovy plugin, but I have still problems to define a build number using the property.


Comment actions Permalink

I'm having an issue, using GroovyPlug on TC 4.5.2,  I followed the instructions to get it installed on the server, but I'm not sure how to use it properly, I replaced the build number format from {build.vcs.number.1} to {build.vcs.lastIncluded.revision.1}.

I get ??? instead of the Changelist number what was included in the last sync/build.

The build configurations is set up like this

1. Sync and Build Apps (includes VCS)
2. Build Data  (includes VCS)
3. Autorun  (includes VCS)

I pretty much want config 2 and 3 to have the same change list as 1 because there are times when VCS for 2 and 3 are newer than 1 because it took newer changelist while it was building the code, which becomes a problem when tracking who caused the breakage.  I was thinking {build.vcs.lastIncluded.revision.1} would be the solution, but I'm not sure how to use it properly.

In fact, we are actually using

1. Sync and Build Apps (includes VCS1)
2. Build Data  (includes VCS2)
3. Autorun  (includes VCS1 & VCS2)

Any help would be much appreciated.



Please sign in to leave a comment.