問題タブ [revision]

tortoiseSVN は初めてです - リビジョンから head を更新する最良の方法は何ですか?

私はオフラインです (正確には、現在、私の svn リポジトリにアクセスできません) が、私が作業している本格的な作業コピーがあります :-)

ここで、ファイルのリビジョン番号を知る必要があります。svn:keywordsオフライン中に特定のファイルのリビジョン番号を確認するにはどうすればよいですか (ちなみにプロパティはありません)。

svn ls -v私は通常、またはsvn log | headまたはでそれらをチェックしますsvn blame（もちろん、現在探している以上のものを提供します）。

ドキュメントの特定のリビジョンを取得できることを知っています

ただし、これはリビジョン番号2-3696048776を知っていることを前提としています。ドキュメント626b345059c2a54fbe8b8009ba87a409の利用可能なすべてのリビジョンを一覧表示するにはどうすればよいですか?

同じ SVN リビジョンで複数の Team-City ビルド プロジェクトを実行したいと考えています。これは可能ですか？

ユーザーがドキュメントに変更を加えることができるPHPアプリケーションがある場合、各ドキュメントのリビジョン追跡を実装するための最良の方法は何ですか？svnや他のSCMがコードで行うように、各リビジョンのストレージを削除する（つまり、行われた変更のみを保存する）ようにします。私はそれがどのように機能するかを非常に単純なレベルで知っていますが、それを実装することを考え始めると、少し混乱します。

何よりもまず、これを支援してくれるライブラリがそこにあるのだろうかと思っているので、自分で完全にロールする必要はありません。

そして、私は疑問に思っています：元のドキュメントの全文だけを保持してから変更のみを保存するのか、それとも最新のドキュメントの全文を保持し、変更するたびに違いを1つとして保存するのか古いリビジョン？

前者の場合、サイトに表示されるページを取得するときに、最初から始めて、現在のバージョンに到達するまで、リビジョンに基づいてデータを再帰的に更新する必要がありますか？多くの改訂があると、これは痛々しいほど遅くなりませんか？

PHPでdiff/patchタイプの操作を実行して、ページの削除と再構築を簡単にするにはどうすればよいですか？

彼らがそれらを編集しているときにページをロックすることは価値がありますか？または、ページを「競合の状態」にして、競合解決操作を実行します。2人のユーザーが異なる部分を変更する場合など、同じページを同時に変更できるようにします。これがどれほど難しいかを考えると、頭がおかしくなります。ああ！

投稿やその他のコンテンツのリビジョン システムをセットアップする方法を理解しようとしています。これは、基本的な belongs_to/has_one/has_many/has_many_through ORM で動作する必要があることを意味すると考えました (優れた ORM はこれをサポートする必要があります)。

私は（モデルが一致する）ようないくつかのテーブルを持つことができると考えていました

リビジョンテーブルを介して参加して、最新の TEXT 本文を取得できる場所。しかし、私はそれがすべてどのように機能するかについて少しぼんやりしています。誰かがこのようなものをセットアップしましたか？

基本的に、記事を読み込んで最新のコンテンツ エントリをリクエストできる必要があります。

以前のリビジョンにさかのぼり、リビジョンを削除する機能も大きな助けになるでしょう。

いずれにせよ、これらは、ある種の履歴追跡がどのように機能すると私が考えるかについてのアイデアにすぎません。私は、ベストプラクティスが何であるかを知りたいだけです。

：編集：

今後は、2 つのテーブルが最も理にかなっているようです。テキストのコピーを 2 つ保存する予定なので、スペースの節約にもなります。最初のテーブルpostsには、結合なしで高速に読み取るための現在のリビジョンのデータが格納されます。投稿bodyは、一致するリビジョンのtextフィールドの値になりますが、markdown/bbcode/tidy/etc によって処理されます。これにより、元のテキストを 1 つのリビジョン行に 2 回保存する (または表示するたびに再解析する) ことなく、(次の編集のために) 元のテキストを保持できます。

したがって、フェッチは ORM フレンドリーになります。次に、作成/更新のために、リビジョンを個別に処理し、新しい現在のリビジョン値で投稿オブジェクトを更新する必要があります。

バックグラウンド

