[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Double file entries after merge of moves/refactoring; possible bug?

From: Paul Burba <ptburba_at_gmail.com>
Date: Thu, 6 Aug 2009 16:16:23 -0400

Hi Horst,

I think you are running into issue #3324
http://subversion.tigris.org/issues/show_bug.cgi?id=3324. I've not
actively working on this, but will take a fresh look.

Paul

On Thu, Jun 18, 2009 at 12:55 PM, Hermanns, Horst<h.hermanns_at_telekom.de> wrote:
> Hi,
>
> we still could not solve our problem (double/old file entries after
> merges in splitted rev-ranges) and made another test.
>
> I made two checkouts of my target-branch 'bra2' and merged in two
> different ways the changes from 'bra1':
>
>  1st checkout:  svn merge -r142:144 https://...bra1 .
>                    A    dir2
>                    A    dir2\dir3
>                    A    dir2\dir3\file1
>
>  2nd checkout:  svn merge --force -r142:143 https://...bra1 . (no
> commit)
>                    A    dir2
>                    A    dir2\file1
>
>                svn merge --force -r143:144 https://...bra1 .
>                    A    dir2\dir3
>                    A    dir2\dir3\file1
>                    D    dir2\file1
>
> Now I made a diff between the two checkout dirs and tried to find the
> difference which causes the double file entry after the commit of the
> 2nd checkout (svn status show identical output and no file
> 'dir2\file1').
>
> I found one difference in the '.svn\entries' files (in this example 143
> - 144) and a additional file 'file1.svn-base' under
> 'dir2\.svn\text-base' of the 2nd checkout.
>
> - Wrong file creation under 'dir1\file1' (old location before move) and
> 'dir1\dir2\file1' with the commit:
> WC\.svn\entries:
>  ...
>  copied
>  https://...bra1/dir2
>  143
>  ...
> - Correct file creation only under 'dir1\dir2\file1' (location after
> move)
>  WC\.svn\entries:
>  ...
>  copied
>  https://...bra1/dir2
>  144
>  ...
>
> Any experiences with merges in splitted rev ranges?
> We already used it indirectly with svnmerge.py and I think 'svn merge'
> also splits rev ranges depending on the mergeinfo properties.
>
> Comments / suggestions welcome.
>
> Thanks and regards
> Horst
>
>
>>>The creation an relocation of the file in one branch leads (after the
> merge of this two changes to
>>>another branch) also to one resulting file in the merge target branch.
> In the other case (merge
>>>in 2 rev ranges) I got two files in the target branch, one in the old
> an the other in the new location.
>
>>>Expect to the outputs which show no tree conflicts and seems to be
>>>correct (first 'A    dir1\file1' followed in the next merge by a
>>>'D dir1\file1' and add in the new location 'A    dir1\dir2\file1') I
> got
>>>two files in the respository after the (single) commit of both merge
>>>results:
>>>
>>># svn merge -r142:143 https://...bra1 .
>>>--- Merging r143 into '.':
>>>A    dir1
>>>A    dir1\file1
>>>
>>># svn merge -r143:144 https://...bra1 .
>>>--- Merging r144 into '.':
>>>A    dir1\dir2
>>>A    dir1\dir2\file1
>>>D    dir1\file1
>>>
>>># svn status  (!seems to be ok, no 'dir1\file1')
>>> M     .
>>>A  +   dir1
>>>A  +   dir1\dir2
>>>A  +   dir1\dir2\file1
>>>
>>>... commit
>>>
>>># svn list https://...bra2/dir1
>>>file1         (!wrong/double entry 'dir1\file1')
>>>
>>># svn list https://...bra2/dir1/dir2
>>>file1         (correct location 'dir1\dir2\file1')
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2363265
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381043

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-06 22:17:41 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.