a few more answers to Stuart's excellent questions

I still owed Stuart a couple more answers from his last set of questions, and he posted a couple more questions, so these answers should hopefully stand on their own, but check out his questions if the answers seem to lack enough context for digestion. J

1) Yes, there will definitely be importers for VSS repositories (in fact, they’re largely done already, although I’m not on the team making it, so I’m working with their PM on learning more about the mechanics of the importer) and there will be importers along the way for other source control systems – we know no one wants to lose all their source control history switching repositories J.  One thing that we're targeting (at the moment, I can't imagine it would change before release but it might) is that since we know many large companies may incrementally adopt the new VSTS's source control, you should be able to a) import from multiple repositories and b) import incrementally - so if you have five teams, they can migrate over on their own schedule instead of everyone having to migrate at once.  I'm personally recommending that people do migrations so that code dependencies don't cross the boundary between the repositories, but that's mainly to help reduce their potential headaches, not a real barrier.  Note that you can still deal with other source control systems in VS, but you lose all the cool integration when doing so – as an example, SourceSafe/CVS/whatever checkins won’t have the automatic bug updating feature we do in VSTS J

2) When doing the drag-and-drop from an external explorer to VS solution explorer, you’ll get a dialog saying (if you were pasting on top of foo.cs) “A file with the name ‘foo.cs’ already exists.  Do you want to check this file out and replace it?” (this thanks to Ben Ryan who was kind enough to attempt the repro steps you provided while I pestered him in his office J), regardless of whether the file is writable or not.  This should be the same behavior regardless of the source control used as Ben and I understand it (this interaction is handled at a higher VS layer than Hatteras), so SourceSafe should work just as well on this front. 

3) (ok, well more like #2, part 2) – if you cut and paste into a file in VS, it will be modification of the file.  With “checkout on edit” (the default) enabled in your options, as soon as you dirty a file (change its contents, not just double-click it to open it) the source control system checks out the file, so for the cut-and-paste case the checkout will happen as soon as you paste in the new contents, as that will be modifying the contents of the file.  Again, this is at a higher layer than Hatteras, so SourceSafe should act correctly in VS2005 as well (and should be fine in VS2003, I'd imagine, but I haven't tested myself)

4) The read-only status from the Hatteras perspective is our way of checking whether the file is what we think it is from the last time we wrote it during a sync – if you make it writable, change the contents, then make it read-only again (all this without checking it out), then on a subsequent sync, we’ll consider the file to be unmodified and overwrite it. (We could be defensive and checksum each file that we might potentially overwrite, but I think it’s obvious that doing a sync would take much longer if we did so, and that’s a painful hit on the common case to protect against a corner case). If you modify the file and leave it writable, we’re smart enough to label this a conflict and let you decide how to handle it with our resolve dialog/interface (with options like overwrite, retry, ignore - maybe “check out the file” (pend an edit) by the time we ship)