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

Re: Tree Conflicts: Edit lands on locally replaced without history file

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 09 Feb 2009 18:18:41 +0000

On Sun, 2009-02-08 at 21:08 -0500, Paul Burba wrote:
> While working on the Issue #3334 branch I keep coming across many
> cases where we update and end up with a WC that can't be resolved and
> committed. Usually the desired behavior is pretty obvious, but
> update_tests.py 33 'update wc containing a replaced-with-history file'
> demonstrates a case I'm not very certain about: An update brings down
> a text edit on file that is locally replaced without history:
>
> # We have this WC:
>
> TRUNK.DBG>svn st -v update_tests-33
> 1 1 jrandom update_tests-33
> 1 1 jrandom update_tests-33\A
> 1 1 jrandom update_tests-33\A\B
> 1 1 jrandom update_tests-33\A\B\lambda
> 1 1 jrandom update_tests-33\A\B\E
> 1 1 jrandom update_tests-33\A\B\E\alpha
> 1 1 jrandom update_tests-33\A\B\E\beta
> 1 1 jrandom update_tests-33\A\B\F
> 1 1 jrandom update_tests-33\A\mu
> 1 1 jrandom update_tests-33\A\C
> 1 1 jrandom update_tests-33\A\D
> 1 1 jrandom update_tests-33\A\D\gamma
> 1 1 jrandom update_tests-33\A\D\G
> 1 1 jrandom update_tests-33\A\D\G\pi
> 1 1 jrandom update_tests-33\A\D\G\rho
> 1 1 jrandom update_tests-33\A\D\G\tau
> 1 1 jrandom update_tests-33\A\D\H
> 1 1 jrandom update_tests-33\A\D\H\chi
> 1 1 jrandom update_tests-33\A\D\H\omega
> 1 1 jrandom update_tests-33\A\D\H\psi
> R 1 1 jrandom update_tests-33\iota
>
>
> TRUNK.DBG>svn diff update_tests-33
> Index: update_tests-33/iota
> ===================================================================
> --- update_tests-33/iota (revision 1)
> +++ update_tests-33/iota (working copy)
> @@ -1 +0,0 @@
> -This is the file 'iota'.

So, the 1-line file is being replaced with a 0-line (empty) file. Is
that what the following line does?

  svntest.main.run_svn(None, 'cp', mu_path, iota_path)

It looks like that diff is broken. Shouldn't it include "+This is the
file 'mu'." ?

> # Here is the incoming text change:
>
> TRUNK.DBG>svn diff update_tests-33\iota -r1:HEAD
> Index: update_tests-33/iota
> ===================================================================
> --- update_tests-33/iota (revision 1)
> +++ update_tests-33/iota (revision 2)
> @@ -1 +1,2 @@
> This is the file 'iota'.
> +New line in 'iota'
>
> # We update and get the expected tree conflict:
>
> TRUNK.DBG>svn up update_tests-33
> Skipped 'update_tests-33\iota'
> At revision 2.
> Summary of conflicts:
> Skipped paths: 1

That flagged a tree conflict? Then it should say so, and not say just
"skipped" without saying why.

> # But iota is still at rev 1...
>
> TRUNK.DBG>svn st update_tests-33 -v
> 2 2 jrandom update_tests-33
> 2 1 jrandom update_tests-33\A
> 2 1 jrandom update_tests-33\A\B
> 2 1 jrandom update_tests-33\A\B\lambda
> 2 1 jrandom update_tests-33\A\B\E
> 2 1 jrandom update_tests-33\A\B\E\alpha
> 2 1 jrandom update_tests-33\A\B\E\beta
> 2 1 jrandom update_tests-33\A\B\F
> 2 1 jrandom update_tests-33\A\mu
> 2 1 jrandom update_tests-33\A\C
> 2 1 jrandom update_tests-33\A\D
> 2 1 jrandom update_tests-33\A\D\gamma
> 2 1 jrandom update_tests-33\A\D\G
> 2 1 jrandom update_tests-33\A\D\G\pi
> 2 1 jrandom update_tests-33\A\D\G\rho
> 2 1 jrandom update_tests-33\A\D\G\tau
> 2 1 jrandom update_tests-33\A\D\H
> 2 1 jrandom update_tests-33\A\D\H\chi
> 2 1 jrandom update_tests-33\A\D\H\omega
> 2 1 jrandom update_tests-33\A\D\H\psi
> R C 1 1 jrandom update_tests-33\iota
> > local delete, incoming edit upon update

OK, so it did flag a tree conflict. (I think it's OK that we report
"local delete" and not "local replacement".)

That's good in that it flagged the conflict, but bad in that it does not
update the base-revision, as shown by the "1" instead of "2" there.

> TRUNK.DBG>svn diff update_tests-33
> Index: update_tests-33/iota
> ===================================================================
> --- update_tests-33/iota (revision 1)
> +++ update_tests-33/iota (working copy)
> @@ -1 +0,0 @@
> -This is the file 'iota'.

And we haven't applied the incoming change to the text-base. Oops.
(Being a replacement, the text-base we're talking about is the one
called "revert-base".)

> # ...So even if we resolve, we can't commit because 'iota' is out of date.
> # (and of course if we update we are back in the same position)
[...]

> So what would we like to see for behavior here? Should the text base
> for iota simply be updated and a tree conflict generated on the delete
> half of the replace, leaving us with a WC like this?
>
> BETTER???>svn st update_tests-33 -v
> 2 2 jrandom update_tests-33
> 2 1 jrandom update_tests-33\A
> 2 1 jrandom update_tests-33\A\B
> 2 1 jrandom update_tests-33\A\B\lambda
> 2 1 jrandom update_tests-33\A\B\E
> 2 1 jrandom update_tests-33\A\B\E\alpha
> 2 1 jrandom update_tests-33\A\B\E\beta
> 2 1 jrandom update_tests-33\A\B\F
> 2 1 jrandom update_tests-33\A\mu
> 2 1 jrandom update_tests-33\A\C
> 2 1 jrandom update_tests-33\A\D
> 2 1 jrandom update_tests-33\A\D\gamma
> 2 1 jrandom update_tests-33\A\D\G
> 2 1 jrandom update_tests-33\A\D\G\pi
> 2 1 jrandom update_tests-33\A\D\G\rho
> 2 1 jrandom update_tests-33\A\D\G\tau
> 2 1 jrandom update_tests-33\A\D\H
> 2 1 jrandom update_tests-33\A\D\H\chi
> 2 1 jrandom update_tests-33\A\D\H\omega
> 2 1 jrandom update_tests-33\A\D\H\psi
> R C 2 1 jrandom update_tests-33\iota
> > local delete, incoming edit upon update
>
> BETTER???>svn diff update_tests-33
> Index: update_tests-33/iota
> ===================================================================
> --- update_tests-33/iota (revision 2)
> +++ update_tests-33/iota (working copy)
> @@ -1,2 +0,0 @@
> -This is the file 'iota'.
> -New line in 'iota'

Yes, of course. That is both good and consistent with the behaviour that
we're getting (trying to get) in the other issue-3334 and similar cases,
is it not?

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1129899
Received on 2009-02-09 19:19:39 CET

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