2

これが私の状況です。svn からチェックアウトしたプロジェクトのローカル コピーがあります。Linuxサーバーで作業しています。私は営業日の初めにチェックアウトを実行し、その後、私と他の人がプロジェクトに含まれるファイル/フォルダーを編集します。一日の終わりに、変更を svn にコミットする必要があります。

コマンドsvn status .を使用して変更を取得してから、新しいファイル/フォルダーと削除されたファイル/フォルダーに対して実行svn add [filename]します。svn delete [filename]

名前が変更されたフォルダーにのみ問題があります。svn でフォルダーの名前を変更する正しい方法は command svn move [from-folder] [to-folder]. しかし、誰かが を使用してフォルダの名前を変更した場合はどうmv [from-folder] [to-folder]でしょうか?

私が行った場合：

svn delete [from-folder]

その後

svn add [to-folder]

「delete コマンド」ではエラーが発生しませんが、「[to-folder] は既にバージョン管理下にある」という「add コマンド」のエラーが発生します。

フォルダの名前が変更されたかどうかを確認するにはどうすればよいですか? どうすれば変更を正しくコミットできますか?

4

2 に答える 2

5

ここにはいくつかの問題があります。

  1. 複数の人が 1 つの作業コピーを共有しています。これは悪い考えです。これを行うと、人々がお互いの変更を踏んだり、コミットする準備ができていないものをコミットしたりするのは簡単すぎます。あなたはすべての説明責任を失いました - 誰が何を変えたのですか? 全員が同じファイルで作業しているため、誰が何をしたかを知ることは不可能です。各ユーザーは、自分のワークステーション (リモート システムで作業する必要がある場合は、自分のホーム ディレクトリ) に自分の作業コピーを持っている必要があります。
  2. 上記の点への補遺: コミット メッセージには、コミットしようとしている変更を行った理由が記述されています。全員が作業コピーを共有していて、1 人だけがコミットしている場合、変更履歴 (「理由」) をどのように記録していますか?
  3. ツールを適切に使用していない人がいます。作業コピーを使用している場合は、すべてsvnサブコマンドで実行する必要があります。完全停止。
  4. あなたは毎日チェックアウトしていますか？適切な Subversion ワークフローでは、その必要はありません。

中心的な質問に答えるには: を使用svn st -uして、ローカルまたはサーバー上の変更を探します。このような問題を防ぐために、頻繁に実行svn updateしてできるだけ早く変更を取得し、ディレクトリ構造の変更を行った後はできるだけ早くコミットすることをお勧めします (他の何かが壊れないことを前提としています)。変化します。

しかし、チーム メンバー間の良好なコミュニケーションとツールの適切な使用に代わるものはありません。

于 2013-03-27T18:29:29.000 に答える
1

svn -u statusは、ローカルとリモートの両方の変更のリストを提供するため、そのような変更があったかどうかを事前に知ることができます。

また、svn はファイルのロック機能を備えているため、チームが他の人の作業を踏まないという合意に達することができない場合、この機能が役立ちます:)。svn lock [[your file]]ロックが盗まれる可能性がありますが、ある程度のセキュリティが得られます。ドキュメントを参照してください:)

于 2013-03-27T17:59:01.193 に答える