problems contributing to Flexisearch, Front Page, and Worldpay

Which modules are you referring to?

What is your cvs account name?

sorry dub, i thought i was more helpful in IRC than it seems i actually was. ;) i didn't really mean "RTFM" in the usual sense, i was just in a hurry and was joking. sorry if it came across like i really meant it.

anyway, as i thought i made clear, the problem is that you either do not have a record in the cvs_accounts table in the DB, or the record for your cvs account is not pointing to your correct drupal.org user id (8625). i said this could be caused by your cvs account pre-dating the cvs.module that integrates all this stuff. to confirm this, we looked and saw that the "CVS" tab in your profile edit page doesn't have a cvs account name. i also just noticed you don't have a "track code" subtab from the track tab in your profile, either.

other than not having a "track code" tab, this situation never used to matter. however, now that the cvs access checking stuff is depending on the cvs_accounts table to enforce things, it matters. the solution is for someone w/ DB access on drupal.org to repair or create the row in the cvs_accounts table for you.

hope this clarifies.

sorry for the miscommunication,
-derek

* The following CVS accounts do not have a user ID associated with them.
o fabio
o cnb
o freedom
o maxdanno
o davidmaurer

There have been 31972 commits.

* warning 157 rows in the {cvs_messages}-table have no user ID associated with them.
* warning 862 rows in the {cvs_files}-table have no user ID associated with them.
* warning 15788 rows in the {cvs_files}-table have no project associated with them.

This is the output of the cvs status page. Seems like there should be an entry for dub.

killes, that output is showing you the incorrect entries in the cvs_accounts table. my point is that dub probably isn't in the table at all. if you query for rows in the table matching the cvs account names he gave, i'd bet $20 there's no record at all. he just needs to be added to the table.

we should really compare the CVSROOT/passwd file for the contrib repository with what's in the cvs_accounts table. that'll catch any remaining problems like this.

heh. killes and i looked into this.

dublind, meet your alter-ego:
http://drupal.org/user/8830

so, you created 2 drupal.org users, applied for cvs access via 1, and are now using the other. hence the trouble.

if you asked nicely, killes might be willing to change the entry in cvs_accounts for you to tie your existing cvs account to your active d.o userid.

the problem is that the jason-m3m account is the one with the cvs access. the dublin drupaler account is the one that owns your projects. i'm not sure what "linking the accounts" really means. maybe you mean all traces of the jason-m3m one should have the uid switched to point to the dublin drupaler one, and then the jason-m3m should be destroyed, etc. i don't know if that's possible, or if they do that kind of thing.

in terms of CVS access (the thing i know something about), you either need to move those projects to the account with the cvs account, or move the cvs account to the user that owns the projects. probably the later is easier. i'll get killes to look at this and see what he thinks.

just to clarify, the cvs access stuff basically does this:

1) cvs tells a script "cvs user xxx wants to commit to file yyy"
2) this script looks up the drupal.org userid that corresponds to cvs user xxx let's call it "uid")
3) script looks up the drupal.org project nodeid that file yyy belongs to (let's call it "nid")
4) script looks at the owner of nid... if that matches the uid from step #2, it's allowed
5) script looks in a new table (all the people added via the cvs access tab) to see if there's an entry that ties the uid from step #2 to the nid from step #3.

since the uids that a) have the cvs account and b) own the projects don't match, this stuff can't work for you.

does that make sense?

Dub, you should simply tell me if you want me to assign the cvs account to the drupal.org account you currently use or not.

Should be fixed now, please check and close.

The new system sounds great and all....but, I'm not so sure if it covers all bases...how does that work with modules that relies on contributed modules, such as the ecommerce suite?

when people try to do things in /modules/ecommerce/contrib/foo, the scripts will first look for a project node that points to /modules/ecommerce/contrib/foo, then /modules/ecommerce/contrib, and finally in /modules/ecommerce. so, if you want different access for a contrib module than its "parent", you just make a new project pointing to the subdirectory, and you can assign whatever access you want to the subproject, which will be independent of the access for the parent project.

I haven't changed the way I contribute for almost 2 years..and while your explanation makes sense..I'm slightly at a loss to why existing contributers to a module weren't already added to the CVS ACCESS tab when the changeover happened.

because:

1. the new policy (clearly documented) is that only project owners get access unless they specifically grant it to someone else they trust. that's the feature. that's by design.
2. i wasn't going to do a bunch of manual effort to try to figure out for each contrib project who should be granted access (the "existing contributers"). that's up to the owner of each project. how am i supposed to know which of the people who've ever made commits should be considered current, valid contributers? why should i spend hours and hours doing guess work, when the process can (and should) be done (much better) in parallel by each project owner?

your problems are a special case since you created 2 drupal accounts and mixed up which one had the cvs access with the one you regularly use. if you kept those 2 accounts straight, it all would have worked as soon as we switched over to the new system, since project owners automatically get access to their own projects.

I'm also completely at a loss to why it's so difficult to sort out.

i don't think it's that difficult. ;) from the first time you reported the problem in IRC, i guessed the underlying problem, and tried to explain it to you then. this is roughly attempt #4 of me explaining how all this works so you can see why the situation you were in was causing problems. i didn't write the handbook pages for people with broken cvs_accounts entries in mind. i should probably add a FAQ subpage or something. :)

i'm not trying to be a pain, and i still feel bad that you took "RTFM" so seriously. however, you're coming across fairly confrontational about all this, and killes and i have poured a lot of energy into making this change (and both of us have gone out of our way to help you out here). bumps and all, this is a vast improvement over the old anything-goes-wild-west of the contributions repository. i don't want to generate any hard feelings. please just show a little more compassion for your fellow drupal developers. :)

thanks,
-derek

geeze, this is just going from sad to worse. :( i *really* don't want to generate so much heat about this. i actually took so much time in my last reply to try to answer all your questions, not to assign blame. i was just pointing out *why* you ran into these problems: because your usage was a special case that i didn't anticipate. once again, i'm sorry this communication is going horribly wrong. not my intention. i'm just trying to be as clear as possible so we all understand the problem and solution. i certainly don't want to leave any bad feelings in the air. probably i was reading more into your message than you meant, which is why i said you were "coming across fairly confrontational...". anyway, i hope we can work together in the future without holding any grudges.

thanks,
-derek

I am reposting this and changing the status to patch to get it to appear on the mailing list...

I have been trying to publish the staticHTML module to Drupal.org for over a week. So far nothing has happened and all problems remain. I have tried everything avalable in the handbooks without result. Here's a list

• TortoiseCVS has uploaded to the drupal-contrib directory but cannot branch the files and directories the error.
  

  In x:\wamp\www\clean_466\modules\staticHTML: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "tag" "-c" "-b" "DRUPAL-4-6-0 modules/staticHTML" "."
  
  CVSROOT=:pserver:username@cvs.drupal.org:/cvs/drupal-contrib

  cvs [tag aborted]: tag 'DRUPAL-4-6-0 modules/staticHTML' has non-visible graphic characters

  Error, CVS operation failed

• Project page does not appear in "My Projects"
• Project page created but not found ( under projects/staticHTML )

I'll one or two weeks more to see if this is a fixable situation otherwise I will have to give up and continue to make it available offsite.

Thanks for any help.

Hiveminds Magazine: the tag you're trying to use, "DRUPAL-4-6-0", is not valid. you want to use "DRUPAL-4-6". see http://drupal.org/node/1002 for more info.

since this issue was so specific to the troubles i caused dub *grin*, i'm changing the title so it's clear it's a special case. hiveminds, if you're still having trouble, please just file a new issue.

thanks everyone,
-derek