enter image description hereHoping to find someone well versed in SVN to assist with a problem that has baffled both me and a colleague well experienced in SVN.
I recently was merging in new content to Trunk. I saw in the dialog box the files I'd edited all scroll down the screen as normal, and then received the 'Merge successful' message.
However, when I looked in Trunk none of the changes were present. In repo browser where you typically can see the author username of the most recent changes as well as the time stamp, it showed a previous merge not made by me.
Baffled, my colleague came to observe the whole process and confirmed that he was seeing the same thing: the merge appearing to succeed, but none of the updates persisting.
Has anyone seen this before, and could anyone offer any advice? I've spent a few hours googling at this point and am exhausting likely culprits.
You won't see merged changes in the repo browser until you commit those changes:
A merge only changes the files in your working copy, not directly in the repository.
Which means you have to first commit your changes.
Related
This is a question that I posted, and then after much digging finally resolved myself. There is actually quite a bit on this subject both on this forum and elsewhere, but it usually requires some familiarity with Terminal. I am going to describe the problem I faced and then describe step-by-step in detail (at a beginner's level) how to resolve the issue in Terminal.
In short, I checked out a previously committed version of my app in Xcode, which - because it was a version from several weeks prior - did not contain my most recent commits. In other words, I had no access to any of the commits that contained my most recent work. They had all disappeared.
My commits and pushes had not stored in GitHub because presumably some time before this I had accidentally selected my main folder as the destination for my commits, rather than one of the two branches I created. So I had absolutely no access to my work. By all appearances I pretty much had to start from scratch.
After much hand wringing, teeth gnashing, and hours of scouring the webs, I finally uncovered the solution. But it takes a bit of understanding about Terminal to make it work. So after several more hours of learning Terminal, I finally successfully restored all of my work.
For any of you who are new to coding (as I am), and who have no experience with Terminal, I will provide detailed instructions on how to resolve this issue if you encounter it in the answer below.
Open Terminal to prompt to your Xcode project. The easiest way to do this is to find your project in Finder, which will have a .xcodeproj extension, and then right click it.
Select New Terminal at Folder.
At this point, a terminal window will pop up. From here, enter the following: git reflog
Press Enter
This will populate a list of all the commits stored in your Xcode project. Each commit is identified by an alphanumeric code (the one I restored was 1a7ea33, for example).
Note the alphanumeric code of the commit you wish to restore.
After this, enter the following: git checkout -b NewBranch 1a1a1a1 (where "NewBranch" is whatever name you decide to name your new branch, and "1a1a1a1" is your alphanumeric code from steps 5 and 6).
Press Enter.
That's it. Close Terminal and open your Xcode project as normal. You will notice the restored commit in the folder you just named in Terminal.
Hopefully no one will ever need this, but if by chance someone does I hope it helps.
This might be a bug but I've never seen a bug in Git before, and I can't find any mention of this issue on the intertubes, so for now I'll assume user stupidity.
I use Git a great deal so I've set up an alias to bring up a birds-eye view of the git log: alias gl='git log --pretty=oneline --abbrev-commit'. So when I'm juggling between different branches, I'll frequently type gl to pull up the log, then q to exit. I find this super convenient.
But today I've noticed something strange: it looks like the most recent two commits are excluded from this view. Here's sample output from gl for one of my active projects:
b6e802d Location autocomplete; major refactoring and cleanup
d0cecdf Admin can download CSV of all users
0149ea2 Changed some verbiage on terms, privacy and profile page
5c0bdff Changed the link for find coach to go to the coaches page
But if I output gl to a file like gl > gitlog.txt, the first few lines are:
5e57f97 City autocomplete supported in mobile navbar search
df43a02 Add firstname & lastname to admin's users CSV download
b6e802d Location autocomplete; major refactoring and cleanup
d0cecdf Admin can download CSV of all users
0149ea2 Changed some verbiage on terms, privacy and profile page
5c0bdff Changed the link for find coach to go to the coaches page
Note that the top 2 lines in the latter are not present in the former.
If I open up the normal git log, all commits are visible as expected.
EDIT: I just discovered that I can work around this for now by piping (redundantly, I think) to less: gl | less shows all commits as expected.
I never noticed this happening before now (ie. the past couple weeks); I've recently updated to a newer Git version, could that be related? Has anyone else seen this happen? What should I do to figure out what's going on here? I don't even know where to start. Does this look like a bug?
Numbers:
Mac OSX 10.9.5
Git 2.2.1
Are any other numbers relevant?
Thanks for reading!
This isn't a complete answer, but I just made a couple observations:
This is only happening with one particular repository. The git log works fine on other projects.
I've added several more commits in the last day or two, and all of those commits are excluded. So it's not that the latest 2 commits are hidden so much as that every commit after a certain one are being excluded.
The earliest commit being hidden begins with the following line:
Add firstname & lastname to admin's users CSV download
Given the behavior of the error, I think there's a bug with Git's log printout that causes some commits to be hidden if a commit message contains &. So the lesson for me, for now, is to not use & in Git commit messages.
Just reproduced this behaviour happening with an old git version (2.6.x), but I updated it (2.19.1) and it was then fixed.
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
Actually I have faced this issue many time during working with SVN. Most of the time I am working with VSS for source control but since last couple of months working with SVN.
We are using tortoise and AnkhSVN with VS 2010.
In our team there are 5-6 people and some of them are working on same file at a time. Now when somebody commit , we have seen that some other developer changes get vanished and Sometime we get some line with version number. This thing get consume lots of time and we have to resolve conflict and all.
Please provide information so we can avoid such issues.
If two developers are working on the same file and make changes to the same are of code, then you have to manually resolve this conflict. There is no way to avoid it, no matter which version control you use.
The version control cannot know what the correct code is, so it requires a human intervention.
There is no way around this, other than preventing the users from working on the same code. this is done in svn by locking the file.
Each developer must svn update before svn commit. Between the update and commit, the developer must do a full, clean build and run all tests to make sure their code still works after merging in all other developer's changes into their copy.
You can set svn:needs-lock on files or folders that need to be locked before making changes, they'll be forced to check for locks. When you will try to edit a file, you will be required to lock it first. And when it is already locked by someone else, they you get an error message, preventing you from making any changes. This can be done in Tortoise SVN in Properties -> Advanced
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.