CORE == EVIL!!

#1 I must have missed those earlier posts... what's the deal with "core"??

#2 Maybe I'm on drugs, but then those earlier posts would have been in the August or November time frame...I sure can't find them now.

Anyhoo:

When you try to import files into a new repository, cvs by default ignores files it anticipates you didn't really want to import, things like object files, editing temporary files, core dumps... Check out www.gnu.org/manual/cvs-1.9/html_node/cvs_141.html.

So it always ignores the core directory. We set up $CVSROOT/CVSROOT/cvsignore properly, but at least one of the implementations here decided to ignore cvsignore.

We did the canonical "cvs co torque" from you guys, then "cvs import ourtorque garagegames gg20020205". And of course it discarded the core directory, so then we did it again a little more maniacally and got it to work.

Then we checkout ourtorque, edit it to our hearts content, and check in our changes.

Then later on we did "cd torque; cvs up -P -A" which checked out everything just fine, then we did "cvs import ourtorque garagegames gg20020215", which again managed to not import the "core" directory into the reference branch of the repository. Since it's the vendor reference branch, it cheerfully deleted all the files in core from the vendor branch. And then we got all bollixed up trying to restore the core files to the build. It's a pain in the butt.

The point is when it works we can do "cvs co ourtorque -j gg20020205 -j gg20020215" and it checks out our modified version and applies all of your changes to it. We hand-merge all the conflicts, check in, and we're ready to go.

#3 I had to use ! to clear all previous ignored types
then write my own using the original I found
here is an example works for me:
!
RCS SCCS CVS CVS.adm cvs
RCSLOG cvslog.*
tags TAGS cvs
.make.state .nse_depinfo
*~ #* .#* ,* _$* *$
*.old *.bak *.BAK *.orig *.rej .del-*
*.a *.olb *.o *.obj *.lnk *.opt
*.Z *.elc *.ln *.dso *.ilk *.ml

#4 That's what we did, only the MacOS-X port of CVS chose to use some other base file. We never did figure out what happened.

#5 An annoying addition to this that I found was that for some reason my version of CVS (Not sure what it was exactly, but it's whatever ships with Mandrake 8.1) does not by default have a cvsignore file in the CVSROOT directory. Yet it still was ignoring the core directory when importing. There aren't by default many files in the CVSROOT directory, so I checked them all out, and none had types to exclude when importing. So I gave up at that point. Plus, it corrupted the directx libs everytime I imported them, and removed the custom build steps from the VC6 project files. Thats the one that really clinched it for me. So I gave up on CVS.

I briefly tried CVS for NT, but it had all the same problems except corrupting the libs. Then I found another free versioning system called FreeVCS, which worked well other than it was entirely too slow. To check out the engine took around 6-8 hours over a 100baseT lan! I can't imagine doing it over cable/dsl.

So does anyone know of any other free versioning systems?

#6 This may be totally off base - but could it have to with the fact that Unix systems used to (maybe Linux still does, I don't know) leave behind core dumps when a program crashes - an image of the running program at the time of the crash - for use with debuggers like dbg? This file was called 'core' and sometimes very very big. CVS may have some built-in capability for ignoring any file with the name core (not distinguishing between directory & file ...). Just a thought.

#7 Yes, that would be cvs's motivation for ignoring anything named "core". It would be fine if the ignore list worked the way the documentation described. Grrr. But since *everybody* using CVS is going to trip over this engine/core/ directory at least once, the simplest long-term solution is for GG to rename it as David suggests.

I love perforce but the free version allows only two client workspaces. Though we only have two programmers working on this project, we each have a Mac build, a Linux build, and a Windows build to work on. I have two Mac builds, actually (one for each OS). So we're well past the limit. Sigh.

#8 Thanks for the perforce suggestion. I did try it once but that was using linux. I didn't like their VC++ integration much, since it didn't have an uninstall to speak of. Once I decided the first time not to use it, it took me a while to get it all off my system. But now that I have an NT4 system sitting around, I think I'll try it again.

I can read the user guide to find out also, but personal experience is always useful to hear. Do your developers connect over the internet to check in/out files? If so, how well does it work?

#9 Wow! Using perforce on NT4 is a breeze! I had it downloaded , set up, and running in about a half an hour. I have connected over the lan to it on both the win client and the web client. Checked out the files, and everything compiled the first time (after I changed the files from read only of course). Now to try it over the internet.


Thanks again for reminding me. For those of you who are having trouble with CVS this is an alternative. Only 2 users for free, but thats the size of my team as far as programmers go right now. If we add more we'll just have to buy it.

#10 Hmm, that's weird. Using "-I !" when importing I got the core folder imported without problems. That was with cvs 1.11.1p1 on a Linux system (both server and client).