My project previously was in the Git source control (cloudforge.com). Now I want to exchange it to SVN source control. (Why not, my team members are not familiar/feel-comfort in Git). But when I want to checkout it already shows that it is yet in the Git source control.
I can't delete my project from git. It shows this error
But I have configured this project into svn by other Mac mini and able to checkout and commit.
My Question:
Why I can't checkout this project from this Mac as I can do it from other Mac?
OR
How can I delete my project from the first screenshot? Because there I can't find any option to delete.
Are you wanting to import your complete git repository into a Subversion repository, including history and log information? Or are you simply wanting to take a snapshot of your current project and make a Subversion repo out of it?
If you want to import the full history, then this may or may not be possible. Git supports branching/merging schemes that Subversion can't handle. It's only possible for fairly simple, linear project histories. See this other question for more details and options.
If you only want to move your current code snapshot into a different repository type, then the process should be relatively straightforward. All of git's metadata is stored in a normally-hidden folder in the root of your working copy named .git. Most IDE's flag a project as being connected to a git repository based on whether this folder is present and whether it has the expected contents. I'm not 100% certain about xcode, but here's what I typically do with other IDEs:
Make a copy of the working copy directory
Delete the hidden .git directory from the copy (plus any metadata files created by your IDE)
Import the copy into the IDE as a new project
At this point, your working copy will have no metadata and the IDE shouldn't associate it with any particular repository or version control system. You should now be able to import it into a Subversion repository using the same process that you would for a new project.
Related
Note: I am relatively new to Git / GitHub. I understand my way around, but I am confused with this corner case
Background
I created an IntelliJ color scheme git repo and pushed it to github online. The directory structure was ad hoc and made up of only output. This was actually fine and worked well.
I noticed that people would not get updates from me this way, and decided to create a JetBrain Repo plugin. This also works well; however, my github location and plugin location on my PC are different.
Issue
I looked over Change Git repository directory location. but was not sure if this fit my usecase.
Since my github is just output files and my plugin files are all input files, can I simply just copy over my .git files (along with README files and such) , and expect it to work correctly?
The linked SO question seems to relate to JUST moving the same directory structure and files over to another location. I am dealing with different directory structure, different files, and directory location; however, it IS the same project.
Update
Before, my workflow was:
Modify Color Scheme in IDE
Export settings from IntelliJ
Place in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
Now it is
Modify Color Scheme in IDE
Run project and autogenerate output in \IdeaProjects\ChroMATERIAL
Place output in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
What I want
Modify Color Scheme in IDE
Run project in \IdeaProjects\ChroMATERIAL
Windows GitHub Client: \IdeaProjects\ChroMATERIAL merge
GitHub
I'm assuming that the generated output matches the structure you need for your Github repository. If so you could easily move your .git folder from
\Documents\Github\ChroMATERIAL
to
\IdeaProjects\ChroMATERIAL
What you should check:
Will the generated output directory be cleared if you clean the project into Intellij? If so you should stick to your current workflow since you could easily delete your local copy.
The other thing which could be a problem is the Github Desktop Client since I don't know how it behaves nor how or if it must be configured in a special way to reflect your changes. (if you just call it from the inside of the repository it should not be a problem at all)
For your explanation:
Git uses relative paths. So it is irrelevant where the repository lives inside your system. The important part is the structure inside the repository since this will be cloned to the remote repository.
I recommend that you copy your .git folder rather than move it. If something goes wrong you can easily revert.
Apple has introduced a new project-related type of file in Xcode 5: "xccheckout".
This file is located in the ".xcodeproj/project.xcworkspace/xcshareddata/" directory, and it seems that it is related to the project's version control system.
An example file is here: http://pastebin.com/5EP63iRa
I suppose that this type of file should be ignored under VCS, but I'm not sure.
So here are the questions:
Should "xccheckout" be ignored?
What is its purpose?
You should check in an Xcode 5 .xccheckout file; in general, files in xcshareddata should be committed.
An .xccheckout file contains metadata about what repositories are used in a workspace. For a single project in a single repository that doesn't make much difference. But if you're using a workspace that has multiple projects from different repositories, the presence of an .xccheckout file in the workspace allows Xcode to know what all of the components that make up a workspace are and where to get them.
The *.xccheckout file contains VCS metadata, and should therefore not be checked into the VCS.
On the other hand: checking in this file will probably not create merge difficulties or other problems.
If you want to ignore this file (which I recommend) you should add this line to your project's .gitignore:
*.xccheckout
Abizern's solution will not work for projects inside a workspace. Because, when you use a workspace, the path to the *.xccheckout file will be: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. And it actually ignores more than you would want.
Edit:
This file exists for managing Xcode's knowledge of the possibly many VCS systems in your project, see Chris Hanson answer. For > 99% of the projects the .xccheckout file is configuration overkill.
It depends. The file contains references to the remote repository you are using. If you are using a centralized VCS such as Perforce or Subversion, everyone's remote repository will be the same and so you can and should check the file in.
If you are using a distributed VCS such as Mercurial or git, but using it as though it were a CVCS (in other words, everyone cloned from a shared repository directly to their personal workspace on their machine) then you still might want to check it in.
However, if you are using a DVCS with everyone having their own remote clone, for example using GitHub in it's standard usage pattern, you DO NOT want to check this file in. If you did then your Pull Requests will be asking for your repository settings to get copied into everyone else's xccheckout file, but your repository settings will be different from everyone else's because you are all using different remote repositories.
Yes, the Project.xccheckout file should be committed to your repository. Xcode uses this file to tell others who open the workspace the entire list of source control repositories used by the workspace and the location of the working copy relative to the workspace, whether those repositories are Git, SVN, or both.
When you open the workspace, Xcode uses the Project.xccheckout file to notify the user that there are other repositories forming part of the workspace, and asks which should be checked out. When checking out additional repositories, Xcode places the working copies in the same workspace-relative folder structure as they were when the Project.xccheckout file was generated.
As Chris Hanson said, it probably doesn't matter for a single-repository, one-project workspace, but for more complex affairs it'll be very handy indeed.
You can find out more about this in the WWDC 2013 session video Understanding Source Control in Xcode; the relevant portion starts at about 15 minutes.
This is what I have in my .gitignore for Xcode.
#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/
It keeps anything that relates to the local state of the way the projects looks for me out of the repository.
The xccheckout file is under here so it is not tracked on my system by default.
Xcode has gotten better and separating out what needs to be shared and what needs to be kept locally. For example; these lines will ignore the default build schemes, which is fine because you can mark specific build schemes as shared, and they are put in a directory that is not ignored.
Breakpoints are ignored, but you can mark specific breakpoints as being shared across projects and they are also placed in a directory that is not ignored.
This is about outdated repo details inside XCode. The case is:
I'm reusing a supporting library from an old project in a new one.
I used "Add files to X project..." functionality to copy them to the new place.
"Automagically" the files were copied with a reference to an old SVN repo, that don't exit anymore.
So... Now I have a project with 2 repos visible, incl. one inactive. I can't commit changes to copied files, as the old repo is still linked.
Two question here:
Is there a way to edit old repo data?
Is there a way to move the copied files to the new repo, where the rest of the project is?
Ultimately I need to commit both parts ;)
Thank you.
OK. So resolving this issues required several steps to be performed. Not sure if all were required, but the eventually I got it right.
Commit all changes you can (in my case all but the folder that was linked with the old repo). Archive your projects.
Go to the root folder of your project and use svn switch --relocate command to merge repos. Details: how to change svn settings
Remove the project from XCode (via Organizer) delete the entire project folder
Remove repos in the Organizer
Fetch whatever was committed in the SVN again. Do that and create a new project. If you see any missing files highlighted in red, like my folder that couldn't be committed, delete it.
Manually add the missing files / folder that to the project, from a local copy.
Now you can commit to the repo!
Tiresome, like most things in XCode... ;)
I'm new to iOS developing, I haven't used earlier versions of XCode.
Yet I have stored my project on my local hd. Now I want to use some online subversion service.
I cannot seem to find the appropriate options in XCode. The hints that I googled all refer to a menu called SCM which I don't seem to have.
I created a new and empty repository online (webbased) and tried to configure XCode to use it by selecting the "Connect to a repository" menu when xcode starts. After some tweeking in the command line this "connect to a repository" succeeded but afterwards XCode simply closed itself again.
I tried copying the files that belong to my project to the path that I set up to be used with SVN manually. I opened the project in XCode from that path and after adding another file wanted to commit that change but couldn't find how to do that from within XCode.
Now I found that in XCode / Organizer / Repositories / MyProject is listed but has the type "GIT", which is wrong.
Do I have to change the repository type to SVN instead of GIT? If so, how can I?
When you created the project there was an option to put the project under source control. This option creates a git repository and is checked by default.
To use SVN you have to import your project into the SVN repository. (And you probably don't want it to be under git and svn at the same time, so you'll either delete the .git folder or recreate your project without the scm option selected.) Once the project is imported into your repository then you make sure Xcode knows about the repository and you can check the project out.
But really I'd recommend just using Git. It's a modern version control system with lots of nice features (though to do much of anything out of the ordinary requires using the command line) and there are nice project hosting sites for it like GitHub. I don't think SVN compares very well to git.
I was using "Tortoisesvn" to take control of my programs's source code. But sometimes, I had problems/bugs while using it. So I decided to use "git"( http://code.google.com/p/msysgit/ ) Also, I'm using git with "Git Source Control Provider" visual studio plugin. Source control is very easy with this extension.
So now I have few noob questions...
1) Where is the main repository? Where is the folder that my project's files backup?
2) Is this program working completely offline? I mean how secure is that? Are there any changes that someone can steal your files( repository/source codes etc. ) ?
Thanks for any input*
Best Regards,
Git is different from SVN in that Git is a DVCS - Distributed Version Control System. That means every "working copy" is a full blown repo. Repos can talk to themselves and there is no need for a main repository ( but usually there is a main or "blessed" repo that is the central.)
So when you created a Git "working copy", you created a repo. You setup another repo on different maching / server and push to it if needed.
I don't know what you mean by "backup", but the metadate for git will be under the .git folder ( it will be hidden unless you have selected to show hidden files and folders in Explorer)
Another feature of DVCS that results from having full blown repos and no main repos is that it works offline. You get full history and you can commit without contacting any server etc. Again, I don't understand why you would ask about security in this context? If it is offline, wouldn't that be the most secure? And Git has lots of security and integrity mechanisms.
Git doesn't work with a centralized "main" repository. Each repo is considered an equal to every other repo.
Git can work completely offline (unlike some other source control systems), but in order to push changes to other repositories you'll of course need to be connected in some way to the machine where the remote repo is hosted.