Display Changeset number after Checkin

[Tobix]

Hi,

it would be nice if there is an option to display the new changeset's number after the checkin.

On most projects I have worked on you have to record the changeset's number in some other system (Ticketing, Bugtracking, Mail,...).

So it would be quite nice, if that this important information is displayed automatically - like the shelf's number.

Thanks

Tobias

[psantosl]

Why would you associate a checkin number to an issue tracker instead of the branch?

 

I'd recommend you taking a look at https://www.plasticscm.com/book/#_a_perfect_workflow

 

Also, we have integration with some issue trackers that can do this association for you. And, you can always write a trigger to do this association. Or a trigger to pop up a dialog that does this

 

But, popping up a dialog with the cset number is not something we'd like to do, because it would be disruptive for mostly everyone except you 🙂

[Tobix]

Hi Psantosl,

thanks for the really fast reply.

Quote

Why would you associate a checkin number to an issue tracker instead of the branch?

Because this is only the unique information to track an issue. The branch describes the work and consists often of many checkins. But the checkin number gives me the correct information when this issue returned to /main.

Quote

I'd recommend you taking a look at https://www.plasticscm.com/book/#_a_perfect_workflow

Sorry, but a perfect workflow exists only in a perfect world. 

If you have only one issue tracker it might be an option, but in the real world you have many systems (often legacy) to work with and humans, that also need this information (mail, chat etc.).

All of them require the changeset number.

 

Quote

But, popping up a dialog with the cset number is not something we'd like to do, because it would be disruptive for mostly everyone except you 🙂

The shelf's dialog has a "Do not ask me again" checkbox , so everyone not needing that information can hide it forever.

I am sure that I am not the only one.

[JanReimer]

Hi Pablo,

I've also been having the need for a quick display of the changeset that I've committed.
I also would like to quickly see the changeset that is currently loaded in my workspace (not the branch that I'm on).

I know I can open branch explorer and hit the home button in order to see the changeset that I'm on. But branch explorer is not open all the time and I would like to have this information at a glance.

A nice solution would be to always display the loaded changeset somewhere in the client (probably the area where selector info is displayed). This would meet both requirements.

By the way, our "perfect workflow" utilizes 3 different ticket systems and our projects can have any combination of these. However, in Plastic I have to decide to use one. Furthermore, Bugzilla connection doesn't provide password input field while we use AuthZ/AuthN for our server. That is, we cannot use Bugzilla issue tracking in Plastic SCM.

Best regards
Jan

[calbzam]

Hi,

You feedback is very welcome. We have been evaluating it but as Pablo commented, the the easiest workaround for now to get this information is creating an "after-checkin" trigger that opens a message box, pop up or similar...

https://www.plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide#Checkin

Best regards,

Carlos.

[Tobix]

HI Carlos,

thanks for your suggestion with the trigger.

If we would register a client side  trigger, will this be run on every user's machines?

Or can we limit it to some users or perhaps operating systems?

As we have Windows and Mac Clients we would expect difficulties if this client trigger would be global to all users.

May I ask another more basic question to client-side triggers?

As far as I understand the samples - the script or code will be run on the client's computer. Do you have any tips how to deploy (and keep it updated) the scripts on 100+ computers?

Thanks

Tobias

[calbzam]

Hi,

Quote

If we would register a client side  trigger, will this be run on every user's machines?

Yes, the client side triggers are ran on the client machines.

Quote

Or can we limit it to some users or perhaps operating systems?

https://www.plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide#Clientcheckin

The triggers include some filter you can use. But if you want to filter per user or OS, I'm afraid that the code of the trigger will need to handle it.

Quote

 

May I ask another more basic question to client-side triggers?

As far as I understand the samples - the script or code will be run on the client's computer. Do you have any tips how to deploy (and keep it updated) the scripts on 100+ computers?

 

You can distribute the client side trigger via global configuration. I think it would be the easiest way:

https://www.plasticscm.com/documentation/administration/plastic-scm-version-control-administrator-guide#Globalfileconfiguration

Regards,

Carlos.