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
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.
Comments
Michael Taylor
Apr 18 '14, 11:02 a.m.Any thoughts about these questions?
sam detweiler
Apr 18 '14, 11:46 a.m.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.
Tim Mok
JAZZ DEVELOPER Apr 21 '14, 8:47 a.m.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.