SourceSafe Team's WebLog

SourceSafe blogging - my place or yours?

2007-05-08T21:53:00Z

For now, the answer is "mine". The team that used to manage CheckItOut has mostly moved on since the 2005-era post below. Just in case this blog still has any readers, please visit http://blogs.msdn.com/richardb/ from now on. You can filter for just the SourceSafe-related posts using the VSS tag.

Best,

[Richard Berg]

SourceSafe 2005 has launched !

2005-11-07T20:40:00Z

SourceSafe 2005 is part of the wave of Microsoft products being launched today, along with Visual Studio 2005.

On behalf of the product development team, many thanks to the community of SourceSafe and Visual Studio users that provided invaluable feedback about the Beta versions and Community Technology Previews of the product.

If you want to attend one of the launch events, you can find the information at http://www.microsoft.com/events/2005launchevents/default.mspx

Been quiet here !

2005-07-20T02:00:00Z

Hey folks,

A few days ago someone sent this comment through the blog:

Have not seen you guys post here in awhile. Just wondering how things are going and if there were any new tidbits or updates you could post. As a source control product I really like sourcesafe. I am almost ready to migrate to it, I need understand a little more about it and maybe get a seperate install from the Visual Studio CD, but beyond that, it looks good (the 2005 version).

Must admit that we haven't been the best bloggers out there :( We have been quite busy making sure that we iron out all issues and make SourceSafe 2005 the best release ever ! We are almost there. In just a few months :)

Our friend asks for tidbits or updates:

What first comes to mind is all the work we have put on making sure the SourceSafe Web Service configuration issues are tackled. Great feedback from the community allowed us to identify several bad bugs in the Beta 2 release. We have also beefed up the documentation on this area and I plan to publish a detailed Whitepaper to make sure everyone can give a try to this new fantastic feature upon release. If you have run into issues, please see the answers we have posted at our forum.
We are still looking for your feedback on the product!, please keep using the beta or CTPs and report the issues you run into. At this point in the development cycle you may see a higher number of issues resolved as “Postponed”, every single fix we take has the risk of introducing other issues, so we take a very risk-oriented approach when considering fixes. Rest assured that every postponed feedback item is considered during planning of future versions
In case you missed it, S. Somasegar our corporate VP posted a note regarding key differences between SourceSafe 2005 and Team Foundation Server

Best Regards,

[Alfredo]

SourceSafe 2005 Beta 2 also released !

2005-04-19T02:03:00Z

In case you missed the 1,000 previous announcements: Visual SourceSafe 2005 Beta 2 is now available !

Check it out here and tell us what you think!

[Alfredo]

We are hiring !

2005-02-24T23:19:00Z

We are looking for experienced, C/C++/C# developers!

You can find the complete job description at Microsoft Careers job posting #124178, or the URL below

http://www.microsoft.com/careers/search/details.aspx?JobID=13aea78b-75b3-4e91-af34-64f0edf6670a

MSSCCI, VSIP and SourceSafe experience is a plus.

-grigori
Dev Lead

Globally changing "Store Only Latest Version" option

2005-01-21T01:47:00Z

User JS asks:

How can I globally change the file property to retain history when a given file is checked into the source safe database ?

Running VSS 6.0d. Currently all files are set to not retain old version on checkin (for some wierd reason).

You can't do this globally from VSS Explorer since File | Properties is only available when a single item is selected. Fortunately you can do this from the command line. The -L parameter of the ss properties command turns on store only latest version, while -L- turns it off. So if you want turn off the option for all the files in a project (e.g., $/foo) run the following:

ss properties -L- $/foo/*.*

The properties command allows the -R (recursive) option, so to change the property for the whole database run:

ss properties -L- -R $/

How might this option have been set in the first place? It's available in the advanced options of the Add File dialog in VSS Explorer, so it may have been set when files were originally added. Normally the "Store only latest version" option is unchecked when the Add File dialog comes up, but you can change this default with the Store_Deltas initialization variable in srcsafe.ini (for all users) or ss.ini (for a particular user). Store_Deltas may be set to Yes or No. Setting it to Yes (the default) causes the Add Files dialog to come up with the "Store only latest version" option unchecked. We recommend using this variable rarely. Usually you want to store deltas, and if the variable is omitted, this is the default. If the Add Files dialog is coming up with "Store only latest version" checked, inspect srcsafe.ini and ss.ini to see if Store_Deltas is set to No.

- Rich Knox [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Branch and Delete Behavior

2005-01-10T20:39:00Z

A newsgroup participant recently asked:

After interrupting delete operations there may be orphaned objects. Those may have been branched to other objects that are still live in the database, so the history of the live object is stored in the orphaned object files. To be able to access the early versions, the orphaned object files are thus required.

Is it possible to repair that situation or do I have to keep the files for the orphaned objects (and accept a lot of 'corrupt' information during analyze), or accept losing the live object history?

Does the 'analyze -d' keep the files for such orphaned objects that have been branched? In that case it would be better to use analyze -d to delete orphaned not-used file-objects while files for orphaned project-objects must be removed manually.

If the delete operation would have finished without interruption, would the history then be moved from the file of the deleted object to the branched live object(s)?

These are some good questions and cover some areas we're improving for VSS 2005. Let's first define some terms and discuss some details of branching and history. Then we’ll look at how delete or destroy operations on a branched file should work. Finally we’ll examine what can happen when an operation is interrupted and discuss how to recover from this situation.

Suppose we branch $/Proj1/foo.cpp to $/Proj2/foo.cpp. We refer to the file branched from ($/Proj1/foo.cpp) as the "branch parent" and the file branched to ($/Proj2/foo.cpp) as the "branch child". The relationship between branch parents and branch children is one to many. A branch parent can have many children, but each branch child has one and only one parent. Branch children can also be branch parents. That is, we can branch $/Proj1/foo.cpp to $/Proj2/foo.cpp and then branch $/Proj2/foo.cpp to $/Proj3/foo.cpp. $/Proj1/foo.cpp is the branch parent of $/proj2/foo.cpp, which is the branch parent of $/Proj3/foo.cpp.

When a file is branched, SourceSafe makes a new copy of the file and starts a new history log for the branch child. The first entry in the history log indicates that a branch occurred and refers to the branch parent. This makes the history of the branch parent available to the branch child, but note that the branch parent's history is NOT copied to the branch child's history log.

When we "delete" a file, SourceSafe only marks the file as deleted. The history and tip version are not physical removed but instead are retained so that the user can recover the file later if desired. Only when we "destroy" a file does SourceSafe actually do a physical removal. Even when we destroy a file, SourceSafe won’t actually remove it if it is a branch parent. Even though it doesn’t show up in SourceSafe Explorer, and we can’t recover it, the branch parent is still there to supply history for its branch children.

Now we get to the part where I have to admit that VSS 6 has some bugs. If we have a destroyed branch parent, and if it’s last branch child is also destroyed, then VSS should do a physical removal of the branch parent and reclaim the space it has been using. Unfortunately VSS 6 doesn’t do this, and neither does analyze v6 detect and remove these unused branch parents. This normally isn’t a big deal, since nothing refers to these "orphan" files. Some users, though, do a lot of branching, and eventually these orphan files may represent a significant chunk of the disk space used by their database. The good news is that for VSS 2005 we have improved orphan detection and removal for analyze and will now be able to remove these and other orphan files and reclaim their space. You need to specify the –d switch for analyze to try to remove unused files.

So far we’ve been talking about normal VSS operations. What if we lose connection to the database in the midst of a delete or destroy operation? VSS 6 has all its intelligence on the client. The "server" is really just a file share for the database. By design the client tries to be as fault tolerant as possible, but it can’t be truly "transactional" in the same sense as SQL Server for example. A delete operation, however, is comparatively safe. SourceSafe just makes a log entry in the parent project’s history and sets a flag in the parent project’s list of children to mark the item as deleted. A network interruption could occur between writing the log entry and setting the flag, but analyze can easily fix this. In any event no files are physically removed from the database. When a delete operation is applied to a project tree, SourceSafe really deletes just the project at the root of the tree. Since this project will no longer be visible from the UI, no action is needed on its children.

A destroy operation is more complicated and can cause some of the problems the poster was concerned with. To destroy an item, we make an entry in the parent project’s history, remove the item from the list of children, and then physically remove the files associated with the destroyed item. Furthermore, if we are destroying a project, we have to recursively destroy its children. But that’s not all. If a destroyed item has branch children, we have to retain its history, since the branch children rely on it. Obviously this can represent many round trips on the network. A large recursive destroy operation can take some time, and if we lose network connection during this operation, we’re likely to leave orphans.

As I mentioned above VSS 6 is not as smart as it might be about orphan removal, but it is aware of branch relationships, so it won’t remove any history that we still need. If you have a database where an interrupted destroy operation has left orphans, you can safely run analyze on it. Analyze v6 may not completely clean up the orphans, but it will retain any required history. Analyze 2005 will do a much better job cleaning up the orphans while still retaining required history.

In general interrupting a long recursive operation by terminating the VSS process can cause "bad things" to happen. There is, however, a cancel button that appears in the lower left corner of VSS Explorer during long operations. You can use this to safely cancel an operation. It’s also best to avoid running long recursive operations over an unreliable connection. If you do end up in this situation, running analyze is a safe thing to do, and it will at least partially clean up the database. VSS 2005 analyze will do better and is backwards compatible with VSS 5 or VSS 6 databases. If you still have database problems after running analyze, contact product support. A VSS 6 license comes with 2 free support incidents, and the VSS product support team has additional tools for dealing with database corruption issues.

- Rich Knox [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Transcript from December chat is now available

2005-01-07T19:03:00Z

Transcript is linked below:

http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_120804.aspx

It is time for another chat !

2004-12-04T00:56:00Z

Come and join us next week at http://msdn.microsoft.com/chats/
Wednesday December 8th, 2004
1:00 - 2:00 P.M. Pacific time
4:00 - 5:00 P.M. Eastern time
20:00 - 21:00 GMT

Event Reminders
Add to Outlook Calendar
Tell a Friend

This chat will be focused on the new ability to work from Visual Studio connected to a SourceSafe database via a WebService. If you have questions on how to configure, what features are available, and how to use the Visual Studio Internet Plug-In for Visual SourceSafe please join us!

[Alfredo]

Help us improve branch and merge

2004-09-23T23:15:00Z

Hi,
I'm Rich Knox, a developer on the Visual SourceSafe team. I'm currently looking at improvements we can make in our branch and merge features. We've gotten feedback that SourceSafe’s current support for branching and merging is weak. We won’t be able to make any big changes for the next release, but we’re currently doing work to improve the user experience.

Please post comments concerning the limitations you find currently in branching and merging, and tell us how you'd like it to work. Be as specific as possible. I can’t promise that we’ll give you everything you ask for, but your input will help us pick the best set of changes we can make for the next release.

-rich

Thank you note

2004-09-16T22:13:00Z

Our team would like to say "thank you" to readers of SQL Server Magazine who voted Visual SourceSafe the "Best Source-Code Control Software" this month.

We are especially honored to win this category as a write-in candidate!

[the SourceSafe Team]

Chat transcript is now available

2004-09-01T00:35:00Z

In the link below you will find the transcript for the SourceSafe and Visual Studio Source Control chat from August 5th:

http://msdn.microsoft.com/chats/vstudio/vstudio_080504.asp

Chat tomorrow with the SourceSafe product team

2004-08-04T17:50:00Z

Come and join us tomorrow at http://msdn.microsoft.com/chats/

August 5, 2004
1:00 - 2:00 P.M. Pacific time
4:00 - 5:00 P.M. Eastern time
20:00 - 21:00 GMT

Event Reminders
Add to Outlook Calendar
Tell a Friend

Do you have questions on the new features of source control in Visual Studio 2005 Beta 1 and Visual SourceSafe 2005 Beta 1?

Join members of the Visual SourceSafe team for a wide-ranging discussion on the Visual SourceSafe 2005 features. Talk with the Visual SourceSafe team about your experiences with this Beta version of Visual SourceSafe 2005; and share your feedback on the features you have tested with this Beta.

[Alfredo]

Announcing Visual SourceSafe Power Toys

2004-07-21T23:45:00Z

A while ago the SourceSafe product team had a focus week on creating sample applications that solved common community issues. We call them “PowerToys”. The goal for these sample applications is to address frequently asked questions we observe in newsgroups/email/conferences etc.

We also want to enable the community of SourceSafe users to enhance these sample applications with your own experience on how to make the PowerToys more useful for other SourceSafe users. To achieve this, we will publish the PowerToys as GotDotNet workspaces. That way we can collaborate with you in creating useful sample applications for the SourceSafe user community.

At some point in the future we hope to be able to publish these in the SourceSafe website, for a wider audience to have access to them.

The first PowerToy to be available is the “SourceSafe User Manager”, you can access it at:

http://workspaces.gotdotnet.com/VSSUserManagerPT

This is a simple application that allows exporting & importing of user lists from one SourceSafe database to another. It also allows importing a user list from a Windows group.

We hope you find it useful, and maybe you are interested enough to add more functionality to it !

Stay tuned for future PowerToys,

[Alfredo]

Source control status in Visual Studio

2004-06-30T00:44:00Z

Today we were looking into ways to improve user responsiveness in the Visual Studio IDE by spawning off asynchronous threads to retrieve status for items in the Solution Explorer that are under Source Control. In addition, we are looking at speeding up things by having the Pending Checkins Window update asynchronously as well. Users could still use the Refresh command to force a synchronous update and display accurate, current SCC status.

What do you folks think? Do you have any annoyances or pet peeves concerning SCC glyph, menu or tooltip display in the Solution Explorer or the Pending Checkins Window?

On a personal note: My name is Brad Peterson. I have been at MS since 1996, with the SourceSafe team the entire time. I am excited to finally get a chance to add some great new features to SourceSafe.

[Brad]

PS: In case you missed it, Visual Studio 2005 Beta 1 released today. You will get SourceSafe 2005 Beta 1 as part of the main install of Visual Studio 2005 Beta 1. So please go ahead an try it out !

SourceSafe Team's WebLog

SourceSafe blogging - my place or yours?

SourceSafe 2005 has launched !

Been quiet here !

SourceSafe 2005 Beta 2 also released !

We are hiring !

Globally changing "Store Only Latest Version" option

Branch and Delete Behavior

Transcript from December chat is now available

It is time for another chat !

Help us improve branch and merge

Thank you note

Chat transcript is now available

Chat tomorrow with the SourceSafe product team

Event RemindersAdd to Outlook CalendarTell a Friend

Announcing Visual SourceSafe Power Toys

Source control status in Visual Studio

Event Reminders
Add to Outlook Calendar
Tell a Friend