On Tue, Jul 20, 1999 at 04:58:49PM -0700, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Nik Clayton <[EMAIL PROTECTED]> wrote:
> > Assuming I did this, what's the approved method?
> >
> > Myself, I'd just
> >
> > # mv ipf.1 ipf.8
> > # cvs remove ipf.1
> > # cvs add ipf.8
> > # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8
> > [... check for any other man pages that refer to ipf(1) and update
> > them accordingly ...]
> >
> > which properly reflects that (until the change) ipf.8 didn't exist. I
> > *would not* use a repository copy for this.
>
> When in doubt, ask the repo-man. :-)
>
> There's enough history in the file that _if_ it were going to be
> renamed, a repository copy should be used. (I don't like them either,
> but they're What We Do.)
I'm curious -- why are they what we do? When I've used CVS on other
projects, it always made more sense to 'cvs remove' and 'cvs add'. That
way, if you checked out files by date stamp, and chose a date prior to
the renaming, the files you got back accurately reflected the state of
the repository at that time. If you repo copy then the file will always
have existed with the new name, even when other files (such as Makefiles)
would refer to the old name.
No?
> However, you shouldn't rename the file, because it is in the contrib
> tree. The whole point of contrib is that it must stay as nearly
> identical to the author's distributions as possible, so that imports
> of new versions aren't painful.
Duly noted.
> I think you should lobby the author <[EMAIL PROTECTED]> to rename
> the file in his own tree. Then the problem goes away when the next
> release is imported.
Will do.
> Meanwhile, if you want to install it into man8, you could do it with
> special rules in "src/sbin/ipf/Makefile". Something like this
> (untested) should do the trick:
>
> MAN8= ipf.8
> CLEANFILES+= ipf.8
>
> ipf.8: ipf.1
> cp ${.ALLSRC} ${.TARGET}
>
> and delete the MAN1 line for ipf.1.
I'll experiment with that (current task: get new laptop working with
Coda. . .)
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message