GIT and WindRiver

Technical C/C++
1

Does anyone have any how tos on getting GIT setup with WindRiver? I haven’t attempted anything yet and am posting this before i go out and do some research. Anything I find I’ll post here but would be thankful to have some input from others!

And good luck to all this season!

2

I know this doesn’t answer your question, but have you considered using git from the command line?

3

That’s my project for today as well. I found this very helpful answer on StackOverflow using the GitHub GUI: http://stackoverflow.com/a/15816653/1177139

I plan to create our WindRiver project normally, then follow the instructions in that answer to create a Git repo at that folder and sync it to GitHub. For setting it up on other team members’ computers, I’ll try following this guy’s process: https://github.com/vcarl/FRC830-Prototype/wiki/Getting-stuff-from-GitHub-to-WindRiver

I’ll post again with my results…someone has run off with our WindRiver CDs at the moment.

4

I’ll probably be going with using the command line, although i might be able to get WindRiver to do a micro-commit on every save.

5

I don’t think I could put up with that many commits - I Ctrl-S reflexively after every line. :stuck_out_tongue:

I’ll stick to manually committing (probably at the end of each day of the build season.)

6

We tried to use git last year. As a mentor, I introduced the students to git and the github GUI app. Eclipse (nay WindRiver) is a serious problem. There are several files that don’t play well with git. There are several articles that I found last year that indicated which ones were a problem. I have not been able to resolve the problems yet (due to lack of time rather than trying).

My number one goal in the next week or so is to determine proper procedures for managing git projects with Eclipse. I am also recommending to the students to use SmartGit HG. I use the command line for git on a regular basis, but the git command line is a little much for students to fathom.

My intention is to first work out the procedures for our team. I will publish the procedures here as well. The procedures will reflect my long experience with version control systems in general and git in particular.

If any one else makes progress, I will appreciate the information.

7

I didn’t have time to fully configure our Git repo today, but I imagine that I will have a fairly aggressive .gitignore when I’m done. We probably don’t need to commit anything other than the code itself, but we’ll see.

8

I’m the head software guy for Team 1967 Janksters. We used git quite successfully last year. We have a few items of heartburn, but I’ll cover that in a separate message. I thought I’d add that our .gitignore and .gitattributes files are available on our open source page: https://github.com/bobwolff68/FRCTeam1967

Our gitignore was one of the tricky items to figure out such that we could clone on a clean computer and build a replica from another computer.

While there are many lines below, the salient ones are:
/code/.metadata
and
/code/<projectname>/PPC603gnu

/code/JankyJoystickInvestigator/PPC603gnu
/code/JankyXboxJoystickTestjig/PPC603gnu
/code/CameraExperiments/PPC603gnu
/code/.metadata/.plugins
/code/.metadata/.plugins
/code/.metadata
/code/Testjig/PPC603gnu
/code/CompleteRobot/PPC603gnu
/code/TrialPrograms/PPC603gnu
/code/JankyRobotStarter/PPC603gnu
/code/JankyTaskTestjig/PPC603gnu
/code/SensorTestjig/PPC603gnu
/code/JankyActuator/PPC603gnu
/code/IluminsTestDrive/PPC603gnu
/code/JankyBattery/PPC603gnu
/code/WPILib_Sources/WPILib/PPC603gnu
/code/SmartDashboardTestjig/PPC603gnu
/code/UltimateAscent-2013/PPC603gnu
/code/SimpleTemplate/PPC603gnu
/code/JankyRobotDrive/PPC603gnu

9

We have our repository set up and I have our .gitignore to ignore all of the compiled files such as *.d *.c. You can take a look at it here:

We don’t have any more code than the basic template.

What I did was make a project, from the template. Then I created and cloned the repository. Then I just copied over the existing project files into the local repository directory. THEN, I imported the directory as a Existing Project.

10

Our .gitignore

PPC603gnu/
.settings/
.cproject
.project
.wrproject
.wrmakefile
11

When we used Git + WindRiver last year, we just set up our project so that code was in an external location (it’s an option when creating a project), had a separate src folder, and kept our code in that. I think it’s much easier than trying to set up a .gitignore for all of the crap WindRiver puts in the project folder.

12

Connor,
I would suggest that you really should include:
.cproject
.project
.wrproject
and
.wrmakefile

and not ignore these. These files are integral to a given project and rebuilding it in the same way each time. In a very small project which has zero modifications, you may be ok … but you could run into bigger issues in time. As a for-instance … if you look at the .-files in our Ultimate Ascent project, you’ll see that we have references to external files and in the .wrmakefile we have custom build steps which aleviate problems with the darned FIRST->DOWNLOAD plugin which doesn’t support being smart about downloading the appropriate final binary if you switch projects often (which we do).
https://github.com/bobwolff68/FRCTeam1967/tree/master/code/UltimateAscent-2013

13

IIRC we ran into issues with absolute paths in those files. Cloning a project does require some extra work, but we’ve done it in the past. Maybe we’re doing our paths wrong? Advice here would be appreciated.

14

Connor,
You are correct - pathing is a PAIN in WindRiver. We did, however, come up with a full fledged solution early last season. It is documented in:

The trick is to use the WS_ROOT_DIR variable. See lines #45-#47 in that file specifically. But the whole thing may be found as a good read. That’s our formula around much of it outside of the final output file being copied to a single hardwired location ALWAYS post-build. This makes it so the FIRST->Download plugin can be set to that location and never changed. Regardless of switching projects you’ll always have the most recently built binary output in the right location ready to be downloaded.

Hope this helps.

bob

15

I wanted to point out that WindRiver (and any Eclipse editor) actually keeps a local history of saves (about 30 of them) that you can use to compare in the editor.

If you right click a file in WR, there is a Compare option, under that select local history and it gives you several versions of the file to look at. You can change the settings to keep more files in the history as well.

This is very helpful for emergencies, but it gets easy to lose track if you are a reflexive saver.

16

I agree with Bob, excluding the project files isn’t a good idea. It’s also nice to have the .out file, so you can manually program the robot with a previous version without setting up a build environment.

This is the .gitignore is use


*.d
*.o
ctdt.c
ctdt.o
17