VSS Visual Merge

The VSS Visual Merge can help you easily paste together two different changes to the same file. The VSS documentation makes it sound like Visual Merge will always be invoked not only when two different users modify the same file but also whenever you do a "get" and the local file is already marked writable. But in actuality this doesn't always happen. Often VSS overwrites a local file that's already been modified, rather than incorporating its changes.

Question

The VSS doc implies that I can Get a file such that it will merge with my local writable copy. This doesn't work for me --- it doesn't merge, it just overwrites, no matter how I set various options.

I'd like to do the following reasonable thing: work on a local, writable set of sources. Then, when I have a batch of fixes ready to go in, check out the appropriate files, install my fixes, and check them back in. I'm looking for a way to do this which doesn't involve manual merging. So far SourceSafe has defeated me at every turn.

Answer

SourceSafe is pretty smart (sometimes too smart :-) about when to do what kind of merge. It will do a merge only if it both

• thinks two sets of changes might have been made in parallel
• can identify a "common ancestor" version

It does this regardless of what options you have set. It's behavior works very well with "multiple checkout" situations etc., but does not work if you try to make changes to your local copy without first "checking out" the VSS files. Also, SourceSafe will try to do a silent merge first and may show you its Visual Merge window only if it's stumped. Supposedly you can control this behavior with SourceSafe options, but my experience is this is only partially true: I've never been able to force a Visual Merge in all cases.

The documentation that seems to say that SourceSafe will do a merge whenever you do any sort of "get" and your local file is writable is misleading at best; SourceSafe only does merges in more restrictive circumstances.

The easiest thing to do is to not fight SourceSafe (working on local files first then checking them out just before checking them back in may seem reasonable to many people, but does not seem reasonable to SourceSafe - or to put it another way "bang head here"). Check out the files when you start to make changes to them, not when you're finished making changes. SourceSafe looks at the "checked out" status as a signal that you intend to change the file, and so it should carefully track all other changes in the meantime. If you don't check out the file until you're done making changes, SourceSafe has incomplete information about the status of the file, has to make some guesses, and doesn't always make its guesses the way you think it should ...including not doing a "merge" just because the local file is writable.

You can always check out too much and then "Undo Checkout" on some files. You can even make undoing your extra checkouts almost completely automatic by setting Tools|Options[General](Check In Unchanged Files) to "Undo Checkout". The only case where this option doesn't quite work is if the file contains "VSS Keywords". Since the keywords are expanded when you check the file out, the local file will always appear at least a little bit different than the one in the database even before you've made any changes to it, and so an automatic "Undo Checkout" will never happen for files containing expanded VSS keywords.

If the files on your local disk contain changes VSS doesn't know about yet and there's any question at all about checking the changes in to VSS, make a copy of the files somewhere outside your VSS working folders. Then if something goes wrong and VSS overwrites your local file with the previous version from the VSS database, you still have a copy of your changes. VSS can overwrite even files marked read-only. VSS seems to always do the right thing, but even so buy yourself some insurance ...especially in unusual situations where there's a possibility VSS will react in an unexpected way.

If you trust the files on your local disk and don't want to use SourceSafe's copy, maybe you don't really need to do a "merge" at all. All you need to do is suppress the "get" that normally gets triggered by a "checkout". To do that, hold down SHIFT while clicking "checkout", then check the "Don't get local copy" box before you click the [Okay] button. This will do what you want without any need to merge at all. Of course if somebody else checked out and modified and checked back in one of the files in the meantime, doing this will overwrite their changes making their changes appear lost. Think of the "Don't get local copy" check box as telling VSS "trust me, I know the copy on my local disk is current". By disabling all checking, it makes it easy for you to shoot yourself in the foot.

All that said, there is a trick for forcing SourceSafe to do a "merge" even when it otherwise wouldn't. The trick is strange, in fact it's just plain nonsensical. And it relies on what could be considered a "bug" in SourceSafe. But it works. You have to proactively do it for each individual file; it's not automatic and it doesn't affect a whole bunch of files all at once and it won't be "remembered" for future occurrences. Use the VSS GUI to display the "History" of the file in question, and note the version number of the version you should have checked out. Then pop open a command line box and enter

SS CHECKOUT -Vn -G- "$/proj/subproj/file.xyz"

where n is the version number you wrote down. This will trick VSS into thinking you checked out a previous version (something you can't do through the GUI and that SourceSafe doesn't support). Then when you do the real "checkout", SourceSafe will invoke its "merge" according to the documented options.