Keeping the tree in sync

[DtD]

Our team is using Mercurial for version control (but this should apply to any vcs) and I am running into issues with Windriver/Eclipse's workspace tree management.

It seems even the smallest of change causes the ".metadata\.plugins\org.eclipse.core.resources \" directories to change completely. Which would not be aweful except they are binary files instead of nice XML files. I'm worried about needless merge conflicts coming from these files, but they are what powers the file structure in the project view. It also seems there is no way to properly add existing files to an already-existing project, so asking people to manually update there trees is not an option either.

There are VCS plugins for eclipse, but we already spent a lot of time getting everyone command-line savvy and I'd rather not stray far from what we already know.

How have other teams gotten around this problem? Is there a way to export the project tree as a pretty little XML file? (Like MSVC natively does.)

~David

[mikets]

We use Mercurial too but we don't check in anything in the .metadata tree. In fact, all we check in are the real source code and the four .*project files and nothing from the PPC603gnu directory either. The PPC603gnu directory mainly contains the compiled binaries. So you don't want it to check in a new version of the binaries just because you compile it.

[perlgerl]

Modify your .hgignore file appropriately.

[davidalln]

For my repository, I shamelessly copied 166's .hgignore file (and edited it to match our project and work for git). It makes sure that there are no continuity issues over multiple computers, as the binaries stay separate. I would suggest that you copy this file to the base of your repository.

http://code.google.com/p/framework16...owse/.hgignore

[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.

[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.

[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.

[DtD]

We ended up going with the "Store the project folder and import it" approach, and things seem to be going great so far. Since all of us are developing in VirtualBox VM's and have identical environments for the most part, I don't think syncing the build settings will become an issue. Thank you everyone for your suggestions.

~David

[demosthenes2k8]

Oh wow. Using Virtualbox is a really good idea!

[DtD]

It works great, I just install it once and we deploy it to several school laptops. No issues with school laptop user rights, and if something goes wrong with one, we just open another, "hg clone" and bam! Very little time lost. Plus, over a Giagabit connection (HINT: The Linksys routers they gave veterans pervious years are Giagabit) it takes about 2 minutes and 43 seconds to transfer our 12 GB virtual hard disk image.

~David