Re: What to do about RCS/OpenRCS

On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote:
> On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni <pfg_at_freebsd.org> wrote:
> > Hello;
> >
> > On 05/07/15 14:56, Lyndon Nerenberg wrote:
> >>
> >> On Thu, 7 May 2015, Pedro Giffuni wrote:
> >>
> >>> Unfortunately I don't use RCS enough (it looks like I should though) so
> >>> I am not in a good position to take the next step and deal with any
> >>> fallout it may produce.
> >>
> >>
> >> If we can have a build-knob to disable GNU RCS and enable the new one I
> >> will happily twist up the new version and hammer on it.
> >>
> >
> > Yes, that's usually the next step in the process. It is a little bit messy
> > because
> > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
> > perhaps something else that we don't use).
> >
> > I really want to check out first if there is some strong opinion against
> > OpenRCS. Perhaps someone that has used it before and thinks it is a
> > bad idea.
> >
> > It looks like there are voices against it, so those have to be addressed
> > first.
> 
> Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
> bits); check with jhb first to make sure that OpenRCS works with
> etcupdate.
> Cheers!

I think this can be fixed by using diff3 instead of merge, I just haven't
sat down and figured out the correct incantation.

That said, I think that having a not-quite-working rcs (OpenRCS) in base
is worse than having no rcs.  If OpenRCS is improved as per Xin's notes
then just switching over is probably the path of least resistance.

I guess I see the following options:

  1) Just leave GNU RCS in the tree.

  2) Improve OpenRCS so it can be swapped in.

  3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate)
     and import just a /bin/ident binary (perhaps from OpenRCS).

Both 2) and 3) require some work.  I suspect 3) requires less. :)

-- 
John Baldwin