[Mathias Weinert]
> > I think the parenthesized text is much too verbose:
>
> The initial intention of my patch was exactly to show more verbose
> texts and information...
Right, but ... I can't believe anyone would think "(empty, because file
is deleted)" is really clearer than "(deleted)".
> > > --- dir2/file5 Sun Sep 9 01:46:40 2001 (r1, original)
> > > +++ dir2/file5 Sun Sep 9 04:33:20 2001 (r2)
> >
> > For modified files, "original" is redundant. That is what the --- line
> > _always_ means, and anyone who knows unified diff format _knows_ this.
>
> Agreed. But as "original" is already part of the current mailer.py
> output I let it stand there.
Well, you're changing the rest of the strings, I'd go ahead and change
that one too.
> since revision 21310. Since this revision "copied" only reports
> files that were copied and not changed and shows the complete file
> (as if it was added). Before this revision such files weren't
> reported at all.
I asked about this (the diff which is shown for a copy, and for a
copy+modify) for two reasons: first, it is not obvious what the _right_
behavior is ('patch' requires a whole file in both cases, but human
readers would usually prefer an incremental diff, which is empty in the
one case); second, the optimal format of the diff headers depends on
exactly what is presented.
> This again makes me think about an option diff_style or something
> similar, althoguh I am not totally convinced that this is necessary.
The copy, rename (copy+delete), copy+modify, rename+modify and delete
cases all have different optimal behavior for someone proofreading the
patch vs. someone applying it with 'patch'.
This makes me wonder if it's finally time to formally specify a "udiff
with metadata" format, to be generated and applied to working copies by
some contrib/client-side/svndiff.{py,pl}. This format would:
- represent all possible changes to a working copy, in a parseable way;
- be as human-readable as possible;
- be based on unified diff, which is the most readable line-based diff
format I know of;
- be usable by GNU 'patch' and compatibles, with the caveat that things
that patch can't handle natively, like renaming, property changes,
and their effects (svn:eol-style and svn:executable), will not work
I don't know that binary files can be represented without compromising
readability. base64 with variable line lengths?
Received on Wed Sep 20 21:10:21 2006