I'm responding to the SVN users list this time, but the problem is nothing
to do with SVN per se.
I recommend just communicating directly with me, unless there's an outcry
from people demanding know how you're progressing.
(Cc my home email address too - I'm going to be OOO on Friday - and that
address is jleffler at earthlink dot net).
"Tim Alsop" <Tim.Alsop@CyberSafe.Ltd.UK> wrote on 06/03/2004 09:10:08 AM:
> I have approx. 750 directories containing SCCS to run through your
> sccs2rcs.sh conversion script. It has been going very well, until I
> encountered an error - see below :
Glad it was going well - and this problem is readily explainable, but not
necessarily so easily fixable. More accurately, it can be fixed, but it
involves some things that you're normally told 'Do not do this'.
> ==> file vscsts.str, rev=1.22, date=1998/06/04 11:08:15, author=sasham
> sccs get -s -k -r1.22 SCCS/s.vscsts.str
> sed -f /tmp/s2r.14812.sed vscsts.str > /tmp/s2r.14812.tmp
> rcs -l -q vscsts.str
> sccs prs -r1.22 -d':C:' SCCS/s.vscsts.str >/tmp/s2r.14812.tmp
> ci -f -r1.22 -d'1998/06/04 11:08:15' -wsasham vscsts.str <
> /tmp/s2r.14812.tmp
> RCS/vscsts.str,v <-- vscsts.str
> ci: RCS/vscsts.str,v: Date 1998/06/04 11:08:15 precedes 1998/06/04
> 11:14:27 in revision 1.21.
>
> ERROR: Doing ci -f -r1.22 -d'1998/06/04 11:08:15' -wsasham vscsts.str <
> /tmp/s2r.14812.tmp
SCCS was sloppy and allowed someone to check in two successive revisions:
1.21 1998-06-04 11:14:27
1.22 1998-06-04 11:08:15
Note that according to the time stamps, version 1.22 was checked in before
version 1.21. RCS is complaining where SCCS did not. And either someone
altered the system clock 6 years ago tomorrow or two people in two
different
time zones made the changes. (SCCS records local time; RCS uses UTC aka
GMT).
> Please remove the logfile /tmp/s2r.14812.log ASAP
>
> Incomplete conversion in ./RCS removed
> Original files in ./SCCS unchanged
> [root@flik include]#
Did you really do this as root? Why?
> What does this mean ? How do I fix it ?
It means there is an error in this particular SCCS file - a logical error.
And we're going to have to go around the back-door to fix it. It also
means
that any other file with two changes made around the same time could also
run
into problems.
In the short term, move s.vscsts.str out of the way, and continue
converting
other files and directories.
Take a backup copy of s.vscsts.str - this is the critical first step!
Make the s.vscsts.str file writable.
Edit it with an editor.
Find the line which starts '^Ad D 1.22 98/06/04 11:08:15'
Change the 08 to 18 - effectively checking in the file ten minutes later.
Verify that the next version - 1.23 or whatever - is after that date/time.
Write the file back and exit the editor.
Make the file non-writable again.
You can now verify that the file is corrupted with 'admin -h
s.vscsts.str'.
You can then tell SCCS to recalculate the checksum 'admin -z
s.vscsts.str'.
You can now verify that the file is uncorrupt with 'admin -h
s.vscsts.str'.
You should then be able to convert the file - unless there are other
anachronisms that RCS objects to.
Be aware that if you ever used a cut-off time around this point, then you
might now get different results from what you did before. On the scale of
risk 0-10, this is down at the 0.01 level - not serious, but theoretically
possible.
--
Jonathan Leffler (jleffler@us.ibm.com)
STSM, Informix Database Engineering, IBM Data Management
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 3 19:00:20 2004