source control

Visual Studio 2005 – Source Control Warnings (or lack thereof)

Matt Simner Visual Studio ,

I’ve just had to apologise to my peers for breaking the build (thankfully not something that happens often).  I encountered an interesting situation where writeable files don’t show as such (a build script had ‘got latest’ but left files writeable).  I then made some changes and performed an incomplete checkin as half of the changed items weren’t checked out.  Visual Studio interestingly showed all of the files as ‘locked’ even though they were writeable.  VS2003 used to detect that and give you a different type of ‘tick’ to show the file was writeable but not checked out (I think 🙂 ).


‘Silly boy’ – I hear you cry – yes I should have done a get latest before checking in (but didn’t – my bad).  This does highlight however the Source Control settings available in the Tools–>Options dialog.  We enforce Checkin comments (through a VSS Addin) and so for safety (knowing what VS2005 is doing with VSS) it’s always worth ensuring the following are enforced:



  • Prompt before checkout
  • Prompt before checkin (to allow comments)
  • Don’t allow editing of checked-in items
  • Checked-in item behaviour

    • On Save – prompt for checkout
    • On Edit  – prompt for checkout

I’d changed some of these items in the past week but some had reverted to previous settings (a little concerning!!).


Anyway – it’s all good – the build passed and I’m a little wiser about what options to tick in future.

Beware the unseen checkout in Visual Studio Setup Projects

Matt Simner Setup and Deployment, Visual Studio ,

I was inadvertently responsible for a broken build this morning as I checked out a Setup Project last night in Visual Studio 2003 that ended up checking out a merge module that was included in the Setup.  This merge module is built and subsequently stored in SourceSafe (I know – it shouldn’t be! – this is a temporary measure) by the build script, and the build failed as the .msm output file was checked out to me.

 

Shouldn’t Visual Studio prompt you when you check out?

The project was checked out in Visual Studio and it gave no warning that the .msm was also going to be checked out.

 


In other setup projects you’ll often find that other files will appear in the Check Out dialog (i.e. you’re about to check  out all the ‘files‘ that have been explicitly included into your setup – from their source location).  As a matter of course it’s wise to first untick everything (right at the top), and then select only the .vdproj file to actually check out.

 

Why didn’t it prompt in this case?

The problem in this case appears to be that the offender is a merge module and was added to the setup project as such rather than as an included ‘file’.  It seems that Visual Studio neglects to mention merge modules when you check out as it probably thinks they’re static and not something it should worry you about! (which is probably true – yadayadayada)

 

How to prevent this happening to you

Well, while this file is still in VSS there’s little option but to just be vigilant whenever you check out a setup project that includes it. Either check out in VSS Explorer or if in Visual Studio -go immediately to VSS and undo the offending checkout.  Another option is to add some more resilience into the build and somehow force an undo-checkout (as no one other than the build should be updating the file).  A variation of this is to disallow checkout for all but the user running the build process through SourceSafe Admin (but this is a pain to administer), and the final and best solution is to remove the need to store the merge module in Source Control by sorting out cross-dependencies in different components so that they all pick the file up from the same central location.