With Subversion 1.5.4, I'm trying to write a script for automated merges
between branches and am finding the merge-tool-cmd interface a bit lacking.
This script is intended to run out of cron. What I want the script to
do is:
* Merge from a specified source branch to a specified destination
branch, using the merge tracking info. If no conflicts, go ahead an commit.
* If the conflict is in a certain defined set of files (such as contain
build numbers, etc.), automatically pick the "mine" file.
* If there is a conflict outside of that set of files, remember the
changeset that caused the conflict and abort the merge attempt. If
there are any eligible changesets before the changeset that caused the
conflict, repeat the merge attempt for eligible changesets up to but not
including the changeset that caused the conflict. Keep repeating until
a successful merge (which would be committed) or the script finds the
first eligible changeset causes a conflict.
* If there was a changeset that caused a conflict, email the author of
that changeset asking them to merge their change (possibly with
--record-only). After the author does this, the script would continue
on from there the next time it is run.
I appear to have run into three issues:
1) The merge-tool-cmd script does not appear to be provided with the
repository path of the file being merged.
2) The merge-tool-cmd script does not appear to be provided with the
name of the source revision it is trying to merge in. It might be able
to figure this out by scanning the file in the fourth argument for a
line with ">>>>>>> .merge-right.r", but I'm not sure such a line is
guaranteed to exist in all cases.
3) When the merge-tool-cmd script returns an exit code of 1 or 2, this
does not appear to stop the merge.
I think I'm going to be reduced to copying the merge-cmd.c code and
directly hacking on that, but I though I'd check first.
For background, I'll describe the branching model this is intended to
support. I think a good name for this model is "cascading release
branches."
Each release has its own release branch. There is no trunk. On a
regular basis, automated merges are run from earlier release branches to
later release branches. Developers check their changes into the branch
of the release for which each change is intended.
When a release nears completion, we use commit scripts and the flags
feature of Bugzilla to restrict the bugs for which commits are allowed
into that release's branch. At some point, automated merges going into
that branch are changed to instead go into the branch for a later release.
When development starts on a new version of the product, we create a
release branch for that version, branching off of its previous release
branch.
This branching model has the advantage that developers usually only have
to check into one branch. Less developer time is wasted merging changes
around. Furthermore, with the --use-merge-history switch, it is easier
to research in which release a particular change first appeared.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-22 16:38:51 CET