To SVN or not to SVN?
 

Hello all,

One of the things that I'm trying to decide about programming this year is whether or not our team is going to use subversion. We're probably talking about 2-3 programmers. In previous years, we haven't used it--but last year the code got nigh-impossible to manage(we had like 7 or 8 projects with names like "Lario Kario final PID") and one situation where someone accidentally downloaded the code for a different robot at a practice day(making one of the chains fall off)

Anyway, I was wondering what experiences people here have had with subversion. None of us has actually used it before--is it difficult to learn? And how much value would it be to a team of this size?

Re: To SVN or not to SVN?
 

I'm not a programmer, but from what I've heard on these threads, using a Subversion-based system really adds many advantages, even to a team of just one programmer Here's some of the advantages I see in a Subversion system.

For Code Backup:
i think Austin said it quite nicely in an earlier thread: For Code Management Between Multiple People:
If there is any time in which multiple people are working on the same code, I see a benefit for a SVN system. I've never used one, but I would imagine that it would be much easier than manually merging code.

In conclusion, you may never think that you would need a Subversion system, and in actuality you probably don't need one. However, it is certainly a great thing to have that can help your team of programmers immensely.

Re: To SVN or not to SVN?
 

It is not very difficult to learn at all. Version control can be very useful even if you only had a single programmer; in that case it would be used only for versioning and not for merging.

I will personally be advocating that my team use some type of version control this year even though we are using Labview and will not be able to take advantage of merges.

We had a situation last year that it would have been VERY helpful to revert to a previous code version but the new version was saved over the old version.

Re: To SVN or not to SVN?
 

Subversion or some other version control is used in Companies every day. It can be used for software all the way to CAD designs.

There has been some topics about SVN hosting lately:
http://www.chiefdelphi.com/forums/sh...threadid=70845
http://www.chiefdelphi.com/forums/sh...threadid=70865
http://www.chiefdelphi.com/forums/sh...threadid=70013

SVN is really nice if you have multiple programmers and working in different locations. If you always keep the latest version on the server you can get it from any computer that has the Subversion software. The subversion software is all open source.

Do Note: you will read about the SVN Merge feature. This will not work well if you are using Labview Programming. If you are using C/C++ code the merge feature works great because it is text based.

There are some Explorer based systems like TortoiseSVN.
There are also some great GUI based systems like RapidSVN.
If you have a server you can easily setup a server using VisualSVN Server Edition.

If you have any more specific questions feel free to IM/E-Mail/PM me and I can answer them. I have been using SVN for almost 4 years now.

Re: To SVN or not to SVN?
 

Use a version control system! It is extremely valuable to have with a single programmer, and as you add programmers, the value of a version control system grows exponentially.

As for experience/difficulty to learn: I currently work at a company of about 30 people. Everyone in the company (not just those working on software) uses subversion. Nearly every document goes into subversion. This includes source code, as well as specifications, inventory control, demos, presentations, etc. As a company, we standardized on TortoiseSVN, though people are free to use any SVN client they choose (I use the command-line client). Most people in the company had never used any version control system before, but given a short presentation everyone picked it up fairly quickly, uses it regularly and sees the value of having it. A few people have occasional problems (almost always due to forgetting to "update"), but they know who to ask for help (me), and I've always been able to talk them through fixes.

My recommendation (especially if most people who will be using it have never used a version control system before) is:
- use a version control system (subversion is a great choice, though there are plenty of other good choices too)
- have one person become an expert at svn - learn all the basic commands; learn all the fancy commands; the internet has lots of resources for learning svn
- have the expert give a presentation of the basics to everyone else - just cover "here's how to check out our repository" and the basic commands (update, add, remove, commit, resolve); don't try to cover everything
- set up a section of the repository as a test section for everyone to experiment with
- eventually everyone will become an expert


The only difficulty that I have had with using SVN within the context of FIRST is that various problems will arise if you do not have constant access to the server (e.g. no internet access at regionals; intermittent internet access from your computer lab; etc). This is a surmountable problem, and NOT unique to using subversion. From what I've heard, certain other version control systems handle being "offline" better than subversion, but I do not have any experience with them.

Re: To SVN or not to SVN?
 

To Git!

I've tried CVS. I've tried SVN. But I've fallen for Git.

Last year the Windows clients left a lot to the imagination, but now msysgit works wonderful, GUI included.

What I really like about it is that a central server is not needed. At school we cannot push commits up from our programming computer and we cannot use the school computers for programming. Git is lovely.

Branching is a breeze, commiting, cloning, everything. I don't have much experience with merging, and I don't imagine I will since we are using LabVIEW this year which pretty much eliminates the possibility of merging (binary files).

If you decide to poke around with it, you can PM me or send me an email. I'll be glad to help.

