Re: [Gnu-arch-users] BUG: extra diff arguments for "tla changes --diffs"]

[Aaron Bentley]

Miles Bader wrote:
> On Wed, Aug 25, 2004 at 02:12:54PM -0400, James Blackwell wrote:
>
> > > Please say _why_ it's a bad idea, i.e. give an example of how someone might
> > > be screwed by this.
> >
> > Its a bad idea because that opens us up to the risk that people will
> > generate and start passing around changesets that aren't portable.
>
>
> For instance?

For instance, if you alter the number of lines of context, you can screw 
up inexact patching.  (which is a major use of changesets).  If the 
person who generated the changeset tests it, they'd probably only test 
exact patching, not inexact.

> I suppose it's conceivable that there are option combinations that could
> cause some problem, but I can't see that any common options (e.g.: -p [to get
> function info in the hunk header], whitespace relaxation options,

Whitespace relaxation options could quite conveivably screw up inexact 
patching, by causing patch to perceive a match where there isn't one.

And some diff options produce patches that aren't reversible, which 
would definitely suck.

> context-size modification options) will.  As long as you use one of the diff
> formats that makes sense (unified, context -- but I think patch will even try
> to apply ed-style diffs!), patch is pretty good at handling what diff throws
> at it.

I think if we stick to one standard, we'll be better able to guarantee 
that existing tools handle it well.  tla already has test cases to make 
sure that the diff version handles unified diffs properly.  Supporting 
context diffs is an additional testing burden.  Same for other options.

Reducing the level of standardization makes it harder to write 
additional tools.  I want to be able to edit a changeset and remove 
unwanted changes.  I want to be able to determine which lines a 
changeset touches, and how the lines are renumbered afterward.  I want 
to be able to do changeset composition, and merge two changesets into 
one.  I even want to subtract changesets from each other.  Every 
additional format the tools must support makes them more complicated to 
write and maintain.

So let's flip the question around: why *should* you be able to apply a 
non-standard changeset?  How do those advantages outweigh the loss of 
simplicity?

I'm not against *producing* non-standard changesets.  I'm all for making 
tla's output more human-readable.  I just think that they should have a 
file =NON-STANDARD in them, and that tla should refuse to apply them by 
default.  If you really want to apply them, you can always delete the 
file, or add a commandline switch to apply-changeset.

> > I think a changeset should be a changeset should be a changeset. *very*
> > predictable and stable.
>
>
> I don't see why they're any different than patch files (really, tla's
> changeset stuff is just super diff + super patch).

I see changesets as another format, which perhaps diff and patch will 
one day support, in addition to unified diffs, context diffs, RCS diffs, 
ed diffs....

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.