The answer to your Visual SourceSafe dilemma: FIVE things (we bet) you didn’t know about Subversion

On November 8th, I presented the webinar, “The answer to your Visual SourceSafe dilemma: FIVE things (we bet) you didn’t know about Subversion,” with Arneh Eskandari, SQL Tools, Red Gate Software. We introduced five powerful truths about Subversion and Arneh performed a live demo showing how to source control your database in Subversion in less than five minutes.

During the webinar, we encouraged our attendees to interact with us by participating in polls and by entering questions for the live Q&A session that we had at the end of the presentation. As a result, we received many great questions that we just couldn’t get to during the live event so we have provided answers to the audience’s questions below.

If you missed the session live, you can watch the recording and download the slides. For more information about this topic, please download my whitepaper, Economics of Migration. We have also put together a whitepaper specifically on the Five Things We Bet You Didn’t Know About Subversion. I also encourage you to download CollabNet Subversion Edge as is the answer for easy installation, administration, security, and governance of your Subversion environment.

Don’t forget to register for our upcoming webinars. CollabNet offers multiple webinars a month that cover a variety of topics related to software development.

As promised, here’s the follow up to the live audience questions.

Q: What is your Codesion offering, is it still free (I’m suspicious of free lunches!)
While I like the idea of free lunches, I too am suspect when offered one. We still offer a free 30-day trial for Codesion, but after that it costs based on a price per user. We do offer a 10 user license of our Application Lifecycle Management platform, CollabNet TeamForge, for free though we do suggest you purchase support for those users.

Q: Where can you see the SVN Revision number?
There are lots of places where a Subversion revision number can be viewed. Perhaps the most applicable is the Subversion info command which provides you with the revision number that reflects what you last got from the repository for your local copy (i.e., working copy) or, if given a URL path to the root of the repository (rather than a path in your working copy), the latest revision number for the repository as a whole.

Q: who is a good contact point for researching SVN support contracts?
Assuming you’re talking about purchase a Subversion support contract, then I’d point you to which outlines the various offerings. Or you can contact us directly about support and other topics at

Q: How does RedGate Source Control resolve/prevent change conflict?
SQL Source Control gives you the option to resolve a conflict by keeping your changes or taking the other developer’s changes. To merge changes from two conflicting versions of an object – resolve the conflict and then manually edit the object to include the changes from the other version.

Q: Does SQL SourceControl allow you to configure directory paths for specific database items?
This isn’t configurable; it enforces a directory structure.

Q: Any obvious tips on improving SVN server performance, say if my server is 1000 miles away from our dev office and dev clients?
In such a situation, your performance is likely most constrained by the network architecture and purchased bandwidth. Do a network trace to see how information is being passed between the clients and the server and based on that see if you can optimize the traffic by reducing the number of hops, etc. Monitor traffic in and out of the server site to see if you’re maxing out the bandwidth you have. If so, then consider purchasing more bandwidth. Server performance is rarely really about the server as Subversion has pretty low demands on the hardware. Certainly you can monitor CPU usage and memory with the latter more likely to be maxed out and therefore another potential area to address. As a database application, Subversion can be impacted based on the performance of the hard drives used for the repositories.

There are also additional steps you can take based on determining what operations are having performance issues. If you find it is pretty much the checkout command (which is always going to be the slowest given that everything has to be passed and then Subversion creates a second copy to help with the performance of all other operations), then often you can just establish a “reference” working copy local to the developers and instead of doing individual checkouts, they can just copy that working copy to get started. If performance is an issue across all read operations, then you might consider establishing a local replica and using Subversion’s WebDAV write-through proxy feature.

Key is not to jump to any particular solution without doing good analysis. Very few organizations need to utilize the last option discussed and most just need some fine-tuning of their network.

Q: Any way to force an SVN server to issue read-only files, in a get-latest scenario?  We like read-only, for various internal reasons.
Certainly. Subversion implements this type of functionality using a property, svn:needs-lock. Applying this property to a file means that a checkout will get that file in read-only mode. The user will need to get the lock on that file on that branch to have write access. You apply properties to new files via the configuration file on your client machines so make an entry there that wildcards the applying of the svn:needs-lock property to all new files with a default value of “*”. For your current files, you’ll need to apply the property to all of them and commit that change to the repository. I’ll stay off my soapbox on not making this the default for all types of files.

Q: Will the Red Gate tool work for cloud-hosted SVN repositories?
Yes. There is no reason why this would work any differently than with local repositories.

