[RFC] browsing history API

Robert Collins robertc at robertcollins.net
Tue May 23 06:11:16 BST 2006


On Tue, 2006-05-23 at 15:01 +1000, Martin Pool wrote:
> On 23 May 2006, Robert Collins <robertc at robertcollins.net> wrote:
> > I think that the API for determining when the file was altered should be
> > on repository, not on the per-file versioned file. That is, calling
> > straight into the versioned file is an abstraction violation.
> > 
> > This is important IMO because if we do manage to make calculating this
> > with renames correctly it should be corrected in the api that generates
> > the list, not in log per se.
> > 
> > -1 on this being on VersionedFile, and -1 on the
> > get_full_revision_history_by_fileid being on branch - most of the calls
> > in the function are on repository, so this entire api should be on
> > repository.
> 
> Actually I'm glad to hear you say that because I had been wondering the
> same thing myself.  So we'll want things that look like
> 
>     repo.some_file_history_query(file_id, ...)
> 
> rather than 
> 
>     repo.get_versioned_file(file_id).some_query()
> 
> In some ways the second seems better factored but only if you assume
> that all repositories will have objects representing the history of a
> particular file, which is not true.

Well, it would be reasonable to state that every repo should be a
factory for that. And if we have other cases where that starts to make
sense, then sure. The key thing that makes me say that is the difference
in layering:

VersionedFile is *not* the history of changes to a file id. Its a record
of the versions of the file.

In our current implementation only the inventory, with the last-modified
field, can say when a file was modified : the VersionedFile graph and
the revisions that modified a file will intersect, but neither is a
subset of the other in the general case. (Reparents are not listed in
the versioned-file graph, and changes in other branches should not be in
the modifying revisions list from the point of view of 'log' - which
wants only the left-most parents according to the revision graph,
intersected with the versioned file graph.).

So if we had an object that represented the concept we want here
directly, I'd say 'put the method on that'. As we dont, we should put it
on the closest object that has access to all the relevant information:
Repository.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060523/a9c03d72/attachment.pgp 


More information about the bazaar mailing list