Re: Subversion-style incrementing revision numbers

[Joel Dice <dicej@mailsnare.net>]

On Tue, 19 Sep 2006, Petr Baudis wrote:

> Dear diary, on Tue, Sep 19, 2006 at 11:07:45PM CEST, I got a letter
> where Joel Dice <dicej@mailsnare.net> said that...
>> Implementation:
>>
>> A simple, efficient implementation of this feature would be based on a
>> single file, $GIT_DIR/history, which would contain a newline-delimited
>> list of SHA commit IDs in chronological order, oldest first.  The current
>> repository IRN would be calculated as the size of that file divided by the
>> SHA+newline length, and the commit ID of any IRN could be determined by
>> seeking to the correct offset in that file.  Every commit would cause a
>> new line to be appended to the history file with that commit's ID.
>> Finally, a history file could be generated for an existing repository by
>> serializing the commit history based on chronological order.
>
> We already have support for recording something similar, it's called a
> revlog. You would just need to modify it to aggregate all the branches
> in a single file.

Thanks - I'll look at that.

> Also, multiple IRNs could refer to a single real commit if you do e.g.
> cg-admin-uncommit, since revlog logs revision updates, not new revisions
> created. This may or may not be considered a good thing. If you rather
> want to just create a new IRN at commit object creation time, also note
> that some tools _might_ validly create commit objects and then throw
> them away, which would generate non-sensical (and after prune, invalid)
> IRNs.

I'm not too worried about cg-admin-uncommit or git-reset, since the IRN 
feature is intended mainly for shared repositories.  I would suggest that 
such commands simply be disallowed for such repositories.

The problem of temporary commits certainly needs to be addressed.  In this 
case, may I assume nothing under $GIT_DIR/refs is ever modified?  If so, 
perhaps I could somehow hook into the git-update-ref step.  Is that what 
the revlog code does?

  - Joel