The CVS backend still has a setting in its xcvs-config.php where the admin can specify if tags should be allowed to be deleted or not. (Naturally, this setting affects xcvs-taginfo.php.) That's not the worst of all solutions, however the cleaner and more cross-VCS way of doing this would be if that check was done in the Commit Restrictions module instead of the trigger script.

The single problem with asking Version Control API for permission is that we don't know if the concerned CVS tag is an actual tag or rather a branch (both of which CVS considers to be essentially the same thing). CVS doesn't tell the trigger script, so we need a method to find out what kind of tag the deleted one actually is. When that's done, Version Control API can be asked for permission of "delete tag" operations, and Commit Restrictions can implement a restriction to deny it in certain cases.

Comments

jpetso’s picture

jpetso commented
Project: Version Control API -- CVS backend » Version Control API
Version: 5.x-0.9-rc5 » 5.x-2.x-dev
Component: Code » API module

The CVS backend side of the issue is solved, the CVS backend can now figure out by itself which label type (branch or tag) has been assigned to the files before. Better yet, it can do so without relying on the database, so the method is pretty reliable as well. Now the only thing that needs to be done is to implement the check to Commit Restrictions (as "Allow removal of invalid tags", or similar) and later on hook the release node integration module (to be written) into hook_versioncontrol_write_access() so that it can disallow the removal of release tags.

jpetso’s picture

jpetso commented
Status: Active » Postponed

Postponed until the release node integration exists. An "Allow removal of invalid tags" option would maybe make sense now, but on the other hand who would want to disallow removing invalid tags? Commit Restrictions allows that by default, so that's not pressing or even necessary I think. Before implementing such an option, let's wait until someone specifically requests it.

jpetso’s picture

jpetso commented
Status: Postponed » Closed (fixed)

Actually, I don't want this in the issue queue anymore because
1. the technical foundation is there, it can be implemented anytime
2. no regressions from the current d.o setup are known
3. it's not currently planned to implement this at all.

I think that's good reasons to throw out this issue as "closed".