Additionally, Module Manager now has it’s own home on Google Code so check it out! (pun intended)

Here is an example of the new nested modules feature:

# My template files
skin               skin/frontend/my/default
design             app/design/frontend/my/default

# Import Colin_HotDealz module
@import            modules/Colin_HotDealz

Update 1/30/2010:
Added nested modules, renamed .modman file to modman, released under Apache License 2.0, and hosted on Google Code.

This project was inspired by my recent Magento development work so I’m not sure how much application it has outside of that, but if you’ve ever wanted to use svn:externals with individual files (you can’t btw) then this is the next best thing (and therefore the best thing). Perhaps some other VCS supports this functionality natively , if you know of it please clue me in. I’ve used git and bazaar but still like the simplicity of subversion for small, non-distributed projects.

Magento’s source code is split among several different groups of files: code, design, locale, skin, libs, etc (as in config), etc.. (as in etcetera)
You really cannot avoid ever having to mix a file in here or there which means svn:externals won’t cut it. Besides, svn:externals won’t let you make one commit from all of your externals so to commit your changes you have to do it once for each folder which makes your commit history nearly useless. Enter “modman”, my Magento module manager. While it could be used for deployment it is primarily geared towards developers. Here is how it works:

Create a branch and put your source code in it. Now create a “.modman” file within the root of the branch. In this file you define (much like svn:externals) a path within your repository and the path that it should map to. Here is an example (with a fictitious module named “HotDealz”:

code   app/code/local/Colin/HotDealz
template   app/design/frontend/default/default/template/hotdealz
hotdealz.xml   app/design/frontend/default/default/layout/hotdealz.xml
images   skin/frontend/default/default/images/hotdealz
HotDealz.csv   app/locale/en_US/Colin_HotDealz.csz

As you can see, very similar to svn:externals only with individual file support which is handy for things like locale files that can’t go in subdirectories.

How It Works

Usage is similar to regular command line usage of subversion. The “modman” script provides a wrapper around svn which checks the code out in a .modman directory at the root of your project then reads the .modman file and creates symbolic links as necessary so that your source code is actually all contained within one directory and your webserver accesses the files where they are supposed to be. No svn:externals definitions are used. Obviously this requires a few things:

1. bash
2. a webserver that is configured to FollowSymLinks

If you do web development on Windows, you may be thinking, “What about Windows support!?”. Well, you have a few options:

• Do your development inside a VirtualBox instance of Linux and share the drive to Windows for editing on your IDE (recommended).
• Try to configure cygwin to work (untested, not recommended).

I chose the former long before I wrote this script since the servers for my projects are all Linux-based and doing development on WAMP when your project runs on L*MP is silly. You can actually still use TortoiseSVN by simply opening the .modman directory from explorer so really after the initial checkout you do not need to continue to use the script except for when adding new definitions to the .modman file.

Sample Usage

Here are some typical commands used with modman:

$ modman --help
$ modman init
$ modman hotdealz checkout "svn url here"
$ modman hotdealz status (can be run from any directory within the project root)
$ modman hotdealz commit
$ modman hotdealz update
$ modman hotdealz add Colin_HotDealz.xml app/etc/modules/HotDealz.xml
etc...

Most commonly used svn commands are passed through to svn for convenience but for advanced work you can just cd to the .modman directory or use TortoiseSVN or your IDE’s integrated subversion tools (I use Netbeans).

Documentation

----------------------
Magento Module Manager
----------------------
Usage: modman <module> <action> [svn args]
Supported global actions (no module specified):
  init           initialize the current directory as the modman root (no module name)
  update-all     update all modules that are currently checked out

Supported actions: (all svn commands support additional arguments)
  checkout       checkout a new modman compatible module
  export         export a modman compatible module (does real copy instead of symlinks)
  update [...]   update module
  add <svn_path> <real_path>   add a file/dir to the .modman file and working copy
  delete <svn_path>   remove a file/dir from the .modman file and working copy
  status         show status of entire module
  diff [...]     run svn diff on module
  commit [...]   commit changes to module
  info           show the module's working copy path and run svn info on working copy
  list           list the definitions in the .modman file

The repository should contain a file called ".modman" which defines which files
go where relative to the directory where modman was initialized.

If additional arguments are given to commands such as commit, paths
should be relative to the svn root.

---- Start example .modman file ----
# Comments are supported, begin a line with a hash
code                   app/code/local/My/Module/
design                 app/design/frontend/default/default/mymodule/
locale/My_Module.xml   app/locale/en_US/My_Module.xml
My_Module.xml          app/etc/modules/My_Module.xml
---- End example .modman file ----

Author:
Colin Mollenhour

http://colin.mollenhour.com/

colin@mollenhour.com

View Source

Download

Leave a comment if you use it!

Repository Setup

In this tutorial, the host’s login is larry, and the group members’ logins are curly and moe. How original…

First, choose a location to host your repos. You may want more than one in which case it would be good to place them all in the same location. I chose “.repos” in my home directory since I should rarely access it directly and no other users will ever access it directly. The name of this first repository will be dmtask1, but you could make additional ones as well, and with different user access rules (more later).

~> whoami
larry
~> mkdir .repos
~> svnadmin create ~/.repos/dmtask1
~> cd .ssh
~/.ssh> ssh-keygen -t rsa -N '' -C 'curly_dmtask1_SVN_only' -f ./id_rsa.curly_dmtask1
~/.ssh> ssh-keygen -t rsa -N '' -C 'moe_dmtask1_SVN_only' -f ./id_rsa.moe_dmtask1

At this point you have created your first svn repository inside your home directory. By default it should be only readable and writable by your user (drwx——). Do not mess with the permissions, just leave them alone.

Also, you have created some public/private key pairs for the two users that we are allowing access to, but we are not done here yet. Send each respective user their private key file (id_rsa.*_dmtask1) via email or preferably some more secure method since those files will allow password-less access to the svn repository.

~/.ssh> echo -n 'command="svnserve -t --tunnel-user=curly -r /home//.repos/dmtask1",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ' >> authorized_keys
~/.ssh> cat id_rsa.curly_dmtask1.pub >> authorized_keys
~/.ssh> echo -n 'command="svnserve -t --tunnel-user=moe -r /home//.repos/dmtask1",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ' >> authorized_keys
~/.ssh> cat id_rsa.moe_dmtask1.pub >> authorized_keys
~/.ssh> chmod 0600 authorized_keys

Now you’ve added the public keys for both users to your authorized_keys file so that they can login to your Linux account without a password. Wait.. What?! Actually, the command=”svnserve -t –tunnel-user=curly”,no-… part tells ssh to run the svnserve command in tunnel mode with the specified user, and not allow any other activity over the ssh session, so you are safe (I think.. I take no responsibility for any security risks blah blah blah…).

Guess what? You’re actually done already. That was easy.

Client Setup – Linux

Ok, now it is time for the clients (your classmates) to do some work.

First get that private key file from the host, say it is called id_rsa.curly_dmtask1

~> whoami
curly
~> mv <path_to_file>/id_rsa.curly_dmtask1 ~/.ssh/
~> chmod 0600 .ssh/id_rsa.curly_dmtask1

Now, setup your environment to force the svn client to use that private key. You will do this with the SVN_SSH environment variable. The first command below sets it once. The second will add it to your is to your shell’s .*rc file: e.g. .bashrc, .zshrc, etc..

~> export SVN_SSH="ssh -i $HOME/.ssh/id_rsa.curly_dmtask1"
~> echo "export SVN_SSH=\"ssh -i $HOME/.ssh/id_rsa.curly_dmtask1\"" >> ~/.`basename $SHELL`rc

You should now be ready to access the svn repository! Here’s how

~> svn checkout svn+ssh://larry@$HOST/@ dmtask1
~> cd dmtask1
~/dmtask1> cat > test_file
This is a test!
<CTRL+D>
~/dmtask1> svn add test_file
~/dmtask1> svn commit -m "Just testing..."

The first command will checkout the repository from the root directory into a new folder in the current working directory named dmtask1. Notice that this command includes larry@, which specifies the host’s username, not yours. Don’t worry, any svn commands you carry out in this working copy will be done under your credentials, not the host’s (the –tunnel-user option accomplishes this).

Client Setup – Windows

If you are accessing an svn repo from windows then you are most likely should be doing it through TortoiseSVN. See this page for some good instructions on configuring your machine to work with this repository setup.

Sources

Official SVN Book

svn+ssh – Some Random Blog