Wrong results switching branches in XCode 4 with Subversion - xcode

I have a project in XCode 4 using subversion over ssh. It's configured with the branches, tags and trunk subdirectories and my project (let's say ProjectOne) is its own directory in trunk like so:
-|-trunk
| \- ProjectOne
|-tags
\-branches
I have the relative paths to the three directories configured in XCode like so:
Trunk : trunk
Branches : branches
Tags : tags
And all three have a green 'light' next to them. I have created a branch for my project called ProjectOneBeta using the organiser, the svn tree now has this structure:
-|-trunk
| \-ProjectOne
|-tags
\-branches
\-ProjectOneBeta
\-ProjectOne
If I checkout the project (with trunk/ProjectOne selected) it will check out by creating it's own directory in my Objective-C directory. When I go to switch a branch the structure gets all screwy though. It then becomes:
-ProjectOne
\-ProjectOne
Can anyone help? Have I checked in the code incorrectly initially? Should there not have been that initial subdirectory in trunk? Am I checking it out wrong? Or do I simply have the relative paths set incorrectly despite the green?

I concluded that the configuration was correct but the initial checkin was wrong. I moved all the stuff up one level so the code & project was just in 'trunk'. Works fine now I just have to remember to check out to a named directory.

Related

Xcode project shows two git repositories (only one is correct); commits go to both

I'm new to git. So, I'm confused and might not be using the correct terminology.
I have two separate Xcode projects, each with it's own local repository. Although the projects have similar names, each project has separate and distinct source files. I've done a couple of commits to each, but when I commit in one project, the commit shows up in both. My new project shows both projects in the git navigator (which might be related to the problem). When I made the new commit, the old project was not open in Xcode.
Each project has it's own .git folder.
Details:
Old Project 1 ("Scheduler"): Shows one repository, but the last commit I did in the new project appears there.
New Project 2 ("Scheduler6"): Shows two repositories, and the last commit I did there shows up in both.
Why does Project 2 show both repositories, and is that the reason my commit ended up in both? How to correct that? This has happened before, and I did "git reset HEAD^" in the old repository to remove the incorrect commit. I want to stop this behavior forever. (And I'm hesitant about fooling around with git commands in Terminal.)
Mystery solved. I created Project 2 by copying numerous files from Project 1, but three image files ended up as references to the Project 1 files, not copies. When I removed those references and added copies instead to Project 2, the GIT navigator stopped showing the Project 1 repository.
Summary: Project 2 showed both GITs because Project 2 referenced some files in Project 1.
There are two ways to fix the trouble:
A. Manually: Open Project 2, select each file (one by one), and check that the Full Path shown in the Identity and Type inspector is a Project 2 path. Fix any files that reference Project 1.
B. Using Terminal: The Xcode project control file is a text file, so checking all Full Paths can be automated using Terminal commands, thusly:
(I assume the two projects are named Project_1 and Project_2, and that their project folders share the same parent folder.)
Duplicate Project_2.xcodeproj (which is actually a bundle).
Change the duplicate's filename suffix from .xcodeproj (I used .xxx). The duplicated "file" becomes a subfolder containing four items, one of which is a text file ("project.pbxproj").
Launch Terminal.
In Terminal, execute "cd path_to_project_2_subfolder". Shortcut: type 'cd', space, drag the folder that as created in step 2 to Terminal, and hit return.
x. (Verification step.) In Terminal, execute "ls" to show the four items. They should be:
project.pbxproj project.xcworkspace/ xcshareddata/ xcuserdata/
In Terminal, execute "strings project.pbxproj | grep ../Project_1/". This shows all lines in project.pbxproj that reference Project_1. '|' is a pipe command that sends the strings output to grep which filters the strings. Because my two project names differed by only one character, I surrounded the project name with '../' and '/' to limit the output to directories and files that belong to Project_1, but you could just use the bare project name if your two names are dis-similar. The commands and arguments are case-sensitive. You should see some lines that reference Project_1. You could also open project.pbxproj in a text editor and search for lines containing Project_1.
One of my files (sharing.png) appeared thusly:
1F4E32C32343DE1A0053C239 /* sharing.png */ = {isa = PBXFileReference;
lastKnownFileType = image.png; name = sharing.png; path =
../../../../Project_1/sharing.png; sourceTree = ""; };
Open Project_2 in Xcode and fix the files that show as references in the strings command. Along the way, use Method A (above) to verify your work.
Check that the GIT navigator only shows Project 2. You might have to close Xcode and relaunch.
I had the same problem, I think it happened because I Initialised git twice on one project. First when I wanted to create the project folder I executed "git init" in the terminal, and later when I wanted to create the project itself by Xcode (a swift project), I did not remove the check mark from initiate a git repo for project. So I have initiated two git repos for one project.

Make a folder both a symlink and a git submodule

This my project structure in a nutshell:
+ A
| + some content
|
+ B
+ A
I want in my main git repo a submodule in B that points to A. But since the A project contains the main method, I want to be able to quickly test before committing, so I'd like a symlink (or rather a mklink since I'm on windows) that points to A so it gets updated without committing.
The problem is that A doesn't have just "some content".
It also has a .git subfolder in it, which a submodule does not.
If you can, use git worktree in order to checkout a branch in a separate folder (than the original A cloned folder)
Then you can try and use a symlink from B subfolder to A, after adding A as a submodule in B.
Note: since Windows 10 build 14972 (Dec. 2016), symlinks (mklink) can be created without needing to elevate the console as administrator.
A better approach is described in "Git: Possible to use same submodule working copy by multiple projects?".

