Quoting Mark Phippard <markphip_at_gmail.com>:
> Using current trunk. I am doing some basic testing so I can figure
> out JavaHL changes to make around the status/info reporting etc.
> I renamed a file and committed it.
> In second WC, I made some edits to file and then did update. This
> reported the tree conflict. I saw stuff like this:
> $ svn st
> M C trunk/src/com/acme/ui/editors/ColorManager.java
> M trunk/src/com/acme/ui/editors/MyColorManager.java
> $ svn info trunk/src/com/acme/ui/editors/ColorManager.java
> Path: trunk/src/com/acme/ui/editors/ColorManager.java
> Tree conflict:
> The update attempted to delete 'ColorManager.java'
> (possibly as part of a rename operation).
> You have edited 'ColorManager.java' locally.
> What I am concerned about is that this file "ColorManager.java" still
> appears to be a versioned file when in fact it no longer exists in the
> repository. In my example, the edits I made to this file were
> actually automatically transferred to the new file ... Cool!.
That's a special-case behavior added before the general tree conflict
effort started. We'd like to make tree conflict resolution
automatic where possible (subject to config).
> So what
> do I do here? I guess maybe svn resolve would have done the right
We haven't hooked up tree conflicts into the interactive conflict
resolution yet. 'svn resolved' will remove the tree conflict from
the file and allow the update to proceed.
> I did svn revert and the bug I am reporting is that this left
> ColorManager.java in my WC with a status of "Normal". So I edited the
> file and tried to commit and of course get the message that the file
> does not exist. So the bug is that the WC was not handled properly.
> My expectation was that svn revert would leave the file in the WC in
> an Unversioned status.
The incoming deletion of ColorManager.java was skipped due to the
tree conflict. 'svn info -uv' should show that ColorManager.java
is still at the old BASE version, and that it has incoming changes.
A similar situation occurs in stat_tests.py 31 (file 'rho'). There's
a bug currently, in that the BASE is updated despite the conflict.
We're rewriting the "skipping" code at the moment to make it consistent
for all tree conflicts.
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-29 17:18:48 CET