Visual Studio 2010.
A few weeks ago we branched our project, and yesterday we merged them. It all went well, and the newly merged project appears to have captured correctly the differential changes.
However, when I check an object out for edit, and then go to check it back in, I get a very long list of objects in the Check In dialog.
The newly checked out object is marked as lock,edit in the Change column.
However, every other object in the project ALSO appears in the list marked as merge, lock
I can't find out what this means, and I don't want to check them in, in case the previous merge operation is changed or undone.
I decided to bite the bullet and check in the outstanding pending changes, having reviewed the difference between a selection of the pending changes and the known good versions, and finding no difference. It all seemst to have gone through correctly so I'll mark this down to experience.
Related
We're using Visual Studio 2015.
I have three branches, 'DEV' where new code is made, 'MAIN', where tested good code goes as the primary repository, and 'PRE' where edits are made to previously released code. (PRE changes can be merged into DEV easily since we should never be working on the same file in two places)
That said, I merged good code from PRE to MAIN with no issues. I checked in those changes. When I merged that code from MAIN to DEV, there was conflict in the .sln file, but this is nothing new. Some new projects exist in DEV that don't yet exist in MAIN or PRE, so there's always some shuffling. I used the merge tool and attempted to resolve the conflict.
I completed the merge, and checked in the changeset. Only after check in do I realize there was a problem in the merge of the .sln file and I cannot build the solution because the paths for the files got crossed/corrupted somehow.
The error I receive is 'Metadata file \path\folders\buildlocation\solution.dll could not be found'. This error is repeated for every project. EDIT: I solved the problem with the build. It was not a .sln problem, but an error in the shared library.
===========================
That said, I believe the question below is still valid, if someone should ever need it.
So here's the question: I know I can do a rollback on DEV to get back to the previous state, but this creates 'new' changes which need to be checked in, which will overwrite the previous change. However, once that's done, I will still need to attempt to re-merge the good changes from MAIN back into DEV. Since that changeset is already merged, it is no longer available as a merge candidate.
How can I A) Rollback checked in changes from a merge in DEV and then B) Re-merge those changes into DEV and attempt to do it correctly?
A couple of people have asked a similar question, the last one a year ago, with no solution (Here and here), so I thought I'd try it again.
I've created snapshots in Xcode 5.1 on a few occasions before making significant code changes. When I go to restore them, I've seen a couple of different behaviors:
There's one file that changed. Xcode shows me the before and after diffs, and I say OK, and click on Restore. The result, nothing's changed.
Same as one, except in this case there are multiple files that have changed. It shows me one, and it looks good. So I click Restore. It doesn't show me any of the other files diffs that have changed, and it doesn't prompt me to be sure I don't want to look at them. After the fact, I've surmised that I need to click on each changed files in order to accept the changes. But still, there's only one Restore button, which dismissed the window. In any case, none of the files have been restored to their former state. If I try to restore from that same snapshot again (naively thinking I could try to retrieve the other changed files), it tells me that the current state and the snapshot are the same.
If I export the changes to another directory, then I do get the reverted files. It's when I do a File->Restore Snapshot where I get no results.
I've taken to manually creating zip archives of the source so I can recover the files manually.
I don't have any Source Control in use in Xcode so far. It seems I should do that if only to do periodic commits on my own.
Do other people use snapshots successfully? Has anyone else experienced this behavior in Xcode 5?
Thanks much for your help. I've yet to get any response on the Apple Developers Forum on the topic :(
-Eric
I have done some work on a VS 2010 project which is under TFS. I have created a shleveset and want to unshelve the shelveset on another system. But I am getting following error:
---------------------------
Microsoft Visual Studio
---------------------------
Multiple errors occurred during the operation, the first of which is displayed below. A full error list is available in the Output Window.
TF203015: The item $/ConsumerCredit/project1/project1.Database/project1.Database.dbproj has an incompatible pending change.
---------------------------
OK
How can I fix it
Some guesses:
Look at your list of pending changes. You may already have opened this file for delete or rename or something like that. You can't get the file out of the shelveset because you opened it in the shelveset for something different such as for 'edit'.
You'll probably have to undo your pending change on this file and then get the shelveset.
Or possibly you locked the file when you checked it out on one system, so you can't start editing on the other system (getting it out of the shelveset would adding to your pending files for edit). You could undo the checkout of the file on your first system.
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 dillegently 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 woking 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 withoout issue, then immediatley went to merge the next changeset; and bang TF203015, and its very unhelpfull test in teh output window; incompatible pending changes.
After a little fiddling around we now realise 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 perfoming 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.
Question: Today I worked with MS Visual Sourcesafe, that is to say Microsoft's Sourcecode destruction system, which has never ever saved anything, but already destroyed much.
Today I had one more of those nasty destructive episodes:
I was working on a reporting service report (*.rdl xml files).
I was modifiying a report, so I created a copy and modified it.
The original being named FILENAME.rdl
My modified copy being named FILENAME2.rdl
I finished, saved. Checked in.
It was all correct.
I switched offline, continued to work.
Later on, I deleted filename.rdl, and renamed filename2.rdl to filename.rdl
I continued working for the rest of the day offline.
In the evening I checked in, and filename2.rdl reappeared.
I thought it had copied the old version back, so I deleted filename.rdl (from local computer and sourcesafe, via the delete keyboard button in the visual studio treeview) and wanted to rename filename2.rdl again to filename.rdl.
When I tried, I realized that filename2.rdl was just an entry that appeared in the treevieww, but not on disk... It was in that very momement that I realized that I now have a problem...
I looked in the recycle bin, but nothing there.
I tried 5 different undelete programms, and shadow copy explorer [to find out that non C drive data - such as the data partition e - is not backed up by the shadow copy service automatically...], but no luck. The file is gone.
Is it possible to still retrieve the file from sourcesafe, or does it get permanently removed when one presses the delete button in VisualStudio treeview and clicks OK on deleting it from file & sourcesafe ?
So far I found this one:
http://support.microsoft.com/?scid=kb;en-us;244019&x=11&y=7
but from that it is unclear whether the file is gone.
The problem is if it isn't there, I should redo the about one hour work this evening, because tomorrow will be a busy day.
There are 2 levels of Delete in SourceSafe. When you delete the file, if you check the "Destroy permanently" option, the file will not be recoverable. Otherwise, you can go to the Properties of its parent project and recover it later.
If it's not stored under some different version or branch of your code, I think you're out of luck.
Regardless, however: you estimate this is one hour's worth of work. You already (presumably) spend some amount of time (probably an hour or two) trying to get the file back. Are you not now at the point where, even if VSS has a way to get your file back for you, you'd be better served just rebuilding it?
Short answer - definitely NO!
It can't! I tried.
But it overwrote the recreated report with a completely wrong recovered version...
Fortunately, I've forseen this, and made a backup copy of the recreated report for this case.
So I didn't spend that one hour of recreating the report in vain.
This program should be forbidden, with noncompliance to this prohibition being subject to the death penalty.
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.