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.
