On Thu, 2009-01-22 at 11:20 -0500, Mark Phippard wrote:
> On Thu, Jan 22, 2009 at 11:07 AM, Stephen Butler <sbutler_at_elego.de> wrote:
> > Quoting Mark Phippard <mphippard_at_collab.net>:
> >
> >> On Thu, Jan 22, 2009 at 9:56 AM, Julian Foad <julianfoad_at_btopenworld.com>
> >> wrote:
> >>>
> >>> FYI I'm just about to look at this.
> >>
> >> I added an svn info to the script to look at the tree conflict. The
> >> problem is that after running update the local revision in the WC for
> >> the folder is 1 when it should have been updated to 2 by the update
> >> command. So this is why it is out of date when you try to commit.
> >> When the tree conflict was created it should have still allowed the WC
> >> revision to be updated.
> >
> > Turning off the skipping of tree conflict victims is pretty
> > straightforward, at least for this use case (#1 in
> > notes/tree-conflicts/detection.txt).
> >
> > What should we do if the user runs update again without resolving the
> > existing tree conflict first? Skipping is not an option.
>
> I've never really grokked why we'd skip updating something, but I am
> sure there are some reasons.
In text conflicts, it's hard to imagine how we could do better than
skip, so we just skip. In tree conflicts, likewise, except now I think
about it it might not be too hard to design how to "compose" two tree
conflicts together... at least in some cases, such as when one of the
conflicts involves deleting the node.
> Clearly the current situation is worse
> though. You cannot commit, because you are out of date, and if you do
> update again after resolving the tree conflict all it does is create
> it again.
Note that the work-around is (should be) to mark as resolved, revert the
schedule-delete, update, then re-schedule the delete:
svn resolved wc2/A/B/E
svn revert -R wc2/A/B/E
svn up wc2
svn delete wc2/A/B/E
Seems to work for me.
I'm not saying that's good, just possible.
- Julian
> > I suppose we could record a new tree conflict, possibly overwriting
> > an existing tree conflict. It could get confusing if the user
> > updates and raises a tree conflict in dir A, then later updates dir
> > A/B and raises a new conflict in A/B. Now there are two tree
> > conflicts in the same tree. This could happen in everyday situations
> > such as an interrupted update.
> >
> > Does anyone see a problem with overwritten or redundant tree
> > conflicts?
>
> If this means we need to potentially overwrite one tree conflict with
> a newer one, than I guess that is what we would need to do. We cannot
> leave things as they are.
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1043323
Received on 2009-01-22 17:44:05 CET