I've been working to polish up my new version of webrev. One of the
features I've added is that webrev generates a patch of the changes.
The question I've hit is: how should we handle renames? Currently, I
have output as follows. Let's say you've renamed
usr/src/cmd/zlogin/Makefile to usr/src/cmd/zlogin/fakefile. The patch
output will be:
--- usr/src/cmd/zlogin/Makefile Mon Sep 11 23:06:16 2006
+++ /dev/null Wed Sep 27 11:24:43 2006
@@ -1,47 +1,0 @@
-#
-#
-# CDDL HEADER START
-#
-# The contents of this file are subject to the terms of the
-# Common Development and Distribution License (the "License").
-# You may not use this file except in compliance with the License.
-#
<..... snip: rest of file is here........>
-lint: lint_PROG
-
-include ../Makefile.targ
--- /dev/null Wed Sep 27 11:24:43 2006
+++ usr/src/cmd/zlogin/fakefile Mon Sep 25 21:15:35 2006
@@ -1,0 +1,47 @@
+#
+# CDDL HEADER START
+#
+# The contents of this file are subject to the terms of the
+# Common Development and Distribution License (the "License").
+# You may not use this file except in compliance with the License.
+#
<..... snip: rest of file is here........>
However, patch(1) rejects this outright, and gpatch(1) prompts me for
filenames and doesn't seem to want to create usr/src/cmd/zlogin/fakefile
for me. Is there any way to make this work right? There are some hints
in the gpatch(1) man page but they reference options that Solaris diff
doesn't have, and the advice about using /dev/null with the UNIX Epoch
timestamp didn't work for me. So, I'm slightly at a loss.... obviously
I could just punt on handling renames but I was hoping for this to be
mostly reliable.
(It's also *really* irritatingly asymmetric that we have /usr/bin/gpatch
but not /usr/bin/gdiff...)
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
tools-discuss mailing list
[email protected]
