Re: [Merge] lp:~craighewetson/qbzr/bugfixes into lp:qbzr
Alexander Belchenko
> Craig Hewetson has proposed merging lp:~craighewetson/qbzr/bugfixes into lp:qbzr.
>
> Requested reviews:
> QBzr Developers (qbzr-dev)
>
> Please provide feedback if there are any problems with the way it was implemented.
Craig,
Sorry for the delay with answer. Unfortunately QBzr team is rather small.
First at all, thank you for your attempt.
There is bug in your addition in uncommit hook: revision object has full
URLs to bugs, not short links like lp:12345. I understand, it's not easy
to fix actually, so I don't expect it. I'm sorry about forcing you to
fix it before. In fact there is no simple way to do the right thing here.
Unfortunately your approach is far from ideal. I can't approve it,
because I know we can do it better. I will explain how I see it.
Of course if anybody else from QBzr team think that your current patch
is OK, I won't object to merge.
But let me explain how I think it could be better.
1) Currently we have 3 places in qbzr where the knowledge about format
and destination of saved data exists:
* uncommit hook
* qcommit cancel code
* qcommit init code
You added 2 more places in qcommit code (save_bug_message,
clear_saved_bug_message).
I'd prefer to introduce new class (say class SavedCommitData in
commit.py) which should handle save/load/clear all required data.
Such class should be able to init data about commit (messages,bugs,
author(s)) from 3 sources: commit dialog (to save data on cancel),
config file (to read saved data), revision object (for uncommit hook).
This way we can change (if needed, but see below) the way how to save
these data.
Using such class we can expand its functionality step-by-step, even for
uncommit stuff.
2) All data about commit (message, bugs, author(s)) should be
saved/restored in one go, IMO. And we should finally fix long standing
TODO about deleting data from config file, not simply set it to empty
string. Also I think we need to save all data together in one place. I
think we need to save data under special section (say [qbzr_commit] or
[qcommit]) in branch.conf.
Certainly it will require more work, but will leads to much better results.
So, if you agree with my proposal, we can work together on implementing
it. If you think it's too much for such simple change, I will work on it
self.
Vincent Ladeuil
<snip/>
bialix> I'd prefer to introduce new class (say class
bialix> SavedCommitData in commit.py) which should handle
bialix> save/load/clear all required data. Such class should
bialix> be able to init data about commit (messages,bugs,
bialix> author(s)) from 3 sources: commit dialog (to save
bialix> data on cancel), config file (to read saved data),
bialix> revision object (for uncommit hook).
Multiply that by three potential users: qbzr, bzr-gtk, bzr itself.
There are strong reasons to even push that to bzrlib itself, I'll
do my best to help here and we can reach that in several steps
anyway.
I don't want to block any effort neither by raising the bar nor
by promising anything, just repeating what I told to Gary in
Barcelona: bzrlib is intended to *support* external clients, if
several clients feel the need to implement the same feature,
clearly something is missing in bzrlib.
bzr-gtk currently defines SavedCommitMessagesManager in
commit.py, ha ha, what a coincidence :-)
This is not directly re-usable in qbzr IMHO, but clearly
there is some duplication going on...
https://bugs.launchpad.net/bzr-gtk/+bug/215674 also contains
some comments related to the feature I think (but Alex should
already know about that).
Vincent
craig Hewetson
But it could be seen as a workaround until someone finds the time to do the fix that you have just proposed.
>>There is bug in your addition in uncommit hook: revision object has full URLs to bugs, not short links like lp:12345.
craig Hewetson
and the fix for the cancel problem (https://bugs.launchpad.net/qbzr/+bug/380896) can be left in as a fix for that bug.
Alexander Belchenko
Craig, please wait a couple of days. I need to create urgent qbzr release as companion to bzr 1.16,
after this I'll return to your patch.
Alexander Belchenko
>>>>>> "bialix" == Alexander Belchenko <bia...@ukr.net> writes:
>
> <snip/>
>
> bialix> I'd prefer to introduce new class (say class
> bialix> SavedCommitData in commit.py) which should handle
> bialix> save/load/clear all required data. Such class should
> bialix> be able to init data about commit (messages,bugs,
> bialix> author(s)) from 3 sources: commit dialog (to save
> bialix> data on cancel), config file (to read saved data),
> bialix> revision object (for uncommit hook).
>
> Multiply that by three potential users: qbzr, bzr-gtk, bzr itself.
>
> There are strong reasons to even push that to bzrlib itself, I'll
> do my best to help here and we can reach that in several steps
> anyway.
Also I agree this will be nice to have in bzr core, but it seems this too hard to bother (see below).
> I don't want to block any effort neither by raising the bar nor
> by promising anything, just repeating what I told to Gary in
> Barcelona: bzrlib is intended to *support* external clients, if
> several clients feel the need to implement the same feature,
> clearly something is missing in bzrlib.
Yeah, this sounds good in theory but in practice any non-trivial design decision or proposal for
bzr.dev leads to long debates about how it should look in ideal world and then we have nothing.
Plus, I'm always can hack something workable for qbzr and don't write hundred of tests just to send
merge request.
Actually I think the bar of bzr.dev development is too high for mere mortal who trying to create
something more complex than 5-10 lines patch. This is my IMHO of course.
> bzr-gtk currently defines SavedCommitMessagesManager in
> commit.py, ha ha, what a coincidence :-)
Interesting. It's roughly what I have in mind.
It inspires me for new ideas.
> This is not directly re-usable in qbzr IMHO, but clearly
> there is some duplication going on...
Yes, and the most difficult part is uncommit hook. Even if both bzr-gtk and qbzr will use the same
codebase for save data there will be 2 uncommit hooks running for people who have both plugins
installed. I.e. without proper support in bzrlib the duplication will continue.
> https://bugs.launchpad.net/bzr-gtk/+bug/215674 also contains
> some comments related to the feature I think (but Alex should
> already know about that).
The discussion is rather long and I saw only beginning of that.
Alexander Belchenko
interested not only for qbzr. I'm trying to explain how I'd like to implement it for qbzr, so maybe
my approach will be interesting for bzr-gtk, and in far far future will be move it in the core (who
knows?).
Background
----------
When user trying to commit from command-line and commit fails because of some blockers it's possible
to remove blockers and then invoke the same commit again using shell history. Therefore user can
reuse commit parameters such as commit message, --fixes, --author. When user working with GUI commit
dialogs these data should be saved by GUI itself, otherwise user will have to enter these data again
by hands.
When user uncommit it's may be because he/she want to improve either the code committed or committed
message of other metadata. VCS don't know intent of the user so it make sense to save messages and
other metadata in uncommit hook and then reuse it on subsequent commit. The data should be saved in
similar way as for ordinal commit in GUI, so commit dialog will use any saved data.
Command-line bzr can save and reuse uncommitted revisions too, but there is no UI for this right
now. If there will be UI to reuse saved data, then command-line bzr users even can rely on saved
data when previous commit fails.
So, discussed approach is more interesting for GUI tools, but because some users have installed both
qbzr and bzr-gtk in the same time then there will be big overlap in implementation and duplication
in uncommit hooks. So maybe it make sense to have this code actually in bzr core, including uncommit
hook.
Existing implementations
------------------------
bzr-gtk
*******
Stores commit message in branch.conf as gtk_global_commit_message and gtk_file_commit_messages
variables. The former used for usual commit messages, the latter used for per-file commit messages
(used by MySQL team only AFAIK). Global commit message saved as string, per-file commit messages
saved as bencoded dict of messages.
When there is uncommitted more than 1 revision messages of all uncommitted revisions joined as one
big text with '***********' as separator between chunks.
qbzr
****
Stores commit message in branch.conf as qbzr_commit_message variable. Message saved as string.
Uncommit hook saves only message for the old tip revision, if there is uncommitted more than 1
revisions all other messages are lost.
As one could see both GUI tools used similar approach, but bzr-gtk also supports per-file messages.
QBzr don't have support for them mostly because there is no documentation on this feature, and
de-facto bzr-gtk is the only one tool that supports them and therefore should be used as reference
implementation. I'd like to hear how support of per-file messages actually works in viz and
gannotate, if this possible.
Both tools does not save --fixes or --author metadata today, but qbzr want to implement support for
--fixes (at least) so corresponding discussion have started in qbzr ML and and this e-mail is the
result of this discussion.
Problems or is there possible to have ideal solution?
-----------------------------------------------------
Although both tools using similar approaches but there is several problems in each implementation.
When user uncommit several revisions it's not clear what is user intent. Should we save all messages
or only latest one? There is no simple answer because it depends on context.
QBzr users want to have more data saved, e.g. ids of fixed bugs. This is really should be handy.
Thinking further we need to save --author option as well, although it used very rare.
bzr-gtk does not have support in gcommit for --fixes and --author AFAIK, but maybe one day will have.
Saving different data as multiple variables in branch.conf leads to non-atomic behavior, even more
manipulating with branch.conf requires branch locking, so operation of saving the data should be
atomic and implemented as single shot.
Therefore it's make sense to use bencoded dict to save many different data in one variable: global
message, per-file messages dict, fixed bugs, authors.
Using branch.conf is only one existing option in bzr core today, but if one starts thinking about
lightweight checkouts then it becomes obvious that saved commit metadata should be saved in the
checkout itself, not in master branch, especially because it could be remote and even more read-only
location.
So, I think there should be new config for tree object, e.g. as .bzr/checkout/tree.conf file.
And saved commit metadata should live there.
Plans for new QBzr implementation
---------------------------------
To have easily extendable solution and to address lightweight checkouts problem I think we need to
implement for QBzr following:
1) Save the data in tree.conf as commit_data variable
2) Save the data as bencoded dict, with keys/values as following: message (list of texts),
per-file-message (also dict, values should be lists of texts), fixes (list of ids), authors (list of
names). If some tool does not understand some metadata it will ignore them.
3) For messages should be used lists of strings, so we can support uncommit of several revisions, if
qbzr will wish this in the future.
Of course this approach may have some weakness, but it's the best I have in mind today taking into
account all problems listed above.
So, I'm planning to implement in near future support for qbzr as described above.
If bzr-gtk developers think this approach could be interested for their tool, we can discuss how to
share the code. If other parties interesting to talk about different variants or knows another
problems I've not listed there, I'm open for constructive discussion.
But in the end I'm planning to implement described above as good enough support for qbzr, even if it
will be no ideal solution for everyone.
Alexander.
Vincent Ladeuil
comments in the other thread ([rfc] bencode unicode strings).
I try to clarify my thoughts on the subject below.
>>>>> "bialix" == Alexander Belchenko <bia...@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.
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 !
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 !
Vincent
Alexander Belchenko
> 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 <bia...@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.
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.
Gary van der Merwe
For uncommit, it might be better to save just the revid(s). Then the
dialog can load all the information that it needs by loading these
revisions.
The save on cancel would then be a separate code path :-(
Vincent Ladeuil
<snip/>
Gary> For uncommit, it might be better to save just the
Gary> revid(s). Then the dialog can load all the information
Gary> that it needs by loading these revisions.
Gary> The save on cancel would then be a separate code path
Gary> :-(
It complicates code (separate code path), it complicates UI (use
aborted commit info or uncommit one), but damn, it sounds so much
cleaner !
Vincent
Alexander Belchenko
We can (and perhaps should) save both message(s) and revids on uncommit.
And save revid=None for canceled commit. Then we can avoid 2 separate
code paths. N'est pas?
Gary van der Merwe
Crazy idea #2 of the day:
If the user presses cancel. create a revision, with no changes, with
no parents, that we can store the relevant metadata in.
Vincent Ladeuil
<snip/>
Gary> The save on cancel would then be a separate code path
Gary> :-(
>>
>> It complicates code (separate code path), it complicates
>> UI (use aborted commit info or uncommit one), but damn, it
>> sounds so much cleaner !
bialix> We can (and perhaps should) save both message(s) and
bialix> revids on uncommit. And save revid=None for canceled
bialix> commit. Then we can avoid 2 separate code
bialix> paths. N'est pas?
Sure, that's certainly a good idea, but I think Garry's idea was
to save the revid only on uncommit to avoid saving the message.
Vincent
Gary van der Merwe
I've been using bzr-builddeb a bit lately. One of the things that it
does, is pull what you have added to debian/changelog and adds it to
you commit file (that opens in you editor if you bzr commit with out
-m.) But if you do qcommit or gcommit, it does not pull this up.
So I think we need a api to say give me the default/restored commit
message + and other metadata (--fixes, --author). The bzr cli should
read the message and write it to the message file, and ignore the
other metadata. qcommit and gcommit can use all the data.
Plugins, such as bzr-builddeb, should be able to hook in to provide
this data if appropriate. A plugin that I would like to write is one
that will provide a default message "Merge %s." % merged_branch_nick
if you have done a merge.
Alexander Belchenko
Then we have to create our own hook perhaps.
Existing hook in bzrlib/msgeditor.py is too much CLI-oriented IMO.
Alexander Belchenko
New plan see below.
Alexander Belchenko пишет:
> Plans for new QBzr implementation
> ---------------------------------
> To have easily extendable solution and to address lightweight checkouts problem I think we need to
> implement for QBzr following:
>
> 1) Save the data in tree.conf as commit_data variable
Save the data in branch.conf as [commit_data] section.
> 2) Save the data as bencoded dict, with keys/values as following: message (list of texts),
> per-file-message (also dict, values should be lists of texts), fixes (list of ids), authors (list of
> names). If some tool does not understand some metadata it will ignore them.
Save the data "as is" using ConfigObj ability to handle dicts and nested
dicts as subsections.
> 3) For messages should be used lists of strings, so we can support uncommit of several revisions, if
> qbzr will wish this in the future.
Save only one message for not-committed yet revision or tip of
uncommitted chain. For uncommit save also beginning and end revids of
uncommitted chain (mainline revids only). For usual commit these revids
will be None or some other special string used by bzrlib internally to
say "no revision".
New approach is simpler and therefore easier to achieve. I'm working on
it now.
Alexander Belchenko
> New approach is simpler and therefore easier to achieve. I'm working on
> it now.
OK, I've finished this work and it's available now in lp:~qbzr-dev/qbzr/commit_data.
Craig, I'd like to hear some feedback from you, if you can test it.
Here is merge proposal:
https://code.launchpad.net/~qbzr-dev/qbzr/commit_data/+merge/10040
I'll wait couple of days for comments/review before landing it.
Gary/Vincent: if you will have a chance to look -- it will be nice.
craig Hewetson
I've removed my "bugfixes" branch. As usual I will update my qbzr with the latest version in trunk.
I'll test those bug fixes and try and find any regressions in the process.
Thanks for the quick response in bug fixing and feature development.