Checkin trigger and obsolete documentation

[JakubH]

I am playing with a before-checkin trigger a bit now. What I need is to find out if the changes contains a merge link (or merge links) and if so, what are the names of the source and destination branch(es). I need this for implementing a better checkin comment checking – we want to have stricter rules for a comment of an integration changeset (merge from a feature branch to a release branch).

Is there a way to find out these information from before-checkin trigger (or before-checkinclient at least) using some cm command(s) or maybe with some custom SQL queries to an underlying database?

 

I suppose that the destination branch could be retrieved from the standard input of the trigger. However, the documentation of the trigger is probably outdated. It says that the format of revision specification of every change (received as a standard input of the trigger) is this:

 item_path #br: branch # rev_no ;rev_id@ rep:rep_name@repserver:server

and this suppose to be an example (which BTW doesn't seem to fit to the format perfectly):

/code/clean.bat#br:/main#CO;revid:12936@rep:default@repserver:DARKTOWER:8084;wk:trigger_test@DARKTOWER

 

However, this is what I get:

CH "/" DIR#br:/main;changeset:118@rep:sandbox@repserver:PLASTIC-SERVER:8087

Which is something completely different from the documentation. It seems to have this format:

change_type path item_type#br:destination_branch;changeset:changeset_number@rep:rep_name@repserver:server:port

where changeset_number is probably changeset ID of a changeset with the parent revision of that item.

In before-checkinclient trigger only change_type absolute_path item_type is given.

 

The documentation says that the content of the changes can be retrieved with cm cat and even changed with cm shelve, but only thing I can get from this is the parent revision of the item, not the actual new revision.

 

[nqramjets]

Out of curiosity, were you able to retrieve the merge-link information?

[JakubH]

Frankly, I figure out a simpler way how to deal with the checkin comments, so in the end I didn't need it. However if needed, I would use direct SQL query to the underlying database now. The schema is not difficult, so it is not so hard to figure out how to retrieve the information you want. And it is much more effective and flexible than cm find.

[nqramjets]

Thanks Jakub, that's a good idea.