• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Low Low
    • 1.1.2
    • 1.0.4
    • Repository (Other)
    • None

      The (re)vision numbers aren't matching with perforce.

      For example, the diff link looks like:

      http://hostname/path?content-type=text/vnd.viewcvs-markup&r1=3&r2=4

      where it should look like

      http://hostname/path?content-type=text/vnd.viewcvs-markup&r1=133611&r2=133753

      A similar problem happens with the "(version n)" link; it's got the wrong revision number in the text and the href, ie 4 instead of 133753.

      Hopefully an easy one for you guys to fix.

      Cheers,

      David

            [BAM-1138] File Version Number problems with Perforce

            bmccoy added a comment -

            Hi David,

            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

            bmccoy added a comment - Hi David, 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

            bmccoy added a comment -

            Hi 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

            bmccoy added a comment - Hi 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

            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

            David Dunwoody added a comment - 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

            bmccoy added a comment -

            Hi David,

            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.

            bmccoy added a comment - Hi David, 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.

              bmccoy bmccoy
              38c857f87151 David Dunwoody
              Affected customers:
              0 This affects my team
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: