On Thu, Jan 17, 2002 at 01:25:37PM -0500, Garrett Rooney wrote:
> >
> > Personally, I would suggest that an extended diff should resemble a
> > shell script closely enough that it could be applied to an exported
> > tree by running it. Metadata not present in an exported tree could
> > be carried along by making it look like comments to sh, and arch or
> > subversion would still be able to find it.
>
> that's a neat idea, but subversion runs on windows, and it would be
> nice to not have to require something like cygwin. if our patch
> format is based in /bin/sh, that sort of ties us to unix like os's.
Just 'cos it could be executed as a shell script doesn't mean you have
to use /bin/sh to interpret it. Lines such as
mv 'old.c' 'new.c'
or
patch 'edited.c' <<\EOF
... patch here ...
EOF
can be parsed perfectly easily by a custom patch-applying program. In
fact, I was assuming that you would write a custom program, so that it
could pick up metadata too, which would be hidden from sh with
comments. A complete patch might look like this:
# extended patch format 1.0 -- cut here and feed to your version
# control system, or /bin/sh in a pinch -- generated by Subversion 1.4
set -ex
# Tree: http://gcc.gnu.org/svn/gcc/
# Change: 23
# Date: 2002-09-21T18:59:06Z
#-Log:
#- Move all C front end files to their own directory.
#-
#- * c-common.c, c-common.def, ...: Renamed c/common.c,
#- c-common-def, ...
#- * Makefile.in: Split out C front end rules to...
# * c/Make-lang.in: New file.
# Files moved without change:
mv 'c-common.c' 'c/common.c'
mv 'c-common.def' 'c/common.def'
# Files deleted:
rm 'c-aux-info.c'
# Files moved and edited:
mv 'c-lex.c' 'c/lex.c'
patch 'c/lex.c' <<\EOF
...
EOF
# Files edited in place:
patch 'Makefile.in' <<\EOF
...
EOF
# Files created:
patch 'c/Make-lang.h' <<\EOF
...
EOF
# End of Patch.
exit 0
In case you're wondering, all of the file names are quoted because
it's easier to write the generators and parsers if you don't have to
worry about which characters are allowed to appear unquoted. Also, I
am explicitly indicating which files are to be patched, and patching
only one file per invocation, because patch(1)'s interpretation of
header lines is inconsistent between versions; this way we sidestep
the whole problem. And, again, it makes life easier for the custom
parser.
Oh, and no line of diff(1) -c or -u output will ever match /^EOF$/, so
no worries about ending a here document in the middle.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:57 2006