subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary M. Gere" <Gary.G...@Sun.COM>
Subject Re: svn merge issues after upgrading server from 1.4.3 to 1.6.6 - unexpected property changes (deleted svn:mergeinfo)
Date Thu, 25 Mar 2010 19:23:03 GMT
-Hi Bob,

First off, thank you very much for your quick reply.

We were running a 1.4.2 subversion server, and upgraded the subversion 
server to 1.6.6. The clients have not changed in any way, and were a mix 
of 1.4, 1.5 and 1.6 clients that used "http" only to communicate with 
the subversion server. We have not had any compatibility issues of any 
kind until we upgraded the server to 1.6.6.

The merge problem did not show up when the server was 1.4.2, but is now 
showing up with the 1.6.6 server.

We did not upgrade the database repository - it is still at version "3". 
I read somewhere in the 1.5 release notes that the "merge tracking" 
added to 1.5 will not be enabled unless the repository is upgraded, 
which it has not.

If I understand your reply correctly, what's happening is old 
svn:mergeinfo data that is no longer needed is being removed (property 
change only). Even though a large number of files are listed in the 
merge/commit, besides files that really were merged, the rest are just 
property changes.

Thank you very much.


On 03/25/10 12:04, Bob Archer wrote:
>> We recently upgraded our subversion server software and are having major
>> problems with merging after moving the subversion server from 1.4.2 to
>> 1.6.6. I am asking the user community for any help they can give us.
>> The details of the prior and current software versions are detailed at the
>> end of this email.
>> The problem we are having is with 'svn merge' with a workspace that was
>> checked out using the subversion 1.4.2 server:
> Eww... not sure how great an idea it is to use a pre 1.5 server with 1.5 and 1.6 clients.
Although I'm not 100% sure of the ramifications... it could just be a performance issue and
the client has to do more work to walk the tree of mergeinfo properties. Perhaps someone that
knows a bit more about that issue will chime in here.
>>    - cd<destination-branch-directory>
>>    - svn merge -r revision1:revision2 SOURCE_SVN_URL .
>> This results in many unrelated files are having their properties change,
>> and many unrelated files being included in the merge. It makes it very
>> difficult to verify that the merge was successful when many unrelated
>> files are included.
>> A small example:
>> An attempt to merge one change from sw1.0 to sw2.0 branch.
>> A folder called Docs contains files that have not been changed.
>> An svn diff produces the following:
>> % cd /data/source/branches/sw2.0
>> % svn stat -q Docs/
>>   M      Docs/WDS-RIS-Blueprint.odt
>>   M      Docs/WDS-RIS-Script-Usage.odt
> As you know a " M" (Space in first col M in second column) indicates that the properties
where changed but not the file itself.
>> % svn diff Docs/
>> Property changes on: Docs/WDS-RIS-Blueprint.odt
>> ___________________________________________________________________
>> Deleted: svn:mergeinfo
>> Property changes on: Docs/WDS-RIS-Script-Usage.odt
>> ___________________________________________________________________
>> Deleted: svn:mergeinfo
> This shows that you do have mergeinfo on your files. So, at some time someone did a merge
probably at the Docs level or directly to a file which added the mergeinfo. Now you are doing
it at a higher folder level so the data is being elided. There's not really anything wrong
> You  might want to train your devs to always do merges at the same folder level to prevent
all the merge data on child folders and files. If they weren't there then they wouldn't be
>> A mix of subversion clients have been in use, including 1.4, 1.5 and 1.6
>> based clients. Those have not changed, and this behavior occurs even using
>> a 1.6.9 client.
> I assume it doesn't happen when you use a 1.4 client... since this version doesn't include
the merge tracking functionality.
>> Can anyone provide any guidance, clues, pointers, etc. to what we need to
>> do to address this issue??
> I think there is nothing you can do to address it. But, to solve your problem you may
just want to pipe the output to grep (or something) and ignore files with a status of " M"
> You might also want to upgrade your server... 1.4.x is pretty old and not supported with
> I hope this helps.. sorry AFAIK there is no magic answer to make this easier.
> BOb

View raw message