Re: Feature request (with patch)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

() 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 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=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.

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 s=
pecify that
=E2=80=98integrity=E2=80=99 be composed of a system part and a user part, t=
he 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:

=2D degenerate
  integrity @@;

=2D degenerate w/ user part
  integrity @^L@;

=2D 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 consist=
ent (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 m=
odification.

   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.

=2D-=20
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 ...........

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlBN05EACgkQZwMiJEyAdQKSVwCgkiU+tlQlCpXTLcNpF/O38wDO
22QAnA5U/gk6mPt941y3+YsZiG4fzYp9
=Ztrb
-----END PGP SIGNATURE-----
--=-=-=--