This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
We're looking for version control integrated with issue tracking w/ the following functionality:
1. Create an Issue and tie it to code when we check that code in
2. When we decide to build a release, we want ONLY the code from a particular version control branch that is associated with specific issues (or with issues that have set to some special status - e.g. BUILD). For example, if I created Issues MR123 and MR456 and there's code tied to both, I then want to be able to say that I only want the code that was checked into the version control repository that was associated with MR123 and NOT MR456
3. The version control repository does not have to be distributed; we're ok w/ a centralized repo
4. Version control allows branches for different releases; merging from one release to another
5. Version control integrates w/ eclipse (can specify the Issue that the code is being associated with)
6. Works on Unix
Is there a version control and issue tracker combination/integration that can provide us with this functionality?
The only one of those that I think is a real problem is the one about pulling a la carte revision code. VCS's are pretty much universally designed with the idea of storing and retrieving modular units, not 1 from Column A and 1 from Column B.
You can probably achieve that effect if you keep a master project and use that as a reference to build patch files for each feature. The patches would then have their own home within the repository. I have actually done something similar when I was trying to juggle multiple sets of changes and didn't know which ones would be released when. As long as the patches don't conflict, they'd be easy to use. Fun breaks out when there are conflicts, however, since at that point you have to pull 2 copies of the project, apply the separate patches, then merge the 2 patched copies. Merging is a pain even without patches.
Branching and tagging are common in many, if not most VCS's. Subversion is an efficient manager for alternate versions of a project, since it presents a view as though each branch or tag is a separate clone variant, but under the hood, only the differences between the various copies are kept, which cuts way down on repository storage requirements.
Customer surveys are for companies who didn't pay proper attention to begin with.