私はハードウェア開発エンジニアリングのバックグラウンドを持っています。私たちの詳細な仕様は、ドキュメント (通常は MS Word) の最後または最初に表として改訂履歴が含まれていました。これらの仕様は、回路図や基板レイアウト ファイルなどのハードウェア設計成果物を保存するために使用される管理システムとは別のドキュメント管理システムに保存されました。ドキュメント管理システムが仕様に使用されず、代わりにファイル名にドキュメントのリビジョン番号が含まれている場合がありました。これは、誰かがダウンレベルのリビジョンでドキュメントを変更し始めることを考えると、最適ではない解決策のように常に感じていました。

質問

DVCS (Git) を使用するソフトウェア プロジェクトの作業を開始しました。MS Word ドキュメントの代わりに、Markdown を使用して仕様/ドキュメントをテキスト ファイルとして作成する予定です。仕様やユーザー ドキュメントなど、すべてを DVCS に含めるというアイデアが気に入っています。ただし、仕様とドキュメントを実際のコードと同じリポジトリに保存するべきではないようです。これは私の質問に私を導きます：

1. 仕様/ドキュメントはコードとは別のリポジトリに保存する必要がありますか?
2. 仕様/ドキュメントごとに個別のリポジトリが必要ですか?
3. ソフトウェア エンジニア/コーダーは、通常、DVCS が改訂履歴を持つ機能を提供することを考えると、仕様とドキュメントに改訂履歴を記録しますか?

Git-1.6.5.1-preview20091022.exeを使用しています。

以下を使用してSubVersionリポジトリのクローンを作成しました。

SubProjectAには、標準のレイアウト（トランク、ブランチ、タグ）があります。SubProjectAは別のプロジェクトのコピーです。所有している場合、60のリビジョンしかありません。コマンドの後に、SubProjectAという名前のフォルダーが作成され、ブランチとしてリモート/トランクのみが含まれます。マスターブランチも存在しません。

その後、実行する必要があります

SubVersionからすべてのリビジョンを取得するために複数回。fetchコマンドが実行されるたびに、一度に1つのリビジョンのみがフェッチされます。

私はもう試した：

成功しませんでした（SubProjectAはリビジョン2390でコピーされ、リビジョン2420で作成されたSubProjectAのブランチが1つあり、最新のリビジョンは2450です）。

フェッチコマンドが一度に1つのリビジョンのみをフェッチする原因となったのはどうすればよいですか？すべてのリビジョンを取得するようにフェッチに指示するにはどうすればよいですか？

ローカルの変更が存在するかどうかをスクリプトで確認するにはどうすればよいですか？おそらくと組み合わせてgit describe？

データベース内のデータのリビジョン管理を作成しています。リビジョン、ロールバック、およびロールバック ロールバックを保存する機能があります。私が使用している、修正が必要なデータベース テーブルは次のとおりです。

オブジェクト
object_chunks
object_attributes

オブジェクトは主要なオブジェクトであり、チャンクはオブジェクトのセクションをグループ化したものであり、属性はチャンク内のデータの属性です。属性はオブジェクト ID をチャンク ID と一緒に保存します。オブジェクトのすべての属性を選択するのは簡単で、チャンク テーブルに対して別の JOIN を実行する必要はありません。

実際に変更されるのは属性だけですが、属性が変更されると、影響を受けるチャンクが更新され、チャンクが更新されるたびにオブジェクトも更新されます。今、私はこの問題を解決する 2 つの異なる方法を考えました。

1. _rev のサフィックスを持つ 3 つの新しいテーブルを作成します。これらのテーブルは、オブジェクトの古いバージョンを格納するだけです。実際のオブジェクトには、rev 番号も格納されます。つまり、3 つの異なる属性を変更したとしましょう。これらの属性は 3 つのチャンクにまたがっており、チャンクに 3 つの新しい行、属性に 3 つ、リビジョン用のオブジェクトに 1 つの新しい行が含まれています。これは最初の変更であるため、rev ID は 1 になり、実際のテーブルでは rev は 2 になります。
2. 上記を単純に実行しますが、別のテーブルを作成する代わりに、単純に同じテーブルに格納します。

注意すべきことの 1 つは、常に改訂があり、チャンクの量は 1 から 100+ まで変化する可能性があることです。平均は約1〜15ですが。属性は 0 から 100+ まで変化します。平均はおそらく 30 前後です。すべての属性が変更されます。これらのオブジェクトは、ユーザーがすべての属性を入力する必要がある「フェーズ」を通過します。それらがいっぱいになると、オブジェクトはアーカイブされ、二度と変更されることはありません。すべてのオブジェクトには、対応するファイルがあります。そのため、オブジェクトはファイルの現在のハッシュ (sha256) も格納します。このハッシュは、重複排除の目的で使用されます。