views:

589

answers:

3

Currently my team uses Visual Sourcesafe, and being very familiar with how horrible the GUI is first hand and having heard the internet mummer about how unreliable it is, I've been trying to push a move to SVN.

Today I was talking to manager about the eventual move, which he supports, and he asked if it was possible to create sourcesafe style links in SVN. Links, for people not familiar with sourcesafe, work the same conceptually as file links under Linux. We use them to link shared code/libraries between projects. I explained that there was no way to create links using SVN, and he brought up that that may be a major sticking point in the migration.

I told him that in my local SVN (which I keep to ease my development, checking only periodically in sourcesafe), I place shared code/libraries in one location, and refer ANT to that location. However, I got the sense that he wasn't hugely impressed by this solution, as it adds complexity to ANT tasks. Personally I think it's worth having a slightly more complex ANT script over having a bunch of link files in source control, but it really a question of which paradigm you subscribe to.

I am curious about how developers at large work around this limitation, and do newer source control systems like Git and Mercurial support links?

+7  A: 

Look into svn:externals properties.

Joel Coehoorn
+1 beat me to it. This is nice because you can reference other repos on other servers if necessary--it's quite powerful
Michael Haren
What would the limitations be here compared to links?
James McMahon
Mostly just naming restrictions (spaces/dots break them) and an overcomplicated/manual UI. Otherwise it's nearly identical.
Joel Coehoorn
Oh, and they operate at the folder level rather than the file level.
Joel Coehoorn
+3  A: 

We use TFS for version control, and TFS does not have the VSS links feature either. We have eliminated all of our linked files. All class files that were previously linked have been placed into class libraries which are shared to our other projects as shared project references in the solution. So in essence you share libraries, not class files.

There was a bit of an adjustment process getting used to this, but I haven't missed links since then. It really does promote a better design practice by having your code setup like this. Having the classes used in only one project helps avoid breaking changes as it is much easier to test the impact of the change (using links you may not even know if you caused a compilation issue with a change). Also some of the features of the nicer source control systems (like robust branching and merging support) work much better when you don't have to worry about linked files.

Jim Petkus
A: 

Links are useful when source files should be shared between different platforms (.NET, Silverlight, .NetCF) because source files may be equal and therefor can be shared, but compiled libraries can't be shared between this platforms.