VSS 2005: how do I create branch at the point of a label? - visual-sourcesafe-2005

Using Visual SourceSafe 2005:
At an earlier point in time I labelled my source to indicate the release of a new version of the software.
What I want to do is now create a branch where the label was created, in order to release a minor upgrade without including other work that I have been doing on the software.
Do I use a branch for this, and how do I do this in VSS 2005?

I'm unsure what you mean. However, go to your topmost level project folder then show history. You can click get on any label you see in the history. Please ensure you put this branch somewhere different to your current development branch.

Related

Restoring old version to current writable in Visual SourceSafe

I am working on an ASP.NET application in VS2010; the repository is still VSS-2005. I am going to abandon the changes made to one of the pages and revert back to the version that existed two checkins ago (which is the current production code). My problem is that I haven't worked with VSS much and I've never done this particular thing before. I can't find any "How to" literature on VSS that tells how to do it, and when I try to do it using the intuitive thing (do a "Get" on the version I want to revert to), it does nothing.
I can View that older version using Notepad, and so I could check out the page and replace the code with the Viewed Notepad version, but this doesn't seem proper somehow.
I've been wondering about the Rollback button, but when I click it, it gives me an ominous message that I am not sure I like: "Rollback cannot be undone; some versions will be lost irretrievably! Continue anyway?"
Well, apparently there are no SourceSafe gurus out there, so I'll answer my own question. I bought a book! And it told me how to do it.
Overview:
Check out the current version manually
"Get" the version we want to revert to
Check in the older version as a newer version
Details:
Check out the current version, then use the View History command to show the History dialog and select the version that is desired to be reverted to.
After selecting/highlighting this version, click on the Get button. The Get dialog shows where the specific file version will be placed along with several options. By default the path in the To text box points to the file in our workspace, which is what we want. Don't select the "Make writable" option since the file in question is already under source control. Leave everything as defaulted, and click OK. In the next dialog, choose "Replace". SourceSafe gets the older verison and overwrites the one in the workspace.
Now that you have the older base version, all you have to do is check in the version and obtain a new version that is identical to the old one.
I got this information from the book "Visual Source Safe 2005 - Software Configuration Management in Practice" by Alexandru Serban, published by Packt Publishing Ltd. I bought the book used, but found you can still get it new from the publisher for a lot less than the list price -- $20 less! I don't know who might need a book about an obsolete source control system, but don't pay full price, get it from the publisher direct! Amazon charges the full list price on new copies (astonishing).

filters in the Pending Changes view of the RTC client for Visual Studio

I'm using RTC a lot and my project has quite a number of components. To see only the components that I'm interested in (the ones with changes) I select a filter in the RTC Pending Changes view. However, whenever I reopen Visual Studio my filter selection is gone. As I'm switching between quite a number of sandboxes and Visual Studio instances daily, having to set the filter again some 2 dozen times a day is getting quite tiresome. Is there any way to save the filter setting?
Another approach would be to use only repository workspaces with the right components in them: when you define a repo workspace, you don't have to select all components from the stream.
That way, the sandboxes can load all components from your repo workspace, without having to set any filter.

TFS 2012 build definition: Parameter Items to Build: cannot convert value Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings

