6

私は、顧客固有の小さなアプリケーションを多数作成する会社で働いています。私たちは少数の開発者ですが、ほとんどの場合、プロジェクトごとに 1 人の開発者しかいません。

Customer1
    ProjectX
        App
        Tests
    ProjectY
        App
        Tests
Customer2
    Project2
Products
    Product1
Common

現在、すべてが単一のリポジトリに格納されています。

プロセスは簡単です。

  1. 開発者が顧客のために新しいプロジェクトを引き受ける
  2. プロジェクト用の新しいフォルダーを作成します
  3. 新しいプロジェクトのコード
  4. 別のプロジェクトでメンテナンスを行う
  5. メンテナンス プロジェクトへの更新のチェックイン
  6. 新しいプロジェクトでの作業が増える
  7. 新しいプロジェクトをチェックイン
  8. お客様へお届け

タグ付けも分岐もありません。以前のバージョンは、日付に基づいてチェックアウトされます。

このプロセスは長年にわたってうまく機能してきましたが、現在のツール (CVS) にはいくつかの問題点があります。

  • 遅い。何も変更されていない場合でも、チェックアウトには数分かかります。履歴はサーバーに保存されるため、差分に時間がかかりすぎます
  • 新しいプロジェクトの追加。CVS で作業したことがあれば、次のようなことを知っているでしょう: フォルダーを追加、フォルダーにファイルを追加、次のフォルダーを追加...
  • 明らかなエラー (バイナリのチェックインなど) を取り消す方法がない
  • 必要なリファクタリングをさらに困難にする名前変更のサポートはありません。

私はしばらくの間 Mercurial を個人的に使用してきましたが、それをすべての開発者に拡張したいと考えています。

私はそれをすべて間違っているかもしれませんが、私たちの組織に実装する方法を理解していないことがいくつかあります.

CVS コミットは現在のフォルダーのみですが、mercurial ではリポジトリ全体です。私たちの場合、あるフォルダーでメンテナンス作業をコミットすると、別のフォルダーで未完成のものもコミットされることを意味します。（変更されたフォルダーで実行できると思いhg ci ./**ますが、マージでは許可されていません。少なくともドキュメントにはそう書かれていますIf you are committing the result of a merge, do not provide any filenames or -I/-X filters.）

Mercurial での一般的な方法は、プロジェクトごとに 1 つのリポジトリを持つことです。

プロジェクトごとに 1 つのリポジトリで問題ありませんが、次のような問題が発生します。

中央サーバーで複数のリポジトリを管理する方法は?
開発者が新しいプロジェクトを作成した場合、最終的に変更をプッシュする必要があります。やってるだけ

hg push http://localhost:8000/Customer1/NewProject

醜いスタック ダンプで hg-webserver をクラッシュさせ、クライアントをハングさせます。

私が理解している方法は、開発者がサーバーシェルにアクセスして、新しいリポジトリを構成ファイルに追加し、hgweb を再起動する必要があるということです。

別の方法は、SSH または共有を使用することです (ファイル共有の代わりに SSH を使用する利点はありますか?)

cd Customer\NewProject
hg init
hg clone --noupdate --pull . //mercurialshare\Customer\Project
echo "[paths]" >.hg\hgrc
echo "default=//mercurialshare\Customer\Project" >>.hg\hgrc

hg push

機能しますが、一部の開発者にとっては少し複雑です

すべての開発者は、すべてのプロジェクトを持っている必要があります。
（実際にはすべてではありませんが、多くのプロジェクトがリンクされているため、それらが存在する必要があり、すべてを持っているのが最も簡単です）

多くの既存のプロジェクトと新しいプロジェクトが毎週追加されるため、すべてのプロジェクトを一度にプルし、新しいプロジェクトを複製する方法が必要です。

サブレポが「グローバル」プルを解決できると考えていましたが、ドキュメントの次の行はショーストッパーです

「コミットすると、Mercurial はプロジェクト全体とそのサブリポジトリの状態の一貫したスナップショットを作成しようとします。これは、最初に変更されたすべてのサブリポジトリでコミットを試み、次にすべてのサブリポジトリの状態を記録することによって行われます。」

グローバルコミットの単一リポジトリの問題に戻ります。

(いくつかのバリアントを試してみましたhg ci .hgsub .hgsubstate <subrepo>が、.hgsubstate は完全なコミットでのみ更新されるようです。他のユーザーはhg pull --update、プロジェクト フォルダーに明示的に指定しないと、プロジェクトの変更を確認できません)

私の現在の考えは、すべてのプロジェクトをプルするバッチファイルをルートに置くことです

私たちの組織で水銀を使用する方法について、他に何かアイデアはありますか?

編集

返信いただきありがとうございます。現在、プロジェクトごとに 1 つのリポジトリがどのように機能するかを評価しています。最上位にバッチファイルを置きます 

FOR /F %%x IN (repolist.txt) DO (
    If EXIST .\%%x\.hg (
        ECHO Pull %%x
        hg pull --update --repository .\%%x
    ) ELSE (
        ECHO Clone %%x
        mkdir .\%%x
        hg clone --pull %1\%%x .\%%x
    )
)
4

1 に答える 1

8

Mercurial はリポジトリごとに 1 つのプロジェクト用に設計されていると言うあなたの権利。さまざまなプロジェクトの履歴が別々に保持されるため、このように作業するとさらに便利です。

DVCS リポジトリに複数のプロジェクトを作成しようとすると、苦痛が生じます。

個人的には、HTTP よりも SSH 経由でプロジェクトを提供することを好みます。その理由の1つは、...

# hg init blah
# hg clone blah ssh://server/blah

HTTP 経由でサービスを提供している場合、これは機能しません (ご存じのとおり)。しかし、それがハードクラッシュを引き起こすことに驚いています:-/

すべてのプロジェクトを取得するサブリポジトリの方法は、あなたが説明したとおりではありません。グローバル コミット (プロジェクトは個別に開発できます) に戻ったわけではありませんが、スーパー プロジェクトには、依存するサブプロジェクトのバージョンが格納されています。これは、(たとえば) サブプロジェクトとしてライブラリがあり、リリースが特定のバージョンに依存している場合にまさに必要なものです。事実上、サブリポジトリ リンクは、特定のバージョンの別のリポジトリへのブックマークです。

しかし、実際にはあなたが求めているものではありません。

おそらく、共通のものは、それを必要とするプロジェクトのサブレポにする必要があります。各プロジェクトは、同じコードの異なるバージョンで凍結される可能性がありますが、問題はありません。それは少し考える必要があります。

それ以外の場合は、スクリプトのアイデアがおそらく最も簡単です。

于 2010-11-08T00:21:21.593 に答える