Hi,
I came across a case where svn-normalizer did remove mergeinfo for a
branch which was still present but got renamed in one revision.
I understand why it behaves the current way, but maybe in favor of the
improvements done for handling moves it might also be a good idea to
have svn-normalizer better handle these scenarios?
For a quick demo/test-case showing the underlying issue, I've attached a
batch-file (for windows) demonstrating the case.
As you see the resulting mergeinfo for FooProject/FooSDK is:
/SDK/FooSDK/trunk:2-3
/SDK/FooSDK2/tags/v2:6
/SDK/FooSDK2/trunk:4
Running svn-normalizer analyse now reports
/SDK/FooSDK as a deleted branch (in r4) and running svn-normalizer
normalize --remove-obsoletes would then drop this mergeinfo.
Suggested behavior would be that if a branch is renamed and still
present on trunk, it would not be removed when using svn-normalizer
normalize --remove-obsoletes.
Regards,
Stefan
@echo off
md testrepo
svnadmin create testrepo
md testout
svn co file:///E:/[delete]SVNTest/testrepo testout
cd testout
REM create test tree
md SDK
md SDK\FooSDK
md SDK\FooSDK\tags
md SDK\FooSDK\trunk
echo "Test" >SDK\FooSDK\trunk\test.txt
md FooProject
svn add *
svn ci -m TestSetup
REM tag current FooSDK trunk
svn cp SDK\FooSDK\trunk SDK\FooSDK\tags\v1
svn ci -m "Tagged FooSDK v1"
REM pull in FooSDK into project
svn cp SDK\FooSDK\tags\v1 FooProject\FooSDK
svn ci -m "Pulled-in FooSDK"
REM rename SDK\FooSDK to FooSDK2
svn up
svn mv SDK\FooSDK SDK\FooSDK2
svn ci -m "Renamed FooSDK to FooSDK2"
REM create v2 of FooSDK2
echo "Test2" >SDK\FooSDK2\trunk\test.txt
svn ci -m "Updated FooSDK2 to v2"
svn cp SDK\FooSDK2\trunk SDK\FooSDK2\tags\v2
svn ci -m "Tagged FooSDK2 v2"
REM update FooProj to FooSDK2
svn merge file:///E:/[delete]SVNTest/testrepo/SDK/FooSDK2/tags/v2
FooProject\FooSDK
svn ci -m "Updated FooSDK to v2"
REM this produces mergeinfos for FooProject/FooSDK as follows:
REM /SDK/FooSDK/trunk:2-3
REM /SDK/FooSDK2/tags/v2:6
REM /SDK/FooSDK2/trunk:4
