On 08.09.2009, at 08:51, Colin Putney wrote:

>
> On 7-Sep-09, at 11:11 PM, Andreas Raab wrote:
>
>> Yes, that is equivalent to having a configuration map for every  
>> update. Unfortunately it means that every single update consists of  
>> two package commits; one for the contents and one for the meta  
>> package (or config map).
>
> Right, dependencies and configuration maps are equivalent, and so  
> far we've been using config maps. An oversight on my part.
>
> But it doesn't (necessarily) mean a commit of the config map for  
> each package commit. Every time you make changes that span several  
> packages (and I've seen quite a few of these in the commit  
> messages), you can roll them into one config map commit. Or to  
> reduce the overhead further, you could roll groups of unrelated  
> changes into the same config map. What's the optimal tradeoff  
> between overhead to create a new config map and the size of the  
> delta between successive config maps?
>
> I suppose we *already* have a unique config map number that  
> describes the state of the image. Maybe we just need to increase  
> it's resolution a bit? Or just start using it as is?


Actually, the server would know the number of all commits ever done to  
the trunk repo, simply by counting all the versions it has. That would  
be a monotonically increasing number, not quite unlike a subversion  
revision number. It may have to be a bit fancier than that to account  
for deleted versions, but not much I would guess?

warning: hand-waving and thinking aloud ahead

To make it more like a subversion revision what would be needed is  
getting back to a particular commit, that is, there would have to be a  
way to get from a revision number to the versions associated with it.  
This could be done by updating a config map whenever something is  
committed and saving it under that revision number. The config map  
would be "virtual" and simply record all the latest packages in the  
repo without respect to load order, because the server has no way of  
knowing that. This would rely on the repo usage as trunk, otherwise it  
would not be sufficient to just record the latest versions, but all  
versions would have to be associated with a revision number. Actually,  
that might be even simpler - put the revision number in the meta data  
for each submitted version. Voila. Then sorting by this number would  
give the exact sequence of trunk commits. Or ... we actually *do* have  
such an ordering already, in the upload time stamp. Wonder if it gets  
updated when moving a package between repositories ... in any case,  
old versions of the repo could simply be accessed by going to http:// 
s.s.o/trunk/123 which would filter out all versions after revision 123.

Or is this all silly talk? Entirely possible ;)

- Bert -