UUID - human readable form now really needed
Hi RTC world -
I read this article about how to generate a BoM from the command line ( https://jazz.net/library/article/978 ). While the article is good and very useful, the output of the identifier and version as a UUID is very difficult to explain. Sure, I understand what it is, but it is extremely hard to read. In this world where everyone finally understands what "2.0" means, to start using a convoluted identifier like the UUID in its raw form is just plain wrong. Ok - so IBM wants to push the edge by using version control where the version number itself doesn't matter - but how do you identify the version itself without a number? (Someone suggested to us once to use the date/time stamp - and we respectfully declined to step back 25 years in CM evolution.)
The article I mentioned above helps us so much to satisfy a need, but the output of the UUID as the version indicator is just not a good idea. I would love to see the result as a real number, or even a plug-in or script to convert the UUID to a real number. Even any further information about how to figure out the version number from the UUID would be nice. I
It would be greatly helpful in RTC 4.0.
Thank you!
I read this article about how to generate a BoM from the command line ( https://jazz.net/library/article/978 ). While the article is good and very useful, the output of the identifier and version as a UUID is very difficult to explain. Sure, I understand what it is, but it is extremely hard to read. In this world where everyone finally understands what "2.0" means, to start using a convoluted identifier like the UUID in its raw form is just plain wrong. Ok - so IBM wants to push the edge by using version control where the version number itself doesn't matter - but how do you identify the version itself without a number? (Someone suggested to us once to use the date/time stamp - and we respectfully declined to step back 25 years in CM evolution.)
The article I mentioned above helps us so much to satisfy a need, but the output of the UUID as the version indicator is just not a good idea. I would love to see the result as a real number, or even a plug-in or script to convert the UUID to a real number. Even any further information about how to figure out the version number from the UUID would be nice. I
It would be greatly helpful in RTC 4.0.
Thank you!
Accepted answer
4 other answers
Donna,
Search the work items for "audit" and you will find several more, for example https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=203884 where you could add your support. Comment the work item or the one David mentioned to support it.
In general I would suggest to create an enhancement request for things like this here: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem or look for a similar one and support it. Just providing a statement here does not have a lot of impact.
Search the work items for "audit" and you will find several more, for example https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=203884 where you could add your support. Comment the work item or the one David mentioned to support it.
In general I would suggest to create an enhancement request for things like this here: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem or look for a similar one and support it. Just providing a statement here does not have a lot of impact.
Hello,
I know this is an old thread but I have two cents to add. After working with a number of RTC based engagements I find that it is easier to use baselines as a means to identify versions. This is because many in-between file versions are irrelevant. At the end of the day I want to know the latest stable version of a file or the latest deployed version of a file rather than just the number of the version. This is also because a file in itself is useless without knowing what relationship it has to the rest of the system. In a massively complex system what use is it to know that version 34542 of file X is included in release 4? What if you have a million files and they all have similar version numbers? What do you do with that information? RTC extracts that complexity and assures you that you are keeping track of the relationships between those files. If you want you can trace the changes to work items to get a bigger picture.
RTC best practices promote constant baselining which is something that wasn't done as much with ClearCase. This allows constant increments and continuous platforms for being able to compare.
Regards,
Andrew
Comments
Just FYI - I agree in the sense that baselines are extremely important (in general CM concepts and in RTC). And they are important for at least the reasons you give.
Just FYI - I agree with you on many points about baselines (in general CM concepts and in RTC). However, in our industry individual files are just as important as groups of files for release. The government standards that we must adhere to require us to report on individual files as well as a whole.
Hello Donna,
just out of curiosity what are some of the standards that require you to track the versioning of each individual file? It would be insane to have to report on something like the average number of check-ins per file for a specific release...
For traceability related issues I have found it vitally important to use the RTC work items and a strong stream strategy.
Regards,
Andrew
I agree with a strong work item and stream practice. (Vital!) We are required to report the version number of each file for the release in a VDD. They don't like the funky-long alpha-numeric that RTC can produce. And they don't give me the time to develop a script to calculate the actual version number. (1, 2, 3, etc).
What I have seen done to keep track of the versions is to use a combination of user id and deliver timestamp. The timestamp taken is the one that refers to when the changeset is delivered to the main stream.
I guess the part up for interpretation is what a "version" means. For me the baseline label would suffice. It also makes tracking groups of files a lot easier. Instead of, for example, saying that release 123 contains version 15 of file X, version 27 of file Y, and version 56 of file Z, I just say release 123 contains version 20140418 of all files.
For a more complex system I would say release 123 contains baseline 20140418 for component Front-End, baseline 20140213 for component Logic, and baseline 20131220 of component Data. A snapshot would keep these relationships for me.
Comments
Seth Packham
FORUM ADMINISTRATOR / JAZZ DEVELOPER Sep 21 '12, 1:41 p.m.Hi Donna, I'm not sure what your question is here.