Simon Large wrote:
> Hi folks,
>
> Developer A renames foo.c to bar.c and commits.
> Developer B edits foo.c and updates.
>
> Subversion spots the tree conflict but doesn't know where the file has
> been moved to (the conflict is on foo.c and only bar.c has the
> copy-source info). This means that the conflict editor cannot help
> much. If the user can locate the destination file (bar.c) manually,
> would it be possible for the conflict editor to merge B's changes to
> foo.c into bar.c?
We could show TMerge in diff mode of those two files. But merging would
have to be done manually.
> Assuming that such a merge is even possible, what about the UI? I
> suggest providing a showlog button for the current folder. This won't
> help if the file has been moved elsewhere in the hierarchy, but some
> of the time it will. Once you have identified the destination file,
> the conflict editor needs a file-open dialog to identify it and do the
> merge. I guess it would then also revert foo.c possibly leaving it as
> an unversioned file in the WC, or simply deleting/recycling it. I
> favour recycling here.
There's already a "show log" button. It shows the log of the parent
folder of the conflicted item - since most of the time the conflicted
item itself won't show a log.
About the helping out with UI buttons/selectors/... to resolve the
conflict: I don't think it's a good idea (I know that Subclipse does
this). For several reasons:
* there are still many things the user would have to do manually (find
the correct files, merge manually, ...)
* everything can be done outside the dialog just fine
* there are just too many situations to cover: Subclipse does this for
nine cases (for now, not sure if they want to add more). But there are
much, much more cases (e.g., file gets renamed, but file is removed and
replaced with a directory in the repository). We risk of showing a
completely wrong UI for such situations if we don't specifically check
for it. And checking for every possible scenario - well, do the math...
* Subversion 1.7 will hopefully be able to provide much more information
and do most of the things automatically, so the whole UI would have to
change again
I suggest we just add guides on how to resolve those conflicts manually
to the docs.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1207689
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-02-22 09:10:27 CET