If any core developer has time, please have a look at commits made for http://bugs.freepascal.org/view.php?id=13214 , in particular r18774.
It works as far as I can test, but is that an 'official' way to create parent-child relation between components?
Things such as ReadState override seem hackish to me.

I will close issue in a few days if either no reviews or no problems will be found ;-)

How did you solve the problem of MQ with win32 line endings?

Florian Klaempfl wrote

How did you solve the problem of MQ with win32 line endings?

I did not :-(
I resorted to manually converting files back and forth. It is not hard, but tedious.

By the way, Mercurial mirror seems to be stuck again since r18773. What is the problem with it?

By the way, Mercurial mirror seems to be stuck again since r18773. What is the problem with it?

Here it is at 18780?

So we cannot recommend this really to people :(

Works for me now, too. What is the update interval? It seems some commits appear immediately,
while others lags for few minutes to an hour.

Actually, I think we still can. The DVCS model itself is so powerful that I will probably
use Mercurial for Lazarus even though I can now commit to svn directly and even despite all the warts of Mercurial's interface. See e.g. a comment about patch management I made in issue 13214. Another important thing for me is speed -- just to view a diff for _one file_ for some commit in the history with TortoiseSVN takes from 1 to 10 minutes, depending on file size and connection speed fluctuations.
The blame is so slow it is out of question.
OTOH, with Mercurial both operations are instantaneous, since they are local.

Normally every 5 min, if some update doesn't break python on the machine hosting it as it happened recently.

It should first solve the awkwardness of line ending problem, it feels so rcs/cvs like.

A lot of my diffs were full diffs when trying hg for a small project because of the line ending issue so the fast diffs got useless ;)

Well, the problem for me is actually from trying to use both svn and if one either:
1) Uses only svn
2) Uses only hg
3) Uses both, but without svn:eol-style=native property then all is well.

Recently I even suggested to drop svn:eol-style, but apparently it is important for some Windows users.

> Another important thing for me is speed -- just to view a diff A lot of my diffs were full diffs when trying hg for a small project because of the line ending issue so the fast diffs got useless ;)

Do you know you can fix up commits in DVCS as long as nobody pulled your changes yet? (And even after that, but at a risk of confusing others).
I must admit, however, that the interface for doing that in Mecrurial is bad -- it is much better in git.

I don't see how using only hg should solve this? If someone pushs a commit with mixed/wrong line feeds there is no way to fix this automatically as far as I can see?

I must admit, I work often on a samba share with a windows editor and commit from unix (e.g. on my arm), but with subversion, this works perfectly.

How should it work? The files end up with mixed line feeds or even worse a full diff because a windows editor might add \r to all line feeds?

What do you mean with fix up?

I must admit, however, that the interface for doing that in Mecrurial is bad -- it is much better in git.

En/na Florian Klaempfl ha escrit:

How did you solve the problem of MQ with win32 line endings?

I don't remember how I set it up (it was a while ago), but under windows I have this in mercurial.ini

[extensions]
hgext.win32text=
[encode]
*.pas = dumbencode:
*.pp = dumbencode:
*.lpr = dumbencode:
*.lfm = dumbencode:
*.lpi = dumbencode:
*.lpk = dumbencode:
*.inc = dumbencode:
[decode]
*.pas = dumbdecode:
*.pp = dumbdecode:
*.lpr = dumbdecode:
*.lfm = dumbdecode:
*.lpi = dumbdecode:
*.lpk = dumbdecode:
*.inc = dumbencode:

And nothing under linux.

Bye

[skiped the rest]

Although the posted config did not work for me, I re-researched th problem and now found the solution!

The clue is here:
http://www.selenic.com/mercurial/wiki/index.cgi/Win32TextExtension?action=diff&rev2=9&rev1=8

Notice how even Mercurial documentation authors were confused initially ;-) To recap, stars must be _doubled_ in encode and decode sections, like that: **.pas = dumbencode:

I mean to change so it is not broken any more.
Unlike svn, DVC systems allow to "change history" -- go back and modify old commits.

En/na Alexander Klenin ha escrit:

You're right, I thought it was working but it wasn't, my repository has cr+lf in it :-(

Bye