I started to write a post on version-control patterns ("How to pack your trunk") when I realized what a can of worms it was. Essentially, every time I wrote down "the way I've always done it" I realized that there were always trade-offs -- that what worked in some situations wouldn't be appropriate in others. In other words, that there really was a need for a pattern language for discussing version-control / change-management.

I'm not talking about "use version control," which has (thankfully) become standard. I'm talking about the organizational memory of your software development team. For instance, I generally organize by deployment task -- /Web, /App1, /App2, /Utilities, etc. But in a more service-oriented environment, it might definitely make more sense to organize in a more use-case driven manner: /admin, /tradingpartner1, /tradingpartner2, /internalclient1, etc.

Umm... Am I missing a well-known resource on this issue? Basically, the post quickly grew towards article length while hardly scratching the surface. I could throw up a Wiki on the topic easily enough, but I don't want to duplicate effort. Thoughts?