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

Re: Issue #386 - conflict resolution callback

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: 2007-10-14 23:34:02 CEST

On 14/10/2007, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Simon Large wrote:
> > Hi Stefan,
> >
> > The comment in the issue states that the implementation is not good
> > enough yet. I have only seen it once (due to trying to merge out
> > revisions which had not been merged!) but it looked pretty good. I can
> > think of only two improvements:
> >
> > Add the word 'or' between the rows of buttons:
> >
> > Choose item: [ Use local ] [ Use repository ]
> > or
> > Resolve conflict [ Edit conflict ] [ Resolved ]
> > or
> > Leave conflicted [ Resolve later] [ Resolve all later ]
> >
> > Also add a help button to take the confused user to the correct page
> > in our docs. Unless I am missing something obvious, this all seems
> > pretty straightforward.
> Ok, done in revision 10996.
> Note: once the docs contain a section/chapter about that particular
> dialog, we have to add the <?dbhh topicname="HIDD_CONFLICTRESOLVE"?>
> part to link the help button with that doc part.

OK, I'll do that.

> > One other question - one complaint is that checkouts, updates,
> > switches, merges, etc can fail if there is a file already there with
> > the same name. People ask "why can't the checkout continue and let me
> > fix the problem after". Would the resolution callback help with that
> > one?
> Is this still the case? SVN 1.5 has the ability to silently version
> those items. If the already existing file differs from the one the
> checkout/update/switch/merge would add, then the file is marked as
> 'modified'.
> Last time I checked, this worked ok. If you found a situation where you
> still get a conflict, let me know and I'll investigate.

I didn't actually check, just thought it might be a use case.

> Something related:
> Subversion 1.5 allows the conflict resolving during an operation not
> only for merges but for all commands. I've only 'activated' this in TSVN
> for merges since this helps when doing multiple merges (or have SVN
> doing multiple merges due to the merge tracking skipping already merged
> revisions).
> But I left it as before for updates/switches/... because I think it
> doesn't help much: there's no big difference whether you resolve a
> conflict right when it happens or after the command has finished. You
> won't gain anything by resolving the conflict right away, but it
> interrupts the command.
> So, what do you think: correct decision?

I agree. Activating it there will only slow down the update switch. If
you start a big update and go off for a coffee, you would be really
annoyed to find it stalled after a couple of files.

It is only really useful for allowing an operation to continue which
would otherwise fail - perfect for multiple merges :-)


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Oct 14 23:34:13 2007

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

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