Contributing a Module with TortoiseCVS
This article is largely taken from http://drupal.org/node/112902. The following is essentially a walk-through focusing on the actual process involved when submitting modules to Drupal.org using TortoiseCVS. This is by no means a detailed CVS guide and I am not a CVS expert.
It is highly recommended that you read the detailed CVS instructions in the Drupal Handbook at some point. This guide is for Windows users and a CVS client is used, so you don't have to use command-line. There are decent instructions already available for Linux users. There is also a video available to help you out.
I also recommend that you familiarize yourself with the Drupal coding standards. I then suggest you download and install the Coder module for checking your application of the standards. [I now consider a Coder review a necessary step before committing changes.] Then it's always nice to at least lay the groundwork for translation of your module, so check out the Translation Template Extractor module. There will be more on this later.
The assumption is that a stable release will be submitted, meaning that the module has been tested thoroughly (preferably by others), the PHP code has been checked for security vulnerabilities, the CSS has been validated etc, and the module is ready to share with the Drupal community. Also make sure you have decided on the directory structure for your module. Renaming files in CVS is hard, and moving around directories is really hard (without the help of the extremely busy CVS admins). If you have your directories structured and files named how you want them before your first CVS commit, you will save yourself (and those busy admins) a ton of grief.
Adding a module to Drupal CVS
- First you will need to apply for a CVS account with Drupal.org and CVS service not blocking by your firewall (CVS port number is 2401).
- After you have installed TortoiseCVS, browse to the folder that contains all of the files for your module. The commands for TortoiseCVS are accessed via the context menu when you right-click on a folder.
Right-click the folder for your module. Select CVS > Make New Module. Make sure that Password server (:pserver:) is selected for Protocol:. For CVSROOT: copy and paste or type the following line, replacing "username" with your username for your CVS account with Drupal (note: username is case-sensitive).- For the Module: field, copy and paste or type in the following line replacing "modulename" with the name of your module. This should match the name of the folder which contains your module files:
- Time to add the files. Right-click on the module folder again and select CVS Add Contents. All of the files in your module folder will be selected automatically. Press OK.
- Now the files have to be committed. Open the folder for your module. You will see orange plus signs on all of the files indicating that they have been added. Select these files, right-click and choose CVS Commit. In the Comment field, add something like "Initial Release for Drupal 5.0" and press OK. If your module folder contains sub-folders i.e. "/images" etc. you may need to repeat this procedure for all of the files in each sub-folder since the commit command is not always recursive.
- It is now time to add your project on Drupal.org. Login to your account. Click on Create content > Project. Most of the fields on the Submit project form should be self-explanatory. The Short project name should match the name of the folder that contains your module files. For CVS tree, use the following URL and replace "modulename" with the short project name you entered earlier:
- You now need to return to CVS to create a CVS tag for the specific version of the module you are releasing. This helps to keep track of different releases. Since this is the initial stable release you will start with 1.0. Use one of the following tags below depending on the version of Drupal:
DRUPAL-6--1-0
DRUPAL-5--1-0
DRUPAL-4-7--1-0 - Now to add the release that was uploaded to CVS earlier. This is an easy step to forget, but don't or you will have wasted all your time. Click the Add new release link for your project - the one on the project page (the "create content » release" doesn't do it). Select the appropriate CVS identifier. The next screen is fairly self-explanatory. Click Submit.
:pserver:username@cvs.drupal.org:/cvs/drupal-contrib
contributions/modules/modulenamePress OK. TortoiseCVS will do its thing and should report that the operation was successful. This has created a directory in Drupal CVS to contain the files for your module. You can verify that the directory was created by visiting the Index of contributions.
When this is complete, the module has been registered on Drupal CVS.
Creating a project for your module on Drupal.org
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/modulenameAfter everything applicable has been filled in, click Submit. Don't worry, you can come back and fill in missing details later.

That's it! Whew! Now your module is officially managed through Drupal CVS and included as a project on Drupal.org. If you want to add a screenshot, first read the Theme screenshot guidelines. You will need to Submit an issue with the Drupal.org webmasters in order to have your screenshot added.
So there you have it. Ten "easy" steps to add your module to Drupal. Perhaps not that easy, but it is to be expected that there will be some tedious procedures to deal with in order to keep the quality of contributions high while maintaining a community effort like Drupal. Hopefully this has been informative and will save some time and headache for people who aren't familiar with CVS but would like to contribute a Drupal module. Again, it is recommended that you read through the Drupal handbook so that you have a more complete understanding of CVS; here is a good place to start.

