On Wed, Oct 29, 2008 at 12:38 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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?
Yes.
>> 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...)
Well there are two issues. The repository has already decided this
file does not exist any more. So if I want the file, I will have to
svn add it. But the current status of the file in the WC would make
this hard to know. In my case, I decided that I want my changes in
the new file, so I want it go away.
>> 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?
Yes, this is from the 1.5 changes. I think it was just dumb luck that
I picked a scenario where this works.
>> 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 am OK with that (although I have not yet figured out how to do it.
I do think we need to make revert pick some default "resolved"
equivalent. Either that or do not let revert run at all.
>> 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.
Well, since I know the file does not exist in the repository any more.
The only valid states I can see for this file would be Scheduled add
or Unversioned. Since I ran Revert, I'd expect it to become
unversioned.
> In any case, users ending up in a conflicted state that is not
> resolvable is unacceptable and needs fixing.
Agreed
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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:44:17 CET