Thanks for your reply Stefan. It's very much appreciated.
Before Subversion 1.8 made the reintegrate merge automatic, I was doing merges
without the reintegrate option, which were, I suppose, inappropriate "complete
merges". They were
generally effective, but sometimes produced errors and strange conflicts. With
Subversion 1.8 or higher, I am forced to cherry-pick, which may sometimes
produce poor results if I pick the
wrong cherries. I had regarded cherry-picking as error-prone and something to
be avoided, but it's good to know that it's used successfully elsewhere.
Bob
From: Stefan Sperling
Sent: Saturday, March 19, 2016 11:10 AM
To: Bob Berger
Cc: users@subversion.apache.org
Subject: Re: What branching patterns work with Subversion reintegrate merge?
On Fri, Mar 18, 2016 at 08:22:06PM +, Bob Berger wrote:
> Subversion requires you to do a sync merge from your trunk to a branch,
> before you can do a reintegrate merge from the branch back to the trunk. But
> the sync merge seems incompatible with a branching pattern where the trunk
> contains ongoing development and branches contain releases
Use cherry-picking merges.
'svn help merge' (output qouted below) contains all you need to know.
The Subversion project itself uses the branching pattern you describe,
so I'm quite sure it works and is fully supported ;-)
If you want to read about our workflow, see here:
http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization
merge: Merge changes into a working copy.
usage: 1. merge SOURCE[@REV] [TARGET_WCPATH]
(the 'complete' merge)
2. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [TARGET_WCPATH]
(the 'cherry-pick' merge)
3. merge SOURCE1[@REV1] SOURCE2[@REV2] [TARGET_WCPATH]
(the '2-URL' merge)
1. This form, with one source path and no revision range, is called
a 'complete' merge:
svn merge SOURCE[@REV] [TARGET_WCPATH]
The complete merge is used for the 'sync' and 'reintegrate' merges
in the 'feature branch' pattern described below. It finds all the
changes on the source branch that have not already been merged to the
target branch, and merges them into the working copy. Merge tracking
is used to know which changes have already been merged.
SOURCE specifies the branch from where the changes will be pulled, and
TARGET_WCPATH specifies a working copy of the target branch to which
the changes will be applied. Normally SOURCE and TARGET_WCPATH should
each correspond to the root of a branch. (If you want to merge only a
subtree, then the subtree path must be included in both SOURCE and
TARGET_WCPATH; this is discouraged, to avoid subtree mergeinfo.)
SOURCE is usually a URL. The optional '@REV' specifies both the peg
revision of the URL and the latest revision that will be considered
for merging; if REV is not specified, the HEAD revision is assumed. If
SOURCE is a working copy path, the corresponding URL of the path is
used, and the default value of 'REV' is the base revision (usually the
revision last updated to).
TARGET_WCPATH is a working copy path; if omitted, '.' is generally
assumed. There are some special cases:
- If SOURCE is a URL:
- If the basename of the URL and the basename of '.' are the
same, then the differences are applied to '.'. Otherwise,
if a file with the same basename as that of the URL is found
within '.', then the differences are applied to that file.
In all other cases, the target defaults to '.'.
- If SOURCE is a working copy path:
- If the source is a file, then differences are applied to that
file (useful for reverse-merging earlier changes). Otherwise,
if the source is a directory, then the target defaults to '.'.
In normal usage the working copy should be up to date, at a single
revision, with no local modifications and no switched subtrees.
- The 'Feature Branch' Merging Pattern -
In this commonly used work flow, known also as the 'development
branch' pattern, a developer creates a branch and commits a series of
changes that implement a new feature. The developer periodically
merges all the latest changes from the parent branch so as to keep the
development branch up to date with those changes. When the feature is
complete, the developer performs a merge from the feature branch to
the parent branch to re-integrate the changes.
parent --+--o--o-o-o--
\\ \ /
\
