Re: [Gnu-arch-users] Re: cached rev support in pyarch

[Aaron Bentley]

David Allouche wrote:
> On Fri, Jun 11, 2004 at 09:30:02AM -0400, Aaron Bentley wrote:
> Okay, but should the cache directory be a tree-root, or a directory
> containing zero or more arch source trees?

That's a part of the builder I haven't paid a lot of attention to.  A 
quick read suggests that a pristine cache is something like a revlib.

> Yes, it is hard. But only cataloging the exceptional conditions and
> raising them in the common case, even if there are corner cases, would
> be vastly useful. Right now, I am still trying to figure out what would
> be the correct exception classes.
>
> I envision several solutions to the exception classification problem:
>
>   1. Check input for sanity when it enters the pyarch framework.

This is fairly safe, but may occasionally guess wrong.  I did that 
recently with 'update'.

>   3. Interpret error messages.

Should be pretty effective, when the messages are easy to parse.  We 
need a "reverse printf" to do this really effectively, though.  It will 
break whenever the error messages change.

>   2. Diagnose after failure.

I think this is a solution to be avoided whenever possible.  No matter 
how low the risk of generating an incorrect error, the discrepancy could 
lead to real problems.

>   4. Fix libtla.

> What annoys me most at the moment is functionality duplication, like
> Category.iter_branches and Category.get_branches. The typical change I'm
> considering is:
>
>   - removing the Category.branches property
>
>   - removing the Category.get_branch method
>
>   - renaming Category.iter_branches to Category.branches
>     (making it a method instead of a property)
>
> Of course, since that would probably break a lot of code, that would
> go only in the next version.

If I wanted to achieve that, I'd probably take these steps:
1. add iter_branches, deprecate branches
2. remove branches
3. add branches as an alternate name for iter_branches, deprecate 
iter_branches
4. remove iter_branches

It takes a while, but if you have enough client code, it's probably good 
to avoid breaking stuff.

Alternative: add a new namespace where iterators are the standard approach.

> For consistence with the rest of pyarch, it should be called
> iter_filechange. Do not worry, I'll handle it... I am doing some quite
> heavy duty editing on your patches. When I'm satisfied with them, I'll
> mirror the microbranches and ask you for feedback.

Sounds good.

Aaron
--
Aaron Bentley
Director of Technology
Panometrics, Inc.