How To: Rename, Move, and Delete Source-Controlled Items in VS.NET
In response to my recent post,
What
is a Source Control Binding?, reader Keith Hill writes,
"A bit OT but do you know why VS.NET SCCI can't handle renaming
projects once they are checked into a SCM system (ClearCase) is what I am
using)? (...) It sure would be nice if the VS.NET SCCI could just handle this
for me."
Indeed, it would
be nice if SCCI supported automatic renames. And just to be clear; renames are
just one of a set of similar operations, which I’ll refer to as namespace changes in this post.
Namespace changes include RENAMES, MOVES, and DELETES.
So why aren't
namespace changes that we make to our projects and files in Visual Studio .NET
pushed to the source control database and committed automatically?
Short answer: the source control plug-in
providers (Rational, SourceGear, Microsoft, Perforce, PVCS, etc) have not taken
the time to provide this functionality and/or have not demanded that this
functionality be facilitated by the addition of MSSCCI functions. Of course,
namespace tracking of the sort that ensures that your file renames in VS.NET are
pushed to the database version of that file is completely doable, even today.
However, the projected cost of doing it right--of implementing an elegant
namespace change-aware source control system for integration with Visual Studio
.NET and other development environments (Dreamweaver jumps to mind)--appears to
have deterred even the most deep-pocketed source control vendors. The architecture isn’t exactly mind
bending. The do-it-right
approach involves some or all of the following elements. Namespace changes must
be:
a) Performed in a Transactional way (SCCI commits all namespace
changes at one time; on check in, for instance);
b) Reversible (for example, on loss of network connectivity or
in response to an Undo Checkout operation);
c) Tracked by the source control system using GUIDs that link a
working copy of a file to its master copy in the database or;
d) [Optionally] broadcast or propagated to all users' working
copies of that project (msg, 'Hey, UserA just renamed a file you have checked
out. What do you want to do?').
A truly
transactional source control solution would be ideal. The ability to reverse, or
roll back a namespace change (which would be close to ideal) would require the
provider to either cache a complete copy of a solution or add some code to their
systems that would preserve the history of name changes to a file until the
parent project/solution is checked in or an undo checkout is requested. Again, I
don’t think that any of the providers do this currently. MSSCCI uses actual file
names to uniquely identify all source-controlled files rather than separate
GUIDs. Changings this could allow a file that is renamed in one place (on the
client) to be mapped to a file with another name (the as yet un-renamed file in
the scc database). Finally, none of the SCC providers provide namespace change
broadcasting or notification services. Again, I reserve the right to be
mistaken.
A A halfway solution?
The Visual
Studio .NET source control integration development team has considered it. However, in lieu of a well-designed
namespace change-aware system, the risks associated with renaming a project or
file in the database, automatically, outweigh the potential
advantages.
You might ask,
“what are these risks associated with renaming projects?" To answer that
question, consider the following hypothetical scenario:
S Simple Rename Scenario--Single User
Risk: unable to easily undo checkout
of a solution containing a renamed file.
++Assumes that client file renames are immediately committed
in the SCC database++
Bob renames a
project from Peck.csproj to Hubble.csproj. Two files are changed in Bob's
working folder: the solution file (telescope.sln) and Peck.csproj. The SCS
system detects a namespace change (the rename) and automatically commits that
one change to the database; Peck.csproj gets renamed to Hubble.csproj. The
database version of telescope.sln is not updated, and thus, differs from Bob’s
version of the solution file. Bob works on his project for a while and then
decides--for whatever reason--to undo checkout for the entire solution. The
telescope.sln file that he gets back from source control references the old
project name, ‘Peck’. The source control system cannot find a project named
'Peck' on local disk (because neither local source control integration nor the
MSSCCI provider remembers the rename to the project file, therefore none of
them can undo this change) so it assumes that
another user has added a new project to the solution. Consequently, the SCC
provider attempts to get the “new” project and all of its files. But there isn’t
a project 'Peck' in the SCC database because it has been renamed to Hubble. The
Get operation fails and Bob ends up with a solution with a missing/unloaded
project.
To fix this
issue, Bob must:
1. Check out the solution exclusively.
2. Open the database and manually rename Hubble.csproj to
Peck.csproj.
3. Manually rename Hubble.csproj.vspscc to
Peck.csproj.vspscc.
4. Get the files locally, etc and then reload the projects into
the solution.
In an
ideal world, the best way to solve this problem would be to add some
code to scci to preserve the history of name changes to a file until the
parent project/solution is checked in or until an undo checkout occurs.
Basically, if we
could remember that Peck was renamed to Hubble, after we get the old solution we
could rename Hubble back to Peck. Tracking this kind of change is non trivial
though. The SCCI code would have to remember changes like
Peck->Hubble->Orbit->Peck->(delete)Peck, or
Peck->Hubble->(delete) Hubble ->(add different) Peck,
etc.
C Complex Rename Scenario (Multi-user)
Risk: Teammate’s changes cannot be
merged into the main code line.
++Again, assumes that client file renames are immediately committed
in the SCC database++
As in the
previous scenario, Bob renames one of the projects in the telescope solution.
The database version of the project file is changed from Peck.csproj to
Hubble.csproj. While Bob is working on the (checked-out) source files, his
co-worker Mike opens the telescope solution from source control for the first
time in order to make a set of targeted bug fixes. Mike gets a version of
telescope.sln that contains a reference to ‘Peck.csproj’, but in the source
control database there is no such project. He ends up with a missing/unloaded
project and a solution that cannot be built. Mike cannot build his enlistment
and might not even be able to edit the files or to fix the bug (if the bug was
in the Peck project’s project files).
Concurrently,
John--a third team member--who had previously opened the telescope solution from
source control and has all the files locally, attempts to Get the latest version
of the solution from source control in order to incorporate any outstanding team
changes into his working copy before building and checking in. However, since
Peck.csproj has been renamed in the database, the SCC status for John's copy of
project is ‘uncontrolled’ and the file appears as a 'pending add'.
John, who has
added several files and has made major build configuration changes since
checking out the solution, decides to add Peck.csproj to and check in his
version of the solution. Consequently, Peck.csproj is added back to the SCC
database.
Now, there are 2
project files in the database, Peck.csproj and Hubble.csproj.
A few minutes
later Bob checks in his changes. The solution file now references the new
project Hubble.csproj rather than Peck.csproj. Effectively, John's major changes
(file additions/changed build configuration) are orphaned and will have to be,
when somebody realizes that they're missing, re-integrated into the main
codeline, manually and painfully.
S Summary
In the absence
of reliable mechanisms for 1) rolling back and synchronizing previously
committed namespace changes between a source control database and a local
enlistment and; 2) disseminating namespace change notifications or commits to
all project enlistees automatically, it is much safer to implicitly discourage
renaming, moving, or deleting source-controlled files and projects than to
complete such operations automatically and thereby enable serious scheduling
setbacks in mainstream collaborative development scenarios. Whew. That was a mouthful.
I can only
assume that the source control providers (VSS, ClearCase, PVCS, Vault, et al)
are as responsible for the lack of transactionality in source control
integration as SCCI in Visual Studio .NET. I speculate that the SCCI team has
entertained some requests from our VSIP partners in this area sometime in the
past and that somebody whose salary is much bigger than mine said, "Whoa. That
sounds expensive. Let's punt."
Obviously, the second roadblock (lack of ability to 'push' namespace
changes down to project enlistees) would be the sole responsibility of the
source control provider.
To rename, move, or delete a source-controlled file
or project in Visual Studio .NET 2002 or 2003
1. Inform all project enlistees that you plan to make a
namespace change to the project.
2. Ask all project enlistees to check in the solution to which
the file or project belongs.
3. Rename, move, or delete the item in Visual Studio
.NET.
4. Check in your changes.
5. Ask all project enlistees to synchronize their working
copies of the solution with the database version.
For more
information see Q305516.
++++++++++++++++++++++++++++
Ugh, This posting is
provided "AS IS" with no warranties, and confers no rights. Microsoft kann für die Richtigkeit und
Vollständigkeit der Inhalte in dieser Newsgroup keine Haftung
übernehmen. Este mensaje se proporciona "como
está" sin garantías de ninguna clase, y no otorga ningún derecho. Ce message est
fourni en l’état, sans garantie d’aucune sorte, et ne vous confère aucun droit.
Vous assumez tous les risques liés à son utilisation. Il
presente posting viene fornito “così come é”, senza garanzie, e non
conferisce alcun diritto.