Peter Samuelson wrote:
>
> [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)".
Agreed. But I think that "empty, because file is newly added" is clearer
than "empty" (and "added" would be not correct).
>
> > > > --- 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.
All right.
>
>
> > 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
Good idea. But, to be honest, out ouf my focus at the moment, although
I already provided another patch for mailer.py where I also report
property changes and therefor had to define a header format for property
changes, too. But also in that patch the focus was on readability and
not to provide something to automatically apply property changes to
a working copy. But, as said before, it's a good idea to create
something like svndiff.py (and then include it in mailer.py, may be
option driven).
>
> I don't know that binary files can be represented without compromising
> readability. base64 with variable line lengths?
Mathias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 21 11:12:11 2006