例:svn updateリビジョン 10 を使用しているとします。ファイルを追加してコミットを実行すると、svnversion は、リビジョンが混在している状態にあると報告します。つまり10時11分。しかし、これらの番号は順番に並んでいるので、明らかにその間に他のコミットはありません。この混合リビジョン状態を削除するために別の svn update を実行する必要がないので、Subversion はこれから私のバージョンが最新 (=HEAD) であると推測できませんでしたか?
これは大したことではありません。上記の推論が真実ではない可能性がある場合、特別なケースが欠けているのではないかと思います。
あなたの問題を正しく理解していれば、あなたの作業コピーにはほとんどの場合、リビジョンが混在していると言えます。これは、異なるファイルが異なるリビジョンでコミットされ、その後変更されたためです。一部のファイル (たとえば) はリビジョン 10 を示し、他のファイルは 25 を示していますが、まだ HEAD リビジョンにいることに気付きましたか? これは、ワークスペースがファイルとリビジョンの追加のメタデータを保持しているためです。
通常、これはまったく問題にはなりません。私に関する限り、これは SVN ワークフローの一部です。これはSVNドキュメントのどこかに説明されていることを思い出しますが、今は見つけられないようです。その場合は、それに応じて回答を編集します。
Subversion が、変更したファイルがバージョン 11 であると主張していることには、実際には少し驚いています。他の誰かがあなたの前にバージョン 11 をコミットした場合、あなたのファイルは最終的にバージョン 12 以降になります。
その理由は、ローカルのサブバージョンが、ファイルが追加されたバージョンが完全にバージョン 11 であると主張できないためだと思います。