Newsgroups: microsoft.public.vb.general.discussion Date: 1999/08/14
Newsgroups: microsoft.public.vb.general.discussion Date: 1999/08/14
I do periodic backup of my VSS on Backup Tapes in case anything happens with the hard drive. But as time goes by, my VSS tree is getting increasingly BIG!
Is there any way to selectively backup the essential files that will allow me to do a full restore of my VSS instead of blindly backing up the entire VSS tree? Could someone describe a backup/restore procedure that streamlines this process?
You should let VSS handle all of this for you rather than picking and choosing. Just goto Administrator and archive the whole database in one step. Restoration is a one step process also. The archive files are not that big in most cases, and if they are, weigh the value of the data against the cost of losing it.
Check the command-line archiver ssarc.
From the help (administrator, utilities)
'Using SSARC, you can:
Archive files, projects, or the entire database into a special compressed file, and then restore it later with history, shared links, and all version information intact. When you archive something from a Visual SourceSafe database using this utility, you can choose to have the object automatically deleted from the database.
Archive specific versions of a file. For example, you could archive all versions of your code prior to version 3.1, effectively freeing up the space those versions use in the database. You can then restore them to the database later if needed.
Archive a file, project, or project tree from one database, and restore it into a different database.
Move files and projects between databases in wide-area Visual SourceSafe installations.
Some things SSARC cannot do:
You cannot leave holes in the archive history.
You cannot move selected versions of a file or project between Visual SourceSafe databases.
You cannot save or restore new versions of a file or project.
You cannot save and restore rights, checkout information, and initialization file settings.
Do not use SSARC as a substitution for making regular back ups of your database.'
But as the help says, you can use it to clean off and archive old versions, reducing the size of your databases.
Newsgroups: microsoft.public.sourcesafe, microsoft.public.visual.sourcesafe, microsoft.public.vstudio.sourcesafe Date: 2000-12-29 21:22:00 PST
> > I am using Source Safe for my project. > > How do I backup the source safe files? > > should I backup all the data files it created on the disk? > >Yes, This is the best way to take the VSS db backup. >Just backup the data folder from the VSS server.
Actually, for a full backup, you'll need more than just the data folder. Since the overhead isn't much, just backup the entire VSS directory and all of its subdirectories. Be sure everyone is logged out of VSS before backing up. See the FAQ at http://www.michaelis.net/SourceSafe/Faq.htm#_Toc467388281
Joe
Make sure that no one is using the database and that Analyze will not begin to run while you are backing up the database. Use any backup utility to copy the \DATA, \LABELS, and \USERS directories.
Newsgroups: microsoft.public.vstudio.sourcesafe Date: 2002-08-19 22:35:56 PST
>It is recommended to backup the VSS database. >What is the best procedure to do. Must I use the VSS >Archive utility and eventually the restore utility to >restore the db? >If one speaks about backing up the VSS db do they actually >mean using the archive utility ? >What is de difference between back up and archive?
Archiving is more permanent than backing up. Use the archive functionality to deal with portions of the database. For backup purposes you can use normal backup programs. Backup the entire VSS directory tree and you're done.
Joe
http://mail.gnu.org/pipermail/info-cvs/2001-March/013565.html
I've read the information I could find in the archives, but there's one question left unanswered in my tiny little brain…:
http://www.laine.org/cvs/vss2cvs/ gives much information and scripts, but doesn't answer the one question I could really do with before making the final push to switch to CVS.
Are there any patches or techniques for CVS similar to the sharing functionality in VSS?
> Are there any patches or techniques for CVS similar to the sharing > functionality in VSS?
You can do something similar to sharing *entire directories*, via specifying lines in the file CVSROOT/modules (look up the "modules" file under "CVS Administrative files" in the documentation).
There is no CVS equivalent to VSS' sharing of individual repository files into multiple places in the work directory, though. Many people will tell you that sharing files from the repository is bad anyway, since it often makes it nearly impossible to fully test changes before doing a commit ("checkin", for a VSS person). The unfortunate reality is that it seems to get used by VSS people *a lot*. (As a matter of fact, a reorganization to eliminate shares of single files is the one thing that's still holding us back from converting :-( ).
The only suggestion I can give is to reorganize your source so that any shares are done as entire directories (and try to make as few as possible, since your modules file could otherwise get quite messy). Look at this as an oppurtunity to give your source code that well-deserved organizational overhaul you've been wanting to do for so long! ;-)
> There is no CVS equivalent to VSS' sharing of individual repository > files into multiple places in the work directory, though.
Well, not natively in CVS, but if you're running it on a server that supports _symlinks_, you can approxmate that behavior, somewhat.. Just symlink the actual repository files to multiple places, works rather well.
The political issues that you raise are correct, though, testing becomes much more complex, I generally use it for simple header files and junk that doesn't change much..
Symlinks in the repository are not for the faint-of-heart (actually, just about anything where you're mucking about in the repository isn't for the faint-of-heart), and things do occasionally get a bit goofy (usually only after I've been mucking about), but I generally find things easy to fix.
Please, backup and _test_ your backups before you go doing anything that involves hopping in to the repository directly..
jon
> > There is no CVS equivalent to VSS' sharing of individual repository > > files into multiple places in the work directory, though. > > Well, not natively in CVS, but if you're running it on a server that > supports _symlinks_, you can approxmate that behavior, somewhat.. Just > symlink the actual repository files to multiple places, works rather > well.
CVS sets locks on a per-directory basis when it is modifying the repository (eg for a tag or commit). If a ,v file is symlinked into multiple directories, two different CVS processes might believe that they have "the lock" that allows them free reign over that file, and one will end up clobbering the other.
A symlink of a directory, on the other hand, likely won't cause any problems. but of course, you can do that via a modules file entry…
> The political issues that you raise are correct, though, testing becomes > much more complex, I generally use it for simple header files and junk > that doesn't change much..
That would lower the likelyhood of a corrupted file, but not completely eliminate the possibility.
> Please, backup and _test_ your backups before you go doing anything that > involves hopping in to the repository directly..
I'll go along with that. Heck, I even do a backup before every import, just in case I do something fumble-fingered.