> ser@germane-software.com wrote:
>> 10) Re-add the rejected Adds, re-delete the accepted Deletes
>
> ----------------------------------------------^ rejected ^------
Right.
> 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.
Darcs allows pre-commit checks on a patch set. I'd could easily add a
flag forcing the script to break just before the commit, providing the
user with a working copy that just contains the accepted patch set. They
could then resume the commit. This is what currently happens
automatically if there's a commit error (such as a version conflict). If
I wanted to get more fancy, the flag could take an argument that is
executed, and only if the process fails does the script exit. Say,
something like:
svb -t 'make test'
That's a good idea, thanks.
Honestly, though... before we go too much further than this, I'm really
trying to restrict what this thing does... see my comments about SVK,
below.
> 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
Thanks.
> And, as John Peacock said to him, you should also look at the patch
> management capabilities of SVK:
My main problem with SVK is twofold:
1) I've never set it up and *not* had trouble installing it.
2) It adds a whole level of infrastructure that I'm entirely uninterested
in. I don't want to use a local repository and push changes back to a
local server. If I wanted to do that, then -- honestly -- I'd just use
darcs.
My little script is exactly that: one file, with three dependencies: Ruby,
svn, and patch, and Ruby is the only one that might be an additional
install.
SVK is an impressive project, but is overkill for what I want, which is
finer control over what gets committed.
--- SER
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 13 21:34:11 2005