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).
Related
I've noticed an immense delay (just sitting there doing nothing) since upgrading to the latest version of windows while using tortoiseSVN to compare any file to its base version [TortoiseMerge].
I was on the fast track and got the fall creators update about a month ago and noticed this too so i reverted back and it went away. After it hit RTM I thought this was fixed but apparently I was wrong.
What do I mean with very slow?
Before fall creators update: <1 second
After: A minute or 2, as long as it takes..and that's just for comparing 1 file.
I just go read an article or something and wait for the tortoiseMerge icon to popup in the taskbar.
Repo is on my Desktop - Client is on my Laptop - same network.
Anyone with a similar experience? Did anyone find a workaround?
Edit:
The issue has more to do with TortoiseMerge than TortoiseSVN or SVN itself - I switched to Beyond Compare and it is working well for now.
The issue is already reported to Microsoft and Microsoft fixed in in Visual Studio 2017 15.6 when you recompile your code. Here the fixed MFC without the slow Get/SetPixel is used.
To fix in in Windows 10 for current and older compiled tools which use MFC, Microsoft released the Update KB4058258. The release notes don't mention the fix, but it is confirmed by the reporter that the fix is part of the cumulative update.
So installing the Update should fix it. So if you have the issue, make sure you run at least Build 16299.214 (run winver.exe to see the number).
If you have this or a higher number at last position, the issue should be gone.
The old and outdated information are archived. See the revisions of this answer for the old workarounds.
Instead of removing the "ribbon" setting, or changing security in Windows, I installed the last nightly build (1.9.9.x), and the performance is back.
I looked at the settings, and the ribbon is still checked as default. But the performance is there.
https://nightlybuilds.tortoisesvn.net/latest/x64/full/
As a workaround, you can use the TortoiseUDiff tool instead. It is still fast. Here is what I do:
Right-click a working folder in Windows Explorer and click 'SVN Commit'
Select one or more files in the 'Commit > Changes made' list
Right-click the selection and select "Show changes as unified diff"
It's not as powerful as TortoiseMerge, but if you just need to see the changes you are committing, the above method still works fast.
After installing 2018-01 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4058258) the speed problems for WinMerge appear to be completely fixed.
In the TortoiseSVN settings window, I
selected Diff Viewer/Merge Tool section
checked External
selected WinMerge.
Works like a charm.
It did a trick for me. I allowed TortoiseSVN program in my antivirus firewall protection settings. It made SVN Commit fastest.
Go to your antivirus. I have Quick heal. So I will tell you the steps accordingly.
1) click on "Internet & Network"
2) Click on "Firewall protection"
3) Check for "Program rules" and click on "Configure" button.
It will open a window displaying the list of allowed Exe on your system.
Your antivirus blocks tortoiseSVN and related exes, if they are not in
allowed Exe list.
4) So now click on "add" button, open dialog box will popup.
5) Go to "C:\Program Files\TortoiseSVN\bin" directory
6) Select TSVNCache.exe, TortoisePlink.exe, TortoiseProc.exe, ConnectVPN.exe And
click "open" then click OK in list window.
Here you go. Hope it helps you.
I have installed gvim in windows 7. When I right click on a file, I get list of editor to be opened with. I see a icon for notepad++, 7zip and beyond compare, but not for vim. it is tough to search "Edit with Vim" in the big list. Is it possible to add icon to "Edit with Vim". I tried setting ICON in registry to gvim.exe path, but that didn't work
I am currently having a crack at coding this up "for real" (but no success yet).
In the meantime, here's what I did on my machine as a sort of workaround:
Create a new text file and call it (for example) vim.reg
and paste this into the file:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\*\shell\Edit with Vim]
"Icon"="\"C:\\Program Files (x86)\\Vim\\vim74\\gvim.exe\""
[HKEY_CLASSES_ROOT\*\shell\Edit with Vim\command]
#="\"C:\\Program Files (x86)\\Vim\\vim74\\gvim.exe\" \"%1\""
and then right-click on the file and select Merge.
Or just manually add those keys directly in RegEdit if you're comfortable with that.
You may need to restart Explorer.exe (eg. log out and back in) for it to take effect.
This will add a new "Edit with vim" entry, with the icon, to the context menu for every filetype.
If you want it only for text files, for example, then change the two occurrences of "*" in the file to "txtfile".
The other vim context menu entries (eg. open with existing vim session) will not be affected - they will still not have icons.
UPDATE:
From the bug report that Christian mentioned, it looks like someone else has now implemented this, in version 7.4.724.
Vim.org reports that the currently release is 7.4.729, so it should include that.
The only trouble is that the Windows binaries available for download from the site are from 2013.
But vim.org also suggests a way to get the latest version, precompiled for Windows:
For the latest version with all patches included see Cream below.
These versions are unofficial, but the download number is high and
complaints are few.
And
For an unofficial version that does include all the latest patches and
optionally a bit more: Cream.
The "one-click installer" mentioned includes the Cream changes.
For the "real Vim" use the "without Cream" version listed further down.
As far as I know, this is not possible yet. There is a whishlist bug that requests this feature, but no one has contributed code yet.
Our team is using local workspaces. I know server workspaces provide better locking functionality, but the "check in lock" that is possible with local workspaces is sufficient for us. It's a bit of a hassle though, because for non-source files (typically, .rpt files) we have to:
Get the latest version of the file.
"Check Out For Edit".
Change the lock type to "Check in - Allow other users to check out but prevent them from checking in".
Is it possible to, at least, change the default lock type for certain file types (.rpts) so that #3 above is done automatically? Ideally, it would be nice if this applied to automatic check-outs as well, if VS is configured to check out automatically when editing/saving.
Now I know this is an old post and I'm not sure of the differences between VS2012 with TFS2012 and VS2015 with TFS2015, but I thought I'd share my solution, in case it help you or anyone else.
While there is not an option to completely automatically "Check-in lock" a file when you edit it that I can find, I did find that you could have it prompt for the check-in lock with that lock already selected.
MY SOLUTION:
You go Tools > Options then select the Source Control > Environment and under Editing select "Prompt for lock on checkout"
Now when ever you open a file and begin editing it, the moment you make a change it will pop up a window like this:
Note: that it has the lock type set to the check-in lock
automatically. If you had selected the "Prompt for check out" selected
in the options form, it would pop up the same for, but with the
"Unchanged" option selected.
One other important thing to note, is if you hit cancel in the Check
Out form, it will proceed to edit the file, but without checking it
out, which may be undesirable.
That covers your Points #2 and #3
As for point #1
Again, I don't know about VS2012 and TFS2012, but with 2015 you go to:Team Explorer > Settings > Source Contol (under the team project node)
You then check "Enable Get Latest on Check Out"
After both settings have been changed:
You can check out a file just by starting to edit it
The program will get the latest file when you check it out.
And it will show a prompt confirming the check-in lock before check out.
Again I'm aware that this answer is coming a little late, and it is done using 2015 software not 2012, but I hope it applies for you, and perhaps this post will help someone else.
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
This is the first time I've tried this in a VS, much less VS 2012, so if the answer is common knowledge, I guess I'm just not that common. (Yeap, Google failed me as well --- or my Google-fu just needs some oiling.)
I'm looking through my TFS code repo history, and from the list of changesets, I opt to view changeset details. Up on the VS 2012 right sidebar, I get a list of all changed files for this particular changeset.
However, I want to open up one of these files and modify them directly (basically for purposes of light code review and housekeeping), so I right-click on one, and select Open.
Unfortunately, this doesn't open up my local copy of the file, but instead (seemingly) downloads the file from the server and gives me the server copy, with a modified filename (suffixed with a short hash). I can't modify this at all.
Is there a way to open my local file copy from the changeset details?
What you could do is right click the file.
Then choose open in source control explorer.
Double click the file there.
Bob should be your uncle now.
If you right click and compare it to your workspace version, that will open a diff between the workspace version and the changeset version. I don't believe there is a way to open the local version of the changeset file directly, as that version doesn't really exist in your local workspace. What you are opening when you open it from the changeset is the specific version associated with that changeset. The file may not even exist in the current solution, so opening the workspace version in same cases wouldn't even be feasible (or you may have never gotten the file).
To the best of my knowledge there is no good way to do this (I wish there was). It's a bit time consuming, but you can get the same effect with a bit of manual effort:
Open the changeset, rollback changes, go to pending changes, and open all of the files. After the last file has opened, go back to pending changes and undo changes (i.e. your rollback). All of the files from that changeset should now be current and open in visual studio.