2

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?

max
  • 49,282
  • 56
  • 208
  • 355
  • Are you talking about a workflow here where a developer discovers a bug while offline. Diagnoses and fixes the issue while still offline and then wants to commit the fix (while still offline)? This sounds like development driving the issue tracking system instead of the other way around? What about the bit where current issues get prioritised? – Nick Pierpoint Aug 24 '12 at 10:53
  • @NickPierpoint: We are trying to move towards the issue tracker driving development *when possible*, but your example still happens quite often - when I travel for example. Of course, I won't know about the most recent priority changes; presumably someone who is in the office can address those, while at least I can do something useful to the old issues. Does this arrangement seem reasonable? – max Aug 24 '12 at 17:43
  • So when travelling you have no access to the internet? No option for contacting the office to create an issue? Hard to believe you'd be out of contact for an extended period - if that's the case then commit locally while incommunicado then follow Raghuram's advice when you resurface. – Nick Pierpoint Aug 29 '12 at 11:46

3 Answers3

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.

Community
  • 1
  • 1
Raghuram
  • 51,854
  • 11
  • 110
  • 122
  • Very interesting, I didn't know I could edit commits or collapse them. I guess this is almost identical to option 4. The only difference is that instead of retroactively linking issues to commits, we'd retroactively edit the commits. Unfortunately, we still need to temporarily store the information about what each commit did, and later copy/paste it into redmine and commit messages. – max Aug 17 '12 at 17:50
0

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.

Mizipzor
  • 51,151
  • 22
  • 97
  • 138
  • But how do you know what to write inside the square brackets if you don't have access to the bug database? And what if the bug isn't even in the database yet when you discovered it (while offline)? – max Aug 17 '12 at 17:54
  • @max with mercurial its easy to edit (unpublished) history. Everyone on the team has a different strategy. Myself, I usually just use a placeholder like `[XXXX]` until I get back online and check the bug database for the number (or report the bug to get it). – Mizipzor Aug 20 '12 at 07:29
0

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.

max
  • 49,282
  • 56
  • 208
  • 355