pre-commit hooks and $Id$ banners?

[Jan Hudec]

On Wed, Apr 26, 2006 at 15:00:56 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jan Hudec wrote:
> > On Wed, Apr 26, 2006 at 13:57:02 -0400, Aaron Bentley wrote:
> >>It would not surprise me if many script authors assume exactly what John
> >>posted.  An empty diff does mean no content differences, AFAIK.
> >>('Binary files differ' is not 'empty')
> > 
> > Yes, but that is an argument for diffing with expanded keywords rather than
> > collapsed, which is how I unerstod the original thougt.
> 
> I expect there are arguments that can be made both for and against
> treating two different expansions of the same internal representation as
> different.  I think it's simplest to treat two files as identical if
> they have the same internal representation.  Otherwise, bzr diff is next
> to useless.

I think, that both diff and patch should work by taking the inputs,
converting them to internal representation *line at a time* and keeping the
unconverted lines as well. Then compare the internal representations with
each other resp. patch context and emmit the external representation (which
may have to be created) to the output. This would be pretty tricky if the
conversion can actually add and remove lines, which some keyword expansions
may want to do!

> >>An alternative would be diff the internal representation, and to do
> >>patch application on the internal representation, also.  That would
> >>allow patches with differing line endings to work properly.
> > 
> > Yes -- but would need a bzr-aware patch. Ie. we can have bzr changesets that
> > will work properly on working trees with different expansions, but they won't
> > be always applicable by standard diff.
> 
> There is already a patch command in bzrtools.  It would need some
> tweaking to get it to accept two files as input, I suppose.
> 
> > Note, that applying such changeset is still not trivial, because the
> > conversion to internal format and back is not necessarily identity.
> 
> I think it's simplest to require that such conversions be identity
> conversions.  Are there examples in which you think they shouldn't be?

Actually neither keyword expansion nor line endings conversion is.
For keyword expansion say you have a file saying:

    $ Revision: blabla $

then it will convert to internal to:

    $ Revision: $

and back to external to:

    $ Revision: 123 $

(123 being whatever current revision is)
Similarly for newline expansion the sequence:
    \r\r\n\n\n\r\n\r
will always convert internal representation to:
    \n\n\n\n\n\n
which will convert back to external to:
    \r\n\r\n\r\n\r\n\r\n\r\n
on windows,
    \n\n\n\n\n\n
on unix and
    \r\r\r\r\r\r
on Mac (ok, we don't support MacOS before MacOS X and that is unix, so
perhaps it switched to \n -- that doesn't matter, really), neither equal to
the original sequence.

So conversion internal -> external -> internal may be required to be
identity, but it does not hold for external -> internal -> external, when the
external is not unmodified result of conversion from internal.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060426/d5e911be/attachment.pgp