On Wed, Oct 29, 2008 at 11:58:45AM -0400, Mark Phippard wrote:
> 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.
So you renamed ColorManager.java to MyColorManager.java, is 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
> Name: ColorManager.java
> URL: file:///Users/mphippard/repositories/svn-1.6/trunk/src/com/acme/ui/editors/ColorManager.java
> Repository Root: file:///Users/mphippard/repositories/svn-1.6
> Repository UUID: a0b8b0e8-12cc-4994-9ac8-95a1682d52c6
> Revision: 4
> Node Kind: file
> Schedule: normal
> Last Changed Author: mphippard
> Last Changed Rev: 3
> Last Changed Date: 2008-10-29 11:44:29 -0400 (Wed, 29 Oct 2008)
> Text Last Updated: 2008-10-29 11:45:02 -0400 (Wed, 29 Oct 2008)
> Checksum: df4e1705289bff7b74b555fa1ffc549d
> 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.
Right. The question is really whether *you* want it to stay a versioned
file. Someone decided to rename it, but maybe you really don't want
that rename to have happened? I guess you would expect having to re-add
the file at the old location if you wanted to keep it? I think currently
you're expected to locally delete it if you don't want to keep it (which
may not make sense, actually...)
> In my example, the edits I made to this file were
> actually automatically transferred to the new file ... Cool!.
Wow, I wish I knew why :)
AFAIK we have not yet added support for moving changes between moved
files. Maybe this has got to do with the copy improvements made in 1.5,
rather than the tree conflict work?
> So what
> do I do here? I guess maybe svn resolve would have done the right
> thing?
Well, the theory goes like this:
First, you think about what you want the merge result to be.
Then, you make the neccessary changes to your conflicted state
to achieve this result and run 'svn resolved' on the tree-conflicted
file (currently, you may still have to run 'svn resolved' on the file's
parent directory instead of the file itself, I'm not sure whether we've
fixed this yet).
> 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.
That sounds like a logic error we made here. Not sure how to handle
this. We agreed in the past that simply dropping a file from version
control was unacceptable because changes could get lost when the user
then forgets to re-add the file. However, now that we are screaming
"TREE CONFLICT" at the user anyway, we may want to reconsider leaving
the file unversioned (and saying so in the conflict description).
> My expectation was that svn revert would leave the file in the WC in
> an Unversioned status.
Because your initial expectation was also that the file would be
unversioned? I'm not saying this expectation was wrong, but we
need to agree upon what would be the best thing to do here.
In any case, users ending up in a conflicted state that is not
resolvable is unacceptable and needs fixing.
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-10-29 17:38:41 CET