Leisner.Henr@xerox.com (Marty) (02/01/89)
We're currently using RCS (actually MKS RCS on Ms/Dos) to manage a software project with about 10 subdirectories and 150 files producing about 10 different executables/libraries in our system. We're using RCS to track versions during development and it works effectively. What we want to accomplish is: 1) an automatic way of generating a release where a common ident string reflects the release level (this isn't revision numbers of each source file) -- only one magic release string should be generated per delivered binary. 2) What's the best way to extract the source code components of a release at a later date. It seems we can extract by date, symbolic name (assuming one's assigned at release creation). 3) Do we want to use the first digit of the revision number to make each release? This seems somewhat awkward, but will work to a limited extent. So release 1.0 will contain revisions 1.xx, release 2.0 will consist of versions at the 2.xx level, etc. Any better ideas? We have access to RCS on Unix-based machines also so we aren't limited to DOS-only ideas. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
dce@stan.UUCP (David Elliott) (02/02/89)
In article <18261@adm.BRL.MIL> Leisner.Henr@xerox.com (Marty) writes: > 1) an automatic way of generating a release where a common ident string >reflects the release level (this isn't revision numbers of each source >file) -- only one magic release string should be generated per delivered >binary. At MIPS, the compiler driver was modified so that during the link step, the last file loaded was always named by the environment variable RLS_ID_OBJECT. Before starting the build for a release, an object file was created containing two strings: one for RCS's ident command, and one for SCCS's what command. For example, the C source might be static char *RCSid = "$Header: UMIPS 3.10 mips$"; static char *SCCSid = "@(#)UMIPS 3.10 mips"; A MIPS customer (starting with release 3.0) can use either what or ident to see what release the binary came from. An OEM can recompile the commands with a different set of strings. A source customer will probably not use this feature. The result is that MIPS's customer support folks can figure out who made the binary when a bug gets reported, and possibly find bugs created outside of MIPS instead of wasting time reproducing a "non-bug". > 2) What's the best way to extract the source code components of a release >at a later date. It seems we can extract by date, symbolic name (assuming >one's assigned at release creation). Symbolic revision names are your best bet, though can always ident each source file at release time and build one big database of file->revision number mappings and use that. > 3) Do we want to use the first digit of the revision number to make each >release? This seems somewhat awkward, but will work to a limited extent. >So release 1.0 will contain revisions 1.xx, release 2.0 will consist of >versions at the 2.xx level, etc. This is up to you, and it's all a matter of taste. You need to decide whether your internal policies match your release policies. Personally, I would rather work in an environment where nobody tells me what revision control system to use, and doesn't design release systems around the revision control system. After all, if you have to release source, there's a good possibility that your source customers use a different system, and your data won't do them any good. -- David Elliott ...!pyramid!boulder!stan!dce "All he wanted was a Pepsi, but I wouldn't give it to him!" -- Mike's mom
runyan@hpirs.HP.COM (Mark Runyan) (02/03/89)
>/ Leisner.Henr@xerox.com (Marty) / 10:19 am Jan 31, 1989 / >What we want to accomplish is: > 1) an automatic way of generating a release where a common ident string >reflects the release level (this isn't revision numbers of each source >file) -- only one magic release string should be generated per delivered >binary. Instead of using $Release$, maybe you could use $State$. That way, revisions and version numbers are not directly tied to any particular release, but the State variable could be used to define a release. Specifically, the problem I'm suggesting that you avoid is the need to check in "Null-change" revisions just because you are releasing a new product. (FileA has been changed from release 1 to release 2, but FileB hasn't. Therefore, to make both FileA and FileB have an ident string with the "2.xx", you would have to check in a revision for FileB which is exactly the same as the "1.xx" version.) Mark Runyan