jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Launay <sebastien.lau...@anyware-tech.com>
Subject Re: Branch and backports management
Date Mon, 31 Aug 2009 09:31:22 GMT
Hi,

Le 30/08/2009 11:07, Jukka Zitting a écrit :
> Yes, that's preferable. You can commit simple things like typo fixes
> or javadoc updates without an issue reference, but in general all
> non-trivial changes should have an entry in the issue tracker and the
> commit message should refer that issue.
>   
That's what i thought.
> We're using the merge tracking feature introduced in Subversion 1.5.
> The basic workflow is to commit the fix to trunk first (unless the
> issue is specific to a branch) and then use the "svn merge" command to
> merge that change to a branch. Alternatively you can simply commit the
> fix in trunk and mark the related Jira issue as fixed for the next
> patch release. The release manager is responsible for checking that
> all (and only) the issues marked for a patch release have been merged
> to the respective maintenance branch.
>   
Ok, i'm familiar with svnmerge wrapper program.
> Yes, though normally we only apply bug fixes to release branches.
>   
IIUC if the merge can not be done automatically, we can update the
release branch manually and then mark the trunk commit as
"already" merged using:
*|svn merge|*|* -*|*|-record-only -r 10000
# where 10000 is the trunk commit revision
in order to avoid merging it again later.
|*
> Note that currently we have two active branches 1.x and 1.6. The 1.x
> branch is there in case we still need to do a 1.7 release based on JCR
> 1.0 and some new features or improvements that can't be made in a
> 1.6.x patch release. It's preferable if any backports from trunk are
> first merged to the 1.x branch and from there to the 1.6 branch. That
> way we can keep the merge tracking records clean.
>   
I did not know there was a 1.x branch to keep in sync.
I understand this branch can be useful when a 1.7 might see the
light of day.
But this branch may also be created from 1.6 when a new release
branch is really needed in order to avoid multiple backports
from branches to branches.
We often have this kind of debate in our enterprise, i just
want to have your position on that.
> The Checkstyle profile in jackrabbit-core/checkstyle.xml is probably
> our most strict style definition, but we haven't been too religious
> about it. We generally follow the standard Java coding conventions
> from Sun (with spaces instead of tabs for indentation) but don't worry
> too much about finer details. See also JCR-97 for the catch-all coding
> style and the good discussion in the comments.
>   
Ok

--
Sébastien Launay

Mime
View raw message