Bazaar

How to delete / remove branch from shared repository?

Asked by Greg

How should I clean out (remove / delete / etc?) a branch from a shared repository?

I had a local repository that become corrupted in some way and I could no longer commit changes. There was a remote repository that still worked fine but if I delete my local branch (the folder in the file system) and try to pull a new local copy, I'd get 'file already exists' error somewhere inside the repository (strange named files obviously inside the .bzr black box).

In the end, I backed up my local working tree, deleted my entire local repository and pulled a new set of branches from the remote location. I'd still like to know if there was a recommended way to delete or remove branches from a shared repository to prevent any conflict occurring.

My file structure was a bit like this:

remote drive
\proj1 (shared repo, no tree)
  \branch1 (plain branch)
  \branch2 (plain branch)

local drive
\proj1 (shared repo)
  \branch1 (plain branch)
  \branch2 (plain branch, bound)

In my case, local proj1\branch2 became corrupted and I could not replace it with remote proj1\branch2

This question may be similar to question #38732 or question #32288 but I'd like clarification. I normally work with Bazaar Explorer and don't use the commands.

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Gordon Tyler
Solved:
Last query:
Last reply:
Revision history for this message
Best Gordon Tyler (doxxx) said : 		#1

Revision data for all branches is stored in the .bzr directory directly inside your shared repo directory. Removing the branch directory merely removes a pointer to a specific set of revisions in the repository that constitute that branch. Pulling the branch into the shared repo again just restores the pointer and would encounter the same corrupted data.

So to answer your question, it's not possible to entirely delete a branch from a shared repository.

Revision history for this message
Greg (gregspecialsource) said : 		#2

Thanks for clarifying that Gordon. Can you think of any work around for my situation?
Recall that I could not Pull a new copy of a branch due to an internal file conflict, even using new and uniquely named folders / repos, as long as the shared repository was present.

Revision history for this message
Gordon Tyler (doxxx) said : 		#3

If the shared repository data is corrupted, then pulling branches into that shared repository is not going to work. The only way to pull new copies of the branches is to create a new shared repository in a different directory and pull your branches into that.

Please file a bug for the errors you were getting, there may be a way to recover the shared repository.

Revision history for this message
John A Meinel (jameinel) said : 		#4

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

Gordon Tyler wrote:
> Question #117689 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/117689
>
> Gordon Tyler posted a new comment:
> If the shared repository data is corrupted, then pulling branches into
> that shared repository is not going to work. The only way to pull new
> copies of the branches is to create a new shared repository in a
> different directory and pull your branches into that.
>
> Please file a bug for the errors you were getting, there may be a way to
> recover the shared repository.
>

There are two ways I've seen this happen:

1) Directories get deleted from the repository. Most likely are:
 .bzr/repository/upload
 .bzr/repository/obsolete_packs

Those directories must exist, and are ones that we never delete. So
something external to bzr is deleting them (if they are missing).

2) You have a stale '.pack' file in .bzr/repository/packs which is not
referenced by '.bzr/repository/pack-names'.

One way to check is:
  bzr dump-btree --raw .bzr/repository-pack-names
and compare the result with the files listed in .bzr/repository/packs.

Anything not referenced can be deleted, though I would recommend
renaming it to a temp location to make sure.

If this is the case, it also should resolve itself. It only results when
you pull the exact same content that you already pulled (though
interrupted). If the upstream data changes (new commits) then the file
content will change, as will its name. Which would thus not conflict
with an existing file.

(1) seems the most likely given what you mentioned. But I don't know
what is randomly deleting empty directories in our repository.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw/BfEACgkQJdeBCYSNAAOa8QCeJbN5UCN46U0R6RQm6byHE48u
ZvsAnjdBHwZp69zGwMianqQRi1gTHtaE
=aFDh
-----END PGP SIGNATURE-----

Revision history for this message
Greg (gregspecialsource) said : 		#5

Thanks Gordon. I had filed bug #602614 relating to this. I could no longer check-in even the smallest change. Failing an attempt to pull a new copy made me suspicious something was wrong in the shared repository.

Revision history for this message
Greg (gregspecialsource) said : 		#6

Thanks Gordon Tyler, that solved my question.