Merge lp:~parthm/bzr/538868-message-for-heavy-checkout into lp:bzr
| Status: | Superseded | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Proposed branch: | lp:~parthm/bzr/538868-message-for-heavy-checkout | ||||||||
| Merge into: | lp:bzr | ||||||||
| Diff against target: |
336 lines (+139/-23) 8 files modified
NEWS (+3/-3) bzrlib/builtins.py (+0/-5) bzrlib/recordcounter.py (+65/-0) bzrlib/remote.py (+2/-1) bzrlib/repofmt/groupcompress_repo.py (+23/-4) bzrlib/repository.py (+6/-4) bzrlib/smart/repository.py (+40/-4) bzrlib/tests/blackbox/test_checkout.py (+0/-2) |
||||||||
| To merge this branch: | bzr merge lp:~parthm/bzr/538868-message-for-heavy-checkout | ||||||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel | 2010-05-12 | Resubmit on 2010-05-12 | |
| Martin Pool | 2nd review | 2010-05-04 | Needs Information on 2010-05-12 |
| Vincent Ladeuil | Approve on 2010-05-04 | ||
| Gary van der Merwe | 2010-04-30 | Approve on 2010-05-04 | |
|
Review via email:
|
|||
This proposal has been superseded by a proposal from 2010-05-14.
Commit Message
(parthm) heavyweight checkout now indicates that history is being copied.
Description of the Change
=== Fixes Bug #538868 ===
For heavyweight checkout show a message showing that history is being copied and it may take some time.
Sample output:
[tmp]% ~/src/bzr.
Copying history to "foobar". This may take some time.
bzr: interrupted
[tmp]% ~/src/bzr.
Copying history to "trunk". This may take some time.
bzr: interrupted
The only ugliness I see is in the off case that to_location already exists. In this case the output is:
[tmp]% ~/src/bzr.
Copying history to "trunk". This may take some time.
bzr: ERROR: File exists: u'/home/
It would be ideal if the "copying history" message is not shown. I suppose thats not too bad though. I had a early failure fix for this but haven't put it in considering that bzr works across multiple transports.
+ # Fail early if to_location/.bzr exists. We don't want to
+ # give a message "Copying history ..." and then fail
+ # saying to_location/.bzr exists.
+ to_loc_bzr = osutils.
+ if osutils.
+ raise errors.
+
| Martin Pool (mbp) wrote : | # |
| Vincent Ladeuil (vila) wrote : | # |
Apart from the message tweaks mentioned on IRC, that's good to land !
| Robert Collins (lifeless) wrote : | # |
I realise this has gone through, so I'd like to just request some more
stuff if you have time; if not please file a bug.
The message will show up when doing a heavy checking in a repository;
that's just annoying - no history is being copied, so no message
should appear. Recommended fix: move the notification into the core,
out of builtins.py.
Secondly, if its worth telling people we're copying [a lot] of history
for checkout, I think its worth telling them about it for branch and
merge too. Perhaps lets set some sort of heuristic (e.g. 100 or more
revisions) and have the warning trigger on that?
-Rob
| Martin Pool (mbp) wrote : | # |
On 6 May 2010 04:28, Robert Collins <email address hidden> wrote:
> I realise this has gone through, so I'd like to just request some more
> stuff if you have time; if not please file a bug.
>
> The message will show up when doing a heavy checking in a repository;
> that's just annoying - no history is being copied, so no message
> should appear. Recommended fix: move the notification into the core,
> out of builtins.py.
+1
perhaps just showing it from fetch would be best
> Secondly, if its worth telling people we're copying [a lot] of history
> for checkout, I think its worth telling them about it for branch and
> merge too. Perhaps lets set some sort of heuristic (e.g. 100 or more
> revisions) and have the warning trigger on that?
-½ on that, because it will create questions about "but it worked
before, what changed?" If we want that kind of approach we should
make sure there's a clear progress bar message, so that it's visible
only while the slow operation is taking place.
--
Martin <http://
| Parth Malwankar (parthm) wrote : | # |
On Thu, May 6, 2010 at 8:58 AM, Robert Collins
<email address hidden> wrote:
> I realise this has gone through, so I'd like to just request some more
> stuff if you have time; if not please file a bug.
>
> The message will show up when doing a heavy checking in a repository;
> that's just annoying - no history is being copied, so no message
> should appear. Recommended fix: move the notification into the core,
> out of builtins.py.
>
> Secondly, if its worth telling people we're copying [a lot] of history
> for checkout, I think its worth telling them about it for branch and
> merge too. Perhaps lets set some sort of heuristic (e.g. 100 or more
> revisions) and have the warning trigger on that?
>
Good points. Thanks for the review.
As discussed on the IRC I will work on fixing this.
I don't have a good solution yet. Will propose something taking into
account Martin Pool recommendation.
| Parth Malwankar (parthm) wrote : | # |
So I updated this patch to skip the message when checkout is done in a shared repo. However, there is an interesting case below.
[tmp]% bzr init-repo foo
Shared repository with trees (format: 2a)
Location:
shared repository: foo
[tmp]% cd foo
[foo]% /home/parthm/
[foo]%
In this case, the entire history is copied so it does take time. I am wondering if we should just stick to the simpler earlier patch. Alternatively, if there is a way to know how many changes need to be pulled we could show the message based on this.
This is still checkout specific and doesn't touch other operations.
| Robert Collins (lifeless) wrote : | # |
Well the main point for me is that the issue - lots of history being
copied - is separate from the commands. So I guess I'm really saying
'do it more broadly please'.
-Rob
| Martin Pool (mbp) wrote : | # |
test
| John A Meinel (jameinel) wrote : | # |
23 pb = ui.ui_factory.
24 + key_count = len(search.
25 try:
^- We've discussed that this is a fairly unfortunate regression, as it requires polling the remote server for the list of revisions rather than just having it stream them out.
I'm pretty sure Parth is already looking at how to fix this.
| Parth Malwankar (parthm) wrote : | # |
With a lot of help from John, this patch is is a good enough shape for review.
Its evolved from a fix for bug #538868 to a fix for bug #374740
The intent is to show users an _estimate_ of the amount of work pending in branch/
E.g.
[tmp]% ~/src/bzr.
- Fetching revisions:Inserting stream:Estimate 106429/320381
As the number of records are proportional to the number of revisions to be fetched, for remote operations, this count is not known and the progress bar starts with "Estimating.. X" where X goes from 0 to revs-to-fetch, following this the progress bar changes to whats shown above. For the local ops, we know the count upfront so the progress starts at 0/N.
A RecordCounter object has been added to maintain current, max, key_count and to encapsulate the estimation algorithm. An instance of this is added to StreamSource which is then used among the various sub-streams to show progress. The wrap_and_count generator wraps existing sub-streams with the progress bar printer.
| Parth Malwankar (parthm) wrote : | # |
Just to add. This progress is seen during the "Inserting stream" phase with is the big time consumer. There is still room for improvement with "Getting stream" and "Inserting missing keys" phase but that can probably be a separate bug.
- 5226. By Parth Malwankar on 2010-05-19
-
close review comments from jam.
News entry clarifies this change is 2a only.
Fixed copyright and style in recordcounter. - 5227. By Parth Malwankar on 2010-05-19
-
merged in changes from trunk
- 5228. By Parth Malwankar on 2010-05-19
-
added comments on choice of STEP value and estimate multiplies
based on review comments from vila.

Thanks, this is a very nice bug to fix.
I would prefer the message came out through trace or the ui factory
than directly to self.outf, because that will make it easier to
refactor out of the cmd implementation, and it's more likely to
automatically respect --quiet. You might then be able to test more
cleanly through TestUIFactory.