Hi,

How does the FPC developers manage the 2.3.x (up coming 2.4) branch? Is it similar to the the Lazarus "fixes" branch, where fixes are applied to trunk and then merged back into "fixes" branch. Or does it more often have it's own development fixes which are NOT available in trunk?

I ask because I would like to track the upcoming 2.4 branch in Git as well as the 2.5.x (trunk) and just want to optimise my SubVersion -> Git sync scripts.

Regards,
- Graeme -

Normally everything is committed first to trunk and then merged.

Jonas

Yes.

Or does it more often have it's own development fixes which are NOT available in trunk?

No.

Jonas Maebe wrote

Normally everything is committed first to trunk and then merged.

Excellent, this makes my job much easier. Thanks.

Regards,
- Graeme -

Jonas Maebe wrote

Normally everything is committed first to trunk and then merged.

Just to confirm, the branch I need to look at is "fixes_2_4" correct?

Regards,
- Graeme -

Yes.

Jonas

Graeme Geldenhuys wrote

I ask because I would like to track the upcoming 2.4 branch in Git as well as the 2.5.x (trunk) and just want to optimise my SubVersion -> Git sync scripts.

Just to let you all know, SubVersion branch "fixes_2_4" is now available in the Git mirror as branch "fixes_2.4".

To view repository via a Web Browser:
http://github.com/graemeg/freepascal

Git clone url:
git://github.com/graemeg/freepascal.git

You don't need to do anything extra if your already cloned the Git mirror or FPC. On your next pull, the "fixes_2.4" will be pulled as well. I am using "cherry-pick" to keep the fixes_2.4 in sync with SubVersion, so patches from trunk are reused in the Git fixes branch (which adds very little overhead and size).

Regards,
- Graeme -

Graeme Geldenhuys wrote

mirror or FPC. On your next pull, the "fixes_2.4" will be pulled as well. I am using "cherry-pick" to keep the fixes_2.4 in sync with SubVersion

But still allows patches directly committed to the fixes_2.4 branch?

Vincent

Vincent Snijders wrote

But still allows patches directly committed to the fixes_2.4 branch?

Yes, I will detect those and apply accordingly. This is why I asked how the "fixes" branch is _normally_ handled. If svnmerge is used - it is simply less effort for me. :-)

Sidebar:
The reason I use cherry-pick is because it gives a more optimised repository, and results in less to clone/pull. I could use the usual 'git svn' to manage the branch, but then git doesn't know that it was actually merges from trunk (via svnmerge) and it acts as if it was normal development commits (no relation to other development branches). Cherry-pick keeps the relationship between branches - including the original commit author etc. More work for me (until I can figure out how to automate this), but I prefer it this way.

I'm now using fixes_2.4 as our default FPC benefits:
* I help test the FPC 2.4 before it gets released
* Fixes 2.4 branch is guaranteed to be in sync with SubVersion.

Regards,
- Graeme -

For fixes_2_4 we use the native merge facilities of subversiob 1.5+

Problem is that often merges are no real merges because the patches don't apply and need manual editing.

Florian Klaempfl wrote

For fixes_2_4 we use the native merge facilities of subversiob 1.5+

Ah, that explains the different format 'merge comment' in each commit message. :-) As long as the commit message mentions "merge" and what revision was merged, it makes things pretty easy for me.

Problem is that often merges are no real merges because the patches don't apply and need manual editing.

In that case I'll probably get a merge conflict at witch point I'll grab the diff directly from SubVersion. That shouldn't be much of a problem. Thanks for the heads-up though. ;-)

Regards,
- Graeme -

Just to let you all know, SubVersion branch "fixes_2_4" is now available in the Git mirror as branch "fixes_2.4".

Thank you!