Cloning VSS Settings across Databases
Stupid VSS Trick #2 '-D' stands for Deprecated.
VSS admins are constantly asking how to copy database settings, such as
user list, permissions, custom srcsafe.ini variables, and user-specific
ss.ini settings from an existing database to a new one. To date, the
documentation has not ventured very far into this thorny thicket.
Some VSS database settings, such as certain srcsafe.ini settings, are easily copied to
a new database. However, the process can be manual and error prone. Other settings, such
as user list and permissions, are extremely difficult
to replicate across databases. I am happy to report that the super-smart and
insanely responsive members of the VSS product support
team recently developed a user list migration utility. For
a copy of this utility, you can leave me your email (obfuscated
to avoid email collecting spam agents) in the comments for this post
and I will send you the files asap. The utility, which is still being tested,
has not been released to the Microsoft Product Support Services site. When it
does go public, I will post an announcement on this blog and will probably
do so on https://msdn.microsoft.com/ssafe as
well.
As I was saying, some settings are easy to copy from database A to database
A1 and A2, and some settings are not. However--and this is where the
stupid VSS trick begins--there is an undocumented, gotcha-ridden,
and "officially deprecated" way to create and configure one database
to your liking and never do so again for subsequent databases. If you're
familar with IIS, this hack is similar to correlating IPs with friendly
NetBios names in the LMHOSTS file. In short, don't try this at home
kids.
- Using the VSS Administrator user interface, create a new database
called db_template in C:\Trash. - In VSS Administrator, create two or three
users. At least one of the users should be Read-Only. - Open Windows Explorer, browse to C:\Trash and copy
the \Data directory to C:\Delete. - From C:\Trash, copy the User.txt file to C:\Delete.
- Click Start, click Run, type "C:\Trash\srcsafe.ini",
and press Enter. - In Notepad (or your favorite editor), find the line
"Data_Path = Data". - Directly beneath that line, type "Data_Path (db2) =
C:\Delete\Data", where (db2) is a variable--or database alias--to which you
will later refer. - Close srcsafe.ini and all VSS applications.
- Click Start, click Run, type CMD, and then press
Enter. - At the command prompt, Change Directory
to C:\Trash. - Type "SET SSDIR=C:\Trash" (this and the precending
step may be unnecessary but there's no reason to not do them.) - Type "SSEXP.EXE -Ddb2" and then press Enter.
You can create as many empty 'databases' as you want in this way, copying the
\Data directory and Users.txt file from db_template to other filesystem or
network locations and then referring to them by alias using the -D
switch. Conceivably, you might then create desktop shortcuts to
the various databases that run a DOS command like SSEXP.EXE -Ddb3 or SSEXP.EXE
-Dmydatabase.
Weirdness #1: Open both db_template and db2 in separate
instances of SourcSafe Explorer. Look at the title bars for each... They both read "Visual SourceSafe
Explorer -- db_template
". To confirm that you're looking at
different databases, you can add a file to one database and refresh the view in the
other. The only way to visually distinguish between these two two databases is by content.
Weirdness #2: no matter how hard you try, you can't
open db2 from the Open SourceSafe Database dialog box because it isn't
really a database. *
It doesn't have its own SRCSAFE.INI file. Neither
does it have its own set of user-specific SS.INI files. One set of
settings::multiple databases.
Weirdness
#3: Open both db_template and db2 in separate instances of SourceSafe Explorer. Drag and
drop a file from $(db_template)/ProjectA into $/(db2)/ProjectB. As I
recall, this action appears to do something but does not actually do anything. Next, drag
$(db2)/ProjectA to a new ProjectC in db_template. Doing so actually shares and branches ProjectA but
not the version of ProjectA one would expect. It shares and branches
(or copies) $/(db_template)/ProjectA to $(db_template)/ProjectC!
* The source of all of this odd behavior is this: when you
copied the \Data directory from db_template in steps 3 and 4, a new database
identifier was not created. Both db_template and db2 think they're the same
database.
In conclusion, this hack can result in some stranger
than strange behavior. That's why I call it a stupid VSS trick and note
that it has been"officially deprecated". Stay tuned for more unnatural
VSS acts in future posts and run Analyze on your
favorite VSS database today. Your database will thank you.
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.