Hi,

It seems the EOL characters keep changing in the .lfm files depending on the platform last used?

For example:
- If I design a form under Windows, I assume the Form Designer uses CRLF as EOL character in the .lfm files.

- Now if I open that exact same file under Linux (note the exact same file, not another one checked out by SubVersion). The Form Designer converts all the EOL characters from CRLF to LF?

This generates a lot of unnecessary noise!

The reason I ask, is because I sometimes find that due to the Form Designer, my patches contain a lot of noise. This happens very often when I use Git or a shared directory between the host OS and a VM OS. The latter two is things I do very often.

This issue seems minimized when using SubVersion on various platforms, because SubVersion silently modifies (yuck) all text files on checkout to match the EOL character used on that platform. Git and a shared directory NEVER modifies files - what's in the repository is EXACTLY what you have locally (which I think is the correct way - but that's a discussion for another day).

What I have also found strange (but better), is that it seems this issue is only affected by the Form Designer. Standard .pas and .pp files edited in Lazarus editor (under Linux or Windows) don't seem to generate that EOL noise when patches are created. Only .lfm files are affected.

Wouldn't it be better if the Form Designer always used a consistent EOL character - no matter what platform? After all, it should only be the Form Designer that edits those files.

Tip to Git users:
-----------------
To those Git users also affected by this issue. You can specify the --ignore-space-at-eol as a parameter to git which will then prevent the unnecessary diff noise due to the Lazarus Form Designer.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

This issue seems minimized when using SubVersion on various platforms, because SubVersion silently modifies (yuck) all text files on checkout to match the EOL character used on that platform.

No, that is not siliently, that is because we told svn so with the svn property: svn:eolstyle = native

Vincent

Graeme Geldenhuys wrote

Wouldn't it be better if the Form Designer always used a consistent EOL character - no matter what platform?

To back up my claim of altering the behaviour of the Form Designer... Many applications and protocols on the internet also use a single consistent EOL character to minimize this issue.

"Most textual Internet protocols (including HTTP, SMTP, FTP, IRC and many others) mandate the use of ASCII CR+LF (0x0D 0x0A) on the protocol level, but recommend that tolerant applications recognize lone LF as well." -- http://en.wikipedia.org/wiki/Newline

So I recommend that the Form Designer standardizes on the CRLF character as the EOL character.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

This behaviour is imo correct? Being flexible when importing files and when exporting save them in the native format?

BTW: Some .lrs files in lazarus/ide miss this property. Furthermore, some have text/plain as mime type, others text/pascal.

To my understanding, lazarus tries to be as native as possible and this breaks with this rule.

Vincent Snijders wrote

No, that is not siliently, that is because we told svn so with the svn property: svn:eolstyle = native

This is an option that must be set when the file is checked in, which means client-side, unless the repository is setup with some "post commit" script to apply those properties.

The point is still that files can slip through, and that often happens. Florian just mentioned such cases too. I even generated a script to run though the tiOPF subversion repository to periodically correct those properties, because other users with commit access do not have the "auto apply properies" rules setup.

The point is, files should not keep changing when checked in or checked out.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Florian Klaempfl wrote

This behaviour is imo correct? Being flexible when importing files and when exporting save them in the native format?

So the repository doesn't truly reflect what you have locally. :-( I guess another one of the hordes of SubVersion limitations.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Just install a pre commit script which prevents checking in files without mime type.

The point is still that files can slip through, and that often happens. Florian just mentioned such cases too.

I guess this are still artefacts from the cvs->svn conversion.

IMO it should. It's the only way to solve the different line ending problem.

Florian Klaempfl wrote

BTW: Some .lrs files in lazarus/ide miss this property. Furthermore, some have text/plain as mime type, others text/pascal.

Thanks Florian. You just proved my point, that mistakes can and do happen in a SubVersion repository.

As I mentioned in my previous reply to Vincent. Setting those properties happen on client-side, and if somebody checks in those files without the proper properties you get inconsistencies with other files.

