ser@germane-software.com wrote:
> 1) svn diff
> 2) break apart the patches, choose which will be accepted.
> a) Write the entire diff, as a backup
> b) Construct a patch including all of the accepted blocks
> c) Construct a patch including all of the rejected blocks
> 3) svn stat
> a) Keep track of the Adds/Deletes
> 4) svn revert
> 5) Delete all Adds
> 6) Apply the accepted patches (which will re-created the Adds)
> 7) Re-add the accepted Adds, re-delete the accepted Deletes
> 8) Commit the changes
> 9) Apply the rejected patches
> 10) Re-add the rejected Adds, re-delete the accepted Deletes
----------------------------------------------^ rejected ^------
> There's heavy error checking throughout this entire process, and attempts
> to clean up should anything fail. In particular, the commit is a
> dangerous point because of conflicts. If the commit fails, I am left with
> a choice of (a) reverting and patching from the entire original patch, or
> (b) resolving conflicts and then resuming at #8.
I suppose this is fine for simple changes, or changes to human-readable files
where errors don't matter much or can't be checked automatically. For software
source code, I would always want to break this proceure in half and build the
version about to be committed, to check that it is syntactically corect, and
also run regression tests if it was a non-trivial change.
> The entire algorithm was rather simple and straightforward until Adds and
> Deletes entered the picture; then it started to look hackey. Still, it
> works, and my concern is with fringe cases, such as properties; I strongly
> suspect that I'm reaching the limit of what I can do without either
> hooking into the Subversion bindings or turning this little script into a
> full application.
Yes - you will silently lose Subversion properties on added files if you are
just using the traditional "patch" utility.
> There are a number of directions that I can go with this, but only two
> interest me. The first is to rewrite this using language bindings, and
> the second is to hack the svn client itself to support block-level
> commits. If it won't be accepted formally into the SVN code, or if I have
> to maintain it, I won't be doing the second option.
You ought to read the thread "(SoC) Feature proposal: Patch-awareness" by
Matthijs Kooijman <m.kooijman@student.utwente.nl>, at
<http://svn.haxx.se/dev/archive-2005-06/0428.shtml>. You and he both want to
do the same thing, so it would be a good idea if you showed him what you have
already done, and shared ideas and work.
And, as John Peacock said to him, you should also look at the patch management
capabilities of SVK:
<http://svk.elixus.org>
since Chia-liang Kao <clkao@clkao.org> has already got something working. He
uses a traditional "patch" format but with any property changes, etc, stored in
a seperate chunk at the end (encoded) which the conventional 'patch' program
will helpfully ignore. CLK said, "What svk patch stored is just serialized
delta editor calls, along with the target tree/rev that the editor call applies
to. svk patch --apply is able to use such information to perform a 3-way merge
when the target has been changed; it can also update the patch painlessly to
provide a cleanly applicable patch, which makes life easier for people using
plain old /usr/bin/patch."
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 13 19:31:26 2005