On Fri, May 24, 2013 at 12:05:19PM +0200, San Martino wrote:
> We already use branches, but we use/justify them for developping long
> features or bug-fixes which require some time and are not urgent.
> In many cases, however, we must urgently fix small, short and important
> bugs and release everything immediatly.. We act on trunk directly for this
> and for this reason we shoule be sure that trunk is always ok. Opening a
> branch for each fix instead of using a validation on pre-commit makes the
> whole procedure more heavy does not guarantee that trunk is always in a
> "correct" state in any case.
The overhead isn't very high:
svn checkout $TRUNK_URL my-fix
cd my-fix
edit files, test, build locally
svn copy ^/trunk ^/branches/my-fix-branch
svn switch ^/branches/my-fix-branch
svn commit -m "commit my fix to a branch"
my-fix-branch is tested / test fails
edit files, test, build locally
svn commit -m "fix the fix"
my-fix-branch is tested / approved
svn switch ^/trunk
svn merge --reintegrate ^/branches/my-fix-branch
svn commit -m "merge my-fix-branch to trunk"
In this example, the extra steps are a copy, two switches, and one merge.
Also, intermediate states of the fix are saved into the repository.
Conflicts during the reintegrate merge are unlikely because the
branch is short-lived. With your suggested approach, conflicts
aren't any less likely and would need to be dealt with during
updates of the trunk working copy.
BTW, with a Subversion 1.8 client, the step:
svn merge --reintegrate ^/branches/my-fix-branch
becomes just:
svn merge ^/branches/my-fix-branch
> While searching on internet I found two
> "Pre-Commit CI" :
>
> http://www.pmease.com/features/continuous-integration.html#proof-build
> http://www.jetbrains.com/teamcity/features/delayed_commit.html
>
> I have not read the documentation, but it appears they are near to what we
> want
> What do you think about them?
Sounds like tools that run a build based on a working copy with
some local changes applied to that working copy.
If your continuous integration software supports building a revision
plus local changes (e.g. in the form of patches submitted to the CI
software by the developer somehow), you could ask your developers to
perform such a test build before commit.
However, if your tooling isn't too complex to fit onto a single
developer machine, then I wonder where the advantage is over
having the developer run a local build before a commit.
Which generally is the expected behaviour of committers, anyway.
Received on 2013-05-24 12:21:57 CEST