Bottom line is, the files should NOT be modified by the repository tools. I often use a "share folder" to work in a VM session testing things under Windows, while my host OS is Linux. This means the files will have inconsistent EOL characters even though the files were checkout out (and silently modified) by svn, because I did not check them out again while I worked in my Windows VM.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Florian Klaempfl wrote

Just install a pre commit script which prevents checking in files without mime type.

That's for mime type, but what about eol-style?

BTW:
To help fix this existing inconsitencies in the SubVersion repository, you can use the following script. This is what I use to fix up the *.pas files in tiOPF.

[ Yes you will have to modify it for .pp or .lrs or .lfm or .inc files, but you get the idea ]

========================
#!/bin/sh
for f in `find . \( ! -regex '.*/\..*' \) -type f -name '*.pas'`; do svn ps svn:eol-style native $f
svn ps svn:mime-type text/plain $f
done
========================

I guess this are still artefacts from the cvs->svn conversion.

Florian, you are not helping your case. ;-) Pointing out more and more issues in SubVersion. Anyway, this is not supposed to be a debate about repositories [I think]. I'm talking about files that are normally not edited by humans, like .lrs or .lfm files.

IMO it should. It's the only way to solve the different line ending problem.

Strangely enough the internet works just fine without such silently modifications to web pages, smtp traffic etc... It's all about the tools that can handle the existing text files correctly. Why can't the editor detect the EOL character and use that while editing a file.

Like I said, the Lazarus editor doesn't seem to cause any problems, but the Lazarus Form Designer does. And I am not using SubVersion to access the Lazarus repository, I'm using Git. So some files are fine, but others are not.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

They should. Especially if you have your sources shared with different environments. Svn will change them to on consistent value.

I share my sources between windows, linux and mac machines and I've only problems with files not having that flag.
Note that I only checkin / update on linux.

Marc

Since you are creating a problem which doesn't exist (for years) for the laz developers I don't think that will happen.
And for the lcl it is not an issue, it can read both.

Marc

Florian Klaempfl wrote

To my understanding, lazarus tries to be as native as possible and this breaks with this rule.

This issue is only for non-human edited files, so if Lazarus Form Designer used CRLF on all platforms, it shouldn't make a difference - excepting fixing patch noise.

A quick script to set all .lfm and .lrs files subversion eol-style property to CRLF should fix this too.

By letting SubVersion silently modify files could corrupt sensitive text data files as well. What if I have data files that must stay exactly as is, no matter the platform.

Even the RFC4180 document dictates that CSV files *must* use CRLF as the EOL character, no matter what platform is being used. So checking in such files into SubVersion with eol-style=native would actually corrupt (in theory) those data files.

http://www.faqs.org/rfcs/rfc4180.html

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

This is probably still an artefact from the cvs to svn conversion.

In this case just don't set the mime type to text :)

Marc Weustink wrote

They should. Especially if you have your sources shared with different environments. Svn will change them to on consistent value.

To quote one of my other replies....

Even the RFC4180 document dictates that CSV files *must* use CRLF as the EOL character, no matter what platform is being used. So checking in such files into SubVersion with eol-style=native would actually corrupt (in theory) those data files.

http://www.faqs.org/rfcs/rfc4180.html

I share my sources between windows, linux and mac machines and I've only problems with files not having that flag. Note that I only checkin / update on linux.

Then clearly SubVersion does more trickery when the files are being committed.

If I modify any form under my Windows VM, all the EOL characters have changed. Generating a patch from that (using my git repository) gives a huge amount of unnecessary noise. The last few patches I submitted to Mantis is proof of that. Only today I found out how to resolve that issue, by specifying the --ignore-space-at-eol, but that means when the patch is finally committed and the change does its round trip back to me, I get another set of merge conflicts, so have to undo my local changes and continue the merge. Normally such a patch round-trip would merge perfectly, but not if EOL characters keep changing.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Florian Klaempfl wrote

