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

Re: 1.6 blocker? copy operation during update fails

From: Neels Janosch Hofmeyr <neels_at_elego.de>
Date: Sat, 10 Jan 2009 01:42:12 +0100

WTF! I just noticed that current trunk shows 'alpha' scheduled *added*
instead of deleted (if I remove the line that modifies 'alpha.moved' after
the move from stefan's script).

$ svn update tc_moved_edited/trunk2
   C tc_moved_edited/trunk2/alpha
A tc_moved_edited/trunk2/alpha.moved
Updated to revision 2.
Summary of conflicts:
  Tree conflicts: 1

$ svn st tc_moved_edited/trunk2
A + C tc_moved_edited/trunk2/alpha
> local edit, incoming delete upon update
M tc_moved_edited/trunk2/alpha.moved

How can that be. alpha is definitely deleted, not added.
Hm, alpha.moved is 'M', 'Modified'. I don't understand, it was only just added.

My wild guess is that add-with-history stuff halfway catches this situation
and removes alpha while applying alpha's local mods to alpha.moved; then
something tree-conflicty comes along and sees alpha being deleted, but
doesn't want to allow it, somehow ending up with alpha being re-'added'. So
this one's gonna be a creative bugfix. ;)

BTW, svn info shows the contradicting 'schedule add' and 'deleted upon
update', as well as stating that "alpha was copied from alpha":
$ svn info tc_moved_edited/trunk2/alpha
Path: tc_moved_edited/trunk2/alpha
Name: alpha
URL: file:///.../test/tc_moved_edited/repos/trunk/alpha
Repository Root: file:///.../test/tc_moved_edited/repos
Revision: 2
Node Kind: file
Schedule: add
Copied From URL: file:///.../test/tc_moved_edited/repos/trunk/alpha
Copied From Rev: 1
Last Changed Author: neels
Last Changed Rev: 1
Last Changed Date: 2009-01-10 01:19:54 +0100 (Sat, 10 Jan 2009)
Text Last Updated: 2009-01-10 01:19:55 +0100 (Sat, 10 Jan 2009)
Checksum: 9f9f90dbe3e5ee1218c86b8839db1995
Tree conflict: local edit, incoming delete upon update
  Source left: (file)
  Source right: (none)

That's scary.
The `1.6 blocker' is most probably related to this. Solving the problem
described here might just also fix the `blocker'.

...carrying on.



Received on 2009-01-10 01:42:40 CET

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