Quiet simply I am trying to add new files to my repository, my command goes like this:
svn add * --force
but this produces:
svn: File 'install/config.xml.php' has inconsistent newlines svn:
Inconsistent line ending style
The thing is that this file is not yet under version control, so when I try to propdel or anything similar it doesn't work.
I am sure this file is not under version control because svn status shows this:
? install/version
? install/config.xml.php
I have already enabled the autoprops in svn default config but this did not help.
Any ideas?
Btw: this is a server, so no GUI.
vim makes it easy to force line endings to entirely CRLF or entirely CR.
:set ff=unix
:wq
d2u, dtox, dos2unix, are some names for simple utilities that are often installed on systems to do this task. You could also use the standard tr(1) utility:
tr -d '\r' < input > output
While working on Windows OS use Notepad ++:
Edit -> EOL Conversion.
- Windows Format
- UNIX/OSX Format
- Old Mac Format
You have current format information in the status bar.
Related
I'm trying to configure OpenSwan, an open source IPsec solution written in C.
I have a script to download a configuration file ipsec.conf on an Amazon Linux EC2 that was created on my Macbook and uploaded to S3.
When I start the ipsec service, it segfaults.
Curiously, if I open the configuration file with VIM, make no changes, and simply write/quit, it works. This lends me to believe somehow the file has some weird characters/formatting.
I know of dos2unix, which I ran on the configuration file but that did not prevent the segfault.
I'm wondering what exactly VIM is doing when I write/quit. I could script that operation on my configuration file after pulling it. Or anything else that would help me understand what's going on.
First, try to open the file with vim, then exit vim (:q) without having saved the file before. If vim says File modified since last complete write; write or use ! to override., this means that this is not something that vim does when write/quit that changes your file, but that this is something that vim does when it opens the file. And this is the most common case.
Vim parses the input file depending on the locale, and if some characters can not be understood according to the locale, vim may forget them. So, when saving the file, those characters will be removed.
Now, use vim to save your file as ipsec-ok.conf.
And run the following command:
bash -c 'diff <(od -xa ipsec.conf) <(od -xa ipsec-ok.conf)'
This will display the differences between the original file and the one that works with OpenSwan. In ascii and hexadecimal formats. This way, you will find the unsupported characters that make OpenSwan dump a core.
Im using a windows system to push my changes to a git linux server, where users commit with macOS, could this be the problem of invalid diff changes? changes which are not changes are displayed as deleted and later on re-added as new somehow. im using sublime and also tryed netbeans with the same behaviour...
Windows and *nix based operating system use different line ending character in files. In your case you are adding the Windows Carriage return character in your file and on MacOSX they are removed.
On your Sublime you can change the line ending character on save to match the MacOSX's line ending . See is there a way to convert files line ending on saving. This way you will not see these changes.
You could also instruct git to automatically do the conversion with the core.autocrlf config. See GitHub dealing with line endings
GitHub suggests that you should make sure to only use \n as a newline character in git-handled repos. There's an option to auto-convert:
$ git config --global core.autocrlf true
Of course, this is said to convert crlf to lf, while you want to convert cr to lf. I hope this still works …
And then convert your files:
# Remove everything from the index
$ git rm --cached -r .
# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add
# Commit
$ git commit -m "Fix CRLF"
As Per Git Config Manual
core.autocrlf
Setting this variable to "true" is almost the same as setting the text
attribute to "auto" on all files except that text files are not
guaranteed to be normalized: files that contain CRLF in the repository
will not be touched. Use this setting if you want to have CRLF line
endings in your working directory even though the repository does not
have normalized line endings. This variable can be set to input, in
which case no output conversion is performed.
The remote repo has mixed cr/lf lineendings, thought it was unix, now i just set the original lineending if it happens again.
I have this line of code in .vimrc :
au BufRead *.xlsx exec "echo 'xxx'"
And when I open a .xlsx file in vim 7.3 ( I know it's weird to open such a file in vim ), it did echo xxx to me.
But after I upgraded vim to 7.4 and did the same thing, it didn't echo anything to me now.
I've tested it in several machines getting the same result, so I wonder what feature in 7.4 causes this , and what can I do to make it echo what I want like before?
I see that you've figured out the culprit already in the comments (thanks Ben!).
This is caused by version v27 of the zip plugin that ships with Vim 7.4. Its change log reads:
(Jason Spiro) provided a lot of new extensions that are synonyms for .zip
And in fact, the new MS Office file formats (ending with x) are all XML-based ZIP files (whereas the previous ones were in a proprietary binary format).
Fortunately, the plugin allows to override the default file extensions that are considered. You can remove the Office ones from the following list and put that into your ~/.vimrc:
:let g:zipPlugin_ext= '*.zip,*.jar,*.xpi,*.ja,*.war,*.ear,*.celzip,*.oxt,*.kmz,*.wsz,*.xap,*.docx,*.docm,*.dotx,*.dotm,*.potx,*.potm,*.ppsx,*.ppsm,*.pptx,*.pptm,*.ppam,*.sldx,*.thmx,*.xlam,*.xlsx,*.xlsm,*.xlsb,*.xltx,*.xltm,*.xlam,*.crtx,*.vdw,*.glox,*.gcsx,*.gqsx'
I use perforce for my revision control, when I hit 'p4 change' it always opens up the list on emacs, and we all know the pain of deleting text in it. How do i change it to gedit or vim or anything else? My default text editor is gedit.
On the command line, set P4EDITOR either as an environment variable or in the P4CONFIG file.
From the command line,
p4 set P4EDITOR="C:\File Editor\editor.exe"
You can test that this was successfull by running the following command after, which should launch your desired editor.
p4 workspace
I had similar problem on my Windows system.
It always used to open clumsy notepad.
I am more comfortable with TextPad, so to change default perforce editor, I made following changes:
I opened System Properties and added new environment variable as following:
Name: `P4EDITOR`
Value: `C:\Program Files (x86)\TextPad 4\TextPad.exe`
After that open a new CMD and there you go !!!
For Notepad++ I needed to use this command -multiInst to trigger edits.
p4 set P4EDITOR="C:\Program Files (x86)\Notepad++\notepad++.exe -multiInst"
Try setting the EDITOR environment variable. Also, the command line p4 should have an option to specify an editor. Also, the .p4config file might have something as well.
Also need to check if EDITOR/P4EDITOR path is correct. If path is wrong, perforce will choose previously working editor.
In the case of WSL, likely your p4 binary is provided for Windows platform as the path and operations are most compatible there, so it's p4.exe most likely. Then simple wawy of setting editor in P4EDITOR is not just enough, we have to convert input argument of filepath which is provided in Windows-based into Linux path.
This solution dated back 19 years ago still works
The concept is to
Create a bash/shell script that accept the argument.
Then in the script we can use wslpath $1 to convert Windows path into Linux path.
The script can be just
#!/bin/bash
vim `wslpath $1`
I thought I might not be able to use Vim to edit change, or client spec of perforce and have to end up using whatever provided like Notepad (not against it, but I just want to use Vim). This solution works for me.
I'm using a windows PC and editing files checked out from SVN, which has files checked in using DOS.
I use cygwin and when I either create a new file or patch a file using cygwin binaries the file format is unix. Really I need to always use DOS format for these so my colleagues are not inconvenienced.
Is there any way I can have cygwin use DOS format for say a bash session?
I appreciate I can run unix2dos against such files but this is a pain - I'd rather just have them as DOS to begin with if possible.
You can make SVN do this conversion for you automatically. Check out propset and the eol-style option:
http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5
This will make the files always have the newline sequence native to the platform on which you checked out the files (i.e., you may get them in LF and the other ones will have the same files with CRLF):
svn propset svn:eol-style native put-your-filenames-here
You can choose the UNIX or DOS file format during the installation of cygwin.