With BC2, when i click the Show differences... option in SourceGear Vault. It allow me to copy from the repository to the working version and save but I can't do this with BC3. It doesn't allow copying to the otherside (right) and have the editing disabled showing at the bottom of the BC3. It is even the same with DiffMerge. What am I not understanding here?
Can someone explain to me why the changes in BC3 and is there a workaround?
Beyond Compare will disable editing of a file for any of the following reasons:
It's one of the input files in a 3-way merge
The comparison was cancelled
The comparison encountered an error (corrupt file, invalid character encoding, out of memory, gamma rays, etc)
The file format's conversion settings don't support converting back to the original format (MS Word, PDF)
The file is on a read-only "filesystem" (7zip/RAR/CHM archives, CD/DVD-ROMs)
A file or parent folder had editing explicitly disabled by the user in the session settings or using the /ro command line switches
The viewer itself doesn't support editing (eg, Hex Compare prior to v4)
Also, the Full Edit (F2) toggle in the Text Compare View menu switches between inline editing and line-based mode. If it's disabled you can copy/delete whole lines and type in the line details edits at the bottom of the window, but the main windows won't have a cursor, typing is disabled, and it will always select whole lines. Unlike the above items, this doesn't show "Editing Disabled" in the status bar.
there must be a flag on the command line to call BC such as /ro# or /#ro or /(side)readonly (where side is left or right), it prevents editing.
these flags are there because differs are often called with temporary files to diff, in particular from SCC. and Vault probably has a single "external diff" command, thus you have to choose whether the flags are always there, it protects you from unexpectly editing a temporary file and loose this work when closing the diff tool, or not.
The few reasons I have found are:
If the encoding of the file is different than the default. In this case change the encoding to the expected one. (Japanese-ShiftJIS in my case)
If a refresh of files is in progress.
Related
I'm on OSX and running Version 1.42.0 of Visual Studio Code. I have noticed that when I single click a word it will highlight. But if I copy CMD + c and then paste CMD+v, the full line will be in the clipboard. This causes problems from time to time, when the screen has given me every indication that I have only selected a single word. Is there some setting that I can set that will make the default behavior to select a word on a single quote and never ghost select a full line?
What it looks like when I single click a word:
And what it looks like after I've copied and pasted:
After filing an issue, it turns out that this behavior is by design.
The word the cursor is on (from a single click) is highlighted along with every occurrence of that word. The word is not selected (that would be a deeper blue).
By default copying without a selection copies the current line.
This in my opinion is an Accessibility issue, as there are strong visual clues that a word is selected. I have found that the behavior can be made more intuitive if you set these to settings.
// Controls whether copying without a selection copies the current line.
"editor.emptySelectionClipboard": false,
// Controls whether the editor should highlight semantic symbol occurrences.
"editor.occurrencesHighlight": false
With these two settings the word the cursor is on will not be highlighted (nor any other occurrences of that word). And if you do happen to copy, with an empty selection, the editor will behave similar to how other applications behave and not copy the current line.
I spent a significant amount of time trying to apply a scientific conference paper template, made in Microsoft Word, that I want to document this problem (and my eventual solution), in case someone faces a similar difficulty (and in case I forget how I did it, I can refer back to this). In this particular case, the conference template was this, but I think many conferences and journals offer similar templates, so this question should have fairly broad interest.
The question is, given this template (which is really not a template in the MS Word sense), how can I create a document that uses the styles defined therein? How can I sure that when I save the document, it will not revert back to some other style definitions defined in Normal.dot?
In MS Word, "templates" are defined in .dot, .dotx, or .dotm files. The .dotx and .dotm formats are for newer versions of Word and the difference lies in whether Macros are disabled or enabled. Despite this definition, some organizations (such as conference organizers or journal publishers) will supply a .doc (or .docx, etc.) file, also calling it a "template" and asking you to use the styles and other formatting elements defined in it. If you were to start editing this file directly and then save it, you might be surprised that the next time you open that document, some of the styles may differ from what you saw when you were initially editing the document. This is because of a clash between the style names provided in the initial file and your Normal.dot template, which is the default template that your instance of MS Word uses. Here are the steps you need to do to avoid this problem:
When you first open the "template" supplied by the conference organizer / journal publisher, immediately save this file as a Word template by choosing "Save as" from the Office button (or File-> Save as... in older versions) and selecting .dot, .dotx, or .dotm in the "Save as type" field. Furthermore, you should save this in "Templates" folder for your installation of Word. In most versions, there is a shortcut to this folder in the top of the left panel of the "Save as" window. Give the file some name like "MyConferenceTemplate.dot".
Next, close the .dot (or .dotx, etc.) file that you just saved. This will help avoid that inadvertently that editing the template.
Create a new document (by clicking Office button->New or similar). On the left panel of the window that opens, select "My Templates...". You should then see the template which you created in step 1. Select this as the template to apply to your new document.
Start editing the newly created file and applying the desired styles...
I am using Beyond Compare 3.3.4.
I want to compare a large number of files and ignore unimportant differences.
In Session -> Session Settings -> Comparison tab, the "Requires opening files" section has a "Compare contents - Rules-based comparison". This does what I want when I open each file individually. The "quick test" section doesn't have this option. How do I apply rules-based comparisons to my "quick test"?
EDIT:
I am having the same problem as the original poster here. The answer given was "You can change this by going to the Session menu and changing your Comparison Criteria to use Rules-based content". Problem is, the "Rules-based comparison" is under the "Requires opening files" section, so this doesn't work. How do I fix this?
This answer describes the behavior of 3.3.4 (and 3.3.8) for Windows 32-bit, which seems to automatically report folder results as if I'd opened each file, as long as I have my session settings correct.
To perform a comparison that ignores unimportant differences, it is necessary to compare the file contents. BC3 can't know if line endings are the only difference (for example) unless it scans the contents for line endings. Therefore, you must set the "Compare contents" checkbox under the "Requires opening files" section. By doing so, the folder comparison automatically scans all file contents, I don't have to open each one individually.
A "quick test", by definition, is based solely on directory information like timestamp and size. It is quick because it does not open nor read the files; so if quickness is what you desire in a comparison, it cannot be rules-based. The concepts are incompatible.
You can see whether a "quick" or "contents" comparison has been run for any pair of files in a folder-compare window by looking at the middle column. If it is blank, only a quick test has been run; if there is an icon, a contents test has also been run.
That icon will be a black ≈ ("almost equal") symbol, two wavy lines, when a "Rules-based comparison" has detected only unimportant differences. The files themselves will be black and treated as matching if you have "View > Ignore Unimportant Differences" active, otherwise they'll be red or gray and treated as mismatching.
For the meaning of each possible icon, here is the relevant section from the Beyond Compare 3 help file:
Please find below screenshot. Hope this will help.
I have a bizarre problem: Somewhere in my HTML/PHP code there's a hidden, invisible character that I can't seem to get rid of. By copying it from Firebug and converting it I identified it as or 'Zero width no-break space'. It shows up as non-empty text node in my website and is causing a serious layout problem.
The problem is, I can't get rid of it. I can't see it in my files even when turning Invisibles on (duh). I can't seem to find it, no search tool seems to pick up on it. I rewrote my code around where it could be, but it seems to be somewhere deeper in one of the framework files.
How can I find characters by charcode across files or something like that? I'm open to different tools, but they have to work on Mac OS X.
You don't get the character in the editor, because you can't find it in text editors. #FEFF or #FFFE are so-called byte-order marks. They are a Microsoft invention to tell in a Unicode file, in which order multi-byte characters are stored.
To get rid of it, tell your editor to save the file either as ANSI/ISO-8859 or as Unicode without BOM. If your editor can't do so, you'll either have to switch editors (sadly) or use some kind of truncation tool like, e.g., a hex editor that allows you to see how the file really looks.
On googling, it seems, that TextWrangler has a "UTF-8, no BOM" mode. Otherwise, if you're comfortable with the terminal, you can use Vim:
:set nobomb
and save the file. Presto!
The characters are always the very first in a text file. Editors with support for the BOM will not, as I mentioned, show it to you at all.
If you are using Textmate and the problem is in a UTF-8 file:
Open the file
File > Re-open with encoding > ISO-8859-1 (Latin1)
You should be able to see and remove the first character in file
File > Save
File > Re-open with encoding > UTF8
File > Save
It works for me every time.
It's a byte-order mark. Under Mac OS X: open terminal window, go to your sources and type:
grep -rn $'\xFEFF' *
It will show you the line numbers and filenames containing BOM.
In Notepad++, there is an option to show all characters. From the top menu:
View -> Show Symbol -> Show All Characters
I'm not a Mac user, but my general advice would be: when all else fails, use a hex editor. Very useful in such cases.
See "Comparison of hex editors" in WikiPedia.
I know it is a little late to answer to this question, but I am adding how to change encoding in Visual Studio, hope it will be helpfull for someone who will be reading this sometime:
Go to File -> Save (your filename) as...
And in File Explorer window, select small arrow next to the Save button -> click Save with Encoding...
Click Yes (on Do you want to replace existing file dialog)
And finally select e.g. Unicode (UTF-8 without signature) - that removes BOM
Good file comparison tools were already discussed to the pain, but my problem is more exotic. Is there any visual text comparison tool (like WinMerge) that would allow me easily do visual comparison on two sections within the same file?
I have multiple configurations within vcproj file and need to maintain them. It is a pain to do this manually -- splitting windows, scrolling character-by character. On top of that xml is very verbose and takes lots of screen real-estate. I cannot believe there is no tool to do automatic file section comparison, since this sounds like a very common problem.
Please, do not offer me to use property pages, I do not want more complexity, I want less. Splitting manually into files and then comparing them is also too medieval (I am doing this now anyways).
I use Beyond Compare (not free, but I think a shareware version is available). You can select the same file for left and right sides, then right-click the beginning of your section on each side and select "Align Manually". This would allow you to compare two sections of the same file relatively easily.
Overall, I highly recommend the product. I haven't tried version 3, which is what they currently have on their Web site, but version 2 is a fabulous tool. A+
Emacs Ediff.
I use UltraEdit for most of my text editing and they have a product called UltraCompare that does a visual compare.
Update by Mofi
UltraCompare Professional supports also a comparison of text snippets in addition to entire files.
After starting UltraCompare, select Text Compare in menu Mode if not already selected. Select in text editor the first text block which should be compared, press Ctrl+C, switch back to UC and paste with Ctrl+V the block into left text area pane. Switch again to text editor, select the other block in same file, press Ctrl+C, switch back to UC, click into right pane and paste the block with Ctrl+V. The two blocks are immediately compared and the differences are displayed.
Such a text snippet comparison for two blocks in same file can be started also directly from within UltraEdit. Select the first block in file, press Ctrl+C, Ctrl+N, Ctrl+V and Ctrl+A to copy, paste and reselect this block in a new file. Select the second block in file. Execute command Compare from menu File in UltraEdit with option Compare selected text automatically being enabled and click on button Compare. UC Professional is started with just the 2 selected blocks for comparison.
You can use Meld to do this
Open up meld without specifying file names
Meld with prompt which type of comparison you want. Choose file comparison
Meld will present the the icon to select the file names. Below that it will prompt for a Blank comparison. Choose that.
In the file comparison window, paste the sections of the file you want to compare.