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
