RTC version ID, snapshots, baselines, streams and recommended SCM approach
My previous research of RTC source code management has concluded that RTC intentionally does not want to think in terms of source file version IDs. But now according to this (https://jazz.net/downloads/rational-team-concert/milestones/5.0M4?p=news#version-identifier-feature) the capability is coming. This may actually help us finally migrate all our source code management processes to RTC! Considering this (https://jazz.net/forum/questions/88668/uuid-human-readable-form-now-really-needed) and specifically Andrew Trobec's comments in this questions/answer, is the concept of version ID and using it to manage source files going to become mainstream in RTC? Given all this, what is the recommended way to use RTC to manage source files? In our current situation, we have requirements to track the approved version of source files that link to approved work items, report on the source file and version differences between environments, and to maintain baselines/snapshots of the list of source files and version in an environment at a given time and to compare and list differences between the environments. |
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 18 '14, 10:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
All of the operations identified in this question can be performed without the use of readable version identifiers. The reason readable version identifiers have been added to RTC is to satisfy customers who either want, or are required, to use processes based on readable version identifiers, rather than the (simpler) RTC processes that do not require them.
|
Have to say I wholeheartedly agree with Geoff. It almost seems like a major regression going back to version numbers on files after working without them for so long.
I guess old habits die hard, and people hang on to what they feel comfortable with, but it's true - everything you have mentioned here and more is done just as easily, if not more so, without the need for version numbers on anything. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Any thoughts about these questions?
my opinion.. RTC is designed around changes, not Files (and thus no file dates, etc). Workitems are linked to change sets, not files.
with the introduction of the net version (instance after result of changes applied)
you have a pseudo version number.
given the existing system you can get the list of files affected by the change sets in a build/snapshot/baseline.
I definitely recommend using work items to approve changes. There are delivery preconditions that can prevent delivery if the changes aren't approved. Builds create snapshots so you can compare them to track differences. The work items listed in the difference can show the approvals.
If your process still requires version identifiers, you can still use them. There is no extra setup required to enable this.