On 18 October 2011 07:35, Wayne Johnson <wayne_at_zk.com> wrote:
> Thank-you for including something constructive instead of just saying
> "it sucks because it confuses me fix it."
+1
>> To make the discussion a bit more constructive, I'd imagine a dialog
>> layout like this, that would help me quite a bit:
>> http://i56.tinypic.com/e7nj9s.png
This screenshot is based on 1.6 I think, although that dialog has not
changed a great deal in 1.7. This is not a new problem - it has been
there for at least the last 2 years.
OK, I hate to admit it but when I think about it again, I'm confused
too, and I wrote the docs, dammit! The root of the problem is that the
term 'merge' is overloaded.
When you update your working copy, repository changes are merged with
your local changes. In that situation the 'prefer local' and 'prefer
repository' make perfect sense. The instructions for generating that
screenshot are in fact based on doing a merge during update.
What we are talking about here is a merge from a different path into a
clean working copy. In that case both sets of changes (relative to the
branch point) are already committed in the repository and they being
merged in a working copy. There are no local changes (*) so the term
'prefer local' is indeed confusing. What it in fact means is the
repository changes for the working copy URL, so you go with what was
in your working copy rather than what is coming in from the merge
source - possibly obvious when you think about it, but you do have to
think about it, which is what people here are complaining about.
I can certainly fix the docs, but I'm unsure how to improve the dialog
as I cannot at the moment come up with an alternative button label.
Showing paths is one way, but only works when the paths are short, and
I'm not sure it makes it that much clearer anyway. Another option
would be to put tooltips on the buttons. Prefer Local could have
something like "Discard incoming lines which conflict and keep what is
already there" and Prefer Repository could have "Accept incoming lines
which conflict in preference to what is already there". I think those
descriptions apply equally well to the update merge and the, er, merge
merge.
OTOH the reason I have never bumped into this myself is that I have
never used those buttons. I would always use Edit Conflicts and
recommend others to do the same. Unless you know exactly what the
conflict is then it is dangerous to auto-resolve conflicting lines.
Simon
(*) there could be local changes if you merge into a modified working
copy (not recommended), or if you are merging several separate ranges,
but that is not what we are talking about.
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2858628
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-10-19 00:54:07 CEST
