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)

Comments (3)

  1. Stuart says:

    Again, thanks for the thoughtful and well-researched answers 🙂

    The only one that still leaves any open questions for me is #4 – I wonder if you could use the modification date of the file as a ‘red flag’ to indicate that a file is worth checksumming, to avoid the performance hit on the sync operation while still avoiding the dataloss risk if somebody did something stupid with the writability of the file.

    (An example of a way that a file could get modified without becoming writable that’s not quite so extreme: using Windows Explorer to copy a file from (the working folder of) some other branch, and saying yes when asked if you want to overwrite the read-only file. If the source file is checked in, it’ll also be read-only, so the destination file will be read-only after the modification. If a user doesn’t realize that it’s Hatteras that made the file read-only, they may not realize the implications of saying yes to that dialog box…)

    If a user managed to modify a file, restore it to read-only status, and *also* set the timestamp to *exactly* what it was when Hatteras last fetched it from the repository, they deserve what they get 😉 At least, I can’t think of any way to accidentally manage that…

  2. I’ve spent the last hour talking with Buck (http://blogs.msdn.com/buckh/) and while it’s not as nice of an answer as I’d like to provide, the concensus is that it’s a possible (even likely V2) feature, it may be a V1 powertoy kind of thing, but it’s almost certainly not going to be part of V1 at this point unfortunately, there’s too many other things to get done before we ship.

    The great thing about the read-only flag is that it’s per-file meta-data – we don’t have to separately store anything anywhere. If NTFS had per-file meta-data (streams notwithstanding), we could store "last Hatteras sync time" along with the file, and then later syncs can check that "last modification time" == "last Hatteras sync time" and if they don’t match, warn/error/whatever.

    As-is, though, we’d have to store the last Hatteras sync time (specifically, the modification timestamp from the file when we last synced it) somewhere ourselves (in a file, in the registry, wherever) and that introduces tons of problems and a lot of extra storage for a (in our opinion) corner case.

    IOW, in an ideal world, our sync path will do that check, but it won’t be in the out-of-the-box V1.

    A couple of options, though:

    1) our object model – we’re talking about firing subscribe-able events both after a file is synced (already in place) and potentially one before the file is synced, allowed veto’ing of the file sync. Those 2 events would be enough to implement the functionality desired. (after-sync event does the mod time lookup and store, before-sync event does the stored time lookup, compare with mod time, veto if changed but file is still read-only)

    2) a new tool that uses our existing web services to get the server’s checksum for the files in the workspace, calculates the ones locally, pends edits on files that have been changed. I kind of like this approach – something that doesn’t affect the typical case, but developers can run if they need to do tree changes outside of VS and aren’t sure whether the necessary edits have been pended.

    In any case, it’s not going to be transparent and part of the normal process in V1 (unfortunately – I do like the concept) but there will be options for either plugging in additional logic (that’d be something that we could definitely release as a powertoy – the "use the object model" approach of #1) or adding a "fixup my workspace’s potentially modified files" kind of tool (also a potential powertoy kind of thing)

    Great idea, Stuart! Sorry it won’t be a V1 thing (it had been cut already) but hopefully we can help you out soon. FWIW, the more customers that demand something, the more the feature gets promoted. It’s hard for us to judge relative feature value on an unreleased product, nor how many customers it affects (no product support history) so rest assured that if this affects a lot of customers (and I wish we psychically knew somehow), it will be addressed sooner (V1 powertoy perhaps?) rather than later (V3, V4 🙂