Concurrent edits of different SID

The ability to retrieve different versions of an SCCS file allows several deltas to be in progress at any given time. This means that several get -e commands may be executed on the same file as long as no two executions retrieve the same version (unless multiple concurrent edits are allowed).

The p.file created by get -e is created in the same directory as the SCCS file, given mode 644 (readable by everyone, writable only by the owner), and owned by the effective user. It contains the following information for each delta that is still in progress:

• the SID of the retrieved version

• the SID given to the new delta when it is created

• the login name of the real user executing get

The first execution of get -e causes the creation of p.file for the corresponding SCCS file. Subsequent executions only update p.file with a line containing the above information. Before updating, however, get checks to assure that no entry already in p.file specifies that the SID of the version to be retrieved is already retrieved (unless multiple concurrent edits are allowed). If the check succeeds, the user is informed that other deltas are in progress and processing continues. If the check fails, an error message results.

It should be noted that concurrent executions of get must be carried out from different directories. Subsequent executions from the same directory will attempt to overwrite the g-file, which is an SCCS error condition. In practice, this problem does not arise because each user normally has a different working directory. See ``Protection'' for a discussion of how different users are permitted to use SCCS commands on the same files.

``Determination of new SID'' shows the possible SID components a user can specify with get (left-most column), the version that will then be retrieved by get, and the resulting SID for the delta, which delta will create (right-most column). In the table

• R, L, B, and S mean release, level, branch, and sequence numbers in the SID, and m means maximum. Thus, for example, R.mL means the maximum level number within release R. R.L.(mB+1).1 means the first sequence number on the new branch (maximum branch number plus 1) of level L within release R. Note that if the SID specified is R.L, R.L.B, or R.L.B.S, each of these specified SID numbers must exist.

• The -b keyletter is effective only if the b flag (see admin(CP)) is present in the file. An entry of - means irrelevant.

• The first two entries in the left-most column apply only if the d (default SID) flag is not present. If the d flag is present in the file, the SID is interpreted as if specified on the command line. Thus, one of the other cases in this figure applies.

• R.1 (the third entry in the right-most column) is used to force the creation of the first delta in a new release.

• hR (the seventh entry in the fourth column) is the highest existing release that is lower than the specified, nonexistent release R.

Determination of new SID

SID specified in get	-b keyletter used	Other conditions	SID retrieved by get	SID of delta to be created by delta
none	no	R defaults to mR	mR.mL	mR.(mL+1)
none	yes	R defaults to mR	mR.mL	mR.mL.(mB+1).1
R	no	R > mR	mR.mL	R.1
R	no	R = mR	mR.mL	mR.(mL+1)
R	yes	R > mR	mR.mL	mR.mL.(mB+1).1
R	yes	R = mR	mR.mL	mR.mL.(mB+1).1
R		R< mR and R does not exist	hR.mL	hR.mL.(mB+1).1
R		Trunk successor number in release > R and R exists	R.mL	R.mL.(mB+1).1
R.L	no	No trunk successor	R.L	R.(L+1)
R.L	yes	No trunk successor	R.L	R.L.(mB+1).1
R.L		Trunk successor in release R	R.L	R.L.(mB+1).1
R.L.B	no	No branch successor	R.L.B.mS	R.L.B.(mS+1)
R.L.B	yes	No branch successor	R.L.B.mS	R.L.(mB+1).1
R.L.B.S	no	No branch successor	R.L.B.S	R.L.B.(S+1)
R.L.B.S	yes	No branch successor	R.L.B.S	R.L.(mB+1).1
R.L.B.S		Branch successor	R.L.B.S	R.L.(mB+1).1