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

[Alexander Belchenko]

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.

OK, I was not aware how emacs tools work.

> <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).

My main point about CLI bzr is: there is no UI to retrieve and provide 
--fixes and --author. These options could be supplied only from 
command-line. Maybe (maybe) it makes sense to provide some special 
keywords recognized in message text (when/after bzr invokes editor to 
allow user supply the message), so it could be used to duplicate 
command-line options --fixes and --author.

Because there is no UI for CLI, how user could see saved/restored 
--fixes? And how user can edit/delete them if any? From CLI?

>     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.

Hence my RFC.

> 
>     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.

It's OK, but Robert asked recently about some docs on it -- it will
be nice tohave it documented somehow.

>     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 ? >-/

We have archives: 
http://groups.google.com/group/qbzr/browse_thread/thread/8cc30f14a952fbcf

Also this is discussed previously in 2 bug reports (qbzr bugs).

>     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 :-).

If you store chain of uncommitted revisions as list rather than one big 
text you certainly can use all or only latest one. As you wish. Current 
bzr-gtk implementation does not seem optimal for me.

> 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.

It's nice, but a bit out of scope for this discussion.
But, to support this mode we would like to save old tip revid, not only 
messages.

>     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.

When commit is canceled (and it's the time to save commit data) then 
usually you don't keep lock so long. Do you?

>     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.

OK, Aaron shows another way: we can use ConfigObj features more heavily 
and store dict as dict, i.e. as [sub]section. Saving list could be more 
tricky, although ConfigObj has support for lists, but I never used it 
and I'm doubt I can do this via bzrlib.config API.

>     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. 

But you can't commit without the tree. So, saving data during uncommit 
on treeless branch is... useless?

You can uncommit using lightweight checkout, then switch checkout to 
another branch, and what will be the right behavior here?

> 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.

No, I disagree. See above.

> Hmm, there may be a gray area here.

Definitely.

>     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.

 From my experience of using TortoiseCVS latest 10 or maybe more 
messages have been saved into registry or some global config file and 
user (me) can reuse any of this messages later, even for different project.
IIUC, this is because you may want to commit file-by-file (hey, it was 
CVS!). Anyway I think this is great feature, and I'd like to implement 
it for QBzr as well. But IMO it's unrelated to uncommit.

>>From there, a GUI can propose a way to select/copy/paste/add any
> of them (or part of) acting like an history and providing even
> broader reuse.
> 
> Just throwing an idea here, I'm not fully convinced myself, but
> it's often valuable to think about various implementations in the
> design stage.
> 
> <snip/>
> 
>     bialix> So, I'm planning to implement in near future support
>     bialix> for qbzr as described above.
> 
> Go ahead !

Thanks.

> When I said to Garry that I want to provide as much support in
> bzrlib that various clients may need, I never intended to forbid
> said clients to implement their own solution.
> 
> Good designs are easier to reach when you have several working
> implementations :-D
> 
>     bialix> If bzr-gtk developers think this approach could be
>     bialix> interested for their tool, we can discuss how to
>     bialix> share the code. If other parties interesting to talk
>     bialix> about different variants or knows another problems
>     bialix> I've not listed there, I'm open for constructive
>     bialix> discussion.
> 
> I hope this helps.
> 
>     bialix> But in the end I'm planning to implement described
>     bialix> above as good enough support for qbzr, even if it
>     bialix> will be no ideal solution for everyone.
> 
> Again, go ahead !

Thanks for feedback.