Add file to checkin via Trigger

[tyler]

I'm trying to add a trigger that will update a versioned file with the submitted changeset number upon each checkin. I've tried using a before-clientcheckin where I update the file (although the changeset is unknown) and then execute a "cm co" with changed file, but the file isn't included in the checkin. I've also tried doing the same thing with an after-clientcheckin trigger with an added "cm ci" but both times it fails to either include the file or submit another checkin.

Is there any way to do this? I basically just want to automatically write the latest changeset to a file and keep it in source control.

[psantosl]

Hi Tyler,

The best thing you could do is to have a before-client-checkin trigger, where you have access to the workspace, so you can write files and so on.

Problem: what you want to do is to get the changeset number, and it can be predicted prior to checkin (the sequence could be possible, if no concurrent checkins happen, but the GUID won't).

So, the best option I see now is that you create a new changeset with the number, of course the number will be the one of the previous cset, but for build purposes it will possible work.

 

A better option: do you really need to have the changeset on a file? Or can you generate this file upon checkout and fill it with the right cset number? Because doing this last approach would be very simple.

 

Thanks!

 

pablo

[tyler]

Thanks for the reply Pablo.

I believe I do need the changeset file versioned because we only conditionally change it (ie. on source file changes, not on data/asset changes) and I want to know the changeset of the latest binary (as well as check to see if it differs from the previous workspace binary cs).

I'm not terribly concerned with the changeset being correct 100% of the time, so if the rare concurrent checkin throws it off then no big deal. Is it possible to ensure that a file that changes from a before-clientcheckin trigger gets included in the checkin? Simply doing a checkout from the trigger didn't work when I tried it. The change was simply left in the workspace and the user would need to do another checkin to submit the changeset file.

Thanks!

Tyler

[psantosl]

Hi Tyler,

 

before-client-checkin lets you modify changed files, so if the file you want to modify is there, then you can change it (and you could get the latest changeset, add 1, and more likely you'd be predicting the changeset number, but of course it doesn't have to be 100% true if someone checkins concurrently).

 

I need to better understand what you want to achieve, and then we can probably find a solution. Why do you need to record the cset *inside* a file and not use the version control itself to host that? Can't you add an attribute to the changeset when you need to track a given version? Or even a label?

 

Thanks!

 

pablo

 

[tyler]

The most important thing I'm trying to track is to know when source files were added or removed. Secondarily to that it would be nice to track the changeset number of the last built binary.

So my approach was to use a checkin trigger update the changeset in a file whenever source files are added or removed. Then when clients that sync to that changeset the build tools notice the change in the version file and trigger a proper rebuild (regenerate project files in unreal). This approach gives the added bonus of easily tracking the changeset number in a header file that the binary can reference.

The only problem I ran in to with this is that the trigger needs to change and add a file to a checkin that was not specified as part of the checkin.

I'll look in to adding attributes or labels, but unless I can communicate to the build tools that source files were added or removed between the old/new changesets then it's moot. It's worth noting that this needs to be a fast operation, or else I might as well rebuild every change all the time.