subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben" <tebu...@googlemail.com>
Subject RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?! -- SOLVED !!!
Date Thu, 01 Apr 2010 11:12:52 GMT
Hi Stanimir!

My problem was: 
I did not have any svn:mergeinfo on any subdirectories on merge source
as well on the merge target before doing a merge.
But after doing a merge I received tons of newly added svn:mergeinfo
entries at random files & directories. 

I really spent a lot of time to understand and solve this siutation.

Finally it turned out, that during our daily work, the subversion
clients tends to "break" existing working copies. It thinks, that you
have a incomplete working copy at some points in the directory
structure. You can identify these siutation by running svnversion: If it
reports a version other than a single number without any suffixes (M may
be ok) you'll run into issues using svn merge and receive additional
svn:mergeinfos on places other than the root directory.

So my best practice checklist for using svn merge is:

- always merge only on root directories
- make a full svn update on the target prior merging
- assert svnversion reports only one number and NO "p" suffix
- perform the svn merge

Hope this helped to understand my original problem and my final
findings.

Thanks a lot for your support, guys!
Cheers
- Ben

P.S.: The other questions is: how & why do working copies break into
"partial state". But this is propably a differnent topic.

-----Original Message-----
From: Stanimir Stamenkov [mailto:s7an10@netscape.net] 
Sent: Wednesday, March 31, 2010 9:05 PM
To: users@subversion.apache.org
Subject: Re: Spurious svn:mergeinfo updated on random, untouched files
on minimalistic merge?! -- SOLVED !!!

Wed, 31 Mar 2010 16:22:37 +0200, /Ben/:

> My problem was not any existing svn:mergeinfos. Neither the source nor
> the target contained *any* svn:mergeinfo except one at the target
root.
> But I finally found the solution!
>
> My problem was:
>      *svnversion reported 3128P*
>
> I have no clue how this occured. We *never* do partial chechkouts, but
a
> short poll at my collegues showed, that many of them having this
> situation, too!
>
> After recovering the partial state all works as expected.

Ben, I haven't got what your actual problem was.  You've stated you 
didn't have svn:mergeinfo on files and folders below the root.  What 
does "svnversion reported 3128P" mean?

-- 
Stanimir


Mime
View raw message