I have an iOS project under Subversion source control and I am using Cornerstone as my SVN client. (I have also tried using XCode for this as well)
I've had numerous problems merging branches, and hope someone can help!
In the simplest test I have done, I have:
Created a new branch from the trunk
Made one small text change in one file in the new branch
Immediately attempted to merge the change back into the trunk from the branch.
When Cornerstone analyses the merge contents, it reports lots of tree conflicts and newly added files.
Other (potentially) relevant info:
I am the only person working on the project at present, so there are no other changes being made.
I have tried merging from branch-branch, trunk-branch, branch-trunk all with the same result
The server is using SVN v1.4.2, my client is v1.6.17. I am suspecting that this may be the cause, but am looking to get this confirmed if possible.
Thanks!
It appears that the problem is due to the server being v1.4.2.
I deleted my existing working copy and checked out a fresh copy, ensuring that the SVN version was set in the check-out dialog box to 1.4.
Now, when I attempt a merge, I only get the options to "Cherry Pick Changes" or "Advanced Merge". The "Synchronise a branch" or "Reintegrate a branch" options no longer appear, so these must be options not supported on 1.4.2 and be the cause of the conflict explosion I was seeing.
In summary, to merge between my branches it appears that I have to select the specific revisions that I wish to merge.
Related
I have shelved my changes in TFS which will be checked in few days time. Now i want to work on different TFS card which belongs to same file. How can i work on the same file when its changes are not checked in yet ?
How can i work on the same file when its changes are not checked in yet ?
You should use Branch. You can create a new branch based on file are not checked in, then you work on different TFS card with previous branch, after that, you can check out the new branch to work on the same file when its changes are not checked in.
Shelvesets are per-user and differently stored in the source control - it is not possible to merge shelvesets, there's no history etc. The only action possible is unshelving; you cannot even merge files while doing so. So, we only use it as a temporary storage for things that are not finished yet and thus cannot be checked into a branch.
So, you should use branches. Maybe a Main branch and different development branches for features & bug fix.
Hope this helps.
I am working on a Swift based XCode project that is synced with Git based master repository. One of my team member has added few files, to the master which I have pulled.
I find those files in my project directory, but not in my project. When I am manually trying to add these files to the project, in that case, I am getting Modify tag on my project, then I am unable to pull new changes from master.
This is very annoying. How do I take care of this.
Also, how do we make sure as a team that everyone of us is working separately on different module, and make surely everyone is able to commit/pull each other's changes.
The project folder with M tag is prohibiting us from doing so.
Edit 1
I have followed steps for this as well
git rm -r --cached ProjectName.xcodeproj
git commit -m "Removed file that shouldn't be tracked"
Even after doing this,
I had made changes in File1.swift, with my team member's changes in File2.swift
He had already committed it, I wanted to pull those changes, however due to changes in File1.swift I was unable to pull it.In order to make it work, I had to discard changes in File1.swift and then only I was able to pull those changes. If this is so, then it is defeating the purpose of using git
Xcode project files
The Xcode project file, or to be more precise, the pbxproj file inside the xcodeproj container keeps track of all files (among other things). Unlike Eclipse, Xcode does not monitor your source/project folder for changes thus does not update the list of files which can lead to inconsistencies after a merge.
Merge conflicts
If your team member adds or removes a file in his local copy of the repository and pushes his changes to the server, he basically overwrittes the pbxproj and therefore updates the list of files of the Xcode project. If you pull those changes there are two possible scenarios:
Git can merge the changes automatically which usually means it will keep your copy of the pbxproj file without the updated file references.
Git cannot merge the changes and therefore indicates a merge conflict that you need to resolve yourself. Depending on the differences and amount of changes these merge conflicts can be pretty annoying to resolve. Sometimes it might be easier to just delete your copy of the pbxproj file, use the one from the server and reapply your local changes, e.g., add file references.
In both cases you might need to compare your pbxproj file against the one from the server and merge things by hand. And yes, your project file will be marked with an M (for modified) which is perfectly fine. Just commit your changes and you are good to go again.
One more thing: Whenever you want to pull changes from the git server you can either stash your changes (git stash) or commit them.
Avoiding merge conflicts
In case you want to avoid merge conflicts in the future, I recommend having a look at the following tools.
Cocoapods
Cocoapods can be used to modularise your project into smaller pieces by creating private Pods. The benefit of this technique: You do not have to keep track of newly added or removed files. Just run pod update and you are up and running again. There are several blog posts that describe this technique in detail, e.g., here
phoenx
At my former company we had a pretty huge codebase and ran into some trouble when using Cocoapods. Therefore, we have developed our own meta-build system called phoenx. Phoenx can generate Xcode project and workspace setups of arbitrary complexity. It uses metadata files (something like Podfiles and Podspecs) to generate the projects etc. . Build settings will be stored in xcconfig files. At the moment it does not provide any setup tool so you have to invest a bit of time to write the xcconfig and metadata files by hand. We are working on a more convenient way to use it though. If you want to give it a try you can install it via sudo gem install phoenx. Documentation is available on GitHub.
Hope that helps!
In earlier versions of XCode, there was an option called Commit to Branch on commit page which really helped when you'd messed around too much with your code in a particular branch and didn't want to commit it into the same branch and neither did you want to lose all the code that you'd written.
I couldn't find this option in XCode 6. Is it still there hidden somewhere, or have they removed it?
An excerpt from the "Save and Revert Changes" section of the Apple IOS Devloper's library
https://developer.apple.com/library/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview/ManageChanges.html
Create a Branch to Isolate Risky Changes
After you’ve worked on a project for a while, you are likely to have a
body of reliable, stable code. You can choose Source Control > Working
Copy > New Branch to create a copy of that code. Then you can work on
new features and other changes without destabilizing your existing
code base. When you are satisfied with your changes, you can merge
them back into the body of stable code. Use Source Control > Working
Copy > Merge from Branch and Source Control > Working Copy > Merge
into Branch to combine and reconcile differences between versions of
your project.
I am working on a project with another developer. We are in the process of a major upgrade with lots of breaking changes. The software we are working on is an AddOn to a product, and we are upgrading to work with a new version of the product. He has checked in some breaking changes that will not run in my environment yet because I am still running on the old version of the product. I have checked in some changes on top of those. Is there any way I can retrieve the code such that it includes only the changes up to the point before the breaking changes and also include only my changes after that in my workspace?
If I had not done a "get latest" I would be OK now because I made the changes on my machine so I would have them. But now I need to "get specific version" to take me back before all the breaking changes and somehow merge only my changesets into my workspace. But there seems to be no way to merge changesets into a workspace, only into another tree. I could select only the files that I touched and get the latest versions of those files, but some of the files contain changes from both my changesets and his changesets (and mine are after his).
So what I really want is a way to merge specific changesets into my workspace (without pciking up all the previous changes) to get back to the state I was in before I did "Get Latest". Is there any way to do that?
Looks like there's no good way to do this. Fortunately, I had another branch that represented the changes I wanted (I had only merged my changes I wanted into it). It didn't feel right to just copy the whole tree over my working tree, so I used WinMerge to identify the files that were different and copied just those files over (after a cursory look to confirm that it was a file that included my changes -- there were a few files generated by Visual Studio that were different just because they were in a different path).
So I guess the general solution would be to create a branch in TFS, merge everything you want into it, get a local copy, then copy the results into your workspace. That does leave a mess in TFS, though (how do you completely remove the dummy branch?) Fortunately the branch I had was one we really wanted to keep (we have a build branch separate from teh development branch).
I'm not really sure if this answers your question, but if you select "Get Specific Version..." then you can select a specific changeset.
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.