It seems whenever I compare via the SVN Repository explorer (most recently after a merge) subclipse will show a few files in the compare window that have no differences whatsoever. Double clicking the file brings up the Java Source Compare window, but Subclipse highlights no sections and shows no differences. A manual inspection of the file shows they are identical. What causes this? Are there any ways to disable it, it can be quite confusing?
Your help is greatly appreciated!
Sounds like it could be whitespace-related. Maybe tortoise defaults to ignoring ws changes.
Seems to be Eclipse bug, which waits for solution...
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318826
There may not be structural change, but only space related or formatting. Try clicking on "next difference".
I think the problem is that after merging the revision of the file is changed. So, although the content of files is the same, the compare view shows the change. It is very very bad... :(
Related
I need to figure out how to turn off emphasized items in Visual Studio Code
This might sound like a strange requirement, but in my workflow vscode functions as less an IDE than a cross-platform ViM-esque frontend with lots of remote development tools built-in.
Due to this use case, I don't need or want the linting features to show up in the file browser. How might I accomplish this?
Attempts to solve the problem
I've run out of search terms here and cannot find an answer.
Searches including terms in this question's title yielded little
SO-specific search queries also yielded little
This seems to be somewhat related, at least as a representation of the "feature" I'm referencing: VS code containes emphasized items but no error
VSCode "preferences" do not appear to show what I'm looking for, likely an issue with me not searching for the right variable name.
In my experience with VSCode it has been wonderfully customize-able, so I'm guessing there's a setting somewhere ready to be modified to accomplish this. Any help much appreciated, thanks!
My use case was a bit different: after viewing some files in a git submodule those files became linted, and errors and warnings cluttered up my VS Code Explorer file browser window on files I had no intention of ever handling. I basically wanted a way to clear out those lint warnings, and found it here. The solution is to reload the window:
CtrlShiftP on Windows/Linux, ⌘ShiftP on Mac -- then select "Developer: Reload Window"
One by-product of reloading the window is that it clears out those unwanted warnings (at least until the next time I visit the file). It also has the effect of clearing out warnings on files that I would normally want to see, of course, but chances are I'll be visiting those files again soon, so it's fine. Not a perfect solution, but it works for me and my use-case; hopefully it can help others.
I don't know how to turn it off, but I had this on multiple folders and I fixed it by renaming the folder to a random name, then naming it back to the name it was before and the error would go away.
If you have this issuse then uninstall extention then CtrlShiftP on Windows/Linux, ⌘ShiftP on Mac -- then select "Developer: Reload Window" then type developer: relode page this issuse automatically resovle
i have this issuse then i uninstall extension then this issuse resolve.
I was able to permanently prevent this by adding the files to the .gitignore file. It seems that this happens in a cloned repository when you add new files.
It happened since yesterday that the Author column in the CVS history disappeared in my Eclipse IDE. I have gone through all the menus in Eclipse and all kinds of Google search but couldn't figured out how to add it back. Does anyone have a clue on it?
I am using the latest Eclipse (Helios) on 64-bit Windows 7. I used the following steps to show CVS history: right click the file name under Project Explorer => Team => Show History.
Thanks!
This happened in my eclipse as well. Unfortunately the other answers did not help me but I was able to fix it by manually editing the cvs plugins stored preference.
Close Eclipse.
Go to the path $WORKSPACE/.metadata/.plugins/org.eclipse.team.cvs.ui in your filesystem. Where $WORKSPACE is the directory that has your Eclipse workspace.
Edit the file dialog_settings.xml in that directory.
You should see an item element with the attribute key="COL_AUTHOR" change the value attribute to be non-zero (I set mine to 100). Specifically, the Xpath for the attribute your trying to change is //section[#name="org.eclipse.team.internal.ccvs.ui.CVSHistoryTableProvider"]/item[#key="COL_AUTHOR"]/#value
Start up Eclipse and the problem should be fixed.
This happened to me as well. It turns out that the author column can be completely collapsed in between the 'Revision Time' column and the 'Comment' column. I had to carefully put my mouse cursor on the right side of the divider between the two columns and drag to the right, in effect resizing the author column to not have 0 width. The UI then exposes the author column, which should always be there if the Revision and Comment columns are present.
I have changed my eclipse environment, so have no way to go back to the old one to confirm that. But thanks for the help, and I will keep it in my mind in future.
When I update my local working copy of an SVN repository in Eclipse using the Subversive plugin it isnt bringing any new files which have been added to the SVN repository. It thinks that the local working copy is up to date and if I ask Eclipse to update it it just says no further changes.
Anyone got any ideas why this is happening?
I just discovered this nasty problem too. It might be related to this bug report.
Deleting the entire tree worked for me too, but that hardly seems like a satisfactory solution. What scares me more is wondering how I will notice that a certain file didn't get updated, if this happens again.
Thanks to the above bug report, this worked for me (eclipse 3.7):
Team/Update to Version...
v Update to HEAD revision (=default)
Depth: Full recursive (default is Working copy)
v Change working copy to specified depth (default is un-checked)
O Ignore externals (=default)
v Allow unversioned obstructs (=default)
I do not know if that fixes the problem permanently. At least it seems a faster solution rather than full checkout.
Sorry I don't have a solution to this problem, but I have it as well, and I don't have enough cred to comment.
Here is a thread describing the same issue:
http://www.eclipse.org/forums/index.php?t=msg&th=14710&start=0&
A "workaround" I found to be successful is deleting the relevant tree (of course, backing it up first) and performing an "update". I am prompted to recreate missing files, which bring the un-added files from the repo as well. Obviously this is a terrible solution, but it does work.
Another interesting effect to note is that it is one-sided. The other machine on the repo is perfectly fine with updating new files.
I have noticed Subversive to be a bit problematic. While this isn't a direct solution to your problem, may I recommend using TortoiseSVN (assuming you're in Windows). It works excellently, has more power than Subversive, and is integrated with your shell making it a smooth transition.
I am not sure if anybody has experienced this.
I am working with a very large file having 7000 lines of code.
I made a lot of changes and when i compared the file with the repository version, it showed me incorrect differences.
I guess the diff algorithm buffers only limited number of lines ahead/behind for searching the current line, and on failing to find that, it simply shows diff with current line in new file.
One such snapshot > http://picasaweb.google.com/lh/photo/ENwZ4gqXxiCF3SWqVnVAqA?feat=directlink
If anybody knows any workaround, please let me know.
Thanks
Easy workaround - use another diff tool. I'm serious. I wouldn't waste time splitting up my files, or wondering how to get it to work with Eclipse's diff tool if there's some known issue with really big files.
I recommend Beyond Compare 3. I say this having used many different diff tools. It's not free, but it's worth it. In the rare chance that it gets confused, it allows you to with a couple of clicks realign any areas that it got confused on. I have used it with some pretty large files, and it rocks.
If you're concerned about Eclipse integration, there's even a plugin, BeyondCVS, that allows you to launch your Beyond Compare diffing from the Eclipse right click 'Compare' menus. Its name is kind of misleading though, as it doesn't appear to be related to CVS.
If you need something free, try one of these diff tools instead:
WinMerge
SourceGear DiffMerge
What version of eclipse are you using? And what edition? (Java? CDT? ...)
Depending on those data, it could make a difference, since files with several thousand lines are known to be a problem for the diff algorithm.
See this thread for illustration.
And do check, as mentioned in the same thread, your error log to check if any particular message could help you to pinpoint the cause of the failed diff.
Is Eclipse's undo history broken? I have been using 3.1, 3.2, 3.3, and now 3.4 versions for the last few years and was always able to undo only about 20-25 changes back in history.
This nonsense has cost me some lost modifications countless times when trying to revert some recent changes (if you reply with "you should commit to svn every 25 changes", I'm going to unleash dragons on you).
There's a setting in Preferences->Editors->Text Editors->Undo history size and I set it to 1000 but it didn't help anything.
I'm mostly using Eclipse with the Perl E.P.I.C. in the Perl Perspective, if it matters.
So guys, what's the problem and how do I fix it?
I'm experienceing the same problems and I am also using Eclipse with EPIC.
It seems this is a known issue with EPIC, see http://sourceforge.net/tracker/index.php?func=detail&aid=1728227&group_id=75859&atid=545274
Reported in 2007, so I'm surprised it hasn't been fixed :(
Edit: Yay! This is now fixed in EPIC version 0.6.37
Testing show that for low values of the property it does indeed work - I'm using the Java Editor.
Perhaps you can try and see if the Java Editor respects those settings - I'm too lazy to make > 50 changes and undo, and if it does file a bug against E.P.I.C.?
Not a direct answer, but Eclipse maintains a local history of edited files (Context menu -> Restore from local history). Maybe that would be a better way than going back 25 steps in the undo-history.