[Top][All Lists]

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

Re: [Gnu-arch-users] Changes consulting project tree to construct revisi

From: Miles Bader
Subject: Re: [Gnu-arch-users] Changes consulting project tree to construct revision
Date: 29 Apr 2004 09:23:28 +0900

Aaron Bentley <address@hidden> writes:
> > Besides being nicely self-consistent, I think it's basically the `right
> > thing', and quite useful:
> > 
> >   tla changes VERSION
> > 
> > currently provides you with the changes made in the project tree subsequent
> > to the last time the project tree was forked/merged from VERSION.
> I'm not aware of any other command that calculates VERSION-TREE-LATEST, 
> but maybe I'm just ignorant.
> Actually, it reports the differences between that revision and the 
> project tree, which is another thing.

My wording was perhaps imprecise:  I mean `Changes in the project tree's
_version_ relative to the last merge point with VERSION.'  That is,
`What changes does TREE-VERSION represent relative to VERSION?'

Because the development in TREE-VERSION, to the degree that it is
derived from VERSION, is all with respect to VERSION-LAST-MERGE, this
gives you consistent and stable results.

Thus you don't have to worry about what happens on the VERSION branch
until such time as you decide to merge in later changes from it.

> The differences between the two trees may be longstanding, and NOT 
> represent changes made since the last fork/merge/sync-tree/etc.

Yes I know; my wording was imprecise, but I was thinking the way you

> Also, the most recent patchlog for specified-version in the tree is
> not necessarily the most recently merged patchlog.

Huh?  Why does that matter?  If you're explicitly specifing VERSION,
then you want to know how TREE-VERSION looks relative to VERSION not
`whatever version happens to be the most recently merged'.

If TREE-VERSION merges from multiple branches, this may be confusing,
but that's pretty much inherent in complicated merge relationships, and
you basically just have to know what what you're doing -- and I think
your proposed change would make it _worse_!

> > If you used the _archive_ to decide the revision of VERSION to use, then it
> > would provide you that intermingled with the _reverse_ of other random
> > changes done to VERSION since you last forked/merged from it.
> Which was exactly what I wanted.  I wanted to see what the differences 
> were between my "release" and "builds" branches.  build gets merges from 
> release, but release never gets anything from build.  In release, I did

Yes, I realize that's what you wanted, and certainly that's useful
functionality, but I don't think it's an appropriate default for the
`changes' command.

> So I can see some value in what you describe, when the question is "what 
> have I changed since I merged foo?".

Sure, and that's what the `changes' command means.  Look at the command name.

> But I think there are better ways of answering that.  And I see a lot
> of value in answering the question "what is the difference between

Sure that's useful, but it's an awkward fit for the `changes' command.
Look at the the wording in the sentence you wrote.

For arbitrary differences, there's a handy command: tla delta.
Perhaps it should accept VERSION arguments too, and default to the
latest archive revision?

`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

reply via email to

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