The Lazarus team is glad to announce the 0.9.28.2 release. This release is based on fpc 2.2.4.

This release can be downloaded from the SourceForge download page: http://sourceforge.net/projects/lazarus/files/

The Lazarus 0.9.28 release had two known issues. This release fixes:
* Fixed compiling a test application without saving (missing project1.lrs)
* Fixed Lazarus directory set by deb package

The following changes are also included:
* Fixed conflicting key definitions related to persistent block
* Fixed quick paste selection
* Fixed endless auto sizing loop when opening project (issue 14862)

The list of changes can be found here:
http://wiki.lazarus.freepascal.org/Lazarus_0.9.28.2_release_notes

Vincent

Vincent Snijders wrote

The Lazarus team is glad to announce the 0.9.28.2 release.

Thanks Vincent. I have updated the Git mirror with a v0.9.28.2 tag as well.

If anybody else is using the Git mirror, your next 'git pull' will get the new tag as well, and you can do local checkouts against it.

http://github.com/graemeg/lazarus/tree/v0.9.28.2

On #lazarus-ide, IRC, somebody said that the fixes_0_9_28 branch was out of sync, is that still true?

Vincent

Vincent Snijders wrote

On #lazarus-ide, IRC, somebody said that the fixes_0_9_28 branch was out of sync, is that still true?

No. The sync (for fixes branch) is not a automated process, but I try and update it once a week (normally Mondays). If somebody urgently needs a fix they can contact me directly or simply cherry-pick the patch they need from "upstream" to there local "fixes" branch. As of 15 minutes ago, the "fixes 0.9.28" branch in Git is synced with SubVersion fixes branch.

PS:
Please note this "manual sync" process in ONLY for the "fixes" branch. Trunk in SubVersion is automatically synced every 15 minutes with Git's "upstream" branch.

Reason for "manual sync" of fixes branch:
-----------------------------------------
Now for the long answer... :-)
* SubVersion does not distinguish between tags and branches.
* SubVersion does not keep a good history of when branches are started and from what commit they started (I think this is fixed in latest SubVersion)
* Git's svn support is not perfect.

So based on the above points I decided to manually sync the "fixes" branch. If I automate the "fixes" sync, then the Git repository grows much bigger than needed because (I think) it actually duplicates patches (commits) for the branch and not reuse them. So I simply get a changelog from my previous sync to current revision in fixes branch. I then cherry-pick those revisions into "fixes". This does not increase the Git repository at all because it reuses the original patch (commit). And yes, I do allow for custom changes in fixes branch, which were not merges (like changing the revision number for a release).

I am interested to hear how long it takes/took to merge this weeks changes. I think in the end automating a bit is worth the effort, unless you can merge the current batch in less than 5 minutes.

Vincent

Vincent Snijders wrote

I am interested to hear how long it takes/took to merge this weeks changes. I think in the end automating a bit is worth the effort, unless you can merge the current batch in less than 5 minutes.

:-) It was a rather large merge this week. It took me 12 minutes - but I haven't had my first cup of coffee yet. ;-)

The longest part of the merge is simply copy and pasting the merge svn revision numbers into gitk so I can search for the git commit revision (SHA1). Then it's simply a right click and selecting "cherry-pick".

I guess I could put a quick script together to automate the above. But normally the merges to fixes branch is small, so I don't mind the few minutes it takes (once a week).

Where do you find what revisions must be merged into fixes branch?

Regards,
- Graeme -

2009/11/16 Graeme Geldenhuys :

Ok. That seems doable for now. It took you less time than me. :-)

I use svnmerge.py avail.

An other version of the output of svnmerge.py avail -log can be seen on: http://www.freepascal.org/~vincents/avail.log

I have written (or am writing) an application to identify which revisions change the same files, so I can group them together in one merge.

Currently there are about 840 revisions to be merged.

Vincent

2009/11/16 Vincent Snijders :

Ok. That seems doable for now. It took you less time than me. :-)

Good to know. :)

I have written (or am writing) an application to identify which revisions change the same files, so I can group them together in one merge.

What if a revision changed more that one file (which happens often)? Wouldn't that cause problems. Also how would that affect me? I use Cherry-pick, which simply applies the original commit to the fixes branch. This allows git users to see where the original commit came from - full history of changes are kept.

Rolling various commits from trunk into a single commit will loose that history? That is why I don't use the standard automated branch tracking in Git for the fixes branch. I use the commit log descriptions in fixes branch to see what the original commit in trunk was, and cherry-pick that original commit.

Not knowing exactly what you application does, but wouldn't that interfere with the commit log descriptions?

Currently there are about 840 revisions to be merged.

Normally I would say: Damn, rather you that me. But in this case, we both do the work. :-)

I see no problem, it just helps me to see that two revisions depend on each other, because they change the same file. (There are of course more dependencies, a new feature in the LCL can be used in the IDE only if the LCL feature has been merged).

If there are two files in a commit, it may create a dependency on other revisions which changes one or two of those files.

Wouldn't that cause problems. Also how would that affect me?

Not at all.

I use Cherry-pick, which simply applies the original commit to the fixes branch. This allows git users to see where the original commit came from - full history of changes are kept.

That is nice.

Rolling various commits from trunk into a single commit will loose that history?

The history is in the log message, as you found out.

It only helps to select revisions, I still use svnmerge.py merge to do the actual merge. So no, it does not interfere.

Vincent

2009/11/16 Vincent Snijders :

> Wouldn't that cause problems. ?Also how would that affect me? to know, thanks. I was simply worried that the commit messages

will change etc if various commits are rolled into one and the commit log description doesn't mention the exact revision where the commit/merge originated from.

It only helps to select revisions, I still use svnmerge.py merge to do the actual merge. So no, it does not interfere.

Excellent, thanks.