Re: Subversion-style incrementing revision numbers
- From
Petr Baudis <pasky@suse.cz>
- Date
- Sep 19, 2006, 21:18 UTC
- Message-ID
- <20060919211844.GB8259@pasky.or.cz>
- In-Reply-To
- <Pine.LNX.4.62.0609191309140.9752@joeldicepc.ecovate.com>
Dear diary, on Tue, Sep 19, 2006 at 11:07:45PM CEST, I got a letter where Joel Dice <dicej@mailsnare.net> said that...
Show 11 quoted lines
> 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.
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.
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Snow falling on Perl. White noise covering line noise. Hides all the bugs too. -- J. Putnam