Is Subversion (Version Control) Necessary For A Small Development Group (1-2 programmers)?

I would argue for git, for two primary reasons trivial to set up repo. Cd into the directory, git init, and you're done logging! Using a vcs of any kind makes it easy / obvious / simple to log why you're making changes.

Having a dvcs in particular makes it really fast and easy to see when, what, and why one made changes. Since a dvcs has long information locally, it's fast and easy to look up, unlike svn on remote machines. These are apparently true for Mercurial as well.

They sure the heck aren't so easy for subversion.

1 Same can be said of other DVCSes e.g. Mercurial -> hg init – Jacob Krall Sep 18 '08 at 1:34.

Source control will give you peace of mind. I'm a mISV, and lost my system hard drive earlier this week. My code is in several Subversion repositories.

I had just finished re-organizing the code, so that I could just check out and go. I'm waiting for the new hard drive to arrive. I have the peace of mind that when the new hard drive gets here, I will be able to continue enhancing my product where I left off.

Yes, source control is a must. I use Sourcegear Vault which is free for a single developer.

When I wish to go to the shops, I take my car to transport the shopping home. It is not necessary to put gas in my car. I could choose to push the car instead, but why would I?

Likewise with choosing not to use version control....

I've always used some sort of version control for my private projects (#programmers == 1), in the beginning just copies with numbers, later RCS, then CVS, then subversion. The benefits to see what you changed at which point in time and why are priceless. So if version control is good for a single programmer, it cannot be worse for a team of people.

Even with a small team, version control like Subversion is important, not just to be able to compare between revisions but also to roll back to a previously working version. But all of this comes with added complexity. Instead of just saving the code, it has to be checked into the system.

Every major version control system has tools to easily check code in, and many will integrate directly with IDEs. However, this doesn't change the fact that there are additional steps that must be taken when saving code files. There is overhead in placing code in a version control system, but having working code to roll back to when a problem occurs can make up for this extra overhead.

Source control doesn't cost you anything but the time of setting it up. It's just a no-brainer.

Yes, even if you are the only person source control is a must. Of course you will not be using it to control who is working on which files, but having the ability to role back if you make a big mistake in your code is really a no-brainer.

I'm just throwing this out there, but I believe PERFORCE is free for up to 2 developers. Don't know how easy it is to set up. I would guess you'd want something that's easy to set up and use.

I am a single programmer and have been using it as a repositry for the last while with no problems but I keep hearing about horror stories. Is it really that bad?

Source Control YES. Subversion NO Subversion is appropriate for really complex stuff that needs to handle branching REALLY well. Otherwise it is not worth the effort of learning and maintaining it.

There's plenty of other more straightforward source control at a small size (I personally recommend PerForce) BTW I would rank Creating a build system is more important than version control. Now, with so few people it IS possible to manage source control by splitting up your work files carefully, but this does not give you version control (which is essentially automatically built into any source control you will find) At the very very least you need to be able to look back and find a version of your file from a few weeks.

Subversion is not overkill for small groups and but should not be thought of as a replacement for proper project management. Long story short- if people don't have a schedule and proper communication, use of version control is not much better not using and can cause more problems than it aims to solve. Questions you should answer while implementing version control: Who is responsible for managing the repository?

Do you have a release schedule? How do you communicate merging changes? What is the difference between your current source management (files, copies on a filesystem) and what you aim to accomplish with subversion?(hint, if you don't have a clear answer, don't use it).

How specifically will your use of subversion be incorporated in your project management plans?

It fullfills the need for a shared repository – Thorbjørn Ravn Andersen Jun 23 '10 at 20:02.

Consider this common case where fixes were applied to some unstable functionality "A" over a span of some months, say. The developer(s) edited multiple files during those several attempts and although functionality "A" got fixed but another functionality "B" got broken. This is generally realized after some time and it can only be recalled that functionality "B" was working at some point of time.In the presence of version control all a developer(s) has/have to do is go through the previous revisions and reach the revision(s) which broke "B" and just undo those parts.

Using a simple divide and rule to reach the error versions makes it so fast (if current revision is 2000, check for 1000 - if it works there then check 1500 ...). In the absence of version control, developer(s) has/have to at least think fresh about how to make it work again and thus have to spend fresh time on something for which complete time was spent. Now, this may be one of the hell lot of functionalities of the project and even the single developer may forget the exact specifications.

So, a spec lookup is needed and what not? I have many a times felt like punching some fellow experienced developers in the head who didn't use version control in a project they were working and later I had to apply some fixes on the same project. One such developer used to feel lazy setting up the SVN and maintaining it and moreover he would not tell me properly when I would ask him how exactly it was working (when I was assigned to work) because he would be busy with some other project.

Laziness is a common human weakness. Anybody can feel lazy. I bet most people would feel lazy or rather more irritated in rethinking something which was already done in the other case (absence of version control).

So, which one is better? Being lazy before or being smart and lazy afterwards.

I'd attempt to be the first to answer NO. It takes time to learn how to use it effectively. And it can be confusing to new users.

Rolling back? Merging your changes together? Being able to branch your project?

Or be sure that all this stuff you are deleting now is NOT going to be lost forever? Its helpful in only a few cases, and I'm not 100% sure that the 10 minutes it takes to find SVN or TortoiseSVN and download it, + the 30 min to learn a little about the use is worth it. OTOH: Is.Your.Partner.

*)&%$#. Crazy? We have several possible tools for use at work.No broad support for either CVS or SVN but rather a commercial relative for most things.. I use tortoiseSVN on my pc to handle my own WORD documents and spreadsheets, and I find that the MERGE capability really helps when others edit my spreadsheets and send them back to me.(I tend to do the merge by saving the different versions as an xml spreadsheet.

) or to back up changes when I use a doc or spreadsheet on more than one PC. However ARGUING about it doesn't work. Show her/him how to install it, and demonstrate a little editing of the same document.

Or let them train themselves at software carpentry.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.