gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] PyArch patches


From: David Allouche
Subject: Re: [Gnu-arch-users] PyArch patches
Date: Sat, 19 Jun 2004 18:27:01 +0200
User-agent: Mutt/1.5.5.1+cvs20040105i

On Fri, Jun 18, 2004 at 09:52:43PM -0400, Aaron Bentley wrote:
> One thing: I can't see an alternative to Tree.get_log().
> 
> I'm getting user input that may be bogus, and I need to return it only 
> if it exists.  If I ask for a (tree) log that doesn't exist, cat-log 
> complains and returns 1, and I get some big fat exceptions.

It would indeed make sense to raise a more specific exceptions here,
which could be RevisionError (revision does not exist, for
cat-archive-log), LibraryError (revision not in library, for
library-log), or PatchlogError (patchlog not in tree, for cat-log). Yet
I am not sure what is the best way to do it... Since tla is about to be
localized, parsing the error logs is no longer really an option, so tla
should maybe be modified to have particular exit status for those cases.

Another big problem here is the fact that the delayed Patchlog parsing
makes it difficult to catch the exception.  That particular problem can
be fixed with a "arch.Patchlog.force()" which causes immediate retrieval
and parsing of the patchlog data.  But maybe that is not really worth
the trouble, what do you think?


> What I have to do is iterate through the logs in order to find out 
> whether the specified log exists, and return it if so.  That's exactly 
> what get_log did.

How hackish... on the other hand tla does not really provide existence
predicates for anything. Testing for the existence of namespace objects
is currently done, very unefficiently, more or less along those lines in
the arch.py "exists" methods and _tla.py "*_exists" functions.

I think the correct way would be:

  * Implementing a "patchlog_exists(tree, version, patchlevel)" function
    in _tla.py, which currently just checks the output of "tla logs"
    using the "in" keyword.
  
    That way we can easily drop in something faster leveraging a new
    feature of tla or looking directly in the {arch} directory.

  * Defining "arch.ArchSourceTree.has_patchlog(revision)" as a
    high-level interface. The "archive/version" and patchlevel parts are
    already handy in Revision instances.

  * Documenting that "arch.Patchlog" expects the patchlog to exist in
    the archive/library/tree or unpleasant things may happen at
    unexpected times, unless the patchlog if "forced" so unpleasant
    things happen right now.

-- 
                                                            -- ddaa




reply via email to

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