タグ付けされた質問 「cvcs」

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 編集：最近のダウン投票（この時点で+ 8 / -6）を考えると、ガートナーのライフサイクルはプログラマーの観点から偏ったメトリックであることは私に明らかにされました。これは私が経営陣に提示する論文の一部であり、経営陣はガートナーの聴衆の一部です。 DVCSを与える暴露＆熱意を（誇大広告とみなさ、ことが「可能性」というか、少なくともなどの攻撃これを読んだとき）、次の質問を考える：「どのように私はDVCSsの準備ができていることを管理を説得するガートナーのハイプ・サイクルを使用することができます（または準備ができている）、それは単なる誇大広告ではありません」 DVCSsが誇大広告であるかどうかを尋ねるだけでは建設的ではありませんが、ガートナーの誇大広告サイクルは、それを尋ねるよりも客観的な手段です（この手段が偏っているとみなされても）。他の楽器を知っている場合は、ぜひとも言及してください。 編集＃2：Gartnerのライフサイクルはすべてのテクノロジーに対応しているわけではないことに同意しますが、一部の人は誇大広告と見なされるほどの話題を生み出したと考えられるため、少なくともこのツールを使用して、どんな程度でもそれを証明/反証するために。私はDVCS、BTWの擁護者です。 編集＃3：答えてくれてありがとう。バウンティは詳細と実践的なアドバイスで私の質問に答えてカレブに行きます。受け入れられた答えは、別の有用な手段を提供し、私の質問を超えて答えてくれた哲学者に送られます。 会社でDVCSの採用を支持して書いているホワイトペーパーの研究をしていて、社会的証拠の概念につまずいた。DVCS採用の社会的証拠が必ずしも貨物カルトではないことを証明したいので、5段階で技術の成熟度を説明するガートナーの誇大広告サイクルにつまずいた。 私の質問は：誇大広告サイクルの特定の段階での分散バージョン管理システム（一般的にはgit、mercurial、bazaarなど）の現在の場所の指標は何でしょうか？...（その他の（複雑ではない））つまり、DVCSの現在の期待は、a）開始、b）膨張、c）減少（幻滅）、d）増加（啓発）、またはe）安定化（成熟）、および（より重要な）理由であると言いますか？ それは難しい質問であり、主観性が関与していることは知っていますが、特定のフェーズの最も明確な議論/証拠に答え（および従来のクッキー）を付与します。

12 research  dvcs  cvcs 

仮定して： チームは一元化されたバージョン管理を使用しています。 完了までに数日かかる大きな機能に取り組んでいますが、ビルドが中断するため、それより前にコミットすることはできません。 チームメンバーは、作業中のファイルの一部を変更する可能性がある何かを毎日コミットします。 これは一元化されたバージョン管理であるため、ある時点でローカルチェックアウトを更新する必要があります：新しい機能をコミットする直前に少なくとも1回。 コミットの直前に1回だけ更新すると、チームメイトによる他の多くの変更が原因で多くの競合が発生する可能性があり、一度にすべてを解決するのは苦痛の世界になる可能性があります。 または、頻繁に更新することもできますが、毎日解決する競合がいくつかあるとしても、少しずつ簡単に解決できるはずです。 頻繁に更新することを常にお勧めしますか？

9 svn  version-control  cvcs 

CVCSではなくDVCSを使用するという選択は、実際にはリリースサイクルの短縮につながりますか？もしそうなら、何がソフトウェアリリースサイクルをより短くするのですか、そしてこれに対する議論は何ですか？ プルリクエストに関連していますか？パッチの簡単な提出がここで役割を果たしますか？ 人的要因に関連していますか？CVCSを使用するプロジェクトチームは、リリーススケジュールに対してより保守的に機能しますか？ 他の要因はありますか？

8 dvcs  release-management  cvcs 

編集：バウンティがまもなく期限切れになるので、これをさらに明確にします。履歴を（異なるSCMからプルして）Mercurialの特定のブランチに直接インポートする方法はありますか？ 私は現在、Perforceを使用している会社で働いており、Mercurialを使用した分散バージョン管理の方法を作っています。私はperfarceを使用してPerforceの履歴をインポートすることに成功しました（適切な名前です。見たり言うたびに笑ったりします）が、これは一度に1つのブランチでしか機能しません。 P4統合設定の仕組みは次のとおりです。 perforceで「クライアント」を作成します。これは、絶えず更新/チェックアウトする対象の説明の一種です。これは、一度に1つのブランチ（トランクまたはその他）しかアドレス指定できません。 これを実行したら、実行します hg clone p4://<server>/<client_name> .hg / hgrcに移動し、perforceパスの行を追加します。 perforce = p4://<server>/<client_name> Mercurialでコードを正常に処理し、hg pull perforce同期をとって、hg pushチェンジリストをエクスポートします。 私ができることは、ブランチごとにPERFORCEパスを設定し、すべてを同じリポジトリで機能させることです。現在、プッシュは問題ではありませんが、別のブランチから履歴をプルすると、デフォルトのブランチになります。 私は何かをすることができhg pull perforce-R5て、それをmercurialのR5ブランチに着陸させたいと思っています。マージの履歴がなくても、ブランチの履歴を保存できるほど十分に甘いでしょう。 Mercurialを統合できるCVCS用のプラグインは他にもありますが、サブバージョン1には同じ問題があります。 これを行うための簡単な方法はないと思いますが、1つのMercurialマシンでいくつかのフックとスクリプトを使用してプロセスを自動化できれば、それで十分です。 編集：物事を少し明確にするために： PERFORCE トランクはMercurialのデフォルトのブランチにマッピングされています PERFORCE R1ブランチはMercurialのリリース1ブランチにマップする必要があります（R2、R3などでも同じ） Mercurialにperforceからプルするように指示すると（つまりhg pull perforce、「perforce」はPerforceクライアントを指すパスの名前です）、PerforceトランクをMercurialのデフォルトにプルする必要があります。 Mercurialにperforce-R1からプルするように指示すると（つまりhg pull perforce-R1、「perforce-R1」はR1クライアントへのパスです）、Perforce R1ブランチをMercurialの「release-1」ブランチにプルする必要があります。これは私が質問している部分です。

8 mercurial  dvcs  perforce  cvcs