Intellij: how to keep existing end-of-line styles when saving?
We have a file with mixed EOL styles (from hex viewer, how happened?)
0A \n
0D 0A \r\n
When saving the existing file with one-line change, many lines are changed on disk (from svn diff).
svn diff
Noted that some lines are added (no deletions). svn diff has a bug.
svn stores file diff(s) in repository. If svn diff has a bug, will the repository be actually corrupted?
svn diff -x "-w --ignore-eol-style"
gave me correct result.
My question is that: how to keep existing EOL styles (mixed in the file) when saving and prevent generating invisible diffs?
Here is a related issue on YouTrack:
https://youtrack.jetbrains.com/issue/IDEA-171699/Keep-differents-lines-separators-in-the-file
Feel free to watch it in order to be notified once it has updates. See this article if you are not familiar with YouTrack.
Related
Is there a common mechanism to hint at IDE formatting like indentation (xxx spaces or tabs), and if yes, how well is it supported ?
I have seen something like that a while ago but I am unable to find back the name, it is a file you put at the root of your project.
Format: .editorconfig file, as suggested in the comments by jonrsharpe, is the thing I was looking for.
The file used by stackoverflow as an example.
Support: Beware that some IDEs still have no native support for this and a plugin is required http://editorconfig.org/#download
Concerning line length, there is some ongoing discussion.
In case you use git, some behavior can enforced via:
.gitignore (ignore some files)
.gitattributes (can enforce line endings)
So I would pretty much recommend to have .editorconfig and if you use git .gitignore and .gitattributes files at the root of your project.
Any other suggestions ?
I use GIT and what I constantly see is that git shows that entire SomeModel.jpr contents were removed and replaced with the same contents. File stays the same. Well sometimes something changes and you miss it in whole soup.
Build JDEVADF_11.1.2.3.0_GENERIC_120914.0223.6276.1
This is probably a problem with your git configuration. I saw this to when I worked on a Windows system and git is configured to use only line feed as line terminator. Check your git settings and play with the line terminator settings (auto or leave as is).
Is there a way that I can review the changes made to a file?
Basically, someone has logged onto my server and made unauthorized changes to a file, this has taken down a whole site. I want to see what the file read before the changes were made. The server is a standard install of centos and apache.
Unfortunately, this file lives outside of the svn (it's a config file).
If the person used copy and cut in vim, and didn‘t clean the registers afterwards, you might find remnants of the changes with :reg in vim.
Which might at least make it easier to identify some parts of the file that were changed.
In vim7.3 there is a setting that allows you to undo changes between sessions. You have to have in your .vimrc the following
set undofile
if you vim did not have this setting there is no hope to recover what the original state of the file before editing it with vim.
If it was set then you can just type u in vim to undo the changes there were made.
The is a vim plugin, gundo, that allows you to have a nice visualization
of the past state of the file (again, you would have to have the option set, and the file were the changes are kept would have to exist).
I'm trying to convert an existing SVN repository to GIT using git-svn clone but versioned files with special characters in the filename like "ö" are showing as "ö" after migration. Obviously, git-svn saves the filenames "as is" - I assume that SVN stores filenames in UTF-8 (as done with the logs), but my Windows uses windows-1252 encoding.
Is it possible to force git-svn to change the filename encoding? Didn't find anything in the manuals.
Unfortunately there seems to be a issue with msysgit: http://code.google.com/p/msysgit/issues/detail?id=80
Although, git in Cygwin doesn't have this issue.
I was wondering if I right click on a file in the SVN repo browser, does it get permanently deleted? can it be recovered?
This question/answer from the SVN FAQ might interest you :
How do I completely remove a file from the repository's history?
There are special cases where you
might want to destroy all evidence of
a file or commit. (Perhaps somebody
accidentally committed a confidential
document.) This isn't so easy, because
Subversion is deliberately designed to
never lose information. Revisions are
immutable trees which build upon one
another. Removing a revision from
history would cause a domino effect,
creating chaos in all subsequent
revisions and possibly invalidating
all working copies.
The project has plans, however, to
someday implement an svnadmin obliterate command which would
accomplish the task of permanently
deleting information. (See issue 516.)
In the meantime, your only recourse is
to svnadmin dump your repository, then
pipe the dumpfile through
svndumpfilter (excluding the bad path)
into an svnadmin load command.
If it's that hard, there are little chances it can be done easily from Tortoise SVN...
(And it's not the goal of Source Control...)
You'll find that you can only delete from the Repo Browser when you are viewing the HEAD revision. This is identical to deleting a file from your working copy and then checking in the delete. In both cases, you'll be able to restore from the previous revision.
Deleting a file via the repo-browser context menu basically creates a new global revision where just that file was deleted, so it appears in the log as such - you can always revert to that revision to get the file back, or you can just pull it directly from the repository into your working copy.
No... Deleting a file (even using the repo browser) only affects working copies. It would be a pretty lousy revision control system if you couldn't recover a file from the past. It is actually pretty difficult to modify files in a committed revision, even if you have root access to the server.
Doesn't right-click just bring up some sort of menu? And with SVN is that you can always revert anyways.
I deleted a top level directory from Repo Browser by accident and the only way to get it back was the following:
Export the top level folder from a previous version history
Make a new folder in the repository to replace the one deleted.
Add the exported files back to the new directory (same name as previous)
Update the working copy, it will delete and then re-add the same files.
Its annoying but at least the working and repo will be back in sync. The "Revert Changes from this Revision" didnt work for undoing repo deletes, it only reverts in working directory not the "Undo" the delete to the repository.