Re: [Gnu-arch-users] PyArch status update

[David Allouche]

On Wed, Mar 24, 2004 at 10:52:46PM -0800, Dustin Sallings wrote:
> 
>       I'm interested in using this for my p4 gateway, but I'm a bit lost 
>       at the intended usage.

Yeah... yeah... I should write documentation... in the meantime, please
just ask me that way or on #arch, I'll do my best as long as it is not
a clear case of RFSC.

>       I believe I'd want to do something like a ``tla missing'' to get a 
> list of Changesets that have not yet been applied and then apply the 
> Changeset and make the appropriate p4 adjustments.

That's right, that feature is not there yet, contributions welcome.

In full generality, it would be:

  1. ArchSourceTree.iter_missing(self, version, reverse=False,
                                       skip_present=False)

     Producing an iterator of Revision.

     To keep the API clean, Summary, Creator and Date would have to be
     accessed from the Revision.patchlog, properties 'summary',
     'creator' and 'date'.

     The --merge options would probably have to be implemented with a
     separate iterator, like ArchSourceTree.iter_missing_merges, using
     the NestedIterator construct I implemented for Version.merges.
     Though, since I do not understand this option fully, it might be
     implemented in some other way (like accessing the
     revision.changelog new_patches property).

  2. iter_missing(archtree, version, reverse=False, skip_present=False)
     
     The tla wrapper in the _tla module, using sequence_cmd, and
     producing an iterator of fully-qualified revision names.

  3. Associated test cases.
  
     Oh, well... if you really need the feature and does not have the
     time to make test cases, just do it and I'll merge it in devo
     anyway.


I agree that simplifying the design by delegating some features to the
ChangeLog class can have adverse effects on performance, but this
decision is motivated by:

  A. In the future (few months), immutable archive objects will be
     interned.
     
     That will probably be done by overloading __new__ and using a
     factory object. In that case the factory object would maintain
     WeakDict objects whose keys are fullname strings and whose values
     are the actual archive objects. Alternative interning strategies
     could use a persistent dictionary or, maybe, even a database
     back-end.

     For patchlogs, this might be problematic because, though this is
     not supposed to happen, it is possible to patch the patchlog files.
     Absolutely correct interning might need restricting it to archived
     patchlogs (truly immutable) as opposed to tree patchlogs.

  B. Eventually, the _tla module should be replaced (at least
     optionally) by a _libtla, shared library, module. When that happen,
     there should (or shouldn't?) be little performance benefit to get
     decorated information with a single invocation, as 'tla changelog
     --summary' provides.
     
     So elegance of the design and faithfulness to Python "there is one
     way to do it" approach is atm considered more important than
     relatively minor performance gains. Remember Knuth's "root of all
     evils".

I believe at that point you have all the information you need to
implement that "missing" ;) feature, and the underlying rationale.

Please ask if something is not yet completely clear.

-- 
                                                            -- ddaa