-2

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.
flag
1 
 I have no idea what you are talking about, nor do I have a clue what the question(or request) here is – cdeszaq Aug 27 2010 at 13:06
We would love to assist you, but could you clarify your request? What is it that you're trying to accomplish? – Bradford♦ Aug 27 2010 at 13:11
It's referencing another post. I frequently mistype the BugzID: xxx when checking in files. This causes the wrong FogBugz to be linked to the files just checked in, and the intended FogBugz doesn't have the files. Perforce doesn't send a new trigger after the changelist has been submitted, even if you go back and change the Description field. So i need a way to update the Perforce linked files in Fogbugz after a changelist has been submitted. – Cahd Aug 27 2010 at 22:01

closed as too localized by Rich Armstrong♦♦ Sep 19 at 17:08

1 Answer

1

It seems to me that the first case of the missing BugzID statement should be corrected for inside Perforce by not allowing the check-in to proceed if "BugzID" doesn't exist. I don't have experience with Perforce, but I know Mercurial can abort a commit if certain conditions aren't met. I'll trust you when you say it's trivial in the script, though :-)

For the second circumstance, if the only problem was that you entered the wrong case number then the key would be updating the FogBugz database. If you're an On Demand customer, this isn't an option as even our Plugin architecture wouldn't allow someone to accomplish that. If you're a licensed customer, though, you would need to update the CVS table. Locating the correct row to change would probably be the hardest (since you would need to know the Previous and New check-in values), but once you did it's simply a matter of changing the ixBug column to be the correct case number.

But you would need to make those changes reactively to making the typo in the first place, so I'm not sure how you could make it part of the script itself. Perhaps you could code a way to tell the script "There were bad check-ins in the last batch, here are the corrections"? Since your script runs every few minutes, it could do the changes as a batch.

link|flag

Not the answer you're looking for? Browse other questions tagged or ask your own question.