[Top][All Lists]

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

Re: [Gnu-arch-users] PyArch newbie observations/questions

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] PyArch newbie observations/questions
Date: Sat, 29 May 2004 00:40:20 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

Good grief. This has been banging around inside the gnu mail system for 3 days! Feel free to use reply-all to me.

David Allouche wrote:
On Tue, May 25, 2004 at 09:54:39AM -0400, Aaron Bentley wrote:
That should be a method in WorkingTree, something like:

def changes(self, link=False, output=None)

I'd rather see delta as a command than changes, since changes can (mostly) be implemented in terms of delta.

Presumably, it can take a DirName or a revision type for either parameter.

I think DELTA would rather be a top-level function like:
      a: Revision|ArchSourceTree
      b: Revision|ArchSourceTree
      out: DirName
  => Changeset

Well, it could be
def delta(self, from=tree_latest_revision(), to=tree_root(), output=None):

With no arguments or with just "to" specified, it would behave like changes.

In my understanding, CHANGES is different from DELTA in several

   1. CHANGES can save its output changeset under a default name in the
      tree-root, named after the master revision.

True.  I'm not aware of a use for this, though.

   2. CHANGES can accept a "limit file set" (oh! that needs to be
      supported too) in a way similar to COMMIT.

AFAIK, the CHANGES limit doesn't work.

   3. CHANGES uses the tree-revision by default.

True, but I don't see that being a big advantage, when we can easily determine the tree revision. I expect pyaba to pass a revision argument to changes/delta 99% of the time.

   4. CHANGES is used in different contexts than DELTA, and though it is
      essentially based on a subset of the functionality of DELTA, I
      consider it as an important "library" operation.

I think delta could be used in the same places just as conveniently, if it had sensible defaults.

      On the other hand, DELTA _is_ a fundamental operation of the
      archive layer (unlike CHANGESET which is a fundamental operation
      of the changeset layer) because it is an extension point for
      transparent optimizations (pristines cache, revlib, smart server).

You are welcome to debunk my arguments, so far I think providing a
WorkingTree.changes method would be generally useful and convenient.

I won't stand in the way of WorkingTree.changes, but I do want to have (and use) delta.

What about the stuff changes dumps to stdout, and the diffs output?

The Changeset class should provide all that information in a convenient
and efficient way. The diffs output looks like a CLI convenience feature
to me, not to be supported explicitely in PyArch.

The changeset output is nice to have for Pyaba. To colorize it the right way, we'd need to parse the leading letters.

Well, I can imagine the incremental output being useful to provide
visual feedback, but it would not really fit the bill (it cannot be used
to provide an ETA) and I do not see offhand how to make it fit in the
current framework.

That could be supported using an extended version of
arch.util.StringOutput (passed as a keword argument to
arch.WorkingTree.changes and, but that would need much more
reflexion to get it right.

It seems to me that we'd want a per change iterator.

Obviously, the "link" option enable source tree relinking with the
revision library.

Yeah, although that's logically distinct functionality, so it wouldn't be terrible to provide a different function for it.

I admit I am not sure about that choice. The reason why it was done that
way in tla was because relinking requires doing the greatest part of the
work of CHANGES, and doing it in one place prevented code duplication.
It is a feature of libtla that CHANGES is used to perform relinking..

My argument pro a relink command is that relinking isn't at all central to the functionality and purpose of changes. It was convenient to stick it there, but it doesn't really belong there.

  -- Practicality beats purity.

     Is it a common occurence for scripts to take the opportunity of
     computing the changes to perform relinking? That's a good question,
     and one I am unable to answer.

Me too.  I don't often hard link my trees.

     By the way, why does "tla commit" not support relinking?

No one seems to have cared enough, and at the time I implemented relinking, I wasn't brave enough to fiddle with commit.

As you can see, I have not quite made up my mind yet...

On second thought, the correct signature for CHANGES could be:

      [output: DirName, default: to the ,,what-changed-* name]
      [master: Revision, default: tree-revision]
      [file_list: iterable of PathName, default: empty]
      [link: bool, default: False]
  => Changeset

It could also raise a TreeLintError if the tree is not commitable, and a
"strict" boolean keyword argument to control when to raise such an
exception. But that would require multiple tree inventories, and that
would be a big performance penalty.

You could avoid doing tree-lint except when there's a lint failure (exit status 2)

For the sake of expressiveness and to support future optimizations, we
also need a companion method:

      [master: Revision, default: tree-revision]
      [file_list: iterable of PathName, default: empty]
  => bool

This is a common operation to check only for the _presence_ of any
change, it could be implemented more efficiently, since the outcome is
known once any change is detected, and it does not required the creation
of a changeset on the disk. Currently, that would be implemented using
"tla changes" without --keep or --output.

Sure. In fact, I'd like a arch.WorkingTree.has_no_changes() function that throws an exception if changes are present.

tree-lint is a big problem...

Without any option, the output is difficult to parse and is prone to
changes, so that's not really reliable.

Frankly, I do not even have a clear idea of what the output of tree-lint
looks like in the general case.

Lists of files, with headers:

These files violate naming conventions:


These apparent source files lack inventory ids:


These explicit ids have no corresponding file:


That output actually looks unambiguous to me, since it has two newlines between the end of a file list and the heading of the next list.

There's also the option of adding an easily&reliably-parsed output representation to tree-lint. Also, I'm a bit confused about how I should be importing pyarch into pyaba. Should I be adding pyarch/arch to my PYTHONPATH? Sticking it into my pyaba directory as a nested tree?

That's not a PyArch specific issue.

Yeah. Like I said, I'm a grasshopper. I didn't even know Python lacked destructors 'till today. I miss RAII already.

Here's a PyArch-specific issue. I could ship pyaba with PyArch in a subdirectory. I'd forward any revisions that affected PyArch to you, of course.

Anyhow, the current release uses the PYTHONPATH. Maybe I'll change that approach in a later release.


reply via email to

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