[#CIB-1625] Build revisions when using perforce should be limited to revisions that affec the client

Pulse

Build revisions when using perforce should be limited to revisions that affec the client

Created: 28/Aug/08 08:18 PM Updated: 08/Nov/08 02:04 AM

Return to search

Component/s:

None

Affects Version/s:

None

Fix Version/s:

2.0.15

Original Estimate:

Unknown

Remaining Estimate:

Unknown

Time Spent:

Unknown

Description

« Hide

Currently the reported revision is the latest on the server. Usability-wise this is annoying as the latest change on the server may have nothing to do with a particular project. This probably also affects Subversion.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

jason - 28/Aug/08 08:20 PM

This prevents things like having the build name artifacts based on the build revision, as the revision is somewhat meaningless in the context of the project. From the server revision you can always infer the latest revision affecting the project, but that is an unneccessary manual step that we should not push onto the end user.

[ Permlink | « Hide ]

TQ Berg - 05/Nov/08 11:33 PM

BTW, if you look at the changes tab for a build [http://pulse.foo.com/browse/projects/Data%20Service%20(main)/builds/100/changes/]

You get the built revision number (e.g. 119742 which is the global one and the one we don't want) -- and you get the revision numbers for the changes (e.g. changes between build 99 and build 100). The latest of these is the number we want (e.g. revision 119741 & revision 119740 -- in this 119741 would suffice -- but we definitely don't want 119742).

Since it appears that you already have the info we need, would it be simple to add it as a build property?

[ Permlink | « Hide ]

jason - 08/Nov/08 02:04 AM

Fixed in change 5101.