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

[Aaron Bentley]

Miles Bader wrote:
> On Wed, Apr 28, 2004 at 09:16:16AM -0400, Aaron Bentley wrote:
> 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.

The differences between the two trees may be longstanding, and NOT 
represent changes made since the last fork/merge/sync-tree/etc.  Also, 
the most recent patchlog for specified-version in the tree is not 
necessarily the most recently merged patchlog.

It would be possible to do what you describe the same way as replay 
--skip-present works: find the latest patchlog from tree-version that 
contains a patchlog from specified-version, and compare with that revision.

Also note that when you specify a revision, changes succeeds even if 
you've never merged anything from specified revision.  So for several 
reasons, changes does not answer the question "what have I changed since 
I merged foo?"

> 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

$ tla changes engine--builds--7.6.4
changes: tree shows no revisions in version
  tree: /home/abentley/7.6.4
  version: engine--builds--7.6.4

In builds, of course, it works fine.

> Since the name of the command is `changes', it makes quite a bit of sense
> that it should you only the _changes_ you've made since VERSION, not those
> plus other random stuff.

To get concrete,

$ tla changes engine--release--7.6.4
* looking for 
address@hidden/engine--release--7.6.4--patch-43 
to compare with
* comparing to 
address@hidden/engine--release--7.6.4--patch-43
[tons of patchlogs omitted]
M  version.cpp
M  install-dist.sh
M  make-dist.sh

install-dist.sh has not changed since I merged patch-43 into builds.  In 
fact, it was changed in the previous version of builds.  The correct 
output would be:

* looking for 
address@hidden/engine--builds--7.6.4--patch-16 
to compare with
* comparing to 
address@hidden/engine--builds--7.6.4--patch-16
A 
{arch}/engine/engine--builds/engine--builds--7.6.4/address@hidden/patch-log/patch-17
A 
{arch}/engine/engine--builds/engine--builds--7.6.4/address@hidden/patch-log/patch-18
A 
{arch}/engine/engine--builds/engine--builds--7.6.4/address@hidden/patch-log/patch-19
M  version.cpp
M  make-dist.sh

> > Other commands (like get, update) use the archive, not the tree to
> > determine the patchlevel, when given a package-version.
>
>
> `update' calculates _two_ revisions in VERSION: it undoes the local changes
> since VERSION -- and that operation uses the tree logs to decide the
> revision, just like changes -- and then and then applies changes on VERSION
> between that revision and the latest archive revision (and then of course
> redoes the undone changes).  So you can't really claim update is one way or
> the other, it's both (and that's its charm).

Yes, though calculating the tree revision makes a whole lot more sense 
to me.

So I can see some value in what you describe, when the question is "what 
have I changed since I merged foo?".  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 TREE and VERSION-LATEST" also.

Anyhow, I won't submit any hasty patches.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.