Looks like the batch-file got truncated by some clients/mail servers on
the way --- here's the plain batch file content.
Anyone having an idea what's going on here?
REM create test repository
mkdir C:\test
cd /d C:\test
mkdir test2
svnadmin create test2
REM check-out test repository
mkdir test2checkout
svn co file:///C:/test/test2 ./test2checkout
cd test2checkout
REM add initial structure
mkdir A
echo > A\test.txt
svn add A
svn commit -m test
REM copy A to B
svn cp A B
svn commit -m test
REM modify A/test.txt
echo >> A\test.txt
svn commit -m test
REM cherry pick test.txt change and commit to B
svn up
svn merge -r 2:3 A/test.txt B/test.txt
svn commit -m test
REM modify A/test.txt again
echo >> A\test.txt
svn commit -m test
REM do an auto merge of B
svn up
svn merge file:///C:/test/test2/A B
REM This produces merge infos in B only
REM alternative
svn revert B -R
svn merge file:///C:/test/test2/A B --record-only
REM This produces merge infos in B AND B/test.txt
Regards,
Stefan
Hi,
I'm wondering why there is a difference in how mergeinfos are recorded
based on whether the merge is done using --record-only or not.
To demonstrate the case, I've put together a repro-script (for Windows
- see attachment).
My question is that why does the last step in the script produce
different merge-info properties:
1. svn merge file:///C:/test/test2/A B
This will produce mergeinfo in B
2. svn merge file:///C:/test/test2/A B --record-only
This will produce mergeinfo in B and B/test.txt
Looking through the web, the docu and the SVN buglist I couldn't find
any matching entry. Maybe someone can point me on where to look for an
explanation?
I'm wondering especially because as an alternative to variation 2, one
might also follow variation 1 and then revert all changes (except for
the recorded mergeinfo B). Isn't the outcome then the same as
variation 2?
Regards,
Stefan
