I'm thinking there are some potentially misleading merging instructions
in the subversion book:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.commonuses.wholebr
The section presents the common approach to branching and merging where
a repository URL is copied to a branch location, and later that branch
is merged back to the trunk. The way to find out the 'base' revision
for the branch is to use --stop-on-copy.
However, if the branch was created by copying from a working directory
that had modifications, then I believe those instructions give the wrong
base revision. In that case, the base revision is actually the revision
on the trunk from which the branch was copied, ie, the revision
preceding the copy. Following the book instructions, someone could
accidentally leave out a set of changes from their merge without
realizing it.
The --stop-on-copy approach works if the commit which created the branch
was *only* a copy. The safer approach is to always use the revision
just prior to the copy. If the branch copy was only a copy, then the
prior revision will be no different than the copied revision. If the
branch copy contained modifications, then those modifications will be
included in a diff against the trunk revision just before the copy.
I understand that that section of the book does not even mention
creating branches from modified working copies, and maybe some would
consider it bad practice or at least more confusing to create branches
that way. However, if it always works to choose the revision just prior
to the --stop-on-copy revision as the base revision, then maybe that
should be in the book instead.
Does anyone concur? I'm not complaining, I only wanted to point this
out in case it was helpful.
Thanks,
gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 18 04:49:24 2006