[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] PyArch status update
From: |
David Allouche |
Subject: |
Re: [Gnu-arch-users] PyArch status update |
Date: |
Fri, 26 Mar 2004 14:36:17 +0100 |
User-agent: |
Mutt/1.5.5.1+cvs20040105i |
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