I'm trying to resolve a tree conflict from SVN in Xcode. From the answer here The operation could not be performed because "PROJECTNAME" has one or more tree conflicts I should simply resolve the conflict using the command-line. No problem, I've got some experience with SVN command line, so I do exactly that
svn merge ^/project/trunk
svn resolve --accept working conflictedFile1.m
svn resolve --accept working conflictedFile2.m
svn resolve --accept working conflictedFile3.m
svn ci . -m "merge: from trunk"
Then I go back to Xcode and just to make sure everything is happy and try to test that everything "took". I do "Source Control -> Update" and then "Source Control -> project -> Merge from Branch … -> trunk" and I again get the stupid error message: "The operation could not be performed because of one or more tree conflicts." and the additional message "The files conflictedFile1.m, conflictedFile2.m, and conflictedFile3.m had a tree conflict."
In fact my question is not how to resolve this tree conflict, but how do I tell Xcode that I already did resolve the conflict? Is there some out-of-date svn database somewhere that I need to refresh/delete? Did I resolve this wrong in the first place?
Bonus question:
It would be really nice to continue to use Xcode's builtin SVN features to do merges, etc. I can use the command line but I'd really rather not for things like merges, when I have a builtin merge-diff tool in my IDE. In general, any advice on using SVN in Xcode properly is greatly appreciated. Therefore, if there is any specific advice anybody can give me to prevent this from happening in the future, I'll be very happy.
What I did was:
(1) branch from trunk to Branch1
(2) add a file on Branch1 (as well as other edits)
(3) branch from Branch1 to Branch2
(4) make edits (no new files)
(5) merge from Branch2 to trunk
(6) merge from trunk to Branch1 -> tree conflict with the files originally created here
Related
I'm trying to run repodriller on all the commits of Jsoup. Each time I start the analysis of a new commit, I need to checkout the repository for that commit, so in my CommitVisitor, I execute this command scmRepository.getScm().checkout(commit.getHash());.
This command throws an exception 9/10 times, being
java.lang.RuntimeException:
org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout
conflict with files:
src/test/resources/htmltests/news-com-au-home.html.gz
src/test/resources/htmltests/xwiki-1324.html.gz
src/test/resources/htmltests/xwiki-edit.html.gz
src/test/resources/htmltests/yahoo-jp.html.gz
Obviously, I have done no modifications on the repository, as I also cloned it fresh.
I highly doubt there's a problem in general with the approach because I've used the same technique on 10 java projects and only this one is problematic.
Is there a way to avoid the checkout of these files with JGit, or some alternative solution to the problem?
If possible, check if the same checkout would work with a regular Git command (git checkout or git switch)
A possible cause of a CheckoutConflictException is an unresolved merge conflict.
I would also check if you have the same file with different case (uper/lowercase).
I am working on shell script, which will automatically merge the different branches in SVN, but currently I stuck as am getting conflicts.
Can we resolve the conflicts by the script only?
No. You can go download a GUI & use it to resolve conflicts. One of the more popular GUIs is: https://tortoisesvn.net/downloads.html It can also be used with a file comparison tool like http://winmerge.org
If you want to try to do this automatically, you may have to figure out which of these options that you'd like to use. These 2 come from Apache's Resolving Tree Conflicts page:
svn resolve --accept=theirs
svn resolve --accept=mine
These 4 come from RedBean.com's SVN 1.8 Basic Work Cycle page:
svn resolve --accept=mine-conflict
svn resolve --accept=theirs-conflict
svn resolve --accept=mine-full
svn resolve --accept=theirs-full
svn resolve --accept=working
I am writing a shell script which can store the actual state of a SVN working copy and restore it later, exactly as it was. Currently I have a problem with specific, rare combination of revisions of files and directories which seems to be undetectable.
Let's say that there is a repository with two revisions.
There are two cases:
Assume that foo is a file (or a directory) that exists only in revision 2. At the beginning the whole working copy is at revision 2. Then foo (and only foo) is updated to revision 1.
Assume that bar is a file (or a directory) that exists only in revision 1. At the beginning the whole working copy is at revision 1. Then bar (and only bar) is updated to revision 2.
The both cases are very similar but it seems that they have different solutions. In both cases the file (or directory) simply vanishes. However, output of command svn status contains no information about that.
How to create by a shell script a list of such files and directories?
There is one simple but bad solution. It is possible to use command svn list to get a list of files that should exist in current revision and compare it to the list of files that really exist.
This solution is unacceptable because it takes a lot of time and generates a big traffic to the server.
I posted the best answer that I can come up with. Still, it works only for the first case and has false-positives.
I once attempted to do the same thing that you're doing, and I hit so many corner cases that I eventually went a completely different direction. Instead of using a script, I used a local git repository.
Check out a working copy from the Subversion repository, then create a local git repository in that folder using git init. Add the entire contents of your Subversion working copy to the git repository - including the .svn metadata directories - using git add followed by a git commit. Git is now keeping track of your working copy plus all of the Subversion metadata associated with it. My current git repository has 5 different branches, each based off of a different Subversion revision and containing different sets of changes that haven't been committed to the Subversion repository yet. The git repository makes it easy to switch back and forth between them, and Subversion works as if they were all separate working copies. Even for large working copies, git does a good job at storing contents efficiently and switching between branches quickly.
Note that this is different than the git svn command, which is git's method of directly interfacing with a Subversion repository. I found git svn to be more complicated to use and easier to break things. Wrapping a normal Subversion working copy in a git repository allowed me to still do all of my repository operations using Subversion, and only required me to learn a few basic git commands (add, commit, branch, checkout, etc). It's a bit easier for someone who is experienced with Subversion and new to git; git svn is more geared towards someone who is experienced with git and stuck with a Subversion repository.
I found partially solution for the first case.
svn status -u | grep '^........\*........ ' | cut -c 22-
This code shows all files that exist in head revision and do not exists in current one. This finds files and directories from first case. However, it generates false-positives, when a file is removed when the parent directory (which still exists) is updated to lower revision.
Ok, I've read it all, and tried to find solutions to my problem to no avail, so was wondering if anyone would be able to give me the ultimate solution to the migration issue I'm having.
It's to do with using SVN externals in GIT, so hold on to your chairs.
I have looked at the following topics only to find that no one has the exact same setup as I have.
git submodule svn external
git: How do you add an external directory to the repository?
What happens when I clone a repository with symlinks on Windows?
Git Symlinks in Windows
Now my setup is really not that complicated, but I can't work out a way to get it working the way I need it. I have:
Project1
Core
Libs
I then have in my main project
MainProject
MainFolder
file.cs
file1.cs
file2.cs
Core (external of Project1)
Libs (external of Project1)
Obviously this is fine on SVN, as you can use externals, but with sub-modules, you can only create them pointing to the root of the repository, which in this case doesn't quite work for me, since I have both Core and Libs on the same repository. Moving them out isn't an option at this point, since we're still in the migration process, and I need to keep constantly syncing them.
I then thought I could just go and use symlinks (notice I'm on a windows environment), as this way I would be able to checkout my Project1 repository at the same level as my MainProject, and via symlinks make sure my project still thinks everything is where it should.
This magically worked, however, upon doing git status I now noticed Project1 was marked as Untracked files, and by committing this and pushing, and checking out again, my symlink was gone, and I now had a hard copy of my Project1 repository copied into MainProject.
This obviously turned out to be a bit of a nightmare ow, so I was just wondering if anyone could help me with this, and maybe point me towards the right direction.
Thanks in advance,
Marcos
While I believe Michael Geddes is working on supporting symlinks in a future msysgit2, there is one way to get that support right now (that you have mentioned)
"Git Symlinks in Windows"
It allows to restore symlinks on checkout in Windows.
If you add Project1 as a submodule of your main project:
it won't be displayed as untracked files in your git status.
you can add a symlink in MainFolder to (Project1/)Core in order to get the structure you want.
I'm running Xcode 4.1 at work and home. I've successfully checked out a project from a remote svn repository (work) on my home setup. The repos was updated, so when I got home, I did an update on the local checkout.
The status of the updated files got flagged "U" (good) and a page appeared showing changes to accept, but when I hit accept, I get a popup that says:
The working copy "ABRA-D" failed to pull. fatal: Not a git repository
(or any of the parent directories): .git
Well, yes... the repo is svn, not git! Closing Xcode and restarting removes the "U" tags and I'm back where I started. Sounds like Xcode is confused about the repo type, though it knew enough to query the svn repo and find out what had been updated. Anyone know a cure?
That issue, already mentioned in "Error : Fatal: Not a git repository (or any of the parent directories): .git", has a somewhat curious solution described here:
Recently I created a new project and at some point I uploaded it to SVN. I am not quite sure how to reproduce this situation but somehow the versioning support of Xcode 4 decided to interpret the project as a git repository.
Each time I tried to copy a file per drag and drop into my project I got following error:
fatal: Not a git repository (or any of the parent directories): .git
The result was that the file got copied into the project folder, but the reference didn't get set in the project. I had to go into the folder and drag and drop the file again and uncheck the copy option this time, so that the reference gets set.
The Solution
Open Xcode and go to Window > Organizer
Find under repositories your project. It might be two entries if you use something like SVN.
Make sure it says "Type Git"
Mark the repository entry and hit backspace or delete (on mac)
Done
In my case, when i created my project it was using git. But later i removed all git files from my SVN repository. Then took an update.
Now, when i tried to add files, it gives me same error.
Solution: I removed all repositories against my project in XCode Organizer. Now when i added new files, it works fine.
I had a git and svn against the same project and tried removing the git and got this error
In the end went and manually edited xcshareddata found at and removed all the entries which had anything to do with the git repositoy.
myproject.xcodeproj/project.xcworkspace/xcshareddata