In my post Alfresco Community Bugfixing I stated
I wish we (as the community) had something — a system and/or process to support our bugfixing needs. A place to exchange community release (bugfix) patches.
Alfresco Community Manager Jeff Potts and me agreed that the root “problem” are two flavors (Community and Enterprise) of core alfresco code and the fact that community contributors have no easy way to “commit and share”.
Meanwhile I’ve been experimenting a bit, and I think the outcome is ready to try out for people feeling comfortable working with sources. The solution introduced here is based on git
(hub) and git-svn
. The latter is only required if you want to deal with subversion HEAD source from the official Alfresco Community repository as well.
The whole setup may also work for other Open Source projects where there is only a community read-only repo available. Due to the possibilities it introduces, git(-svn)
may even prove to be helpful in the case where all you have is an ordinary svn
repo. I for one am moving entirely to git
– wrapping svn
where needed.
Subscribing to Bugfixes
At this time, the git repository has three branches (3.4.c-fixes, 3.4.d-fixes and 4.0.a-fixes) and three tags (3.4.c, 3.4.d and 4.0.a). As the names suggest, the tags correspond to the svn release revisions (r24514, r25020, r30857) and the respective branches are for bugfix maintaince only.
If you are just interested in subscribing to bugfix-only sources, all you need to do to hook up is
git clone git@github.com:deas/alfresco.git
To obtain the latest version of a certain branch, execute the following
cd alfresco git checkout 4.0.a-fixes git pull
Incorporating Official Subversion HEAD
If you want the latest source from the official subversion repository as well, you can link it in like so:
cd alfresco git checkout 4.0.a git svn init http://svn.alfresco.com/repos/alfresco-open-mirror \ -T alfresco/HEAD git update-ref refs/remotes/trunk 4.0.a git svn fetch git checkout -b svn-head git svn rebase
Now, you are on a new (local only, up to date) branch svn-head
. You may see a few warnings Couldn't find revmap ...
, but those are not a real problems.
Cherry-Picking Bugfixes
Not everybody can or wants to work through code (possibly with a debugger) to fix a bug. Sometimes you don’t have to. ALF-10840 is an example. Well in fact I worked through the code fixing it myself in this case, but this example still shows how to fix a bug in the sources without actual coding. :)
This is what worked here:
git checkout svn-head git svn rebase git log
There, you’ll find commit 534ab26f191bb3fbef8bc0b05d5f13911112f106
mentioning “Fix for ALF-10840”. If you know the svn
rev, you can just as well run
git svn find-rev r31335
to find out the corresponding git
commit-id.
With the commit-id at hand, you can cherry-pick the bugfix into the 4.0.a-fixes
branch.
git checkout 4.0.a-fixes git cherry-pick 534ab26f191bb3fbef8bc0b05d5f13911112f106
Done – sources are now ready for compilation with the bugfix rolled in.
Final Words
Of course sometimes you won’t find a fix in svn HEAD
and you have to do the heavy lifting yourself. Things may also get a bit messy when you want to introduce official fixes in sources you have already touched. Still, it should not be too hard – git revert ...
and interactive rebasing are your friends.
I am in no way the official bugfix maintainer for Alfresco Community releases and I won’t be tracking Alfresco JIRA for fixes in general. For the time being, I will only be fixing bugs that affect me.
But I would definitely appreciate people joining a collaborative bugfix approach as that may save us all some time and give us better software. Just drop me a line if you’d like to be added as a contributor (repo write access).
Update Okt 27, 2011:
Tags and branches have been updated to 4.0.b.
Update Dec 17, 2013:
Unfortunately, it proved to be easier for me to implement fixes as drop-in extension code in most cases. Even though I think this approach is somewhat broken, that’s how things are for now. Given that, I will commit fixes to this repo only if the “fix as extension approach” does not work for some reason.
Resources: