Basic SVN Usage

Question

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

1. 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?

2. 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?

3. 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?

4. 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.

Answer 1

I can't answer your main questions because they are very VS specific, but when you say:

I'm scared that if I start using it and I do something unintentionally stupid, I'd lose my code.

let me reassure you. The whole point of a VCS is to prevent any code loss, ever. All version control systems I'm aware of make it impossivble to modify older versions of your files without jumping through some extremely unlikely hoops, such as directly editing the repository with a text or hex editor. So long as you don't do that, and so long as you back up your repository regularly, your code will be safe and you should feel free to experiment.

Answer 2

1. 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)
2. 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.
3. 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.
4. 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.

Answer 3

You should read the book. It's free and has answers to things like question 2 (Answer: export).

Answer 4

4) I start with this one because this will answer many of your first questions: Pragmatic Version Control using Subversion is the bible for working with SVN in my respect. But unlike the bible, you can go through it in a couple of days with no haste at all.

1) Versioning projects usually takes the form of committing only source files, as project files (of your VS, for example) usually contain irrelevant definitions of your current installation, and litter the repository. Everyday commits are for your personal use. For major versions use tags.

2) The .svn directory is a local cache repository completely managed by the SVN client. Don't touch it.

3) Merging, deleting and adding files is what version control is all about. Yes, SVN will handle this gracefully, and this is all explained easily in the referenced book. Each revision of your project is self-contained.

Answer 5

1. After committing your personal changes you would build locally. Usually you would build locally and test before committing. In the real world multiple developers all work on the same SVN and there is usually a nightly build where you can get updated binaries, and you of course rebuild as necessary locally. In your case just rebuild as the case dictates, submit your source code compulsively and then commit the binaries about every day.
2. This seems like an SVN and Visual Studio settings issue. I'd consult those forums for help.
3. You will generally be handling the solution on your end, i.e. when you add and delete files your local solution changes and because solutions are small you also upload this solution to your SVN. Any SVN can handle the adding and deletion of files.
4. I started with google code and subclipse, graduating to Tortoise SVN. Tortoise SVN is nice because it integrates in to the shell, so you can develop in whatever IDE you want and treat your local files like local files, and simply commit them when needed.

It is only wierd right at the beginning, but an SVN will quickly become second nature to you. Good luck on your project.

Answer 6

Personally I picked up source control through trial and error. I do feel that Sourcegear Vault is much more user friendly and better tuned for Visual Studio development but I've managed to use both effectively.

If you run into trouble with SVN I recommend you check out vault which is free for one or two man teams. (One admin and one user account does not require a purchase.)

Answer 7

I'll second Avihu Turzion's recommendation of Pragmatic Version Control using Subversion. Also check out Eric Sink's source control how-to if you haven't already.

1. Since you're the only one committing, building and packaging the binaries locally is definitely an option. If the building/packaging steps are fairly standard, automate them by setting up a continuous integration system. TeamCity Professional is a free product you can start with that is easy to configure and get working with Subversion.

2. As mentioned by others, the Export option is the way to get a version of your solution without the .svn files.

3. Subversion handles file creation, merging, and deleting fairly smoothly. With the plug-ins you mention, particularly if you're using something like AnhkSVN and TortoiseSVN, it's possible for what the plug-in reports as committed (versus what the Subversion repository actually has committed) to get out of sync. If you delete files or move files, considering doing it entirely at the command-line (or in TortoiseSVN).

4. I learned to use source control on my own once I'd been working a few years. While I started with Visual SourceSafe (which was terrible), I eventually moved on to companies that used Subversion and/or TFS for version control.

You're far more likely to lose code if you don't use source control than if you do. You're definitely starting things off on the right foot.

Answer 8

