Up until now I've been using Xcode with Subversion for my code repositories with no problem. Now I'm working on a project that uses a Git repository stored at GitHub, so I figured I'd go clone that repository to my local machine and get started.
In Xcode, I add the repository then tell it to Clone -- The machine chews on this for a while, and if I use the Finder I can see the files being placed in the target directory (which is a newly-created, empty directory on my system). After a while though, I get an error message:
fatal: destination path '/Users/myname/Documents/ProjectName' already exists and is not an empty directory.
I have tried this three times now, each time starting with an empty target directory, and it gives the same error message each time, so I know it has to be something I am doing wrong, or have not set up properly.
Thinking that perhaps something was going wrong and the system was trying to do a second clone operation (to a now non-empty directory) I tried canceling and trying a build, but some files are missing from the project -- so not all of it made it down to my system.
My searches on this issue turn up several hits for people doing the clone via command line and showing this error message, but not through the Xcode interface.
Does anyone have any suggestions about what might be going wrong?
Related
There's a problem with TFS everywhere plugin for Eclipse if I try to revert or restore a file under a source control and if the folder/file is mapped to a different volume than the actual project.
When I try to restore or revert it, I get an error:
java.io.IOException: Failed to rename /Users/*/*/*/*/.tf1/8/d54f18aa-bdce-4ab7-958a-01eaaf0c36c1.tmp to /Volumes/macOSData/*/*/*/*/*/some_file.cs. Check the file and directory permissions.
Log has additional line:
2018-07-31 12:44:39,814 WARN [ModalContext] (com.microsoft.tfs.util.FileHelpers) Main rename failed (source permissions problem?), trying to rename temp file back
There's no problem while I get specific version of the project, even with overriding existing files, so there permissions are fine, at least for getting files. Also, this does not happen when the file is on the same volume as the local TFS mapping.
Setting all permissions to 777 does fix the problem, but this marks all files with +x making them all "changed", making this solution unacceptable.
I tried mapping the base folder to a second drive (i.e. force creating a .tf folder on a second drive), but this doesn't help. The error will appear when I try to revert stuff on the main volume.
I tried using symlinks so the mapping stays within the same volume, but still no luck.
Is there any way to solve this? Or everything should be on the same volume?
After a whole day of digging around and poking with jshell, this appears to be a bug with File.renameTo() in Java on macOS. renameTo function silently fails without any exception even though there's no permission issue to write to the destination. This happens only when writing to a different volume.
I have submitted a pull request into TFS Everywhere repo on github with a workaround for this issue.
Anyone interested can compile plugin with this changes to get things working:
https://github.com/Microsoft/team-explorer-everywhere/pull/276
How do i know that online reindexing is done ?
I had a repository with name datadelivery-feed-tcp-c++ which I moved to datadelivery-feed-tcp-cpp and deleted the datadelivery-feed-tcp-c++ repository.
But On kicking online reindexing it gives a lot of below warning.It is stuck at this warning.
[2017-09-28 07:00:27,300] [Index-Batch-3] WARN com.google.gerrit.server.index.change.StalenessChecker : error checking staleness of 8737 in datadelivery-feed-tcp-c%252B%252B
org.eclipse.jgit.errors.RepositoryNotFoundException: repository not found: Invalid name: datadelivery-feed-tcp-c%252B%252B
I have tried flushing cache also
ssh -p 29418 host gerrit flush-caches --all
How do I resolve it ?
EDIT : By renaming a repo I meant, I have cloned it and imported all the data into other project, verified it and then removed it using delete project plugin
I think you already had changes in the datadelivery-feed-tcp-c++ repository and you just renamed it at the filesystem, correct? You can't do that because you need to adjust the database data accordingly. The better way to rename a repository is doing the following:
1) Clone the original repository (with all existing changes) creating a new one with the new name. Use the importer plugin to do that.
2) Remove the original repository (and all related changes). Use the delete-project plugin to do that.
Notes:
i) In your current case, first rename the repository back to the original name at the filesystem.
ii) You can download the plugins here.
My question is, how should my Erlang app reliably find a binary in the priv directory, not just in production; when installed properly, but during common test?
I realised today when I added a travis-ci configuration to an old Erlang app and pushed it to git-hub, that the process by which it works locally for me, is a little more fragile than I thought. The travis-ci build failed because it, not unreasonably, checked out my repo into a directory named after the repo, which is of the form erlang-APP. Locally my app is in a directory called APP-VSN though.
The result of this is that a call to code:lib_dir(APP) returns a correct result during the common test run locally, but if I rename my current directory to erlang-APP instead of APP-VSN (or just APP works too) my local build fails, just like it does for travis-ci, because code:lib_dir(APP) returns {error,bad_name}. The behaviour as though .. is added to the library path for rebar ct.
Renaming my github repo from erlang-APP to APP resolves the travis-ci build failure... but knowing the build tests only pass depending on the name of the directory the repo is checked out into doesn't sit right with me.
One way could be to use a soft link (either in the repo under version control, or created when initializing the tests), and make your Erlang code path go via the link. E.g., "./APP" -> ".", or "./lib/APP" -> "..".
Basically I deleted these files while doing some clean up in my puppet directory.
Now when I run #app: puppet apply /some/file I got an error stating these file where missing. (of course)
So I created two new files and I got this:
err: Could not run command from prerun_command: Execution of '/etc/puppet/etckeeper-commit-pre' returned 1:
err: Could not run command from postrun_command: Execution of '/etc/puppet/etckeeper-commit-post' returned 1
Any hints would be great thanks
Thanks
Anthony
If you have the Puppet "filebucket" enabled, you could look through the logs to find the hash of the removed file, then recover from that.
Otherwise go to your backups, or reinstall the package they come from.
The story:
I've been developing a RoR-app in both my desktop and laptop. It was quite handy to commit changes made on another, push them to github and fetch & merge on other.
The starting point is this: I committed latest changes on my desktop, pushed them to github and then fetched and merged them into my laptop. Then, I made some commits on laptop and pushed to github. Took the changes, merged to my desktop (with --no-ff). THEN, happened the probable source of all mischiefs: I reverted the desktop to commit where it was before the latest fetch & merge. Made some development work with it, committed, pushed to github. In the laptop, I did the revert as well, though I reverted it to a commit which was made somewhere between the latest fetch from github, fetched again and merged those. Some error messages came after reverting desktop and laptop both, but things worked still fairly well and I kept working on both machines.
Until now. I tried to push from my laptop to github, which gives the following output:
Counting objects: 106, done.
error: unable to find 5a2a4ac...
error: unable to find bc36923...
error: unable to find ecb0d86...
error: unable to find f76d194...
error: unable to find f899df7...
Compressing objects: 100% (64/64), done.
fatal: failed to read object 5a2a4ac... : Invalid argument
error: failed to push some refs to 'git#github:username/repo.git'
So, the question is, what exactly took place here?
EDIT: It seems that because of suspending my laptop and moving it from place to place in that state screwed up the hard drive somehow. The fsck output is unavailable because we worked around the problem and kept on working, but IIRC some branches and commits were dangling, including that commit which git failed to read. - Teemu
I have run into these kinds of issues.
Rather than spending hours trying to resolve and fix these issues, my 'solution' is usually to take the code I want, copy it into a new directory, delete the .git files and then create a new github for it and then connect the two as usual.
Although this may not be a specific answer to the details you raise, I find that there can be a number of ways that git/github issues can happen and rather than wishing I was a 'git expert' now (it's happening but it takes time), I do the above and continue with my actual application development.
The problem you have is that you are trying to read objects that are not part of your 'tree'. They exist but they have been orphaned. However, git allows you to merge one project to another so this is one way you can keep your commits without starting again, something like the following:
git remote add -f somename git://somegitplace.com/user/some.git
git merge -s ours --no-commit somename/master
git read-tree --prefix=ext/somename -u somename/master
git commit -m 'external merge'
git pull -s subtree somename master
Hope that helps. Let me know if not and we can attack it again