Re: [Gnu-arch-users] PyArch newbie observations/questions

[Aaron Bentley]

Good grief.  This has been banging around inside the gnu mail system for 
3 days!  Feel free to use reply-all to me.

David Allouche wrote:
> On Tue, May 25, 2004 at 09:54:39AM -0400, Aaron Bentley wrote:
> > > 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.
>
>
> I think DELTA would rather be a top-level function like:
>
>   arch.delta
>       a: Revision|ArchSourceTree
>       b: Revision|ArchSourceTree
>       out: DirName
>   => Changeset

Well, it could be
def delta(self, from=tree_latest_revision(), to=tree_root(), output=None):

With no arguments or with just "to" specified, it would behave like changes.

> In my understanding, CHANGES is different from DELTA in several
> ways:
>
>    1. CHANGES can save its output changeset under a default name in the
>       tree-root, named after the master revision.

True.  I'm not aware of a use for this, though.

>    2. CHANGES can accept a "limit file set" (oh! that needs to be
>       supported too) in a way similar to COMMIT.

AFAIK, the CHANGES limit doesn't work.

>    3. CHANGES uses the tree-revision by default.

True, but I don't see that being a big advantage, when we can easily 
determine the tree revision.  I expect pyaba to pass a revision argument 
to changes/delta 99% of the time.

>    4. CHANGES is used in different contexts than DELTA, and though it is
>       essentially based on a subset of the functionality of DELTA, I
>       consider it as an important "library" operation.

I think delta could be used in the same places just as conveniently, if 
it had sensible defaults.

>       On the other hand, DELTA _is_ a fundamental operation of the
>       archive layer (unlike CHANGESET which is a fundamental operation
>       of the changeset layer) because it is an extension point for
>       transparent optimizations (pristines cache, revlib, smart server).
>
> You are welcome to debunk my arguments, so far I think providing a
> WorkingTree.changes method would be generally useful and convenient.

I won't stand in the way of WorkingTree.changes, but I do want to have 
(and use) delta.

> > What about the stuff changes dumps to stdout, and the diffs output?
>
>
> The Changeset class should provide all that information in a convenient
> and efficient way. The diffs output looks like a CLI convenience feature
> to me, not to be supported explicitely in PyArch.

The changeset output is nice to have for Pyaba.  To colorize it the 
right way, we'd need to parse the leading letters.

> Well, I can imagine the incremental output being useful to provide
> visual feedback, but it would not really fit the bill (it cannot be used
> to provide an ETA) and I do not see offhand how to make it fit in the
> current framework.
>
> That could be supported using an extended version of
> arch.util.StringOutput (passed as a keword argument to
> arch.WorkingTree.changes and arch.delta), but that would need much more
> reflexion to get it right.

It seems to me that we'd want a per change iterator.

> > > 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.  

> I admit I am not sure about that choice. The reason why it was done that
> way in tla was because relinking requires doing the greatest part of the
> work of CHANGES, and doing it in one place prevented code duplication.
> It is a feature of libtla that CHANGES is used to perform relinking..

My argument pro a relink command is that relinking isn't at all central 
to the functionality and purpose of changes.  It was convenient to stick 
it there, but it doesn't really belong there.

>   -- Practicality beats purity.
>
>      Is it a common occurence for scripts to take the opportunity of
>      computing the changes to perform relinking? That's a good question,
>      and one I am unable to answer.

Me too.  I don't often hard link my trees.

>      By the way, why does "tla commit" not support relinking?

No one seems to have cared enough, and at the time I implemented 
relinking, I wasn't brave enough to fiddle with commit.

> As you can see, I have not quite made up my mind yet...
>
>
> On second thought, the correct signature for CHANGES could be:
>
>   arch.WorkingTree.changes
>       [output: DirName, default: to the ,,what-changed-* name]
>       [master: Revision, default: tree-revision]
>       [file_list: iterable of PathName, default: empty]
>       [link: bool, default: False]
>   => Changeset
>
> It could also raise a TreeLintError if the tree is not commitable, and a
> "strict" boolean keyword argument to control when to raise such an
> exception. But that would require multiple tree inventories, and that
> would be a big performance penalty.

You could avoid doing tree-lint except when there's a lint failure (exit 
status 2)

> For the sake of expressiveness and to support future optimizations, we
> also need a companion method:
>
>   arch.WorkingTree.has_changes
>       [master: Revision, default: tree-revision]
>       [file_list: iterable of PathName, default: empty]
>   => bool
>
> This is a common operation to check only for the _presence_ of any
> change, it could be implemented more efficiently, since the outcome is
> known once any change is detected, and it does not required the creation
> of a changeset on the disk. Currently, that would be implemented using
> "tla changes" without --keep or --output.

Sure.  In fact, I'd like a arch.WorkingTree.has_no_changes() function 
that throws an exception if changes are present.

> > > 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.
>
>
> Frankly, I do not even have a clear idea of what the output of tree-lint
> looks like in the general case.

Lists of files, with headers:

These files violate naming conventions:

.foo


These apparent source files lack inventory ids:

README


These explicit ids have no corresponding file:

.arch-ids/RIDME.id


That output actually looks unambiguous to me, since it has two newlines 
between the end of a file list and the heading of the next list.

> > There's also the option of adding an easily&reliably-parsed output 
> > representation to tree-lint.
> > 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?
>
>
> That's not a PyArch specific issue.

Yeah.  Like I said, I'm a grasshopper.  I didn't even know Python lacked 
destructors 'till today.  I miss RAII already.

Here's a PyArch-specific issue.  I could ship pyaba with PyArch in a 
subdirectory.  I'd forward any revisions that affected PyArch to you, of 
course.

Anyhow, the current release uses the PYTHONPATH.  Maybe I'll change that 
approach in a later release.

Aaron