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. 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?
2013/5/24 Stefan Sperling <stsp_at_elego.de>
> On Fri, May 24, 2013 at 10:14:04AM +0200, San Martino wrote:
> > Hello,
> >
> > I know this has been asked already, but we would really like to reject
> any
> > attempt to commit files which would break a project in trunk. The
> decision
> > to reject the committed files is based on the result of the building
> > process of the project the files being committed belong to. I know that
> > during the pre-commit phase the repository cannot be accessed
> concurrently,
> > but this is not a problem for us since our buildings are really fast and
> we
> > can tolerate any delay involved.
> >
> > Are there any tools to achieve what we want? Note that it will be
> necessary
> > ro recompile the whole project unit, not just the single files being
> > committed.
> >
> > Thanks.
>
> It sounds like you need a working copy for building.
> I don't think there is a way to construct a useful working copy
> from a transaction.
>
> You'd have to use some fragile construct such as a working copy
> of HEAD with local changes which are pulled from the transacion
> with the help of svnlook. This is inherently racy, because
> transactions run concurrently and HEAD could change during your
> test build.
>
> Essentially, doing what you have in mind really isn't supposed to be done.
>
> Instead, you could forbid direct commits to trunk, and only merge changes
> from branches that have been vetted. Have you considered that approach?
> Everything is transactional, and you always have a working trunk build.
> Your pre-commit hook could reject attempted commits to trunk which do
> not tweak svn:mergeinfo, and possibly even verify that the merge is
> merging changes from an approved branch by checking the mergeinfo and
> comparing it to a list of branches which may merge into trunk.
>
Received on 2013-05-24 12:05:52 CEST