In this case just don't set the mime type to text :)

Funny that - a CSV file is a text file.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Florian Klaempfl wrote: > In this case just don't set the mime type to text :) Funny that - a CSV file is a text file.

You talked about data files in general. For a csv just set the mime type to e.g. text/csv and svn:eolstyle to crlf and it works on all platforms and nobody can commit an illegal csv.

[...] This issue is only for non-human edited files, so if Lazarus Form Designer used CRLF on all platforms, it shouldn't make a difference - excepting fixing patch noise.

lfm files are human edited.

What .lfm patches are bigger than .pas patches because of the line endings?

What has csv to do with lfm?

Mattias

Marc Weustink wrote

Since you are creating a problem which doesn't exist (for years) for the laz developers I don't think that will happen.

Considering that many projects are flocking away from SubVersion to something better like Git or Mercurial, it might become a problem in the future. You guys already proved that that is possible, after all, you guys already moved from CVS to SubVersion.

I'm simply using my repository of choice (due to better features), but I would also like to continue contributing to the Lazarus project. Such unnecessary issues make it a lot harder for contributors or for the people that need to commit my (and maybe others) patches.

And for the lcl it is not an issue, it can read both.

So then if the Form Designer uses CRLF for .lrs and .lfm files, it shouldn't pose any problem at all making the change. :-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Mattias Gaertner wrote

lfm files are human edited.

Probably by 0.1% of the general Lazarus users. In that case, the Lazarus editor can simply detect that it's a .lfm and always use CRLF when saving it. It already detects the .lfm because of syntax highlighting.

What .lfm patches are bigger than .pas patches because of the line endings?

http://bugs.freepascal.org/view.php?id=13941
http://bugs.freepascal.org/view.php?id=13952

And I was just about to submit another *huge* patch simply because I resized a TGroupBox. Which is when I started investigating the issue and found the problem is the EOL characters.

What has csv to do with lfm?

That it is perfectly acceptable (and practised in the real world) to have some files always adhere to a specific EOL character, no matter what platform is used.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Florian, you are not helping your case. ;-) Pointing out more and more issues in SubVersion.

In which regard? cvs had a poor eol handling which caused a lot of trouble. svn fixes this. However, when converting, the missing eol info had been added by the conversion script but it was missed at certain points and these omissions still pop up.

If git is better you shouldn't have any trouble with line feeding.

it might become a problem in the future. You guys already proved that that is possible, after all, you guys already moved from CVS to SubVersion.

Indeed, cvs was a pain and svn fixed most of the problems as well as adding some usefull stuff and being a superset of cvs. git misses several stuff compared with svn: proper eol handling, blocking of patches from merging, good support of non unix platforms, ...

I don't see a *must* in that document (and confirms my thought that there is *no* CSV standard)

Definition of the CSV Format
While there are various specifications and implementations for the CSV format (for ex. [4], [5], [6] and [7]), there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files. This section documents the format that seems to be followed by most implementations

and

Encoding considerations:

As per section 4.1.1. of RFC 2046 [3], this media type uses CRLF to denote line breaks. However, implementors should be aware that some implementations may use other values.

Marc

Florian Klaempfl wrote

had been added by the conversion script but it was missed at certain points and these omissions still pop up.

I hope the script I supplied helps a bit, or gets you on the right track.

If git is better you shouldn't have any trouble with line feeding.

Remember that my lazarus git repository is feeding off a SubVersion repository. Not ideal, but workable. My true Git repositories have no problems at all - and I do use them from various platforms.

git misses several stuff compared with svn:

As proven before... we agree to disagree on that point. :-)

proper eol handling,

Fixed. Git is more that just a source code repository (ala SubVersion), it is more like a file system with integrity checking all built in. What you put in, is exactly (guaranteed by SHA1 checks) what you will get out. No silent modifications of files. In todays software world, all text programs (editors etc..) should be able to handle any text files with whatever EOL characters. If not, that text editor isn't worth using.

blocking of patches from merging

