Bert Freudenberg wrote:
> 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 ;)

I think that's a great idea. If there were an automatically generated 
config map that gets updated on every commits in a repository it would 
definitely help solve a lot of problems.

Cheers,
   - Andreas