QBzr planning for the next 6 months
Ian Clatworthy
next 6 months? It would be good to reach 1.0 in that time, yes? What do
we think is still required for that?
Some things I'd like to see:
* qshelve & qunshelve
* qsend improved, including a "format" combo for sending bundles
off in git and hg format
* smart forms within qrun, not just a text field, for arg & option entry
* multiple author support within qcommit
* most custom dialogs in Explorer moved down into the QBzr layer.
Thoughts?
Ian C.
INADA Naoki
* Add "-r" to qupdate.
* Add "Update to this revision" menu in qlog.
* Add 2 pane view to qbrowse. Left pane is directory tree and right
pene is icon view, like windows explorer.
This should support Cut&Paste, Drag&Drop moving when browsing working tree.
* Add qmove. "mv --auto --preview" and "mv --after" in GUI.
--
INADA Naoki <songof...@gmail.com>
INADA Naoki
--
INADA Naoki <songof...@gmail.com>
Gary van der Merwe
> Any thoughts on the goals we ought to set for QBzr development in the
> next 6 months? It would be good to reach 1.0 in that time, yes? What do
> we think is still required for that?
>
> Some things I'd like to see:
>
>
> * qsend improved, including a "format" combo for sending bundles
> off in git and hg format
>
>
> * multiple author support within qcommit
>
> * most custom dialogs in Explorer moved down into the QBzr layer.
>
> Thoughts?
>
> Ian C.
What I plan to work on:
* Find/Goto line for Cat/Annotate/Diff (wip: lp:~garyvdm/qbzr/annotate_find)
* Improve diff:
* Better block alignment & scrolling.
* Tabbed view ( + ui to switch between continues and tabbed)
* Allow for editing wt files & reverting blocks.
* More view options:
* line wrap
* Tab size
* Chose file type for syntax highlighting.
* Show white space.
* Allow for per file ui options (e.g. encoding, some of the view
options mentioned above)
* Able to cater for qshelve & qcommit block selection.
* 3 way Diff Merge, integrated with annotate.
* Investigate a new idea for 2 threads.
craig Hewetson
Our source code trees are getting bigger and bigger and I've received feedback from fellow developers that the qadd, qcommit and qbrowse dialogs are getting slower.
All the new features that you guys mentioned sounds great but for me performance is key.
Gary van der Merwe
Sure. I can look at that.
One thing that would be a big help with this is if you can create
example branches that have performance problems.
craig Hewetson
One thing that would be a big help with this is if you can create example branches that have performance problems.
Unfortunately the source I work on is closed.
Alexander Belchenko
Then we need for example any big open-source Java project, we can get
the copy of it's history and tree with bzr-svn, for example.
Nicholas Allen
I work on large Java projects and am not noticing any performance
problems. It may be because my class files are output into a different
directory than the source files so I only ignore the output directory
and not the *.class pattern. Also I have a reasonable amount of RAM (12
GB) so the cache is always warm. I would expect you're seeing these
problems for one or both of those reasons....
Nick
Gary van der Merwe
I just realised what is happening with qadd when you have lots of
ignored files (bug 513105). That should easy to fix.
What else is slow?
Alexander Belchenko
> Any thoughts on the goals we ought to set for QBzr development in the
> next 6 months? It would be good to reach 1.0 in that time, yes?
I'm not sure about 1.0 at all.
> What do
> we think is still required for that?
Fixing all real bugs, perhaps? (It was a semi-joke).
> Some things I'd like to see:
>
> * qshelve & qunshelve
Will be nice, but hard. I've recently played with editor support in
shelve, it's really nice. If we won't try to reimplement the wheel and
mostly using existing support it will help a lot.
> * qsend improved, including a "format" combo for sending bundles
> off in git and hg format
Sounds easy enough.
> * smart forms within qrun, not just a text field, for arg & option entry
Tricky, mostly because we need to invent something universal.
> * multiple author support within qcommit
Should be easy, Craig made some sketches in the past.
> * most custom dialogs in Explorer moved down into the QBzr layer.
>
> Thoughts?
I have no specific proposals today, mostly because have a little free
time these days.
craig Hewetson
I work on large Java projects and am not noticing any performance
problems. It may be because my class files are output into a different
directory than the source files so I only ignore the output directory
and not the *.class pattern. Also I have a reasonable amount of RAM (12
GB) so the cache is always warm. I would expect you're seeing these
problems for one or both of those reasons....
There are 43,075 items (directories + files, excluding eclipse workspaces and the .bzr directory) in my tree.
I think the problem might be that there is just a lot of directories. Also some of the projects I get full control over have their .class files in a separate bin directory.
I think with your 12GB of memory and running Ubuntu (since last time we spoke) your machine doesn't count ;-)
@Alexander:
>>Then we need for example any big open-source Java project, we can get the copy of it's history and tree with bzr-svn, for example.
http://community.jboss.org/wiki/SVNRepository
and
http://wiki.services.openoffice.org/wiki/Setting_up_Subversion_Access
Also I know that mysql uses bazaar and they should have a large source repo. (Although its not a Java project, the shear size of the repo might expose other weakness)
@Gary:
The "other" performance issues come from fellow collegues that run Windows and MacOSx. The bug I logged was the only issue that I found on my machine. But I know that qbrowse in bzr-explorer does take a long time for me when I use the "filter" combo box for the first time. But this could just be solved by giving progress feedback to the user.
Gary van der Merwe
> @Gary:
> The "other" performance issues come from fellow collegues that run
> Windows and MacOSx. The bug I logged was the only issue that I found on
> my machine. But I know that qbrowse in bzr-explorer does take a long
> time for me when I use the "filter" combo box for the first time. But
> this could just be solved by giving progress feedback to the user.
Sounds like https://bugs.launchpad.net/qbzr/+bug/476641
John Szakmeister
[snip]
>> * qshelve & qunshelve
>
> Will be nice, but hard. I've recently played with editor support in shelve,
> it's really nice. If we won't try to reimplement the wheel and mostly using
> existing support it will help a lot.
Ditto. I've been looking at how to run a shelve operation and,
unfortunately, it's not as easy as I had hoped. I've also been tied
up with moving, and some work related things so my progress has been
slooow. :-(
-John
craig Hewetson
A low bug count for the project will make things easier for the developers.
Alexander Belchenko
> Apart from all the features mentioned, maybe a large set of (non-wishlist) bugs
> needs to be assigned to a 1.0 milestone?
> A low bug count for the project will make things easier for the developers.
I've tried go this path in the summer 2008, and have planned to release
1.0 at the end of that year. I have failed, mostly because Gary starts
to contribute a lot of cool new features (thanks, Gary!) but
unfortunately new features introduce new bugs from time to time. This is
endless story, and it makes me depressed. :-(
We need new features, but it's hard to get them right from the start and
bugless :-(
Alexander Belchenko
Just to be honest: I'm introduce new bugs too!
Gary, please don't consider my mail as offence, I really like your work!
We're all humans.
Gary van der Merwe
> Just to be honest: I'm introduce new bugs too!
> Gary, please don't consider my mail as offence, I really like your work!
> We're all humans.
None taken...
craig Hewetson
After the "agreement" we cannot include more into 1.0, they must go to trunk.
NOTE: obviously fixes get cherry picked into trunk.
Ian Clatworthy
> There are 43,075 items (directories + files, excluding eclipse
> workspaces and the .bzr directory) in my tree.
That's a large project comparable in size to Firefox. OpenOffice is
around 80K items. I believe MySQL is around 8-10K items versioned in
their tree.
> The "other" performance issues come from fellow collegues that run
> Windows and MacOSx. The bug I logged was the only issue that I found on
> my machine. But I know that qbrowse in bzr-explorer does take a long
> time for me when I use the "filter" combo box for the first time. But
> this could just be solved by giving progress feedback to the user.
Explorer is using the qbrowse widget by default now. That widget is
smart enough to do lazy loading. However, I must load everything when
applying text filtering because I don't know what directories will
contain something matching the text deep inside them. That's why the
very first use of text filtering on a tree is slow - it's loading every
directory recursively.
I suspect there's space for tuning the widget further though. For
example, IIUIC, the tree is locked and unlocked for each directory load
rather than being locked and unlocked once.
Ian C.
Ian Clatworthy
I'd prefer to just set a date (like June 30) and allocate some time
before that to bug fixing. Timeboxing ftw.
Ian C.
Alexander Belchenko
If we do the 1.0 branch today it will be equivalent to call 0.18 series
as 1.0. Is it what we want right now? In the end 1.0 is just a number.
craig Hewetson
If we do the 1.0 branch today it will be equivalent to call 0.18 series as 1.0. Is it what we want right now? In the end 1.0 is just a number.
(I think its reached maturity a long time ago, but there is nothing wrong with high standards :-) ) If a lot of bugs get squashed then it will be more that just an impression.
But its not my call, just making suggestions to prompt the decision makers.
@Ian:
>>That's a large project comparable in size to Firefox. OpenOffice is around 80K items. I believe MySQL is around 8-10K items versioned in their tree.
Martin Pool
Yes please! This is the only way we'll be able to include explorer
bugfixes into later bzr 2.1.x installers, and into distros including
Ubuntu that ship our stable series.
--
Martin <http://launchpad.net/~mbp/>
Alexander Belchenko
Alexander Belchenko
> Any thoughts on the goals we ought to set for QBzr development in the
> next 6 months? It would be good to reach 1.0 in that time, yes? What do
> we think is still required for that?
I'd like to propose next timeline: till May (and UDS) we work on 0.19
and maybe 0.20. Then cut the 1.0 branch, call it beta and start fixing
all bugs which we think we have to fix.
Maybe we can sprint at UDS and set the goals more precisely.
I will assemble the list of features based on everyone proposals. But we
need to make 1.0 is planned in the terms of date/time. So any feature
which won't be ready to May won't be in 1.0. Something like that.
Gays, what do you think, is it sane plan?
Alexander Belchenko
sorry, I've started to type Gary, then Guys.
Martin Pool
Perhaps qbzr may want to mesh with that. I don't know what you could
do right away, but if we abstract the merge and conflict ui a bit
more, qbzr might be able to provide a graphical interface to it.
--
Martin <http://launchpad.net/~mbp/>
Gary van der Merwe
> In bzrlib, I'm going to ask people to focus on merge/conflict bugs.
> Perhaps qbzr may want to mesh with that. I don't know what you could
> do right away, but if we abstract the merge and conflict ui a bit
> more, qbzr might be able to provide a graphical interface to it.
Is this handling text conflicts, or other types of conflicts?
For text conflicts, I've long wanted to build a 3 way diff/merge window.
I started writing a spec about it. [1] The spec is not finished. I still
need to describe how it will integrate with annotate. This is the bit
that I think will help people alot with difficult merges.
Do you have any thing else in mind?
I'm not to familiar with the work Vincent has been doing. Where can I
read about this?
[1] http://wiki.bazaar.canonical.com/qbzr/Blueprint/diffmerge
Gary van der Merwe
On 17/02/2010 08:12, Gary van der Merwe wrote:
> What I plan to work on:
>
> * Find/Goto line for Cat/Annotate/Diff (wip:
> lp:~garyvdm/qbzr/annotate_find)
>
> * Improve diff:
> * Better block alignment & scrolling.
> * Tabbed view ( + ui to switch between continues and tabbed)
> * Allow for editing wt files & reverting blocks.
> * More view options:
> * line wrap
> * Tab size
> * Chose file type for syntax highlighting.
> * Show white space.
> * Allow for per file ui options (e.g. encoding, some of the view
> options mentioned above)
> * Able to cater for qshelve & qcommit block selection.
>
> * 3 way Diff Merge, integrated with annotate.
>
> * Investigate a new idea for 2 threads.
Martin Pool
> On 25/02/2010 11:19, Martin Pool wrote:
>>
>> In bzrlib, I'm going to ask people to focus on merge/conflict bugs.
>> Perhaps qbzr may want to mesh with that. I don't know what you could
>> do right away, but if we abstract the merge and conflict ui a bit
>> more, qbzr might be able to provide a graphical interface to it.
>
> Is this handling text conflicts, or other types of conflicts?
Both
> For text conflicts, I've long wanted to build a 3 way diff/merge window. I
> started writing a spec about it. [1] The spec is not finished. I still need
> to describe how it will integrate with annotate. This is the bit that I
> think will help people alot with difficult merges.
Integrating with annotating during merge could be amazing
>
> Do you have any thing else in mind?
>
>
> I'm not to familiar with the work Vincent has been doing. Where can I read
> about this?
http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution
>
> [1] http://wiki.bazaar.canonical.com/qbzr/Blueprint/diffmerge
>
--
Martin <http://launchpad.net/~mbp/>
Alexander Belchenko
> In bzrlib, I'm going to ask people to focus on merge/conflict bugs.
> Perhaps qbzr may want to mesh with that. I don't know what you could
> do right away, but if we abstract the merge and conflict ui a bit
> more, qbzr might be able to provide a graphical interface to it.
Maybe we can do:
* qmerge --preview
* better predefined extmerge / diff tools to resolve conflicts
* non-text conflicts resolution helpers? (there we need help from Vincent)
Vincent Ladeuil
Gary> On 25/02/2010 11:19, Martin Pool wrote:
>> In bzrlib, I'm going to ask people to focus on merge/conflict bugs.
>> Perhaps qbzr may want to mesh with that. I don't know what you could
>> do right away, but if we abstract the merge and conflict ui a bit
>> more, qbzr might be able to provide a graphical interface to it.
Gary> Is this handling text conflicts, or other types of conflicts?
All kind of conflicts. My work lately has been mostly focused on
tree-shape conflicts though.
Gary> For text conflicts, I've long wanted to build a 3 way
Gary> diff/merge window. I started writing a spec about
Gary> it. [1] The spec is not finished. I still need to
Gary> describe how it will integrate with annotate. This is
Gary> the bit that I think will help people alot with
Gary> difficult merges.
Giving access to annotations while resolving conflicts is
certainly one of the nicest thing a GUI can do to help.
Gary> Do you have any thing else in mind?
Yes. providing more help for *other* types of conflicts.
Gary> I'm not to familiar with the work Vincent has been doing. Where
Gary> can I read about this?
http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution
tracks both the work recently landed and the next steps.
Vincent
Gary van der Merwe
> Ian Clatworthy пишет:
>> Any thoughts on the goals we ought to set for QBzr development in the
>> next 6 months? It would be good to reach 1.0 in that time, yes? What do
>> we think is still required for that?
>
>
> I'd like to propose next timeline: till May (and UDS) we work on 0.19
> and maybe 0.20. Then cut the 1.0 branch, call it beta and start fixing
> all bugs which we think we have to fix.
Version Numbers
===============
I don't think our version number matter much to our users. QBzr is
really a library. When a user downloads a windows installer for bazaar,
they probably does not know than he is downloading qbzr, allthough they
would be very likely to use it. All though they are likely to notice the
bzr version number.
Maybe doing a 1.0 release will improve moral, and hence contributions
from both old, and new contributors. If this is the case, lets do it.
Otherwise, I don't see the point.
However...
Planing
=======
This is very important for me. It basically means, what do we work on
next. We need to ask: What new features will make the lives of existing
bzr users much easier? What features will make users of other dvcs say,
wow, thats cool, I better switch to bzr? What features will remove
obstacles for non vcs users so it becomes so it becomes just so easy,
that it feels natural.
> Maybe we can sprint at UDS and set the goals more precisely.
That sounds very good.
Iwata
* "Save As" menu in qbrowse and qlog(file list pane).
* qbrowse -r X..Y
* Additional menus in qlog.
- Export this revision
- Branch this revision
- Revert this revision (Reverse cherry picking)
- Revert to this revision, and so on.
* external diff improvement.
o definitions per file extensions.
o return without waiting end of diff application.(It arrows
me to open multiple files at once.)
Alexander Belchenko
> BTW, I wish these features.
>
> * "Save As" menu in qbrowse and qlog(file list pane).
+1, and for qcat/qannotate too.
> * qbrowse -r X..Y
Can you explain?
> * Additional menus in qlog.
> - Export this revision
> - Branch this revision
> - Revert this revision (Reverse cherry picking)
> - Revert to this revision, and so on.
+1, I think we have bug report on this wishlist.
> * external diff improvement.
> o definitions per file extensions.
Will be nice, yes.
Gary van der Merwe
> * Additional menus in qlog.
> - Export this revision
> - Branch this revision
> - Revert this revision (Reverse cherry picking)
That would be very nice.
> - Revert to this revision, and so on.
These days, I use update -r rather than revert -r. I find that it
causes me to run in to less gotchas.
Alexander Belchenko
Can you explain? What's benefits of this?
Gary van der Merwe
update has 2 advantages:
* It allows you to keep track of what revision you are on (by updating
the working tree tip and which shows up in qlog)
* It does merges
Typical update/revert -r is used for regression testing.
For bug 421039, I had tried regression testing it with revert -r, but
became stuck because older versions became incompatible with the
version of bzr. With update -r, I was able to make a small change to
fix this incompatibility, and then run update -r repeatedly, to find
the regression, having my compatibility fix merge in to the tree each
time.
Another example:
The other day my colleague found a regression using revert -r, and
then fixed it, but forgot to first revert (-r -1). So he lost his fix,
and had to redo it (not to serious because it was a small fix.) Had he
used update -r, he could have use update to merge his fix into the
latest version
update also allows you to do daggy fixes with out creating extra branches. i.e.:
update -r XX
hack hack hack
commit
update
commit
Iwata
>> * qbrowse -r X..Y
>
> Can you explain?
I want a dialog which can compare any 2 revisions (include working tree).
Please see https://answers.launchpad.net/qbzr/+question/92517
Alexander Belchenko
пїЅпїЅ пїЅпїЅпїЅпїЅ: Iwata <iwat...@gmail.com>
пїЅпїЅпїЅпїЅ: qb...@googlegroups.com
пїЅпїЅпїЅпїЅ: 28 пїЅпїЅпїЅпїЅпїЅпїЅпїЅ, 04:20:33
пїЅпїЅпїЅпїЅ: Re: [qbzr] QBzr planning for the next 6 months
2010/2/27 Alexander Belchenko <bia...@ukr.net>:
>> пїЅ пїЅ* qbrowse -r X..Y
>
> Can you explain?
I want a dialog which can compare any 2 revisions (include working tree).
Please see https://answers.launchpad.net/qbzr/+question/92517
So it should be actually qstatus -r X..Y
Gary van der Merwe
> update also allows you to do daggy fixes with out creating extra branches. i.e.:
>
> update -r XX
> hack hack hack
> commit
> update
> commit
I'm sorry. That is incorrect. You can't do the first commit if the wt
is not up to date.
craig Hewetson
In bzrlib, I'm going to ask people to focus on merge/conflict bugs.
Perhaps qbzr may want to mesh with that. I don't know what you could
do right away, but if we abstract the merge and conflict ui a bit
more, qbzr might be able to provide a graphical interface to it.
Also a status/description area can be give at the bottom of the list of conflicts to give the user a description of the reason for the conflict (per selection). as in "bzr help conflict-types".
I've attached a mockup of what I'm trying to describe.
Should start a different email discussion for this? Or is this thread fine?
Nicholas Allen
Nick
> ------------------------------------------------------------------------
>
Ian Clatworthy
> I love it Craig! Please implement this someone! ;-)
Me too!
I recently suggested that we should share the development load by
encouraging developers to adopt-a-dialog. Can someone please adopt
qconflicts and make this happen? See
http://wiki.bazaar.canonical.com/QBzr/Developers
Ian C.
Nicholas Allen
on the bottom of the dialog instead of taking up a whole row for itself.
I would also add some more options in the context menu. eg:
"Resolve all conflicts with my version"
"Resolve all conflicts with other version"
Nick
> ------------------------------------------------------------------------
>
Alexander Belchenko
Looks nice.
>
>
> ------------------------------------------------------------------------
>
Gary van der Merwe
That looks good.
I would like to talk about the internals of qconflicts. I would like it
to use the TreeWidget. This will have the following advantages.
* Functionality in than is available in the treewidget (revert, rename
ect) will be available in qconflicts.
* Improvements made to the treewidget for handling conflicts, such the
ones described by Craig, will be available in other dialogs such as qcommit.
What do we need to do before we can do this:
* We need to be able to filter the treeview to only show conflicts. The
is easy.
* Improvements to launching the ext merge. See
https://bugs.launchpad.net/qbzr/+bug/489915
craig Hewetson
@Gary
The filtered treewidget idea makes a lot of sense. Then we don't need custom right click actions.
Although I think that description area is important to help the user make the correct decision.
@Ian
My only problem (where it applies to me) with adopt-a-dialog is that my python skills aren't where I would like them to be. Its like adopting a child and not being able to feed it properly :)
I think the problem is that the project needs more active (seasoned python) developers, like Alexander, Gary and you. I feel they have the right to adopt a dialog and it is more effective if they do.