Date: Tue, 23 Jan 2001 22:18:17 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Archie Cobbs <archie@dellroad.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Kris Kennaway <kris@FreeBSD.org> Subject: Re: cvs commit: src/contrib/tcpdump print-smb.c Message-ID: <XFMail.010123221817.jhb@FreeBSD.org> In-Reply-To: <200101240610.WAA00480@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24-Jan-01 Archie Cobbs wrote: > Kris Kennaway writes: >> > > > Modified files: >> > > > contrib/tcpdump print-smb.c >> > > > Log: >> > > > Fix bug where tcpdump shows data beyond the end of certain >> > > > NBT packets. >> > > > >> > > > Revision Changes Path >> > > > 1.2 +3 -1 src/contrib/tcpdump/print-smb.c >> > > >> > > Congratulations, you just took this file off the vendor branch >> > > :-( >> > >> > Sorry if I'm being obtuse, but how is that a problem? Doesn't CVS >> > do the right thing in this case? There are lots of other files >> > in that directory with $FreeBSD$ in them. >> >> No. From now on, every new vendor release of that file will need to >> have patches merged by hand. > > By hand? The "cvs update -j .. -j .." or whatever that you do after > an import should take care of all of the non-conflicting > modifications > for all of the files at once. So there should be zero extra work > caused by this change, unless I'm misunderstanding something (I'm > not a CVS expert). See the committers guide, it has a FAQ for this: http://www.freebsd.org/tutorials/committers-guide/article.html <quote> 10.1. Why are trivial or cosmetic changes to files on a vendor branch a bad idea? The RCS file format is quite braindead and certain operations to achieve things for CVS are hideously expensive for the repository. Making changes to files on a vendor branch, thereby pulling the file off that branch, is one example of this. Suppose you have a file which was first imported on a vendor branch, and was then re-imported three times (still on the vendor branch) as the vendor makes updates to the file. 1.1.1.1 vendor import 1.1.1.2 vendor import, +1000, -500 lines 1.1.1.3 vendor import, +2000, -500 lines 1.1.1.4 vendor import, +1000, -1000 lines Now suppose that one of the FreeBSD committers makes a one line change to this file, causing it to go to version 1.2. This causes it to leave the branch, resulting in 4,001 lines being added to the file's history, and 2,001 lines being deleted. This is because the 1.2 delta is stored relative to 1.1.1.1, not 1.1.1.4, and so the entire vendor history is duplicated in the 1.2 delta. Now, repeat this for 2000 files in a large directory, it adds up a lot. This is why we have such ``hands off'' policies for src/contrib and other things that track the vendor releases. This is why ``typo fixes'' in man pages and spelling ``corrections'' are so strongly discouraged for vendor code. </quote> -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010123221817.jhb>