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 :-)
Simon
--
___
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