correcting old log messages

[Robert Collins]

On Tue, 2008-01-29 at 21:54 -0700, Stuart McGraw wrote:
> Robert Collins wrote:
> > On Tue, 2008-01-29 at 17:54 -0700, Stuart McGraw wrote:
> >> I have no idea how Bazaar works internally so perhaps
> >> something in Bazaar's design or implementation would
> >> prevent doing this, but is it hypothetically reasonable?
> > 
> > In short - yes, we could add another dimension of versioning, so that
> > revisions and their content are versioned, as well as the users source
> > tree being versioned (the revisions of the source tree are 'bzr
> > revisions', I have no idea what we'd call the revisions of the
> > revisions :).
> 
> I'm sure that having versioned metadata is useful in some
> environments, but my thought was unversioned metadata would
> be also very useful (fix the uncorrectable log message problem)
> and might be a lot less complex to implement: a "last changed"
> timestamp (handwaving away clock skew issues here) on each
> piece of changable metadata, no history.  (yes, i'm sure there
> is a lot more to it. ;-)

We have a big hammer for transmitting data without examining the entire
contents: we journal the things we want clients to be able to grab and
sync on (aka we version them). Consider that if there is a set of
metadata with a serial number on each, we need for an arbitrary client
to divide that set into 'newer' and 'older' - and that serial number
needs to be both globally unique and have a total sort (merging actions
are required to convert partial sorts into total sorts). Once divided we
can transmit the newer items of metadata, but to resolve conflicts
nicely we need history (if you and I both edit the same revision
simultaneously, but neither of us kept the original, then we end up
doing a two-way-merge which is nasty to the user). Hmm rambling - I
could go on. Suffice to say that the current generally accepted solution
in the DVCS space for any data that you want to allow concurrent changes
to is 'keep history'.

> > Currently, it does not seem worth the complexity or investment to write
> > this. AFAIK none of the modern VCS systems do this. (svn is not
> > modern ;)).
> 
> The lack of this ability surprises me a little.  If someone
> told me about a system into which information could be entered,
> but not corrected after the fact, I would consider that system
> broken (partially) without even knowing what it was supposed
> to do.  But maybe that's just me.
> 
> Now that I think about it, isn't that the way the U.S.
> government's terrorist watch-list works? :-)

:). bzr allows edits of the current tree; but if you consider old
commits the audit trail of how the tree got its current shape and
contents, I think it might make more sense to you. That is - the current
shape is entirely mutable; the path from then to now is not.

> Anyway, it was just a thought.  Thanks for the feedback.

Anytime :)

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080130/af4e7f65/attachment.pgp