it's called cherry-picking in git.

good support of non unix platforms, ...

This is old news. The native Windows Git version (I guess you are referring to Windows, because I know that is what you mainly use) works perfectly. I use it without problems in my Windows VM sessions.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

What is so special about .lfm files? The same happens to the pas files, doesn't it? If so, then I can skip the sub thread about csv files.

Vincent

Op donderdag 11-06-2009 om 12:39 uur [tijdzone +0200], schreef Graeme Geldenhuys:

One of the main reasons we still use svn is because those 'better' systems of you can't handle this properly. (As we told you before, and before, and before....)

That's why _you_ have a problem now with line-endings, because your tool doesn't handle this right.

I don't see why we have to fix/change something for a broken tool that you insist to use, but we don't because it's broken in this regard?

Joost.

We used such a script but if you forget about certain extensions, it doesn't help ;)

Tell this unix editor writers (and MS too).

No. It does not prevent that somebody pushes a merge.

What about OS/2, MorphOS, ... ?

Op donderdag 11-06-2009 om 13:20 uur [tijdzone +0200], schreef Graeme Geldenhuys:

Maybe in your -unix-centric- world. But not in the real -windows-centric- world. And we are aiming to build some tools which are really cross-platform. And not with all kind of tricks.

And we want to do this right. This implies conversion from line-endings between platforms. Subversion can do this (because it's build with the same mindset: cross-platform) Git can't, because it's hacked together for one platform. Maybe some people added windows-support later on, but it's not designed to do so, like gcc programs using mingw/(that other framework).

I don't know how others are thinging about this, but I think it would be better when you stop cluttering this mailinglists with all your git-problems and git-promo-talk.

As you said, we aggree to disaggree. You want to use your own tools, then don't bother us with your tool's problems.

Joost.

Op donderdag 11-06-2009 om 12:39 uur [tijdzone +0200], schreef Graeme Geldenhuys:

Then you have to invest time in our toolchain.

I wanted to submit to gdb-archer, and they use git. So I had to set up git. What do you think: should I spam their mailinglist that they should use subversion instead?

The first days I spent searching for a bug, was it a Git-problem. . . I was very mad, you may know that. But it's my own problem. They choose git, not I. (I think they won't use it again, though.) All the branches are bringing more problems then solutions. But they are a special case, they have to stay as close as the official cvs branch, to avoid a complete fork. In principle one of the situations git could be usefull. But it's far from ideal...

Joost

Same goes for pascal files:
Big parts of pas files are created by code completion and I bet most lazarus created pas files are only edited with lazarus. The diff tools handle them both as text files.

I just tested: They are not huge when using svn diff, nor when using diff of the fsf and many other diff tools can ignore line endings. Probably you used your diff tool wrong.

Many csv readers can only handle windows line endings. So the recommendation makes sense.

I don't see this given for lfm.

Mattias

Joost van der Sluis wrote

That's why _you_ have a problem now with line-endings, because your tool doesn't handle this right.

I use the best tool for the job, otherwise we would all be developing software using vi or notepad.

I am NOT suggesting you guys change you repository!!! We have discussed this over and over and over before.... Hence the reason I created and maintain a git clone of the lazarus subversion repository. I am suggesting something which is done often in many other software cases as well, and it is something that will NOT even break any existing code or tools. The .lrs files and .lfm files are probably only edited by a select few humans (probably 0.1% of all cases), so it's not even something that will raise any issues.

I don't see why we have to fix/change something for a broken tool that

Oh please Joost, get off your high horse... Git (and probably other tools) don't believe that silently modifying text files is the right way to go. That does NOT make those tools broken. Git simply believes in integrity! What you put in is exactly what you get out.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Mattias Gaertner wrote

I just tested: They are not huge when using svn diff, nor when using

In the patches I submitted, every single line in the .lfm files have changed, when in fact only a few values have changed. This makes in near impossible for the person committing that patch to actually see what I have changed, before they commit it to the subversion repository.

