Some Subversion Questions

July 21, 2007 • from Hood River, Oregon • 9 comments

On this page:

Since I know a bunch of you are using Subversion I'm going to lean on 'ya all for a few questions that I've run into while using Subversion here.

Since I last posted about Source Control I started using Subversion for source control fairly extensively on a host of projects. As many had suggested in the comments of that post Tortoise SVN can get quite addictive and it's true enough. It took me a while to warm up to that idea, but I've become quite enamored with the shell extension and don't miss the source control inside of VS.NET at all. Life's been good and I have a shared depository running on my site for the last few months.

There are a couple of things that I need some best practices advice on.

Exporting to SVN and getting a Checked out Copy

I've started creating a secondary repository for all sorts of different development stuff that's a bit older, just to have it stored away etc. So I've been creating a bunch of new repository folders and adding projects into them.

Even with having gone through this process a bunch of times now I still haven't found a really clean way to create a repository on the server. What I seem to have to do to make this really fly is:

Clean up my folders to get them ready for Export
Do the Import into SVN
Delete or rename the directory
Use Check Out to get a local Working Copy

I tried a bunch of different ways to do this but the above seems to be the only way to go from a plain directory to a directory that's under SVN control. Is there an easier way? It seems that Import should somewhere have an option to automatically put the uploaded files under source control, but the docs actually say that that's not so. Doing a Checkout on the existing folder also doesn't work as Tortoise will not override existing files apparently.

Am I missing something?

Branching Individual Files

I'm currently working with both VS.NET 2005 and VS.NET 2008 for a couple of .NET 2.0 projects. I basically have separate folders for VS 2008 and VS 2005 where I store my projects which works fine for the main projects. However, for my library projects - Web Controls, Business Object Library, Utilities etc. - these libraries I'd actually like to share between versions because they're used in both. So for now I have a my Projects2005 branch on disk and a Projects2008 branch and each of the project folders under Subversion control using the Subversion to keep the two folder versions in sync.

It actually works well, except for one thing. The project files of course are incompatible between versions so I have to be careful when updating (or rather not updating) the project file with the Subversion repository.

So I thought it would be nice if I could just branch the project file or at least exclude the project file from the VS.2008 folder, but I haven't figured out a way to do this. I can't quite figure out how to remove the files from version control but leave the file actually there in such a way that an update won't put an updated file back.

In short I want to be able to update the file without Subversion knowing about it or wanting to update the file.

I suppose there's another workaround which is just to copy the project file give it a new name and don't add that file to SVN, but I'd like to avoid that if possible.

This is probably doable but after futzing around with this I can't quite see how to get it done...

The Voices of Reason

Rob Bazinet
July 21, 2007

# re: Some Subversion Questions

Check out http://www.visualsvn.com/, it relies on TortoiseSVN but is a great add-in to VS.NET.

I have been using it for months now and it beats having to have a separate check-out from VS.NET. It is not a native source control provider but I have not seen any drawbacks.

No, not affiliated with them at all.

Andrew
July 21, 2007

# re: Some Subversion Questions

It sounds like you have a couple of things going on here. I heartily recommend Pragmatic Version Control using Subversion, http://www.powells.com/biblio/63-9780974514062-1, you can swing by Powell's Tech in downtown Portland and grab a copy.

You can do the things you're talking about through the command line using the instructions in the book, or using the Repo-Browser in TortoiseSVN. Its a skinny book, read it twice. There's a couple of pages in there that are just real gems and I keep going back to them about once a quarter for this type of stuff.

Scott Bellware
July 22, 2007

# re: Some Subversion Questions

Rick,

There's no other trick to getting a project under source control. The way you're doing it is the way it's intended to work. The clumsy part of it only happens for the guy on the team that does the initial import, since he's also already got the code on his box, and would probably just prefer that code to be converted into a working copy. For everyone else on the team, it's just a matter of doing a plain-old checkout.

It likely feels weird to you since you're always the guy doing the import. Since the frequency of doing an initial import compared with the rest of the operations that happen against the repository during the life of the project are sufficiently infinitesimal to barely even deserve a mention, and since it only effects the person doing the initial setup work for the project, there isn't much call to add special features to simultaneously do an import and an in-place conversion to a working copy. It's a low-frequency feature that if implemented would have to be maintained forever. Since the scenario can already be served with two existing features, and since the feature would be used rarely, its cost would out-weigh its benefit.

Ted
July 22, 2007

# re: Some Subversion Questions

You can ignore files by setting the property svn:ignore on the directory that contains the file to a list of files you want to ignore. It accepts wild cards too, so you could ignore executables, logs, etc. With TortoiseSVN you can get to the properties by right clicking on a file under version control and picking Properties under the TortoiseSVN menu. Just hit enter between each item in your list.

For gory details:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.ignore

Thomas Wagner
July 22, 2007

# re: Some Subversion Questions

