On Sun, 25 Apr 2010 23:55:35 +0100 Owain Ainsworth <zer...@googlemail.com> wrote:
> On Sun, Apr 25, 2010 at 05:27:26PM -0500, Chris Bennett wrote: > > I am glad to see someone else agreeing that rm-ing xenocara and > > getting it again is a good choice. > > I had to build a few debugging versions and I found the instructions > > for getting it clean to use again extremely confusing. > > I was concerned I would get it wrong and mess everything new up. > > To get a completely clean tree with nothing unrecognised by cvs, > assuming that no files known by cvs are corrupted (do not do this if > you have testing drivers in the tree that are not related to cvs). If > it breaks, you keep the pieces. > > $ cvs up | grep ^\? | tr -d '\?' | xargs rm -rf > $ cvs up # just in case > > Those who are better at awk than I could come up with something > shorter, I bet. For me at least, the problem is not 'unrecognized' files, instead it is *modified* files. With "XENOCARA_RERUN_AUTOCONF=Yes" set in mk.conf, half the damn tree is molested by gnu autoshit resulting supposedly "modofied" files. Since the `cvs up -C` flag is currently broken in both gnu cvs and opencvs (BUG: user/6363 -- copies modified files rather than moving them out of the way and fetching a fresh copy from cvs, resulting in a merge "M" rather than "U" update/fetch of the now missing file), there is no way to simply overwrite the modified files. Anyhow, whether or not '-C' works, you'd still be refetching half (or more) of the xenocara tree since a vast portion of it is gnu autoshit files which have been modified. As for building a lot quicker by not setting XENOCARA_RERUN_AUTOCONF, well, then you would not be testing to make sure gnu autoshit is still working properly. In short, it's a no-win situation. -- The OpenBSD Journal - http://www.undeadly.org
