I use Xcode Repositories for working with svn, and today i added a new version to my Core Data Model and tried to commit it. But Xcode through an error:
svn: Commit failed (details follow):
svn: Entry for '/Users/user/Desktop/project/Core Data/Translator.xcdatamodeld/Translator 2.0.xcdatamodel/contents' is marked as 'copied' but is not itself scheduled
for addition. Perhaps you're committing a target that is
inside an unversioned (or not-yet-versioned) directory?
I think that the problem is that svn treates xcdatamodel as a dolder, and since it is changed it doesn's under version control anymore. But what should i do then? Don't commit new models and transfer it manually?)
I would recommend writing a subversion checkout/commit hook that would create a zip or tar archive of the Translator.xcdatamodeld directory, and then check that in. The actual xcdatamodeld directory would be ignored. (It would probably be best not to compress the archive, since compressing will just make it harder for svn to compute diffs and make your repository larger.)
The problem is that when you start with the first data model, Xcode creates a file, let's say:
myProject.xcdatamodeld
Let's say that you create, via menu Editor > Add Model Version, a second version of the model named _myProject_v2_. What Xcode actually does is: it creates a folder, named as your original model, and copies the original model in a subfolder, then creates a second subfolder with a file containing the new version:
myProject.xcdatamodeld
|
+- myProject.xcdatamodel
| |
| +- contents (a file containing the actual model)
|
+- myProject_v2.xcdatamodel
|
+- contents (a file containing the 2nd version of the model)
So SVN gets confused, because what he thinks is a file (the original myProject.xcdatamodeld) and which is stored in SVN, is now a folder, with subfolders.
And moreover, these subfolders, being created by XCode, gets eventually their hidden .svn folder.. so my solution is:
delete folder myProject.xcdatamodeld from SVN
do a commit of the rest
close Xcode and rename your folder project: eh: _projectFolder_old_
do a checkout of the project, which hopefully will not have a myProject.xcdatamodeld
from within xcode, create a bogus data model named myProject. Don't create anything in the model, it's useless
version it, with Editor > Add Model Version
close XCode
open in Finder your old datamodel in myProject.xcdatamodeld (right mouse button, Show package contents)
open in Finder your original model and copy the contents file from *projectFolder_old/myProject.xcdatamodeld/myProject.xcdatamodel* to the new project: projectFolder/myProject.xcdatamodeld/myProject.xcdatamodel (you will need to do a couple of Show Package Contents
repeat for your second version, copy the contents file from *projectFolder_old/myProject.xcdatamodeld/myProject_v2.xcdatamodel* to the new project: *projectFolder/myProject.xcdatamodeld/myProject_v2.xcdatamodel*
reopen Xcode and check everything is correct
add to svn the files, if not already added, and do a commit
Related
I'm putting a custom plist file (GoogleService-Info.plist) into my Resources directory, but it isn't getting copied into my built project. I can go into XCode and manually add it through "Copy Bundle Resources", but I need to get this running without manual steps.
I can't just use <resource-file src="src/GoogleService-Info.plist" /> in my plugin.xml because I'm building for a couple different widgetIds - I have 2 versions of this file that I switch out, depending on my widgetId. I have the copying and renaming automated with a hook to get the right file into Resources/GoogleService-Info.plist.
How can I get the file I put into Resources included?
The cordova-ios project has code to get the resource files included in the XCode project files, and you could replicate that, but I ended up with a workaround:
Copied my file to a consistent name in a before_prepare hook
Used a resource-file tag for the new name in my plugin.xml
I'm new to JavaFX 8 and the IntelliJ IDE. I have a JavaFX8 project that works but not as I would like. I'd like to try another approach but the substantial changes may not work. I don't want to loose code I have working.
To save code I have working, I've been creating a new project and then locally copying all the folders(.idea, out, src) and files except .iml, of the working project into the appropriate folders in the new project with the newly generated .iml.
This always seems to work but is it proper procedure?
I'm not on a team of developers and have yet to learn Git/GitHub.
Please advise. Thanks.
Maybe you should learn how to use a Version Control System like Git, then you can create a project repository and have different branches for things you want to try out. Keeping the working code in your master branch will prevent you loosing your working code. Also, when using a vcs you can always revert to versions of your code that have been working. The IntelliJ Idea IDE has perfect support for working with all different types of version control systems. If you don't want to learn any forms of vcs then there is no other way to "backup" your working code.
Is it proper procedure? It's probably not how most people would go about achieving what you want to achieve but it's certainly workable. If you wanted to stick with that for simplicity now, I'd copy the whole directory structure, delete the .idea and .iml files, and then create a new project in IntelliJ on that clean copy: IntelliJ will automatically set up folder structure based on the existing source without you having to go through any additional manual setup.
If you're willing to experiment with the git route, to achieve the basics of what you want to achieve is not very complicated and I've written a small quick-start below. IntelliJ offers very good support for Git, and once your repository is created you can do everything you need from the IDE. I'm going to assume you're working on Windows, although the steps shouldn't be too far removed on other platforms.
Install Git
You can download and install Git from https://git-scm.com/download/win, which will install a command shell called Git Bash.
One-off setup for your project
Open up git bash and go into the directory containing your source. Rather than seeing separate drives as Windows does, Git Bash assumes there is a logical 'root' directory under which all your files are accessible. Your C: drive will be /c. To move around you can use cd to change directory (using / instead of ) and ls to list files instead of using dir.
Assuming your source code is in C:\projects\myproject:
cd /c/projects/myproject
git init
The second line above creates a git repository in that directory. This doesn't affect your code, it just creates a folder called .git that contains all of the book-keeping information.
You don't want to have every file under version control - in particular you don't want your build outputs. You need to set up a file in your project directory called .gitignore which tells git which files and directories should be ignored. As a starting point you can copy https://github.com/github/gitignore/blob/master/Java.gitignore and rename the file to .gitignore
Basic Commands and committing your initial version
There are a small number of basic commands:
git status
Running git status will tell you which files have been modified, which are not under version control, and which files have been added to the staging area to be committed next time.
git add path/to/file
This adds a file to the staging area waiting to be committed. You can add multiple files to the staging area before committing them in one go.
git commit -m "description of your change"
This commits all of the staged files as a new version, which the specified commit message.
If you go into your project directory, do a git status and check through the list to make sure there's nothing you don't want to have under version control, then you can do git add . to add everything to the staging area and git commit -m "Check in initial version of the source code" to commit it to the repository.
After you've committed, you can run
git log
To see a history of all of the changes. IntelliJ has a view that will show you the same thing.
Creating an experimental branch
This is where git shines; if you want to try something experimental you can create a branch of your project while allowing git to preserve the original version.
git checkout -b experiment1
Will create and switch to a branch called experiment1. You can delete, rename, move, rewrite and develop whatever you like on this branch. The changes you commit will be independent of your original working version.
You can switch back to your original version (preserving all of the changes you've committed on that branch) using:
git checkout master
Where master is just the name of the default branch created when you ran git init. The experimental version will still be there and can be switched to again using git checkout experiment1 or from IntelliJ using the branch selection in the bottom right corner of the status bar.
If you decide that the changes you've made in experiment1 are to become your new "good" version, you can merge them back into the master branch and repeat the cycle from there.
I know how to use Mercurial to rename a file. And I understand that the hg log command does not display file history prior to renaming the file unless you use the -f option, and also that you can force the file history to be displayed as described in the accepted answer here Why 'hg mv' (mercurial) doesn't move a file's history by default?
However, when I rename a file, and then check the File History using TortoiseHg, I am unable to view the full history of the file including any changes prior to renaming the file, even though I updated my ~/.hgrc file to include those changes as explanined in the aforementioned link. How can I do that? How can I force File History to include changes that happened to the file prior to renaming the file, and display that history list on TortoisHg?
UPDATE
TertoiseHg version 3.1 shows the full history. I had version 2.8 that did now show the history.
Thanks to Lazy Badger for his answer.
Linked answer is outdated (partially, at least in part of existing section [default] - now it's [alias])
I see full history of renamed file in TortoiseHG without any additional tricks (TortoiseHg version 3.0.2)
I want to run some tests in my project but I do not want to affect the
original code, and I wanto to clone the project so I can run tests there
Does anyone know how to clone a project on IntelliJ Idea 11?
Using your operating system File Explorer tool, just copy and paste the entire project directory somewhere new. All of the configuration should use relative paths by default.
If your IDEA project is .ipr based, then delete the new .iws file before opening the project.
If your IDEA project is .idea directory based, then delete the workspace.xml file before opening the project.
If you want to copy and rename the project too, like I wanted to clone a project in order to use it with a newer version of IntelliJ.
Copy the whole directory to a new location, for example on Linux:
cp -r myproject new/location/
To rename the project:
2.1. rename the project folder (e.g. mv myproject newproject)
2.2. get into the new project folder (e.g. cd newproject) and edit the .name file with a text editor.
Open the new project now in IntelliJ (you may want to remove the workspace.xml if you don't want to keep the open file history - I kept it) and enjoy your new project!
For copy with rename I had to do one more step to get it to stop referencing the old module name. That was to right click on the module in the project pane and do Refactor > Rename ( or do Shift + F6 ) to rename the module.
This was for IntelliJ IDEA 2016.3.3
I had a gradle project and the provided answers did not work. The project did not have a structure in IntelliJ and I did not see the source files.
The following worked:
Export project (Export to zip file)
Move the zip file somewhere new
Unzip
With IntelliJ, import as a new project with "open".
Better Solution of course:
Have it in a git directory, make a "test-branch" and try whatever you want to try.
Apparently the accepted answer doesn't work anymore with current versions of Idea and the many derived IDEs (I tried this with PHPStorm). The problem: most of the config files are located in the .idea subdirectory of your project, but the file .idea/workspace.xml also contains the ProjectId, and that should of course be unique. So, if you copied the project directory manually, the easiest fix is to change the ProjectId - from what I have seen you can enter any alphanumeric string, e.g. "ProjectId123".
As far as I can see the main settings that are stored under the ProjectId are the workspace settings, under ~/.config/JetBrains/[IDENameAndVersion]/workspace/[ProjectId].xml. This file mostly contains the open editor tabs (with paths relative to the project directory) and the tool windows, so if you copy the project directory, you will always have the same editor tabs open in both projects (containing the "same" files, but from the respective project). If you want to avoid opening all files and setting up the tool windows, you can copy the old [ProjectId].xml file to e.g. ProjectId123.xml (using the ProjectId that you entered earlier).
After Copying your existing Project to a new folder don't forget to mark your src directory as Source directory. You can do this under Project Structure | Modules.
To duplicate and rename a CLion cmake project I followed the info in the other answers with some tweaks.
What seems to be the stepless way to eliminate all references to the old project name in the new one (tested with CLion 2019.1.2):
Copy folder
rename the new folder
On the new project folder:
delete the project info folder (CLion will recreate it):
<new project name>/.idea
On a text editor, open:
<new project name>/CMakeLists.txt
change every reference to the old project name with the new name and save it.
This will assure CLion will not use Project and Target info in "CMakeLists.txt" file to recreate project files and data in ".idea" folder with the old name.
Note that other info in this file referencing the old project folder, or files stored there, such as INCLUDE, SOURCE directories, and files, should also be changed to point to the new folder.
delete old compile data. Delete folders like:
<new project name>/cmake-*
Open project in CLion
It should have the new name and no reference to the old name anywhere.
If using CSV, you may also wish to delete old CSV data
EDIT: If project requires CUDA, CUDACXX environment variable must be reassigned to full path of nvcc compiler:
File->settings->Build, Execution, Deployment->CMake->Environment
IF CLion CUDA Run Patcher is installed it maybe needed to restart CLion.
I made a sample project called "Stack", but realized that i needed some more data structures, so i renamed everything - the project, made 2 new folders & their matching groups in XCode, modified the Target Build path to look for "Main/DataStructures-Prefix.pch" instead. But there's one file i don't understand -> earlier, i had gotten a "Stack.1" in my folder, so i just renamed it to "Main.1" and it doesn't seem to be affecting the build process, but i'm pretty skeptical. What does this "Main.1" do? is it the linked intermediate file like in C/C++?
here's a picture:
"Main.1" is a template for creating a "man page" (i.e. an on-line manual page) for your program. You can verify that by calling
man ./Main.1
on the command line in the directory where "Main.1" is located.
If you run
xcodebuild install
on the command line then the manual page is copied to the
$DSTROOT/usr/share/man/man1/
directory, where DSTROOT is the "Installation Build Products Location". The file is not used otherwise in the build process.
If you don't need a man page, you can just remove the file from the Xcode project.