| || |
Should all code changes be associated with issues?
I am working at a company with Accurev as the source control versioning system.
It is configured in such a way that every time you promote code into accurev, your change needs to be associated with some certain "issue". I think this sometimes feels like annoying overhead, and would like to know whether there are any best practices regarding how to to deal with this "problem" ?
( I welcome references to relevant good books, articles, webpages, blogs... maybe the best practise even is to avoid the enforcement of associating everything with issues)
See the paragraph below for an example of why I think it can be a problem to try to associate all promotes to certain issues.
For example, if I am working with a certain "issue" (and having modified some code in a couple of classes) and then I suddenly get involved in something else, such as a colleague coming and wanting to do some pair programming with me (and this new work should belong to another "issue") in my workspace.
Then when our pair programming session is over, I would like to also finish the code changes in my first "issue", but then when I promote the code I need to choose one issue when the code is promoted.
Sure, I can choose only of the issues and promote everything into that issue, but then the purpose of the trackability by issue get partially lost when you promote some stuff that are unrelated to the issue, but just by "accident" (kind of) got coupled with the issue.
Finally, I just have some terminology questions (which would help me to google for information about issue handling strategies):
Do CVS or Subversion have similar (as Accurev) issue tracking features that enforce the developers to associate the code promoting to certain issues ?
Are those source control systems using another word for "issues" and another word for "promote" when you save your code into the source code repository system ? If so, what words do they use ?
Re: Should all code changes be associated with iss
To answer the topic title: It really depends on your development process. Tracking every check-in helps to communicate to the team what you're working on and how it might impact them. In your example, why are you promoting things that aren't related to the issue? Is the problem that the issue doesn't cover the complete functionality? Why is that the case? The issue should be like an external comment that spans code files - you know why you promoted those files, who you promoted them for, and maybe have some idea of how long it took you to complete the work.
CVS and Subversion do NOT have built-in issue tracking systems out of the box. There are several add-ons, and every popular defect/issue tracker should support them with add-ons or scripts that let you track check-ins with tasks/issues.
CVS uses the term check-in (if I remember correctly) and SVN uses the term "commit".