Adding version control to an existing project

Question

I am working on a project that has grown to a decent size, and I am the only developer. We currently don\'t use any version control, but I definitely need to start.

Answer 1

Technical issues aside, just get SVN and start using it. You will see the immediate benefits (looking at code history, diff-debugging to see what change introduced the bug that was not present last week), and you will never want to look back.

I, personally, do not like my source control integrated in the IDE. I use Tortoise SVN that integrates with Windows Explorer and lets you check in, diff, merge, etc files straight from the OS.

Answer 2

I'm more familiar with Perforce than subversion, but putting a project under version control is not at all hard.

Once you've installed and got your version control software running, clean out your code directory of everything that isn't a source (for instance, run 'make clean'). Then use just use the command to add new files to your repository, recursively. Follow that by a submit, and you are done. I recommend checking out onto a different machine and building at least once to make sure you have everything you need to build.

As for deploying onto servers, that's not really a version control problem. You would typically either put that into your build system (i.e. 'make testinstall', 'make install') or just write shell scripts.

Answer 3

1) Create a new repository - you can create it on the test server and later transfer it to a dedicated server/NAS if it makes things simple for you. 2) Import all your existing source code into the repository. 3) You can create using the 'svn' command line tool (and its related tools, like svnadmin) a batch file which will automate the upload and deployment process (the latter combined with the compiler of course).

You can find more information here: SVN book - just start read it - you don't need to read it all to start and get svn running. MSBuild - a build automation platform by microsoft, although it may be an overkill, depening on the size of your project.

If you have Visual Studio on the same computer as the batch file, you may use it to compile your solution, although I'm suspecting you'll hit scaling problems in the future.

Answer 4

I didn't see anybody addressing this part of your question/post:

Is there a tool that will automate the upload to the test, then the deployment to the live servers?

One gotcha is that Subversion creates hidden .svn folders in your working copy. One of the solutions is to use the svn export command. That will make a copy of your repository on another directory without the .svn folders.

As far as I know there is no automated tool for this. You can create a batch file that will issue the svn export command like this:

svn export C:\MyReporitosy\Path C:\DestinationPath

Just include this as part of your deployment process. Make sure to deploy your code from this exported directory and not your working copy. You should be fine then.

Answer 5

Import your existing base into a SVN repository, check it back out and begin working again.

Answer 6

To add to the previous answers, I would recommand also the obvious (but they should be made explicit) advices:

• choose a stable state of your project to import in your repository (whatever tool you choose)
• create immediately a label (or tag in SVN), once the import is done and 'checked' (like 'does it compile ?', 'have we get all setting files needed ?', ...)
• think about the different 'development efforts' you will need to do during the lifecycle of this project, and that will get you a good idea of what your branches should look like.
  (maintenance branch for an old version already in production while your are developing the next version, merge branch to isolate complicated merges, patch branches, ...)

Now, beware:

Is there a tool that will automate the upload to the test, then the deployment to the live servers?

That part of your question refers to a 'release management' process, and that is very different that 'version management'.
I am not sure the version tool you will choose can help actively. Especially when you consider there should be no version control tool on a production server (in order to keep the dependency of a production server with any tool to a minimum: only monitoring and reporting tool should be allowed, in addition of course of your programm - here a web server for instance -)