[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    Re: [darcs-users] Language aware darcs
From:       zander () kde ! org
Date:       2005-01-11 18:22:56
Message-ID: 20050111182256.GA15903 () factotummedia ! nl
[Download RAW message or body]


On Tue, Jan 11, 2005 at 05:31:43PM +0100, Sebastian Sylvan wrote:
> On Tue, 11 Jan 2005 05:41:47 -0500, David Roundy
> <droundy@abridgegame.org> wrote:
> > 
> > There are different issues depending on whether one is considering a full
> > parsing or approximate handling of the language.  It's important to have a
> > complete set of patch types that are commutable--otherwise you'd get
> > spurious conflicts due to simply mixing patch types.  The replace patch,
> > for example, commutes well hunk patches.
> 
> Well, the language-specific patches would only need to commute with
> each other and the existing text-based patches.
> So the Python-patches wouldn't have to commute with the Java-patches
> since they never touch the same files.

This implicates you can never change the content-type of a file.
Solution to that might be;  changing the content-type of a file effectively
makes the whole file being 'added' (probably without the real remove/add).
This implies that any change in the file will always depend on the
set-content-type-patch.

> > Also, you can't just parse the file into its grammar, since you need to be
> > able to precisely reproduce the original file.  In C,
> 
> Maybe the grammar could be used to find conflicts, but keep the actual
> change as a hunk. So you wouldn't need to "reproduce" anything. The
> actual modification is still visible, but it has little annotation
> which specifies, in a language specific way, what has been modified.
> That is the patches are basically like they are now, but annotated
> with information helping to figure out conflicts. So if you add a
> function in one file, that patch would be annotated with the function
> name and type and scope etc., and then if you use a function call to
> that function in another patch that change would be annotated with the
> function's name and scope etc. - darcs can then use these annotations
> to figure out that the later patch depends on the former.

That point, while it would be nice, seems impossible to do correct.
I mean (speaking Java here) if I add
    private void method1() { }
in one patch; and later create a patch:
    private void method2() {
        method1();
    }
the second depends on the first; but currently darcs will not know this.
If you suggest darcs can find this out; then the next step is to look
through other files defining methods that I use in my class, and depend
on those to.
So adding method2 to another class (and in java thats another file)
should still make it depend on the first patch.

IMO if you can't do the second dependency (method-usage cross files), its
too confusing to do the first (method usage, same file).
-- 
Thomas Zander

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]