R – Basic SVN Usage

ankhsvnsvnversion controlvisual studio

Preface

Let me start off by saying that I'm a relatively new programmer and I have no prior experience with source control — although after some reading, the concepts and general lingo are not alien to me.

Background

I'm about to start my first professional project (I'll be the only one committing) and I'd like to take this opportunity to become proficient with Subversion and source control practice in general.

Development will take place on a Windows box in Visual Studio with the help of the AnkhSVN SC plug-in.
I've setup SVN on a Windows server and created a repository where I'll store my project(s).
This particular project will require delivery of binaries and source code.

Questions

How is solution building usually set up? Say I've imported an initial version of the solution into the repository; next, I've achieved some milestone in my local working copy; I commit those changes; what happens then? Do I just build the solution on my local development machine and package the binaries right there and then? How is this done in the real world?
After messing around with VS and AnkhSVN in a VM, I've noticed that after I checkout some revision of a solution, my local copy's directory tree gets an extra directory called ".svn" in each node. As per the third point in "Background", I'll also be delivering source code along with the binaries. This poses a question: how do I get a "clean" version of my solution? Am I expected to write a shell script that does the cleaning for me?
I often create, merge (by hand, that is), and delete files in my solutions. Will SVN (rather VS and AnkhSVN) handle this gracefully? Will VS/AnkhSVN automatically reload a solution that had files added/removed from it if I go back to a certain revision?
Where did you learn to use source control, and how long did it take you to become proficient (i.e., until these operations were second nature) at it.

I really want to start using source control, but I'm scared that if I start using it and I do something unintentionally stupid, I'd lose my code. Any extra advice is appreciated.

Best Answer

Normally, packaged binaries are not kept in source control. If anything, use a separate repository for them. As a matter of fact, try to keep binaries away from your repository if at all possible. No compiled versions of your source code. (see comments as well)
Get TortoiseSVN for use in Explorer. You can use the Export option (as opposed to checkout) for a clean version of the directory. Use a separate directory for this.
Visual Studio will ask you if you want to reload projects or solutions that have changed. You will need to make sure that you check in a project at the same time as your added / deleted file though. It won't give you problems now, but it would if you were working on this with more than one person or if you want to revert to an earlier version later.
Here and there :) Took me a month or so of regular usage to get it right *

I've used AnkhSVN in the past and it's nice, but if you have large solutions with lots of files, you might want to shell out some cash for VisualSVN. It uses TortoiseSVN (which in term has some caching mechanisms), ~~making it faster~~ (see comment below about AnkhSVN 2.0). VisualSVN will also help you a little in setting up properties on special directories. It will automatically ignore bin and obj directories for instance.
I'm not a big fan of paying for a product leaning so heavily on a free project, but I have to say the investment was worth it.

Other people have linked some nice sources on how to set up your repository, so I won't go into that too much. I generally use the /trunk, /branches, /tags approach myself. Tag your release versions at least, to find them quickly later.

Ad 4:
I've worked with CVS (very little), Visual SourceSafe, Subversion and Team Foundation Server so far. I mean to try Git at some point, but you could do a lot worse than SVN.

Related Solutions

Visual-studio – Should I add the Visual Studio .suo and .user files to source control

These files contain user preference configurations that are in general specific to your machine, so it's better not to put it in SCM. Also, VS will change it almost every time you execute it, so it will always be marked by the SCM as 'changed'. I don't include either, I'm in a project using VS for 2 years and had no problems doing that. The only minor annoyance is that the debug parameters (execution path, deployment target, etc.) are stored in one of those files (don't know which), so if you have a standard for them you won't be able to 'publish' it via SCM for other developers to have the entire development environment 'ready to use'.

Git – How to migrate an SVN repository with history to a new Git repository

Create a users file (i.e. users.txt) for mapping SVN users to Git:

user1 = First Last Name <email@address.com>
user2 = First Last Name <email@address.com>
...

You can use this one-liner to build a template from your existing SVN repository:

svn log -q | awk -F '|' '/^r/ {gsub(/ /, "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt

SVN will stop if it finds a missing SVN user, not in the file. But after that, you can update the file and pick up where you left off.

Now pull the SVN data from the repository:

git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path dest_dir-tmp

This command will create a new Git repository in dest_dir-tmp and start pulling the SVN repository. Note that the "--stdlayout" flag implies you have the common "trunk/, branches/, tags/" SVN layout. If your layout differs, become familiar with --tags, --branches, --trunk options (in general git svn help).

All common protocols are allowed: svn://, http://, https://. The URL should target the base repository, something like http://svn.mycompany.com/myrepo/repository. The URL string must not include /trunk, /tag or /branches.

Note that after executing this command it very often looks like the operation is "hanging/frozen", and it's quite normal that it can be stuck for a long time after initializing the new repository. Eventually, you will then see log messages which indicate that it's migrating.

Also note that if you omit the --no-metadata flag, Git will append information about the corresponding SVN revision to the commit message (i.e. git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>)

If a user name is not found, update your users.txt file then:

cd dest_dir-tmp
git svn fetch

You might have to repeat that last command several times, if you have a large project until all of the Subversion commits have been fetched:

git svn fetch

When completed, Git will checkout the SVN trunk into a new branch. Any other branches are set up as remotes. You can view the other SVN branches with:

git branch -r

If you want to keep other remote branches in your repository, you want to create a local branch for each one manually. (Skip trunk/master.) If you don't do this, the branches won't get cloned in the final step.

git checkout -b local_branch remote_branch
# It's OK if local_branch and remote_branch are the same names

Tags are imported as branches. You have to create a local branch, make a tag and delete the branch to have them as tags in Git. To do it with tag "v1":

git checkout -b tag_v1 remotes/tags/v1
git checkout master
git tag v1 tag_v1
git branch -D tag_v1

Clone your GIT-SVN repository into a clean Git repository:

git clone dest_dir-tmp dest_dir
rm -rf dest_dir-tmp
cd dest_dir

The local branches that you created earlier from remote branches will only have been copied as remote branches into the newly cloned repository. (Skip trunk/master.) For each branch you want to keep:

git checkout -b local_branch origin/remote_branch

Finally, remove the remote from your clean Git repository that points to the now-deleted temporary repository:

git remote rm origin