[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: Tue, 25 May 2004 09:54:39 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

David Allouche wrote:
Yeah! Feedback on PyArch :-)

Here's more :-)

Are there mappings to changes/what-changed? (If nothing else, I'm
frequently going to want to know if a working tree has uncommitted
changes; I may or may not care what they are).

No there are not. Patches welcome.

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.

If output is set, it should be a string, and the changeset will be saved
under this name. On normal termination, the method returns a Changeset
object whose string value (remember, changesets are DirName objects, so
they are string objects) is equal to output.

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

It might make sense to special-case output=True and use the filesystem
name given by tla when the option --keep is given without --output
option. That's an option if the changeset name is predictible in a
race-free way.

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. There was considerable wailing and gnashing of teeth when I made it an option to "changes" in the first place.

How about tree-lint? Parsing the output may not be a trivial feature to add, but even an output status indicating errors/warnings/clean output
could be useful.

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.

There's also the option of adding an easily&reliably-parsed output representation to tree-lint. We could ape "inventory"'s leading-letters scheme, or produce a directory:


That could be factored out into the
RevisionIterable, VersionIterable, BranchIterable, and CategoryIterable

I don't understand why these are inherited from each other, since all they do is redefine inherited functions to throw exceptions. But I'm just a grasshopper when it comes to Python.

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?

Aaron Bentley
Director of Technology
Panometrics, Inc.

reply via email to

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