Addressing comments from other posts

Calvin raised a few questions in an earlier post that I wanted to answer in a new post (the comment chain on that post was getting pretty long). You can read his last two comments here.

I doubt installing the SQL2005 beta side-by-side with SQL 2000 is an issue (if it actually installed as an upgrade to SQL 2000, that could be an issue, but I didn't realize it would even allow you to do so). As I said before, some perf issues with prc_get were found and fixed since the CTP shipped, so that's almost certainly what's raining on your parade. I can't get you updated bits, but I believe there will be another CTP release in the not-too-distant future.

Our branching story is more like perforce than VSS. When you branch, by default it will create the branched items in your workspace (which means you'd pay the per-file copy cost at least as far as your client's filesystem is concerned). However, the server side operation is (logically) a link operation at branch time, and you can choose not to create the branched items in your workspace at branch time if the local filesystem cost is a problem (from the command line, you'd specify the /noget option; in the VS UI, there's a checkbox from the branch dialog).

As far as support for SQL2000 and VS2003 goes, it all comes down to what Team System needs (not just the raw Version Control feature set). Team System depends on features new to Visual Studio 2005; there's no practical way to make it "plug in" to VS2003. I'm not sure if the version control components themselves depend on SQL2005 or not, but I know several features of Team System (including the reporting features relating to version control) do depend on new features in SQL 2005. So, while I'm sure there is a marketing angle to the version dependancies, there are definitely technical reasons as well.

I hope that covers your questions and concerns (and is of some interest to other readers). As always, feedback and/or additional questions are welcome.

Comments (6)

  1. Calvin says:

    Thanks, Chris.

    I was in hell with VSS, so I don’t even bother try VSS 8.0.

    I am in the middle of testing perforce, it looks pretty good. Hatteras shares the same concept and style of perforce except it’s going to integrate with VS better, that’s why I am so excited about it. Unfortunately, it beat me on the firsr try. 🙂

    So, any idea it’s going to be out? Is there anyway to make it a standalone installation instead of embedding in TEAM foundation? TEAM foundation installation gave everybody a painful experience, that I guess nobody want to touch it any more until they heard somebody else actually tried to use it.

  2. Krishna says:

    We were excited to hear that the source control for Team system is being implemented from ground-up. we have been trying out the beta with good success. One of the things that we were looking for is atomic check-in for multiple files, since the system is going to be SQL Server based, is there any plans for supporting this? The second is would there be any kind of lock mechanisms available? For example if a user is checking-in their files and another user is getting the latest version, this user would be blocked till all files from the first user is checked-in?

  3. Chris says:


    I don’t know "for sure" when we’ll be out, but it is Visual Studio *2005*, after all. I’m just too low on the totem pole to have the information (or the authority, even if I did) to say.

    You won’t be able to have a standalone installation of Hatteras, though you could certainly choose to use only that component (and there’ll be various ways to use other solutions for the other components). There is a command-line client to Hatteras, so you don’t have to be in Visual Studio to use it, if that helps.

    The CTP installation was a pain, I know. I can tell you that we’re certainly working on improving the whole experience, setup as much as anything else. We’re better now, and we’ll continue to get better as we approach release.

  4. Chris says:


    Yes, checkins for multiple items can (and usually ARE) done as an atomic transaction. You select any subset of items with pending changes, and attempt to check in – either they’re all checked in successfully, or none of them are. Various conflicts (such as a newer version being created since you checked out) can be resolved before, during, or after the check in attempt.

    There are lock features to prevent checkouts and checkins while a user is making changes (if desired); but I can see that’s not the type of locking you’re describing. For your scenario, the user getting files will either get ALL of the checking-in-user’s changes, or none of them. Basically, you get the versions of items at the time you "started" your "get latest", so any new versions created during your get won’t show up haphazardly.

    Does that address your question?

  5. Krishna says:

    Thanks Chris, Exactly what I was looking for, with the current vss quite often we ran into compilation errors because someone is in the middle of a check-in and we were getting the latest version at the same time, this type of locking should cover my scenario…Great that a lot is being taken care of with the new system, a benefit if you are starting from scratch 🙂

Skip to main content