ポータブルストレージに基づくバージョン管理?


9

私は、共有サーバーや2つのマシン間のネットワーク接続を使用せずに、2つのマシンで個人プロジェクトを開発しています。

一般的なバージョン管理システムは、共有リポジトリとしてのポータブルストレージ(USBフラッシュデバイスなど)の使用を確実にサポートしていますか?


ポータブルストレージを使用する必要があるのはなぜですか?
Bernard

通常のバージョン管理システムが共有サーバーで行うのと同じ方法で、2つのマシン間でコードを移動します。(私は共有サーバーを持っていません。)
billpg 2012年

私は以前、工場で製造ツールを更新するためにUSBフラッシュドライブ上のMercurialリポジトリのセットを使用していましたが、それは本当にうまくいきました。離れた場所にいる現場の技術者がローカルマシンのコードをいつ変更しているかを確認し、変更をフラッシュドライブに同期する前に変更をマージ(または拒否)することもできます。
マーク・ブース

SVNがローカルストレージをサポートし、USBを使用できることはすでにここで述べられています。しかし、私はそれを自分のプライベートDropBoxフォルダーに格納することを好みます;)また、多くの無料サービス(assemblaやtfs.visualstudio.comなど)を使用することもできます
Pavel Voronin

回答:


31

GitMercurialなどのDVCSを使用します。

分散バージョン管理システムには、共有の中央サーバーはありません。

DVCSを使用すると、リポジトリのすべてのコピーに完全な履歴(すべて)が保持されます。つまり、USBキーで使用した場合、行った変更はUSBキーのリポジトリに対して行われ、コンピュータ間で移動すると、この履歴が保持されます。


9
そして、githubを使用していれば、USBドライブを持ち歩く必要はありません
CamelBlues

ありがとうございました。ポータブルストレージをリポジトリとして使用するように設定できますか?
billpg 2012年

@billpg-はい。それは単にディレクトリ構造に住んでいます。
2012年

@ CamelBlues、bitbucket、kilnhg、またはおそらく適切でない可能性のあるさまざまなその他...
Murph

3
私はメインの個人用MercurialリポジトリをDropBoxに持っています。うまく機能し、自動的にバックアップを実装します(DropBoxがすべてのコンピューターを失うと同時に消えることはないため)。
David Thornley

7

上記のGIT、Mercurialなどとは別に、Fossilも確認してください-ランタイムバイナリが小さく(WindowsとLinuxの場合は1Meg程度)、移植可能でインストールが必要ないという利点があります。したがって、他のものとは異なり(私が知る限り)、ストレージデバイスに配置して、ストレージが接続されている任意のマシンで実行できます。最初にアプリをマシンにインストールする必要はありません。Wikiと、リポジトリの変更/欠陥追跡システムが含まれています。また、GUIが組み込まれています。

私はそれを真剣に使用していません(私はほとんどGITを使用しています)が、その軽量なアプローチに感銘を受け、Wikiと欠陥トラッカーが含まれているため、小規模なプロジェクトに理想的です。私の唯一の懸念は、GITのより強力な機能の一部が実行できない可能性があることでした。GITとは異なり、ユーザーコミュニティはそれほど大きくないため、質問に対する回答を見つけるのは簡単です。


Gitは1つのことを真剣に行うためにUnixの戒律を採用していますが、ticgit(チケットシステム)やgollum(リポジトリベースのwiki)などの拡張機能を使用して、これらの機能をGitに組み込むことができます。
Jason Lewis

@Jason Lewis:あなたは正しい、そしてそれはオープンソースなので、とにかく要件を満たすように変更するだけでよいので、GIT(またはその他のツール)は誰でもすべてになり得ます(気になる可能性があり、時間とリソースに余裕があります) 。ダウンロードには、すべての「プラグイン」をインストールし、デバッグすべて私が言っていたことは、それの価値を考慮化石、「ジャストは、箱から出して動作します」というソリューションです。
mattnz

1

DCVSの使用はおそらく良い考えですが、それが唯一のオプションではありません。

