Hi Toby,
But I also mentioned it earlier. VSS isn't that bad. It does the job
it was designed for, easy version control. As long as you do use the
advanced commands, you won't have any problems.
Hmm, I think I'd have to disagree with you on that one! My biggest
problem with VSS is that Microsoft *knows* that there are serious
data-loss bugs in it.
You got me wrong on this. I totally agree with all your comments on the
known problems of VSS. I should have written my statement in the past.
There where times, when VSS wasn't that bad, because:
* subversion didn't existed
* CVS wasn't easy to use under Windows
* subversion first lacked the very important feature "exclusive locking"
(very important if binary files are involved)
* tortoise SVN didn't existed
* still up to day, there is no SCCS provider for subversion
Esp. the last point is very important on windows if you have to work
with non-technical people (sometimes also with technical people). You
can have the best tools available for a specific job. But if the people
using the tools do not understand why and how they should use them, the
tool is worthless. I took me at least one year to explain version
control to some people (technical and non technical). But every time
they need to change the computer, they complain why the work from
yesterday is lost. (because they forgot to commit the change). They
drive me crazy. No chance to explain them what and why they have to do
special steps. Even writing an operation procedure wasn't enough.
Only the SCCS interface available for a few programs made things a
little better. Because they don't have to switch tools in order to make
their work persistent. And the fact that MS placed the SCCS API under an
NDA slammed the doors for better tools available on the market. The
interface must be so damn simple because of the limited activities you
can perform over that interface, that any programmer would be ashamed if
he places such an interface under a NDA.
So for me the problem is not really VSS. It has lots of weaknesses and
known bugs, but if someone wants to use it, go ahead. They have been
warned. The problem is the missing interoperability of a lots of
commercial programs with the possible alternative version control
solutions. Due to the NDA, you can't easily replace VSS. And due to the
limited possibilities in the API, you can't perform any of the advanced
scenarios, that will easily break VSS. (I know there is PushOk, but it
isn't preinstalled, it involves additional licensing costs and you have
to know about it's existence)
I will never ever propose VSS as a solution for enterprise level version
control to anybody. But I know companies, even in pharmaceutical areas,
that use VSS for more than 10 years, with no problem. Or at least, they
don't know their problems. Probably they never look back in history or
they never perform any bugfixes.
I know that I will have a hard time convincing my team members that we
will not have the VSS style of working anymore: write protected files
and the program is asking for a checkout if you start to modify a file.
They don't care about the possible problems due to VSS and they don't
see the needs involved in project maintenance. It will change their work
cycle and they feel uncomfortable. So I haven't tested ankh deeply.
Anyone who doubts whether MS knows about the problems in VSS should
read
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvss/html/vssbest.asp>.
It's full of little gems such as:
I personally like this one:
* System clocks: Synchronize the dates and system clocks for all Visual
SourceSafe client computers with the Visual SourceSafe server. This
prevents check-in and check-out operations from appearing to happen out
of sequence and *affects any labels* that are applied.
Dirk
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
