allow 'bzr checkout' to resume

Bug #125067 reported by Jean Jordaan
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Wishlist
Unassigned

Bug Description

When trying to resume an interrupted checkout, bzr dies with:

bzr: ERROR: Not a branch: /home/jean/repos/bzr/code.launchpad.net/bzr-trunk/.bzr/branch/

Here's some discussion on how to fix it:

<jam-laptop> lifeless: I probably agree, but I would argue it is hard to
             detect the "I want to resume a checkout" from "I'm
             accidentally checking out into a different branch"
<jam-laptop> unless we store what operation is occurring and clean that
             up when it finishes
<lifeless> jam-laptop: i think its fairly easy to tell :).
<jam-laptop> In which case we might as well have a 'bzr resume' command
<lifeless> jam-laptop: threre are three failure points' repo, branch,
           tree
<lifeless> if you have repo, no branch, no tree, its a resuming checkout
           trivially. (any dir that exists will be empty)
<lifeless> if you have repo, branch, no tree then its the same as
           'checkout .' basically - easy to support and detect reliably
<jam-laptop> except for a shared repo at the root
<jam-laptop> which has a repo but no branch
<jam-laptop> and no tree
<jam-laptop> and you don't really want it to have either
<lifeless> why not?
<jam-laptop> Because I typed a command in the wrong directory
<jam-laptop> the point of not overwriting was because we didn't want to
             break what you already had
<lifeless> 'bzr zap-tree'
<lifeless> or add a --force option to checkout and say 'there appears to
           be bzr data here already, you can use --force to create a
           checkout anyway'
<jam-laptop> --force is a decent answer

Revision history for this message
Aaron Bentley (abentley) wrote : Re: [Bug 125067] allow 'bzr checkout' to resume

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jean Jordaan wrote:
> <jam-laptop> the point of not overwriting was because we didn't want to
> break what you already had
> <lifeless> 'bzr zap-tree'

Seems like an obvious extension of "bzr remove-tree".

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGk7dy0F+nu1YWqI0RAhmNAJ48HW28k2SPlWCnDwZkmLTuC6Dh6gCfYlAv
adlionIQy5ZH5DIz4ZiI6OA=
=uafF
-----END PGP SIGNATURE-----

Revision history for this message
James Y Knight (foom) wrote :

Why doesn't bzr branch make the branch dir first, and then pull down revisions into it? Then I could resume it with a simple bzr pull from within.

Revision history for this message
James Y Knight (foom) wrote :

(forgot to say: this would be _quite nice_ to have working, what with bzr-svn branching taking more than 4 hours to run...)

Revision history for this message
John A Meinel (jameinel) wrote :

There is a branch around which does this. It was part of my fixing "bzr push" and "bzr branch" to initialize a branch object so that they could be resumed. The original change got kicked because of Robert's concern of having an empty branch show up during "bzr push".
But the "bzr branch" code is probably still reasonable.

I believe the code is at:
https://code.launchpad.net/~jameinel/bzr/fix-push2

and is associated with bug 45504. (There was another fix that I also wrote for the bug, which I think is fix-push-alt).

Someone could probably clean that up so it just contains the changes to .sprout() (and not to .clone()).

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 125067] Re: allow 'bzr checkout' to resume

On Wed, 2007-08-08 at 15:16 +0000, John A Meinel wrote:
> There is a branch around which does this. It was part of my fixing "bzr push" and "bzr branch" to initialize a branch object so that they could be resumed. The original change got kicked because of Robert's concern of having an empty branch show up during "bzr push".
> But the "bzr branch" code is probably still reasonable.
>
> I believe the code is at:
> https://code.launchpad.net/~jameinel/bzr/fix-push2
>
> and is associated with bug 45504. (There was another fix that I also
> wrote for the bug, which I think is fix-push-alt).
>
> Someone could probably clean that up so it just contains the changes to
> .sprout() (and not to .clone()).

It's worth noting that with packs, fetch is atomic, so your branch won't
help them be resumable.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Revision history for this message
James Y Knight (foom) wrote :

As long as it's fast, it hardly matters. And packs are supposed to make it fast, right?

git-svn is slow to fetch revisions. It'd be nice to be able to restart it without having to manually hack in a branch directory so that I can use 'pull' to complete the operation.

Revision history for this message
John A Meinel (jameinel) wrote :

Well, even the fastest format will still take a while to download 60MB of historical data. (Or if it is something like the Mozilla tree, 2GB).

This may be something we actually want to think about. It is nice to be able to incrementally download information, and not have all of that download be completely wasted if your connection times out.

We could do it in a variety of ways. Such as downloading packs as 100 revisions at a time, or even 1000. Then as long as you have completed 1 chunk, then you are better off than starting from scratch. (You could even update the branch pointer at that time, so it is reasonably valid).

I know there is the basic plan to have pack files that build up over time, and possibly collapse them into larger packs. I think it could be better to have a cap of how many revisions we put between each atomic operation.

Revision history for this message
James Y Knight (foom) wrote :

Well, limiting a pack file to some reasonable number like 100MB seems pretty sane. But other than that, it seems to me that making the downloader able to resume the download if interrupted is clearly the right solution.

Revision history for this message
Robert Collins (lifeless) wrote :

On Thu, 2007-08-09 at 19:04 +0000, James Y Knight wrote:
> Well, limiting a pack file to some reasonable number like 100MB seems
> pretty sane. But other than that, it seems to me that making the
> downloader able to resume the download if interrupted is clearly the
> right solution.

Versioning of .iso's or similar large documents will grow packs to
arbitrary sizes unless we add bittorrent like splitting and recombining
of data into the mix. Further, there are roundtrip costs involved in
accessing separate packs, we really want to keep the total number of
packs managable - I'm currently working on upper pack count = sum of the
digits in the revision count - which gives logarithmic backoff without
rewriting on every commit.

individual packs are currently atomically inserted, and the temporary
file is discarded. If you wanted to design a way to make reuse of such
things (remember we are not blind-copying the remote packs, as we don't
want all the data that they have in the general case (though detecting
when we do want it all and blind copying would be a nice optimisation)
so its not a matter of looking for the same pack name in a special area
or something like that.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Dan Watkins (oddbloke)
Changed in bzr:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Any progress on this? How do i resume svn checkout?

Revision history for this message
Parth Malwankar (parthm) wrote :

There is some discussion about a --step option for pull here:
https://answers.launchpad.net/bzr/+question/106865

Jelmer Vernooij (jelmer)
tags: added: checkout resume
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.