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!.
Hi Mark,
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
> thing?
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.
Regards,
Steve
--
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