Multiple releases nodes with the same name

It shouldn't be possible to create two releases with the same name. See also: #715574: Pointing a 6.x-1.x-dev release at HEAD

The project release to delete should be the one created from HEAD.

I deleted the project release created from HEAD. In less than 12 hours, the packaging script should create the archive for the development snapshot.

This is not fixed. The fact that it was possible to create the release in the first place is a bug.

This happened to drush 6.x-3.0-alpha1 as well #695898: Why do we have 2 releases of drush 6.x-3.0-alpha1?.

@webernet: The report created by tlattimore was a task for removing one of the project releases; that is why I marked this report as fixed.

Another case of this: #790754: Can't change my module's version number

And another: #850110: Delete release node or point HEAD to new version for FBconnect module

Argh. This is extremely frustrating. I just tried to reproduce this on scratch.d.o and in both possible cases, I was prevented by validation errors.

A) You already have a 6.x-1.x-dev release from HEAD, you create a new DRUPAL-6--1 branch, and you try to add a release node directly for DRUPAL-6--1:

B) You already have a 6.x-1.x-dev release from DRUPAL-6--1, and you try to add a new release from HEAD that's also called 6.x-1.x-dev:

WTF? ;) I don't understand how these people are bypassing this validation.

Given the impending Git migration and the fact that all this code is going to have to be re-written for #850142: Integrate VCAPI with project_release node add form, I'm inclined not to spend much time on this and instead make sure we have automated tests to ensure it works in all these edge cases over at #850142.

#893936: how to move HEAD from a 6.x-2.x to a 7.x-1.x

I ran into the same problem with my Blogger Importer module: first dev release (http://drupal.org/node/909270) points to HEAD, 2nd (correct one, http://drupal.org/node/904686) points to a branch -- how do I delete the first one?

Thank you

Also I just realized, it's not properly tracking the branch -- changes I committed to the branch 3 days ago aren't reflected in the dev release shown on the module page.

I'm having the same problem. I was able to create a release pointing to HEAD for Comment OG when I already had a release pointing to the 6.x branch, which means there are now two 6.x-1.x-dev releases. Also, the HEAD release is months behind on the branch, as you can see by comparing dates on both releases.

This is now causing grief for the Git migration. See #1019692: Migrate release node VCS data

In there, I wrote:

I notice that lots of these duplicates are basically sequential nids. So either someone effectively pressed "submit" twice or there was a weird data replication bug in the d.o DB cluster. I was thinking that maybe the check for existing releases was buggy and including a {node}.status constraint, but I just triple checked and it's not. This is really pissing me off. In a few of the linked issues, the user doesn't report doing anything weird or pressing submit twice or anything, so at this point, I'm inclined to believe this is a d.o replication bug, not anything broken in project_release.module or cvs.module. :/

Yeah, I'm utterly at a loss to explain how this is happening just by looking at the project_release.module and cvs.module code related to creating release nodes. I hate to do this, but I'm going to wave my hands and start blaming the d.o DB replication system. That's probably wrong, too, but I don't know what else to say. If someone else wants to look at the relevant code, I'd be happy to give someone a guided tour...

Actually, upon even closer inspection, this is a cvs.module vs. project_release.module bug, after all. There's something fishy going on where project_release.module doesn't do its usual version number validation when cvs.module is altering the node form, and yet the cvs.module validation isn't actually happening on the final submission of the node form, only on the intermediate steps (it turns the node form into a multi-page form). So, I was unable to replicate this in testing since I wasn't trying to test the case of preparing the release node form twice in two separate tabs and submitting both simultaneously... Now that I tried that, I reproduced locally. Argh. Sorry for all the hassle this has caused!

Moving this back to a project_release bug. The cleanup will happen either at #1019692: Migrate release node VCS data or at individual issues where they already exist.

While I was offline today, I tore all the validation logic apart. Lots of different aspects of it were broken. Here are patches for project_release, cvs.module, and versioncontrol_release. I've tested this heavily with both the cvs (including regular tags, branches, and the dreaded HEAD workflow), and vc_release, and everything works to prevent duplicates. The one case that's slightly less than ideal is in cvs.module, if you have a HEAD release called 6.x-2.x-dev, and you create a DRUPAL-6--2 branch, that branch is available on the first page where you select the version, and when you do, it lets you get to the 2nd page where you can type in the release nodes, and only when you try to save or preview that do you get the validation error. I don't think I care, since a) cvs.module is almost dead, b) this is a fairly obscure case, and c) it does eventually prevent you from doing harm, you just might have wasted some time first.

Anyway, anyone planning to review any of this? I suppose I should deploy it on beta.d.o or something so folks can try it there (although I don't think we have a dummy scratch CVS repo there for people to make new tags with. If someone wants to test there, let me know a project you own and I can delete some existing releases so you'll be able to try making duplicate new ones or something.

Also, since this is making things suck over at #1019692: Migrate release node VCS data and since this is follow-up work to really finish off #850142: Integrate VCAPI with project_release node add form I'm tagging this issue for the git migration and sprint #8 (currently in progress).

@dww - that's wild, woolly and awesome that the logic's been improved. and you're right, i don't have the brainspace to be able to review it now. so excellent, glad we've got it, and i'm happy to just have you put it into vc_release and if we have problems, deal with it then :)

@sdboyer: Yeah, I didn't expect you to review this. ;) However, this isn't as simple as "put it in vc_release and if we have prorblems, we deal with them later" because this is also fixing project_release and cvs module for immediate deployment to prevent more duplicate data from getting in and breaking the work at #1019692: Migrate release node VCS data. I'm basically okay just deploying now given my own testing, but it'd be nice to have some independent verification if possible.

I've tested the cvslog and project_release portions of this patch locally, with the following scenarios, and found the two patches together to prevent duplicate releases in the all cases. In the case of duplicate releases pointing to the same tag or branch, I'm using two browser tabs to complete the steps of the release form simultaneously.

1) Duplicate releases pointing to HEAD are prevented.

2) Duplicate releases pointing to a tag (Drupal-6--1-0) are prevented.

3) Duplicate releases pointing to a branch (DRUPAL-6--1) are prevented.

4) Attempting to create a dev snapshot from a branch (DRUPAL-6--1, 6.x-1.x-dev) when an 6.x-1.x-dev release pointing at HEAD already exists, is prevented.

5) Reverse of 4, creating a new snapshot from HEAD when the same version pointing at a branch already exists.

I'll post back again when I get vc_release tested, but I figured you'd want to get his out as soon as possible.

Committed the patches in #19 to HEAD of all 3 projects, merged into bzr, and deployed live on d.o. So far, so good. I'm hoping to hear from some folks in IRC when they're planning to make releases and try to get some more testing of this now that it's live. Worst case, I'll test it myself the next time I'm making a release of something.