私の個人的な経験に裏打ちされたヒントを提供しようと思います。
私のチームメイトの1人は、経験はあるものの、SVNを本当に理解していません。当然、SVNの海を描いたメンタルマップ上の空白の領域は、彼にかなり奇妙な使用パターンを採用させます。
たとえば、「開発者ごとに1日1 SVNコミット」というポリシーを宣言しました。そうしないと、「サーバーのディスクスペースがすぐになくなる」ためです。SVNコミットは完全なコピーではなくデルタであると彼に説明したとき、彼は疑いを持って返答しましたが、今日でもその意味を理解しているかどうかは完全にはわかりません。
ディスクスペースが問題であったとしても、一度に多くのファイルをコミットすることができるため、彼が提案したのは間違った解決策だと思います。さらに、SVNはバイナリファイルのデルタを保存しないため、大きなバイナリファイルをチェックインすることで多くのスペースを浪費する可能性があります。1日に1回のチェックインも、たとえば1日に複数のバグを修正する場合など、一緒に属さない変更をコミットするように強制するため、悪いです。
当社で採用したソリューションは、バイナリファイルを含むコミットを拒否するフィルターがあることです。チェックインコメントに特別なキーワードを使用することで、コミットを強制できます（実行内容を知っていることをSVNに示す必要があります）。1年に1回または2回、プロジェクトマネージャーは古いブランチをアーカイブし、リポジトリから削除します。この戦略では、私が知っているスペースの問題はありません（私たちのリポジトリはいくつかの異なるプロジェクトをサポートし、100000以上のリビジョンを持っています）。
要約すると、ディスクスペースは重要な問題であることに同意するが、その一方で指摘することができます。
- 1回のモノリシックなチェックインではなく、機能関連のチェックインの重要性。
- 1日に1つの大きなバイナリファイルをチェックインすることで、とにかくディスクがいっぱいになる可能性があるという事実。
その後、ディスクスペースの使用を管理する戦略（たとえば、バイナリファイルフィルター、定期的なバックアップ、古い未使用のブランチのクリーンアップ）を議論するために、会議（おそらく他の開発者またはシステム管理者と）を開催することを提案できます。
また、SVNにEclipse .project構成を含めるかどうかについての激しい議論がありました。私のチームメイトは、多くの無意味な衝突を引き起こしましたが、そうすべきだと主張しました。私は個々の開発者構成ファイルをSVNに保存することに反対でした。最後に、チームメイトは、コミットのたびにソースツリー全体を再チェックアウトして、「リポジトリにコミットされたコードが機能すること」を確認する練習をしていることがわかりました。それが、彼がSVNでプロジェクト構成を維持することに非常に熱心だった理由でした。そのため、プロジェクトを再インポートするのは簡単です。コミットが作業コピーをリモートのバイト単位で同期し、再チェックアウトが不要になると説明したとき、私のチームメイトは再び疑念を持って応答し、最終的に問題全体を取るに足らないものとして振り切った。
私の意見では、チームは、SCMとまったく共有する必要のない開発者固有の設定のみを含むプロジェクト構成ファイルのSVNの競合を解決することで時間を無駄にします。誰かが誤った仮定に基づいてプロセスを調整したため、これはすべて混乱しています。
ビルドサーバーを使用していますか？プロジェクト全体をチェックアウトして毎晩コンパイルするビルドサーバーがあります。翌朝、テスターにはすぐにテストできる製品のインストーラーがあり（マスタービルドが正常に実行された場合）、私たち（開発者）はすべての警告（およびエラーがある場合）を含むビルドレポートを取得します。もちろん、あなたは、各開発者は、プロジェクトの残りの部分と一緒にそれらをチェックアウトすることができます。ビルドサーバー用の標準の設定ファイルを設定し、それらを確認する必要があるが、それらは、チェックインすることはできません任意のローカルな変更。
このシナリオでは、プロジェクト全体をチェックアウトしていつでもビルドできるようにするという彼のニーズに対応します。また、製品の一部ではないため、そもそもチェックされてはならない変更をマージするのに時間を費やすことも避けます。製品はマスタービルドであり、クリーンに保つ必要があります。誰かがマスタービルドを壊す（たとえば、自分の.projectファイルをチェックインする）場合、変更を元に戻すか、その開発者に問題を修正させることができます。
もし彼が再び問題を持ち出せば、あなたは再び会議を開き（おそらく他の開発者と）、共通の戦略を一緒に見つけることを提案できます。
SVNの基本をよりよく理解するために、自分をシニアだと思っているチームメイトを説得するにはどうすればよいですか？
最善の戦略は、紛争を個人レベルに持ち込むことを避け、むしろ手元の問題と可能な解決策について議論することだと思います。あなたが彼が個人的な対立を探しているという印象を持っている場合、ここにいくつかの提案があります（再び、個人的な経験から）：
- チームのダイナミクスはどうですか？あなたの同僚は、このチームメイトと同様の経験を持っていますか？チームが特定の行動（小さなジョークまたは観察）を阻止し、建設的な対立（会議の提案、またはコーヒーブレーク中の非公式なトピックの立ち上げ）を促すために、チームのメンバーの1人に与えることができる、明示的ではない小さなヒントがたくさんあります）。優れたチームは、邪魔な要素をすばやく特定し、物事を通常の状態に戻すことができます。
- あなたの人事管理はどれほど良いですか？私たちの会社には紛争が1件あり、状況をクリアするために人事部長が介入しなければなりませんでした。それは素晴らしいものではありませんでしたが、時には作業環境が非常に悪化し、それ自体では良くならないことがあります。これがあなたの場合ではないことを願っています（まだそれまでに得た印象はありません）が、あなたが良い人事管理を持っているか、自分で紛争を解決する必要があるかどうかを知ることは常に良いことです。
なぜこれを書いているのですか？あなたは、「SVNの基本をよりよく理解するために、自分を年配者と見なしているチームメイトを説得したい」と言います。私には、対立があまりにも個人的になっているように思えます。一部の心理学者は、私たちのコミュニケーションの70％が感情レベルにあると主張しています。このレベルが機能していない場合、人々は感情の処理に忙しすぎるため、事実について話すことを止めます。
だから、あなたのポイントを説明する以外に、コミュニケーションを改善するために何かを試みることもできます。コーヒーに招待したり、昼休みを一緒にしたり、仕事に関係のないトピックについて短い会話をしたりすると、コミュニケーションが改善され、同僚に理解してもらいたい重要な事実に注意を向けることができます。彼がこの種のコミュニケーションを受け入れた場合、おそらくあなたがこれまでに抱えていた対立は、あなたがお互いをよく知らず、いくつかの小さな誤解があったという事実に関連していたかもしれませんが、彼はおそらく建設的なコラボレーションを構築することに寛大です。彼が拒否した場合、彼の側にはより深い敵意があるかもしれません。
この場合、役割が明確になるまで待つべきだと思います。あなたのチームメイトが公式にあなたよりも高いランクを持っていない場合、彼は物事を改善しようとするあなたの試みにイライラすることはありません。時間が経つにつれて、彼はそれを受け入れるか、自分がより良く知っていることを見せようとし続けているなら、自分から馬鹿を作らなければなりません。彼がより高いランクを持っている場合、これが議論されていないことを彼に理解させる方法を見つける必要があります。役割が明確になったときに、建設的な提案や批判を受け入れることができない場合、彼は本当に自尊心やそのようなものに何らかの問題を抱えているに違いありません。
したがって、上記のすべての戦略が失敗し、（非常に）不満を感じ続ける場合、私がすべきことはあなたの荷物をまとめてより良い場所を探すことだけだと思います。私は3年前にこの経験をし、今では非常に満足しているはるかに良い会社を見つけました。たぶん、これはあなたの場合ではありません（もちろんそうではないことを願っています）が、この点も理解してみてください。
ちょうど私の2セント。