On 2010/05/26 15:04, J.C. Roberts wrote: > 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
that is a cvsweb fabrication.
