問題タブ [bazaar]

化石/bzrを使用するときに「git stash」の動作をエミュレートすることは可能ですか?

基本的に、次のワークフローの処理に興味があります。

• ある時点で、ソース コード ツリーの状態が X になり、コミットされます。
• 新しいコードの作成に進み、しばらく書いて、リファクタリングの機会を見つけます
• この時点ではコミットできません。開始した変更が完了していないためです。まだアトミックではありません。
• この時点で、「git stash」を実行し、現在の作業を保存して、状態 X に戻ります。
• リファクタリングとコミットを行い、ソース コードの状態は Y になりました
• ステート Y のソース コードをスタッシュ内のコードとマージし、変更を完了してアトミックに変更し、もう一度コミットして、ソース コードをステート Z にプッシュします。

「git stash」を実行する代わりに状態 X でコードを分岐し、その分岐でリファクタリングを実行してから、分岐をメインの分岐にマージすることで、別の SCM を使用するときにこのシナリオをエミュレートすることは一般的に可能だと思います。しかし、分岐が必ずしも安価な操作ではないことは承知しています。最終的に化石/bzrの特定の機能に依存するより良い特定のアプローチはありますか?

たとえば、ファイルをからに移動したとし/project/file.csます/project/subdir/file.cs。nautilusがこれを自動的にに変換するといいでしょうbzr mv /project/file.cs /project/subdir/file.cs。これを設定することは可能ですか？

バージョン管理されたファイルで昔ながらのことをしているときに警告されたらいいのですがmv、それは別の質問だと思います。

BazaarにはLaunchpad疑似プロトコル（lp :)があり、ユーザーは完全なLaunchpadの場所を書き込むことなく、リモートブランチで操作できます。私は、次のような方法で独自の疑似プロトコルを作成する方法を探しています（GITと同様）。

...それ以外の...

...それはお尻の痛みです。

bazaar.confについて読みましたが、各ブランチ/リポジトリにグローバルプッシュの場所を設定することしかできないようです。私が見たもう1つの方法は、エイリアスを使用することですが、同じ問題があり、新しいブランチを作成する必要がある場合は非常に醜いです。

BZRコードを変更せずにこれを行うことは可能ですか？これは明らかなはずです...

共有bzrリポジトリをバックアップしようとしています。見てきましたbzr export hotcopy.tgzが、最新のリビジョンのスナップショットしか撮っていないようです。

バックアップを実行するためのコマンドはありますか、それとも実行する必要がありますか

1. tmpディレクトリへのフルチェックアウト
2. tmpディレクトリを圧縮します
3. tmpディレクトリを削除します

または、bzrリポジトリをバックアップするためのより良い方法はありますか？

理解に苦しむbzr init-repo。

独自の分離リポジトリに入れたい 3 つのプロジェクトがあります。subversion では、svnadmin createそれらを作成するために 3 回使用します。このような：

上記は、3 つの分離された Subversion リポジトリを提供します。

3 つの分離された共有 bazaar リポジトリを作成するにはどうすればよいですか?

このようにしますか

それともこうするか

それとも別の方法がありますか？

違いは何だろうか

と

私が知る限り、唯一の違いは次のとおりです。

1. bzr getプル位置を設定します。
2. bzr checkoutプル位置は設定されないため、最初にプルするときに指定する必要があります。

他に違いはありますか？

Specifically, I'm using bzr, but tips for any VCS are welcome.

バージョン管理されていないすべてのファイルを Bazaar ワークスペースから削除するにはどうすればよいですか? hg purge --allorに相当することを探していますgit clean -fd。

bzr pushデフォルトは、プッシュ先の最初のターゲットです。別の場所にプッシュしたいが、毎回手動で入力したくない場合、デフォルトを変更するにはどうすればよいですか?

DVCS で共通ライブラリ ソースをどのように管理しますか?

現在、私のチームは Perforce を使用してソフトウェア プロジェクトを管理しています。Perforce の「ワークスペース マッピング」機能を使用して、共通ライブラリ ソースを開発アプリケーション ディレクトリに簡単にマップし、ソース管理と開発プロジェクト作業の間の変換を透過的に保つことができます。たとえば、リポジトリは次のようになります。

SCMツリー構造

• 根
  • アプリ
    • フォーラムサイト
    • 管理ツール
  • 一般
    • event.logger
    • json.parser
  • デシベル
    • ユーザー
    • サイト構成

優れた P4 マッピング機能により、開発者は、ワークスペース マップを使用して最も理にかなった形式で、作業中のプロジェクトの完全なソース セットを取得できます。典型的な開発プロジェクト フォルダーは次のようになります。

開発プロジェクト フォルダ

開発者が自分のコンポーネントまたはアプリケーションでソースを編集すると、変更は正しいバージョン ポイントの正しいソース管理ディレクトリにマップされます。これは開発者にとって透過的であり、管理の複雑さと新しいプロジェクトを設定する時間を削減します。

Perforce の潜在的な代替手段として、Git、Bazaar、および Mercurial を調査しています。DVCS の世界で一般的なコンポーネント ソースがどのように処理されているかについて、誰か洞察を提供できますか?