問題タブ [shelving]

/main/ で編集して作成されたチェンジリストをブランチ /dev/branch に移動する方法はあるのでしょうか?

多くのファイルを含む 6 つのチェンジリストがあります。すべてのファイルを棚上げし、ブランチに移動してそこで作業を続けたいと考えています。可能であれば、これを P4V で直接行うことをお勧めします。

2010.2 P4 サーバーで P4V 2011.1 を使用しています。

UserAが Perforce で変更リストを作成し、それを棚上げできるようにしたいと考えています。次に、 UserBがそのチェンジリストの保留を解除してサブミットできるようにしたいと考えています。

これは簡単に聞こえますが、Perforce のシェルフ解除は期待どおりには機能しないようです。UserB が 'p4 unshelve -s 1234' を実行すると、変更 1234 から変更されたすべてのファイルが取り消されますが、変更のメタデータ (説明、ジョブ修正) は取り込まれません! これは、UserB が棚上げされた CL をまったく新しい CL にコピーして送信できることを意味します (説明と修正を手動で再作成することによって) が、古い棚上げされた CL がそのまま残ります。

ここでの論理的なことは、UserBが

1. CL の棚上げを解除する
2. 棚上げされた CL のメタデータを表示する
3. そのメタデータを新しいCLにコピーします。
4. 新しい CL を提出する
5. 古い保留 CL を削除する

これは、Perforce のドキュメントでも推奨されていることです。ちょっとした問題が 1 つあります。UserB は、別のユーザーの保留された CL を削除することはできません! UserA と p4 管理者のみが、保留中の CL を削除できます。ドキュメントがこれを正しく説明していない理由がわかりません。

以前にこの問題が発生したことはありますか? どのように解決しましたか？

編集:私の質問は非常に一般化されていることを明確にする必要があります。UserAが開発者で、UserBがビルド システム自体であるツールに取り組んでいます。開発者は CL を棚上げしてから、ビルド システムの棚上げを解除し、一連のビルドとテストでそれを検証します (これらのすべてのテストに合格した場合、CL を自動的に送信します)。ビルド システムが保留中の CL を提出した場合、すべての開発者が忘れずに CL を削除することを期待するのは、失敗する運命にあるようです!

hg shelve (屋根裏ではない) 拡張機能がインストールされており、パッチをドロップしたいと考えています。git ではgit stash drop. shelve エクステンションを使用してこれを行うにはどうすればよいですか?

私はMercurialに不慣れで、まだ評価プロセスにあるので、これらの4つの概念は私にとってちょっと混乱しています。Gitのステージング/インデックスの概念と同等であると言われているものもあれば、Gitのステージングよりも優れているものもあります。

4つのコマンドhg graft、、、および（および、ただしhg record、これはすでにGraftとTransplantで説明されています）は互いにどのように比較され、キューとdirstateの概念はどのようになりますか？どのユースケースで一方が他方よりも選択されますか？hg qrecordhg shelvehg transplant

それぞれにヘルプページがあることは知っていますが、VCSは一般的に私にとって新しいトピックであるため、それぞれが何をするのかを理解するのは依然として困難です。

コードレビューの主な目的のために、SVNでコードの変更を棚上げしたいと思います。私はいくつかの問題を抱えており、誰かが私が何か間違っているかどうかを確認できることを望んでいました。

この追加の構造を持つようにリポジトリを設定しました：

次に、シェルフを作成するために、作業ディレクトリのルートフォルダを右クリックし、をクリックBranch/Tag...して、正しいパス（たとえば/shelves/username1/MYPROJECT_29012013）を参照し、を選択Working copyして、最後にOK。

シェルフ内のコードを確認するには、にRepo Browser移動し、シェルフブランチを参照して右クリックし、を選択しShow Logます。これにより、下半分にファイルのリストを含むポップアップが表示されます。これらのファイルのいずれかをダブルクリックすると、変更の差分が表示されます。魔法！

これは、自分のマシンで作成した小さなテストリポジトリで完全に機能します。実際のコードベース（リモートリポジトリを使用）では、差分のファイルをダブルクリックするとエラーが発生します。それは言う

私は何か間違ったことをしていますか？それとも、これはバグである可能性がありますか？棚とコ​​ードレビューを実装するためのより良い方法はありますTortoiseSVNか？

編集：このプロセスは、TortoiseSVN 1.7.5（SVN 1.7.3）を使用している同僚にとっては問題なく機能します。TortoiseSVN 1.7.10（SVN 1.7.7）を使用しています。それで、これはおそらくバグですか？または、私のマシンでは設定が異なりますか？

仕事を締めくくっていたので、家に帰る前に TFS での変更を棚上げしたいと思いました。変更内容はすべてディスクに保存され、データベースに対してクエリを書き込むためのスクラッチ パッドとして使用していた SQL クエリ ウィンドウが多数開いていました。

残念ながら、これらのファイルをディスクに保存せずに正当な変更を棚上げすることはできません。また、保存するつもりはありません。これらは、いくつかの SQL クエリをマッシュアップするためのスクラッチ パッドにすぎません。

これに対する回避策はありますか? クエリは保存されず、ソース管理に追加されたこともありません。

私は Mercurial を初めて使用し、git のような変更を隠しておく方法について少し混乱しています。SO を掘り下げたところ、屋根裏拡張機能を使用しているものと、棚拡張機能を使用しているものがあることがわかりました。どちらか一方を使用する必要がある理由はありますか? それらは補完的ですか？

ありがとう...

TFS から Subversion に移行しています。ある同僚は、棚付けができなくなったらとてもがっかりするだろうと述べました。TFS では、一連のファイルを作成して単一の名前で保存することができます。ファイルはリポジトリに保存されますが、HEAD やブランチには保存されません。変更はアーカイブされ、タグ付けされるだけです。

これは、Subversion で一連の変更にタグを付けるのと似ていますが、変更をチェックインする必要はありません。シェルビングは、コード レビュー、変更の安定バージョン (まだチェックインされていない) のチェックポイントの作成、および変更を安全に保つために役立ちます。まだチェックインする準備ができていない場合でも、リポジトリにアクセスできます。

Subversion でこれを行うには、リポジトリ内のコードを分岐し、自分のコードをその分岐にチェックインする必要があるように思えます。変更を破棄する可能性が高い場合、これは非常に面倒です。

私はしばらくマーキュリアルを使用しており、ゆっくりとその機能を学んでいます。少し前に棚の存在を知り、楽しく使っています。現在、パッチ キューを理解しようとしていますが、私が読んだ限りでは、パッチ キューはシェルフに非常に似ているように思えます。実際にコミットせずに作業を保存し、必要に応じてブランチを切り替えて、後で戻ってくることができます。これら2つはどのように異なりますか？

注: 私はこれを見ました: Mercurial: grapht vs. record vs. qrecord vs. shelve vs. transport vs. dirstate vs. queueですが、これに対処していることはわかりませんでした。