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

Re: Apply patch suggestions

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Sat, 25 Apr 2009 10:40:39 +0200

Hans-Emil Skogh wrote:
> Hi all!
>
> I lately been using the Create/Apply patch - command quite a lot. (It's
> excellent to shelve changes for some time, and then bringing them back
> again! (Oh, I wish that SVN could start supporting shelving of
> changelists natively!)) Anyway, while the functionality is excellent,
> the user interface leaves some things to desire, mostly in the
> user-friendliness apartment. I really noticed this when I explained how
> to some co-workers how to apply a patch...
>
> I have a couple of suggestions to make it hopefully a bit more
> intuitive to use:
>
> When you have selected "Apply patch...", a TortoiseMerge window opens
> with a dialog titled "Select diff file...".
> - I would suggest modifying the name of the TortoiseMerge window to
> "Apply patch", or perhaps "Apply patch - TortoiseMerge" or similar. This
> will make the Apply patch window easy to find in the windows task-bar.
> - The title of the "Select diff file..."" dialog could maybe be a little
> clearer by writing "Select patch file...". The command is called "Apply
> patch", and the default file extension when creating a patch is .patch,
> so I think it would make more sense.
>
> When the patch file is loaded you are presented to an empty
> TortoiseMerge window, with a small "File patches" window that you need
> to interact with to actually apply the patches.
> - Here I would suggest to add two buttons to the "File patches" window:
> "Patch all files" and (if a selection is made) "Patch selected files".
> While these are avaliable in the context menu, it is not really that
> obvious that you have to right click somewhere before you can patch the
> files.
> - Extend the names in the context menu from "Patch all" and "Patch
> selected" to the more clear "Patch all files" and "Patch selected files".
> - Until a file have been selected for "Preview patched file" I think it
> would be better if the main TortoiseMerge-window could be hidden. Now
> the empty window takes a lot of attention, which makes it easy to miss
> the small "File patches" window.
> - Maybe there would be possible to indicate in the "File patches" window
> what file that is open in the TortoiseMerge-window. Perhaps by making
> that file bold? I find it sort of confusing (but good!) that the content
> of the TortoiseMerge-window changes when a new file is previewed instead
> of that a new window is opened. It has happened to me multiple times
> that I forget that no new window has been opened, and I end up closing
> the TortoiseMerge window, and thereby closing the whole Apply patch
> command before I'm finished....
>
> Phew, that was really a handfull... But I love the patch-functionality,
> and I think it could really shine with a little smoother GUI!

All very good ideas. Will take a while to implement though.

Another thing to remember: svn 1.7 will have a new patch format which
includes binary changes and renames/moves. It will also provide a new
API to create and apply such patch files. That means that the diff/patch
feature of TMerge will have to be rewritten anyway, so I'm leaning
towards waiting to implement these changes right now but wait at least
until we switch the TSVN trunk to the svn trunk.

I've filed an issue for this:
http://issues.tortoisesvn.net/index.php?do=details&task_id=435

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=1907374
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-04-25 10:40:54 CEST

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.