Date: Sun, 29 Jun 1997 11:52:53 -0700 From: Paul Traina <pst@shockwave.com> To: "Jonathan M. Bresler" <jmb@FreeBSD.ORG> Cc: steve@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-contrib@FreeBSD.ORG Subject: Re: cvs commit: src/contrib/patch ChangeLog Makefile.in NEWS acconfig.h backupfile.c common.h config.hin configure configure.in Message-ID: <199706291852.LAA26110@precipice.shockwave.com> In-Reply-To: Your message of "Sun, 29 Jun 1997 06:53:41 PDT." <199706291353.GAA02724@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Jonathan M. Bresler" <jmb@FreeBSD.ORG> Subject: Re: cvs commit: src/contrib/patch ChangeLog Makefile.in NEWS acconfi >>g.h backupfile.c common.h config.hin configure configure.in Paul Traina wrote: > > Steve, > It doesn't look like you did this as an import, but rather as a commit > to the main branch. That means we've got a big nasty ugly problem on > our hands. > > All updates to ANY stuff gotten from ANY vendor need to go on the vendor > branch. > > I think, at this point, the best thing to do is rm -rf contrib/patch > from the repository and start over again with a clean import of 2.4. > > This is Peter's call. Paul, over the last couple years, we have seen a couple snafu's in commits/imports to the source tree. mistakes like these are horrendously expensive to repair (need to consume CVS guru time and effort). There's the technical operation, and then there's policy that is put into place to stop people from being stupid. The technical operation is obvious, you go into the cvs repository and rm -rf the hierarchy you just imported. However, this needs to be done before anyone takes a snampshot of the repository (good old sup strikes again), and I think CVSup has the same sort of restriction, albiet to a lesser extent of pain. On the other hand, while this operation is, in fact, simple to do, I don't feel very good about having just anyone do rm -rf's in the CVS repository. What's to stop someone from accidently removing the wrong thing, like /home/ncvs/src/contrib instead of /home/ncvs/src/contrib/patch :-( What if someone thought they had a virgin import they were removing, but, in fact, they were uninformed (read: polite way of saying clueless) and wiped something that was part of a distribution already. That's why these horrible mistakes need to be fixed by a set of trusted, available, informed, cvs meisters, which, by definition, need to be a very very very small subset of the committers group. please include example command lines (both wrong and corrected) so others can learn from mistakes that are made. Here's Steve's mistake (in short): 1. He imported patch 2.3 (no problem yet) cvs import -m "Initial import of patch v2.3" src/contrib/patch \ FSF v2_3 2. He realized 2.4 came out, so somewhere he did something approximating diff -c -r -N patch-2.3 patch-2.4 >DIFFS cvs co contrib_patch cd contrib_patch patch <DIFFS cvs commit -m "Upgrade to v2.4" This was a mistake. The proper thing to do was to do: cvs import -m "Upgrade to patch 2.4" src/contrib/patch \ FSF v2_4 on a virgin extraction of the FSF patch-2.4.tar.gz distribution. Followed by: cd /tmp/somewhere cvs co -jFSF:yesterday -jFSF contrib_patch cd contrib_patch <fix up any conflicts> cvs commit -m "Resolve v2.4 import conflicts." to handle any conflicts between FreeBSD local changes and the new version. The point is that in any software we import from a 3rd party, whether it goes in contrib or not, changes from the vendor must be kept on the vendor branch (in this example, FSF). This way, we can easily extract FreeBSD local changes at any point with cvs diff -c -rFSF and easily merge them over time.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706291852.LAA26110>