Re: Do most people checkout read-only and use "cvs edit"?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Izo <address@hidden> writes:

> Karr, David wrote:
> > I'm not talking about locking.  It's always impractical to "check out
> > with locks", in any SCM.  I'm just talking about what happens in the
> > user's client view.  I was under the impression before that "cvs edit"
> > just affects the file in the user's client view.  Does this also lock
> > the file on the server?
> 
> cvs edit is purely informational and does few things:

On the whole, your post is excellent. I'll just add a few details here
to help folks understand what is happening behind the scenes...

> 
> 1. makes the file writeable which helps in case if you have CVSREAD=yes, 
> so all files co'd read-only

A file that has had 'cvs watch add foo.c' or 'cvs edit foo.c' done to it
will be checked out by default with a umask that specifies read-only.

> 2. creates local copy of the original file into Base subdirectory on 
> local file

Yes, the local tree will have a CVS/Base/foo.c and an entry in
CVS/Baserev of a pristine copy of the currently edited version of
'foo.c' whenever a 'cvs edit foo.c' command is given. 

This is primarily an optimization used for when a 'cvs unedit' is
performed.

Note: There have been discussions that it might be useful for some
disconnected operations (or very low bandwidth connections to the
server) to let optionally allow for a CVS/Base/<file> be created as a
base for local 'cvs diff' operations as well as to do a better job of
determining if a file is locally modified or not without sending the
entire file to the server at the cost of consuming twice the diskspace
for a given tree.

> 3. creates an information in the CVS repository (I do not know where, 
> maybe only in CVSROOT/history file) which helps other users to get this 
> information, let say for coordination purposes

If the file is module/somedir/anotherdir/foo.c then the information is
recorded in the repository in $CVSROOT/
module/somedir/anotherdir/CVS/fileattr which contains information about
any watches or editors of files in both module/somedir/anotherdir and
module/somedir/anotherdir/Attic (for files that are dead on the main
trunk but alive on one or more branches).

> Reverse for cvs edit is cvs unedit, which should be called at least once 
> for every cvs edit command. Otherwise we sooner or later get the mess 
> and this information gets unuseful.

A 'cvs commit' and a 'cvs release' of the module will also undo the
'cvs edit' operation.

> So the correct purpose and procedure of using cvs edit would be:
> 
> 1. cvs editors <file_or_directory_in_question>
> 2. communicate with other editors in a way of "what is going on" and 
> decide in a way "does it and how does this all affect my intentions"
> 3. cvs edit or back-off (and wait for better time)
> 4. if cvs edit:
> 4.1. do the job
> 4.2. cvs update <file_or_directory_in_question> to get the changes that 
> the other editors did on the object
> 4.3. resolve eventual conflicts
> 4.4. cvs ci
> 4.5. cvs unedit <file_or_directory_in_question>

The final step is not needed as 'cvs ci' will do an implicit unedit for
the user and the committed file will once more be read-only if there are
any remaining 'cvs watchers' on it.

However, should the 'cvs ci' step not be done, the user should do a 'cvs
unedit' if the tree is going to be long lived. In addition, users should
get into the habbit of using 'cvs release' to remove a checked out tree
instead of just removing it from the local disk.

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFA7V2B3x41pRYZE/gRAqXzAJ9NBvHVz9DFemD1z3CHctziMf0U/wCgzfm3
FhGmMRsp9+42JsS6/4G5jfM=
=ux5l
-----END PGP SIGNATURE-----