cannot delete a branch

[Jamie Wilkinson]

In the libcmml project I mistakenly added a branch pointing to the upstream subversion url; I added the release series and did it correctly but now I want to remove the branch pointing to the same location because it's not a bazaar branch.

There is no "delete" link anywhere in the edit branch page.

[David Allouche (ddaa)]

Yes. You cannot delete branches.

Long story short, it would be problematic in the general case, but there's definitely a need to fix mistakes. Related to bug 29998.

Your best option in the short term is to reuse the branch for something else: ask an admin to change its name. and product, then change the URL and description. You should not have to ask an admin, related to bug 37476.

[David Allouche (ddaa)]

When we fix this bug, we should remember to add an administrative UI to allow undeleting branches which have not been garbage-collected yet.

[Jonathan Lange (jml)]

David, could you please explain what's problematic about the general case?

[David Allouche (ddaa)]

I mean general case as in "delete a branch, from the web ui, even if it referenced from other places".

If we provide a deletion UI, but database constraints prevent us from deleting a branch, we need to be able to diagnose the reason and at least explain it to the user. And maybe just delete the branch and the references. For example, branch links from bugs, specs, release series, subscriptions, etc.

If the web UI does not immediately deletes the database entry, but just marks the branch as "to-delete" (which is preferrable because it allows undeletion) we need to implement filtering for deleted branches in every part of Launchpad that deals with branch. Which is difficult.

Finally, we should support garbage collection of branch-related filesystem data, including the branch mirror, the sftp area (for hosted branch), the loggerhead caches, etc. One way to approach the problem is to delete any filesystem data that is not associated to a database object, but that opens several race condition for non-web systems that operate on this filesystem data. Those race conditions do not seem serious, but would produce spurious error reports and should be avoided.

Another approach to garbage collection, with the to-delete flag, would be adding a "garbage-collected" status (no, in-progress, done), and only allow deletion of the database object when the garbage collection is complete.

So, it's complicated.

On the upside, I taught Tom how to delete branches, so he will manually handle administrative requests to delete branches.

[Tim Penhey (thumper)]

I think we should add the ability for a user to delete a branch as long as it hasn't been pushed to, or subscribed by anyone other than the user themselves.

This is really a non-branch, as there will be nothing on the code hosting filesystem that needs to be cleaned up, and the removal of the branch from the database will be sufficient to clean it up.

Deleting existing code however is more problematic.

I'd suggest a lifecycle_status of "Delete pending". It would automatically be handled by all the current filtering mechanisms.

Any attempt to push to a delete pending branch will fail. Mirroring is not attempted for a delete pending branch.

The removal process could then start at the code hosting filesystem, then the intermediate locations (sftp area), and finally out of the database itself.

We wouldn't then need difficult garbage-collected statuses.

[Andrew Bennetts (spiv)]

I think Tim makes a good suggestion: if none of the problematic cases David highlights exist, then we should just delete the branch.

If the branch has data, or bug associations or anything like that, we can just say "sorry, this branch is used; please talk to an admin." It's not great, but it's a reasonable compromise that deals with many cases when people want to delete branches. And it's an incremental step towards a general solution, if that's what we decide to do.

[Martin Pool (mbp)]

Can't we just mark the branch hidden, and so not visible in the web interface or supermirror? Is that hard?

[Tim Penhey (thumper)]

On Tuesday 26 June 2007 21:53:47 Martin Pool wrote:
> Can't we just mark the branch hidden, and so not visible in the web
> interface or supermirror? Is that hard?
>

Yes, but the question really is how to mark the branch as hidden.

My suggestion is to use the lifecycle status.

[Jonathan Lange (jml)]

... in which case it can be unhidden by an admin?

+1.

I think introducing this will diminish the value of the 'Abandoned' status, but that we can think more about that once we get some usage data.

[Tim Penhey (thumper)]

What I'd like to see is a last_modified_date added to the branch table.

Once a branch has been set to delete_pending lifecycle status it is removed after a defined period (30 days?).

This allows time for the status to be reverted, or a subscriber to branch from the branch to be deleted prior to it being removed.

If this is what we want, then we'd have to continue to make the branch available to read from, but not push to. If they want to push to it then they have to change the lifecycle status to something other than delete_pending.

[David Allouche (ddaa)]

I overdesigned it.

If we assume that branch ids never wrap around, we can make it much simpler:

 * Just delete the Branch database record in simple cases (when there is other Launchpad object attached to the branch).
 * Clean up filesystem data that is not associated to any branch in the database.
 * When the Branch is associated to other Launchpad objects, "merge" it in the way we can currently merge Persons. See https://blueprints.launchpad.net/launchpad-bazaar/+spec/branch-merge for rationale.

I do not have strong opinions on the process surrounding branch deletion. My gut feeling is that we should not overload last_modified_date as suggested by Tim, but instead of a dedicated timestamp, maybe date_pending_delete. But I will no push this point, as it is only a gut feeling.

[Tim Penhey (thumper)]

Fixed in RF 4715.