This post originated from an RSS feed registered with .NET Buzz
by Chris Flaat.
Original Post: Linked items and SCC integration
Feed Title: Chris Flaat's Weblog
Feed URL: /msdnerror.htm?aspxerrorpath=/cflaat/Rss.aspx
Feed Description: I mainly discuss tips & tricks about VS 2002, VS 2003, and upcoming versions of VS.
A person named Blair commented on one of my prior entries about using linked files.
They mention that the integration of a project's linked files with source code control
has some limitations, esp. when you link to files outside the current project directory.
I looked into this issue a bit, and I can state that this claim is, well, uh, shall
we say...not entirely inaccurate. :-) However, it's not quite as bleak
as one might think. I talked with some people who understand this particular
issue a lot better than me, and here’s a summary of what they told me.
In VS 2002 and VS 2003, when a project with linked items is added to source code control,
VS goes through and calculates the closest common parent to all the files in the project,
and that becomes the root of the project in VSS (we call it the “unified root”).
If later you try and link a new file, AND it’s under the existing unified root, it
will be added to SCC. (If it's not under the unified root, it will still
be added as a linked file but won't be added to SCC.)
For example, let’s say you have a VB project in c:\My Visual Studio Projects\foo and
you've added c:\boot.ini as a linked item. If you then add that project to SCC,
your unified root will map to c:\. If you then add another file from somewhere
under c:\ as a linked item then it should still get successfully added to SCC.
(However, if you try to add a linked file from another drive, e.g. under d:\, you
can add it as a linked file but it can’t be added to SCC. That’s just a limitation
of the current SCC integration.) The most important thing to understand is that
when you do the first “Add to Source Control” operation, your initial unified root
is set up.
If for some reason you really need a linked item from another drive, you could work
around this by adding to your solution a new project that lives on the other drive,
add the linked item to that project, and then add your whole solution (e.g. with one
project on c: and one project on the d: drive) to SCC.
Bottom line: Where possible, the best thing to do is figure out ahead of time what
linked files (and other projects) you need, and add them to your project before adding
the whole project to SCC. Obviously, you can’t always know that up front, but
when possible this is the way to go.
If you already have a project under SCC and you really want to add an SCC-controlled
linked item to it from somewhere outside your unified root, you could try to work
around this by changing the unified root, but this is complex, risky (you could lose
change history), and not really recommended unless you’re a really advanced VSS user.
A (somewhat lame) workaround is simply to avoid using SCC with linked files.
Put the file under the same directory as your other files, and you’re done.
If this is feasible, this is clearly the path of least resistance.
Personally, I use linked files only when I want to occasionally view a file that isn’t
really “part of” my project, but still get syntax coloring, symbol browsing features,
etc.
So, I hope this provides some useful information about how this stuff works, and suggests
some ways to make linked files coexist better with source code control. If you
want to read more about linked items, this
MSDN page is a good place to start.
Previous Topic