Needs a little edit
Great page but it needs a bit of a rearrangement according to the Module Maintainer guide Create a CVS project that states:
So we need to move the branching and tagging after the node creation part. I'm leaving this as a comment so others will know this when they go through this. I'll try to make the edits within the next day or so and then remove this comment when done.
Hmm...
Are you sure that is correct any more? I've added 6 modules following this process and not had any problems.
I have seen some changes that seem to have been made since the original source of this post, which would also need this change.
I'll be happy to move that part if we know it is still correct to do so.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
May be a problem
I followed these instructions exactly and I was unable to create a release. After re-tagging it worked fine, but I'd recommend creating the project page first, just in case.
I understand
The powers-that-be changed this page without consulting with me and deliberately took a major necessary step out. For those who read this, I can tell you it no longer works - you must create a branch before you create a tag.
No branch needed
No you don't need to make a branch to tag. You can tag directly from HEAD and if you only have one version of your module when you start (e.g. only Drupal 6) then this is the simplest thing to do and you can wait to branch until you make a new version. Using HEAD (and not a branch) for the code that is currently compatible with the latest version of Drupal is definitely one of the primary ways to use HEAD and by most "CVS gurus" is considered best practice.
The CVS docs are on deck for a major reorg/rewrite in the next few weeks so hopefully we can make all of this information clearer and presented in a flow that is much less confusing for everyone.
Lullabot loves you | Be a Ninja, join the Drupal Dojo
And...
For those of us who are maintaining both a 5.x version and a 6.x version, not creating a branch causes unpredictable code mixing. I tried to create a new module with the instructions as they exist now, and both versions got clobbered. The only thing that fixed it was creating branches for both versions.
For non-CVS gurus...
What is the right syntax for creating tag off HEAD?
I followed the instructions for creating a branch, which is part of the next slide, and then I could create a TAG with no problems. But Nancy is right, using the instructions given here, you need to create a branch for release x.y before you can create tag x.y.z. Don't quite understand why you want a tag with no associated major Drupal version, anyway. Since modules must be major version-specific.
Also there are filters that are very persinikity about syntax, tags have the form DRUPAL-v--r-p with two hyphens between version and revision. Probably a reason for that too that I don't understand...
Remember to open CVS Port
I can not create new module, and i found that since we use pserver (Password Server) for CVS's protocol then we need to open port 2401.
Check your firewall setting.
My problems with the article
I followed this for my first module (Type user nids) which is currently only a Drupal 6 module. I had no problems in doing everything within the Head or trunk of the tree. This makes sense to me in that when I do have to make a DRUPAL-6--1 branch, that is, when I start making a Drupal 7 version, both the branched Drupal 6 version and the Drupal 7 version continued in the Trunk will have a consistent history through the branch or trunk back to the base of the trunk. This would not be the case had I made a Drupal 6 branch while still continuing to work on only the Drupal 6 version.
The problems I have with the article stem from its stated assumption as follows:
"The assumption is that a stable release will be submitted, meaning that the module has been tested thoroughly"
In my case this was close to being true. Its a small module, I had well tested it and I had placed it on a website and invited other people to test it. Regardless of this, I would still have preferred to have gone through some Apha, Beta or Release Candidate phase. By following the above instructions, I found I had no opportunity to do this. Where I was expected to do this I could not change the release version. Not having actually done it, I'm still not sure how to create a -dev version.
I believe the above assumption is a bad assumption to base the article on, regardless of it being well stated in the article. It would be better to start with the opposite assumption as that is what's more likely the beginning state, where readers are likely to want this article.
The other problem I had with this article was finding the article. All the links from the email telling me that I had gained a CVS account were to articles that assumed the user was on Unix and most of the links within Drupal on CVS had the same assumption. I had to do a lot of searching with Google to find it.
HEAD
I'm guessing that the real problem is that you didn't branch 7 off of HEAD. This is a problem I have made many times.
NancyDru
Help for the impatient & CVS Maintainers
Can steps 3 and 4 be combined into a single step, with a sub-list for all steps that need to be completed here?
It may help impatient readers, (aka Me), from hitting submit before completing the last field in the form. Missing this step will publish directly into "/cvs/drupal-contrib" which is getting messy cause of users like me :(
Well...
I guess you could file a feature request against Tortoise.
NancyDru
I was meaning the documentation!
Hi Nancy
I was meaning that if the doco was changed to this:
--------------------------------------------------------------------
Step 3: Right-click the folder for your module. Select CVS > Make New Module.
:pserver:username@cvs.drupal.org:/cvs/drupal-contribcontributions/modules/modulenameTortoiseCVS will do its thing and should report that the operation was successful. This has created a directory in Drupal CVS to contain the files for your module. You can verify that the directory was created by visiting the Index of contributions.
--------------------------------------------------------------------
It may help users like me submitting the form before setting the final form field.