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.
Related
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!
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
We're finding ourselves unable to open our project in Visual Studio because SVN is adding lines like
"<<<<<<< .mine"
to our .csproj files.
This is apparently something SVN inserts when it has trouble merging files, but we're not interested in merging things as two people can never have the same file checked out.
How do we set Visual SVN to Replace instead of Merge?
Thanks for any help.
It's doing that because SVN tries to preserve whatever changes you've made to your local working copy. Thats a pretty important aspect to the SVN method of version control so I don't know, and doubt, if its possible to do that. I do know you can tell svn to ignore files, but their changes then won't be committed to the repository, nor updated from the repository.
If its a problem, delete the csproj file, then when you update it will redownload the proper version. Do that whenever theres a problem. If it happens quite a bit, then one of the developers is messing with the file.
Past projects I've worked on had a dozen engineers working on the same projects, and we never had constant merge problems with the .csproj files.
What do you mean by "two people can never have the same file checked out"? I think you are misunderstanding how Subversion works - checkout is not an exclusive lock on a file.
Visual SVN uses Tortoise on the backend I believe. when you are in a conflicted situation (i.e. SVN cannot merge the two versions cleanly) you should have the option you should get a pop up where you have the option to either "Use Local" or "Use Repository". If you choose "Resolve Later" you'll get what you are describing.
I'm using VisualSVN with my Visual Studio 2008 and I have to run some sort of commit monitor in the tray area to see if the local copy of project is out of date.
I have two problems with that:
I hate to have it in two places, I want to see that as an icon in my VS,
The commit monitor software keeps an eye on several projects, when I work on project 1 (which VS knows about), I'm not interested in other projects.
I couldn't find any addons for Visual Studio to do that and was wondering if anyone knows about anything good.
Generally, you have 2 options (besides running commitmonitor as you already do):
run update before you start to change something
ignore it all and merge with any updates when you want to commit.
SVN's really designed around the 'wait until you're ready and merge it all together' model, as there's no guarantee that even if you update your working copy immediately before starting to modify it, someone won't commit changes before you've had a chance to commit. So, let the system do the work for you.
The ultimate alternative if you are worried about conflicts is to use the svn:needs-lock property which means you will have to get a lock on any file you modify before modifying it, and you won't be able to get a lock on a file someone else is modifying.
You might like to ask the VisualSVN people if they'd add an option to check the repository when a project is loaded by VS (or run AnkhSVN and implement this feature yourself).
Work has started in AnkhSVN in this direction, we started to implement the 'Synchronize View' that's also used in Eclipse/Subclipse. The things still missing are: Scheduled checking of the repository, and maybe a notification inside VS to tell you that something has changed.
Right now you can manually refresh this view to see local and remote changes (and merges which can be potential conflicts). Patches are welcome to extend this feature :-)
I'm assuming VisualSVN is your "server" (even if running on the same machine).
AnkhSVN is a good Visual Studio Integrated SVN Client.
I'm using Visual Studio 6.0 and Visual Basic 6.0.
I have them integrated but when I check out a Project and then try to edit a module in that project it's locked and I have to manually right-click on it and do a Check Out to unlock it.
I thought there was a way to have VSS automatically check out the file for editing.
Any suggestions?
I agree with kris here. Now I know that a bunch of folks saying your "software stinks" doesn't really answer your question. But there is a world of difference between a check out style source control and a file locking system like Source safe. The general consensus is that Check out systems are far superior.
With check out, what you do is you check out the project from your repository. All the files are editable. You work on your project as normally. Then before you checkin you do another update. If anybody else in your team did a update the software will automatically merge in the changes into your code. You will have a chance to review the merges and resolve any conflicts. After the update you can then check in your changes which everyone else can retrieve.
The big scary part is the merging part. Back when CVS and subversion where just command line tools it was a little scary as it was a pain to retrieve what happened with the merging. But with today's tools like Tortoise is all visual. In the last couple of years I can't think of any instance where a automatic merge failed. Any conflicts (basically two people edit the same line of code) are display right here for you to resolve.
Subversion
Tortoise SVN
There is an option in SourceSafe under the "Local Files" tab labeled "Use read-only flag for files that are not checked out". By default this option is selected, but if you unselect it, you will be able to edit any file in the project without checking it out.
Once you uncheck the option, you can get the latest version of a project to remove the read-only flag from all the files.
When you check out a file, you will be warned that there is a writable copy of the file in your working folder, at which time you can replace it with the version in the SourceSafe database.
I never figured out a way to do this. It was always a huge pain. Sorry for posting a negative answer, but I figured that you might want to know that you aren't alone in hating this, but that there wasn't an immediate and obvious answer. I'll be following this question along with you in case someone out there does know of a solution...
I don't think it is possible to do this (at least it wasn't when we used VSS eight years ago), but while you are experiencing the pain of a check out styled source control, run - don't walk, to some real, non-locking style source control solution. SVN, CVS, Git, Mecruial, anything that doesn't lock files, and doesn't leave your source in a proprietary file sytem. We switched to CVS eight years ago because we lost all of our source history (the code was checkout out so it was retrievable), due to a VSS glitch. Best thing we ever did, made collaboration ten times easier. Now CVS isn't the best solution (it was the most reasonable solution for windows back then), but anything is better than VSS.
Best solution I found was to check out all the files. Took a bit of poking around to figure out how to do that. Here's how:
How to check out all VB6 Project files from VSS?
when I check out a Project and then
try to edit a module in that project
it's locked and I have to manually
right-click on it and do a Check Out
to unlock it
Like it or not, it works that way by design i.e. you can check out all the files but you have to explicitly choose to do so, rather than being the default option. I guess that's because checking out all modules (class modules, forms, usercontrols, etc) locks out all other users from the entire project, which is normally undesirable in a team collaboration environment.