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

• Anonymous
  October 04, 2004
  The comment has been removed
• Anonymous
  October 07, 2004
  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?
• Anonymous
  October 07, 2004
  The comment has been removed
• Anonymous
  October 07, 2004
  Krishna,
  
  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?
• Anonymous
  October 08, 2004
  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 :-)