Ben Leibig wrote:
>
> Well, I've tried as hard as I can, but I can't convice our developers that
> RCS locking is not necessary when using CVS. They're all old school, and
> they don't trust CVS's ability to merge, nor do they claim they need it.
If they don't need it, then they're never trying to work on the same
file
at the same time, so they don't need locks. But I digress....
> THey do however want the whole remote repository ability, which means I'm
> in a hard spot. I need to figure out how to provide locking (every file
> gets locked everytime it is checked out and unlocked everytime it is
> commited.) Using CVS, or to provide a remote repository system using RCS.
Nope, not in CVS. If these are hard requirements, you'll have to try
to find something else that's going to work.
The "cvs watch" facility could be used. If you have "cvs watch on",
then files are checked out into the developer's directory in read-only
mode. The developers will then use "cvs edit" to unlock the files.
You may want to look into Noel Yap's "cvs edit -c" patch.
This is, in my experience, the most restrictive form of locking that
makes sense. It is easy to subvert, but, then, so are more restrictive
locks.
> Actually the developers even want to have a copy of the checked out source
> all running in one directory on one of the UNIX servers. When they check
> out they want the file's permissions in that directory to change so they
> can access it untill the check it back in, then they want it to go to read
> only for everyone.
The proposed procedure will provide multiple copies, one for each
developer, and each directory will have only the appropriate files
read/write. This isn't what the developers are asking for, but it's
the best CVS is going to do.
It also strikes me as a lousy way to work, since you're working in
an environment where you can't control changes. If a guy who's working
on a header file goofs and goes to lunch, you can't compile in that
directory until after his lunch. In the CVS environment, you get
only checked-in changes, and only when you ask for them. Not quick
hacks that don't quite work yet whenever.
I'm not sure how possable any of this is. It seems
> like what we really need is a client/server version of RCS.
You need more than that, I'd think. I really doubt that there is
a system that'll do exactly what you've stated without a lot of
customization.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