1. The way I store my files in Subversion is to setup the Trunk/Branch/Tag directories, though I almost never use Tags. You're trunk is your solid, working foundation. Branches are when you need to "branch" the code, work on something, then merge it back into the trunk. You can do this for something that you know will take a while and you know you might have to do some quick fixes, which modify the trunk. Make sense?

   -- You can checkout your latest and do a build locally or setup a build environment using MSBuild, or Cruise Control.NET or TeamCity (from the guys who do resharper). This will do a build for you, which you can then deploy. All this can be automated, it's just some work configuring everything. Team Foundation Server handles most of this.

2. The .svn directory is so subversion knows what you're working on and can say "hey something changed, alert the user with a nice red mark and let them know somethings changed."

3. Yes SVN will handle deletes and merges gracefully. You may be forced to use the "clean up" utility from time to time.

4. I learned source control from a senior dev on my first project.

Answer 9

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

Most places have standardized on an automated build process. How to set one up varies based on the requirements of the company and the project but the benefits can't be disputed. The last place I worked automated 90% of the build and ran it as needed but they were moving toward a fully automated one when I left. This is beyond the scope of your question but if you're interested you should look in to build automation. Some common tools for .NET development are CruiseControl.NET, MSBuild, NANT. Most tools were created for a specific development environment or language but are easily adapted to other environments.

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?

As others have noted, .svn is a cache of the repository. When you update, checkin or merge svn compares the cached version against the operation your intending to do and only updates, checks in, merges the differences. In the case of AnkhSVN, it integrates pretty well with VS and is designed to ignore unnecessary files when it checks in files. So you shouldn't have a problem with checking in temporary files and binaries (unless you specifically add them of course).

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?

This is SVN's forte. Some VCSs (suchs as Visual Source Safe) make merging a scary operation. SVN on the other hand was specifically designed with merging operations in mind. Most are handled automatically. If there's a conflict between to versions being merged (the same line was modifed in two different ways), it will show you the problem and the rest is up to you. Its very hard to truly delete a file in SVN. So if you decide to explore an old version any deleted files will still be their.

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'd heard of VCS in college but never used one until my first paid programming position. It was visual source safe. It was pretty easy to learn the basics (check out, check in, comments, viewing and comparing old versions). Branching I learned later with a private repository. It was a good thing too. Branching in VSS is more error prone than most other VCSs. My current employer uses SVN, which even though it is not the most advanced VCS available, made VSS look like a hack.

I can't stress the importance of an an automated build enough. My current employer had no build process when I started (still doesn't for most projects). One of the first things I did with the project I inherited was automate the entire build process. It runs on a dedicated server as a background process monitoring SVN for changes. If it detects any it kicks off an incremental build that only takes a few seconds. This is followed by a suite of automated unit tests. If all the tests succeed it drops the binaries into a test environment for further automated integration and system testing. I get notified at each step of the process and know instantly if something fails.

Answer 10

I'm going to try and add some comments that haven't already been covered by the well-written answers above.

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?

It should be noted that ignoring certain files is a core function of SVN, so there is no additional tooling necessary - just some setup. Once you've configured SVN to ignore your build output you can develop and build to your heart's content without worrying about SVN trying to suck up binaries.

Tag your releases. Use the version number in the release in the tag name. Build your binaries from the tag and send your customer a clean copy of the source as well as the generated binaries. You don't need to revision the binaries themselves because the immutability of tags means you will always be able to re-generate the same payload.

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?

There are a few operations that VCS typically have problems with. One is deleting a revisioned file using Windows Explorer (aka: keyboard delete). Another is moving revisioned files from one place in your repository to another from Windows Explorer. Outside of these semi-rare actions, SVN will easily keep up with your modifications and merges. For the two events listed above you can use the SVN command line, TortoiseSVN, or another helped application to perform an 'SVN delete' or 'SVN delete + SVN (re)add'.

Btw - a good (and free) merge tool is Kdiff3.

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 learned SVN at work, Mercurial at home, and AccuRev at work (again). It can take a very long time to 'get' your first VCS - especially if you are learning it in a vacuum. After the first one, it gets easier. I would put this on the order of months, not weeks.

Good luck!