When one makes a few changes to the code in Visual Studio, then undoes some of them (Ctrl+Z) and then saves the code (Ctrl+S) the whole change history from that point onward (all undone changes) are lost - one can't redo these changes (Ctrl+Y). The history from that point backward is kept by VS but the forward part of it is for an unknown reason dropped.
Any way to keep the whole history?
Use Source control (or local source control on your desktop if that's not feasible), and you can roll backwards or forwards tons of changes, check in more often.
With Git for example I can check in every few minutes and be able to roll back or forward individual lines or commits.
They are using VSS here, so I'm using git for local undo/redo extensions. Source control is the best way to handle more lengthy change histories like you are referring to.
You cannot do anything to make the editor(which maintains the history) save every step you did when you undo some changes and save it. So the answer is NO. I don't know about visual studio 2012 editor though because I haven't used it.
Maybe this extension will help.
http://visualstudiogallery.msdn.microsoft.com/226c2108-9da9-407d-b90d-9783040d27b8
Related
In source control systems and tools like tortoises for svn or sourcetree for git, when I am committing a merge, I can usually just left a default comment generated by the tool that is basically a summary of what changes were merged. In visual studio using TFS, there is a comment textbox right above the changes list, but I have to type it all manually. It's not super important but it is a time saver sometimes. Maybe i'm just not looking at the right place.
If you're using TFS with Git, then this becomes less of an issue. When you merge all the individual commits come along for the ride, so it's not necessary to re-describe them in the merge commit.
Try extension Auto Merge
If you need set original comment setup Settings "comment_format" like {{OriginalComment}}
I have used TFS a lot, and unfortunately I don't think that option exists. I usually copy my original checkin text and then paste it if I am doing multiple merges. I realize this is a low tech way to do it and the original comment isn't generated for me. If you want to be able to do this bad enough, you can probably write a Visual Studio plug in that would do it for you, or you could code up just about anything you want to add with the Team Foundation Server SDK.
I work in Visual Studio on C# project.
I edit some files it that project simultaneously. After some work is done i want to divide all changes to "groups" of changes and commit each group changes to separate commit. Its okay when it comes to files - i include one files, exclude others and all is fine.
But problem appears when some changes are in the single common text file. I'd like to split them to different check-ins by TFS itslf, but as far as i know it is not possible.
So tell me please, is there any way to split changes to distinguish them due development process? For example when i start editing common file i press something button or issue a command. Later, when i have to add changes regarding to another check-in to that file, before these changes are really done, i press another button (another command) and since this moment changes are recording as needed to be commited to another check-in.
I hope you understand what i mean. Sorry for my bad English.
If you are going to make a quick change to a file that has work in progress, you should shelve the changes and revert to the source control version (uncheck the "preserve pending changes" box). Then you can make the changes and check in the file. After that, unshelve your changes (your work in progress) from earlier, VS will merge the changes with your checking and you can carry on.
Since it sounds like you have already made the changes and the file contains code you are ready to check in and code you don't, one thing you can do is to shelve the changes now (but do "preserve pending changes"). Then you can delete any code that aren't ready and check in the file. After check in, you can unshelve your changes.
You might want to consider using branches to isolate your long-running changes; although that has its own set of problems.
You could create another workspace on your computer, and use each workspace for a different task. That way, you can work simultaneously on different tasks on the same file without affecting each-other. When you check-in from one workspace, do a "get latest" on the other workspace and merge the changes there before you check-in the other work.
Recently switched jobs and with it switched source control from TFS to SVN, which is new to me.
In TFS there was an option to disable automatic checkout of files when you started typing in them. It's enabled by default and a lot of users like this behaviour, but I prefer to know for certain what's being changed before committing. A personal thing.
VisualSVN auto-checkouts by default. Is there an similar option to turn it off? I can't seem to find out in the settings.
"Automatic checkout" term in SVN and in TFS worlds has different meanings, as far as I see.
In Subversion, checkout relates to svn checkout operation which gets a working copy from a repository. In TFS it looks like the term somehow relates to automatic locking mechanism.
If you want a file to be locked automatically when you start modifying it in Visual Studio (with VisualSVN extension installed), see the KB article "Lock-Modify-Unlock Model with VisualSVN". I also suggest reading the SVNBook chapter "Locking".
Generally speaking, you can set svn:needs-lock property on files. The property instructs client which files must be locked before editing. After applying svn:need-lock to a file the file gets read-only attribute. Before editing the file must be explicitly locked by the user. After committing the lock is released by default.
Short answer: I don;t think you can do this without becoming very unpopular.
I think you should read up on the SVN redbook's description of how SVN works, especially the versioning models
In your environment, everyone wants to be able to modify any file locally and then send their changes to the server, merging changes with colleague's changes if necessary. This approach works well if 2 people are not changing the same files all the time, which is typical of most dev shops.
The old TFS/VSS model of checkout a file to work on it is pretty obsolete today - the more 'optimistic' approach where you assume you have exclusive access is much more productive. (as usual its easier to ask forgiveness if it goes wrong than ask permission every time)
Your main problem is that you cannot mix these models - if your colleagues are using the merge model, then you have to as well. You cannot lock a file and expect them to still be able to change any file anytime.
Now, there are tricks you can use to prevent yourself from modifying files you never meant to - I'm not sure of VisualSVN but TortoiseSVN (awesome tool) can run client hooks - ie you can write a program to run on every checkout, and that program can be as simple as setting every file's read-only flag. Whether this is god enough for you is another matter.
Personally, I would get used to the idea of change whatever you like whenever. If you accidentally edit a file, you can see the change indicator (AnkhSVN turns the file icon orange for changed files), and its easy to 'svn revert' changes you didn't want to make. Also SVN lets you see diffs really easily, especially on commit - double click the files in the commit dialog. The productivity gains from being able to work without the tools getting in your way (as I found with TFS continually pinging at me as I tried to edit a file) are huge. The SVN tools are really good to let you "ask forgiveness" so you don't need to run in the crappy old TFS way now you've upgraded to something better.
The other advantage is that this applies to files that are not in a Visual Studio project, if you've ever had a project file that was edited outside VS (eg a generated WCF client stub) then you will appreciate how SVN works - never again will you do a full commit and find that TFS has conveniently decided that your changed file wasn't changed and so didn't need to be committed!
I pressed Alt-E which I mistakenly thought was Merge Changes In Merge Tool, however, that was actually Keep Local Version. Is there a way to go back? Is there a way to find out what was merged, as in what file? Ugh! :(
I have completely stopped working in case I erase something of importance.
I'm using MSVS 2013 Professional.
Here's another possible approach.
If you know what version of the code you started with before you started making your current batch of changes, you can grab a copy of your local workspace files. Then Undo all your Pending Changes. Then delete all the files in your local workspace (in Windows explorer). Then do a Get Specific Version to get back the old version of the files from where you started, then copy-paste in your updated files from your backup copy. Then do a Get Latest. This should retrigger the Merge process.
I don't know a great answer to this problem, but I do know one thing you can do (I hope you don't have a massive amount of pending changes, or this will get tedious).
The problem is that TFS thinks you have now merged the server changes (other devs changes) into your workspace, even though you told it to basically toss them. If you try to check-in now it will blow away other developers changes in TFS.
What you can do is go through each file in your pending changes window, and do a Compare With Latest Version. This will show you the differences between your local file, and the file in TFS. You will notice two types of differences:
the changes you made which you can just skip past.
Changes that other devs made and are on the server, these differences will show up as though you have deleted/undone that code locally
For the changes that other devs made, you will have to manually reapply them in your local workspace before you check-in.
I want to use a versioning system to back up and track my changes but I'm too lazy to check out/check in, merge, commit, etc. I don't want to branch, fork or anything else. I just want to be able to see what files have changes and what my Main() looked like last week.
So I'm looking for an application that will simply take my Visual Studio projects folder and back it up in such a way that all prior versions of the files are preserved so I can not only have a backup, but I can easily see how the file looked at some point in the past without me having to explicitly put it in a repository, update/commit/merge/etc.
Basically what I'm looking for is dropbox's functionality but on my local machine and without the 30 day limitation of prior versions.
Does such an application exist?
As AlexC stated, I highly doubt that the little bit of work you save by not using a version control system explicitly is worth the drawbacks, but anyway:
Simplest idea: Just write a wrapper script that checks out the HEAD of your repository, starts Visual Studio and commits everything to version control after you close it.
Alternatively, just trigger commits every hour. With most VCSes, non-modified files won't show up in the listing of modified files.