The revision number used in the url is actually the revision number of the particular file rather than the change revision number.
meaning that in the above example the actual file has changed 4 times. Looking at your logs the number 133753 appears to be the change number rather than the file revision number.

Just for reference, the number is generated from the perforce describe command which returns results such as:

Change 68 by devuser@newClient on 2007/04/16 18:15:30

        myComment

Affected files ...

... //bambootest/successBuild/myFile.txt#6 delete

where the #6 is the revision number of the file.

Hope this helps
Brydie.

I see what the problem is here; FishEye uses the change number, and Bamboo uses the revision number.

Obviously using the revision number is easier, because you can do ?r1=${revision-1}&r2=${revision}. However, FishEye expects ?r1=${last_changeset_the_file_changed}&r2=68 (in your example above).

The difficulty is figuring out ${last_changeset_the_file_changed}; I guess you'd have to persist this somewhere...

Would you like me to drop a mail to Cenqua to see if they can help out on their side? They may have the metadata to be able to support revision-to-revision diffs instead of changeset-to-changeset...

Cheers,

David

It seems that cvs and svn repositories use the revision number and perforce uses the change number. We were using the same rules to generate all the URLs, we will have to change this to repository specific.

However I would also be very interested to see whether Cenqua could support the revision-to-revision diffs instead.

Thanks
Brydie

I have fixed bamboo to use the change list numbers instead of file revision numbers in the diff links. Unfortunately this will only take affect on future builds (old builds will still have the revision number). I have included the changes in the next release.

Cheers
Brydie