bzr remove-branch in lightweight checkout removes the branch, which may be surprising

[Larry Osolkowski]

If a lightweight checkout of a remote branch is done, and a --remove--branch is done on the checkout location, the source branch is removed.

[Larry Osolkowski (losolkowski)]

That should be bzr remove-branch.

[Martin Pool (mbp)]

That seems like the correct behaviour, though I can see why you find
it surprising. What would you have liked to have happen?

[Larry Osolkowski (losolkowski)]

As a new user of Bazaar, I would have expected a message that there is no branch there. If not for the fact that I had a mirror branch in another folder, I would have lost the complete source branch. We did later determine that we could recover it from the dead head in the shared repository, but the tags are not recovered using this approach, so some critical information could still be lost. In general, I think it should be made difficult to accidentally remove a branch, or at least make this side effect more apparent in the documentation. Thanks for your quick response.

[Larry Osolkowski (losolkowski)]

To follow up - my expectation, which was incorrect, was that a lightweight checkout would just provide a copy of the working tree; i.e., the files, and nothing else. Most other version control systems that I've used have a simple and obvious mechanism for getting a copy of the current files for a project/branch for review or whatever. I thought that was what I was doing. When I was done with the files, I tried doing a remove-tree, but was told that there was no branch. For some reason which now escapes me, I then tried a remove-branch, and the source branch was removed. Since there was no local branch, I didn't expect it to do anything. After further research, I now understand what a lightweight checkout does, but it took some digging to find this information.

[John A Meinel (jameinel)]

If all you wanted was the content, not linked to anything else, you could
use 'bzr export'. If 'bzr remove-tree' was complaining about no branch, that
probably meaner the branch was already removed, or renamed, etc. Remove tree
doesn't *need* a branch, though the current code structure makes it hard to
write that way.

John
=:->
On Oct 18, 2011 8:00 PM, "Larry Osolkowski" <email address hidden>
wrote:

> To follow up - my expectation, which was incorrect, was that a
> lightweight checkout would just provide a copy of the working tree;
> i.e., the files, and nothing else. Most other version control systems
> that I've used have a simple and obvious mechanism for getting a copy of
> the current files for a project/branch for review or whatever. I thought
> that was what I was doing. When I was done with the files, I tried doing
> a remove-tree, but was told that there was no branch. For some reason
> which now escapes me, I then tried a remove-branch, and the source
> branch was removed. Since there was no local branch, I didn't expect it
> to do anything. After further research, I now understand what a
> lightweight checkout does, but it took some digging to find this
> information.
>
> --
> You received this bug notification because you are a member of bzr-core,
> which is subscribed to Bazaar.
> https://bugs.launchpad.net/bugs/876629
>
> Title:
> Source branch removed
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/bzr/+bug/876629/+subscriptions
>

[Martin Pool (mbp)]

So, what should we do with this?

 * add some documentation suggesting you can use 'export' to get a tree with no metadata (maybe in 'help checkout'? elsewhere?)
 * give a warning or ask for confirmation when you do remove-branch from a lightweight checkout (or even always?)

I'll leave this open asking for those two (though they could be done separately or someone else might have a better idea).

[Larry Osolkowski (losolkowski)]

I'll think about this some more, but your two suggestions are good ones. It might also be helpful to mention in the help for checkout that doing a remove branch will remove the parent. It's probably a good idea to request confirmation whenever the user executes a command that could destroy data, but I don't know how effective the usual "are you sure?" prompts really are; probably better than nothing.

[Martin Pool (mbp)]

One more thing in 2.5b5 and trunk, is that 'bzr remove-branch
COLO_BRANCH_NAME', actually removes the .bzr/branch directory, leaving
you with a broken (but recoverable) setup. It's a bit of a trap
because this completes even if COLO_BRANCH_NAME is the name of a colo
branch and not of a file or directory:

mbp@joy% bzr init --format development-colo /tmp/t1
Created a standalone tree (format: development-colo)
mbp@joy% cd /tmp/t1
mbp@joy% bzr.trunk switch -b 1
mbp@joy% bzr branches
* 1
mbp@joy% bzr switch -b 2
Tree is up to date at revision 0.
Switched to branch: /tmp/t1/
mbp@joy% bzr.trunk remove-branch 1
mbp@joy% bzr branches
  1
  2
mbp@joy% bzr st
bzr: ERROR: Not a branch: "/tmp/t1/.bzr/branch/": location is a repository.

This is a bit like <http://pad.lv/876629> and perhaps the same bug.

  bzr remove-branch NAME

I think the cases we need to support are:

1 - remove a colocated branch (by default from the current repo,
probably no default for the branch name)
2 - remove a .bzr/branch directory

I think we could handle 1 with

  bzr remove-branch [-d DIR] COLO_NAME

and it must be a real named branch.

2- The current code is fine but we should probably have some checks
that the user is pointing to the root of a directory and perhaps to a
directory that contains only a branch (not a tree, not a repository).
And, for consistency with #1 (but breaking the ui a bit), we could
have the location named by -d.

What do you think?
--
Martin

[Alex Rousskov (rousskov)]

I suggest renaming the title of this bug to something like "bzr remove-branch causes heart attacks". I realize that a near-death experience suffered by a developer would still be of "low importance", but perhaps such renaming will help guide the discussion. :-)

In my specific case, while trying to optimize checkouts of Squid branches on my workstation, I deleted the *official* Squid v3.2 branch in the *official* Squid repository on the *official* server. It just should not be that easy!

Here are approximate steps reconstructed from bash history (just to make sure I am commenting on the right bug report):

   # start by an innocent checkout from the official Squid repository:
   bzr co --lightweight bzr+ssh://bzr.squid-cache.org/bzr/squid3/3.2 v3.2
   cd v3.2
   bzr info
   # Nah, this is still not what I need. I think I saw a cleanup command somewhere.
   bzr help commands
   bzr remove-branch --help # Yes, I really read it. Possibly twice!
   cd ..
   bzr remove-branch v3.2
   rm -rf v3.2
   # And here I realize I destroyed the official Squid repository:
   bzr branch bzr+ssh://bzr.squid-cache.org/bzr/squid3/3.2 v3.2
   bzr: ERROR: Not a branch: "bzr+ssh://bzr.squid-cache.org/bzr/squid3/3.2/".
   Millions of Squid developers around the world suddenly cried out in terror.

Yes, Robert Collins was able to promptly recover the deleted official branch (by typing a few magic bzr commands on the official Squid server, I am sure), but not every project is lucky to have Robert.

IMHO, any bzr command that seems to operate on local files and does not involve a "bzr commit" or equivalent (with revision history and, hence, undo) must not lead to removal of anything on a remote server, at least not without some well-documented --force[-total-destruction-everywhere] flag and a "There is no undo unless you can count on Robert" warning.