Hi all,

This is my first post. Its glad to meet you all through this post.

In a typical RCS Setup

i (user1) added a file in RCS say hello.c using ci hello.c

when i checked out i got it (hello.c) as it is ( COOL ) co -l hello.c

Also I released the lock using co -u hello.c ( I am not sure this is
correct )

when another person say user2 tried to check out or check in using co
-l hello.c or ci -l hello.c

it says Permission denied.

Pls help me out ...

Regards
Prince

princeofcode@gmail.com wrote:

It isn't; it simply checked the file out a second time without releasing
the other lock.


Releasing the lock requires either a check-in (which will be a no-op -
apart from releasing the lock and deleting the source - if you've not
changed the file), or 'rcs -u'.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

Sorry I m not clear with your thoughts.

Can u pls elobrate me

Thx for your Response

Looking Forward
Prince
Jonathan Leffler wrote:

princeofcode@gmail.com wrote:

I will try - there isn't much more to say, so mostly it will repeat what
was said before, albeit slightly differently since I didn't get the idea
across first time.



When you did 'co -u', you did not release the lock.
What you did was simply check out the file without locking it.


There are two ways of releasing the locks - one that intentionally
unlocks it, and one that does so mostly accidentally.

The intentional way is 'rcs -u' (and 'rcs -l' would lock the file if it
was currently unlocked). If you want to unlock the file, use this method.

The largely accidental way is a check-in where the file has not been
changed. RCS notes that there are no changes and simply unlocks the
file (and removes the previous version). You can override that with 'ci
-f' to force the check-in. Note that this is not a good idea if you
have changed the file but don't want those changes preserved.

Note that the co-worker cannot check the file out with a lock until you
release the lock. However, 'co -p' could be used to obtain a writable
file - but beware conflicting changes when the changes are finally
checked in.

If locking conflicts are a regular problem, consider using CVS (or
SubVersion) instead.

[Minor caveat: I'm ignoring separate locks on separate branches.]

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

On Sat, 07 Oct 2006 14:20:40 GMT, Jonathan Leffler <jleffler@earthlink.net> wrote:
....

What version of RCS are we talking about? A simple test with RCS version
5.7 indicates that 'co -u foo' does indeed release the lock, if you have
one. (It also discards any changes, of course.)

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!