How do you manage code changes?

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

[gnirts]

Our team uses Subversion. It is supported by MPLAB 7.30 (just look in the help files under "Version Control" or something like that). The fact the machines are not regularly networked is not an issue. You create a repository on one machine with your base code, and all other machines can connect to it and perform what is called a "check out." You can then edit the code you checked out all you want, and later you reconnect to the repo and "commit" your changes. Performing an "update" allows you to receive the changes that others have made and integrate to the code on your machine. SVN (Subversion) has great internal differencing tools, and will be familiar to those who have worked with CVS. You can find it here: http://subversion.tigris.org/

I also suggest using http://tortoisesvn.tigris.org/ (like TortoiseCVS but for Subversion) and http://winmerge.sourceforge.net/ (A powerful file-differ for Windows)

You can even convert existing CVS (which Subversion is designed to replace) repos to SVN using http://cvs2svn.tigris.org/

Good Luck,
Robinson

[X-Istence]

I use Subversion with TortoiseSVN. Mostly because it is really nice to be able to go back a few revisions and see what changes were made and why i made them in the first place. See the above post for more subversion information.

[Timothy D. Ginn]

For openFIRST we currently use CVS but are in the process of migrating to Subversion (it was only last week that SourceForge rolled out Subversion support to all projects).

We're running this in an environment where contributors are (or have at various points been) spread across at least 3 different countries (and two continents). They both work well over dialup and/or unreliable connections (well, as well as anything can work over an unreliable connection).

For learning either the SourceForge site documents for CVS and Subversion are good. They've also got recommended software for both, too (Subversion is below the CVS one in that list).

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

[Eldarion]

I used CVS on Linux through the whole build season. It even allowed us to merge each other's changes pretty much seamlessly.

TortiseCVS is a great Windows CVS client.

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

[Keith Watson]

Originally Posted by Eldarion

TortiseCVS is a great Windows CVS client.

I used TortoiseCVS at home.

Here is a tip: After you have checked in a major revision of your code, tag it. The tag makes it easy to keep track of the major revisions.

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

[gnirts]

So it seems that others are using Subversion as well. A few questions about version control in general:

Which files in the code directory does everyone put under version control? Just .c and .h? .hex too? What about documentation?

And how often does everyone commit? Major revisions? Every compile?

Lastly, do people using CVS/SVN use the tools inside MPLAB or Tortoise?

Just Curious,
Robinson

[devicenull]

Originally Posted by gnirts

So it seems that others are using Subversion as well. A few questions about version control in general:

Which files in the code directory does everyone put under version control? Just .c and .h? .hex too? What about documentation?

And how often does everyone commit? Major revisions? Every compile?

Lastly, do people using CVS/SVN use the tools inside MPLAB or Tortoise?

Just Curious,
Robinson

*.c, *.h, hex files don't matter, they can be re-created.

Documentation? What documentation?

I commit usually after I get something working correctly.. every compile is a bit excessive, because about half my compiles are something simple, like switching a sign.

I use the tools inside MPlab.

[Cuog]

this will depend on the size of your progtramming team but the approach i used this year was to split up the work and merge eceryone's completed work manually, for example this year the driving code was written byt my team mate Tom and i wrote the autonomous i then got the user_routines file from him and added it to my project that had modifications in user_routines_fast and got the two running nicely. basically just subdivide what needs to be done and give spots for it to be placed then copy and paste

[Timothy D. Ginn]

Originally Posted by gnirts

So it seems that others are using Subversion as well. A few questions about version control in general:

Which files in the code directory does everyone put under version control? Just .c and .h? .hex too? What about documentation?

Generally speaking the version control systems work best with textual data rather than binary files. So, things like documentation, the .h and .c files, etc. would be good to put in. You can, of course, have binary data there too (like the .hex files, images, etc.), but, the version control systems generally won't give you features like comparing the changes from one version to another with that type of data.

Originally Posted by gnirts

And how often does everyone commit? Major revisions? Every compile?

The general rule of thumb we use is commit after any changes that are stable enough to have passed some very basic preliminary testing (e.g. no syntax errors and such). I tend to do it more or less every time I would ordinarily save a file (less any of those where it would fail the preliminary tests).

Originally Posted by gnirts

Lastly, do people using CVS/SVN use the tools inside MPLAB or Tortoise?

Since we're not using it for robot code (and thus not MPLAB) I can't directly answer that question. What I will mention (which may not be of particular relevance to you personally, but others reading this thread later may find useful to know) is that Eclipse (which I believe I've read from some other threads in the past can be used to program the robot, but that I use with the PHPEclipse plugin for writing PHP code) has plugins for both Subversion and CVS. I haven't used those extensively; I usually use the command line interface to CVS/Subversion (then again, I often develop these things when logged remotely into other boxes and anything else could be prohibitively slow).

[Donut]

We use a set of folders with different version names, and a good old USB drive. My job this year (other than doing a few tasks that had to be finished) was pretty much merging code and making sure everything got coded.

We should probably invest in something else though.

[Eldarion]

Originally Posted by Keith Watson

I used TortoiseCVS at home.

Here is a tip: After you have checked in a major revision of your code, tag it. The tag makes it easy to keep track of the major revisions.

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.