Suppose a file has 4 revisions (1.1 to 1.4). I deleted revisions 1.2 and 1.3 using rcs -o1.2:1.3 myfile.txt
. Now I want to change revision number 1.4 to become revision number 1.2. How do I do this using RCS?
Change the version number of a revision in RCS
rcsversion control
Related Solutions
You could try the venerable RCS (package "rcs") as @steeldriver mentioned, a non-modern version control system that works on a per-file basis with virtually no overhead or complication. There are multiple ways to use it, but one possibility:
- Create an RCS subdirectory, where the version history will be stored.
- Edit your file
- Check in your changes:
ci -l -m -t- myfile
- Repeat
If you store this text in your file:
$RCSfile$
$Revision$
$Date$
then RCS will populate those strings with information about your revision and its datestamp, once you check it in (technically, when you check it out).
The file stored in RCS/
will be called myfile,v
and will contain the diffs between each revision. Of course there's more to learn about RCS. You can look at the manpages for ci
, co
, rcs
, rcsdiff
and others.
Here's some more information:
- If you skip creating the
RCS/
directory, then the archive will appear in the same directory as your file. - You "check in" a file with
ci
to record a version of it in the archive (the*,v
file in the RCS/ directory). Check-in has the weird side effect of removing your file, leaving your data only present in the*,v
archive. To avoid this side effect, use-l
or-u
with theci
command. - You "check out" a file with
co
to reconstitute it from the archive. - You "lock" a file to make it writable and prevent others from writing to it, which would create a "merge" situation. In your case, with only one user modifying the file, "locked" means writable and "unlocked" means read-only. If you modify and "unlocked" file (by forcing a write to it),
ci
will complain when you try to check the changes in (so, avoid doing that). - Since you're the only one editing your file, you have a choice of scenarios: you can keep your file read-only (unlocked) or writable (locked). I use unlocked mode for files that I don't expect to change often, as that prevents me from accidentally modifying them, because they're read-only, even for me. I use locked mode for files that I'm actively modifying, but when I want to keep a revision history of the contents.
- Using
-l
withci
orco
will lock it, leaving it writable. Without-l
it will be read-only withco
or it will be removed altogether withci
. Useci -u
to leave the file in read-only mode after checking its contents into the archive. - Using
-m.
will preventci
from asking for a revision message. - Using
-t-
will preventci
from asking for an initial message (when the archive file is first created). - Using
-M
withci
orco
will keep the timestamp of a file in sync with the timestamp of the file at the time of check-in. co -r1.2 -p -q myfile
will print revision1.2
ofmyfile
to stdout. Without the-p
option, and assuming thatmyfile
is "unlocked" (read-only), thenco -r1.2 myfile
will overwritemyfile
with a read-only copy of revision1.2
ofmyfile
.-q
disables the informational messages.- You can create "branches", with revisions like
1.3.1.1
. I don't recommend this as it gets confusing fast. I prefer to keep with a linear flow of revisions.
So, if you prefer to keep your file always writable, you could use ci -l -M -m -t- myfile
. You can use rcsdiff myfile
to see the differences between the current contents of myfile
and the most recent checked-in version. You can use rcsdiff -r1.2 -r1.4 myfile
to see the differences between revisions 1.2
and 1.4
of myfile
.
The archive file is just a text file, whose format is documented in man rcsfile
. However, don't attempt to edit the archive file directly. IMO, the text-based archive file, the absolute minimal extra baggage (only a single archive file), and keyword substitution are RCS's biggest strengths and what makes it a great tool for local-only, single-user, single-file-at-a-time versioning. If I were redesigning RCS, I would remove the complications beyond this scenario (e.g. multi-user, branching), which I think are better handled by more modern distributed version control systems.
As with any command, there are some quirks; you should play around with test files until you understand the workflow you want for yourself. Then, for best results, embed your favorite options into a script so you don't have to remember the likes of -t-
, for example.
RCS indeed creates files with the ,v
suffix:
$ mkdir RCS
$ echo hello > hello.txt
$ ci hello.txt
RCS/hello.txt,v <-- hello.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> test file
>>
initial revision: 1.1
done
$ ls RCS
hello.txt,v
and they don't look exactly like the original file, so it may indeed be prudent to recognize them as something different.
$ cat RCS/hello.txt,v
head 1.1;
access;
symbols;
locks; strict;
comment @# @;
1.1
date 2021.08.28.14.44.57; author ilkkachu; state Exp;
branches;
next ;
desc
@test file
@
1.1
log
@Initial revision
@
text
@hello
@
It also seems to be able to process at least some binary data, though does that in a line-based manner.
Why they would be recognized as audio files in particular, that I don't know.
Best Answer
You'd have to recreate the archive-file. rcs will allow you to increase the revision number with a new check-in, but won't allow you to decrease it.