[p4] Perforce VS latest .net source control solution
david.weintraub at bofasecurities.com
Tue Jul 11 06:33:41 PDT 2006
If the new source code solution from .NET doesn't completely mangle your
source, then it would be a great improvement over VSS. Your source is
safer if you print it out and ran it through a paper shredder than
putting it in VSS. The joke in the CM world is that Microsoft created
VSS as part of an experiment to see how awful Microsoft would have to
make a program in order for people not to use it. There conclusion is
that the bad software threshold (BST) is somewhere between Bob and VSS.
The new software is called Team System and sometimes VSTS and really is
a whole development environment. The source control part doesn't have a
separate identity from Team System. Sometimes it is referred to as Team
Foundation Version Control.
One of the most anticipated features is something called "The Shelf"
which apparently lets you store your changes without having to check
them into the main source control system. Let's say you're working on
the trunk, and you decide you want to save your changes. You could check
them into the trunk, but maybe your changes aren't ready to be placed
into the build. In VSTS, you create a shelf where you can temporarily
store your changes. I believe that this "shelf" can be shared with other
users if desired, and that it is available from almost any client.
If you were working on several projects (like you have several
changelists in Perforce), you could have multiple shelves. You'd fetch
your files off a shelf, work on that, and then put that shelf back and
work on the next one. Each shelf would be completely separate, so your
changes wouldn't interfere with each other.
You could do the same with a branch in Perforce, but a branch involves a
lot of overhead. The branch is there polluting your source tree. And, if
you create multiple branches, and you want to switch between them, you'd
have to edit your client, do a "p4 sync", and hope for the best.
Although the shelf is a widely talked about feature, it isn't unique,
and other systems use what is known as private branching. In ClearCase,
you almost always develop your source on a private branch and in
ClearCase UCM, it is the official way to develop. In Subversion, you
have a "switch" command that allows you to "switch" between one private
branch and another without creating a new work area. Using multiple
clients in Perforce isn't quite the same as a shelf because your source
is only stored on the local machine while source stored in a shelf would
be on the server.
VSTS's source control appears to be made exclusively for .NET and
probably takes into account many of the quirks of .NET development. For
example, the need to put all webpages in a single directory that
complicates using .NET webpage development with Perforce. (See
<http://www.perforce.com/perforce/technotes/note064.html> for more
information). It doesn't appear that this new source control system will
be placed as a direct competitor against Perforce. However, it will
probably hurt Perforce's penetration in the .NET environment.
My main concern with this new system is that source is stored on a
MS-SQL Server and not in a typical source database. The only other major
source control system I know that does something like this is StarTeam.
My experience with this type of source storage is not good. In a SQL
type system, versions of your code are stored in SQL "blobs". If there
are problems with the SQL server, you kiss your source code goodbye. In
almost any other type of version control system, you can usually extract
your source code, and even fix the underlying problems. You simply can't
do this in Microsoft SQL Server.
I've been doing source control for almost two decades, and sooner or
later, you hit a situation where you run into a major problem. I've
debugged problems in VSS, CVS, PVCS, RCS, SCCS, Subversion, and even
ClearCase. The only place where I was unable to save a source control
system was a place that used StarTeam. It took four techs from Borland
and myself almost a week to just get the system back up and running.
The diagnosis was that the SQL database first got some sort of minor
glitch in it over a month earlier. This glitch slowly grew until it
reach a point where StarTeam would no longer startup. There was no way
to isolate the problem from the rest of the source tree, and basically
our whole source tree had to be trashed. We had to restore the StarTeam
database from six week old backups in order to get around this problem.
I spent another three days pulling out old copies of our source by
setting up a second StarTeam server, restoring tapes, pulling out the
source I could, and placing that back into our source archive. The last
few versions of the source code I ended up restoring by combing through
every computer in our office for snatches of source code.
We lost six days of work and were always nervous after that incident
about the safety of our source code. The only good point of the whole
exercise is that from the various Perl scripts I wrote to save our
source archive, I was able to quickly develop a StarTeam to ClearCase
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Barry Au-Yeung
Sent: Monday, July 10, 2006 7:11 PM
To: perforce-user at perforce.com
Subject: [p4] Perforce VS latest .net source control solution
Has anyone evaluate the latest source code solution from .net? Whats
the name of it?
I heard there are significant improvements compare to the VSS.
I want to obtain the detail comparison.
perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user