cvs commit: src/contrib/groff FREEBSD-Xlist src/contrib/groff/src/include getopt.h src/contrib/groff/src/libs/libgroff getopt.c getopt1.c

[Ruslan Ermilov]

On Wed, Feb 18, 2004 at 09:52:55AM -0800, Nate Lawson wrote:
> On Wed, 18 Feb 2004, Ruslan Ermilov wrote:
> > On Wed, Feb 18, 2004 at 07:02:53AM +0100, Ollivier Robert wrote:
> > > According to Andrey Chernov:
> > > > > According to Andrey A. Chernov:
> > > > > >   1.3       +2 -0      src/contrib/groff/FREEBSD-Xlist
> > > > > >   1.2       +0 -169    src/contrib/groff/src/include/getopt.h (dead)
> > > > > >   1.2       +0 -1055   src/contrib/groff/src/libs/libgroff/getopt.c (dead)
> > > > > >   1.2       +0 -188    src/contrib/groff/src/libs/libgroff/getopt1.c (dead)
> > >
> > > > that it will be replacement for gnu getopt (as for fnmatch, stpcpy etc gnu
> > > > pollution). getopt_long() was too long in the libc to really trigger the
> > > > switch now. I don't take files off the branch, just remove unneded junk,
> > > > most of it is already in FREEBSD-Xlist. It always be our style to not
> > > > import unneeded files.
> > >
> > > Look at the commit message, these files were on the FSF vendor branch, you
> > > have taken these off that branch!  That's _not_ the way you should have done
> > > it.
> >
> > Removing files on the HEAD branch is somewhat rather special way
> > to "take files off the vendor branch", and as Andrey already
> > pointed out, we needed to remove at least getopt.h so the
> > FreeBSD's native version of getopt.h gets used.  And there was
> > no point keeping other getopt*.c either with this change.
> 
> This is not the appropriate way to do it.  des@, roberto@, and myself
> have all explained this both times this has happened.
> 
I know, I just happen to have a different opinion on this subject.

It's pretty legal (and always was) to remove unneeded files on HEAD,
while preserving them on vendor branch.  We did it this way all the
time, with yacc(1) output files, etc.  Yes, this creates a conflict
with future imports (if these imports have and modify these files),
but this conflict is intentional.  Read this output:

$ grep -C 'Never make local changes' /usr/src/contrib/*/FREEBSD-upgrade

Removing files on a vendor branch, OTOH, implies that these files
were removed by the vendor, which it's NOT.

Consider this:

- getopt.h got first imported with release tag v1_0,
- getopt.h was removed on vendor branch (VENDOR),

(so far so good)

- getopt.h gets imported again with release tag v2_0.

The last command will in effect un-delete this file, which is
not probably what we need.

Of course one could argue that we should also put getopt.h
into FREEBSD-Xlist, so that the next import won't re-import
it again, but then it is not different from simply removing
it on HEAD -- there will be no conflict with future imports
using the same exclude file.

My preferences for handling the vendor branches are as follows:

1 checkout on vendor branch (-rVENDOR) should give the same
  output as checkout of the latest vendor release tag, if
  possible; the only exceptions are partial vendor fixes or
  upgrades, where vendor didn't release the new version.
  (David O'Brien has pointed this out to me recently when I
  simply committed on the vendor branch to upgrade our copy
  of one-true-awk to the latest version.)

2 local deletions should be done on HEAD, so that we are
  safe with respect to contents of FREEBSD-Xlist, as
  explained above

3 (follows from #1) after a new import, both vendor branch
  and HEAD, in that order, should be cleared to remove files
  that were not imported (either vendor has removed them, or
  these files are in our exclude list) with the commit log
  such as "Removed files not present in the latest import".
  Note the order here: old and excluded files should first
  be deleted on the vendor branch, and only then what's left
  on HEAD should be cleared: locally modified files that are
  no longer needed.

The two working examples of this technique could be found in
freefall:~ru/import/, and were used for some time now to handle
Groff and Texinfo.


Cheers,
-- 
Ruslan Ermilov
FreeBSD committer
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040218/334f845d/attachment.bin