Daniel Rall wrote:
> On Mon, 18 Sep 2006, Mathias Weinert wrote:
>
> > Peter Samuelson wrote:
> ...
> > > I'm still not convinced that "()" is a clearer magic filename than
> > > "/dev/null". The advantage of "/dev/null" is that you can omit the
> > > timestamp in _all_ cases, and I find the lack of such clutter
> > > refreshing when reading udiffs, especially since this usually prevents
> > > the --- +++ headers from wrapping past 80 columns. My own patch
> > > management scripts already remove timestamps from my diff headers, for
> > > readability, and I happen to know I'm not the only one who does this.
> >
> > As already said in an earlier post IMHO the output of mailer.py is more
> > a textual information than a base for any kind of automatic processing.
> > On the other hand there seem to be several people out there who use
> > mailer.py's output to apply patches etc.
>
> While change notification email output is more intended for human
> consumption than machine consumption, occassionally you come across
> some changes to a project that you only have easy access to in that
> form. It's awfully convenient to be able to cut and paste from the
> patch in the notification email....
Agreed.
>
> > So why not defining an additional configuration parameter 'diff_style'
> > with the possible values 'human' which prints the diff labels like
> > suggested (may be using /dev/null for deleted paths) and 'patch' which
> > prints no additional information?
> >
> > Two additional thoughts about this:
> > 1. Although we would introduce two types of diff output, both of them
> > would work with patch if no additional flags are given with the
> > patch command.
>
> The only reason I see for such an enhancement would be if the mailer
> produced truly human-friendly output, such as the diff views in Trac
> and ViewVC, which is not intended to be digested by programs like
> 'patch'.
Also agreed (but implementing something like in Trac or ViewVC is another
story...).
>
> IMHO, adding this complexity and minor additional tool incompatibility
> doesn't seem like the best trade-off for the additional information it
> provides.
>
> > 2. I don't mind using /dev/null for deleted paths. The only additional
> > argument that comes into my mind is that a Windows user will not know
> > anything about /dev/null.
>
> While I agree, () doesn't strike me as particularly more informative.
Okay, so let's use
--- file1 r5 Sun Sep 9 15:40:00 2001 (original)
+++ /dev/null 00:00:00 1970 (empty, because file is deleted)
for deleted files.
Putting all arguments together I suggest
- to change the output of mailer.py's diff as already proposed in
an earlier post
- accept that options -T and -Z may not work properly (which doesn't
make so much sense IMHO because when patching a wc file it should get
a new timestamp)
- with the new form of displaying deleted files
- also apply this change to added files
- without adding the new configuration option diff_style
This leads to diffs which can be used by most patch commands (I am not
aware of any version in which the new proposed format doesn't work where
the old one worked) and which will be more informative for human readers.
Added file:
old: --- (empty file)
+++ dir1/file3 Sun Sep 9 01:46:40 2001
new: --- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ dir1/file3 r1 Sun Sep 9 01:46:40 2001
Modified file:
old: --- dir2/file5 (original)
+++ dir2/file5 Sun Sep 9 04:33:20 2001
new: --- dir2/file5 r1 Sun Sep 9 01:46:40 2001 (original)
+++ dir2/file5 r2 Sun Sep 9 04:33:20 2001
Unchanged copied file:
old: --- file1 (original)
+++ dir2/file7 Sun Sep 9 07:20:00 2001
new: --- file1 r1 Sun Sep 9 01:46:40 2001 (copy source)
+++ dir2/file7 r3 Sun Sep 9 07:20:00 2001 (unchanged copied file)
Copied and changed file:
old: --- file1 (original)
+++ dir3/file8 Sun Sep 9 10:06:40 2001
new: --- file1 r1 Sun Sep 9 01:46:40 2001 (copy source)
+++ dir3/file8 r4 Sun Sep 9 10:06:40 2001
Deleted file:
old: --- file2 Sun Sep 9 15:40:00 2001
+++ (empty file)
new: --- file2 r5 Sun Sep 9 15:40:00 2001 (original)
+++ /dev/null 00:00:00 1970 (empty, because file is deleted)
Is this commonly accepted?
Mathias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 19 09:14:56 2006