Thank you Daniel, below is the script I used (line wrapping might mess
up a few lines, sorry)
As I was cleaning it up, I realized that in 1.6.17 (yes, still using it,
and where I saw the issue first) the behavior is different (2-url merge
gives me a tree conflict).
I am really tempted to delete the extra merginfo-that is my biggest
concern at this time.
--------- start of script (dos cmd)
@ECHO off
REM -- Script to test handling of merge info during a 2-url merge
ECHO.
ECHO -- Create empty repo in current folder
md repo
svnadmin create --fs-type fsfs repo\testRepo
SET repoRoot=file:///%CD:\=/%/repo
ECHO.
ECHO -- Create sructure to import in repo
md WC
md WC\trunk
md WC\branches
svn import WC %repoRoot%/testRepo -m"Importing"
rd /s /Q WC
ECHO.
ECHO -- Check out working copy of the entire repo
svn co %repoRoot%/testRepo workingCopy
ECHO.
ECHO -- Play in trunk, adding one file
pushd workingCopy\trunk
echo Adding fileA in trunk>FileA.txt
svn add FileA.txt
svn commit . -m"Adding first file to trunk"
popd
ECHO.
ECHO -- Create 2 branches from trunk. This does not create any mergeinfo
svn copy %repoRoot%/testRepo/trunk %repoRoot%/testRepo/branches/foo
-m"branching to foo" --parents
svn copy %repoRoot%/testRepo/trunk %repoRoot%/testRepo/branches/bar
-m"branching to bar" --parents
ECHO.
ECHO -- Add a file to trunk
pushd workingCopy\trunk
echo Adding fileB in trunk>FileB.txt
svn add FileB.txt
svn commit . -m"Adding second file to trunk"
popd
ECHO.
ECHO -- Edit file in foo
svn update workingCopy
pushd workingCopy\branches\foo
echo Editing first file in foo>>fileA.txt
svn commit . -m"Editing file in foo"
popd
svn update workingCopy
ECHO.
ECHO -- Merge latest from trunk to foo. This creates mergeinfo in foo
and brings FileB
svn merge %repoRoot%/testRepo/trunk workingCopy\branches\foo
svn commit workingCopy\branches\foo -m"Merging latest from trunk to foo"
svn update workingCopy
ECHO.
ECHO -- Perform 2-URL merge to get diff between trunk and foo and apply
to bar
ECHO.
ECHO -- Showing the diff first: fileB is not listed
svn diff %repoRoot%/testRepo/trunk %repoRoot%/testRepo/branches/foo
ECHO.
ECHO -- Now merging. svn 1.6.17 shows tree conflict on FileB. svn 1.14.2
shows no conflict
svn merge %repoRoot%/testRepo/trunk %repoRoot%/testRepo/branches/foo
workingCopy\branches\bar
REM next line is for 1.6.17 only
REM : svn resolve workingCopy\branches\bar\FileB.txt --accept working
svn commit workingCopy\branches\bar -m"Merging diff from trunk to foo
into bar"
ECHO.
ECHO -- In bar, mergeinfo shows that part of trunk was merged in bar,
but this is not correct
ECHO -- For instance, mergeinfo shows Trunk 4-6, but the file added in
trunk at r5 is not bar
svn update workingCopy
ECHO.
ECHO. No fileB in here
dir workingCopy\branches\bar
ECHO.
ECHO.
svn pg svn:mergeinfo workingCopy\branches\bar
svn mergeinfo workingCopy\trunk workingCopy\branches\bar
------------------ end of script
Christophe
On 5/12/2022 10:52 AM, Daniel Shahaf wrote:
Could you post the script, please? It's hard to answer your question
when it describes the details verbally rather than machine-readably.
It sounds like a supported scenario.
Cheers,
Daniel
Christophe Royer wrote on Fri, 06 May 2022 21:46 +00:00:
I recently saw some mergeinfo that I can explain but still look wrong to
me. Not sure if it’s a wrong usage of svn, or possibly a defect, and so
far I have not seen any post about this. Here is the scenario (I have a
script, batch file for windows, if needed):
Seen first using svn 1.6.17, confirmed with with svn 1.14.2
Here is the setup:
* Create repo with trunk and branches
* Add a file to trunk
* Create 2 branches from trunk, foo and bar (at this point, neither
branch has mergeinfo for trunk)
* In foo, edit the existing file
* Make some changes in trunk (I added a file)
* Merge trunk to foo (this bring the new file in and adds mergeinfo
for trunk, including the revision where the new file was added)
Now the fun part:
* Do a 2-url merge to merge the changes solely made in foo, and apply
them to bar
The diff between trunk and foo shows only one file was edited (the
second file does not show, since merge made it the same in trunk and
foo). But the diff also shows mergeinfo changed between trunk and foo,
so those get merged to bar, which seem appropriate.
However, it follows that bar now indicates that it has those changes
from trunk (esp. the one revision where the file was added in trunk) but
of course that file is not in bar…And this occurs whether or not I use
–ignore-ancestry.
I could use cherrypicking instead, but I did not want to have to pick
specific changes (I really want all the changes made in foo, but only
those changes)
So,
1)is that a misuse of svn, an unsupported scenario?. Or is there room
for improvement to the mergeinfo management?
2)should I manually delete those “unwanted” mergeinfo? If I don’t, I
have an idea of the issues I can run into. But I am afraid to miss
something here, and removing them would cause other issues.
Thanks
Christophe
