Keeping the tree in sync

[DtD]

Both are pretty much what we have done in the past, but it seems that if you do that the code tree (Like which files are part of a project) does not get synced, looking at some of the files in .metadata suggests the tree is stored there instead of with the project its self. Our .hgignore currently looks like http://pastebin.com/D13gKtFq I made it after experimenting with removing everything that looks like user preferences and other rapidly changing, useless files. However, org.eclipse.core.resources seems to be unable to strip down anymore than I already have or the project breaks.

EDIT: DOH! I just found out that you can have Windriver "Use Existing Project" the just a standalone project and it worked great. I guess the org.eclipse.core.resources folder is only like a cache or something. Kinda weird it ignores the project folder if it exists but expects org.eclipse.core.resources. Thank you both!

[Mike Soukup]

Here's what we do; we've been quite happy with it.

We keep all our code since 1998, including a bunch of test and prototype code, on an SVN server. We only put the source files there (plus makefiles for the old IFI years). No .project, no .wr* files, no objects. Nothing but .h & .cpp. Then in workbench we create a new project based on one of the FRC examples, delete all the .cpp & .h files that it created in the project, and add the folder that has all our files to the project (Right click on project -> New -> Folder. Click "Advanced", select "Link to folder in the file system", and browse to the folder). That way our code repository isn't cluttered with any of the junk that the IDE creates.

[basicxman]

Originally Posted by Mike Soukup

No .project, no .wr* files, no objects. Nothing but .h & .cpp.

We too do it like this, except using a much superior version control system (okay that is open to opinion of course), Git.

Sample .gitignore file:

*~
*.bak
*.cproject
*.project
*.wrmakefile
*.wrproject
Makefile
*.c
*.o
*.d
*.a

Originally Posted by Mike Soukup

Then in workbench we create a new project based on one of the FRC examples, delete all the .cpp & .h files that it created in the project, and add the folder that has all our files to the project (Right click on project -> New -> Folder. Click "Advanced", select "Link to folder in the file system", and browse to the folder).

Why not set default build properties for vxWorks Downloadable Kernel Module projects and simply create a new project?

[mikets]

Well, the .*project files contains the Wind River build environment preferences. If you don't check them in, every programmer in your team has to recreate the build environment. For example, we hit a limitation last year with our code that it got big and exceeding the "short call" distance. So I had to add -mlongcall to the build option. That modified .wrproject. If I didn't check it in, all the other programmers had to do the same to their build option. If I check them in, all they have to do is to sync the files.
The .*project files are like makefile. They are part of the project. If they are not checked in, it will be more steps for each programmers to add/remove/rename a file to the project.

[basicxman]

Originally Posted by mikets

Well, the .*project files contains the Wind River build environment preferences. If you don't check them in, every programmer in your team has to recreate the build environment.

Good point, however we have in-house documentation (to be released to the public) on how to set up a proper WindRiver environment. Given that most project files look the same, they are put in the ignore file. If there is something unique about a specific project, it can simply be tracked for that project.

[mikets]

But the basic question is: why not check them in? These files do not change unless you change the build environment, add/remove/rename a file etc. So they are not files that will be changed on every compile. So I don't see the disadvantage of checking them in. If they changed, other programmers should get that change anyway.

[basicxman]

Originally Posted by mikets

So they are not files that will be changed on every compile. So I don't see the disadvantage of checking them in. If they changed, other programmers should get that change anyway.

So in a normal situation, it defeats the point of version control. If it's changed, simply track it.

[Bot190]

As has been noted, My team uses .hgignore so that none of the build files are added to our repository. This helps keep the size down, and prevents conflicts.

There are upsides and downsides to not checking in the .*project files.
On one hand, if someone has their workspace setup differently, you don't have to worry about windriver not knowing where stuff is. On the other hand, as has been said, build properties have to be changed on each computer.