Externals when migrating from SVN to GIT

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.

Xcode Git Submodule Commit Issue

What I did
I made a new Single Page App project in my application called "parent".
I made a new Static library project called "child" and I've Added it as a git submodule in my parent project folder.
I have imported the child project into the parent project by dragging from the finder from submodule directory, the child project file to my parent project in Xcode window -> Parent Project file tree.
Now Is my problem
When I would like to do a commit through File -> Source Control -> Commit, I select files enter my message and do a commit all goes right.
Now When I make a change into my child project and try to commit by the same way, xcode make me know it success the commit
Now try a pull from File -> Source Control -> Pull, My child project is selectable but my parent project has "Uncommited Changes".
So I come back to the commit interface and I saw the items that should have been committed during the last commit. Especially the folder of my submodule project.
What I did to resolve the problem
I use git from the command line in my parent project folder:
git add .
git commit -am "Core has been modified"
When I use this, I can access my to repository from the pull interface, that confirm that all change has been committed.
The real Problem
My company would like to make that work only with the Xcode SCM tool.
The problem seems to be linked to the use of "Submodule"
How can I make it work without the use of the Command Line
We have the same problem. It's like a small bug in XCode. Our workaround at the moment is the same as you mentioned and the only solution would be a bugfix or enhancement how XCode support
Our workflow looks like the following :
-commit submodule changes with XCode
-commit main changes with XCode
-commit main directory change with CLI ( git commit )
-push main & submodule with XCode
we hope that this small bug would be fixed in the future directly in XCode
When you make a commit in a submodule, it shows up as a change in the parent.
The solution is to make changes to the submodule first, then commit the changes to the parent. This way all of your changes to the submodule will get bundled into the parent project commit.

TeamCity Subversion labelling

I'm trying to label a build that is made of multiple checkouts like this:
+Root
+-trunk
+--Folder1
+--Folder2
+-Tags
+--ProjectA
+---Build-123
+----Folder1
+----Folder2
where 123 in Build-123 is the build number.
I'm trying to achieve this by using the following labelling rules:
/Root/trunk/Folder1=>/Root/tags/ProjectA
/Root/trunk/Folder2=>/Root/tags/ProjectA
And this labelling pattern:
BUILD-%system.build.number%
I was hoping that TeamCity would create the BUILD-123 tag and copy the contents of Folder1 and Folder2 into it. However I get the following error:
Failed: Failed to set label 'BUILD-123': Svn labeling failed: Cannot copy 'Root/trunk/Folder1', 'Root/trunk/Folder2' to the same directory 'Root/tags/ProjectA/CO-BUILD-123'
I'm using TeamCity 5 with Subversion 1.6
This seems to be a limitation on SVN side. The only solution I've found is to call SVN directly to create the destination folder first (mkdir) then use svnCopy to copy each source into that folder.
It seems we need to have labeling rules such as
trunk => tags # the trunk contains the root of my project
branches/*/ => tags # a branch usually contains the a copy of the root of the project
tags/*/ => tags # a tag usually contains the a copy of the root of the project
this will enable (re)tagging branches and tags without explicitly setting their names.
unfortunately TeamCity does not have such generic rules
Please read TeamCity's docs about this topic:
I suppose you need rules like
/Root/trunk=>/Root/Tags/ProjectA
or
/trunk=>/Tags/ProjectA
depending on where you repository root is.

Resources