| Author |
 Topic  |
|
|
chjfth
Junior Member
24 Posts |
 Posted - Nov 06 2006 : 04:07:55 AM
|
I'm suffering from a bad behavior of VC++ 6 IDE:
First, under linux, I checkout my source files from SVN repositories, and those files has LF(line-feed) as eol-style.
Second, I will edit the checked-out files in VC++ IDE(through Samba sharing).
Finally, when I save the edited file, the file gots CRLF and LF mixed in it. i.e. CRLF appears at the lines that I have edited with VC++ IDE.
Now the trouble: when I use 'svn commit' to try to commit the edited file, SVN spouts the error:
====
svn: Inconsistent line ending style
====
SVN's requirement for consistent eol-style seems really picky at first thought, but I later found it fairly reasonable. SVN can recognize three kinds of eof-style: CRLF, LF, and CR. If your text file contains a lot of scrambled CR and LF bytes, then for a specific CR,LF pair, how can SVN determine it represents a single line or two lines.
Therefore, my prefered behavior is: when a text editor saves a file, it should always use only one eol-style. The unique eol-style to be used can be deduced as:
* default: follow the first eol marker seen in the file,
* if user explicitly required a certain eol-style to be used, follow the user.
And here comes the question of how to delimit text lines when a lot of scrambled CR and LF are encountered. For my opinion, a MS-Windows based text editor should:
1. When a CR if seen, check next byte:
1.1 If the next byte is LF, then this CR/LF pair concludes a new line,
1.2 If the next byte is not LF(may be CR again), then the single CR in step 1 concludes a new line.
2. When a LF is seen, it itself concludes a new line as well.
Can VisualAssistX's future version help VC++ IDE save eol-style-unified text files? Thank you in advance.
|
|
|
feline
Whole Tomato Software
United Kingdom
18941 Posts |
Posted - Nov 06 2006 : 09:01:04 AM
|
I am under the impression that you can configure Samba to do the line feed conversion for you, we used to use Samba at my old job, but I was never involved in actually setting up the shares, so my knowledge of this is rather limited.
The newer IDE's have better options for controlling the line feed format in files, so any change in VA would be VC6 specific. This would require either monitoring every single edit VC6 makes, or some sort of "clean up the file now" command, neither of which is an appealing prospect.
In the short term finding a quick and easy work around is probably the best solution. A Samba fix would be ideal, since it would be totally transparent. You should be able to write a sed command to fix the line endings, certainly I have cleaned up line endings often enough in VIM 6. |
zen is the art of being at one with the two'ness |
 |