After a lot of editing of my build templates (I recreated them in 2012 to avoid any issues.. but then I suppose I got sloppy and simply copy/pasted whole blocks from the old workflow, and I suppose that must have completely destroyed my versioning) I now have problems with just one build definition based on the build template I edited. (All other ones seem to be working fine.. so I suppose that one got a problem during all the editing. (I was mostly adding and removing Version=11.0.0.0 to the assemblies in the build template))
The exact error is:
Parameter Items to Build: cannot convert value
'Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings' of
type Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings
to type
Microsoft.TeamFoundation.Build.Workflow.Activities.Buildsettings,
reset to default.
It is displayed when editing the build definition and wanting to select the project/solution and configuration to build. Actually, with this now I cannot save (without error) any more and the value gets deleted again.
(I am using VS 2012 (VS 2010 still installed) against TFS 2012.)
How to fix?
Open up your XAML and look at the xmlns's on the Activity root node:
Here's a snipped version of mine:
<Activity mc:Ignorable="sads sap sap2010" <!--Removed-->
xmlns="http://schemas.microsoft.com/netfx/2009/xaml/activities"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:mt="clr-namespace:Microsoft.TeamFoundation;assembly=Microsoft.TeamFoundation.Common"
xmlns:mtbc="clr-namespace:Microsoft.TeamFoundation.Build.Client;assembly=Microsoft.TeamFoundation.Build.Client"
xmlns:mtbw="clr-namespace:Microsoft.TeamFoundation.Build.Workflow;assembly=Microsoft.TeamFoundation.Build.Workflow"
xmlns:mtbwa="clr-namespace:Microsoft.TeamFoundation.Build.Workflow.Activities;assembly=Microsoft.TeamFoundation.Build.Workflow"
xmlns:mtbwt="clr-namespace:Microsoft.TeamFoundation.Build.Workflow.Tracking;assembly=Microsoft.TeamFoundation.Build.Workflow"
xmlns:mttbb="clr-namespace:Microsoft.TeamFoundation.TestImpact.BuildIntegration.BuildActivities;assembly=Microsoft.TeamFoundation.TestImpact.BuildIntegration"
xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client"
xmlns:mtvc1="clr-namespace:Microsoft.TeamFoundation.VersionControl.Common;assembly=Microsoft.TeamFoundation.VersionControl.Common"
Look for Version Specific references (usually "10.0" or "11.0") and remove them so they look like the ones I have above.
Also, check you project references and ensure that they are not Version Specific.
Here is HOW to change the assemblies in your TFS Template:
In Source Control Explorer, browse to the BuildprocessTemplates and
open (double-click or choose "View" from the Right Click menu) the
template that your build is based on (the one giving you the above
error)
You should see a visual diagram of the workflow. At the bottom are
three tabs: Variables, Arguments, and Imports. Click on Arguments.
Select the BuildSettings Argument
Find the Properties box. The properties for an arguement are:
ArgumentType, Direction,IsRequired, Name, and Value.
Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings
should be the selected Type but the problem is (typical) you can't
tell which version of this assembly is selected. Click the drop
down.
At the bottom of the list choose "Browse for Types..."
NOW you can see all of the available assemblies and their versions. Choose the one you want, most likely upgrade to the latest. Be sure to go through all of the various arguements and make sure their types are all are set to the same version to ensure compatibility.
You may encounter issues now saving the file. All may appear to be ok. TFS indicates it knows the file has changed, checkin seems to go smoothly, but when the file is opened the assemblies still reflect v 10. If you open the same file from the file system you may find that the assemblies in the file really are v 11. What give? No idea. Some sort of glitch in VS.
But here is a work around:
Uninstall VS 2010 Team Foundation Server Power Tools from your
development machine
Open VS 2012 and make sure the template has no pending changes (undo) and get latest version
CHECK OUT FOR EDIT (important) but do not make any changes in VS (it
won't open anyway since the 10 assemblies were uninstalled in a
previous step)
Close VS 2012 (important because if it is open it will appear that your change didn't take)
Open the template from the file system (I used notepad to eliminate any interference from VS) and perform a find/replace on "Version=10.0.0.0" with "Version=11.0.0.0" and save the file
open VS 2012 and now you should be able to see the workflow designer
Of course, check in the file

What does this purple 'T' icon mean in Visual Studio/TFS 2012

I'm using Visual Studio 2012, linked up to TFS 2012 for source control.
I've just branched some code, but after creating the branch files it told me I don't have 'Manage Branch' permission.
Not an issue, I can sort that, but my Google skills are failing me when it comes to working out exactly what this little purple 'T' icon means in the source explorer window.
I presume it's a pending change?
LATER THAT DAY : After sorting the permissions out, I checked the new branch in ok and the icon disappeared, but I'd still like to know what it meant, and how to identify any other icons that might appear.
It's just the new VS2012 icon for a pending Branch action. If you look closely, it's not a 'T' but actually an upwards facing split arrow. A larger version of the icon can be seen if you look at the File -> Source Control -> Branching and Merging -> Branch menu item.
Normally you won't see this since branch actions are usually performed server side. In your case since you didn't have permissions it was tracked as a pending branch request, and cleared once your permission problem was resolved.
When you check in your new branch the purple icon will disappear.
The purple T symbol will be shown next to all files in a newly created branch that has pending changes (the branch is created but not checked in). I assume this is the 'pending change' indicator at source control or branching level.

TortoiseSVN: how do I undo the last Update command?

The last TortoiseSVN Update command loaded work-in-progress code from the trunk which shouldn't have been committed yet, and overwrote the files that I had on my branch.
How do I undo that last Update command and revert back to the versions that I had on my machine before the Update?
There is no "undo" or "revert", but if you update to the previous revision, that is the recommended way to accomplish what you are asking for. In TortoiseSVN, select "Update to revision..." and enter the revision number you want to go back to.
revert back to the versions that I had on my machine
If you had local changes on your machine that were never committed (i.e., no revision number), and you updated over them, then you are out of luck. The only way to get back your local changes is if you have a backup (check the "Previous Versions" tab in Windows Explorer...)
Check out this guide for undoing revisions on TortoiseSVN. The entire concept of version control supports the issue you've created for yourself so it is a popular action.
This is called update to revision... In the ui you can choose which version you want to go back to. Make backup copy of your local svn tree first to be safe!
You can update to a specific revision by right clicking on your working copy, Under the TortoiseSVN menu item, there is a update to revision menu option that will allow you to change your working copy to the revision of your choice. If you do a show log on the repository you can get an idea of when the offending code got committed and revert back to the prior repository revision. As a precaution, I would make a copy of and working copy, or important files in your working copy, to ensure that if things go bad, you can always get back to where you are now.
Now this changes your working copy, not the repo, so if you are wanting to revert the repository back, then that is a different issue, but I do not think that is what you are asking for.

Resources