OpenRCS 4.5: revisions < 1.0 become inaccessible

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenRCS 4.5: revisions < 1.0 become inaccessible

bernward.pub
>Synopsis: some revisions < 1.0 become inaccessible after ci r1.1
>Category: user
>Environment:
        System      : OpenBSD 6.4
        Details     : OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018
                         [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP

        Architecture: OpenBSD.amd64
        Machine     : amd64
>Description:
        Revisions r0.1, r0.2 ??? are accessible,
        as long as no revison 1.1 or higher is checked in.
        After check in of revision 1.1, only the revisions 1.1 and 0.1
        are accessible. A try to check out revison 0.2 gives a message,
        that revision 1.1 will be checked out and actually rcs does so.

>How-To-Repeat:

# init
echo test | rcs -i dummy

# check in rev 0.1
echo dummy0.1 >dummy; ci -r0.1 dummy
echo "# A # check rev 0.1:"
co dummy; cat dummy

# check in rev 0.2
co -l dummy; echo dummy0.2 >>dummy; ci -mr0.2 dummy
echo "# B # check rev 0.2:"
co dummy; cat dummy

# check in rev 1.1
co -l dummy; echo dummy1.1 >>dummy; ci -r1.1 -mr1.1 dummy
echo "# C # check rev 1.1:"
co dummy; cat dummy
echo "# D # check rev 0.2 (FAILS!):"
co -f0.2 dummy; cat dummy
echo "# E # check rev 0.1 (OK!):"
co -f0.1 dummy; cat dummy

>Fix:
        (do not use revisions < 1.1)

Regards, Bernward.


dmesg:
OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4167065600 (3974MB)
avail mem = 4031508480 (3844MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf00 (51 entries)
bios0: vendor American Megatrends Inc. version "F9" date 03/02/2018
bios0: GIGABYTE GB-BXBT-2807
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG LPIT HPET SSDT SSDT SSDT UEFI BGRT
acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) BRCM(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.64 MHz, 06-37-08
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 87 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus 4 (RP04)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PLPE
acpipwrres1 at acpi0: PLPE
acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1
acpipwrres3 at acpi0: CLK0, resource for CAM1
acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 90 degC
"INT3396" at acpi0 not configured
acpicmos0 at acpi0
"DMA0F28" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
"BCM2E1A" at acpi0 not configured
"BCM4752" at acpi0 not configured
"INTCF0B" at acpi0 not configured
"INTCF1A" at acpi0 not configured
"INTCF1C" at acpi0 not configured
"SMO91D0" at acpi0 not configured
"ATML1000" at acpi0 not configured
"INT33BD" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1578, 1577, 1494, 1411, 1328, 1245, 1162, 1079, 996, 913, 830, 747, 664, 581, 498 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e
inteldrm0 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0e
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1280x1024, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ahci0 at pci0 dev 19 function 0 "Intel Bay Trail AHCI" rev 0x0e: msi, AHCI 1.3
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, HGST HTS545050A7, GR2O> SCSI3 0/direct fixed naa.5000cca7a3d6357f
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
xhci0 at pci0 dev 20 function 0 "Intel Bay Trail xHCI" rev 0x0e: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel Bay Trail TXE" rev 0x0e at pci0 dev 26 function 0 not configured
azalia0 at pci0 dev 27 function 0 "Intel Bay Trail HD Audio" rev 0x0e: msi
azalia0: codecs: Realtek/0x0283, Intel/0x2882, using Realtek/0x0283
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel Bay Trail PCIE" rev 0x0e: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel Bay Trail PCIE" rev 0x0e: msi
pci2 at ppb1 bus 2
"Realtek 8191SE" rev 0x00 at pci2 dev 0 function 0 not configured
ppb2 at pci0 dev 28 function 2 "Intel Bay Trail PCIE" rev 0x0e: msi
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), msi, address fc:aa:14:ad:e2:5e
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb3 at pci0 dev 28 function 3 "Intel Bay Trail PCIE" rev 0x0e: msi
pci4 at ppb3 bus 4
pcib0 at pci0 dev 31 function 0 "Intel Bay Trail LPC" rev 0x0e
ichiic0 at pci0 dev 31 function 3 "Intel Bay Trail SMBus" rev 0x0e: apic 1 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 SO-DIMM
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
efifb at mainbus0 not configured
ugen0 at uhub0 port 2 "Realtek Bluetooth Radio" rev 2.10/2.00 addr 2
uhidev0 at uhub0 port 3 configuration 1 interface 0 "Cherry Mikroschalter product 0x010d" rev 2.00/1.00 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub0 port 3 configuration 1 interface 1 "Cherry Mikroschalter product 0x010d" rev 2.00/1.00 addr 3
uhidev1: iclass 3/0
uhid0 at uhidev1: input=2, output=0, feature=0
uhidev2 at uhub0 port 4 configuration 1 interface 0 "SIGMACH1P U+P Mouse" rev 1.10/1.10 addr 4
uhidev2: no report descriptor
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (fd1544c01853c8be.a) swap on sd0b dump on sd0b

usbdevs:
Controller /dev/usb0:
addr 01: 8086:0000 Intel, xHCI root hub
         super speed, self powered, config 1, rev 1.00
         driver: uhub0
addr 02: 13d3:3410 Realtek, Bluetooth Radio
         full speed, self powered, config 1, rev 2.00, iSerialNumber 00e04c000001
         driver: ugen0
addr 03: 046a:010d Cherry Mikroschalter, product 0x010d
         low speed, power 100 mA, config 1, rev 1.00
         driver: uhidev0
         driver: uhidev1
addr 04: 1c4f:0003 SIGMACH1P, U+P Mouse
         low speed, power 98 mA, config 1, rev 1.10
         driver: uhidev2

Reply | Threaded
Open this post in threaded view
|

Re: OpenRCS 4.5: revisions < 1.0 become inaccessible

Ingo Schwarze
Hi Bernward,

[hidden email] wrote on Sat, Jan 12, 2019 at 06:50:29PM +0100:

> Synopsis: some revisions < 1.0 become inaccessible after ci r1.1
> Description:
> Revisions r0.1, r0.2 ??? are accessible,
> as long as no revison 1.1 or higher is checked in.
> After check in of revision 1.1, only the revisions 1.1 and 0.1
> are accessible. A try to check out revison 0.2 gives a message,
> that revision 1.1 will be checked out and actually rcs does so.

As far as i know, RCS and CVS revision numbers are defined as strings
of dot-separated positive non-zero decimal integers, so if revision
numbers like "0.1" or "1.0" partially work in some respects, that
seems an accident to me and not intentional.

So i wouldn't call this a bug in the code.

At worst, it might be a documentation issue.
Then again, rcs(1) already says:

  $ mkdir RCS
  $ ci foo.c
  This command creates an RCS file foo.c,v in the RCS directory,
  stores foo.c into it as revision 1.1, and deletes foo.c.

And ci(1) already says:

  Revision numbering starts at 1.1 and increases logically.

So i'm not even convinced that the documenation is defective.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: OpenRCS 4.5: revisions < 1.0 become inaccessible

bernward.pub
Hello Ingo,

I used to use branches with number zero for first experimental versions
without problems on Linux. I just assumed, this would be compatible
with OpenRCS. You cited ci(1) with the demanding sentence "Revision
numbering starts at 1.1". The old version of ci(1) in OpenBSD-3.9 says,
that 1.1 is the "default number", which could be interpreted in a more
liberal way, saying that the user has the option to user other values.
OpenBSD-3.9 also had a man page rcsfile(5) with the format of the
RCS file. There I find:

        delta     ::=  num
        ...
        num       ::=  {digit | .}+
        digit     ::=  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

That indicates to my opinion, that in the original RCS the digit zero
was allowed.

But trying to reconstruct my data, I now found a more serious problem:

Using the revision numbers 1.1, 1.2, 2.1 for the test script,
version 1.2 becomes inaccessible after ci of revision 2.1,
here the changed script:

### start script2
# init
echo test | rcs -i dummy

# check in rev 1.1
echo dummy1.1 >dummy; ci -r1.1 dummy
echo "# A # check rev 1.1:"
co dummy; cat dummy

# check in rev 1.2
co -l dummy; echo dummy1.2 >>dummy; ci -mr1.2 dummy
echo "# B # check rev 1.2:"
co dummy; cat dummy

# check in rev 2.1
co -l dummy; echo dummy2.1 >>dummy; ci -r2.1 -mr2.1 dummy
echo "# C # check rev 2.1:"
co dummy; cat dummy
echo "# D # check rev 1.2 (FAILS!):"
co -f1.2 dummy; cat dummy
echo "# E # check rev 1.1 (OK!):"
co -f1.1 dummy; cat dummy
### end script2

It seems, that the problem ist not (only) with the use of zeros, but
with the use of different branches. I could get access to the middle
version by editing the RCS file by hand and changing the number 2.1
to 1.3. The same is possible for the first test case: after changing
version 1.1 to 0.3, version 0.2 is accessible again.
 
Best regards, Bernward.


On 2019-01-13 14:43, Ingo Schwarze wrote:

> Hi Bernward,
>
> [hidden email] wrote on Sat, Jan 12, 2019 at 06:50:29PM +0100:
>
> > Synopsis: some revisions < 1.0 become inaccessible after ci r1.1
> > Description:
> > Revisions r0.1, r0.2 ??? are accessible,
> > as long as no revison 1.1 or higher is checked in.
> > After check in of revision 1.1, only the revisions 1.1 and 0.1
> > are accessible. A try to check out revison 0.2 gives a message,
> > that revision 1.1 will be checked out and actually rcs does so.
>
> As far as i know, RCS and CVS revision numbers are defined as strings
> of dot-separated positive non-zero decimal integers, so if revision
> numbers like "0.1" or "1.0" partially work in some respects, that
> seems an accident to me and not intentional.
>
> So i wouldn't call this a bug in the code.
>
> At worst, it might be a documentation issue.
> Then again, rcs(1) already says:
>
>   $ mkdir RCS
>   $ ci foo.c
>   This command creates an RCS file foo.c,v in the RCS directory,
>   stores foo.c into it as revision 1.1, and deletes foo.c.
>
> And ci(1) already says:
>
>   Revision numbering starts at 1.1 and increases logically.
>
> So i'm not even convinced that the documenation is defective.
>
> Yours,
>   Ingo

Reply | Threaded
Open this post in threaded view
|

Re: OpenRCS 4.5: revisions < 1.0 become inaccessible

bernward.pub
Hello Ingo,

I found a solution for both problems. Two similar tests in co.c
and rcs.c are involved. I commented them out and both of my test
scripts showed the expected result, none failed.

In co.c, I commented out lines 271-279, in rcs.c lines 923-929.
In both files the involved test are commented with
        '/* XXX rcsnum_cmp()'.
Probably someone was already working at that point. In co.c, the
further comment is "Check out the latest revision if <frev> is
greater than HEAD". The test in rcs.c has obviously the same
intention.

Both tests fail, because they do not regard the higher value of
the higher places in rn_id[]. The test decides, that requested
revion number is higher than the head revision, if ANY place
makes the comparison rf_head->rn_id[i] < rev->rn_id[i] true, even
if the comparison of higer valued places should have proven, that
the requested version is lower than the head revision.

The obviously intended change to use rcsnum_cmp() for theese tests
would probably also heal the problem, because rcsnum_cmp() seems
to regard the higher value of the higher places. I choosed to
just comment out the tests, because
a) this was just the easiest work-around
b) I do understand, why theese tests are usefull:
would it not be better to give an error message,
if the requested revision does not exist, in spite
of silently deliver the head revision?

The two test spripts can be found in my older mails in this thread:
mail 2019-01-14 script2 testing revision numbers 1.1, 1.2, 2.1
mail 2019-01-12 script1 testing revision numbers 0.1, 0.2, 1.1

Best regards,

Bernward.