Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

RTC version ID, snapshots, baselines, streams and recommended SCM approach

Questions
Tags
Users
Badges
Michael Taylor
(88●6●57●64) Apr 17 '14, 6:27 p.m.

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.

0 votes

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.

2 answers
8,876 views
0 votes

2 answers

Permanent link
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Apr 18 '14, 10:52 p.m.
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.

1 vote

Permanent link
Davyd Norris
(202●2●10●14) Apr 20 '14, 10:21 p.m.
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.

0 votes

Your answer

Register or log in to post 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,143

Question asked: Apr 17 '14, 6:27 p.m.

Question was seen: 8,876 times

Last updated: Apr 21 '14, 8:47 a.m.

Confirmation Cancel Confirm