jasuk70 wrote:

In perforce we use the following:

p4 changes -m1 ...

In a directory which will give us the last change which was done on
this directory and we use that change number in our build mechanism.

Does it report when the last change happened? Or do you need more
information about exactly what the change was?

I am looking for something similar in RTC's SCM preforably with the
command line tool although we could use the API to get the
information.

In Jazz SCM, determining when the contents of a directory last changed
is a lot harder than you might think. (See work item 2376 if you want
all the gory details.)

Look at the "scm lastmod" command, or the teamLastModified Ant task.
The essentially tell you when a directory last changed. But they come
with a number of limitations, so use with care.

jasuk70 wrote:

This is the information it shows:

hpi2-~/src/TAFC/2008_PATCH: p4 changes -m1 ...
Change 85364 on 2009/10/22 by *****@***** 'QA Coverage Program to test
jtr'

What we use is the Change Number 85364 in this case to put information
into our compiled code to show what the last change was that went into
a release before it was built.

So looking at binaries in the future we can use this number to get the
exact source used for that release.

e.g. in perforce

p4 sync -f ...@85364

Would make the depot match the code used in that release.

We need to do something similar with RTC.

It seems that your real goal is to recreate the source code that was
used for a release. That's possible with RTC, but the mechanism to do
it will be completely different.

When you run a build from RTC, a snapshot is usually created. If you
can find the right snapshot, it is trivial to create a new repository
workspace that has the exact contents of that snapshot. The trick is
recording the snapshot that was used for a release build. The usual
technique is to mark the RTC build result with a tag (so it is easy to
find) and prevent it from being deleted. If you have the build result,
it is trivial to find the snapshot that is associated with it. It might
be possible to also embed the snapshot ID into the compiled code; I have
never attempted that.