Migrating from VSS to Hatteras
Buck posted the preliminary plan on VSS->Hatteras migration, be sure to check it out if you currently use VSS and might be looking to make the change.
The comments are mainly focused on the drawbacks - you lose VSS sharing and pinning.
I think between the label and locking capabilities of Hatteras, people that use pinning should still be ok. However, if we could hear an example or two of how people use pinning, we can either show that Hatteras fulfills the same need, or we'll have a nice feature request :)
As far as sharing, there seems to be two main scenarios that people are using sharing to provide:
1) Common or 3rd-party code or libraries that are used by many projects, but in such a way that either none of the various projects are updating it, or they're all taking the same updates (e.g. when a new version of the library comes out).
2) Common code that any of a variety of projects might update.
I'll talk about number 2 first (naturally). This scenario is what Albert Einstein and others call “spooky action at a distance”. Granted, they're talking about particle physics and we're talking about source control, but the parallels are actually fairly strong.
The underlying assumption is that all of those projects sharing the object(s) don't mind having new versions show up, either because the people touching the shared objects know of all of the clients of the object, or are reasonably certain that their changes won't negatively impact any of them. This, in our experience at least, is not true, but that does NOT mean it isn't true for you. Ask yourself if you've ever had project A break because someone updated the shared code in project B - nothing wrong with project B still, but all of a sudden, project A won't build, or has some kind of new 'bug' that turns out to be due to a change in that shared code.
If you've never had this happen to you, then you're the perfect customer for VSS-style sharing. If you HAVE been a victim of this, then I will make the claim that you don't want sharing, you want a branch and merge model instead. I also believe the #1 folks want branch-and-merge, so let's move on to that.
Branching and merging between branches lets you decide when the various branches pick up changes (either from the original 'trunk' to the branch, or the reverse - even across branches with a “baseless” merge, but that's another blog entry all by itself).
So, for the #1 folks, you'd branch your shared code into each project tree (using disk space that scales on the order of a few bytes per file branched, not to the size of the files branched, mind you). Then, when a new version becomes available, you'd change the trunk, make sure it's happy, and check in. Then, in each branch, you can pend the merge of the changes, ensure everything in that project is still happy, and then check in - making any changes to that project's sources, if necessary. If you find yourself having to change the branched bits to make things work (this represents some segment of the #2 crowd, the question is how big a segment), you can then decide whether and how to merge those changes back to the trunk, if you want to keep the shared code as identical as possible across all the projects.
While sharing works very well for those it is ideally suited to, it does something between frustrate and completely fail for those it is NOT ideally suited for. Branching and merging are somewhat more intimidating, but is significantly more flexible, letting you choose when, and tailor how, shared items are updated.
Obviously, neither system is universally ideal - there are clearly those of you out there that will never run into the potential “spooky action” that sharing can lead to. I'm curious to know, from among those of you that use sharing, how many of you fall into category #1 above vs. category 2 (or still other categories I haven't been made aware of). I can envision a way to make branch-and-merge act like sharing, in terms of a policy you'd turn on (like exclusive checkout) - that is, if you check in a change on a branched item, you would want to automatically merge that change throughout the branch tree for that item.