Daniel, the first script I sent may confuse things a little, because of
the tree conflict.
Here is another script that avoid that issue. The problem is the same:
it looks like the mergeinfo does not match the state of the branch.
-----start of 2nd script
@ECHO off
REM -- Script to test handling of merge info during a 2-url merge
REM -- this time, we setup to avoid tree conflict: we don't add file
after the branches are created,
REM -- we just update them
REM ***********************
REM 2 files in trunk: fileA and fileB
REM 2 branches
REM edit fileA in trunk, merge to foo
REM edit fileB in foo
REM diff between trunk and foo do NOT show fileA (merged, same im both)
REM 2-url merge trunk to foo into bar: should bring changes to fileB only
REM ***********************
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 two files
pushd workingCopy\trunk
echo Adding fileA in trunk>FileA.txt
echo Adding fileB in trunk>FileB.txt
svn add FileA.txt FileB.txt
svn commit . -m"Adding 2 files 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 -- Edit fileA in trunk
svn update workingCopy
pushd workingCopy\trunk
echo Editing fileA in trunk>>fileA.txt
svn commit . -m"Editing fileA in trunk"
popd
svn update workingCopy
ECHO.
ECHO -- Merge latest from trunk to foo. This creates mergeinfo in foo
and brings fileA changes
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 -- Edit fileB in foo
svn update workingCopy
pushd workingCopy\branches\foo
echo Editing fileB in foo>>fileB.txt
svn commit . -m"Editing fileB in foo"
popd
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: fileA is not listed (only fileB)
svn diff %repoRoot%/testRepo/trunk %repoRoot%/testRepo/branches/foo
ECHO.
ECHO -- Now merging
svn merge %repoRoot%/testRepo/trunk %repoRoot%/testRepo/branches/foo
workingCopy\branches\bar
svn commit workingCopy\branches\bar -m"Merging diff from trunk to foo
into bar"
svn update workingCopy
ECHO.
ECHO -- In bar, fileA does not have the trunk changes, good
TYPE workingCopy\branches\bar\FileA.txt
ECHO.
ECHO -- But the trunk revision where fileA was changed (r5) shows as
merged in bar
ECHO -- rev5 of fileA in the trunk
svn cat %repoRoot%/testRepo/trunk/FileA.txt@5
ECHO.
ECHO -- mergeinfo porperty for bar
svn pg svn:mergeinfo workingCopy\branches\bar
ECHO.
ECHO -- svn mergeinfo between trunk and bar
svn mergeinfo workingCopy\trunk workingCopy\branches\bar
-----end of 2nd script
Christophe
On 5/12/2022 4:41 PM, Christophe Royer wrote:
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
