Best Way To Add Version Control To Existing Project

Question

Hey guys, I am currently working on a project and it's grown to a decent size, but I am the only developer. We currently don't use any version control, but I definitely need to start. I wanted to use Subversion but I was wondering what would be the best way to transfer an existing project to it.

I have a test server that I use for developing new features, then transfer those files to the 2 production servers. Is there a tool that will automate the upload to the test, then the deployment to the live servers?

All this is developed in ASP.NET using Visual Studio (don't know if that matters)

Answer 1

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

Answer 2

To expand a little on the previous answer...

1) Create a new SVN repository
2) Commit all the code you've worked on so far to it
3) Check all that code OUT again, to create a working copy on your dev machine
4) Work!

It's definitely not a hurdle, really.

Answer 3

You should look at Visual SVN, which integrates seamlessly into Visual Studio.

Answer 4

Subversion Server install... Subverison Client Libraries instal...

Install Ankh for integration with VS Install Tortoise for File Manager integration

In File Manager, right click on top level direction with Solution... Import...

Answer 5

It may be overkill for what you require but creating a SVN repository on one machine, and then on another setting up an contious integration server. TeamCity is one I would recommend. (you may also be able to use virtual PC for this if hardware is at a premium)

This will allow you to add the custom build steps to deploy onto the production servers once a build is complete and tested.

TeamCity for more information. Thi also provides a plugin into Visual Studio as well

Answer 6

It is easy to start using Subversion. Download TortoiseSVN, which integrates SVN into Windows Explorer. Download AnkhSVN for VS integration. Set up svnserve as a Windows Service (it's in the docs).

Then all you do is check out an empty directory from svn and copy all your code files into it. Then add them with Tortoise, and commit. When you change files in Visual Studio, Ankh will show you which files you've changed and you can commit them there.

We do all our deployment with NAnt scripts, although you may find batch scripts and xcopy sufficient.

Answer 7

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 8

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 9

+1 on the answers provided by Joe and Steve.. I would also mention that it is important to set up your ignore lists or SVN Props so that you don't check in user files, resharper setting.

Also make sure you include everything that may be needed for the build, such as build scripts, 3rd party assemblies, external tools such as nunit, nant etc

While you are at it, I would highly recommend you look at CC.net, and getting continuous integration server installed to automate your build.

Having source control is one thing, using it properly is another entirely. Remember to check in frequently and early.

Answer 10

The easy answer is Subversion along with Tortoise SVN.

I've used Subversion with visual studio, and I've implemented it with an existing project. There is a free Visual Studio plugin called Ankh, which I used with some success. However, I have had some issues where Ankh refuses to stay in sync with the real state of the files as reflected in the .svn metadata (it did things like insist a file needed to be updated when tortoise would show me it was up to date). In these instances, a visual studio restart fixed the issues, but that is painful and tedious for me.

Currently, I stopped using Ankh and just work my project as normal in VS and then use Tortoise and windows explorer to check them in/out. This works flawlessly. No VS refreshes or restarts necessary.

Answer 11

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 12

Version control and deployment are two separate issues (although a good version control system can make the deployment a more consistent, reproducible process). Once you have your version control server set up you can use a set of simple script/batch files to automate checking the code out and deploying it to the server.

Answer 13

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 14

No SVN server required.
Use Tortoise Mercurial http://sourceforge.net/project/showfiles.php?group_id=199155

Setup local repo
1) Download and Install
2) Open an explorer window to the base directory of you project
3) Right-Click -> TortoiseHG -> Create Repository Here -> Ok
4) Right-Click -> HG Commit...
5) Type your commit comment, select which files to track, and click Commit

Setup remote repo over file share (other transport methods available)
1) Open explorer window to remote folder
2a) Right-Click -> TortoiseHG -> Clone a Repository
2b) Alternatively, just copy your local repo over

Updating remote repo after committing local
1) Open explorer window to remote folder
2) Right-Click -> TortoiseHG -> Synchronize
3) Select "Update to new tip" in Pull menu
4) Enter the path to your local repo into the "Remote Path:" input box 5) Click Pull

Answer 15

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 -)

Answer 16

I wondering why you had chosen Subversion? If your project is not using any vc, may be you should consider to use Mercurial or Git either.

Their stronger point is that they don't need a central repository, that means that your programmers can checkout your project, go to their home, work (without having to have a connection to your servers), and the next day come back to the office and sync their repositories.

If SVN is not a mayor requirement, i recommend to consider any of both dvc systems.

Answer 17

in addition to all the other comments about the practicalities of getting the project under source control I'd encourage you to take a look at Streamed Lines: Branching Patterns for Parallel Software Development as guide to code line and branching policies - might save you some re-work later.

Also Eric Sink had a great collection of posts introdcing the various source code control concepts - Source Control HOWTO

Answer 18

I have recently started to love the simplicity of Bazaar to solve the problem of starting version control after already having hacked on an application for a while.

With bazaar it is really only a few simple commands: 1) bzr init 2) bzr add [the files you are interested in] 3) bzr commit

Note that this does not setup any central repository. But you can do that as well.

Regarding using it as a deployment tool I am quite sure I read something about it not long ago. The documentation is really good anyway.

Answer 19

I use mercurial on my desktop and I love it. Creating the repository is super easy...

hg init /path/to/repository

Add the files...

hg add /folder/pattern  

OR

hg add FILE

Then you just commit...

hg commit

And you're up and running.

The other great thing is when I want to sync to my laptop it's just...

hg pull //desktop_name/path/to/repo/  
hg update

The thing that I like about subversion is the pluggin for Visual Studio, I stay on top of my updates more when the status icons are starring me in the face all of the time. The pluggin may definitely make up for the hassel of setting the svn repository up if you're going to be working with the one project a lot.