Probably you used your diff tool wrong.

% <edit some file>
% git diff <== outputs a standard patch format.

or

% <edit some file>
% git add <whetever_file_changed>
% git format-patch HEAD <== generates text files containing patch>

I now found that I can do the following, which ignores the EOL character changes.

% git diff --ignore-space-at-eol

I don't see this given for lfm.

I actually got this mixed up. The original file is in a UNIX format using LF as the EOL character. I also used the editor called 'syn' to convert it to DOS (CRLF) and then back to UNIX (LF). 'git diff' showed no files changed - as expected.

I then opened the .lfm file with Lazarus Form Designer. Changed a value of a button, clicked save. Then changed the value back to what it was and clicked save again. For all intent purposes there should be NO changes. Doing a 'git diff' shows that every line in the .lfm file and .lrs file has changed.

Opening the .lfm file with 'syn' which then shows me the EOL format used, shows DOS (CRLF) and the line-ending type. BUT I am using a Linux version of Lazarus?????

I'm totally confused and this makes no sense at the moment. The files I played around with is

components/filebrowser/frmconfigfilebrowser.lfm
components/filebrowser/frmconfigfilebrowser.lrs
components/filebrowser/frmconfigfilebrowser.pas

What is their eol-style property set at for SubVersion? I would guess it's not set. But that still doesn't explain why my Linux version of Lazarus changes the .lfm and .lrs to use CRLF when everybody else things it uses the native EOL character of your platform - which in my case was LF (before the edit) and is now CRLF after the edit.

See attached screenshots.

BTW:
I did the same test with the .pas file. 'syn' confirmed that it was a UNIX file. I made changes and saved. I then un-did those changes and saved again. 'git diff' reported nothing has changed - which is correct. So the Lazarus editor doesn't fiddle with the EOL characters, but the Form Designer does.

This is what I want (strangely enough), but then all the .lfm and .lrs files in the repository should be converted to DOS (CRLF) line-ending characters to start with and eol-style=crlf should be set.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: before_edit.png
Type: image/png
Size: 1164 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090611/25614014/attachment-0003.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: after_edit.png
Type: image/png
Size: 994 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090611/25614014/attachment-0004.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: after_edit_git_status.png
Type: image/png
Size: 5659 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090611/25614014/attachment-0005.png>

Op donderdag 11-06-2009 om 14:17 uur [tijdzone +0200], schreef Graeme Geldenhuys:

I think most developers have better things to work on, especially when they don't have this problem themselves.

Yes, that's their design. But that design is not suitable when you use different platforms, between which conversion is needed in some cases.

So, wrong tool in our case.

Joost.

Florian Klaempfl wrote

Tell this unix editor writers (and MS too).

If I create a document using OpenOffice under Linux, that document also works fine under Windows and vice-versa. Most editors I know or use can happily edit a text file and keep the EOL style as it was before. No need for conversions.

As for other editors - Like I said, some editors just aren't worth using.

What about OS/2, MorphOS, ... ?

SubVersion has been around for much longer than Git or Mercurial. Give it time. As far as I know, there is already an OS/2 port, but I don't know how far they are. But then again, who still uses OS/2 or... what the hell is MorphOS?

[By the way, I was a BIG advocate for OS/2 in its day and even worked with IBM promoting it at computer shows in South Africa. I even received a gold Team OS/2 badge for my efforts. I almost forgot about that. :-)]

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

\ know how far they are. But then again, who still uses OS/2 or... what <cut> is MorphOS?

http://wiki.lazarus.freepascal.org/MorphOS

Vincent

Vincent Snijders wrote

http://wiki.lazarus.freepascal.org/MorphOS

No Lazarus port yet, though.

Vincent

Joost van der Sluis wrote

Maybe in your -unix-centric- world. But not in the real -windows-centric- world. And we are aiming to build some tools which are really cross-platform. And not with all kind of tricks.

