Version control symlink files 

Conclusion 

It is ok to version control symlink files as long as only "ci -l" is used, not "co".

You can also "rcs -l" symlink files too — links are still there.

Actually, both "ci -l" and "ci -u" are ok. But the problem with "ci -u" is that you have to refer to "co" for help when you need to change. But when you check out, whether locked or unlocked, the link will be gone.

documented on: 2006.12.28

history, co -u 

It is ok to version control symlink files as long as only "ci -l" is issued, and no vcs tag update occurs within the file, just as what I've been doing for /export/sysback/files.

After co (even if -u), the symlink file will be overwritten as a real file, thus the link is lost.

$ dir p5903/p-ml-apics.tex p-ml-apics.tex
lrwxrwxrwx    1 tong     tong           20 Oct  5 16:43 p-ml-apics.tex -> p5903/p-ml-apics.tex
-rw-r-----    1 tong     tong        36619 Oct  5 16:44 p5903/p-ml-apics.tex
$ co -f -u p-ml-apics.tex
RCS/p-ml-apics.tex,v  -->  p-ml-apics.tex
revision 1.6 (unlocked)
$ dir p5903/p-ml-apics.tex p-ml-apics.tex
-r--r-----    1 tong     tong        36619 Oct  5 16:46 p-ml-apics.tex
-rw-r-----    1 tong     tong        36619 Oct  5 16:44 p5903/p-ml-apics.tex

documented on: 2001.06.09 Sat 17:47:10

cmd:rcs check in (cmd:ci) problem 

locked by "somebody else" 

Symptom 

$ ci sendh
RCS/sendh,v  <--  sendh
ci: RCS/sendh,v: revision 1.12 locked by suntong

Reason 

Can not check in file that is locked by somebody else.

Solution 

way 
# list the files, then
# uncheck them
echo $fl
yes | rcs -u -M !$
rcs -l !$
# check them in immedietely afterwords
ci -l -m"- " !$
history 
$ rcs -u sendh
RCS file: RCS/sendh,v
Revision 1.12 is already locked by suntong.
Do you want to break the lock? [ny](n): y
State the reason for breaking the lock:
(terminate with single '.' or end of file)
>> ^D
suntong... User unknown
Saving message in /export/home/tong/dead.letter
...
$ rcs -l sendh
RCS file: RCS/sendh,v
1.12 locked
done
$ ci -l -m"send_log,probe-mail" sendh
RCS/sendh,v  <--  sendh
new revision: 1.13; previous revision: 1.12
done

Conclusion 

Do not check out any file before transfering to a different account. Otherwise, have to unlock it first.

no lock set by … 

Symptom 

$ ci ld.sys.lst
RCS/ld.sys.lst,v  <--  ld.sys.lst
ci: RCS/ld.sys.lst,v: no lock set by suntong

Solution 

Use 'rcs -U' to set locking to non-strict:

$ rlog ld.sys.lst
RCS file: RCS/ld.sys.lst,v
Working file: ld.sys.lst
head: 1.2
branch:
locks: strict
        tong: 1.2
$ rcs -U !$
rcs -U ld.sys.lst
RCS file: RCS/ld.sys.lst,v
done
$ ci ld.sys.lst
RCS/ld.sys.lst,v  <--  ld.sys.lst
new revision: 1.3; previous revision: 1.2
done

help 

-U   Set locking to non-strict.
-u[rev]
     Unlock the revision with number rev.
-M   Do not send mail when breaking  somebody  else's  lock.

No Write protect after checking in. 

*Tags*: no locking

Symptom 

After I check in a file using "ci -u", I saw that the +w flag is still on for the "owner".

Reason 

The file has been set to non-strict locking, by previous "rcs -U".

Using rlog file will show:

[...]
branch:
locks:
access list:
[...]

Solution 

Set locking to strict, again:

$ rcs -L fileh
RCS file: RCS/fileh,v
done
Tip !!

Using rlog file will now show:

locks: strict
$ diff fileh,v.000730 fileh,v
5c5
<       tong:1.21;
---
>       tong:1.21; strict;
$ dir fileh; ci -u -m"lns" fileh
-rwxr-x--x   1 tong     tong        18324 Jul 30 17:52 fileh*
RCS/fileh,v  <--  fileh
new revision: 1.22; previous revision: 1.21
done
$ dir fileh
-r-xr-x--x   1 tong     tong        18324 Jul 30 17:52 fileh*

documented on: 2000.03.16 Thu 14:54:43

File locked in rcs error 

Newsgroups: comp.unix.questions,comp.unix.programmer,comp.emacs

Have you ever experience problems with rcs command?

when I issue rlog t-chp-ds.tex, I get

rlog: RCS/t-chp-ds.tex,v: bad diff output line:
rlog aborted

This is the second time that I met with error in rcs version control. I use the emacs built-in tools to do the version control. I couldn't notice any sign of error until it is too late. Neither my yesterday's backup nor last week's can recover the error. The 3rd level backup was 10 days ago, which lacks 5 versions.

Tracking the changes between the versions is important to me. Now I have to find the hard way to rescue my version history. I tried to manually twist the .tex,v file to get rid of errors but failed. I thought of trying to use patch to rebuild the previous versions, but it doesn't seems to work.

I appreciate any tips or comments. Thanks

File locked in rcs error 

> Have you ever experience problems with rcs command?
[...]
> This is the second time that I met with error in rcs version
> control. [...] I tried to manually twist the .tex,v file to get
> rid of errors but failed.
[...]

Problem solved.

FYI:

rcsdiff, symbolic name undefined 

Symptom 

$ rcsdiff -wu -r .* 2>&1 | histring -f '^RCS file.*'
RCS file: RCS/.aliases_cs,v
rcsdiff: RCS/.aliases_cs,v: Symbolic name `(P' is undefined.
rcsdiff: RCS/.bash_logout,v: No such file or directory
===================================================================
RCS file: RCS/.bash_profile_,v
rcsdiff: RCS/.bash_profile_,v: Symbolic name `,T' is undefined.
===================================================================
RCS file: RCS/.bash_profile_su,v
retrieving revision 1.4
diff -wu -r1.4 .bash_profile_su
===================================================================
RCS file: RCS/.bash_rc,v
rcsdiff: RCS/.bash_rc,v: Symbolic name `(P' is undefined.
[...]

Why are the "symbolic name undefined" problems?

Conclusion / Solution 

The problem occurs when there is more than one file on the rcsdiff command line. I.e., rcsdiff file1 file2 file3… From file2 and on, the "symbolic name undefined" error will occur.

Solution: have to compare files individually, not all in one line.

Like this:

gen_file_list | xargsi rcsdiff -wU -r {}