ソース管理には MKS Integrity を使用しています。私はそれを制御することはできません-私はそれを使用する必要があります。
知っておくべき、避けるべき「落とし穴」にはどのようなものがありますか? また、ソフトウェアをより使いやすくするための優れた点はありますか?
ソース管理のツリー構造がサンドボックスのツリー構造と一致しないケースにすでに遭遇しました。複数のケースで、ファイルが 2 つの場所に存在し、再同期すると現在のバージョンが取得され、古いバージョンが上書きされ、同期されなくなります。もちろん、ツリー構造が一致しないため、古いファイルを見つけるのは困難です。
私は 1999 年からソース管理を使用しています。信頼性が高く、変更履歴が失われたことはありません。私たちはブランチに関して特別なことをしていないので、あなたの質問には答えられません。
再同期 (F6) とヘッドへの更新 (F7) を行ったとします。
SI は、コマンドライン設計に基づいて構築されています。コマンドライン バージョン (pj.exe など) を使用すると、より一貫した結果が得られる場合があります。ドキュメントは簡単ではありません。
MKS は、最新のエンタープライズ バージョンに莫大な資金を求めているため、Subversion に移行しようとしています。
この MKS の落とし穴を発見しました: 一度に特定のラベルを持つことができるメンバーのリビジョンは 1 つだけです。
私たちのチームの誰かが pdf リソースの名前を変更し、ファイル名に _Old を追加しました (彼はそれを削除するのではなく、それをデプロイの一部にしたかったので、これを行いました)
次に、新しいバージョンの pdf を同じアーカイブに追加して、既存の改訂履歴グラフに接続できるようにしました。
ここで、そのメンバーのリビジョン履歴を見ると、同じメンバーの 2 つのリビジョンが同じ開発パスで使用されていることがわかります。
展開プロセスの一環として、展開されているアーティファクトをチェックポイントし、メンバーにラベルを適用して、メンバーが含まれるリリースを指定します。
MKS は 1 つのリビジョンにのみラベルを適用するため、チェックポイントを確認したところ、ラベルが欠落していたため、新しい pdf が展開に含まれていないように見えました
また、VISUAL STUDIOの統合は避けてください!!! それをインストールして以来、私のチームの何人かのメンバーはビジュアル スタジオの頻繁なクラッシュに取り組まなければなりませんでした。明らかに、その分岐メカニズムは、整合性コマンド ラインまたは GUI クライアント内に同等のものがない機能に依存しています。したがって、チームの誰かが Visual Studio 統合を使用している場合、彼らが作業するブランチが統合によって作成されていない限り、それらは機能しません。そのため、統合を使用しているチーム メンバーがそれを操作できるようにするためだけに、Visual Studio がゆっくりと貧弱に行うことを Visual Studio で行うことに行き詰まっていることに気付くでしょう。