I'm excited to say that Explorer+QBzr is getting closer every week to being good enough for me to stay off the command line altogether. The biggest reason for me to fire up a terminal shell is shelve/unshelve functionality.
Is anyone else in need of this? If so, Are you in need enough to write it? :-) It would be awesome to have this in the next release or two of QBzr IMO.
> I'm excited to say that Explorer+QBzr is getting closer every week to > being good enough for me to stay off the command line altogether. The > biggest reason for me to fire up a terminal shell is shelve/unshelve > functionality.
> Is anyone else in need of this?
I'd like to have GUI for shelve, yes.
> If so, Are you in need enough to write > it? :-)
No, I'm overloaded by other things. Once I'll get free time I'm planning to work over our long-standing merge proposals. And maybe over bzr-explorer merge proposals too. The recent thread about patches inclusion to bzr made me think about our situation which is very bad.
Manpower! Manpower! Come to us!
> It would be awesome to have this in the next release or two of > QBzr IMO.
My personal wishlist for QBzr is order of magnitude longer :-/
> I'm excited to say that Explorer+QBzr is getting closer every week to being > good enough for me to stay off the command line altogether. The biggest > reason for me to fire up a terminal shell is shelve/unshelve functionality.
I'd love to see this as well.
> Is anyone else in need of this? If so, Are you in need enough to write it? > :-) It would be awesome to have this in the next release or two of QBzr IMO.
I'd like to try, but I feel that my knowledge of how to do things "the correct way" with QBzr is still lacking. And there's the whole free time thing (it would probably take me hours to write, and I only get ~1 of those a day for things like this--if I'm lucky).
> On Mon, Nov 9, 2009 at 8:42 PM, Ian Clatworthy > <ian.clatwor...@canonical.com> wrote: >> I'm excited to say that Explorer+QBzr is getting closer every week to being >> good enough for me to stay off the command line altogether. The biggest >> reason for me to fire up a terminal shell is shelve/unshelve functionality.
> I'd love to see this as well.
>> Is anyone else in need of this? If so, Are you in need enough to write it? >> :-) It would be awesome to have this in the next release or two of QBzr IMO.
> I'd like to try, but I feel that my knowledge of how to do things "the > correct way" with QBzr is still lacking. And there's the whole free > time thing (it would probably take me hours to write, and I only get > ~1 of those a day for things like this--if I'm lucky).
I'm sure Gary and me can mentoring anyone who willing to help.
The first thing that should be done (IMO) is to define sketch of UI for this command.
The one most irritating thing with shelve for me is inability to split hunks. Sometimes I have 2 unrelated changes very close to each other (2-3 unchanged lines between them) and I simply can't simply shelve one and keep other. :-/
On Tue, Nov 10, 2009 at 5:54 AM, Alexander Belchenko <bia...@ukr.net> wrote:
[snip]
> I'm sure Gary and me can mentoring anyone who willing to help.
Thanks!
> The first thing that should be done (IMO) is to define sketch of UI for this > command.
I can't do this today, but I'll try sketching up something over the next several days.
> The one most irritating thing with shelve for me is inability to split > hunks. Sometimes I have 2 unrelated changes very close to each other (2-3 > unchanged lines between them) and I simply can't simply shelve one and keep > other. :-/
Same here. I haven't looked at the underlying apis to know whether splitting by lines is possible. I'll try and take a look at that too.
On Tue, Nov 10, 2009 at 12:16 PM, John Szakmeister <j...@szakmeister.net> wrote:
> On Tue, Nov 10, 2009 at 5:54 AM, Alexander Belchenko <bia...@ukr.net> wrote: > [snip] >> I'm sure Gary and me can mentoring anyone who willing to help.
> Thanks!
>> The first thing that should be done (IMO) is to define sketch of UI for this >> command.
> I can't do this today, but I'll try sketching up something over the > next several days.
>> The one most irritating thing with shelve for me is inability to split >> hunks. Sometimes I have 2 unrelated changes very close to each other (2-3 >> unchanged lines between them) and I simply can't simply shelve one and keep >> other. :-/
> Same here. I haven't looked at the underlying apis to know whether > splitting by lines is possible. I'll try and take a look at that too.
> -John
Last time I checked there was an unmerged branch in launchpad for bzr[1] that had the needed functionality. Maybe it is worth a check ?
> On Tue, Nov 10, 2009 at 12:16 PM, John Szakmeister <j...@szakmeister.net> wrote: >> On Tue, Nov 10, 2009 at 5:54 AM, Alexander Belchenko <bia...@ukr.net> wrote: >> [snip] >>> I'm sure Gary and me can mentoring anyone who willing to help. >> Thanks!
>>> The first thing that should be done (IMO) is to define sketch of UI for this >>> command. >> I can't do this today, but I'll try sketching up something over the >> next several days.
>>> The one most irritating thing with shelve for me is inability to split >>> hunks. Sometimes I have 2 unrelated changes very close to each other (2-3 >>> unchanged lines between them) and I simply can't simply shelve one and keep >>> other. :-/ >> Same here. I haven't looked at the underlying apis to know whether >> splitting by lines is possible. I'll try and take a look at that too.
>> -John
> Last time I checked there was an unmerged branch in launchpad for > bzr[1] that had the needed functionality. Maybe it is worth a check ?
>>>> The one most irritating thing with shelve for me is inability to split >>>> hunks. Sometimes I have 2 unrelated changes very close to each other >>>> (2-3 >>>> unchanged lines between them) and I simply can't simply shelve one >>>> and keep >>>> other. :-/ >>> Same here. I haven't looked at the underlying apis to know whether >>> splitting by lines is possible. I'll try and take a look at that too.
>>> -John
>> Last time I checked there was an unmerged branch in launchpad for >> bzr[1] that had the needed functionality. Maybe it is worth a check ?
Aaron Bentley has proposed something where he starts an editor in order to have fine-grained control over what you want to save and shelve. I haven't looked at it closely, but it is certainly meant to help with this situation.
John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
On Tue, Nov 10, 2009 at 5:54 AM, Alexander Belchenko <bia...@ukr.net> wrote:
[snip]
> I'm sure Gary and me can mentoring anyone who willing to help.
> The first thing that should be done (IMO) is to define sketch of UI for this
> command.
> The one most irritating thing with shelve for me is inability to split
> hunks. Sometimes I have 2 unrelated changes very close to each other (2-3
> unchanged lines between them) and I simply can't simply shelve one and keep
> other. :-/
So here's a stab at an initial gui. Let me say right off the bat, I'm
not happy with it (too much visual white space, and I'm not addressing
a couple other issues that I want to bring up).
Alexander, I agree: splitting hunks is something I want to see as
well. I really like SlickEdit's interface when dealing with diffs...
and I see qshelve being similar. Namely, there are a couple of
buttons, block and line, that will shelve a block or just a line.
Typically, in SlickEdit moving a block over would cause it to move the
contents and make it move to the next diff whereas line would not.
I've really come to enjoy the block behavior because I can quickly go
through reverting whole blocks and only click a button to do each one.
I think it's nice to have buttons to quickly jump to the next and
previous files ("I'm not shelving anything here", and "Whups, I need
to go back and shelve one more change"). There is also the issue of
shelving the renaming of a file versus shelving the contents. I'm
tempted to say that "All" will shelve everything, including the rename
and if you don't want that, then shelve the entire contents by
repeatedly hitting the "Block" button.
I think having the list of files that are modified is a good thing
(makes it easy to target a file to shelve changes in). My current
thought process is to use color to distinguish whether or not a file
has shelved changes. Perhaps there is something else that makes more
sense? I'm also not entirely sure how to pull off the diff view, but
I think I have a couple ideas to help get me started. I think it's
easier to understand what's happening with SlickEdit's diff viewer
that QBzr's for this kind of stuff. Just for reference, here is an
example of SlickEdit's diff viewer:
http://www.szakmeister.net/downloads/vsdiff.png
It may make more sense to have the file list as a separate dialog, and
pop-up the shelving gui whenever you want to shelve changes in a file?
We could make it so that you can start with a file and cruise through
the whole set. Thoughts on any of this?
Thanks! And my apologies for taking so long to get something out
there... I've been swamped at work and at home. :-(
> On Tue, Nov 10, 2009 at 5:54 AM, Alexander Belchenko <bia...@ukr.net> wrote:
> [snip]
>> I'm sure Gary and me can mentoring anyone who willing to help.
>> The first thing that should be done (IMO) is to define sketch of UI for this
>> command.
>> The one most irritating thing with shelve for me is inability to split
>> hunks. Sometimes I have 2 unrelated changes very close to each other (2-3
>> unchanged lines between them) and I simply can't simply shelve one and keep
>> other. :-/
> So here's a stab at an initial gui. Let me say right off the bat, I'm
> not happy with it (too much visual white space, and I'm not addressing
> a couple other issues that I want to bring up).
I'm not very like the current form too.
We several times discussed how we want to improve the qdiff: putt all files in the tabs, add the
list of modified files. So I want to say that I'd like to use tabs for shelve from the start.
Navigation between tabs can be done by Qt itself, so we don't need to invent Next File/Prev File
buttons.
On your screenshot the right bottom corner supposed to be used for file list? It occupies too much
valuable space, so put the file list separately seems like the better idea for me.
Also I have one big concern about reinventing the wheel. It's fun of course, but given in mind we
all have not infinite amount of free time to do the qbzr improvements I think we need at least
looking around and decide if we can or can't reuse something similar or ready-to-use.
We have support for launching external diff tools in qdiff. Your screenshot shows us there is
already existing tools with good UI for such sort of tasks. More: recently I've made big job of
moving changes from one tree to another with WinMerge tool on Windows (I've gave up to use bzr merge
for this task because of different file-ids; /sigh thouse fileids is so fileids!). And I should say
that I found WinMerge is really cool tool to sync changes between 2 sides, selectively copy hunks
between files. It's roughly the same we want from qshelve, IMO.
So... I think we can look at the variant of running external diff tool (SlickEdit in your case?) to
delegate the "shelving" to more rich tool. Recently in bzr core has added feature to shell to be
able run some external tool (editor) to edit the file and shelving auto-guessed on new file content.
I'm not quite understand how it should work, nor I see it in action yet. But this can be big time
saver for us.
In the case of external tool usage we need a list of modified files (e.g. like in qcommit/qrevert)
with 3-states checkboxes: unchecked means don't touch/shelve the file, checked fully means shelve
all changes, and checked partially means shelve the part of changes. Double click on file will open
external tool then.
But all this does not help in default mode when user don't configure the external tool yet.
> Alexander, I agree: splitting hunks is something I want to see as
> well. I really like SlickEdit's interface when dealing with diffs...
> and I see qshelve being similar. Namely, there are a couple of
> buttons, block and line, that will shelve a block or just a line.
> Typically, in SlickEdit moving a block over would cause it to move the
> contents and make it move to the next diff whereas line would not.
> I've really come to enjoy the block behavior because I can quickly go
> through reverting whole blocks and only click a button to do each one.
> I think it's nice to have buttons to quickly jump to the next and
> previous files ("I'm not shelving anything here", and "Whups, I need
> to go back and shelve one more change"). There is also the issue of
> shelving the renaming of a file versus shelving the contents. I'm
> tempted to say that "All" will shelve everything, including the rename
> and if you don't want that, then shelve the entire contents by
> repeatedly hitting the "Block" button.
> I think having the list of files that are modified is a good thing
> (makes it easy to target a file to shelve changes in). My current
> thought process is to use color to distinguish whether or not a file
> has shelved changes. Perhaps there is something else that makes more
> sense? I'm also not entirely sure how to pull off the diff view, but
> I think I have a couple ideas to help get me started. I think it's
> easier to understand what's happening with SlickEdit's diff viewer
> that QBzr's for this kind of stuff. Just for reference, here is an
> example of SlickEdit's diff viewer:
> http://www.szakmeister.net/downloads/vsdiff.png
> It may make more sense to have the file list as a separate dialog, and
> pop-up the shelving gui whenever you want to shelve changes in a file?
> We could make it so that you can start with a file and cruise through
> the whole set. Thoughts on any of this?
> Thanks! And my apologies for taking so long to get something out
> there... I've been swamped at work and at home. :-(
On Tue, Nov 24, 2009 at 1:48 AM, Alexander Belchenko <bia...@ukr.net> wrote:
> Hi John,
> Thanks for starting sketching this.
No problem!
> John Szakmeister пишет:
[snip]
> I'm not very like the current form too.
No worries. :-)
> We several times discussed how we want to improve the qdiff: putt all files in the tabs, add the
> list of modified files. So I want to say that I'd like to use tabs for shelve from the start.
> Navigation between tabs can be done by Qt itself, so we don't need to invent Next File/Prev File
> buttons.
How does that work for lots of files? I think finding the right tab
at that point might be difficult. Or is the idea to have a tab with
the list of modified files, and then you choose what files you want to
edit, and they show up in different tabs?
> On your screenshot the right bottom corner supposed to be used for file list? It occupies too much
> valuable space, so put the file list separately seems like the better idea for me.
I assume you mean on a separate tab? Nevermind, I see you explained
what you were thinking further down.
> Also I have one big concern about reinventing the wheel. It's fun of course, but given in mind we
> all have not infinite amount of free time to do the qbzr improvements I think we need at least
> looking around and decide if we can or can't reuse something similar or ready-to-use.
Personally, I don't get much satisfaction out of re-inventing wheels.
:-) OTOH, I'd like it to work out of the box for people. There's
already so much that's required to use Bazaar and some of it's best
plugins. :-)
> We have support for launching external diff tools in qdiff. Your screenshot shows us there is
> already existing tools with good UI for such sort of tasks. More: recently I've made big job of
> moving changes from one tree to another with WinMerge tool on Windows (I've gave up to use bzr merge
> for this task because of different file-ids; /sigh thouse fileids is so fileids!). And I should say
> that I found WinMerge is really cool tool to sync changes between 2 sides, selectively copy hunks
> between files. It's roughly the same we want from qshelve, IMO.
> So... I think we can look at the variant of running external diff tool (SlickEdit in your case?) to
> delegate the "shelving" to more rich tool. Recently in bzr core has added feature to shell to be
> able run some external tool (editor) to edit the file and shelving auto-guessed on new file content.
> I'm not quite understand how it should work, nor I see it in action yet. But this can be big time
> saver for us.
I can start working towards that goal first. There are several issues
I see though:
* If I launch the tool against a single file, I don't see how we can
have a speedy workflow. The reason being that we can't tell when the
user exits the app that the intent was to move to the next file or
not.
* If I launch the tool against a series of files (which I'm not sure
how I'd do that), then it's really the external tool that helps speed
up the workflow (which I'm fine with). I guess in this case, I could
have an option to run against all files?
I'd really like to keep the workflow fast. I had some scripts that
essentially helped me to do this sort of thing with Subversion, and it
was a life-saver.
> In the case of external tool usage we need a list of modified files (e.g. like in qcommit/qrevert)
> with 3-states checkboxes: unchecked means don't touch/shelve the file, checked fully means shelve
> all changes, and checked partially means shelve the part of changes. Double click on file will open
> external tool then.
Can the user directly set the state of the checks? I would guess not
since checked partially doesn't make much sense. OTOH, changing it to
shelve all or shelve none makes sense.
> But all this does not help in default mode when user don't configure the external tool yet.
Precisely. But I see where you're going. We can add that part down the road.
Thanks for taking the time to elaborate on your ideas (and some of the
past history that I missed!). I'll give that a shot. Unfortunately,
this week is crazy for me, so it may take me a while to get back to
you with something.
On Tue, Nov 24, 2009 at 4:59 PM, Alexander Belchenko <bia...@ukr.net> wrote:
> Gary van der Merwe пишет:
>> I think the UI should be like this: http://imagebin.ca/view/3qpWxmJ.html
> Am I understand correctly that you screenshot implies there will be no way to select changes at line level vs. default hunk level?
Good point. No.
I should point out though, that it gives you more fine grained control
that cli shelve. Shelve only allows you to select a group of hunks.
Araxis Merge has a feature where you can set "Synchronization Links"
[1]. As a side affect, it also can be used to split hunks. This has
given me an idea for qdiffmerge, but it would be usable for this to.
You would right click on a hunk, and click on "Split Hunk". It will
then show a arrow where it has split the hunk, and you can drag it up
and down. This won't allow you to split a hunk mid line though.
> You would right click on a hunk, and click on "Split Hunk". It will
> then show a arrow where it has split the hunk, and you can drag it up
> and down. This won't allow you to split a hunk mid line though.
It won't but it would still be awesomely useful. I can't wait!
> On Tue, Nov 24, 2009 at 4:59 PM, Alexander Belchenko <bia...@ukr.net> wrote:
>> Gary van der Merwe пишет:
>>> I think the UI should be like this: http://imagebin.ca/view/3qpWxmJ.html >> Am I understand correctly that you screenshot implies there will be no way to select changes at line level vs. default hunk level?
> Good point. No.
> I should point out though, that it gives you more fine grained control
> that cli shelve. Shelve only allows you to select a group of hunks.
That's exactly what we discussed with John earlier in this thread. It seems many people do not feel happy with current hunk-or-nothing approach.
> Araxis Merge has a feature where you can set "Synchronization Links"
> [1]. As a side affect, it also can be used to split hunks. This has
> given me an idea for qdiffmerge, but it would be usable for this to.
> You would right click on a hunk, and click on "Split Hunk". It will
> then show a arrow where it has split the hunk, and you can drag it up
> and down. This won't allow you to split a hunk mid line though.
I have no experience with Araxis, but do have experience with WinMerge.
The latter is not ideal tool and it can't split hunks, but I like that I can use simple keyboard commands there to copy hunks between sides with Alt+Arrow (Left/Right) and Alt+Arrow (Up/Down) to jump between hunks.
So I'd like to have comparable rich keyboard commands there and in addition (say with Alt+Shift or somesuch) have ability to copy one current line to left or right.
I really don't think all this checkboxes are mandatory for shelve. Just 2 sides diff with final result of the file at right and latest committed version at right. IIUC this is how it supposed to work in builtin shelve with editor support.
> But all this does not help in default mode when user don't configure the external tool yet.
> (To be continued...)
Sorry I did not finished my previous mail because I had to go that day.
I want to say that we definitely need built-in shelve selector/editor and your ideas is good spark IMO.
But as you saw Gary also has some plans re improvements of qdiff and then reuse it for qshelve.
Although I think we can get the working prototype of qshelve regardless of his current work, or we can wait for Gary's improvements.
Anyway there is need for matching GUI for qunshleve, which does not require complicated editor, but rather list of available shelves and ability to unshelve or just delete corresponding entry.
On Wed, Nov 25, 2009 at 4:33 AM, Alexander Belchenko <bia...@ukr.net> wrote:
> Alexander Belchenko пишет:
>> But all this does not help in default mode when user don't configure the
>> external tool yet.
>> (To be continued...)
> Sorry I did not finished my previous mail because I had to go that day.
No worries.
> I want to say that we definitely need built-in shelve selector/editor and
> your ideas is good spark IMO.
> But as you saw Gary also has some plans re improvements of qdiff and then
> reuse it for qshelve.
I've seen that discussion... I'm thoroughly excited about it too!
> Although I think we can get the working prototype of qshelve regardless of
> his current work, or we can wait for Gary's improvements.
I think we can get started, and work in Gary's stuff along the way.
It's going to take me a while, so he's likely to be ready before I am.
:-)
> Anyway there is need for matching GUI for qunshleve, which does not require
> complicated editor, but rather list of available shelves and ability to
> unshelve or just delete corresponding entry.
*nods* Yeah, that one seems like the easy one to knock out. :-)
On Wed, Nov 25, 2009 at 5:30 AM, John Szakmeister <j...@szakmeister.net> wrote:
[snip]
>> Although I think we can get the working prototype of qshelve regardless of
>> his current work, or we can wait for Gary's improvements.
> I think we can get started, and work in Gary's stuff along the way.
> It's going to take me a while, so he's likely to be ready before I am.
> :-)
Just an FYI: I've been *swamped* at work lately. I just had to change
programs, and now I'm busting tail trying to clean up a mess.
Unfortunately, it's really eating into my dev time at home. :-( So
while I've made some progress, I'm not anywhere close to where I want
to be yet. If it has become too long to wait, I promise not to be
offended if someone wants to take it over. Otherwise, I'll hopefully
have a little dev time when the holidays get a little closer.
