1

I would like to revision control some python files using RCS. After checking ci the scripts, a header is added to the script. I get a syntax error because that. How to comment the header with # after ci?

For e.g. - This is what my script looks like after ci

head    1.1;
access;
symbols;
locks; strict;
comment @# @;


1.1
date    2020.02.07.18.34.54;    author chiraga; state Exp;
branches;
next    ;


desc
@le
@


1.1
log
@Initial revision
@
text
@#!/pkg/qct/software/python/3.5.0/bin/python
Chirag Agrawal
  • 21
  • 1
  • 1
    You're not supposed to run the RCS file as if it were code. Leave it alone; only use the `rcs` tool to check things in and out of it; the checked-out content will be byte-for-byte identical to the original checked-in content. – Charles Duffy Feb 07 '20 at 18:52
  • ...that said, using RCS in this decade (or even in the last three decades) is not really a great idea. There's "ancient", and then there's "antique"... people don't even use CVS anymore, and CVS was designed to be RCS's replacement! Why would you choose it for a new project? – Charles Duffy Feb 07 '20 at 18:54
  • Is it usually expected to check out the script and then run it? What if I want to keep the script checked in unless I want to edit it? – Chirag Agrawal Feb 07 '20 at 18:54
  • Yes, it is expected to check anything out before you run it. – Charles Duffy Feb 07 '20 at 18:55
  • What are my other less ancient options? – Chirag Agrawal Feb 07 '20 at 18:55
  • ...the *dominant* SCM today is git. The most traditional competitor (as something that was designed to be easy-to-use from people coming from CVS, which was designed to appeal to people using RCS) is probably svn. There are lots and lots of other competitors that put up a good showing -- hg is one that's still actively maintained, f/e. – Charles Duffy Feb 07 '20 at 18:56
  • One requirement is I would not like to install a new software. I would like to use something present by default in linux OS. Looks like Hg needs to be installed. – Chirag Agrawal Feb 07 '20 at 18:59
  • There is no one "Linux OS". What is and is not installed by default depends on your distribution. That said, prioritizing this goal is going to be putting you in a world of hurt – Charles Duffy Feb 07 '20 at 19:10
  • RCS normally keeps the history of a file in a subdirectory called "RCS", with ",v" appended to the name. That file is managed by RCS. It's no a copy of the file you checked in. (The most popular revision control system these days is git. It may or may not be installed by default, but installing it should be easy. Learning to use it is less trivial, but well worth it.) – Keith Thompson Feb 07 '20 at 20:30

1 Answers1

3

First of all, RCS is a perfectly good option if you have single files you want to control. It is less complex than git and has a more understandable method of naming 'revisions' - it is much easier to understand versions 1.1 and 1.2 compared to the git commit SHA-1 checksums. In my lab, we continue to use it for text/troff/groff files, shell scripts, perl scripts, Makefiles, and rmarkdown files where they are standalone - although we use git for most complex projects. We have shell and perl script that are more than 30 years old that RCS still works on. RCS is NOT great for files that form part of a system, package, project etc. Use git for that.

To answer your question you need to understand how RCS works.

1 - after you did the initial check-in of your script you would have had 1 or 2 files:

filename.py,v (the RCS 'database' of your file) and possibly filename.py (your original code).

If you did the check-in with ci -l filename.py that would have given you both files, but if you just ran ci filename.py RCS would have checked your python script into the RCS file (with the trailing ,v) and removed your original.

2 - To get your usable python script out you need to check it out. If you want to check it out to work on it, then run:

co -l filename.py

The -l means 'lock the file out exclusively to me' - which is what you want when you are editing it.

At this stage you should be able to edit and run the script filename.py - NOTE that you will not and should not be trying to run the filename.py,v file - that is the database where your changes are recorded.

After each significant edit you will need to check the changes in - if it is you solely working on the file then ci -l filename.py is the easiest as it checks in your changes and keeps the source file available to you for you to edit.

Once you have a final tested script you would usually check in the last set of changes and then copy the source file to wherever you are deploying it - perhaps /usr/local/bin.

I would advise you to place a 

$Revision$

string somewhere in the comments section of the file so you can tell which version you have deployed. After you check in the file this will look something like this:

$Revision: 1.2 $

and will change each time.

Lots of RCS tutorials around but a quick version is here.

PJP
  • 612
  • 1
  • 6
  • 18