Amadiere.com

Fourteen and a half crazy frog burpers

25th April 2009

Configuring Subversion Clients

Filed under: Subversion — Tags: , , — Alex Holt @ 3:16 pm

After my new found love of all things Subversion, I’ve been trying to faff about obtaining that perfect config (instead of doing any actual coding!). There are a number of things in the TortoiseSVN settings that I’ve needed to change so far which have caused me a bit of bother maybe. That and I’d like to just point out a few cool things that you can find when digging around TortoiseSVN too.

Firstly, there is the two important settings you should heavily consider before you even start using SVN:

Some important settings for TortoiseSVN

Some important settings for TortoiseSVN

The first thing of note is the big “Global Ignore Pattern” box. This is a space delimited list of files (with wildcards included) that can be used for excluding when you commit to your repository. The original set I left as it was, but added a few key additional files to that list:

*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *_ReSharper* *.suo Thumbs.db

The key ones you’ll spot I’ve added are *_ReSharper*, *.suo and Thumbs.db. I was keen to avoid putting all the ReSharper files in there by default, and this seemed like a good way of doing this. The *.suo was added when I realised that all I had to do was open the project and this file would change, a little look around shed the light that this file isn’t needed and can be dropped from SVN altogether. Thumbs.db (case sensitivity is important btw), was because I develop on a windows box and it seems intent on creating that damn file everytime I put an image in the directory – so I’ve excluded that too.

The tickbox at the bottom was a little bit more recommended, than something I’ve learnt from. When you have a nosey at the official documentation for TortoiseSVN, they do say that Visual Studio.NET has issues with the dot format SVN directory (Edit: This was only relevant for VS 2003 it seems (see Bert Huijben’s comment below) – so not much of a worry if you are on exclusively newer versions.):

VS.NET when used with web projects can’t handle the .svn folders that Subversion uses to store its internal information. This is not a bug in Subversion. The bug is in VS.NET and the frontpage extensions it uses. Read the section called “Subversion Working Folders” to find out more about this issue.

If you want to change the behaviour of Subversion and TortoiseSVN, you can use this checkbox to set the environment variable which controls this.

You should note that changing this option will not automatically convert existing working copies to use the new admin directory. You will have to do that yourself using a script (See our FAQ) or simply check out a fresh working copy.

While this issue might have gone away (I never experienced it). It seems quite foolish to simply ignore this setting when it does explicitly say against it!

I’ll reserve this post for any future amendments to my standard settings – as much a reference for myself as anyone else.

Wooooo! Time to do some coding!

4th April 2009

The Layout of a Subversion Repository

Filed under: Subversion,Visual Studio — Tags: , , , , — Alex Holt @ 1:07 pm

In and amongst other things recently, I’ve been working on sorting out a replacement for Microsoft SourceSafe / nothing at all. I’ve done my research and I believe Subversion an excellent starting place for using version control and will probably keep most, if not all developers happy. If distributed (and GIT) turns out to be too much of an advantage to ignore – the fact that Subversion is such a mature and well used product, there will always be an upgrade path.

I’ll try not to go into too much detail, as there are plenty of useful resources dotted around that you can find information from. However, before I go onto the directory layout of our repository, I feel I should mention the hardware and software layout of Subversion itself in our environment. Where I work, we are migrating from our historically used Classic ASP code to using C# in ASP.NET, though we have some systems using PHP too. I mention this because we want to be able to use Subversion to look after all code – not just one specific language.

Server Software: In my opinion, I believe you need both Subversion and Apache HTTP for an optimal setup. As we have an Active Directory server as well, it seemed like a good idea to use this rather than create further usernames and passwords for all our developers. For this, you can download and configure everything manually (after all, there is an excellent resource in the free eBook on Subversion) – but actually – you might as well just download the excellent VisualSVN Server. It takes almost all the hardwork out of creating the Subversion server. It’s truely a brilliant piece of kit and if you are new to Subversion, I’d advise using this (or at least having a nosey at it and seeing how it does things – if you’re that way inclined). It’s possibly worth me mentioning that all these applications have the most agreeable price-tag of absolutely nothing at all. Woo!

Client Software: For this, every developer wanting to use Subversion must install TortoiseSVN. TortoiseSVN is a great explorer based client for Subversion that allows developers to perform standard (and advanced) commands from the safety of the right click context menus. This works for all languages and files, but I’d advise for anyone working in Visual Studio, that downloading and paying $50 for VisualSVN is money well spent. It doesn’t require VisualSVN Server, but it gives you a way of utilising all the TortoiseSVN context menus from within Visual Studio, meaning you needn’t worry about mulitple windows and all that. Just concentrate on your coding! Also, because you have installed VisualSVN (or Apache seperately) you can allow (authenticated) users to view the repository in their web browser of choice.

All this and we’re almost up and running. But before we can continue, we need to sort out the structure. This is how I’ve suggested our team uses it:

svn / aspnet  / libraries  / trunk
                           / branches�
                           / tags
              / project01  / trunk
                           / branches
                           / tags
              / project02  / trunk
                           / branches
                           / tags
              / users      / amadiere
                           / user02

