[RFC]New style of revision id [Was Re: VCS comparison table]

[John Arbash Meinel]

Goffredo Baroncelli wrote:
> Hi all,
> 
> enclose a little patch which shows an implementation of a revision-id which 
> include an hash. The biggest problem of this patch is that the sha1 is computed 
> on every file.
> 
> $ ~/bazaar/repo/bzr-sha1/bzr init .
> $ echo 1 >>a
> $ ~/bazaar/repo/bzr-sha1/bzr add a
> added a
> $ ~/bazaar/repo/bzr-sha1/bzr ci -m "a added"
> added a
> Committed revision 1.
> $ bzr log --show-ids
> ------------------------------------------------------------
> revno: 1
> revision-id: ghigo at venice-20061024194142-ab95629418a97c1bdd76641e6bac0312ad782b36
> committer: ghigo <ghigo at venice>
> branch nick: 1
> timestamp: Tue 2006-10-24 21:41:42 +0200
> message:
>   a added
> 
> 
> The last part of the rev-id is the sha1sum of a manifest. The manifest used for the 
> checksum can be found in the log

Well, if you wanted to get all of the benefits of git, you could either:

1) Move the sha hash to the beginning of the revision id. That makes
autocomplete work because the random stuff is up front.

2) Get rid of the user at host-date stuff completely. I don't know that it
is really needed. Though I would guess that the sha might have a higher
chance of collision in this system.

Very neat work, though. There *is* a race condition. In that the working
tree can change from the time you generate the manifest, until the time
that the code is actually committed into the repository.

So there are a couple other small things you could do:

1) If you call WorkingTree.get_file_sha1() it will use the value in the
hash cache, rather than reading every file and doing the sha1 of it.
(You may already be doing this, I didn't look too closely)

2) After the testament has been built, it should be kept around during
the commit stage. And it should verify that the sha1 that we already
computed matches the sha1 of the text we are adding to the repository.
This means that commits during race conditions will fail, but at least
they aren't broken.

It does mean that a commit has to do 2 passes over your files, 1 to
check what is different and generate the manifest, and a second to do
the actual commit. But IIRC we might already be doing a double pass.
(This may only be when we generate a status summary if you don't supply
-m to commit).

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061024/2f09e89b/attachment.pgp