How do you manage code changes?

[X-Istence]

Originally Posted by Eldarion

Thanks for the tip. I was aware of that and have been making good use of it.

Do you have any experience branching from the main revision? I have been running into some problems, mainly I don't know how to merge the branch back into the head revision.

I make branches for when something changes radically, and I want head to stay the same for a while.

[phrontist]

I use subversion with Tortise . Elite Frontier will provide SVN hosting to FIRST teams for free (they already host 116 and 1418).

[Keith Watson]

Originally Posted by Eldarion

Do you have any experience branching from the main revision? I have been running into some problems, mainly I don't know how to merge the branch back into the head revision.

I used cvs (including scripts written on top of cvs) for many, many years. We did not use branches very often. More than 95% of our stuff was done on the mainline. Branching is best used when you need to do isolated development with version control while the mainline goes through several revisions.

If you use TortoiseCVS check the User's Guide, it's simple. If you use a flavor of regular cvs look for "cvs update -j branchname". This means "join the branch to the mainline". Here is some documentation on Branching and Merging.

[Joe Ross]

Originally Posted by Keith Watson

If you use TortoiseCVS check the User's Guide, it's simple. If you use a flavor of regular cvs look for "cvs update -j branchname". This means "join the branch to the mainline". Here is some documentation on Branching and Merging.

Be sure to read the section Merging from a branch several times. I missed that part the first time I merged a branch and it caused me grief later on.

We ended up with only one branch, when I completely rewrote our PID framework. I worked off the PID branch while everyone else worked from head.

[Joe Ross]

We used a dedicated laptop running Debian Linux (stable) as the server. I used cvsd to chroot the cvs pserver process. Each team member had a unique login and a trivial password^*. I used viewcvs (now renamed to viewvc) as a web interface to let anyone without cvs knowledge browse the repository. We stored all kinds of stuff in the repository, not just our code. For example, we stored all the rules and updates and other documentation, our team roster, even photos of the robot.

We do not have internet access at our build, but do have an internal wireless lan. When we were at our build location, the cvs laptop is there. When we aren't building, it's at my house accessible over our dsl connection. The laptop ran a dns server such that when it was at our build location, you could use the same address as when you were accessing it over the internet.

The commit philosophy we used was such that you should commit after testing when a test platform was availible, but if a test platform wasn't availible commit once you were happy and the code compiled.

For our programming directory, we stored all the .c, .h, .lkr, .lib, .mcp, all the text readmes, and the .hex file. We wanted to have a complete history of the hex file so we could pull up exactly the program we used for each match, without worrying about library changes or other things like that.

Right now we have a tag for the state it was after ship, and for after each fix-it window. We'll also have a tag for the code as it was in the robot for each match so that the drive team can easily request an old version. Depending on whether significant changes get implemented between matches, we may end up branching.

^{*We'll probably be switching to a more secure form of authentication next year, I just wanted to get something that worked easily out of the box}

[Eldarion]

Originally Posted by Keith Watson

I used cvs (including scripts written on top of cvs) for many, many years. We did not use branches very often. More than 95% of our stuff was done on the mainline. Branching is best used when you need to do isolated development with version control while the mainline goes through several revisions.

If you use TortoiseCVS check the User's Guide, it's simple. If you use a flavor of regular cvs look for "cvs update -j branchname". This means "join the branch to the mainline". Here is some documentation on Branching and Merging.

Thaks for the links. For some reason I was finding it difficult to locate CVS documentation.

[Keith Watson]

Originally Posted by comwiz7

Every time I make a major revision, I copy the old code to another folder and call it like FRC2006Rev1, the number being the version or whatever. Then I save the new change as FRC2006Rev2 and so on...I'm assuming there is a better way to do this. Anybody want to clue me in?

Use one of the version control systems mentioned in this thread.

Copying entire folders like you are doing works. Just be very careful if you are going to open a workspace in one of the saved folders. MPLAB stores the absolute pathnames to the source code so it is still using the source files in the original folder, not the new folder!

[devicenull]

Originally Posted by ericand

I'm curious about experiences with the use of source code repositories (CVS, RCS, DARCS,...) and if anyone has been able to incorporate them into their teams development process.

We've tried but the use of a central repository has not worked well due to the fact that our development is on machines that are not regularly networked together. We archive the best code of the day and use it to seed a development directory for the next day's work.

What we have done that has worked fairly well, is use a contextual diff tool (KDIFF3) that provides a quick way to compare and merge two source directories. Using this tool, we can quickly see what has changed from a previous day's work, or we can merge separate development directories into one.

Check out SVK, it's basically a decentralized SVN. I've never actually used it, but I hear its pretty good.

I've got SVN installed on my laptop (Hint: You don't need a server to use SVN with, file:/// repositories work fine). When I get home, I run a batch script that backs up the SVN tree to my desktop, then I have another script there which copies it over to my linux SVN server, so I can use stuff like ViewCV It also has the nice advantage of me having three seperate copies of the code, so I can't lose it.