Apply patch suggestions

[Hans-Emil Skogh]

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!

 

Hans-Emil

[Karl Heinz Marbaise]

Hi Hans-Emil,

> 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!))

May be i don't understand what you are talking about, but what exactly
did you mean with "...shelving of changelists..." ?

Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1880230

To unsubscribe from this discussion, e-mail: [dev-uns...@tortoisesvn.tigris.org].

[Hans-Emil Skogh]

>> Oh, I wish that SVN could start supporting shelving of
>> changelists natively!

>May be i don't understand what you are talking about, but what exactly

>did you mean with "...shelving of changelists..." ?

I heard about the concept first from microsofts new source control server, team foundation server. Wikipedia defines shelving of changelists as "shelving is a way to save a set of pending changes without committing them to source control, while still making them available to other users". Technically microsofts solution  is equivalent to a branch.

 

When I think about shelving changes, I mostly think about doing it locally.

 

For example:

You are working on some task in your WC, lets call it task A, but sudenly priotities change. You have to switch to another task now, lets call it task B, and finish task A first when task B is finished.

 

In SVN you can solve this in three ways (that I'm aware of):

1.) Create a branch from your WC. Revert your WC. Finish task B in WC. Switch WC to the branch. Finnish task A in WC. Reintegrate branch to trunk. Delete branch. Switch WC back.

2.) Check out a new WC for task B. Finish task B in new WC. Delete new WC. Finish task A in original WC.

3.) Create a patch from the changes in your WC. Revert your WC. Finish task B in WC. Apply patch to WC. Finnish task A in WC.

 

So, whats wrong with the present alternatives? Well, nr 1 is a bit overkill if the tasks are small. You will end up doing quite a few operations to manage your shelving until you are done. Nr 2 is simple if the WC:s are small. But if you have largish or potentially huge WC:s, it's a real pain. How about nr 3 then? I think that it's closest in terms of convenience, but it's still quite many steps, and you have to manually manage where you keep your patches and how you name the files so that you can find them again...

 

With shelving support, the workflow would look like this:

S.) Shelve changes in your WC. Finish task B in WC. Unshelve changes.

 

Much smoother.

 

If we ignore the part about sharing shelved data it would be enough if the shelved data was saved in the working copy, and technically it would be equivalent to the creating patch-solution described above, with all it's benefits.

 

When I think about it, I guess it would be possible to let TSVN have a patch-store right alongside the log-cache. The patch-store could contain patches, each with a description and a reference to what WC (and repo-path and revision) it was created from.

 

Hans-Emil

[Stefan Küng]

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

[Hans-Emil Skogh]

>> I lately been using the Create/Apply patch - command quite a lot.

...
>> I have a couple of suggestions to make it hopefully a bit more
>> intuitive to use:

...

> 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.

 

Oh joy! I'm really looking forward to that one. I guess it has been in the pipe for quite a while. Hopefully it will make the 1.7 release!

 

> 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.

Makes sense.

 

Hans-Emil