Alexander L. Belikoff wrote:
> The second annoyance was the fact that SVN effectively mandates the user
> performing the merge to explicitly specify two revisions, the diff between
> which would be applied to the target revision. While merge is no trivial
> operation by any means, having a number of usable strategies implemented
> would definitely help. In this particular case, at least having an ability to
> merge the changes from another branch using common ancestor as a starting
> point would help. Or, having a symbolic name for a revision number from which
> the named branch was derived (e.g. /fooproject/branches/mychanges@BIRTH)
> would also help. True, this could be all scripted on top of SVN but that
> would be complex and error-prone.
Attached a trivially simple win32 batch file for managing
the last merged revision and performing the merge.
Maybe it is useful to someone else, too.
Assuming that you set suitable default values in the script,
you simply execute the script, potentially resolve conflicts,
and commit to merge recent changes from trunk into your branch.
Because I'm currently working on a branch, I use it very often,
and it is very simple and not error-prone at all.
It's really trivial!
(And probably would be even more trivial under Unix/Linux.)
Of course, having such functionality already built-in in subversion
will be nice; however as long as you can implement this functionality
by trivial scripts, I don't see a serious problem there.
Ben Collins-Sussman wrote:
> Did you read chapter 4 in the book? Granted, it's occasionally annoying
> to have to figure out the exact 2 revisions to compare in order to
> perform a merge, but no more so than in CVS. ('cvs up -j N -j M
> foo.c'). When I do a merge in CVS (a backport of a bugfix, for
> example), it's actually *harder*, because I need to run 'cvs up -j -j'
> on every single file in my non-atomic changeset(s), and discover the
> exact revisions of every file to compare. With SVN, you find 2 versions
> of the entire branch-tree, and a single merge command gives you all the
> changes at once. It's much easier than CVS in that regard. (See
> example further down this mail.)
Actually it's not so hard in CVS, because you can tag the last merged
state, so that you also only need one merge command plus one
command move the tag.
Cheers,
Folker
@echo off
rem This script merges changes from one repository directory
rem into the working copy of another directory. A property
rem of the target directory is used to track the last merged revision.
rem
rem The script uses the svn info command to get the revision to merge to.
rem Before calling this script, you should execute svn update.
setlocal
rem ***** Source URL:
set from=%1
if "%from%" == "" set from=<default-from-url>
echo Src URL: %from%
rem ***** Target URL:
set into=%2
if "%into%" == "" set into=.
echo Dest path: %into%
rem ***** Property name to store the last merged revision:
set prop=%3
if "%prop%" == "" set prop=last-merge-from-trunk
echo Prop name: %prop%
rem ****************************************
svn propget %prop% >old.tmp
for /f %%i in (old.tmp) do set old=%%i
del old.tmp
echo Old rev: %old%
svn info >info.tmp
for /f "tokens=1,2" %%i in (info.tmp) do if "%%i" == "Revision:" set new=%%j
del info.tmp
echo New rev: %new%
svn propset %prop% %new% %into%
svn merge %from% -r %old%:%new%
rem ****************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 21 10:08:23 2004