Version Control
 

As any decent, self-respecting programmer knows, version control is a very important bit of software development -- even moreso, perhaps, when applied to the competition setting, when time is of the essence. However, for whatever reasons, many a programmer often finds that it is at the end of his list of things to do (a list that does not always get completed, regrettably). But, as most things go in the programming world, we must re-learn the things we already know the hard way, before we really know them; inevetably, this means that experience, particularly the not-so-good variety, is a cruel, yet necessary master.

For my team in particular, last year's competition has become somewhat of a wake-up call in this regard, and we now are trying to do whatever we can to avoid this problem again. Further, the importance of version control has become underscored by the introduction of multiple developers this year. So, while it might be possible for a single person to keep in his mind the mangled and numerous ad hoc schemes of so-called "version control" that creep up when they are unplanned (and, indeed, all experience has shown otherwise), the problem becomes a serious one, for sure, when multiple persons are introduced into the development environment.

Further, I happen to be pretty sure that this is not a unique problem of my team; it seems to me, that other teams must have some experience with different version control systems. My question, therefore, is thus: What version control system do you implement (or recommend) and what problems have you faced with it in terms of usability, integration, and practicality for the FIRST competition environment?

Thank you,
Mark Rawls

Re: Version Control
 

Last year, me and the other programmer (Superdan) just did it cheesy-style, comment on what you did to the program at the top of the .bsx file, save it based on the date (12-05-03.bsx). All saved in one directory, periodically back it up, fin.

This year though, we have several programmers, and yeah, I see that a problem could arise.

One possible solution I just though of, which is way overkill, and may not work for everyone, is to design a website, that would be run from the localhost (whatever computer you use to program on), and you simply "upload" the new file(s), and a small description of what was changed, who changed it, and if it was loaded into the robot, whatever.

Yes, it's completely overkill, but being snowed in (sort of) makes you think too much ;).

I'm sure a similar program could be written in C++/Java, but I don't know either well enough to do something like, whereas PHP/HTML I've done a bit of work in, so maybe I'll try to start some sort of crazy Version Control software.

If anyone sees any huge flaws in my idea, please, point them out, cause it's late, I've been up all day, and I'm starting to suffer from "Cabin Fever". Stupid snow and lack of friends/sledding hills that live within walking distance...

Re: Version Control
 

Wildstang uses CVS for version control, and it's been a really great experience. Recently I have also looked into Subversion, which is basically a better CVS. I don't know if we'll end up using it this year or not, but it's also a nice tool. (Both are free, BTW). I'd highly recommend to other teams who are just doing the "name the file with the date" type thing to set up a CVS system. It's not too bad to set up, and it doesn't even need to be installed on a server. You can just use it on a local machine if you want. Even if you develop all by yourself, it's still beneficial. And, of course, once you have version control set up, the rule of thumb is: commit early and commit often. Also, make liberal use of tags. We tag our code anytime we reach any sort of milestone, as well as tagging the version of code that ships with our robot and creating a tag for each competition we attend. This way we can always know exactly what the code looked like when we competed at a certain regional or whatnot.

Re: Version Control
 

What do you expect from a team run by software engineers?

To expand on what Dave said, CVS saved us lots of time & energy. It allowed two groups to easily work on the same files at the same time without any risk of overwriting each other's changes. It allowed us to check our changes against a known working version to figure out what we messed up. And it was critical at GLR when we were debugging on practice day. We had to look at previous versions of the file to figure out what we did wrong. Without any version control our software development would have been much tougher.

Re: Version Control
 

This is what I was wondering about myself. I've used CVS for other (non-FIRST related) projects, and, in general, think it is very useful. However, I feel it would probably be best to run CVS locally at the competition -- we only have one laptop for programming, anyway. I wasn't aware how to do this, so I did some research on cvshome.org and found this (and not much more):

Source [cvshome.org]

What are the issues of using CVS with windows that are pertinent (windows bashing aside, of course)?

