Date: Mon, 26 Jun 2000 15:52:39 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/crypto/openssh canohost.c ssh.h sshd.c Message-ID: <20000626155239.A12194@dragon.nuxi.com> In-Reply-To: <Pine.BSF.4.21.0006261809420.78867-100000@green.dyndns.org>; from green@FreeBSD.org on Mon, Jun 26, 2000 at 06:20:40PM -0400 References: <20000626142054.A2392@dragon.nuxi.com> <Pine.BSF.4.21.0006261809420.78867-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 26, 2000 at 06:20:40PM -0400, Brian Fundakowski Feldman wrote: > There is a bit more code in the repository (a _TINY_ bit! take a look), and Not a tiny bit. Peter has told us many times before that once a file is off the Vender branch, later vendor imports are keep as diffs from the the point of branch. It does not just keep your "tiny" change. > the next import will merge the $FreeBSD$ line (unless it's removed), and not > cause conflicts because the -same- code will be in both bases WRT what I > just committed. What _is_ it that you are so concerned about harming? Please try this. If you've changed the file (ie, pulled it off the vendor branch) you *_WILL_* get a "C" (conflict) placed beside the filename you are imported. Now CVS will tell you to use ``cvs co -j.... -j... src/crypto/openssh'' in an attempt to merge the changes into the vendor branch. Problem is CVS is often not smart enough to do the Right Thing. Rather than see you've just added "/* $FreeBSD$ */" since the last vendor import, it gets more creative. There are many Binutils and GCC files I have gotten their developers to accept. And we thus are back to using the stock files. TRUST me as I've been thru it many times in the past 2mos, CVS will not DTRT. The importer has to look at change logs, do diffs, etc.. to realize those files that we really just want to use their stock versions. Peter will probably correct me, but it has been my experience from its actions that CVS forever remembers which vendor branch rev the change was made to. When the CVS double -j merge checkout is done, it takes the diff from the vendor branch rev the change was made to and the next vendor branch rev and applies that diff to HEAD. It then does that recursively for each vendor branch rev. Thus we get crappy auto merges. -- -- David (obrien@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?20000626155239.A12194>