Since the information is just being ignored, why not just write a utility that converts proprietary RCS files to GNU RCS format rather than adding support for arbitrary sections?
On Sep 10, 2012 7:49 AM, "Thien-Thi Nguyen" <
address@hidden> wrote:
() Martin Burnicki <address@hidden>
() Tue, 28 Aug 2012 13:17:06 +0200
[...]
ext
address@hidden 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 file.
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üttner, 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.
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
‘integrity’ header directly. To DTRT, i think we need to specify that
‘integrity’ be composed of a system part and a user part, 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 ‘integrity’, a conceptually consistent (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 ‘integrity’, t300 should pass w/o modification.
Hannes Küttner 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.
--
Thien-Thi Nguyen ..................................... GPG key: 4C807502
. NB: ttn at glug dot org is not me .
. (and has not been since 2007 or so) .
. ACCEPT NO SUBSTITUTES .
........... please send technical questions to mailing lists ...........