Linking commits to issues - best practices [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

We are trying to introduce what we hope is a good development practice: every commit must be linked to an issue in issue tracking system. (It's perfectly acceptable to create a new issue in order to satisfy this requirement.)

Our issue tracker (Redmine) and DVCS (Mercurial) integrate well, but we have one problem: what happens if a developer needs to commit something while offline? Currently, Redmine is accessed online, and Mercurial is accessed through TortoiseHG (Windows) or shell (Linux).

I am not aware of any tool (e.g., a Windows desktop client, commercial or free) that allows to use Redmine offline (to create issues, not just view them). We wouldn't even mind copying Redmine database to each developer's machine, but then sync'ing the databases wouldn't be easy.

What should we do? I can see the following options:

1. Switch away from Redmine to an issue tracker that has offline support. [I don't think Trac is that much better]

2. Hack together some solution to create issues in Redmine offline. [not sure how, without causing rather than solving problems]

3. Give up on the idea that commits must always refer to an existing issue. [but it seemed like such a good idea]

4. Retrocatively link commits with issues. [this requires that the developers write the description of each issue in a temporary location, later copy them to Redmine, and then manually link the new issue with the commit; inefficient and error-prone]

5. Prohibit offline commits (thus, prohibiting working offline). [seems silly, given how DVCS was selected primarily to allow offline work]

What would be your recommendation?

Answer 1

It is one thing to work on issues offline and commit locally and another to push it upstream (say to a designated server).

The former can be done without access to redmine. Either there could be an existing redmine issue or a new issue would need to be created and associated with the commits.

Before pushing the changes upstream, the issue id can be updated either by editing the last commit or while collapsing multiple commits to one. The latter may be a better option since you would have a single commit upstream per issue - which can be easily rolled back, if required.

Answer 2

Here at my place we have commits linked to specific issues (in the case of bugfixing commits). The system is simple:

1. In the commit message you type the bug number inside square brackets.
2. When we do a release we collect all the commits made since last release.
3. Through regular expressions we extract the id's of bugs fixed.
4. We use this list to update the bug database and create a changelog.

I think the important lesson here is that the bug database and version control system doesn't have to be that explicitly linked. Through the syntax convention its easy to aggregate and get an overview, which makes it easy (enough) to update the bug database manually.

Edit: Regarding the "work offline" part. Mercurial is a DVCS and not meant to be constantly connected. Embrace this, allow local commits and handle the bug database when you got back online and/or push.

Answer 3

Redmine effectively has an offline ability to create issues: it can be configured to accept new issues and issue updates by email. And most email clients work offline (storing the message temporarily in the outbox, until the user goes online).

Email can also provide a (very limited) offline viewing mode. If I'm notified by email of every new issue and update, and automatically move those emails into a separate folder, I can find the corresponding issue number.

This isn't ideal, but works as a makeshift solution until redmine adds an offline mode. And of course, if it's done by too many people, there's a risk of conflicts that redmine isn't equipped to resolve well (e.g., two people trying to change the issue status).

There's also one general and unavoidable problem with the integration of DVCS with a (centralized) issue tracker. Suppose two developers solve a certain issue, and link their commit to it. When they both push their commits to the repository tied to redmine, only one of the solutions would be kept during the conflict resolution process. The issue will still be linked to individual commits, without a clear indication that one of the commits is essentially deprecated by another.