I just reviewed r15401:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=15401

I think it would be better to revert it and apply the changes from r14005, so that it can be merged more easily.
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/nobj.pas?r1=14004&r2=14005

Vincent

Op 2010-06-10 13:45, Vincent Snijders het geskryf:

I think it would be better to revert it and apply the changes from r14005, so that it can be merged more easily.

Can I simply change the 'lEquals' to 'aequals' in a new commit, or must one do some r14005 cherry-pick (I don't know the SVN equivalent)?

What is the coding standards in FPC? This is very unclear. I'm used to naming local variables as lMyVar (l prefix) and method parameters as AMyVar (A prefix), so using 'equals -> aequals' as a local variable name is strange to me.

Regards,
- Graeme -

There are no official coding standards. Just one important guideline: don't change someone else's code style "just to change it".

Michael.

No, that will still conflict.

or must one do some r14005 cherry-pick (I don't know the SVN equivalent)?

And I don't know what "cherry picking" is. r14005 has to be reverted, and then the entire branch should be brought up-to-date by merging everything from trunk. You can also merge single revisions (is that what cherry picking means?), but eventually that branch has to be merged back into trunk so it's better to keep it completely in sync.

What is the coding standards in FPC?

In general: http://wiki.freepascal.org/Coding_style

As you'll notice, many things are not defined, such as identifier naming. There are no fixed rules for those things, but it is recommended to keep things similar as the surrounding code (e.g., not introducing identifiers with camel case if the rest of the code uses all lowercase).

There are no conventions in FPC for naming parameters or local variables according to a particular pattern.

Jonas

Op 2010-06-10 14:13, Michael Van Canneyt het geskryf:

There are no official coding standards. Just one important guideline: don't change someone else's code style "just to change it".

OK thanks. I knew about that rule, and just to be clear, that wasn't the reason for r15401.

Regards,
- Graeme -

Op 2010-06-10 14:17, Jonas Maebe het geskryf:

And I don't know what "cherry picking" is. r14005 has to be reverted, and then the entire branch should be brought up-to-date by merging

I take it you meant r15401. "cherry picking" is taking the same commit from another branch and merge it into the current branch you are in. All the original commit information (author, date, comment etc.) is transferred. Now git log, merge, diff etc know where the new commit originated from and will not conflict.

I looked in the SubVersion Red-Book doc and from that I think one can use the standard 'svn merge -r' command, but I don't think SubVersion tracks all the details like git. Anyway, it doesn't matter.

My knowledge of SubVersion has degraded rapidly. Could somebody with more knowledge/confidence of SVN bring cpstrnew branch in sync with Trunk. I'll hold off on further commits I have for cpstrnew branch until then.

naming. There are no fixed rules for those things, but it is recommended to keep things similar as the surrounding code (e.g., not

OK, will do.

Regards,
- Graeme -

Well.

After all these years, first time I find out about this page. Luckily I follow the style as described there :-)

Michael.

Graeme Geldenhuys wrote

My knowledge of SubVersion has degraded rapidly. Could somebody with more knowledge/confidence of SVN bring cpstrnew branch in sync with Trunk.

The merge commands are very simple:

svn merge <path to trunk> (either an url or a local checkout) <resolve conflicts>
svn resolved <files that had conflicts>
svn ci

The harder part was resolving the conflicts. The merged version has been committed in r15421, I hope that I didn't break anything (I only checked make cycle on Darwin and cross-compiling the win32 rtl).

Jonas

Op 2010-06-13 14:35, Jonas Maebe het geskryf:

svn merge <path to trunk> (either an url or a local checkout) <resolve conflicts> svn resolved <files that had conflicts> svn ci

Thanks, I made a note of that.

The harder part was resolving the conflicts. The merged version has been committed in r15421, I hope that I didn't break anything

I'll give it a try later today. Thanks.

Regards,
- Graeme -