Ditto on the VisualSVN. Have been using it for some time and its pretty nice. When I want to get a new project into SVN I typically set up the repository on the server then create a directory on the HD that is the top level of the repository. After that add sub dir for branches and tags on the HD. That step is followed by an SCN Checkout of the top repository (via Tortoise) at the top level dir on the HD. This establishes the connection between the working dir tree and the server. All thats left now is to copy existing files into that structure followed by a Tortoise "Add" at the top level dir to get the contents of the entire tree into SVN. Or if its a new project, just create the solution via VS in the appropriate spot of the tree and ADD those files to SVN when done. Dont know how appropriate this is but it works.

mob
July 22, 2007

# re: Some Subversion Questions

Rick,

The import thing got me too. All you have to do is create your project folder in the svn repository (IE: svn://myrepo/MyWebApp), then right click the project folder on your machine (IE: D:\Dev\Web\MyWebApp) and select 'SVN Checkout'. It will prompt you with the checkout dialog, browse to your repository project folder (IE: svn://myrepo/MyWebApp), the checkout directory (On your local machine) should default to the project folder you right clicked. Click OK and then YES to the "warning" dialog that appears (that states that the checkout folder is not empty). Now right-click the project folder again and select "SVN Commit", this will allow you to select and commit the contents of the folder. This essentially 'hooks up' your folder to the svn folder and then adds (imports) the files. So you shouldnt have to do the import/rename/delete/checkout song and dance.

One thing to remember though, if you are excluding files or folders, is not to accidentally commit them by doing a 'select all files'. For example if you are excluding bin/obj folders make sure they are unchecked in the commit dialog. Once you have commited the files/folders you want, then you go back and set the exclude properties on the commited folders.

m

Bob Archer
July 23, 2007

# re: Some Subversion Questions

Rick,

I don't think anyone mentioned that the alternative to Import is Add. You can add your project rather than importing. In addition, adding allows you to ignore stuff. So, if you add you new project you can ignore your obj, bin folders, your user files, etc.

You also don't need a new repository for each project. You can put everything into the same repository. So, when you do an add you can just specify a new folder trunk in an existing repository, for example, myprojectname/trunk in the add dialog.

Once the add is complete your working folder is already a checked out project.

BOb

Winston
July 23, 2007

# re: Some Subversion Questions

Thomas and mob are right. You just need to connect your top folder to a folder in SVN, and TortoiseSVN will find everything underneath it. My process is 3 steps

1. Create "MyProject" repository
2. Checkout MyProject/trunk to my working directory
3. Commit all my existing code

Regarding #3, After checking out the trunk to just my top level folder, I do a "Commit", which will show me everything that hasn't been added. Then I just designate everything that should be ignored (bin, obj .suo, etc) and commit the rest. I prefer using TortoiseSVN "Commit" to using "Add" because I can set up my ignores at the same time that I am setting up my adds. This gets it all done in one dialog.

For a while I used Ankh to set up projects because it knew what to ignore, after which I would
disable Ankh and use TortoiseSVN. It took a while for me to find a way of setting up SVN projects that I was comfortable with, but now it's pretty routine, and I'll probably try to write a powershell script to automate it.

Regarding your branching issue, that's a tough one. We decided not to use Branching. It's great for "feature branches", but branching is really only useful if you're also merging stuff back in at regular intervals. For example, we created an "MS AJAX branch" when AJAX 1.0 was released, and once it was stable, merged it back into the trunk. For VS versions, we did things differently. I haven't used 2008 yet, but here's how we did it for 2003/2005:

We have a "Common" solution containing lots of reusable stuff in several projects. We needed to version it for 1.1 and 2.0, so we did what NHibernate did. We have multiple project files: Common-1.1.csproj and Common-2.0.csproj. That way we can exclude Generics-related classes. You shouldn't need to exclude the other project file from your folder, just don't use it in the solution. So this means the different projects share many of same files. If a particular file needs to contain *both* 2.0 and 1.1 versions of the code, we can have the project file define a constant (NET_2_0) and wrap the 2.0 code in directives like:

#if NET_2_0
IList<T> List<T>();
#endif

SugarDaddy
January 29, 2008

# re: Exporting to SVN and getting a Checked out Copy

@Mob

"So you shouldnt have to do the import/rename/delete/checkout song and dance. "

Haha... no you just have to select all of your files all over again! How that's easier than renaming and re-checking-out I'll never know.

Bottom line, this is an ass backwards feature of the program. Obviously if you're importing into the repository, you want those files to be under version control. So why not do it?

My boss recently told me to change from _svn to .svn. I figured tortoise would make the change to all of my projects for me. Nope. Now I have to go in and check out each one all over again. First of all, the checkout and commit method doesn't even work for me. I get "file already exists" errors. Second of all, I'll be damned if I'm going to go through and select all of the project files for about 50 projects. I'm wishing ill will towards the Tortoise SVN programmers right now.

Rick Strahl's Weblog