Basically speaking:

  • Every language has it’s own repository. There is no need to bring multiple languages into one repository, especially when the amount of code for each language is sufficient to live in its own. I think there may be exceptions to this rule, but those can be taken on a case by case basis.
  • Every language would have a ‘libraries’ directory (this is the equivalent to ‘include’ or whatever). Some things will obviously be used multiple times, so it makes sense to keep them in a central area, this is nothing new. With everything being in one repository however, it means moving something from Project01 to the libraries area will still keep all the history and version attached to it. This is a big plus from where I’m sitting and is why I’ve gone for this layout.
  • Each library or project folder would have the standard 3 directories for trunks, branches and tags. There is plenty of advise and advantages for this structure, most detailed in the SVN book. A project may involve further sub-project folders if it was relevant, before creating the trunk, branches, tags folder structure. However, depending on the nature of the project, it might be better to create multiple top level projects than sub projects with ‘different trunks’.
  • Each user would have their own area (without the 3 standard directory structure). There isn’t a need here for the trunks, branches and tags because this area shouldn’t be used for projects. This area should be used by developers to simply ‘Sandbox’ or test small bits of code etc. There isn’t an end product to need to branch. In the end, this code is the developers to work with – so I guess if they wanted the branches, then they can go for it.

I think with this format, we’ve got a good standing point for where we want to be going with Version Control and the ASP.NET environment. I’m confident, but until we really start using it in anger – we’ll never know! But the idea is then, when I want to develop something, I open Visual Studio and a blank solution. I then add the projects that I’ll need (e.g. Project01, Libraries and Amadiere) and off I go – I have everything open I need and they are all going to their appropriate places in Subversion! Genious!

14th September 2008

SourceSafe or SubVersion?

Filed under: Subversion — Tags: , , — Alex Holt @ 5:17 pm

Since time of yore, Microsoft Visual Source Safe has been our version control software of choice. No one is really sure why, but probably because it came free with Microsoft Visual Studio way back when VB6 was in its prime. And, when you look, actually, it wasn’t such a bad choice… back then. There was probably only CVS that could have rivalled it.

Cut forward to today, September 2008. Here we are, still using MS InterDev to edit our VB Script & classic ASP web pages, stored in our MS Visual Source Safe database. Not the image of cutting edge it could be remarked. In fact, mentioning this to most geeks would probably produce a stutter, a light cough and a snigger of amusement – followed shortly by a tarrade of insults and jokes. Well times are a-changin’! In the coming months we are looking to progress forward and create ourselves a presence in the 21st century! Yep, C# and the .NET framework! Fantastic! Wooo! Jolly brilliant and all that!

Having known about a number of different version control systems existing, I decided to have a quick nosey around and see what people suggested, and boy was I surprised!

Maybe not much of a surprise that a Microsoft product wasn’t the most popular product on the market, but what surprised me was the amount of hostility to it. Spend a little time just browsing around Google for information and comparisons between the various version control systems leaves very little to be desired regarding SourceSafe. Indeed, Jeff Atwood (from StackOverflow) declares “Source Control: Anything but Source Safe!“, which is quite a statement considering how well known and estabilished SourceSafe actually is. From my time looking around, I struggled to find anyone actually supporting the use of it – they were all desperately trying to find reasons to get away from it. Bizarre…. or is it?

When I read through the comments and wealth of moans & gripes about SourceSafe, I started to realise that we have had quite a lot of these problems. But we had either never realised they were errors (“it’s not a bug, it’s a feature!”), or just thought that we were unlucky. We have problems maintaining our users, sure at times. We have had more than our fair share of corrupt databases, that’s definitely true. We have even had issues where collegues have swore blind that they’ve checked things in and out again, but SourceSafe hasn’t made a version update. I’m starting to believe that they weren’t remembering it wrong and that actually, it might have been SourceSafe after all…

The biggest thing I spotted when reading through all the articles, was the difference in the way people use version control systems compared to how we use SourceSafe. It’s not surprise to me, in fact, I probably already knew that we were never really challenging our system to do things. We simply used it as a panic button in the rare instance where we totally messed something up, we could just log into the SourceSafe admin and restore a copy of the file. Genius! No need to talk to the server maintenance and ask them to restore a 3Kb file. However, the more I look at SubVersion and how it has improved and basically, its feature set, methodologies and so on – the more I realise: “Why the hell did we continue using SourceSafe for so long?!”.

Just to emphasise my point, here are some of the things that I believe could be selling points to try and move our development environment onto SubVersion and away from SourceSafe:

  • Branching: the ability to take a snapshot in time of the working code and either work on it seperately, or prepare it for release.
  • Merging of Changes: If any last minute fixes are applied to the release candidate code/branch, they can be merged seemlessly into the development branch of the code. Human’s may not even need to go into the code to edit it! In fact, they don’t even need to remember what changes were made due to the conflict detection.
  • Web Access to Repository: The ability to view the source code & branches over the web appears to be apparent in SourceSafe also now, but this is a great bonus compared with before.
  • Point-in-Time Code: I can create a branch of code based on how a specific branch of code was on a specific date, or based upon the code that was deployed in a specific release. This is a brain-exploder! Project-A is in development and two weeks after the first release, a bug has been found and needs an emergency patch. The development environment is no longer in-sync because we’ve been doing updates. No problem, give me copies of the project from the Version 1 release please. Fix bug, make it live, then merge the change into the development copy if its still there.
  • Atomic Commits: This is the biggest bonus in my eyes. It basically means that if you’ve changed loads of pages/code, and one of the pages you try to change causes a bucketful of errors – all the other pages haven’t been made live. Imagine all the issues that would arise if it was a the Database Access class that had failed to update – all the pages that required it would be live – causing errors – until you either reversed the process or fixed the problems. No problem with Atomic Commits – just take your time, fix the issues – it’ll only go live when ALL pages are fine. :)

There are of course other perks, such as user administration being apparently easier in SubVersion. But for the process of trying to understand the differences – those points are to me, very significant!

It’s all very exciting this version control lark!

Theme designed & built for Amadiere.com by Alex Holt. Powered by WordPress