[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Build on Pre-Commit

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 24 May 2013 12:21:22 +0200

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.