お世話になります。
<br/>
ビルド実行時、他者によってチェックアウトされているファイルがある場合、それを強制チェックアウトする実装方法について伺いたく思います。
確認しましたところ、bool FPlasticSourceControlState::IsCheckOutOther によってその判定を行っているようですが、そのファイルを強制チェックアウトしたい場合、どのようにすればよいでしょうか。
宜しくお願い致します。
お世話になっております。
ご質問ありがとうございます。
強制チェックアウトを行うには、まず、お使いのバージョン管理システムに強制チェックアウト機能が搭載されているかどうかを確認する必要があります。
APIから拝察するに、Plastic SCMをご利用でしょうか？
実装としては、特定の条件が与えられた場合に限り（コマンドラインで特別な引数を付与したときなど）、FPlasticCheckOutWorker::IsChckedOutOther()が戻すフラグをfalseに偽装させ、FPlasticCheckOutWorker::Execute()で編成するコマンドの内容を強権的なものに変える、というアプローチが考えられます。
大変申し訳ないことですが、Plastic SCMはEpicの製品ではないため、強制チェックアウト機能の有無や手順について確認／保証することはご容赦ください。
以上、よろしくお願いします。
お世話になります。
ご確認ありがとうございます。
バージョン管理システムはPerforceを使用しております。
こちらですが、現状のUEのプログラムですと、ビルド中、１ファイルに対してSaveを試み、それがSaveできない場合、処理を停止するようになっているようです。そちらを強制チェックアウトを行いSaveを行うにはどのようにすればよいでしょうか、という質問でした。FPackageSourceControlHelper、FSourceControlHelper、ISourceControlState.hなどで、CheckOutやAdd、Delete、Save、またはIsCheckOutInOtherBranchなどがあるようでしたので、それらを拡張する形で実装できるのか、質問させていただきました。
お世話になります。
チェックアウトの衝突についてですが、頻繁には起きておりませんが、長時間のビルドの場合に、それが起きてビルドが止まりますと影響が大きい状況です。
状況につきましては、ご推測の通りです。
---------
チェックアウトの衝突が生じているか、CI（Jenkinsなど）がビルドを実行した際の書き込み先がバージョン管理システムで管理されており、開発者がそれをチェックアウトしていることがあって、衝突が発生している
---------
また、ご回答を受けまして、仕様のほうを再度検討しようと思います。
ありがとうございました。
ちょっと違う話かもしれませんが、Perforce運用でビルド作成やリダイレクタ修正などでチェックアウト状態で作業したい場合に、Release Streamを作成して、そちらで作業、完了後にマージという手段を取ることがあります。その際にチェックアウトされているものとコンフリクトすることには変わりは無いですが、一旦作業完了したあとでコンフリクトしたファイルだけ個別にあとで解決できるという利点があります。
ワークスペースを別に作成する必要があるのと、ブランチ・マージ処理にある程度時間がかかってしまうという欠点はあります。
自分のやり方だとAutoCheckoutなどつけずに（もしくは-noP4など）SCMなしで実行させて、最終的にサブミットの必要なファイルを自前でreconcileしてチェックアウトとチェックインするやり方をいつもしています。
ジョブはローカルで稼働するのでジョブ自体のエラーのみに集中できますし、サブミット前のチェックアウト失敗などにも臨機応変に対応（ロックしている人にメンション通知など）できるのでサブミットは自前でやったほうが取り回ししやすいと思います。
スクリプトひとつ書けば色々なジョブで使いまわせるので結構便利です。
注意点として、ジョブでチェックアウトしない場合は書き込まれるファイルの読み取り専用を外す必要があるので、WSの設定にallwrite（書き込み可能状態で更新）、clobber（ローカルが新しい時も上書き）の2つの設定をしておく必要があります。
p4 submitはフィルリストが空のCLをサブミットするとexit 1になるのでそちらも対応が必要です。
チェックアウトの失敗は誰かにロックされていて失敗する場合と、ジョブ実行中にファイルが更新されてチェックアウトに失敗する2通りになるので、そちらも何かしら対応が必要です。
お世話になっております。
皆様コメントありがとうございます。
Release Streamを作成するか、SCMを切って実行するかの違いはありますが、コンフリクトの問題が起こらない状況で実行を行い、サブミット時にReconcileなどで解決を図るというアプローチは、確かによくお見かけするやり方であると思います。
大変参考になる情報をご共有いただき、誠にありがとうございます。
それでは改めてチケットをCloseさせていただきますが、ご不明点や追記コメントなどありましたら、遠慮なくご利用ください。
以上、よろしくお願いいたします。
お世話になっております。
ご返信ありがとうございます。
バージョン管理システムはPerforceをお使いとの旨、承知いたしました。
UEの保存システムは、連携先となる（他社製の）バージョン管理システムにリクエストを投げているだけであるため、バージョン管理システム側でサポートされていない機能に関してはUE側でも実装しようがない、という点はご承知おきください。
そのうえで、東陽テクニカ様が公開されているPerforceのマニュアルを確認してみたのですが、
https://kb.toyo.co.jp/wiki/display/KBTOP/Helix_Core_Manual
https://kb.toyo.co.jp/docs/core/r23.1/manuals/CmdRef/Content/CmdRef/p4_edit.html
Perforceには排他的チェックアウトで他者にチェックアウトされたファイルを強制的にチェックアウトするオプションが提供されていないように見受けられます。
可能な操作は、super/Admin権限によるチェンジリストの強制Revertで、
https://kb.toyo.co.jp/wiki/pages/viewpage.action?pageId=17475859
通常は、このような強権的なオペレーションは管理者が手動で行う操作であり、UEの標準の保存プロセスの拡張として実装するには複雑で、また、安全でないと考えます。
また、ビルド時にチェックアウト衝突が起こることは、社内外でもあまり見聞きすることがない状況です。対策として、バージョン管理システムの管理範囲やワークフローを見直すことも一つの手ではないかと思います。
弊社でもチェックアウトで問題が生じた際は、チェックアウトをかけている者に直連絡し、当人にRevertさせることを原則としています。連絡がつかない場合のみ、特定の手続きを経て管理者がマニュアル的に強制Revertを行うというルールです。
実際、お手元ではどのような頻度、状況でチェックアウトの衝突が生じているか、お聞かせいただくことは可能でしょうか？ たとえば、CI（Jenkinsなど）がビルドを実行した際の書き込み先がバージョン管理システムで管理されており、開発者がそれをチェックアウトしていることがあって、衝突が発生している、といったような状況でしょうか？
※必要があればこのスレッドをpublicからprivate投稿に切り替えることも可能ですので、お申し出ください。
以上、よろしくお願いいたします。
# 2025/06/09 13:02 一部編集
お世話になっております。
ご確認ありがとうございます。
仕様の方を再検討いただけるとのこと、承知いたしました。
それでは本件は回答済みとしてCloseさせていただこうと思いますが、再検討時に何か不明点や、疑問点が生じた場合は、EPSを通じてお気軽にお問い合わせください。
以上、よろしくお願いいたします。