Workbench with SVN problems

We have a rather large group of programmers this year, and several of them have extensive C++ knowledge. We used WindRiver Workbench last year, and the team agreed to use it again this year. Last year we also used SVN as an archive tool, but with only a few programmers there wasn’t much of a need to use it during development. This year we would like to use SVN (or maybe Git) as a versioning tool on all the programmers’ computers.

The repository is all setup, and the first few “share”, and “checkout” tests worked fine on my Windows7 desktop computer at home. The trouble started when we loaded the development environment on several notebooks, and netbook computers running Win-XP, Vista, and Windows-7. Some of them work some of the time, all of them have problems building projects they checkout some of the time. It is not consistent at all. I checked out the same project 10 times in a row (changing the name each time so they had unique directories in the workspace). Sometimes they will checkout with the following in the name:

“(Host OS (Native Development) Downloadable Kernel Module Project)”
If it does, there is no hope for it building and creating the “.out” file.

It must have the following in the project name to build:
“(Wind River VxWorks6.3 Downloadable Kernel Module Project)”

We do nothing different from one checkout to the next. In 10 checkouts, 3 were OK, and 7 were not.

The netbooks seem to be more prone to this than the systems with more performance. There are no errors during the checkout, it just doesn’t create the proper project.

Very frustrating….

We have installed the Jan 9th updates for LabView, and WindRiver WB
For SVN we have installed the Subclipse plug-in to Eclipse:
http://subclipse.tigris.org/update_1.6.x
We are using:
SilkSVN Vers 1.6.5
TortiseSVN Version 1.6.6.17493

One other note. Sometimes even after a good checkout the first build will not create the .out file. The “PPC603gnu” directory will only have a Makefile in it. We found that if you delete the PPC603gnu directory, and build the project again, it will recreate the directory, and build all of the objects and produce the .out file.

Hi Mike,

Can’t comment on your specific setup, however I can tell you we are using SVN without any difficulty so far using Google Code for our SVN server, and the Subclipse plugin.

I have no instructions for the Google Code setup, but it’s quite self-explanatory.

For Subclipse, here is the procedure we’re using courtesy of student Zwe Gwelithini from 1310:

  1. First go to http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240 to download Subclipse
  2. Extract it to your desktop
  3. Open Windriver then in the menu tabs go to Help ---->Software Updates —> Find and install
  4. Click “Search For New Features To Install”
  5. Click “New Local Site” and then click the Subclipse folder that you extracted to your desktop
  6. Click “Finish” and then wait for the update to finish
  7. Restart Windriver after the update is finished

We too have installed all the mandatory updates, and everything appears to be working.

-Mr. Lim…

how are you checking it out?
file>new>Project Checkout Projects from SVN?

is it through apache or svnserve (http:// or svn://)

We are using XP-Dev.com for our SVN Repository. We signed up with them last year, and they let us keep our large free account even thought they charge for these accounts now.

We do all the Checkout, Update, Commit, and Branch/Tags functions from within WindRiver Workbench. We don’t do anything by command line. We did load TortiseSVN because it is a great GUI for probing around and reporting on the status of the repository, but don’t use it to touch the files. That is one reason I went with SVN, because it was so well integrated into Workbench.

After last night we narrowed the problems down to two. The worst is the random event where during a checkout; the new project is not correct and cannot be used. It can take up to 5 tries before it will checkout correctly. The other is that we had trouble building projects where we changed the name of the project as it was being checked out. The build files still look for a few folders based on the name the original project was created with. We fixed this by picking unique names when the project is created the first time.

Thanks for the help.