On Tue, 25 May 2010 21:21:49 -0700 Philip Guenther <[email protected]> wrote: > > On Sun, May 23, 2010 at 10:57 PM, J.C. Roberts > <[email protected]> wrote: ... > > I found the problem. The 'xorg' vendor branch was treated as 'HEAD' > > for a while, but subsequently moving 'HEAD' back over to the 'MAIN' > > branch has broken date limited checkouts of 'HEAD'. Instead of > > getting what was HEAD at the specified time (i.e. the 'xorg' vendor > > branch), you get HEAD of the MAIN branch at the specified time, > > which results in about 200 ancient files, and of course, a xenocara > > checkout that wont build. > > I've read that three times now and I can't figure out what you're > trying to say. > 1) I don't see an 'xorg' branch at all in the xenocara/dist/Mesa/ > subdirs > 2) 'HEAD' is a magic word to cvs that many people misuse to mean the > trunk (aka, what you get when you do "cvs up -A"), but it does *NOT* > mean that when given to cvs's -r option...but it doesn't sound like > you're using it here > with either definition > 3) 'MAIN'? Is that another name for the trunk? > > > > I've got no clue why the cvs server once considered the 'xorg' > > branch as HEAD, but when asked for HEAD with a date_sepc defined, > > it fails to remember 'xorg' was HEAD at that time and mistakenly > > gives you what was in the 'MAIN' branch at the specified time. > > Oh, I think I see what you're trying to say. Yes, asking for a > version from a specific time from before a given file was locally > modified results in the 'wrong' version being checked out. This is > because vendor branch support is a kludge in cvs. In this case, it's > the fact that it doesn't treat all the revisions on the 1.1.1 branch > with timestamps before 1.2 as occuring "between" 1.1 and 1.2. You can > see the same effect with 'annotate'. > > > > Either cvs itself is > > hosed (not figuring out what branch was head at a specific time), or > > the branching commit was done wrong and needs to be fixed. > > It's the former. Note that the problem is not solvable without > additional metadata, in part because cvs thinks that it supports > multiple vendor branches. > > > > None of the following successfully clean up the hosed checkout: > > > > __ __ __ __cvs -d$CVSROOT up -ACd -jxorg -D'18 Apr 2010 10:30 GMT' > > __ __ __ __cvs -d$CVSROOT up -ACd -jxorg:'18 Apr 2010 10:30 GMT' > > __ __ __ __cvs -d$CVSROOT up -ACd -rxorg -D'18 Apr 2010 10:30 GMT' > > The first of those check out the trunk on the specified date and then > merge all the changes from the xorg branch onto that. I think there's > a bug in the opencvs server that makes it barf on that, though you can > get that effect with two commands. > > The second should check out the tip of the trunk and then merge into > it the changes from the xorg branch that were made before the > specified date. Again, I think bugs keep that from working in one > fell swoop though two commands should be doable. > > The third of those 'should be' a usage error, but just results in the > -D option being ignored. > > > I believe there's no way to do what you want with cvs and I would be > shocked to be shown otherwise. > > > > My cvs-fu is to weak to work around this easily. You might be able > > to work around it on a directory by directory basis (picking the > > correct branch for each directory), but it would be far better to > > fix the branches/tags in the repositories. > > The repository is fine; it's a design limitation of cvs's vendor > branches. > > > > Since deleting or renaming branches is bad juju, I think the answer > > might be to add 'MAIN' as a tag to all the stuff in the 'xorg' > > branch. I've never hit this problem before, so I'm not really sure. > > What is "MAIN"? Where is it documented? >
Here: http://www.openbsd.org/cgi-bin/cvsweb/xenocara/proto/x11proto/keysym.h I don't know where the documentation for the "MAIN" branch exists, assuming it does exist. Sorry for the quick mail, but I'm falling asleep as I type. I'll reread your message again in the proverbial morning. jcr -- The OpenBSD Journal - http://www.undeadly.org
