[qbzr] [qbzr/bzr-gtk] Save commit message and other metadata when commit GUI dialog is cancelled or in uncommit hook

[Vincent Ladeuil]

Sorry for the delay and most importantly, sorry for my too-short
comments in the other thread ([rfc] bencode unicode strings).

I try to clarify my thoughts on the subject below.

>>>>> "bialix" == Alexander Belchenko <bialix at ukr.net> writes:

    bialix> I send the copy of my thoughts to main bzr list
    bialix> because Vincent pointed me that this topic could be
    bialix> interested not only for qbzr. I'm trying to explain
    bialix> how I'd like to implement it for qbzr, so maybe my
    bialix> approach will be interesting for bzr-gtk, and in far
    bialix> far future will be move it in the core (who knows?).

    bialix> Background
    bialix> ----------

    bialix> When user trying to commit from command-line and
    bialix> commit fails because of some blockers it's possible
    bialix> to remove blockers and then invoke the same commit
    bialix> again using shell history.

That's not the only use case, if bzr was able to save the commit
message (author, fixes, etc) when a commit is abandoned, that
data can also be reused when an editor is invoked (which the
shell history doesn't know about).

There is also 'dvc', an emacs front-end, that currently saves the
commit message in a temp file.

<snip/>

    bialix> When user uncommit it's may be because he/she want to
    bialix> improve either the code committed or committed
    bialix> message of other metadata. VCS don't know intent of
    bialix> the user so it make sense to save messages and other
    bialix> metadata in uncommit hook and then reuse it on
    bialix> subsequent commit. The data should be saved in
    bialix> similar way as for ordinal commit in GUI, so commit
    bialix> dialog will use any saved data.

Definitely the main point... as long as the data can be reused
between the various actors.

    bialix> Command-line bzr can save and reuse uncommitted
    bialix> revisions too, but there is no UI for this right
    bialix> now.

Right. The closest that exist right now is via the --file commit
option.

    bialix> If there will be UI to reuse saved data, then
    bialix> command-line bzr users even can rely on saved data
    bialix> when previous commit fails.

Yup, interoperability.

    bialix> So, discussed approach is more interesting for GUI
    bialix> tools,

Not only, most of the time, when I uncommit, my next commit
message is unchanged and --fixes and --author will too (except I
rarely use them, but my point is that, most of the time, I
uncommit when I realize I should commit something different, but
the intent doesn't change).

    bialix> but because some users have installed both qbzr and
    bialix> bzr-gtk in the same time then there will be big
    bialix> overlap in implementation and duplication in uncommit
    bialix> hooks. So maybe it make sense to have this code
    bialix> actually in bzr core, including uncommit hook.

Right. The code should be shared, but even more importantly the
data format should be interoperable.

    bialix> Existing implementations
    bialix> ------------------------

<snip/>

I agree with these descriptions.

    bialix> As one could see both GUI tools used similar
    bialix> approach, but bzr-gtk also supports per-file
    bialix> messages.  QBzr don't have support for them mostly
    bialix> because there is no documentation on this feature,
    bialix> and de-facto bzr-gtk is the only one tool that
    bialix> supports them and therefore should be used as
    bialix> reference implementation. I'd like to hear how
    bialix> support of per-file messages actually works in viz
    bialix> and gannotate, if this possible.

As pointed out by jam in another thread, this roughly use a
'file-info' revision property as benconded dict key=file-id,
value=utf-8 encoded message.

    bialix> Both tools does not save --fixes or --author metadata
    bialix> today, but qbzr want to implement support for --fixes
    bialix> (at least) so corresponding discussion have started
    bialix> in qbzr ML

I missed that. Is there a problem with my subscription ? >-/

    bialix> and and this e-mail is the result of this discussion.

    bialix> Problems or is there possible to have ideal solution?
    bialix> -----------------------------------------------------

    bialix> Although both tools using similar approaches but
    bialix> there is several problems in each implementation.

    bialix> When user uncommit several revisions it's not clear
    bialix> what is user intent. Should we save all messages or
    bialix> only latest one? There is no simple answer because it
    bialix> depends on context.

Yes, it's unclear, my long term answer will be that we should
keep it simple which tends to mean (to me) that only the single
revision uncommit case should be taken into account (but I may
well be wrong here, the concept of uncommitting several revisions
to do a single commit doesn't really fit in my brain :-).

For more complex use cases, I think a GUI allowing some drag and
drop between a qlog-like presentation starting at the uncommitted
tip and the commit dialog will give more flexibility.

    bialix> QBzr users want to have more data saved, e.g. ids of
    bialix> fixed bugs. This is really should be handy.  Thinking
    bialix> further we need to save --author option as well,
    bialix> although it used very rare.

    bialix> bzr-gtk does not have support in gcommit for --fixes
    bialix> and --author AFAIK, but maybe one day will have.

Especially if bzrlib provide the infrastructure ;-P

    bialix> Saving different data as multiple variables in
    bialix> branch.conf leads to non-atomic behavior, even more
    bialix> manipulating with branch.conf requires branch
    bialix> locking, so operation of saving the data should be
    bialix> atomic and implemented as single shot.

Right, but commit and uncommit requires a branch lock, so I don't
think there are problems there.

    bialix> Therefore it's make sense to use bencoded dict to
    bialix> save many different data in one variable: global
    bialix> message, per-file messages dict, fixed bugs, authors.

    bialix> Using branch.conf is only one existing option in bzr
    bialix> core today, but if one starts thinking about
    bialix> lightweight checkouts then it becomes obvious that
    bialix> saved commit metadata should be saved in the checkout
    bialix> itself, not in master branch, especially because it
    bialix> could be remote and even more read-only location.

Huh ? You can't commit/uncommit without accessing the
branch. 

bound branches may pose a problem though when the --local option
is used (which branch.conf should be updated/used when ?).

    bialix> So, I think there should be new config for tree
    bialix> object, e.g. as .bzr/checkout/tree.conf file.  And
    bialix> saved commit metadata should live there.

*Preparing* a commit message is tree-related, but saving an
uncommit message is clearly branch-related.

Hmm, there may be a gray area here.

    bialix> Plans for new QBzr implementation
    bialix> ---------------------------------

<snip/>

    bialix> 3) For messages should be used lists of strings, so
    bialix> we can support uncommit of several revisions, if qbzr
    bialix> will wish this in the future.

An even more general solution will be to save the commit/uncommit
information in some *user* file, shared for all branches.