death to revision messages

[John A Meinel]

Lalo Martins wrote:
> tonight I'm giving a presentation at the Beijing LUG about (their words)
> "the revolution in open source revision control systems".  As part of my
> preparation, I'm making a list of features in other systems that my
> favourite racer doesn't (yet) have.
>
> This is an interesting one.  About 7 times out of 10 I want to undo a
> commit, is because I put the wrong commit message.  And if the system
> made it easier (as Darcs does), I'd probably want to do it even more often.

Well, if you look at my "uncommit" plugin, you can back out the last
commit, and just re-commit it. Especially since you have a strong
assurance that the local commit hasn't been seen. And if it was, it
would just look like a different branch.

>
> On the other hand, on Monotone it wouldn't even be necessary.  From what
> I understand of the documentation (and one developer already told me the
> documentation is probably incomplete, but anyway), I could just issue a
> new cert with the correct message.

I believe all meta information is a new cert in Monotone. Basically,
they are key + value pairs pointing at a sha1 sum, with their own sha1
sum and a signature.
I personally find it a little odd that *all* entries are individually
added and signed. It has some interesting applications, but it means
that all information comes with quite a bit of overhead. I'm guessing
that internal to the database they keep the overhead low by using an
integer => sha-sum table. At least I would, because it is unlikely that
you will see > 2^32 distinct sha sums in your local database (you could
always upgrade to 2^64 and still not have to store the 2^160 of a sha
sum, or future upgrade to SHA256/512).
>
> I'm here to propose we go to a more Monotonic approach to revision
> metadata.  This may apply to the message, but also tags and other stuff
> we might want to add later (passes-tests flags, arbitrary comments, etc
> - we talked about this stuff in the past, and I even made a provision
> for it in suq).
>
> So a revision wouldn't have a message as an inherent attribute anymore.
>  But it would have any number of "annotations", which would be probably
> stored elsewhere.

What if we leave the message in the revision, but go ahead and add some
sort of annotation-store?

>
> [Re crypto - which right now we don't have at all, but for the future:
> The annotations may or may not be signed (Monotone-style), but if they
> are, the signatures should *not* be checked by default (only if you
> request them to be), so we avoid the performance problems Monotone can
> get sometimes.]

Having talked with NJS (what is his real name?) on irc, it seems that
the real slowdown is Monotone doing a 4-revision selfcheck for each
commit. So when you pull 50 patches, it makes something like 200 checks
(it patches against previous ancestors to make sure that it's patching,
and patch collecting algorithms work and generate the same output).

However, their crypto is very streamlined. A lot simpler than something
like gpg, and certainly doesn't require spawning a whole process for
each check (or signature). That said, I have no idea how secure their
crypto is. It might be quite good, it might be rot-13 (though I assume
they are reasonably competent).

>
> Not clear to me yet how much revision-controlled these annotations would
> be, though.  It's probably worth noting when they are added, but should
> you be allowed to delete one?  Modify it in-place?
>

Having come from Arch, I found I really like having history be preserved
unchanging. There is just a security from knowing that all the new stuff
isn't going to break what used to work.
And since this is a revision control system, revision-control the
annotations. :)
I can see that it might be tricky to get it right, so I suppose you
could do something like an append-only annotation.
The easiest thing I can see is to use the same ImmutableStore and have
it indexed by revision_id (just like the current inventory). Though they
are really designed around not changing.
But you need some way of indexing to see if a given revision id has any
annotations.
I suppose one alternative would be a directory per revision id, with all
annotations stored in there.
And you still need a way to indicate which annotations are still
meaningful, and which are considered "old". (That is, if you take my
suggestion and don't just delete them).

> Anyway, just another thought.  I am of course prepared to implement this
>  ;-) but consensus first.

I feel like it doesn't really fit with the current bazaar-ng philosophy.
You can get away with it better in monotone because you have a database,
and can say "give me everything which references *this* sha1sum", that's
tricky to do in a filesystem, especially if you are trying to not change
history (append/new-file-only).

>
> best,
>                                                Lalo Martins

If you can flesh it out a little bit more, I think having some sort of
annotation mechanism could be nice. It could be used to implement "tag:"
support, for instance. Maybe my "don't change history" is too harsh a
requirement. I know Martin is exploring weave-style files, which you
could potentially do with an append-only main file, but you have a
multi-write index file (either that, or the whole thing is multi-write,
which in my mind is much worse), though I think either way with a little
bit of corruption you end up with tag soup.

John
=:->

> --
>       So many of our dreams at first seem impossible,
>        then they seem improbable, and then, when we
>        summon the will, they soon become inevitable.
> --
> http://www.exoweb.net/                  mailto:lalo at exoweb.net
> GNU: never give up freedom                 http://www.gnu.org/
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050712/7f5840bd/attachment.pgp