Well, after some more searching, I found a help file for TortoiseCVS that'll let me get a local repository -- it's the one I have installed, after trying WinCVS and not liking it much; are there better ones out there? Also, does anyone know of any possible issues with setting up a server for build season, and then using a local repository at competition?

For an idea of just how helpful this will be ... consider that two years ago my brother had the ingenious idea of naming successive versions of programs so that their values got closer and closer to pi (3.14159...). Well, not that there's anything wrong with that, per se, but he didn't tell anyone, started with a 9, and there was some bit about perfect numbers thrown in. Needless to say, when one of our mentors was looking through the code, he became somewhat confused.

Re: Version Control
 

I'm afraid I can't help you much there. We run a networked CVS server on a Linux machine during the build season, and when we travel we have an old laptop with Linux loaded on it that we copy the repository to and work from there. So unfortunately we don't have any experience with using Windows as the host for the repository...

Re: Version Control
 

Which brings up a good point... if the software for windows in terms of CVS sucks, perhaps you might want to run Linux...

Re: Version Control
 

My team has 4 programmers, and 2 computers in the schooly running linux. As we are mostly in the learning C stage, i havent done anything about CVS yet (as i am head of the programming team), but i think it could be useful when we really get going. I have been reading a little bit about it, and it dosent seem overly difficult.
I am quite experienced with Linux, so that wont be an issue, but how hard is it to use cvs, and is it really worth the trouble for just 4 programmers, when they could each be assigned their own module to write, then just stick it all together.
Thanks

Re: Version Control
 

The real question might be how much it sucks. And how much it sucks to get everything working for Linux (and then explain to the new students interested in programming how to use it). I re-read the thread about using linux, and it seemed to trail off at the point of porting the IFI loader. Any news on that? Anyone tried using purely linux to work on the EduBot and had any success?

Not very hard at all. There aren't that many commands you need to use regularly (and there's a nice guide here).

Well, the main strength of CVS is that if those areas overlap, when it comes time to "stick it all together" it gives you a helping hand. But also, another main strength is that it makes it very easy to, say, roll back to the last working version (but then again, things never break at competition!) Whether or not it's worth it depends on you, but I would say it wouldn't be a bad thing to look into.

Re: Version Control
 

It'll happen when someone who can do it feels like doing it. I'll try it myself once I get the prototype the engineers are building (with this year's edu controller). Maybe one or two weeks? Someone want to start now?

The compiler and linker and all that stuff seem to work fine through wine. I might try replacing them with gpasm and sdcc, but it seems too much trouble right now.

Why don't you just setup some small linux box as a cvs server and let students use whatever platform they want?

Re: Version Control
 

Oh? So WINE works fine with the IDE and the entire package? Or are there things it doesn't do?

What version of wine?

Re: Version Control
 

Wine 20031118. (Basically, the latest one)

I don't know if the IDE works because I never bothered to try installing IE, but the compiler and linker work. They're the important programs.

You'll need to use the native windows version of msvcrt to avoid problems with the compiler failing to spawn helper programs. You'll also need to manually specify the header directory, and maybe some other directories too. I've created a hex file by manually compiling and linking files through wine, but it hasn't been tested since I don't have access to this year's controller. I didn't see any errors during the compile, so I assume the hex files should run fine. (Never know until you test...)

Re: Version Control
 

So... is there anything that doesn't work? If it's compiled there's a linux tool to transfer if I remember correctly... it's in the linux thread I started.

Re: Version Control
 

See Linux thread here: http://www.chiefdelphi.com/forums/sh...ad.php?t=22134

Actually I looked at the link you supplied, It doesn't appear that the programmer you linked to will work. The IFI controller actually has a serial bootloader running on it to program it. See my comments towards the end of the Linux thread.

Speaking of which: Mike, have you had any luck writing a programmer? (Since you seemed to express interest in that same thead)