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

Re: tree conflict on tc_url_rev branch?

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 25 Nov 2008 10:18:18 -0500

On Mon, Nov 24, 2008 at 6:55 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Nov 24, 2008 at 06:15:35AM +0100, Neels J Hofmeyr wrote:
>> Stefan Sperling wrote:
>> > On Sun, Nov 23, 2008 at 05:30:50PM +0000, Stefan Sperling wrote:
>> >> Hi,
>> >>
>> >> in r34288, I added this file on trunk:
>> >
>> >> For some reason, the file was not added in the sync-up commit
>> >> I made in r34325. I don't really understand why this happened.
>> >
>> > I forgot to mention that throughout all of this, I was using svn
>> > version 1.5.4 (r33841).
>>
>> Reproduced with 1.5.1. So that this problem doesn't harm the branch, I've
>> done a
>>
>> svn cp \
>> $svnrepos/trunk/notes/tree-conflicts/use-cases-resolution.txt \
>> $svnrepos/branches/tc_url_rev/notes/tree-conflicts/use-cases-resolution.txt
>> to fix the problem. We should try to reproduce this elsewhere in case we
>> need to.
>
> OK.
>
> Question to merge-trackers:
> Will --reintegrate'ing the branch still work now?

TCers,

Since Julian removed the explicit mergeinfo on
'notes/tree-conflicts/use-cases-resolution.txt' in r34380, yes
reintegrate should definitely work. In fact I just tried it and
everything looks fine at first glance.

Had Julian not done this, then reintegrate still should have worked if
using a trunk build > r34306, since use-cases-resolution.txt's
natural history (a.k.a. implicit mergeinfo) would show that it was up
to date with trunk. I emphasize "should have worked" since I haven't
tried this exact scenario.

Regarding Neels' REPOS-to-REPOS copy of use-cases-resolution.txt from
trunk to the branch in r34373, this is a good example of how
additional subtree mergeinfo can still come into existence. WC-to-WC
copies no longer create explicit mergeinfo on the dest, but the other
variants of copy still do. Since the other flavors of copy/move have
access to the repos they can definitively determine the source's
inherited mergeinfo. Though in some cases it isn't necessary to do
so, I need to look into this more, but that is a topic for another
thread.

The thing that worries me much more than any of the preceding, is why
didn't Stefan's sync-up commit in r34325 add
'notes\tree-conflicts\use-cases-resolution.txt'? I just tried to
replicate the synch merge and the file *was* added using a trunk_at_34403
build:

C:\SVN\src-branch-tc_url_rev>svn info
Path: .
URL: http://svn.collab.net/repos/svn/branches/tc_url_rev
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 34324
Node Kind: directory
Schedule: normal
Last Changed Author: stsp
Last Changed Rev: 34324
Last Changed Date: 2008-11-21 17:01:40 -0500 (Fri, 21 Nov 2008)

C:\SVN\src-branch-tc_url_rev>svn merge
http://svn.collab.net/repos/svn/trunk -r0:34324 --accept postpone
--- Merging r34284 through r34324 into '.':
A notes\tree-conflicts\use-cases-resolution.txt
U subversion\libsvn_subr\config_file.c
U subversion\libsvn_subr\dirent_uri.c
U subversion\libsvn_subr\mergeinfo.c
U subversion\tests\libsvn_subr\dirent_uri-test.c
U subversion\tests\cmdline\stat_tests.py
U subversion\tests\cmdline\info_tests.py
U subversion\tests\cmdline\merge_tests.py
U subversion\svn\status.c
U subversion\svn\schema\info.rnc
C subversion\svn\tree-conflicts.c
U subversion\svn\main.c
U subversion\svn\tree-conflicts.h
U subversion\svn\info-cmd.c
U subversion\include\svn_dirent_uri.h
C subversion\include\svn_wc.h
U subversion\include\private\svn_wc_private.h
U subversion\include\private\svn_mergeinfo_private.h
U subversion\libsvn_wc\util.c
U subversion\libsvn_wc\adm_ops.c
U subversion\libsvn_wc\status.c
U subversion\libsvn_wc\tree_conflicts.c
U subversion\libsvn_client\merge.c
U subversion\libsvn_repos\reporter.c
U INSTALL
U TODO-1.6
Summary of conflicts:
  Text conflicts: 2

Even stranger, using 1.5.4 it still works:

C:\SVN\src-branch-tc_url_rev-1.5.4WC>\SVN\svn-win32-branch-1.5.4.RELEASE\bin\svn.exe
info
Path: .
URL: http://svn.collab.net/repos/svn/branches/tc_url_rev
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 34324
Node Kind: directory
Schedule: normal
Last Changed Author: stsp
Last Changed Rev: 34324
Last Changed Date: 2008-11-21 17:01:40 -0500 (Fri, 21 Nov 2008)

C:\SVN\src-branch-tc_url_rev-1.5.4WC>\SVN\svn-win32-branch-1.5.4.RELEASE\bin\svn.exe
merge http://svn.collab.net/repos/svn/trunk -r0:34324 --accept
postpone
--- Merging r34284 through r34324 into '.':
A notes\tree-conflicts\use-cases-resolution.txt
U subversion\libsvn_subr\config_file.c
U subversion\libsvn_subr\dirent_uri.c
U subversion\libsvn_subr\mergeinfo.c
U subversion\tests\libsvn_subr\dirent_uri-test.c
U subversion\tests\cmdline\stat_tests.py
U subversion\tests\cmdline\info_tests.py
U subversion\tests\cmdline\merge_tests.py
U subversion\svn\status.c
U subversion\svn\schema\info.rnc
C subversion\svn\tree-conflicts.c
U subversion\svn\main.c
U subversion\svn\tree-conflicts.h
U subversion\svn\info-cmd.c
U subversion\include\svn_dirent_uri.h
C subversion\include\svn_wc.h
U subversion\include\private\svn_wc_private.h
U subversion\include\private\svn_mergeinfo_private.h
U subversion\libsvn_wc\util.c
U subversion\libsvn_wc\adm_ops.c
U subversion\libsvn_wc\status.c
U subversion\libsvn_wc\tree_conflicts.c
U subversion\libsvn_client\merge.c
U subversion\libsvn_repos\reporter.c
U INSTALL
U TODO-1.6

Neels, when you reproduced the problem with 1.5.1 how exactly were you
doing this?

Paul

> I would probably have waited for the reintegration merge and
> resurrected the file before committing the merge result to
> trunk (but this solution is no fun if there is more than
> one file involved).
>
>
> Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-25 16:18:33 CET

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

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