RCS (how does it work?)

S

strelok

Hello guys,

I'm learning FreeBSD and trying to understand how works RCS (Revision Control System).

So, my question is why I'm able to edit file when it's locked by RCS.


Code: 
[root@FreeBSD_PC /etc]# ci networks

networks,v <-- networks
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> test
>> .
initial revision: 1.1
done
[root@FreeBSD_PC /etc]#


[root@FreeBSD_PC /etc]# ls -l
-r--r--r--  1 root     wheel  381  2 apr 18:03 networks
-r--r--r--  1 root     wheel  693  2 apr 18:04 networks,v
After this I can edit file networks by ee or vi in spite of read-only for this file.
 
strelok said:
After this I can edit file networks by ee or vi in spite of read-only for this file.
Click to expand...
@Root can always edit everything regardless of permissions. The only way to prevent @root from editing or modifying a file is to use MAC (Mandatory Access Control).
 
Last edited by a moderator:
I would steer clear of RCS because it's so seriously outdated on the concept level as a revision control system. If you're on FreeBSD10 it includes the Subversion revision control system out of the box as svnlite. On older versions of FreeBSD you have to install devel/subversion. The other commonly used revision control system is GIT, devel/git.
 
kpa said:
I would steer clear of RCS because it's so seriously outdated on the concept level as a revision control system.
Click to expand...
True, but it's a simple system to play with and get some idea how RCS systems work. It doesn't require the set up of a repository and can easily be used on single files in-place. But I agree, don't use it for anything else. Only to play with.
 
Hello kpa,

Thank you very much for your valuable comment. I will take it into account for sure.
I started to learn FreeBSD from 9.2 release.
 
If you use GIT you can start using it in literally seconds and you don't need to set up a repository either.

Code: 
freebsd10 / # cd /etc
freebsd10 /etc # git init   
Initialized empty Git repository in /etc/.git/
freebsd10 /etc # git add jail.conf 
freebsd10 /etc # git commit
<describe the file for the commit and exit editor with save>

And that's all you need to do to have /etc/jail.conf under revision control with a local GIT repository in the same /etc/ directory. You can then add more files to repo with just git add <file> and commit them with git commit. The simplicity of using GIT for this kind of use is equally on par with RCS but with GIT you are don't have to know anything about the internals of the system, something that is almost unavoidable with RCS when you run into the many common snags that RCS has.
 
kpa said:
If you use GIT you can start using it in literally seconds and you don't need to set up a repository either.
Click to expand...
Brilliant. Now I've learned something from this thread too. Thank you very much :beergrin
 
I have quite a few files checked into RCS. Is there a way to undo this so that I can start using git rather? RCS has set all the config files I have checked into RCS with read only permissions. Do I have to undo this?
 
Use co(1) to get the latest version out of the ,v file. Then simply remove that ,v file. Set the correct permissions and you should be good to go.

One reason I looked at ci(1)/co(1) is because I regularly mistype vi /some/file and end up doing ci /some/file ;)
 
SirDice said:
Use co(1) to get the latest version out of the ,v file. Then simply remove that ,v file. Set the correct permissions and you should be good to go.

One reason I looked at ci(1)/co(1) is because I regularly mistype vi /some/file and end up doing ci /some/file ;)
Click to expand...

Thanks for that. Is it necessary to change the permissions? I'm not sure what the original permissions were before checking the files into RCS. I assume root had read/write permissions instead of just read.
 
The permissions thing is RCS wanting to mess with the permissions of the files you check in to the local repository. It assumes that the file that is checked in and no longer locked by you for editing should be made read-only. You can prevent that by using ci -l instead of plain ci. GIT doesn't suffer from such oddities because it's not concerned about locking for editing because it is assumed that nobody else would ever edit your own working copy.
 
You must log in or register to reply here.
Back
Top