ivanp@mc.UUCP (Ivan Peters) (05/21/91)
I am looking over CVS, a system that is a add on to RCS (a configuration management system) and I have a question I hope someone would please answer: How does CVS support (or does CVS support) dual derivations? example: If someone is deveolping on release 2, of something, and someone else is developing on release 1. How does one make release 1.1, 1.2, etc, (a branch) while allowing work to continue on 2.1 2.2? These releases contain multiple files and sub-dirs. (assume test is the top directory in the repository) One can tag a release. (cvs tag -rTEST2_0 test) One can checkout a release. (cvs co -rTEST1_0 test) One can update from a release. (cvs update -rTEST1_0 test) One can not check in a release, other than the most current. (cvs ci *) Is there a easy process that I am missing? How do others do it? I would like to avoid making a new dir under the repository for each release to be worked on if possible... Any help would be REALLY APRECIATED!!!!! Thanks in advance. :-)
cmf851@anu.oz.au (Albert Langer) (05/22/91)
In article <1991May21.135016.3671@apertus.uucp> apertus!ivanp@tenfwd.uci.com writes: >One can not check in a release, other than the most current. (cvs ci *) > >Is there a easy process that I am missing? I haven't actually used CVS yet, so this response may be quite wrong, but from my reading of the docs there is indeed an easy process that you are missing. Try using cvs ci * I think you will find that it checks in on the same branch that you checked out on, since a record of what you checked out is kept in the local admin files with your checked out source. If I haven't misunderstood the essence of what cvs is all about, then I suspect you have :-) and you need to re-read the docs free from any preconceptions about how RCS and SCCS behave. If I'm wrong then I need to do so myself and would welcome somebody pointing this out. -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
pat@bnrmtl.bnr.ca (Patrick Smith) (05/22/91)
In article <1991May22.142240.16480@newshost.anu.edu.au>, cmf851@anu.oz.au (Albert Langer) writes: |> In article <1991May21.135016.3671@apertus.uucp> apertus!ivanp@tenfwd.uci.com writes: |> |> >One can not check in a release, other than the most current. (cvs ci *) |> > |> >Is there a easy process that I am missing? |> |> I haven't actually used CVS yet, so this response may be quite wrong, |> but from my reading of the docs there is indeed an easy process that you |> are missing. |> |> Try using cvs ci * |> |> I think you will find that it checks in on the same branch that you |> checked out on, since a record of what you checked out is kept in the |> local admin files with your checked out source. |> |> -- |> Opinions disclaimed (Authoritative answer from opinion server) |> Header reply address wrong. Use cmf851@csc2.anu.edu.au Well, I haven't used CVS much myself (yet), but I've spent a while figuring out how to set it up here. It seems to me that you're far better off using separate directories for different releases. If you try to combine them in a single directory, with different RCS/CVS branches (releases), you wind up with a number of problems: First, a simple 'cvs ci' without the -r option will not work to check changes into the old release. cvs will try to commit your changes into the newest release. (If you checked the files out from the old release before making any changes, cvs won't do anything; it will just tell you that your copies are not up to date - since you don't have the latest revisions from the new release.) BUT - when you commit use the -r option, all the normal consistency checks are skipped. One of these checks for multiple updates. So if person A checks out a file from the old release, then B checks out the same file (again from the old release), makes some changes and commits the changes to the old release, and then A makes some changes and commits those, then B's changes will be lost. -- Patrick Smith Bell-Northern Research, Montreal, Canada (514) 765-7914 bnrmtl!pat@larry.mcrcim.mcgill.edu patrick@bnr.ca ... Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental.
robert@isgtec.UUCP (Robert Osborne) (05/24/91)
In article <1991May21.135016.3671@apertus.uucp>, ivanp@mc.UUCP (Ivan Peters) writes: |> How does CVS support (or does CVS support) dual derivations? |> |> One can checkout a release. (cvs co -rTEST1_0 test) |> One can update from a release. (cvs update -rTEST1_0 test) |> |> One can not check in a release, other than the most current. (cvs ci *) Hmmm, seems to be correct. I think the only way to do this is either: 1) use rcs directly 2) use the checkin script 3) change 'cvs ci' so it takes the tag just like all the other commands (ie. change the current argument -r to -F and -rTAG would check into the branch defined at that symbol) I'll look into 3), it might be fairly simple to do. If Brian Berliner is reading this maybe he has some input on this question, Brian? Rob. -- Robert A. Osborne ...uunet!utai!lsuc!isgtec!robert or robert@isgtec.uucp
ivanp@mc.UUCP (Ivan Peters) (05/24/91)
In article <1991May22.142240.16480@newshost.anu.edu.au>, cmf851@anu.oz.au (Albert Langer) writes: |> In article <1991May21.135016.3671@apertus.uucp> apertus!ivanp@tenfwd.uci.com writes: |> |> >One can not check in a release, other than the most current. (cvs ci *) ***PLEASE NOTE STATEMENT IN () |> > |> >Is there a easy process that I am missing? |> |> I haven't actually used CVS yet, so this response may be quite wrong, |> but from my reading of the docs there is indeed an easy process that you |> are missing. |> |> Try using cvs ci * ***PLEASE NOTE :-) |> |> I think you will find that it checks in on the same branch that you |> checked out on, since a record of what you checked out is kept in the |> local admin files with your checked out source. |> |> If I haven't misunderstood the essence of what cvs is all about, then |> I suspect you have :-) and you need to re-read the docs free from any |> preconceptions about how RCS and SCCS behave. If I'm wrong then I technically yes, at this point, a cvs ci * only checks in to the most current as I pointed out in the first posting, and is included in your re-post... |> need to do so myself and would welcome somebody pointing this out. |> I would suggest one re-reads a message (and ones' reply), before one posts it. :-) I do apreciate the attempt!! Two points: -The response was very short, and therefore could be misunderstood on my end. (my apologies! if true) -My original description of the problem was apparently not clear enough. (It was the best description I was able to offer at the time. But, if anyone can misunderstand something, it is not clear enough so my apologies again) I will atempt to clarify... -I do not think I am missing a basic function, I think I am missing a procedure, i.e. combination of functions. What I have done is: cvs tag -rTEST1_0 test ; marking existing for continued support ; on 1_0 cvs ci -r2.0 * ; setting up devel on 2.0 files cvs tag -rTEST2_0 test ; mark devel with a tag for easy co cvs co -rTEST1_0 test ; get ready for support on 1_0 at this point I have my problem. after some changes to test 1_0 if I try: cvs ci * it requests an update. if I try:cvs update -rTEST1_0 nothing significant changes, the following cvs ci * will still request an update before proceding. if I try:cvs update it will default to most current, and once more merge me with 2_0, the TEST2_0 files, which I do not want yet. if I try a file by file checkin on the 1.* revision level files, cvs ci -r1.5.1.1 xx.c (with the requirement to tag each file revision ) cvs does not appear to keep track of these revisions, it gives one a WARNING that it will bypass all consistency checks whenever cvs ci -r is used. This does not allow a update sequence at any level other than the top. Which leaves me with... how can one branch, to do support, on files previeous to ones most current/development track? a seperate dir for support and devel under the repository is not very desireable (but I would like to know if it is the only way people have done it) for two reasons: -ones' support repository/dir is a duplicate of ones' devel repository/dir (to a major extent) -merging between the two can easily become a problem. I think that this info would be useful for anyone tring to use CVS and RCS for a configuration management system. Any help/suggestions would be APRECIATED!! I don't think this is a trivial problem... (Though I hope it is)
wolfe@dds4.uucp (Peter Wolfe) (05/24/91)
In article <1991May21.135016.3671@apertus.uucp> apertus!ivanp@tenfwd.uci.com writes: >I am looking over CVS, a system that is a add on to RCS (a configuration >management system) and I have a question I hope someone would please answer: > >How does CVS support (or does CVS support) dual derivations? > This is a topic worth doing some surveys on. Come on folks - how do you take care of multiple derviations of common source using CVS/RCS/SCCS (I know that you can throw money at Configuration Management vendors to do this). In a past life I cobbled together massive CSH/SCCS scripts to support this. Each release had a directory tree and a configuration file indicating which version (R.L.B.S or R.L) it was using. The sccs get command would use the R or R.L.B to fetch the latest copy. You could link releases together so that changes to common source would propogate. One distinction between SCCS and RCS is the time when you indicate what version you wish to checkin. SCCS requires you to identify at checkout time the version (e.g. a new branch) you are creating while RCS only allows this at checkin time. -- Peter Wolfe (604-270-1171) uunet!van-bc!dds4!wolfe Digital Dispatch Systems, Richmond BC Canada
phjm@fairfax.fairfax.com (Phillip Merrick) (06/05/91)
In article <1991May23.201749.20336@dds4.uucp> wolfe@dds4.uucp (Peter Wolfe) writes: >This is a topic worth doing some surveys on. Come on folks - how do you >take care of multiple derviations of common source using CVS/RCS/SCCS (I >know that you can throw money at Configuration Management vendors to do >this). [I am cross-posting this to comp.unix.programmer and comp.unix.misc since I have noticed some related questions on multiple derivations there recently also. Disclaimer: I know little about CVS - it may be that CVS can do all the stuff I'm describing already.] For several years now I have been handling multiple versions/releases of source files with the following configuration management model imposed over RCS. With some help from colleagues, I originally put this in place on a moderately large (~ 650 KLOC) project at the point at which we made our first release (where new development and release maintenance diverge). The model and the tools supporting it have been deployed on several other projects since then. The primary aim of the model is to support this (very common) scenario: - Version X has been released - New development proceeds - We need to fix version X, and re-release it - We want to merge the fix forward into development The basis of the model is the use of an RCS branch for each version of the software in question, and the replication of the same branching structure across all the project RCS files. Establishing new branches uniformly across files is achieved with 'bogus' check-ins. These bogus check-ins are assigned revision numbers ending in '.0' to distinguish them from real revisions to the source file. An RCS symbolic name (the version name) is assigned to each branch, in every file. By assigning symbolic names to entire branches (e.g. VER1 --> 1.0.0) it becomes very easy to access the most recent revision along a particular branch (e.g. co -rVER1). An 'rlog -rVER1' will show only revisions made to that branch. The trunk is where new development takes place. When it comes time to make a new major release, we check out the latest trunk revisions and check them in on a new branch, to which we assign a suitable RCS symbolic name. The RCS files conceptually look something like this: 0.0--0.X-->1.0------1.X---> "DEV"- - - - - - - --->2.0--------2.X-----> "DEV" | | | | 1.0.0.0---1.0.0.X--> "VER1" 2.0.0.0------2.0.0.X--> "VER2" This shows two major releases ("VER1" and "VER2"), with new development continuing along "DEV". Note that the files are intially created at "0.0" - purely to free up "1.0" as a suitable branch point for the first major release. Note also that further derivations from (say) 1.0 are possible, and would be represented as additional branches numbered 1.0.1.X, etc. Now, assume that a bug occurs in VER2. The programmer checks out the most recent revision to VER2, makes the fix, and checks it back into VER2. The programmer then locks DEV, does an rcsmerge of the fix from VER2, and (after conflict resolution and verification) checks back into DEV. Of course, the bug could easily have been detected and fixed in VER1, then merged forward into VER2 and DEV. This becomes particularly convenient when a fix spans several files. Minor 'maintenance' releases of bug fixes are made by taking a snapshot of the version in question. For the RCS files, this just entails tagging the most recent revision (e.g. 1.0.1.5) with an appropriate RCS symbolic name (eg. "VER1.a"). This model is used in conjunction with parallel directory trees of checked out source files. The RCS files live in their own tree, with checked out source files in parallel source trees. In the filesystem, it looks something like this: projdir | +---------------+--------------+---------------+ | | | | VER1 VER2 DEV RCS / | \ / | \ / | \ | src bin lib src bin lib src bin lib src The src subdirectory can be an arbitrarily deep directory hierarchy. It is consistent across each version tree. Each branch in the RCS files "feeds" the src subdirectory of the corresponding version tree. Each version tree holds the most current source for that version. Past maintenance releases (or 'snapshots') can also be checked out into their own parallel tree, when necessary, Programmer's work directories can be organised along similar lines to the version trees (but generally will be a subdirectory of src). This model is basically derived from ideas gleaned from Andy Glew's excellent "Boxes, Links and Parallel Trees" paper in the proceedings of the April '89 Usenix Software Management Workshop. Needless to say, managing all of the above requires a fairly high degree of automation. Hence I have developed my own obligatory 'wrappers over RCS'. These wrappers have gradually evolved into something approaching a full configuration management toolset (written in C and shell scripts). It bears the name 'FCMtools' and in addition to implementing the model described above can also provide: + Management reporting: e.g. tell me all the changes to version X since 1/6/91; show me the configuration for release M.n. The reports include the obvious things plus the RCS log comments entered at check-in time. Another report makes it easy to track down who has what files locked. + Name lookup: an RCS file locator mechanism allows the user to simply provide enough of the pathname to uniquely identify a source file. (eg. fcmout file.c, or fcmout dir/file.c). This works in conjunction with an environment variable that specifies a target hierarchy for the checked out file. Name transformation is almost mandatory given the parallel trees layout, unless you like typing long pathnames. + Tools to manage the parallel version trees. A tool named 'fcmcollect' can update a version tree with all the changed revisions from the corresponding RCS branch. This allows easy integration with make (just run fcmcollect as the first step in the build). 'fcmcollect' only checks-out new revisions: it doesn't get triggered by changes in the modification date or by RCS lock operations. 'fcmcollect' also knows how to mirror the RCS hierarchy by creating new directories as they appear, deleting obsoleted files, etc. + Ability to setup a programmer's work area (usually some subtree of the whole src hierarchy) with one command (fcmcollect, again). + Simplified merging. Amongst other things, overlaps can be flagged with the version names (instead of the revision numbers). + Administrator functions: versions can be individually protected against one or more of check-in, check-out with lock, or selection for a merge operation. This helps during release preparation. A per-project setup file is used for specifying file location, RCS file structure and characteristics of the various source file types. + An RCS file creation utility. You can use it to install new files into one or more versions - it will set up the branches and symbolic names as necessary. It keys into the setup file on the source file suffix to determine how to initialise the RCS file. Also, it will insert a predefined file header (can vary by file type) containing a standard set of comments (e.g. copyright notices) and RCS macros ($Date$, $Revision$, $Log$, etc.) If you have persisted this far, you might be wondering if I'm planning on making FCMtools generally available. The package needs a minor clean-up and (more importantly) improved documentation. I also need to get a hold of RCS 5.5 and verify that it all still works! When I get that done - I'm guessing 4-5 weeks from now, real work permitting - I'll post to alt.sources. If you are really eager, send me email and we can take it from there. Oh, it currently runs on several Sys V.3 boxes - but it started life on a BSD based system and has acquired only a couple of Sys-Visms along the way. Hope this helps somebody! -- Phillip Merrick | Domain: pmerrick@fairfax.com Fairfax Software Corp., Fairfax VA | UUCP: uunet!fairfax!pmerrick