Question

There appear to be two Perforce integration possibilities:

1. A server trigger submit on Perforce that scans a changelist description for a string pattern like BugzID:casenum, which connects to Fogbugz that adds a reference to that changelist to the case.
2. A P4DTG integration that uses the Perforce jobs mechanism to map cases to jobs.

For the last year or so we have been using the first of these, mainly due to infrastructure reasons. The trigger mechansm relies upon the engineer remembering to add the string pattern, and not mistyping the case number. There appears to be no way to fix erroneous entries after the fact.

So I've been looking at the P4DTG solution. While at first sight it looks ok, there are a couple of issues that are raised from the docs. Firstly, it appears that a Perforce job is created for every new case in Fogbugz. This will cause us problems - a case will not necessarily involve Perforce work, for example. Secondly, it appears to rely upon the software engineers managing jobs in addition to changelists. While not at first sight a big issue, it does introduce a change to current practice. And I'm still not sure if P4DTG cures the incorrect data issue by allowing fixes post-submit.

My instinct is to stay with the first one, and live with the incorrect data issue. Is there a way to fix up this data afterwards?

But P4DTG is more modern & integrated - I just don't like the thought of hundreds of jobs being on the Perforce server which are not needed. Or am I missing something?

So what is the best solution, workflow? Does can anyone pass on their experiences?

Answer 1

We've used a script for quite a while now that is executed every few minutes (not from a trigger -- it uses a counter) that was modified from the Perforce review daemon script. This in itself was pretty easy to set up. As far as incorrect information is concerned there are two possibilities:

1. Missing a case number: the web query to add this is actually pretty trivial and can executed quite easily after a changelist has been modified (or completely manually).
2. Incorrect case number: this would require an edit to the FB database to remove the incorrect case number. The correct correlation can be made as in the previous note.

We didn't go with the P4DTG solution because of 1) when we set this up, there were server conflicts and 2) the extra FB user required for its usage.

Answer 2

We've been using FogBugz for about 6 years now, and Perforce just a tad longer than that. Integrating the two has been a thorn in my side since day one. I tried the script/trigger method first, but found it cumbersome for the reasons you mentioned.

I then tried the P4DTG for a while, but eventually gave up on it. While it is better, it's not good enough. First of all, I found it too complicated to configure. Sure, if you follow the instructions you can get it working well enough, but the configuration is not intuitive. If something's not working right, good luck figuring it out. Secondly, it provided little useful functionality. Once it's working all it really does for you is add a changelist number to a case. The link to show you a diff uses P4Web and I found it useless (and again, it's another thing you have to set up and maintain). Finally, it was too unreliable. It seemed the service was constantly stopping for reasons unknown. There have been a few updates since I gave up, so maybe it's better now, but I'm not going to bother finding out. I'm done with it.

Regarding your concerns with the P4DTG, I don't know of a way around all the useless jobs that you are going to accumulate, but I can say they don't really get in the way. When it came time to attach a job to a changelist, it was a simple matter to find it by searching on the FB case number. Also, you can attach a job to a changelist after submission, so you're not screwed if you forget to attach it like you are if you forget to include the "BugzId" when using the script/trigger mechanism (although Kris K. seems to have found a way around that problem).

If you've got something working in place, I say follow your instincts and stick with it. The switch to the P4DTG will, at best, bring you little to no improvement over your current process, at worst, it will bring you countless hours of frustration.

I currently use neither. When I submit a changelist, I include the case number in my comment. When I resolve a case, I tag it with the changelist number (e.g., "cl-7370").