企業ファイルリポジトリにGITを使用する必要がありますか？

Question

企業ファイルリポジトリにGITを使用する必要がありますか？

私たちには、同じファイルを共有する必要がある世界中の多くのリモートワーカーがいます（追加と編集を含む）。

私たちは過去にSVNを使って素晴らしい結果を出しました。

私たちが持っていた最大のSVNリポジトリの1つは17GBでした。サイズは決して問題ではありませんでした。主にバイナリファイルがありました。

しかし、欠点は、SVNが各フォルダに隠れたフォルダを格納することはあまりにユーザーフレンドリーではないということでした。（ユーザーがフォルダをコピー＆ペーストするときはEsp）。

Gitはこれを解決するようです。質問は私がGitを使うべきか、SVNに固執すべきか、それとも私がまだ出会っていない他のオープンソースツールがあるのでしょうか？

1

追加された 27 10月 2011 〜で 09:57 著者 Blake K Peterson

ビュー: 8

源

ro ru fr es pt de hi bn ar kk tr

あなたはロックを使用していますか？

追加された 27 10月 2011 〜で 09:58, 著者 Josh Lee, 源

あなたのニーズを満たすことができる多くのDVCSソリューションがあります。 SVNが好きだが、.svnディレクトリが嫌いな人は、SVN 1.7をルートの単一の.svnディレクトリに移動しましたか？

追加された 27 10月 2011 〜で 10:00, 著者 AlG, 源

@ジョシュ。いいえ、私たちはしませんでした。私は私たちがサーバー上に持っていたSVNのバージョンを今確信していません。しかし、それは働いた。私たちは主に、マーケティングチームとレビューチームの間のマーケティング担保作成およびレビューにこのツールを使用しました。

追加された 28 10月 2011 〜で 01:40, 著者 Blake K Peterson, 源

@AI。 WOW ... 1.7の.svnフォルダを調べると、問題が解決します:)

追加された 28 10月 2011 〜で 01:41, 著者 Blake K Peterson, 源

5 答え

懸念している主な欠点が多くの.svn隠しフォルダである場合、これはもはやv1.7のケースではありません。

See Working Copy Metadata Storage Improvements

Subversion 1.7で導入された変更点の重要な特徴は、作業コピー・メタデータ・ストレージの単一化への集中ロケーション。 .svnディレクトリ内のすべてのディレクトリに.svnディレクトリ作業コピー、Subversion 1.7作業コピーには1つの.svn ディレクトリ - 作業コピーのルートにあります。このディレクトリには（とりわけ）SQLiteでバックアップされたデータベースで、その作業コピーに対してメタデータSubversionが必要です。

1

追加された 27 10月 2011 〜で 10:00 著者 RedFilter

源

なぜdownvote？

追加された 28 10月 2011 〜で 09:09, 著者 RedFilter, 源

@ブレイク：不明...

追加された 29 10月 2011 〜で 06:20, 著者 RedFilter, 源

ありがとう！ - 私は推測するSVNに戻って:)

追加された 28 10月 2011 〜で 01:41, 著者 Blake K Peterson, 源

@redFilter ...誰によって？

追加された 29 10月 2011 〜で 12:26, 著者 Blake K Peterson, 源

著者 David W. · Answer 1 · 2011-10-27T11:32Z

あなたはここのことを考えている。おそらく、ソースコントロールソリューションは必要ありません。あなたの従業員が .svn ファイルで混乱していると、彼らはGitと混同されます。

可能な解決策は、 Dropbox です。 DropboxはDropboxと呼ばれるフォルダをLinux、Unix、Macの$ HOMEディレクトリの下、またはWindowsのMy Documentsフォルダの下に置きます。そこに置かれたファイルは、Dropboxサーバーに同期されます。

別のコンピュータに移動して同じDropboxアカウントを共有すると、すべてのファイルもそこに保存されます。 Dropboxは、Linux、Windows、およびMacで動作します。

すべてDropboxアカウントを持っている場合は、それらのアカウント間に共有フォルダを作成できます。そのように複数の人の間でフォルダを共有することができます。 Dropboxにはいくつかのバージョン管理メカニズムがあります。以前のファイルのコピーを取り戻すことができるので、変更が気に入らなければ元に戻すことができます。削除されたバージョンを取得することもできます。

Dropboxは2GBのデータは無料で、支払いを希望する場合はさらにスペースを取ることができます。私はこの種の状況にDropboxを使用しており、2Gbアカウントでは通常十分です。

SugarSync のような他の同様のサービスがありますが、私はDropboxの絶対的な単純さが好きです。これは技術者以外のユーザーには効果的です。

David Pogueはちょうどいくつかの記事を書きました数週間前。

私は自分の仕事を大幅に簡素化したことが分かっているユーザー以外は、Dropboxと何ら関係がありません。

Dropbox Alternatives のリストがあります。私はそれらのいずれかを保証することはできませんが、おそらく一見価値があります。

著者 Mark Longair · Answer 2 · 2011-10-27T10:12Z

17ギガバイトはgitリポジトリ ¹ のために非常に大きいでしょう。そしてあなたは経験を耐えられるように設定設定オプションを注意する必要があります。

大量のバイナリファイルをバージョニングするというユースケースは、少数の領域の1つで、代わりにSubversionを使用するのが妥当だと思いますgitまたはMercurialの

^{1
_{サイズが数百ギガバイト（バックアップ目的）のgitリポジトリを1つ使用しますが、これはあいまいなスポーツです。}}

著者 Basile Starynkevitch · Answer 3 · 2011-10-27T10:00Z

Gitは内部の .git ディレクトリをリポジトリの一番上のディレクトリに保存します。

私がGitで見つけた主な利点は、すべての履歴がローカルで利用できることと、巨大なの違いを作り出すラップトップのためです。

0

追加された 27 10月 2011 〜で 10:00 著者 Basile Starynkevitch

源

うん、それはsvnからの主要な引っ張りだった。

追加された 28 10月 2011 〜で 01:39, 著者 Blake K Peterson, 源

著者 Lazy Badger · Answer 4 · 2011-10-27T10:24Z

共有ファイルストレージとしてのみVCSを使用している場合、これはそのようなタスクには不合理です。また、SCMのほとんどはバイナリファイルを扱いにくいです。ほとんどの場合、バイナリ（特にバイナリ用）のリビジョン履歴

再開 - 私はGitに移動する理由を見ることができません（そしてSVNを使用しても通常のWebDAVの場所で十分かもしれません）

0

追加された 27 10月 2011 〜で 10:24 著者 Lazy Badger

源

FSとoneliner "copy src dst"の変更を監視するためのFAMモジュールは、このように、ほぼリアルタイムで動作します

追加された 28 10月 2011 〜で 03:06, 著者 Lazy Badger, 源

ええ、ケースになりそう:)あなたのコメントありがとうございます。私はもともと、もともと過労について考えました。しかし、私たちはライブ・プロダクション・ファイルで1つのディレクトリを使用し、cronを使用してこれらをWebサイト上のフォルダにチェックアウトしました。これは、ウェブサイトの画像や担保を最新の状態に保つのに最適な解決策でした。

追加された 28 10月 2011 〜で 01:43, 著者 Blake K Peterson, 源