On Monday, March 6, 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.
They'd rather step on each others toes, I understand. Well, for "RCS" style
locking, have a look at 'cvs admin -l'. However, I doubt it does exactly
what they/you want/need...
> 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.
Ouch, good luck...
> 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.
Ahh, of course, since it's checked out just like the developers version,
things will be locked, thereby getting no work done. Yes, I understand,
they want an *exception*...
> I'm not sure how possable any of this is. It seems
> like what we really need is a client/server version of RCS. Anyone have
> any advice, if nothing else can someone tell me how to do the locking. I
> know this has come up before, but I don't really understand how the RCS
> lock works, nor if it still works with CVS 1.10.8.
I'm sorry, I don't know how to help you. Maybe PCVS, Aegis, SourceSafe,
or whatever other thing out there, will have what these developers think
they need...
--Toby.
