[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: Aaron Bentley
Subject: Re: [Gnu-arch-users] Changes consulting project tree to construct revision
Date: Wed, 28 Apr 2004 14:03:36 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

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 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

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 Bentley
Director of Technology
Panometrics, Inc.

reply via email to

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