[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflict merry-go-round on update/switch

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 26 Nov 2008 20:19:45 +0000

On Wed, Nov 26, 2008 at 07:30:10PM +0000, Julian Foad wrote:
> I talked to Mike and Mark about this today but I didn't think of this
> "diff" issue then. We agreed that if it makes the user experience vastly
> better we should do it, even if we don't yet do the corresponding thing
> for the other kinds of tree conflict on update. We can treat this as a
> step forward from broken (not noticing a conflict) to good, and the
> other cases as a smaller step forward from broken (not noticing) to
> better (noticing but being awkward to resolve).
> I want to do this now. If we don't get all of the cases done now, we can
> then see whether the community thinks it is acceptable to improve the
> behaviour of the other cases in a point release, or else do it in 1.7.


But let me add (tounge-in-cheek):

  svn devs: We need feedback by research monkeys^W^W users to find out
            what exactly we should be doing here.
  users: Wait, didn't you have it designed perfectly from top to bottom
         before you implemented this?
  svn devs: er... no...
  users: But isn't that what your own policy says???
  svn devs: Well, look, it's a hard problem... CVS couldn't do this!
            See merge-tracking... you like merge-tracking, don't you?
            Besides, there is a chicken-and-egg problem -- you have
            not told us yet how *you* want tree conflicts to behave...

We should be prepared to get any kind of feedback.
(I'm not saying that this would be any different if we did not
do what you propose, we need feedback either way.)


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-26 21:20:01 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.