|
|
chjfth
Junior Member
24 Posts |
Posted - Nov 06 2006 : 09:17:46 AM
|
| Sigh, a samba fix(if exists) is not my desired anyway, because storing LF-delimited text files on Linux volumes is not always what I expect, -- this time because I may sometimes checkout .dsp an .dsw onto a Linux volume and open them by VC++ IDE, -- as you know, CRLF is required by VC6 .dsp & .dsw files. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18941 Posts |
Posted - Nov 06 2006 : 09:49:14 AM
|
I have edited VS2003 and VS2005 projects from a shared UNIX directory, but never VC6 projects, so my experience is not quite the same.
One quick test later, editing a UNIX format code file VC6 with VA disabled, and VC6 is setting the new line to be Windows format, regardless of the file format. So this is definitely a VC6 limitation, rather than a VA bug *sigh*.
When I used to use CVS on the UNIX command line all the time we had a set of simple scripts wrapped around it, the main example being "update". This command ran "cvs update" and piped the output through a (from memory) sed command, which inserted the escape sequences to colour code each line, depending on its status, "new", "changed", "updated", "conflict".
Are you running SVN on the command line? If so is wrapping the SVN commit command in an alias / batch file an option? On paper it sounds fairly easy to run all cpp / .h files through an awk command to strip out all CR characters.
I am aware this is not the ideal solution, but if we can get this working then you have a solution now, rather than waiting an indeterminate time for a possible code fix in VA.
Based on a bit of experimentation and a quick web search the following sed command *should* work:
sed 1,$s/\\x0d//g unix_format_code.cpp > unix_format_code2.cpp
Unfortunately it is not doing anything when run under Windows using the GNU Windows sed command. The new file is identical to the original file. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
18941 Posts |
Posted - Nov 06 2006 : 09:53:41 AM
|
From this web page http://homepage.smc.edu/morgan_david/CS41/lineterminators.htm
There are supposed to be the two commands:
dos2unix - converts text files in Windows format to unix format
unix2dos - converts text files in unix format to Windows format |
zen is the art of being at one with the two'ness |
|
|
|
chjfth
Junior Member
24 Posts |
Posted - Nov 06 2006 : 8:32:13 PM
|
Thank you for your tip. According to your tip, I really have to find out whether SVN's core library has a commit hook functionality, and I'm better off if it is really implimented in SVN's core, since I may use TortoiseSVN or sometimes svn command line(from Windows or Linux) to do the commit.
However, I'm still expecting eol-style-unified text files when C++ source are saved. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 06 2006 : 9:23:29 PM
|
case=270 will fix what VA inserts into the text buffer based upon the first eol it sees (what I mean is that once fixed, VA will not fix scrambled line-endings but will use the convention already present in the file as determined by the first line)
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Dec 19 2006 : 8:59:15 PM
|
| case=270 is fixed in build 1543 |
|
|
|
chjfth
Junior Member
24 Posts |
Posted - Jan 06 2007 : 10:49:51 AM
|
| I've tried VAX 10.3.1543.0 today. Unfortunately, it seems not to behave as sean has said on Nov 06,2006. I create a pure LF-style text file on my Windows PC(on local disk, not remote samba mount), open the text file in VC6(VAX enabled of course), and insert some text lines then save it. But the inserted lines still end with CRLF, and those untouch lines end with LF intact. |
|
|
|
chjfth
Junior Member
24 Posts |
Posted - Jan 06 2007 : 10:54:25 AM
|
| I've tried VAX 10.3.1543.0 today. Unfortunately, it seems not to behave as sean has said on Nov 06,2006. I create a pure LF-style text file on my Windows PC(on local disk, not remote samba mount), open the text file in VC6(VAX enabled of course), and insert some text lines then save it. But the inserted lines still end with CRLF, and those untouch lines end with LF intact. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18941 Posts |
Posted - Jan 06 2007 : 6:48:24 PM
|
The bug fix applied to VA inserting autotext, and has been confirmed by at least one other user as working correctly.
Unfortunately VC6 on its own does not handle UNIX format files. If you disable VA completely in VC6 and then repeat this text you get exactly the same problem. So any editing you do, even without VA, in VC6 will introduce Windows format lines into your file.
The newer IDE's will respect the file format when editing, and this is where the VA bug fix will show up.
If you are working across a Samba mount you may be able to configure Samba to do the line ending conversions for you transparently. I am aware of the concept, but don't actually know how to achieve this myself. |
zen is the art of being at one with the two'ness |
|
|
|
jcoders
Starting Member
1 Posts |
Posted - Feb 06 2007 : 4:33:47 PM
|
Hi,
I was following up on the topic at hand and wanted to share some insight i had.I suffered with the similar problem svn:inconsistent line ending, and used a text editor to convert the line delimmiters.
quote:
Originally posted by chjfth
I'm suffering from a bad behavior of VC++ 6 IDE:
First, under linux, I checkout my source files from SVN repositories, and those files has LF(line-feed) as eol-style.
Second, I will edit the checked-out files in VC++ IDE(through Samba sharing).
Finally, when I save the edited file, the file gots CRLF and LF mixed in it. i.e. CRLF appears at the lines that I have edited with VC++ IDE.
Now the trouble: when I use 'svn commit' to try to commit the edited file, SVN spouts the error:
====
svn: Inconsistent line ending style
====
SVN's requirement for consistent eol-style seems really picky at first thought, but I later found it fairly reasonable. SVN can recognize three kinds of eof-style: CRLF, LF, and CR. If your text file contains a lot of scrambled CR and LF bytes, then for a specific CR,LF pair, how can SVN determine it represents a single line or two lines.
Therefore, my prefered behavior is: when a text editor saves a file, it should always use only one eol-style. The unique eol-style to be used can be deduced as:
* default: follow the first eol marker seen in the file,
* if user explicitly required a certain eol-style to be used, follow the user.
And here comes the question of how to delimit text lines when a lot of scrambled CR and LF are encountered. For my opinion, a MS-Windows based text editor should:
1. When a CR if seen, check next byte:
1.1 If the next byte is LF, then this CR/LF pair concludes a new line,
1.2 If the next byte is not LF(may be CR again), then the single CR in step 1 concludes a new line.
2. When a LF is seen, it itself concludes a new line as well.
Can VisualAssistX's future version help VC++ IDE save eol-style-unified text files? Thank you in advance.
|
|
|
|
mmb
Senior Member
42 Posts |
Posted - Feb 07 2007 : 05:49:35 AM
|
chjfth: We used a slightly changed plugin for VC6 that solves this problem "the simple" way. It hooks the save command of the VC Editor, reads the file, convert it accordingly to some rules like extension/directory and saves it again.
The problem is, that the file is not converted in memory but on disk, so:
1.) VC detects a change after every save and ask to reload. It can be configured to reload automatically, but then you lose you undo buffer :-(
2.) The hook seems to be not synchronized, in some rare cases the plugin cannot write to file because it's still locked (maybe this happens only on a Samba share) ...
Search for Strip'em or mail me and I will send you my "enhanced" version.
Currently we checkout separately in Windows and Linux, then SVN/CVS converts the lineendings for you ...
And compiling on local FS is much faster in Windows ...
|
|
|
|
bugfix
Tomato Guru
Germany
324 Posts |
Posted - Feb 07 2007 : 11:09:53 AM
|
compiling on local fs is always faster, this has nothing to do w/ windows:)
anyways..
id make a plugin that hooks create/writefile and closehandle using http://research.microsoft.com/sn/detours.
-in hooked createfile check if filename is e.g. h or cpp file and add returned handle to a list/array.
-in hooked writefile check if handle is in your array/list and convert lineendings as needed
-in hooked closefile remove handle from array/list
easy, eh?:) |
http://www.mf-sd.de |
|
|
|
feline
Whole Tomato Software
United Kingdom
18941 Posts |
Posted - Feb 07 2007 : 1:15:24 PM
|
I am reminded of the observation that any job is easy, so long as someone else has to do it 
This question comes up now and then, so being able to point people at a solution would be nice. I just wonder about possible conflicts with other processes that want to track file access, e.g. anti-virus programs, desktop search programs, etc. I have very occasionally seen anti-virus programs upset VA so I know this is not a totally theoretical risk, but hopefully it is a small one. |
zen is the art of being at one with the two'ness |
|
|
|
bugfix
Tomato Guru
Germany
324 Posts |
Posted - Feb 07 2007 : 3:48:48 PM
|
if it wasnt for vc6 i might have done it. im still wondering how many use that old thing w/ it crappy compiler, glad at MS dropped support for it long ago!
another way might be using svn pre-commit-hook script, havent looked at that though or you do some perl/python or whatever script which you run locally before committing.
anyhow just some thoughts |
http://www.mf-sd.de |
|
|
|
feline
Whole Tomato Software
United Kingdom
18941 Posts |
Posted - Feb 08 2007 : 09:21:32 AM
|
We get a lot of support questions about VC6, so based on this it is still very popular.
I have suggested people look into pre-commit scripts / calls before as a good solution for this. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
|
|
Feature req: preserve eol-style when saving files
