There isn't much more frustrating that dealing with SVN when it won't commit. Here's the error message that I'm getting:
I've done everything I can think of and torn out what little hair I have left. I've read the other suggestions that were posted on Stackoverflow. This problem started when I allowed Visual Studio 2010 to rename a namespace. I know I got everything back to where it was but SVN isn't convinced.
Here is the SVN Status (better screen shot):
You made some operation in Visual Studio that resultsd in renaming or moving some file to ../CourierReportingEnemy.Designer.cs (check the error message). Commit of such change must include 2 operations: remove (removing original file) and add (re-adding it in new place or with new name) with a link between the two operations. However, the REMOVE part of this change is not included with your commit by some reason.
Try committing from the root of the Subversion working copy (e.g. your solution's root) and make sure that the commit includes all the necessary changes.
Update:
It looks like that there is a problem. The move source Messenger.cs* files are non-versioned now. However they should be marked as deleted. There is a chance that AnkhSVN had troubles to translate Visual Studio's operation to Subversion, but I'm not sure.
I'd suggest to start from scratch and re-do your namespace rename. However, there is a chance that Repair moves/renames feature of TortoiseSVN will help.
Related
We use VisualStudio with SVN and VisualSVN.
I restructured the solution by moving (cut and paste/drag and drop) and renaming a lot of files.
Never heard a complaint from VisualSVN, now it is time to commit it refuses to do so:
Commit failed (details follow):
Error: Cannot commit 'C:\Sources\xxx' 'xx\Model\Model.cs' because it was moved to
'xxx\NewModel.cs' which is not part of the commit; both sides of the move must be committed together
That is correct neither file exists any longer at the given positions, and frankly I don't care.
I need SVN to store the solution as it is now. It is OK that I will not be able to trace change history for moved and/or copied files.
Is there a way to force the commit?
It seems that you get the error because you commit only the part of the move action. Moves in Subversion consist of svn copy (to the new item location) followed by svn delete (of the original item), so both sides of the move must be committed in one revision together.
I suggest following these steps:
Visual Studio | VisualSVN | Commit....
Make sure that both sides of the move you've performed are listed in "Changes made" list view and try to commit. Do you still get the same error?
If the first step fails, go to Visual Studio | VisualSVN | Windows | Pending Changes. Right-click the root node of your solution / working copy and choose Commit.... Still getting the error?
Go to Visual Studio | VisualSVN | Set Working Copy Root... and make sure that the working copy root points to the root of your solution's WC. Attempt to commit after this step.
I ran into this exact problem over the past week while refactoring some code and renaming numerous files. I was able to correct the problem as follows:
I committed my project folders one at a time (at the folder level) to isolate the problem. In my case, all but two folders committed without errors.
In the problematic folders, I committed the files individually. I now had a green dot next to every file, but the two folders were still yellow.
I tried to commit the folder again. It gave me the same error, but now it just showed the files it was having an issue with in the dialog box.
The files that were giving me a problem were files that had been deleted and not on my drive. I right clicked on each file and reverted it. This put the file back on my drive, even though it wasn't part of my project in VS.
Lastly, I added the file back to the project in VS and then immediately deleted it and committed the project. Everything appears to be fixed now.
TL;DR -- If SVN thinks a file is part of your project, but the file is missing from you HDD, it will give you this error. Simply revert the file to get it back on your drive. To clean it up, add the file back into your project and then delete it within VS to get everything in sync.
Please click refresh button first, after refresh in commit package Visual Studio will be included delete and rename rules, needed for SVN
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've got a file managed by Visual Sourcesafe 2005 which I have edited. I'd like to check in the file exactly as-is on my box, but VSS always merges it with the file in the repository, breaking my code.
I don't know what I expected to happen...
Is there any way to check the file in without merge shy of deleting the existing file from the repo and adding my copy back in?
I've looked for command line options to no avail.
You could just do "Undo check out" for all files, keeping their local versions on your machine; then again check out this files without getting latest versions from Visual SourceSafe; then check in all of them. In this case history is preserved. You just overwrite latest versions of files without any merge. Seems for me it's what you wanted.
I had the same problem and sorted it out in that way.
I'm putting this answer here, but still really hoping that a better one comes up.
I figured that I can go into the VSS GUI and rename the file to ".old", then add my local file into the repo. It's extremely hacky, but allows me to keep the file history.
Such issue might happen when the file was checked out by multple people and there was a newer version checked in by others after your checkout. (See Four scenarios that merge may be performed #2 of the article for more details.)
I don't see a option in SourceSafe CheckIn command to control that either. If you don't want merge happen, you may exclusively check out the file before editing.
I'm using Visual Studio 2010 Pro against Team Server 2010 and I had my project opened (apparently) as a solution from the repo, but I should've opened it as "web site". I found this out during compile, so I went to shelve my new changes and deleted the project from my local disk, then opened the project again from source (this time as web site) and now I can't unshelve my files.
Is there any way to work around this? Did I blow something up? Do I need to do maintenance at the server?
I found this question on SO #2332685 but I don't know what cache files he's talking about (I'm on XP :\ )
EDIT: Found this link after posting the question, sorry for the delay in researching, still didn't fix my problem
Of course I can't find an error code for TF203015 anywhere, so no resolution either (hence my inclusion of the number in the title, yeah?)
EDIT:
I should probably mention that these files were never checked in in the first place. Does that matter? Can you shelve an unchecked item? Is that what I did wrong?
EDIT:
WHAP - FOUND IT!!! Use "Undo" on the items that don't exist because they show up in pending changes as checkins.
I had deleted the files in trying to reload the workspace, even though I had shelved the changes. Then VS2010 thought those files were still pending to save. I didn't need that, so I had to figure out to "undo" the changes in Pending Changes.
Then I could unshelve.
It thought I had two ops (unshelve, commit-for-add) going simultaneously, and I thought I had only one op (unshelve).
This is a slight aside to the OP's question
You can get a TF203015 when you try and batch merge a multiple changesets from one branch to the other without due care.
Consider a situation where you have a MAIN trunk and a DEV branch. You branched DEV from MAIN and have diligently worked away at a feature in DEV; checking work back into DEV as you progressed. Now fast forward a week or two. You are now feature complete and want to merge back into MAIN.
This is where one of our devs hit this error.
He had been working on one solution for weeks, and checking changesets back into DEV periodically, so wanted to merge a non contiguous series of changesets back into MAIN.
So he picks the merge option, selects the first changeset; merges without issue, then immediately went to merge the next changeset; and bang TF203015, and its very unhelpful test in the output window; incompatible pending changes.
After a little fiddling around we now realize what is going on here; the first merge created a pending change in MAIN for the developers solution. The next merge attempt was also changes to the same solution, which would require TFS to "queue up" a second set of pending changes to the same files. It cant do this.
So in this scenario TF203015 means; "The destination branch already has pending changes on some files that are changed in this changeset. Please resolve and commit the destination branch changes before performing this merge operation"
The solution; after each merge operation our developer tests the workspace for MAIN and commits the pending change caused by the merge, then goes back to DEV and repeats.
Actually sensible and simple, but masked by a very obtuse error message.
You can use the Team Foundation Server Power Tools March 2011 (http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx) that includes the command tfpt unshelve.
Once the Power Tools are installed, open a Visual Studio command prompt, change to the directory that contains the project of interest, and execute the tfpt unshelve command. It will unshelve and display the merge dialog so you can resolve the conflicts.
I credit this blog post with helping me find this solution: http://fluentbytes.com/the-how-and-why-behind-tf203015-file-has-an-incompatible-change-while-unshelving-a-shelve-set
I had what appeared to be the same issue but I had created a branch after shelving my changes and I wanted to unshelve those changes to the new branch.
TFS cannot unshelve to a different path than the path upon which the shelf was created.
Solution: I unshelved back to the original branch then I used beyond compare to merge the changes from my original branch to the new branch and checked in.
It could also be that after you create a folder in say a "Test" and you want to merge from dev to test, that you do not have that newly created folder structure checked into TFS - You will /can also get this error message.
Thus this message error CAN occur without anything to do with SHELVESETS as well for others coming from google and finding this page.
This might be the same as jcolebrand's answer, but I'm afraid I found the phrasing there a bit abstruse. Sincere apologies if I'm just repeating.
In my scenario the incompatible pending change message was presented because I was trying to roll back multiple changesets, and the same file was affected by more than one of those changeset.
In my case I did not want to commit until all the changes had been rolled back. I believe if I had been able to commit after rolling back each changeset, the error would not have happened.
The method which worked for me was as follows:
I opted to roll back one changeset at a time. I found using the command line was actually a more informative way of doing this because it lists all the conflicts, whereas I think the VS UI rollback just lists the first.
While rolling back a changeset, if there was an incompatible pending change, I had to undo my workspace's pending changes for the affected files.
When all the changesets had been rolled back, I had to manually revert the files which had experienced incompatible pending change. Mostly this could be achieved simply by getting a specific version of the file (the "last-known-good" version before all the bad checkins started). But for some files where there had been both desired changes and undesired changes, I got the "last-known-good" and manually applied the good changes to it.
This link resolved my issue:
https://blogs.infosupport.com/the-how-and-why-behind-tf203015-lt-file-gt-has-an-incompatible-change-while-unshelving-a-shelve-set/
The reason was pending change in the same work space create an incompatible change. So undo the pending changes and try unshelve. This should resolve the issue.
If you have two branches MAIN(target) and DEV(source), now you want merge DEV into MAIN, then all files you want merge from your source, must not be older then the similar files in your target branch.
For example: you have an changed file test.cs in your DEV branch, changed at 14.03.2016. In your MAIN branch you have test.cs changed at 15.03.2016. So the target is newer then the source file and you have TF203015.
Solution: navigate in TFS Explorer to the conflict-file and merge it explicit. TFS will open the conflict manager and you can merge the conflicts by hand. Following you can merge the selected changeset.
Remarks: If you have more conflicts, you must navigate to each conflict-file and merge it explicit, so TFS opens the the conflict Manager and you can merge it by hand.
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.