![]() ![]() It would be nice if the extension would take note of the existing lineĮndings and automatically convert back and forth between them - see Outstanding changes when you enable the eol extension. Repository, so yes, it can certainly be the case that a file now has The eol extension will *normalize* the line endings stored in the Something like this could possibly explain some of the issues I've > system believe a file has outstanding changing when you've not touched > opposite, where setting a conversion preference can actually make the > more tolerant of differing line endings. > actually result in fewer commits, not more of them, ie. > that setting up a system to handle line ending conversions should > should do may differ from other people's, but I would have thought I expect my idea of what end of line handling hgeol file if you want to override what the repository-native When you say '** = native', you are asking for files to have native lineĮndings in the working copy and *LF* line endings in the repository. ![]() The next commit? I know you cannot really see the change in line endingsīut I think that is more a problem with the diff format. Is this diff now just showing you that the crlf file will be modified by > the following script, with the eol extension active, on Windows (so > The problem, if it is considered to be one, can be reproduced using Apologies for any formatting issues - I'm wrestling with Outlook here whichĭoesn't appear to have the same definition of 'plain text' that the rest of the Something like thisĬould possibly explain some of the issues I've been seeing. Opposite, where setting a conversion preference can actually make the system believeĪ file has outstanding changing when you've not touched it. it becomes more tolerant of differing line endings. Handle line ending conversions should actually result in fewer commits, not more of I expect my idea of what end of line handling should do mayĭiffer from other people's, but I would have thought that setting up a system to > script, with the eol extension active, on Windows (so native = CRLF): > The problem, if it is considered to be one, can be reproduced using the following +++ b/crlf Thu Sep 02 20:51:48 2010 -1,1 +1,1 this is maybe not exactly the same problem as reported by Ben,īut it seems close enough and is annoying on its own. The following script, with the eol extension active, on Windows (so The problem, if it is considered to be one, can be reproduced using Only, in the repository) or a bug in the eol extension. I don't know if this is by design (every file should have LF endings Re-enabling the extension, 'hg status' continues to work as The funny effect is that now the dirstate caches this state, so when Hg status says a file has changes but hg diffĪfter disabling the eol extension, 'hg status' reports no change, as Mercurial appears to do something funny to the line Still reports there as being no difference.) It can’t be going on the Shows changed files but hg diff doesn't!”, and tried the -git flag, but it When I try “hg diff” on thatįile, there’s no change reported. AĬheck with the command line tool shows that the file is indeed there as Identical content, but it shows up in TortoiseHg as having been altered. One of our source generation tools regenerated a file with Secondly, change detection seems not to work the way I wouldĮxpect, and I can’t help but feel that this is related to whitespace or (As youĬan imagine, this tends to muddy the change log and makes annotation difficult.) To each line in the file, indicating the line ending has been altered. Occasion, and occasionally being prompted to check in files with whitespace changes Problem as we are still getting the inconsistency message from Visual Studio on Unfortunately this doesn’t seem to have fixed the ![]() We couldn’tįind why this occurred so we installed the hgeol extension, and set it to makeĪll our source files convert to ‘native’ format, in the hope that Only other tool performing modifications being Mercurial/TortoiseHg. We still edit exclusively in Visual Studio, with the It would appear to be something Mercurial was doing to the files, since nothingĮlse has really changed. That files had inconsistent line endings. Whitespace generally, which myself and my colleagues don’t seem toįirstly, we were finding that Visual Studio kept telling us However, there are persistent problems with line endings, and possibly Have a central repo hosted on Linux which we push to over ssh and we develop on I’ve been using Mercurial on Windows via TortoiseHg onĪ large repository converted from CVS and for the most part it works well. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |