ilan343@violet.berkeley.edu (03/07/90)
I have been using RCS to keep track of changes to software involving a large number of modules (30-40). I am looking for suggestions on how to organize the releases of the complete software configuration. How do I treat the whole package as a single unit? I'd like to give it a revision name( or number in the X.XX.XX format). Also, I'd like use this name inside the code, as I can with keywords like $Header$ for each individual module. I know of "symbolic names", but they seem somewhat inflexible. From what I understand, the symbolic names are associated to just the revision number itself, but not to the level number, or branches. Any comments on how to effectively use RCS (or other revision control packages) would be appreciated.
khera@juliet.cs.duke.edu (Vick Khera) (03/08/90)
In article <1990Mar6.195640.26473@agate.berkeley.edu> ilan343@violet.berkeley.edu writes: > [ ... ] >I'd like to give it a revision name( or number in the X.XX.XX format). >Also, I'd like use this name inside the code, as I can with keywords >like $Header$ for each individual module. Try using the RCS state. this can be set with "rcs -s<state>:rev" and then expanded in the source files with $State$. you can also check out files based on the state. check out the man pages on rcs and co. >I know of "symbolic names", but they seem somewhat inflexible. From >what I understand, the symbolic names are associated to just the >revision number itself, but not to the level number, or branches. > [ ... ] symbolic names refer to the revision *or* branch specified. check the man page for rcs. i do not believe you can get this information into the source file, though. v. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vick Khera Department of Computer Science ARPA: khera@cs.duke.edu Duke University UUCP: ..!{mcnc,decvax}!duke!khera Durham, NC 27706
runyan@hpcuhc.HP.COM (Mark Runyan) (03/15/90)
This may be late and too long for most... >/ ilan343@violet.berkeley.edu / 11:56 am Mar 6, 1990 / >I know of "symbolic names", but they seem somewhat inflexible. From >what I understand, the symbolic names are associated to just the >revision number itself, but not to the level number, or branches. Perhaps you have a clear understanding of symbolic names and they don't meet your needs, but let me add to the confusion. A symbolic name can made into a pointer to a revision, a level, a branch, or a twig. For instance "-NA_SYM:1.1" will point A_SYM at revision 1.1 and just revision 1.1, but "-NA_SYM:1" will point A_SYM at the highest 1.x revision. It will float along the top of the 1.x versions. If you use "-NA_SYM:1.2.3.1" you point at just one revision (this is what I call a 'fixed' symbol). However, "-NA_SYM:1.2.3" points at the top of the branch 1.2.3. If you have revisions 1.2.3.1, 1.2.3.2, and 1.2.3.3, using A_SYM will recover 1.2.3.3. If you add 1.2.3.4, then A_SYM will point to 1.2.3.4 (this is what I call a `floating' symbol). You can recover a specific branch revision with A_SYM set to 1.2.3, by using "-rA_SYM.x", where x is 1, 2, 3, or 4. (e.g a "ci -rA_SYM.2 file,v" will recover version 1.2.3.2. The symbolic name can be seen as a sort of `macro' replacement. Now if you have product numbers, like A.BB.CC, you can set your symbolic revision names A, BB, and CC for each file. You don't have to keep levels artificially set, but you can allow the symbolic names to tie the product together. For instance, for three files (remember that '.' can't be in a symbolic name, so you might use '_' instead): -------------------. 2.2 4.1 1.5 | Version A.B1.00 of your product could be made up of 2.1 3.1 1.4 | versions f1(1.1), f2(1.2), and f3(1.3). You could 1.3 2.1 1.3 | could set A_B1_00 to point to 1.1 for f1, 1.2 for f2, 1.2 1.2 1.2 | and 1.3 at f3. If a patch is added to f3 at 1.3.1.1, 1.1 1.1 1.1 | you can set A_B1_01 to point to 1.1 for f1, 1.2 for f1 f2 f3 | f2, and 1.3.1.1 for f3. This allows you to ignore -----FILES---------' what the actual revisions were and assigns a value that can be followed through the all the files in the produt. A later version of your product A_B3_00 could be set to point to 2.2 for f1, 4.1 for f2, and 1.2 for f3 (in case you have to back out several changes :-) ). Now none of this may address your question, in which case, I apologize... Mark Runyan