[Top][All Lists]

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

Re: [Gnu-arch-users] Ruminations on Arch Desiderata

From: Tom Lord
Subject: Re: [Gnu-arch-users] Ruminations on Arch Desiderata
Date: Wed, 17 Sep 2003 07:52:49 -0700 (PDT)

    > From: Doran Moppert <address@hidden>

    > On Tue, Sep 16, 2003 at 09:18:22PM -0700, Tom Lord wrote:
    > > There is a feature idea that floats around on the back burner for
    > > making it possible to declare a particular file to be of some specific
    > > (non-diff-patchable) type.....

    > back burner? Damn ... I thought that it would be a natural extension on 
    > inventory tagging mechanism to be able to associate "types" with files, so
    > that alternative (pluggable) diff/merge tools could be used.

That's the idea, yes.   "Back burner" only because demand for other
features has been higher.

I mentioned the back burner idea precisely to suggest what direction
to start thinking/hacking in if you want something like, say, support
for multi-fork files.

    > To bring up one of your favourites, XML can be diff/patched with
    > specialised programs easily (err freshmeat for xmldiff). And
    > while tools don't exist for a lot of other binary formats, it
    > would be beneficial (for me at least) to have the capability in
    > an RCS.

Absolutely, yes.

A not _absolutely_ necessary property of pluggable diff/patch tools is
that they should support inexact patching.   In other words, if I have
three files, no two equal, A, B, C -- each of a certain non-textual

        Xdiff A B > ,tmp

        Xpatch -o D C ,tmp

should produce is a D which is a valid file of the same type, ideally
merging the changes from A to B.   It may produce a "rejects"
annotation which should, if at all possible, give the user enough raw
data to merge any unmerged changes "by hand".

    > <think iteration=2>
    > then again, maybe this is orthogonal to inventory tagging and should be
    > handled with /bin/file .. but of course file is imperfect.

    > actually format-specific visual diff is a human interface issue: best 
left out
    > of arch lest I start distributing changesets that rely on some arcane tool
    > I've hacked up ....
    > </think>

    > Sounds like you were right. Ignore this message :)

Sounds like I was right but you interpreted me wrong :-)

I think you're on the right track: typed files, _probably_ associated
with the inventory mechanism, pluggable diff/patch tools --- yup.


reply via email to

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