Fix a botched log-message

[Stefan Monnier]

> There are some complications that I'm aware of.

> 1) Do you version this new information or not?

I'd expect we would want to version it.

>    b) If you do version, then you still have a potential for conflicts
>    on a location that doesn't have a direct filesystem representation.

Why not give it a file name.
After all, we do it for .bzrignore.  We could do the same for tags, BTW.
That would mean we can't change that info on a tree-less branch, but
it doesn't sound like a serious restriction.

>       It is even possible for someone who knows nothing about a given
>       log entry to get a conflict that they then need to
>       resolve. (Because I pulled from Joe who changed it, and then
>       merged from Mary who also changed it, but to something else.)

That's already the case for any other file: I may have to resolve
conflicts is file src/foo.c while I only ever work on the translation of
doc/bar.texi and known nothing about programming in C.  It's inherent to
the job of merging: if you don't want that, then stick to `pull'.

> 2) Scalability. You need to know when doing a  fetch/merge/pull which entries
> ~   you need to propagate. And remember, the whole point is being able to change

If it's a normal file, I see no problem here.

>    d) You also have to consider the scalability of *using* this
>    information.  Specifically when you do "bzr log" for every revision
>    you need to check if there is a potential log modification that you
>    need to use instead of the one you have.

Since the only things you want to do with .bzrloginfo is
"insert(revid,text)" and "lookup(revid)" and that insert doesn't even
need to be fast, that doesn't sound too difficult.  Of course, the fact
that it needs to be mergeable makes it a bit more interesting.

>    This also impacts stuff like propagation, because you need to store
>    the data in such a way that it is fast to retrieve when you need it
>    for log, but also fast to compute what needs to be sent for
>    'bzr push'.

Again, if it's a normal file, this is a non-issue.

> I don't know of any distributed VCS that lets you modify commit
> information such as this.

You mean you don't want to do it, just because none of the competition
provides this feature?

> Anyway, we discussed it quite a bit (at least as part of the 'bzr
> tags' discussion). I think we have an idea of how to write it so that
> it is efficient.  The main reason Martin didn't implement it was
> 2b. You need a simple way to communicate to a user that you have
> a conflict in something that isn't a file on disk. And it complicates
> the internal model, because now you have 2 DAGs instead of just 1 that
> people need to think about (or at least the internal code does).

Why not make it a normal file?


        Stefan