Oh like the tricks to tell SubVersion to convert line-endings and then you sometimes forget to tell SubVersion about that so the repository now sits with mixed EOL style all over the place. Very nice and consistent.

I'm pretty sure you would love it if your NTFS file-system started modifying your data, because NTFS things it's better that way. NTFS doesn't touch your data, neither does Git. Like I said, Git is more like a file-system with integrity checking.

The tools that work with the actual data (editors, IDE's etc) needs to know how to handle the data. That's got f**kall to do with your source code repository, which you entrust to look after your data and keep its integrity in check.

I don't know how others are thinging about this, but I think it would be better when you stop cluttering this mailinglists with all your

As far as I understand, Lazarus is an open source project and I believe I may raise my concerns in this mailing list. I was not the one making this thread about SubVersion vs Git. I was simply raising my concern about the Lazarus Form Designer changing the EOL style in the .lfm and .lrs files, but NOT in the .pas files.

If you don't like what I have to say, stop reading and replying to my messages!

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Vincent Snijders wrote

> http://wiki.lazarus.freepascal.org/MorphOS

Thanks Vincent. Amiga compatible. Amiga was before my time or just not popular in South Africa. :-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Op donderdag 11-06-2009 om 15:10 uur [tijdzone +0200], schreef Graeme Geldenhuys:

I do like it that when I use something like GetLazDefaultConfigPath I get '/etc/whatever' on Linux and 'c:\local users\settings\whatever' on Windows. That's not consistent but very usefull because differences between platforms do exist. You could try to ignore those differences, but that's not how Lazarus works.

If you don't like what I have to say, stop reading and replying to my messages!

Pretty dull would like to work on the stand-alone fcl-web-server. (It's working, btw, only post-data is not handled well in all cases) But I have to write an quotation (Is that the correct English word for the Dutch word 'offerte'?) for a client...

Joost.

If you don't like there changes you probably don't trust them to push to your repository. In that case, you pull from them (which would be my preferred choice). The developer can send you a pull request and you can accept or pick what you want. If the other developer did manage to push something you did not want, kill his access (as he clearly did not listen to you) and undo that specific commit on your side.

The following URL shows 4 different ways of handling specific commits from somebody else.

http://www.gitready.com/intermediate/2009/03/04/pick-out-individual-commits.html

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

It's even about myself :) When making a fix I might find out that it shouldn't go into a fixes branch, so I block this revision for merging. If I don't do so, I (or somebody else I trust) might merge this patch months later and break things by accident.

Graeme Geldenhuys wrote

SubVersion has been around for much longer than Git or Mercurial. Give it time. As far as I know, there is already an OS/2 port, but I don't know how far they are. But then again, who still uses OS/2 or... what the hell is MorphOS?

FWIW: Paul Smedley has updated the OS/2 version of SVN to 1.6.2 and an announcement was made on May 26th about it on the VOICENews list...

[quote]
++ From the VOICE OS/2-eCS News Service http://www.os2voice.org ++

From: Mark Dodel

Paul Smedley has updated Subversion to v1.6.2.
http://www.smedley.info/os2ports/

Subversion is an open source version control system. More information on Subversion can be found at http://subversion.tigris.org/ This updates Subversion for OS/2-eCS to the v1.6.2 source code level.

Subversion 1.6.2 - updated 2009-05-25
http://download.smedley.info/subversion-1.6.2-os2-20090525.zip REQUIRES: libc063.dll - ftp://ftp.netlabs.org/pub/gcc/libc-0.6.3-csd3.zip

Please let Paul know if you find this software useful. He needs user feedback to continue work on these projects. He maintains a bug tracker for many projects at http://mantis.smedley.info It just requires a simple registration.
[/quote]

Wouldn't it be better if the Form Designer always used a consistent EOL character - no matter what platform? After all, it should only be the Form Designer that edits those files.

All files under control of (created and updated by) the IDE should have one neutral format and a neutral language. I also found such files containing user-language dependent comments, what is annoying and can result in unnecessary patches.

DoDi