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.

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:

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 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:

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

Yes, you can use the Jazz SCM command line to efficiently update your
file area.

Cheers,
Geoff

jasuk70 wrote:

gmclemmwrote:
Just for interest's sake, why are you writing code to do this?
It is built-in functionality of the Jazz SCM system.

Cheers,
Geoff



Can it be done from the command line?

We need to use this in our build process. (Which is done using
makefiles on multiple Unix and windows platforms using the same
source code)

Cheers,

Jas

Just for interest's sake, why are you writing code to do this?
It is built-in functionality of the Jazz SCM system.

Cheers,
Geoff

jasuk70 wrote:

adhoowrote:
Unfortunately I think you have to work from the other end, start with
the
workspaces/streams and then fetch baselines from them, if you know
of the
set of workspaces/streams/snapshot that you want to inspect.


Thanks,

I know the stream name, I need to iterate through the components in
that stream and then compare using the baselines. (I.e. I know the
baseline name will start with certain characters and and then if it
exists, I then need to check the previous baseline and see what has
changed.)

If that makes sense.

We use this information to create an update package to allow users to
only update the relevant components. Under perforce this was a very
simple task that used the command line tool p4.

Any tips on doing the "Iterate through components in a
stream" bit that should get me well on the way.

Thanks again for the help,

Jas

Here's a thread that shows a couple of ways to get a list of changeSets by comparing two baselines.

http://jazz.net/forums/viewtopic.php?p=22460

I didn't find the baselineQueries very easy to use...maybe I was just using them wrong. The query would just return 25 or so and I wanted all of them. So I just get a list of all the baselines and then grab the baseline id that I'm looking for or sort them and grab the latest one.

List<IBaseline> baselines = this.workspaceMgr.findAllBaselines(component, "", this.monitor);

Unfortunately I think you have to work from the other end, start with the
workspaces/streams and then fetch baselines from them, if you know of the
set of workspaces/streams/snapshot that you want to inspect.

On Wed, 02 Dec 2009 12:23:00 -0500, jasuk70
<jdean> wrote:

The main thing I'm trying to work out is how to use the
"Searches" to find baselines (And snapshots) linked to a
stream or a component within a stream.


IWorkspaceManager wm =
SCMPlatform.getWorkspaceManager(teamRepository);
IBaselineSearchCriteria search =
IBaselineSearchCriteria.FACTORY.newInstance();
search.????
List<IBaselineHandle> baselines =
wm.findBaselines(search, 0, null);
for (Iterator<IBaselineHandle> baseline =
baselines.iterator() ; baseline.hasNext(); )
{
System.out.println("Baseline =
");
}


The search doesn't seem to have any understandable methods to do
this.

Cheers,

Jas

--