Need help trying to show changed files between baselines.
Hi,
I'm relativity new to Java and quite new to RTC. I am looking for samples with the Plain Java API to help me try to list files that have changed in each component between releases (Baselines).
I've looked at the samples that come with the plain Java API's which explain some of the basics but there doesn't seem to be much that shows much more detail, especially with the source control side. Is it possible for someone to post a sample to achieve the above.
Thanks for any help,
Regards,
Jason
I'm relativity new to Java and quite new to RTC. I am looking for samples with the Plain Java API to help me try to list files that have changed in each component between releases (Baselines).
I've looked at the samples that come with the plain Java API's which explain some of the basics but there doesn't seem to be much that shows much more detail, especially with the source control side. Is it possible for someone to post a sample to achieve the above.
Thanks for any help,
Regards,
Jason
13 answers
You can also use the Jazz SCM command line to determine the changes (the
"scm compare" operation).
For details, see the most recent posting in the "Getting verbose output
during the build fetch operation" thread in the jazz.user forum.
Cheers,
Geoff
jasuk70 wrote:
Hi,
We need a list of files that have changed in each component so we can
generate an upgrade package for each component that has changed for
our auto update system.
An example of the perforce way is:
ukvir-jdrh5_64-~: p4 changes -m 1 //depot/APP/COMP1/...
Change 86367 on 2009/11/25 by xxx@xxx 'xxxxxxxxxxxxxx'
The routine will then check the last change that was made to the
component and work out if this "Component" has been updated
since the last release (By checking a file that has been checked into
an area of perforce). If it has changed, then it will update this
area with the latest change number and then mark this component as
needing to be updated.
This is all done by the build process.
Cheers,
Jas
"scm compare" operation).
For details, see the most recent posting in the "Getting verbose output
during the build fetch operation" thread in the jazz.user forum.
Cheers,
Geoff
jasuk70 wrote:
gmclemmwrote:
Yes, you can use the Jazz SCM command line to efficiently update your
file area.
Cheers,
Geoff
Hi,
We need a list of files that have changed in each component so we can
generate an upgrade package for each component that has changed for
our auto update system.
An example of the perforce way is:
ukvir-jdrh5_64-~: p4 changes -m 1 //depot/APP/COMP1/...
Change 86367 on 2009/11/25 by xxx@xxx 'xxxxxxxxxxxxxx'
The routine will then check the last change that was made to the
component and work out if this "Component" has been updated
since the last release (By checking a file that has been checked into
an area of perforce). If it has changed, then it will update this
area with the latest change number and then mark this component as
needing to be updated.
This is all done by the build process.
Cheers,
Jas
You can see if http://jazz.net/library/article/195 has any useful tidbits
in it.
Also, you can check if the "scm lastmod" command helps you in anyway.
On Fri, 04 Dec 2009 11:38:01 -0500, jasuk70
<jdean> wrote:
Hi,
We need a list of files that have changed in each component so we can
generate an upgrade package for each component that has changed for
our auto update system.
An example of the perforce way is:
ukvir-jdrh5_64-~: p4 changes -m 1 //depot/APP/COMP1/...
Change 86367 on 2009/11/25 by xxx@xxx 'xxxxxxxxxxxxxx'
The routine will then check the last change that was made to the
component and work out if this "Component" has been updated
since the last release (By checking a file that has been checked into
an area of perforce). If it has changed, then it will update this
area with the latest change number and then mark this component as
needing to be updated.
This is all done by the build process.
Cheers,
Jas
--
in it.
Also, you can check if the "scm lastmod" command helps you in anyway.
On Fri, 04 Dec 2009 11:38:01 -0500, jasuk70
<jdean> wrote:
gmclemmwrote:
Yes, you can use the Jazz SCM command line to efficiently update your
file area.
Cheers,
Geoff
Hi,
We need a list of files that have changed in each component so we can
generate an upgrade package for each component that has changed for
our auto update system.
An example of the perforce way is:
ukvir-jdrh5_64-~: p4 changes -m 1 //depot/APP/COMP1/...
Change 86367 on 2009/11/25 by xxx@xxx 'xxxxxxxxxxxxxx'
The routine will then check the last change that was made to the
component and work out if this "Component" has been updated
since the last release (By checking a file that has been checked into
an area of perforce). If it has changed, then it will update this
area with the latest change number and then mark this component as
needing to be updated.
This is all done by the build process.
Cheers,
Jas
--
Geoff is correct, you can use the scm compare command from the command line to get a detailed change log.
Below is the output of running the command "scm help compare".
I hope this helps,
JohnC
SCM Server
Help on compare
Display the outgoing changes from one item to another. The items must be specified on the commandline along with their type. Change direction (either incoming or outgoing) is shown relative to the first item.
Aliases: comp
Usage: scm compare <new> <new> <old> <old>
new-type - Type of the new item to compare. One of: "workspace", "stream", "baseline", or "snapshot"
new - New item to compare against (must be of type specified in new-type), may be alias, UUID, or name.
old-type - Type of the old item to compare. One of: "workspace", "stream", "baseline", or "snapshot"
old - Old item to compare against the new item (must be of type specified in new-type), may be alias, UUID, or name.
Options:
-c arg - Component for baseline comparisons. Required if the baseline is specified with anything other than an alias or UUID.
-C arg - Format for contributors. {userid} expands to the user's repository ID; {name} expands to the user name; {email} expands to the user's email address; {itemid} expands to the user's repository item ID
-D arg - Format for dates. Legal values can be found in the Java SimpleDateFormat specification.
-f arg - Only show changes in the given direction. Must be one of: "i" for incoming; "o" for outgoing; or "b" for both (default).
-I arg - A combination of letters indicating which items to show - flow direction: "d"; component: "c"; baseline: "b"; work item: "w"; change set: "s"; filesystem: "f" (default: "dcbsw")
-P arg - Password for repository.
-p arg - Prune unchanged/empty items. May include: "d" for empty directions; "c" for unchanged components.
-r arg - URI specifying the location of repository.
-S arg - Indicate what optional values should be displayed. "c" causes contributor fields to be shown; "d" causes date fields to be shown; "i" causes work items to be shown under change sets.
-u arg - Username for repository.
-w arg - Root work items under a specific node type. Must be one of: "r" for root; "d" for direction; "c" for component; "b" for baseline.
Below is the output of running the command "scm help compare".
I hope this helps,
JohnC
SCM Server
Help on compare
Display the outgoing changes from one item to another. The items must be specified on the commandline along with their type. Change direction (either incoming or outgoing) is shown relative to the first item.
Aliases: comp
Usage: scm compare <new> <new> <old> <old>
new-type - Type of the new item to compare. One of: "workspace", "stream", "baseline", or "snapshot"
new - New item to compare against (must be of type specified in new-type), may be alias, UUID, or name.
old-type - Type of the old item to compare. One of: "workspace", "stream", "baseline", or "snapshot"
old - Old item to compare against the new item (must be of type specified in new-type), may be alias, UUID, or name.
Options:
-c arg - Component for baseline comparisons. Required if the baseline is specified with anything other than an alias or UUID.
-C arg - Format for contributors. {userid} expands to the user's repository ID; {name} expands to the user name; {email} expands to the user's email address; {itemid} expands to the user's repository item ID
-D arg - Format for dates. Legal values can be found in the Java SimpleDateFormat specification.
-f arg - Only show changes in the given direction. Must be one of: "i" for incoming; "o" for outgoing; or "b" for both (default).
-I arg - A combination of letters indicating which items to show - flow direction: "d"; component: "c"; baseline: "b"; work item: "w"; change set: "s"; filesystem: "f" (default: "dcbsw")
-P arg - Password for repository.
-p arg - Prune unchanged/empty items. May include: "d" for empty directions; "c" for unchanged components.
-r arg - URI specifying the location of repository.
-S arg - Indicate what optional values should be displayed. "c" causes contributor fields to be shown; "d" causes date fields to be shown; "i" causes work items to be shown under change sets.
-u arg - Username for repository.
-w arg - Root work items under a specific node type. Must be one of: "r" for root; "d" for direction; "c" for component; "b" for baseline.
page 2of 1 pagesof 2 pages