USBサムドライブに小さなCVSリポジトリがあります。アクセスしたいときは、リポジトリのルートのパスを使用cvs -d <path>または設定$CVSROOTするだけです(もちろん、システムにサムドライブをマウントする必要があります)。

すでにCVSを使用することに慣れている場合は、これで問題が解決するはずです。同じことがSVNにも当てはまります。これは、中央リポジトリがサムドライブ上にあり、常に表示されているわけではないことを意味します。

一般に、CVSではなくDCVSを使用することについての議論があります。これらの議論は、中央リポジトリがサムドライブにあるのか他のどこにあるのかによって特に影響を受けるとは思いません。たとえば、サムドライブにgitリポジトリを簡単に作成できます。


1
私は通常DVCSの大ファンではありませんが、この場合はDVCSの方が良いと思います。非分散型VCSの問題は、リポジトリが単一障害点であることです。それは、気候制御のデータセンターに座っていますし、定期的にバックアップされる場合、それは大したことではありません-しかし、サムドライブのようなものがします早く失われた(または踏ん、または犬に食べられ、または白ロシアに落とし込ん)を取得します以降。
Mike Baranczak 2012年

1
@MikeBaranczak:良い点-しかし、CVSリポジトリかどうかにかかわら、サムドライブ上のすべてのものは定期的にバックアップする必要があります。
キース・トンプソン

分散システムでは、各クライアントはすでにリポジトリの完全なコピーを持っています。したがって、個別の「バックアップ」手順を実行する理由はありません。
Mike Baranczak 2012年

1
@MikeBaranczak:もちろん、それはDCVSを使用する正当な理由です。私のポイントは、DCVS対集中システムの選択は、サムドライブを使用しているかどうかに依存しないということです。
Keith Thompson

0

他の回答への追加として:

DVCSはこの問題に非常によく適合しますが、技術的に快適であればSubversionを使用することもできます。Subversionは中央サーバーの代わりにローカルディレクトリを使用できます。それをサムドライブに入れて使用するだけです。

DVCSと比較した場合の欠点は、サムドライブが差し込まれている間のみSubversion(つまり、コミット、ログの表示など)で作業できることです。また、常に同じサムドライブ(または少なくとも-to-dateのコピー)、Subversionでは複数のリポジトリを使用しないでください(これは非分散部分です)。したがって、GitやMercurialとは異なり、サムドライブを忘れた場合は使用できません。

注意:

上記とコメントで説明したように、DVCSは本当に問題に適しています。完全を期すためにSubversionについてのみ触れましたが、Subversionを使用する特別な理由がある場合に備えて。


1
キースの回答と同様に、ローカルディレクトリにあるVCSの問題は、単一障害点であることです。また、マシンAからマシンBに移動し、サムドライブをマシンAに接続したままにしておくと、DVCSを使用しているかどうかを気にする可能性ははるかに低くなります(VCSを使用すると、ローカルの変更を後でマージできます)。 、続行する前に、機械Aに戻ってドライブを取得し、マシンBに戻る必要があります。
マークブース

@MarkBooth:私はこのソリューションを推奨していません。完全を期すため、およびOPにSubversionの特別な設定がある場合に備えて、このソリューションが存在することを指摘したいと思います。これを明確にするために、回答を編集しました。
sleske 2012年

@sleskeに感謝します。svn(または実際にCvs)を優先することで、このソリューションを使用することに有利になる可能性があることに同意しますが、完全な開示のために、そのアプローチの欠点についても言及する必要があります。私のコメントからあなたの答えへのポイントを自由に編集してください。よろしければ、コメントをクリーンアップ(削除)させていただきます。* 8 ')
Mark Booth

この答えが何を言っているのかはよくわかりません。
Keith Thompson

1
@KeithThompson:SVNが中央サーバーの代わりにローカルディレクトリを使用できるという情報を追加します。これはSVNのドキュメントで説明されていますが、ほとんどの人は中央サーバー経由でSVNを使用するため、SVNがサーバーを必要としないことは明らかではないかもしれません。
sleske 2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.