Q: My team is actually thinking about to migrate from SVN to VSS.  But now I think we should not to do that, at all.  At least, I’ll ask him to re-think about…
I definitely wouldn’t consider moving from Subversion to Visual SourceSafe given that the latter is not going to be supported past June. I’d be quite interested in why you were considering that move and might be able to help you be successful with Subversion. Feel free to respond to this posting and I’ll be in touch.

Q: We saw 1.7.0 was recently released. Should we use it? What’s in it?
I definitely encourage people to use the latest releases whenever possible. Open source projects operate differently than commercial tool develop in that process is never held hostage by the need to get the product out the door. That means that you don’t have to wait for 1.7.1 to feel comfortable that you’ve got a robust release. In addition to releases bringing in new functionality or optimizing existing functionality, they often include bug fixes to functionality that you are likely using on a regular basis so keeping up-to-date is important. It is also quite easy to do since you don’t have to migrate repositories to new releases so you’re only looking at upgrading the binaries (and your users are likely doing that already with the clients).

Release 1.7’s key focus was on a rewrite of the working copy structure to help both with performance as well as with increasing feature velocity moving forward. The metadata and pristine/base copy of what you check out are both moved to the top of the working copy with the metadata consolidated into a SQLite database. Other parts of this release include cutting down HTTP chatter, improving merge tracking, enforcing some best practices, enhancing change reporting, and a few administration features and improvements. I encourage you to view the webinar that I did with one of leading Subversion committers, Mike Pilato, to learn more.

Q: We are in a regulated industry and must have our history available. Can we migrate VSS with full history?
I’d still consider leaving history in VSS and archiving both the repository and the tool to satisfy this need. That said, it is possible to migrate with full history depending on the amount and kind of corruption in your VSS repository as well as the time and money you want to invest in the migration. People successfully migrate from VSS, with history, all the time using open source tools. If you want to pursue this option, we do have a unique migration tool at CollabNet that allows for a bit more of the environment to be accurately reflected in the resulting Subversion repository.  One other thing, if you do choose to migrate your history, I’d recommend not migrating it into the production repository, but into a history repository. It is still a good idea to start things fresh after a move.

Q: We code mainly in C# and Java. Could/should we have those projects in the same Subversion repository?
You definitely could put them in the same repository as Subversion will revision anything that you can put onto a hard drive. As whether you should, well that would take knowing more about the projects and your organization. If the projects directly relate to one another (e.g., the C# defines the back-end of the application and the Java the front-end), then it may well make sense to have them in the same project. If there is no relationship, then different repositories may make more sense (e.g., repositories by platform).

Often repository layouts are determined by access permission commonality. If an organization treats all projects the same with the same group of users given the same permissions, then it may be best to have the projects in a single repository. If the access varies based on a different set of developers for each, then separate repositories is probably better. More often than not, organizations do separate repositories by platform.

Q: What service do you recommend to make the transition to Subversion easier and more productive?
I strongly recommend that organizations look at the Subversion Applied Workshop. While we frequently focus on migrating data, we often forget that we need to consider how our processes should be impacted in order to get the most out of our new version control tool and to avoid the possibility of trying to put a square peg in a round hole. An organization’s current version control process has been driven, to some extent, by what the legacy tool did well and did not do well. There is a need to go back to the core requirements, define the high level process needed to satisfy those requirements, and then apply Subversion Best Practices to implementing that process. That’s hard for an organization to do on their own since they are new to Subversion, but it is critical to being successful and happy with Subversion.

Bob Jenkins

Bob Jenkins has spent over 17 years focused on application life-cycle tools. At CollabNet, Mr. Jenkins consults with enterprises that are planning to adopt Git or Subversion on how to apply best practices to their SCM processes. He aslo helps define the areas of investment by CollabNet in open source version control tools.

Tagged with: , , , , , , , ,
Posted in Subversion

Leave a Reply

Your email address will not be published. Required fields are marked *




connect with CollabNet
   Contact Us

Have new blog posts sent directly to your email.

looking for something

CollabNet: Join @Flint_Brenton: at @DevOpsSummit: June 7 for his talk on #DevOps in an Open & Heterogeneous World: @SYSCONmedia:
Date: 27 May 2016 | 9:33 pm

CollabNet: So proud of these students & happy to be a part of @yeswecode!: #YesWeCode #Agile
Date: 27 May 2016 | 7:37 pm

CollabNet: RT @Flint_Brenton: Join me at @DevOpsSummit: on 6/7 at 1:55 pm for my talk on #DevOps in an Open & Heterogeneous World:…
Date: 27 May 2016 | 6:51 pm