2008/9/18 Wim Coenen <wcoenen_at_gmail.com>
> 2008/9/18 tmto <tmto_at_arcor.de> wrote:
>
>> But if I check my working copy branch path with "check for modification"
>> some other files has a change svn property "svn:mergeinfo that has change
>> form "Working Base" to "Working Copy". May be OK but why not all files? I
>> don`t understand?
>>
>
> After upgrading our svn server from 1.4 to 1.5 and doing a merge, I also
> noticed that the svn:mergeinfo property was set or changed on files that
> were unrelated to the merge. The files in question all had one thing in
> common: they were moved or copied at some point in their history.
>
> I believe this is an effect of the 1.4 -> 1.5 transition. It seems to occur
> only the first time when you merge changes into a specific location.
>
After some more research it turns out that my above statement is inaccurate.
What happens is that once a file/folder has explicit mergeinfo, each
subsequent merge to the branch will update that mergeinfo even if the
file/folder is unrelated. This is annoying as it introduces more and more
clutter in the changelist for each merge.
To avoid this, only merge to the "root" folder of the branch, for example
"/branches/maintenance2.x". None of the files or folders below
"/branches/maintenance2.x" should then get mergeinfo. Follow the advice at
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword
Unfortunately, even if you merge only at the "root" folder of the branch,
empty svn:mergeinfo properties can still appear on individual files and
folders when they are copied, to indicate that they have not received the
same merges as their siblings. This introduces the same issue again. The
safest and easiest solution is probably to accept that merges can cause
svn:mergeinfo updates all over the place. Don't worry about it and just
commit them. Let's hope that future subversion releases will alleviate or
hide the log clutter in some way.
HTH,
Wim Coenen
Received on 2008-09-19 15:59:55 CEST