A way to manage code is a necessity! For years we just kept making copies of the project folder.. and didn't name them well. D=

http://code.google.com/p/msysgit/
http://en.wikipedia.org/wiki/Git_(software)

Re: To SVN or not to SVN?
 

SVN is not the best choice considering that LabView is a binary format. However, it's better than no source controlling either.

You have some alternatives like git, but SVN seems to be the one with most clients and "ease". If your team mates love the commandline, git may be a little easier and "cleaner".

However, even if you don't need version controlling, it is nice to have a central repository for all your code, side projects, accidents, experiments, etc.

Team 2502 has a working Trac with SVN repo and it's a really nice system when you need to quickly download a single file or something.

Plus, we can attach messages to the commits so we know what the person was thinking and what the person was doing. Our programming team isn't large, it's mainly me and few other guys just working with me on my screen, etc.

Go with SVN. Especially if you know someone that can set up Apache with svn module. I set it up on my basement server and it's really nice. Even at school with locked down ports, I slip right through port 80 and a lot of convenience.

keehun

Re: To SVN or not to SVN?
 

When programming with multiple people, you definitely want a version control system. SVN happens to be popular, but I don't recommend it, for FIRST use, it is centralized, which means you must be connected to the Internet if you want to check out a past version or make a quick commit. In features which may not be directly relevant, SVN doesn't have tags (it uses a really dirty hack which irritates me to no end instead).

In FIRST, benefits of a revision control system are you can trace who wrote what line (a "blame"), if you have a cool feature which you want to test, you can branch from the current source and merge it in if it works, or delete it if it doesn't, without touching "production" code. Whenever you test that code on the robot, you can "tag" that version with a name (instead of a meaningless number) whenever you test that code on the robot, going back to a working version is very helpful.

Personally, I highly recommend a decentralized revision control system. The benefits of a decentralized revision control system (which SVN is not) is that merging becomes much easier, since the distributed capability is very dependent on it. Most importantly for FIRST, you can make commits and inspect the entire history without an Internet connection, and you do not need to worry about locking files that you are editing on. For this, I HIGHLY recommend Git, because it is fast fast fast, packs the entire history into files smaller then a single SVN checkout (!) and merging is so easy it is fun. Git tracks content, not individual files, so you can even track a line of code as it has been moved around different files. If you can get a system going, taking the time to learn Git (or any collaboration friendly revision control system, e.g. not RCS/CVS) is highly worth it.

Revision Control with Git for FRC Teams Very good document I think (of course I am a bit biased, I wrote it)

Re: To SVN or not to SVN?
 

Wow, thanks for all the advice!

After reading some literature and conferring with some of the other programmers, we've decided on a Subversion system hosted on Google Code. Now I just hope it doesn't eat our code on week five somehow*gulp*

Re: To SVN or not to SVN?
 

The good thing is that even if the subversion server crashes and loses all the data, everyone that has checked out the repository has a local copy. In other words, you're no worse then if you didn't have revision control.

Re: To SVN or not to SVN?
 

Good point. Also I would imagine Google keeps good backups what is more likely is someone makes a corrupt checkin, in which case it is extremely easy to roll back to the last known good code.

I am a Software Developer for Purdue University and we use Microsoft's Team Foundation Server every day although it is not Subversion, CVS, Git, or others the idea is still central to professional programming.

Re: To SVN or not to SVN?
 

LOL, I guess I'm just paranoid about having my code stored somewhere else:)

Re: To SVN or not to SVN?
 

Git all the way as well!

Works on windows now, best source control for mac and linux, it's distributed, and much cleaner than subversion's .svn directories.

If you're going for version control, I strongly suggest git.

Re: To SVN or not to SVN?
 

Thanks everyone for the great suggestions. I think we will give Git a try.

Will the Labview version FIRST teams use this year have a tool to see the difference between two versions of a VI?

Re: To SVN or not to SVN?
 

Before you commit (hehe, pun) to Google Code, I'd suggest that you check out Beanstalk (http://www.beanstalkapp.com/) if you're interested in privacy. Its free plan is a bit stringy (3 users, 1 repository, 20MB), but its "Personal" plan, which if $15/month, is a good deal if you're team is willing to pay for it.

Our team is using it and we absolutely love it. It's front-end web application is excellent to view and manage commits and changes, as well as download any part of the code you may need without having Subversion installed.

Beanstalk + TortoiseSVN is a great combination for someone looking into simple version control. Git may be technically superior, but, as of now, subversion is simpler to manage.

Re: To SVN or not to SVN?
 

This is a random message but I wanted to share this link:

http://www.svnhostingcomparison.com/

Also, if you guys want SVN Hosting, Team 2502 will do its best to host it for you if you want. PM me.