Simon Large wrote:
> This is a proposal/request to help make patches easier to create and apply.
> Feel free to comment!
> Stefan, feel free to say 'go away ...' ;-)
As soon as I read that, I _knew_ it would mean a lot of work coming my
way ;)
> The current interface has no user interaction/feedback, except to select the
> patch file name, and no way to include a log message.
>
> Create Patch
> The commit dialog is re-used to list the files which have changed and allow
> the user to select the ones for the patch. The user can also enter a log
> message.
Simple enough.
> The patch is created in the usual way using unified diff, then post
> processed to strip out the files the user has not checked. Patch files are
> normally quite small, so this should not require a lot of processing.
You mean it wouldn't require a lot of time for the processing -
implementing it is a lot more work.
> The log message is inserted before the unified diff at the top of the patch
> file between triple square brackets, which has become something of an ad-hoc
> 'standard' for patches on the subversion list:
> [[[
> Log message lines ...
> ]]]
> Unified diff starts here
Yes, that's what the patches on the Subversion mailing list usually look
like.
> At the moment, there is no way to add or delete files (delete just removes
> all lines from the file, add just tries to set properties), and I don't know
> if property changes work either. Not sure if this is due to SVN or TSVN.
Property changes and changes in binary files won't get in a patchfile at
all.
> Anything that SVN does not support should result in an error dialog
> something like this:
>
> -------
> Test2.c - added
> Test3.c - deleted
> -------
> These actions are not currently supported in patch files and will not be
> included. Do you want to create the patch file anyway? [Yes] [No]
> -------
Keep in mind though that a patchfile _can_ add files, and also (kind of)
remove files. An added file is simply created, and a removed file is
left with zero bytes length.
What definitely won't work is moving/renaming - the patchfile doesn't
know that.
> It might be possible to exclude them from the commit/patch dialog to avoid
> this error message, but that would mean more divergence from the Commit
> dialog, and more questions from users about why some files are not there.
correct.
> Apply Patch
> When the patchfile is selected, open a dialog listing the changed files and
> displaying the log message.
>
> The supplied log message should have an additional line inserted at the
> beginning in the form:
> [PATCH] Patchfile.ext yyyy/mm/dd hh:mm:ss
> The time shown is the timestamp of the patchfile
Why do you want the timestamp of the patchfile? Why is that important?
> Buttons here are
> [Open] select a different patch file
> [Apply]
> [Cancel]
>
> If the user clicks on Apply, store the log message in the top level of the
> commit dialog's log history, then strip the log message from (a copy of) the
> patchfile and send to TMerge in the usual way.
I think that TMerge should be the one to show the log message of the
patchfile (it already can parse it, so the filelist would be easier to
implement than in TortoiseProc).
> If the patch is accepted, the log message is available at commit time from
> the log message history. Prefixing the name/date of the file helps to
> identify the correct log message from the history list if there have been
> several attempts at patching.
I think it would be _very_ bad practice to apply several patches with
logmessages without committing them in between.
The problem with patchfiles is that there isn't a standard which can
handle binary diffs, properties and renames/moves (yet). The patchfile
as it is used now was developed for CVS and hasn't changed since.
I'll think of your suggestions - maybe when I'm bored I'll try to
implement something like that ;)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Oct 7 20:33:50 2004