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

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

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

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

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

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

1
あなたはロックを使用していますか?
追加された 著者 Josh Lee,
あなたのニーズを満たすことができる多くのDVCSソリューションがあります。 SVNが好きだが、.svnディレクトリが嫌いな人は、SVN 1.7をルートの単一の.svnディレクトリに移動しましたか?
追加された 著者 AlG,
@ジョシュ。いいえ、私たちはしませんでした。私は私たちがサーバー上に持っていたSVNのバージョンを今確信していません。しかし、それは働いた。私たちは主に、マーケティングチームとレビューチームの間のマーケティング担保作成およびレビューにこのツールを使用しました。
追加された 著者 Blake K Peterson,
@AI。 WOW ... 1.7の.svnフォルダを調べると、問題が解決します:)
追加された 著者 Blake K Peterson,

5 答え

あなたはここのことを考えている。おそらく、ソースコントロールソリューションは必要ありません。あなたの従業員が .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 のリストがあります。私はそれらのいずれかを保証することはできませんが、おそらく一見価値があります。

1
追加された
ありがとうございます - 私はいつかdropboxについて知っていますが、おそらくもっと良いオープンソースのソリューションがあると思っています。私はSugarSyncについて聞いたことがありません。私はそれを見てdefします。 :)
追加された 著者 Blake K Peterson,

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

See Working Copy Metadata Storage Improvements

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

1
追加された
なぜdownvote?
追加された 著者 RedFilter,
@ブレイク:不明...
追加された 著者 RedFilter,
ありがとう! - 私は推測するSVNに戻って:)
追加された 著者 Blake K Peterson,
@redFilter ...誰によって?
追加された 著者 Blake K Peterson,

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

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

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

0
追加された
ありがとう!はい - それはSVN 1.7のソリューションだと思われます。
追加された 著者 Blake K Peterson,

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

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

0
追加された
うん、それはsvnからの主要な引っ張りだった。
追加された 著者 Blake K Peterson,

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

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

0
追加された
FSとoneliner "copy src dst"の変更を監視するためのFAMモジュールは、このように、ほぼリアルタイムで動作します
追加された 著者 Lazy Badger,
ええ、ケースになりそう:)あなたのコメントありがとうございます。私はもともと、もともと過労について考えました。しかし、私たちはライブ・プロダクション・ファイルで1つのディレクトリを使用し、cronを使用してこれらをWebサイト上のフォルダにチェックアウトしました。これは、ウェブサイトの画像や担保を最新の状態に保つのに最適な解決策でした。
追加された 著者 Blake K Peterson,