Since some time ago, when copying text from UTF-8 enabled terminal windows (on Windows!) into a GitHub issue (from Web browser), seem to remove the newlines (\n), causing all text to become one very long line. This is a sudden and highly annoying issue, that I am not able to resolve.
I am sure sure the text as copied has not changed for years, since I have been using the same various terminals and Windows and pasting into all other places such as other programs and web sites, work fine.
Q: Any idea what is going on?
(I have also tried to find a way to report the issue to github, but since the MS acquisition, there is no longer a sensible way to report bugs!)
Other SO posts have suggested to use this repo for tracking, but still require you to send email.
(Who the heck uses emails for bug reporting these days!?)
Today, our team once again stumbled upon old bugs being resolved with LATER or REMIND, and it's high likely that we'll forget about them soon again. Both of these non-resolutions tend to get out of sight when mixed into resolved bugs. The Mozilla team itself agreed on removing them [1] for their installation and many other projects have followed since. Using LATER and REMIND is merely a source of confusion.
So also we decided to disable[2] them:
Administration > Field values > Resolution
for both values: unchecked property enabled for bugs
But they don't disappear from the user interface for bugs. Is it broken, have I to delete the values instead? What am I doing wrong?
[1] The discussion has held in 35839 – REMIND and LATER considered harmful to bugzilla.mozilla.org
[2] deleting them seemed not to be appropriate due to the already existing bugs
Now (after having changed the language from German to English for asking here) I tried it again, and the values aren't available any more. I suffered probably only from a caching effect.
When we click the check box "Install files for complex script and right to left languages (including Thai)" in Regional and Language settings what exactly happens?
Changes to registry keys?
I noticed that it installs some .fon files and keyboard dlls.
Is this totally necessary if one just wish to read complex script on Windows XP? My test inside VirtualBox as Windows 7 as the host OS seems to indicate that for reading Complex Script need not be enabled. Yet that's not what all the literature on the subject says. What's going on?
Update:
http://hi.wikipedia.org should not be readable if Complex Script is not enabled
http://hi.wikipedia.org/wiki/विकिपीडिया:Devanagari_Help
Problem is that it is readable.
Font files. Rendering libraries ('Uniscript'). Input methods. Certainment beaucoup de cle-registry. (Certainly lots-o-registry-keys.)
Note that IE will tend to get things right even when other things don't, since it builds in a good deal of fancy-pants rendering. Try, oh, Outlook, or some simple sample Win32 program.
Whenever I alter (or even just resave without altering) a Perl file, it completely takes down our backend. I have no idea what the problem could be. Permissions are correct. Encoding is correct. Encoding is UTF-8. Transfer mode was ASCII.
I might not deal with Perl too much but I have no idea what the problem could be. The network admin hosting our website has no idea what the problem could be.
Text editors I tried: Dreamweaver, TextMate, Vim
Operating systems I tried: Mac OS X, Linux (Ubuntu)
FTP clients I tried: Transmit (Mac), Filezilla (Linux (Ubuntu))
It's not that it's bad code, I even tried to open and solely save and my backend still goes down.
The network admin told me that he ran the files through a dos2unix converter and it worked immediately. I of course tried this and it did not, more so it wouldn't make any sense, since I tried this in some of the most respected editors and I don't think it would make such drastic changes to the file type without any user input. (when I say respected editors Dreamweaver is not included in that sentiment).
I personally think it is some sort of server-side issue because I have crossed my t's and dotted my i's in regards to any possible client side issue but I have tried everything. Any opinions as to what the root of this problem is, and any possible solutions? Thanks in advance.
Try setting binary mode in your FTP client. That will allow you to experiment with different line endings (dos2unix) on the client side, without worrying about them being translated during transfer.
I've had this problem in the past and line-feeds were indeed the culprit.
Your editor and/or FTP program may be mangling the linefeeds.
Running dos2unix on the server is a good test as to the problem but not the cause.
Generate an MD5 hash of the file after each step in saving and transport to find where it changes.
You do not say what kind of framework/server you are using.
Maybe the server reloads the file while it is still being written by FTP or whatever? (I.e. that the file is not complete when the server reads it?)
Will a server restart fix the problem once the file is uploaded?
It sounds like you are using dos2unix before the transfer but the network admin is using it after. Perhaps it's doing something different in that case.
How many lines are in the file? What is the file size before and after you save it, after you transfer it, and after transfer and running dos2unix on it?
If this is just a line ending problem, you might point your network admin at http://www.perlmonks.org/?node_id=586942.
Response to rebra: No frameworks are used, and I don't know what kind of server this is on. This is basically a one man project on a shared host which was pretty horribly maintained and I'm trying to clean house.
Yeah that does make sense and I asked the server people about that, one of my first questions actually, but even if that is the case, I can't reboot via Plesk (kind of like cPanel). But thanks for that, you put into technical words/explanation what I was thinking of the whole time.
I asked a couple of coworkers about AnkhSVN and neither one of them was happy with it. One of them went as far as saying that AnkhSVN has messed up his devenv several times.
What's your experience with AnkhSVN? I really miss having an IDE integrated source control tool.
Older AnkhSVN (pre 2.0) was very crappy and I was only using it for shiny icons in the solution explorer. I relied on Tortoise for everything except reverts.
The newer Ankh is a complete rewrite (it is now using the Source Control API of the IDE) and looks & works much better. Still, I haven't forced it to any heavy lifting. Icons is enough for me.
The only gripe I have with 2.0 is the fact that it slaps its footprint to .sln files. I always revert them lest they cause problems for co-workers who do not have Ankh installed. I don't know if my fears are groundless or not.
addendum:
I have been using v2.1.7141 a bit more extensively for the last few weeks and here are the new things I have to add:
No ugly crashes that plagued v1.x. Yay!
For some reason, "Show Changes" (diff) windows are limited to only two. Meh.
Diff windows do not allow editing/reverting yet. Boo!
Updates, commits and browsing are MUCH faster than Tortoise. Yay!
All in all, I would not use it standalone, but once you start using it, it becomes an almost indispensable companion to Tortoise.
I always had stability issues with AnkhSVN. I couldn't switch everyone to Subversion where I work without an integrated solution.
Thank goodness for VisualSVN + TortoiseSVN.
VisualSVN isn't free, but it is cheap, and works a treat.
I tried version 1, and it was unreliable to say the least. I can't say anything about 2.0.
If you can afford it, the one I use, VisualSVN, is very good and uses TortoiseSVN for all its gui, except for the specialized things related to its VS integration.
#pilif: AnkhSVN maintains an in-memory state of the working copy, which is invalidated/updated by Visual Studio events (ie you edit/change a file) and AnkhSVN events (ie you commit/update/revert/etc)
Whenever the working copy is changed from outside Visual Studio (by editing with another tool, or by using another Subversion client), you will have to refresh AnkhSvn using the Refresh command we provide.
The other thing that happens when you delete a file in a project with TortoiseSvn for example, is that it remains listed in the project file, and you will have to remove it there seperately (and then commit the project file as well).
Copy/Pasting parts of my own Blogpost, as I switched from Ankh to VisualSVN:
Why did I switch? Because i was a bit unhappy with the overall stability of Ankh, since it has some problems actually tracking Solution changes. VisualSVN is “just” a TortoiseSVN Frontend, which means it leaves all the “heavy lifting” to a third-party tool that a) is installed on most Workstations anyway and b) that’s been tested and used by such a wide audience, it’s really rock-solid.
Now, AnkhSVN is certainly not a bad product, and the people behind it are serious about what they are doing, but having long-deleted files still in my SVN or getting the “Please Cleanup your solution” message get’s annoying after some time, but my biggest gripe is the property window. It’s nice that there is a nice window with Radio Buttons asking me which property I want to add. Unfortunately, there is no way to manually enter a property.
Edit: That was for AnkhSVN 1.x. In the meantime, it was updated to 2.x and much improved. I use it in production on a system where I don't have VisualSVN and it works extremely well now.
I had no problems with v1, but I was warned not to use it. I've been using v2 for a while, and I've had no problems with it. I still keep a backup of the repository though...
I started with AnkhSvn and then moved on to VisualSvn. I have my own gripes with VisualSvn but its far less trouble compared to Ankh. I'm yet to try the new version of Ankh which they say is a complete rewrite and had inputs from Microsoft dev team as well.
I've been using both the newest version of Ankh SVN and Tortoise on a project at home. I find them to both be very good with a caveat.
I've found that both SVN tools have at times failed to keep up with my file/folder renaming and moving resulting in it thinking that a perfectly good file needs to be deleted on the next commit. This is probably down to me misusing SVN in some way but TFS at work does not have this problem.
I tried AnkhSVN (1.0.3, just 4 months ago), and it did not work the way I wanted it to (i.e. needed to select things in the browser window instead of based on active file). I ended up making some macros that utilize TortoiseSVN that work much more like what I expected.
I've been very happy with using TortoiseSVN via explorer and my macros inside the IDE.
Earlier on (like 2 years ago when I last tried), AnkhSVN and Tortoise used in parallel with the same working copy caused some kind of working copy corruption where Ankh and Tortoise somehow lost track of the state the other tool left the working copy in.
It was as if one of the tools stored additional metadata not contained in the working copy and was reliant on that being correct.
The problems showed themselves by Ankh (or Tortoise) insisting on files being there which weren't, on files being changed which weren't and on files not being changed which were (and thus unable to commit).
Maybe this has been fixed since, but I thought I'd better warn you guys.
About a year ago me and a buddy used AnkhSVN for a project... several commits later while moving namespaces around, it broke the SVN repository. Broke as in, the last commit we did got corrupted, and we couldn't commit anymore.
After that we used TortoiseSVN and did the namespace moving manually, it just... worked. If you're only working on base class libraries you could always try using SharpDevelop instead (that integrates with TortoiseSVN).
I do hope they did fix AnkhSVN now though because IDE integrations always rock... when they work.
#mcintyre321
I've found that both SVN tools have at times failed to keep up with my file/folder renaming and moving resulting in it thinking that a perfectly good file needs to be deleted on the next commit.
A move or rename operation results in an delete and 'add with history' at subversion level.
TortoiseSvn shows this as:
originalFile deleted
newFile added (+)