gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Encoding handling proposal


From: Marcus Sundman
Subject: Re: [Gnu-arch-users] Encoding handling proposal
Date: Tue, 31 Aug 2004 01:12:36 +0300
User-agent: KMail/1.7

On Tuesday 31 August 2004 00:24, Charles Duffy wrote:
> On Sun, 2004-08-29 at 17:29, Marcus Sundman wrote:
> > On Monday 30 August 2004 01:09, Charles Duffy wrote:
> > > Hmm -- being able to view the difference between two files in a way
> > > sensitive to their type without being able to apply those changes in
> > > a way sensitive to the file type seems like rather a waste.
> >
> > Yes, but that doesn't mean the patch file format has to be different,
> > just that it has to be flexible enough to accomodate a wide range of
> > situations. E.g. a diff tool for java source code might notice that a
> > 20 line method you moved hasn't changed at all, so it might write a
> > patch file saying that the corresponding byte range is moved to another
> > offset. A generic text diff tool on the other hand might make a patch
> > file saying 20 lines have been removed and 20 new lines have been
> > introduced at another offset. The latter patch file would be a lot
> > larger than the former, but that doesn't mean they would have to have
> > different formats.
>
> "Move this byte range from here to here" isn't robust against patching
> on inexact input; such a patch would thus be unmergable.

I don't see why the format couldn't support variable size pre- and 
post-contexts. That wouldn't be as nice as a custom, fully context-aware 
diff/patch pair, but at least it'd be as good as the standard gnu diff.

> "Move the method with *this* name to be above the method with *this*
> name" is more robust, and could be applied (or rejected with an
> intelligent explanation about why it won't apply) -- but doing it means
> a file-format-aware diff/patch tool pair.

I agree that such an approach would be more robust, but I don't think the 
benefits outweigh the problems. I strongly believe in having only one patch 
file format, but I wouldn't mind having it support some "fancy" 
transformations. That way features could be added to future diff tools 
without having to update all existing systems.


- Marcus Sundman




reply via email to

[Prev in Thread] Current Thread [Next in Thread]