QL / PASCAL

[NormanDunbar]

TT moves in mysterious ways.

Cheers,
Norm.

[Chain-Q]

@NormanDunbar
I merged your sysutils patch in r49306. Good job.

The patch you provided also contains the mt_inf() signature change, which I still ignored, for the reasons I explained earlier.

[Derek_Stewart]

Hi,

This maybe a beginners question here, if I apply the the patch locally from a diff file, will svn know this patch has been applied, when an svn update is applied?

[NormanDunbar]

The patch you provided also contains the mt_inf() signature change, which I still ignored, for the reasons I explained earlier.

Apologies. I could have dworn I fixed that already. Obviously not. I will do so ASAP.


Cheers,
Norm.

[NormanDunbar]

if I apply the the patch locally from a diff file, will svn know this patch has been applied, when an svn update is applied?

If you apply the patch, svn update will not overwrite it. I'veapplied two svn updates since creating the patch.

However, if you apply the patch and someone else updates the code in/around the same lication in the file, you will get a conflict. That will prompt svn patch to prompt you for an action. One option is to view all options. Pick that then choose how to continue from the list.

I've had one conflict (in 6 files) during one svn update. I resolved it by letting the new file overwrite my changes, then checking and re-applying my changes manually -- by retyping. Not the most efficient method, but it worked fine.

When/if Chain-Q merges my changes, a future svn update will apply them to your copy of the official code.

HTH

Cheers,
Norm.

[Derek_Stewart]

Hi Norm,

I have been reading the ebook: Version Control with Subversion, from the Freepascal web site, I can follow the instructions, but still trying understand the concepts.

So much to learn, not enough time to try it all?

[NormanDunbar]

Have fun Derek!

By the way, my latest changes have been merged into the main project:

NormanDunbar
I merged your sysutils patch in r49306. Good job.

If you run svn update, you'll get them automagically, aslong asthe version number listed at the end is equal orhigher than r49306. (Which will need the new vlink version 16h too.)

Cheers,
Norm.

[NormanDunbar]

Ok, it seems that the RenameFile() function was working correctly. It was my test code that was broken. trying to rename a file from 'ram1_before.txt' to 'after.txt' without the 'ram1_' on its name. Duh!

So, RenameFile() is working fine in that it:

• Renames a file correctly.
• Fails to rename if the "to" filename is invalid.
• Fails to rename if the "to" filename already exists.
• Fails to rename if the "to" filename is on a different device.

So, the code in FPC.patch.7.zip which included this function, is valid and works fine. As previously mentioned by Chain-Q, I'd neglected to revert back the function header for MT_INF in qdos.inc. The latest update (run svn info) which is version 49335, has that already applied. So, if svn info gives you a revision number less than that, run svn update to pull in the latest code.



Cheers,
Norm.

[Chain-Q]

Norman, the FPC_patch.8.zip you attached only contains a 0 bytes file. Is this intentional?

[NormanDunbar]

Interesting!

I removed the attachment after finding that the latest revision already fixed mt_inf's parameter types and came up with zero changes. I wonder why it's back again.

Attempting a further removal......done, it is gone properly now.

Cheers,
Norm.