Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!usc!cs.utexas.edu!uunet!yale!mfci!bronson
From: bronson@mfci.UUCP (Tan Bronson)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <919@m3.mfci.UUCP>
Date: 28 Jun 89 17:22:36 GMT
References: <791@redsox.bsw.com> <357@umigw.MIAMI.EDU> <1625@zen.co.uk>
Sender: news@mfci.UUCP
Reply-To: bronson@mfci.UUCP (Tan Bronson)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 67

In article <1625@zen.co.uk> vic@zen.UUCP (Victor Gavin) writes:
]In article <357@umigw.MIAMI.EDU> steve@umigw.miami.edu (steve emmerson) writes:
]>In article <791@redsox.bsw.com>, Larry Campbell <campbell@redsox.UUCP> 
]>describes a possible methodology for configuration management using the
]>"state" attribute of individual RCS files.
]>
]>It would be better, IMHO, to increment the release level (i.e. "state")
]>of all other modules --- regardless of the difficulty of doing so.
]
]I've been waiting for someone else to mention this, but since no one has come
]forward...
]
]What's wrong with named versions?
]
]Just "rcs -nVersion_1 RCS/*" (or use rcsfreeze, which checks in your files
]for you as well), and everything has a consistent ``name'', you no longer
]have to keep each file at the same revision code or make unwieldy abuse of
]features designed for other uses.
]
    The advantage of marking every file is it's trivial to branch.
Usng only symbolic names means that when you need to create a branch
you can potentially have a to:
	find all names which point to that branch point
	create the new point where that branch will work from (RCS does this)
	create new points for the other symbols.
    Here are a few examples which describe what I'm trying to say above:

    The first branch is easy (for Ckp1), note that only Ckp1 is affected.

    Before: Head:1.1; Ckp1:1.1 Ckp2:1.1 Ckp3:1.1
    After:  Head 1.1; Ckp1:1.1.1.1 Ckp2:1.1 Ckp3:1.1

    The next branch is messier (for Ckp2), as we'd like to keep a 
separate branch for Ckp2 (see below)
    Before: Head 1.1; Ckp1:1.1.1.1 Ckp2:1.1 Ckp3:1.1
    After:  Head 1.3; Ckp1:1.1.1.1 Ckp2:1.2.1.1 Ckp3:1.3

    Alternatively one could make Ckp2:1.1.1.1.1, but requires
Ckp1 to be changed to Ckp1:1.1.1.2 to keep RCS `branching automatically'
(see below)

    If one creates a new `RCS revision' for every version, the resulting 
RCS looks something like this:
    Head 1.4; Ckp1:1.1 Ckp2:1.2 Ckp3:1.3

    This is revision wasteful, but you can now `co -lCkp1' and when you
check in the file a branch will be created automatically by ci.

    My configuration management package uses the later mechanism now,
but people object to revision number changing when nothing has changed,
so I've been trying to figure out how one could do `delayed' branching.

    Has anyone solved the general case? Delayed branching is great for
code which stays the same, but but once you have to do the delayed
branch it's a mess. Maybe that's the time to something like:

    Before: Head:1.1; Ckp1:1.1 Ckp2:1.1 Ckp3:1.1
    After:  Head 1.4; Ckp1:1.1 Ckp2:1.2 Ckp3:1.3

    and of course this can be further complicated by the existance of
other branches and revisons.

    any ideas? (I want to live within the framework of RCS)
Tan Bronson
Multiflow Computer Inc  UUCP(work): {yale,uunet}!mfci!bronson 
30 Business Park	UUCP(home): {yale,mfci}!bronson!tan 
Branford, Ct 06405	Phone(work):(203)-488-6090