Re: Feature request (with patch)

Thien-Thi Nguyen wrote:
> () Martin Burnicki <[email protected]>
> () Tue, 28 Aug 2012 13:17:06 +0200
>
>     [...]
>
>     ext
>     @project g:/mbglib/mbglib.pj;
>     project /repository/clkdrv/linux/soft/mbgclock/mbgclock.pj;
>     project g:/clkdrv/win_2k/soft/sys/mbgclock/mbgclock.pj;
>     @
>
>     This section is located before the "desc" section of an archive fil=
e.
>
>     The current version of GNU rcs is unable to access archive files
>     which have such section since the section type is not supported, so
>     Hannes K=C3=BCttner, whom I've added in CC:, has made a patch which
>     detects unknown sections when an archive file is read, and simply
>     writes the unknown sections back when the archive file is rewritten=
.
>
>     [ref mbg_rcs_unexpected_keywords.patch]
>
> Thanks for the patch.  Although RCS hungers for users, my immediate
> reaction is to regretfully point out that the comma-v syntax is frozen
> (see 5.8 NEWS) in preparation for yet-unspecified "integrity features",
> and thus reject it as it stands.

OK, but it's a pity since we can't use GNU RCS without this patch. It=20
would have been easier for us if you had picked the patch up so we could=20
have upgraded easily to newer rcs versions in the future.

> That said, i now view that decision to be incomplete in that it left no
> clean way to add user-defined extensions, aside from hijacking the
> =E2=80=98integrity=E2=80=99 header directly.  To DTRT, i think we need =
to specify that
> =E2=80=98integrity=E2=80=99 be composed of a system part and a user par=
t, the latter
> opaque (pass-through) to RCS.  These parts should be separated by some
> "uncommon" byte (something in [0x01,0x1F], ideally), with the system
> part coming first, and the user part (and sep byte) optional.
>
> Some examples, w/ formfeed (ASCII 0x0C, '\f', ^L) as the sep byte:
>
> - degenerate
>    integrity @@;
>
> - degenerate w/ user part
>    integrity @^L@;
>
> - degenerate system part, non-degenerate user part
>    integrity @^L
>      project g:/mbglib/mbglib.pj;
>      project /repository/clkdrv/linux/soft/mbgclock/mbgclock.pj;
>      project g:/clkdrv/win_2k/soft/sys/mbgclock/mbgclock.pj;
>    @;
>
> Thus, the overall change is to push user data out of the top-level, and
> into the second-half of =E2=80=98integrity=E2=80=99, a conceptually con=
sistent (IMHO)
> location that satisfies forward compatability (at the cost of having to
> manually convert some comma-v files via a sed script).
>
> What do you think?  FYI, prior discussion on the system part is at:
> <http://lists.gnu.org/archive/html/help-rcs/2012-07/msg00000.html>.
>
>     [t300 workaround]
>
> If user data is part of =E2=80=98integrity=E2=80=99, t300 should pass w=
/o modification.

Sounds good, but doesn't help us since we actually need to share the=20
repos with the 3rd party rcs system which adds this private header field=20
our patch should take care of.

>     Hannes K=C3=BCttner has also rewritten the complete graphical user
>     interface in python3, so there's also a modern front end available
>     for the current version of GNU rcs.
>
>     If someone is interested we can send them a copy of the python GUI.
>
> Long-term RCS will provide a shared-object library (and API), but stop
> short of a graphical interface.  If your code and its documentation are
> available under free licenses (see <http://www.gnu.org/licenses>), i
> would be happy to add a link to its homepage from the RCS homepage.

Actually the python program just calls the binaries. This is very new=20
stuff and still needs some testing, but once we have found it is stable=20
we can make it available under a free license.


Thanks,

Martin
--=20
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany