Whilst doing git svn clone -s https://svn.example.com/repo/ I received the following output:
r3073 = a6132f3a937b632015e66d694250da9f606b8333 (refs/remotes/trunk)
Found possible branch point: https://svn.example.com/repo/trunk => https://svn.example.com/repo/branches/v1.3, 3073
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: repo/branches/trunk
real path: repo/trunk
Continuing ahead with repo/trunk
fatal: Not a valid object name refs/remotes/tags/Sync Controllers
cat-file commit refs/remotes/tags/Sync Controllers: command returned error: 128
Running git branch -a gives:
remotes/tags/Sync%20Controllers
remotes/tags/v1.1
remotes/trunk
remotes/v1.2
I think the problem is that "remotes/tags/Sync Controllers" != "remotes/tags/Sync%20Controllers".
The tag on SVN has a space in it, but the tag in git had this space converted to %20 (URL encoded). To solve it just manually add a new tag with the verbatim name:
cd .git/refs/remotes/tags/
mv Sync%20Controllers Sync\ Controllers
Then run the git svn clone command again.
(Normally you'd do this with git tag OLDTAG NEWTAG but git was not allowing me to define a tag with a space in. The tag files are simply text files containing the hash of the relevant commit.)
You may use git-svn server-side alternative, SubGit in order to avoid many of git-svn translation problems.
I'm a SubGit developer and could say that we worked a lot to resolve character translation issues like the one above; in this particular case tag would be translated to a refs/tags/Sync+Controllers tag.
Note also, that git-svn has translated Subversion tag as a branch instead of a tag.
I ran into this issue today, and considered this branch which contains a pace in it is not important, i just run
git branch -r -d partialPayment%202.4
And re-run git svn fetch
It skipped current branch and continue grabbing the next one.
I'm using git 1.29.2 and getting the issue too. Additionlly it is running into a Windows Server 2016 and git is under cygwin.
Was checking into /GitMigration/.git/svn/refs/remotes/origin, and the folder is there with blank spaces not %20 so nothing to change on it.
However into the packed-refs the tag that is producing the problem does not appears, no name and no hash.
The problem should has another related issue with something else that produce the error, not just this.
Looking into the ./.git/config found a series of repetitions of the following lines:
branches = server/branches/*:refs/remotes/origin/*
tags = server/tags/*:refs/remotes/origin/tags/*
That are producing each time i did run the git-svn clone sentence. So i did remove those from the config file, save it and run again, but this time using git svn fetch, to prevent get again the lines duplicated, and voala !! Problem solved.
I believe the problem with spaces is fixed in Git >= 1.8.0 (See: #786942).
So you should upgrade it.
I've tested it and it seems to work in the recent version of git.
See GitHub Home page: https://github.com/git/git
Related
I am attempting to get the volar vue language server to work in place of vetur for neovim's native lsp.
Using both lspconfig and lspinstall I was able to create a working custom install for sumneko_lua (unrelated but had to manually build due to some issues with the built-in :LspInstall lua). Below is that code duplicated and modified for an attempt at using this new vue server:
local vue_config = require'lspinstall/util'.extract_config('vuels')
vue_config.default_config.cmd = {'node', './node_modules/vscode-vue-languageservice/out/index.js', '--stdio'}
require'lspinstall/servers'.newvue = vim.tbl_extend('error', vue_config, {
install_script = [[
! test -f package.json && npm init -y --scope=lspinstall || true
npm install vscode-vue-languageservice#latest
]],
uninstall_script = nil
})
Running :LspInstall newvue installs properly, however :LspInfo shows this language server is attached to the buffer (of a .vue file) but not active. I believe the issue is with this path: ./node_modules/vscode-vue-languageservice/out/index.js. It exists, but may not be the correct entry point? The default vue ls simply has vls as the command because it provides a binary. Am I missing something in this package? I have yet to come across another language server without a single binary to pick out.
Thanks!
Can you try an absolute path to the out.js file? In my pretty elaborate config for a custom Volar install I'm using something just /home/myuser/dev/volar/packages/server/out/index.js (where the volar folder is just the whole volar cloned github repo). My full config is here
I don't think you can use relative paths like you did. I know you're assuming that the "./node_modules" means "workspace directory" but it's hard to tell in which directory nvim-lspconfig opens up those executables.
I have yet to come across another language server without a single binary to pick out.
Volar also provides a binary, it's volar-server (after running npm i -g #volar/server), it's just with a custom install (ie. alongside the real volar) you can't use it, because I assume you want to use your local install with custom code.
As for more indepth debugging/logging, you can check ~/.cache/nvim/lsp.log to see why the language server dies in detail.
I got this problem when I use git svn to checkout my svn repos.Then I follow some suggestions from website and try to reinstall svn:core by
sudo cpan SVN:Core
but I still got following error when I try to check out a svn repos.
dyld: lazy symbol binding failed: Symbol not found: _svn_ra_make_callbacks
Referenced from: /usr/local/Cellar/perl/5.32.0/lib/perl5/site_perl/5.32.0/darwin-thread-
multi-2level/auto/SVN/_Ra/_Ra.bundle
Expected in: flat namespace
dyld: Symbol not found: _svn_ra_make_callbacks
Referenced from: /usr/local/Cellar/perl/5.32.0/lib/perl5/site_perl/5.32.0/darwin-thread-
multi-2level/auto/SVN/_Ra/_Ra.bundle
Expected in: flat namespace
error: git-svn died of signal 6
I check from website that the function is declared in the library header:
libsvn_swig_perl/swigutil_pl.h
But I didn't find error message related this lib (I did see some warning) when I install SVN:Core.
Are there something I need to setup or check for this issue when I install SVN:Core to make my git svn check out work properly?
Thank you~~
Eric
You should not need to manually install Perl package SVN::Core. The Homebrew formula subversion already does that — but, only for Intel hardware currently, as you can see. Volunteering to contribute other hardware support would be warmly welcome.
That formula (script) is what powers brew install subversion. Does this command work for you at all? Can you run svn info? If not, then you should first of all get svn installation working — and only then add git-svn on top. This is because the dependency structure looks like this:
If the bottom-most box is broken for you, then messing with Perl packages is guaranteed to not help.
I check from website that the function is declared in the library header
Please be specific; which website? I don't see any _svn_ra_make_callbacks in the latest upstream source, neither in 1.14.1 tarball.
Node, mimosa, durandal newb. I'm attempting to install the mimosa skeleton of durandal on windows, as detailed on the durandal website. Running this command:
mimosa skel:new durandal "C:\Users\Anthony\node projects\typelearn"
(quotes because windows and space in path) gives me this error, with the incorrect path for the template installation location:
C:\Users\Anthony>mimosa skel:new durandal "C:\Users\Anthony\node projects\typele
arn"
13:16:11 - Retrieving registry...
13:16:11 - Found skeleton in registry
13:16:11 - Cloning GitHub repo [[ git://github.com/BlueSpire/Durandal-Mimosa-Ske
leton.git ]] to temp holding directory.
13:16:13 - Moving cloned repo to [[ C:\Users\Anthony\C:\Users\Anthony\node proj
ects\typelearn ]].
fs.js:642
return binding.mkdir(pathModule._makeLong(path),
^
Error: ENOENT, no such file or directory 'C:\Users\Anthony\C:\Users\Anthony\node
projects\typelearn'
at Object.fs.mkdirSync (fs.js:642:18)
at _moveDirectoryContents (C:\Users\Anthony\AppData\Roaming\npm\node_modules
\mimosa\node_modules\skelmimosa\lib\command\new.js:87:8)
at C:\Users\Anthony\AppData\Roaming\npm\node_modules\mimosa\node_modules\ske
lmimosa\lib\command\new.js:64:5
at ChildProcess.exithandler (child_process.js:635:7)
at ChildProcess.EventEmitter.emit (events.js:98:17)
at maybeClose (child_process.js:735:16)
at Socket.<anonymous> (child_process.js:948:11)
at Socket.EventEmitter.emit (events.js:95:17)
at Pipe.close (net.js:466:12)
Removing the quotes around the file path in the command line argument gives the same error. Having a filepath with no spaces gives the same error.
Note that this works fine: C:\Users\Anthony\node projects\typelearn>mimosa skel:new durandal
One question:
how can I get the skeleton to install correctly? It looks like a bug to me: C:\Users\Anthony\C:\Users\Anthony\node projects\typelearn is definitely not a path that exists, yet mimosa is attempting to move the cloned repo there.
I believe I've fixed that bug and I released a new version of Mimosa. I'm unable to test on Windows at this time, but I'm hopeful the solution was cross-platform.
The folder provided was always envisioned to be something in the current directory. But I'm happy to support the use case you've brought up here.
This same issue will bite you on mimosa new too. I'll get that fixed after I release 2.0 sometime later this month.
It looks like the path has to be relative to the current directory so I believe this would have worked:
C:\Users\Anthony>mimosa skel:new durandal "\node projects\typelearn"
since it looks like it automatically adds the current path to the one supplied. So maybe the docs need to be more specific or else the bug is that the command should allow for absolute paths as well.
I think this is a bug. This works fine:
C:\Users\Anthony\node projects\typelearn>mimosa skel:new durandal
14:28:11 - Retrieving registry...
14:28:11 - Found skeleton in registry
14:28:11 - Cloning GitHub repo [[ git://github.com/BlueSpire/Durandal-Mimosa-Ske
leton.git ]] to temp holding directory.
14:28:13 - Moving cloned repo to [[ C:\Users\Anthony\node projects\typelearn ]]
.
14:28:13 - Cleaning up...
14:28:13 - Skeleton successfully cloned from GitHub.
C:\Users\Anthony\node projects\typelearn>
Bug created here: https://github.com/dbashford/mimosa/issues/339
I have created a push package with the appropriate files as per the Apple spec for APNS. This manifest file represents all of the files that are present:
{
"icon.iconset/icon_128x128.png": "78609fcff69688f969a38f957ac2f10fc79d6732",
"icon.iconset/icon_128x128#2x.png": "78609fcff69688f969a38f957ac2f10fc79d6732",
"icon.iconset/icon_16x16.png": "d348589e2cf37d8f23940f8545afe75a2e98b4ac",
"icon.iconset/icon_16x16#2x.png": "d348589e2cf37d8f23940f8545afe75a2e98b4ac",
"icon.iconset/icon_32x32.png": "e4418a1c5f2ecfbb702961515aaa65d5449b1c53",
"icon.iconset/icon_32x32#2x.png": "e4418a1c5f2ecfbb702961515aaa65d5449b1c53",
"website.json": "45be9c4a6f1bf96e27a9eecab219304b35c5ac24"
}
I have manually checked the sha1 values on the CLI and they are all correct, along with the file locations. And yet I still get this error back from Safari each time I try to get permission:
{ '{"logs":': { '"Verifying hashes in manifest.json failed"]': '' } }
Which is not valid JSON either. Any ideas why this would be failing?
I recently implemented push notifications through pushwoosh. They automatically created the package for me and I checked how they done it. The only difference between mine manifest file and your is a back slash before the normal slash. Maybe it could do the difference for you. Copy and paste this code in your manifest (I have already added your SHA1 values):
{"icon.iconset\/icon_16x16.png":"d348589e2cf37d8f23940f8545afe75a2e98b4ac","icon.iconset\/icon_16x16#2x.png":"d348589e2cf37d8f23940f8545afe75a2e98b4ac","icon.iconset\/icon_32x32.png":"e4418a1c5f2ecfbb702961515aaa65d5449b1c53","icon.iconset\/icon_32x32#2x.png":"e4418a1c5f2ecfbb702961515aaa65d5449b1c53","icon.iconset\/icon_128x128.png":"78609fcff69688f969a38f957ac2f10fc79d6732","icon.iconset\/icon_128x128#2x.png":"78609fcff69688f969a38f957ac2f10fc79d6732","website.json":"45be9c4a6f1bf96e27a9eecab219304b35c5ac24"}
I created a small ruby script for generating these manifests based on the code in https://github.com/SymmetricInfinity/push_package/blob/master/lib/push_package.rb.
Copy the script into a directory containing an icon.iconset directory and your website.json. Then you can run ruby gen_manifest.rb inside that directory and the script will write the manifest.json. At the very least it may be a sanity check to see that everything is correct. The script is here: https://gist.github.com/adamvduke/7934457
If you don't have any ruby experience, comment back and I can walk you through it.
Every time when I try to start my mapreduce application (in standalone Hadoop), it tries to put stuff in the tmp directory, which it can't:
Exception in thread "main" java.io.IOException: Failed to set permissions of path: \tmp\hadoop-username\mapred\staging\username-1524148556\.staging to 0700
It ties to use an invalid path (slashes should be the other way around for cygwin).
I set hadoop.tmp.dir in core-site.xml (in the conf folder of Hadoop), but it seems that the config file is never read (if I put syntax errors in the file, it makes no difference). I added:
--config /home/username/hadoop-1.0.1/conf
To the command, but no difference. I also tried:
export HADOOP_CONF_DIR=/home/username/hadoop-1.0.1/conf
but also that does not seem to have an effect....
Any pointers on why the configs would not be read, or what else I am failing to see here?
Thanks!
It's not that the slashes are inverted, it's that /tmp is a cygwin path which actually maps to /cygwin/tmp or c:\cygwin\tmp. since hadoop is java and doesn't know about cygwin mappings, it takes /tmp to mean c:\tmp.
there's an awful lot of stuff to patch if you want to get 1.0.1 running on cygwin.
see: http://en.wikisource.org/wiki/User:Fkorning/Code/Hadoop-on-Cygwin
I found the following link useful, it seems that the problem stands with newer version of Hadoop. I'm using version 1.0.4 and I'm still facing this problem.
http://comments.gmane.org/gmane.comp.jakarta.lucene.hadoop.user/25837
UPDATED: in Mahout 0.7 and for the ones who use the "Mahoot in Action" book example, you shoud change the example code as follows:
File outFile = new File("output");
if (!outFile.exists()) {
outFile.mkdir();
}
Path output = new Path("output");
HadoopUtil.delete(conf, output);
KMeansDriver.run(conf, new Path("testdata/points"), new Path("testdata/clusters"),
output, new EuclideanDistanceMeasure(), 0.001, 10,
true, 0.1, true);