まだSubversionを使用する特定の理由は?[閉まっている]


22

会社のバージョン管理システムを選択したい。これまでのところ、Git、Subversion、Mercurialがあることを知っています。

最近、Gitが最もよく使用されていることがわかりました。そのため、まだSubversionを使用する特別な理由があるのでしょうか、それともGitに直接アクセスする必要があるのでしょうか。


36
両方とも機能します。重要なことは、彼らがあなたの要件を満たすかどうかです。
マシューフリン


11
どの議論でMercurialを除外しますか?
mouviciel

8
主観的な(IMHOをベイトする)言葉遣いと「Gitが最もよく使われていると思う日」-必要な引用。Gitはオープンソースの世界では非常に一般的ですが、企業の分野ではGitは非常まれです。軍団は、単一の中央の権威あるリポジトリのアイデアを本当に気に入っており、変更が非常に遅いです。企業スペースでは、SVNよりも優れたole CVSを見る可能性が高く、DVCSを気にしないでください。
キース

4
@RobinWinslow-SVNはGitとは異なります。状況によってはより適切であり、他の状況ではより適切です。個人的に私はDVCS全般を好み、明らかにGitを好みますが、どちらも主観的な意見です。価値がないわけではありませんが、このようなサイトには属していません。
キース

回答:


46

SVNはまったく死んでいません。まだ非常に広く使用されており、すぐにどこにも行きません。SVNは、特に分散バージョン管理が必要な分散プロジェクトを実際に実行していない場合、分散バージョン管理よりもはるかに簡単に使用できます。

中央リポジトリが1つしかない場合(これまでのところソース管理なしで十分に小さい場合に必要なすべて)、SVNを使用して対話する方がはるかに簡単です。たとえば、SVNを使用すると、1回の操作でリポジトリから変更をプルしたり、ローカルの変更をコミットしたりできますが、HGとGitでは同等の作業を行うために2つまたは3つの手順が必要です。

また、最近の改訂により、SVNは多くのパフォーマンスの問題を修正し、人々がHGとGitを好むようになりました。数年前よりも大幅に高速になりました。この時点では、実際に分散バージョン管理の高度な機能が必要でない限り、プロジェクトのHGまたはGitを検討する正当な理由はありません。


16
私はあなたの推定に完全には同意しませんが、SVNを支持する重要なポイントを1つ追加したいと思います。業界の多くの人々はSVNに満足していますが、それで快適に作業するのに十分なGitを知りません。チーム全体がSVNに慣れている場合、Gitへの切り替えにはかなりのコストがかかる可能性があります。(もちろん、その反対も当てはまります)。
ヨアヒムザウアー

8
できれば、これを何十回も支持します。多くの人が流行に乗っていますが、なぜ分散ソース管理が必要なのか、本当に考えていません。
陶酔

21
@Euphoric:すべてのプロジェクトで常に分散ソース管理が必要な理由を正確に知っています。分岐とマージを単純で、明白で、信頼できるものにするという重要な副作用があります。Subversionは、選択した基本モデルが単純に複雑になるため、分岐を伴うコーナーケースではまだ動きが取れません。
ジャン・ヒューデック

18
分散バージョン管理は「流行」ではありません。同時バージョン管理がファイルロックパラダイムの進化であったように、それはソース管理の進化です。
JesperE

6
@MichaelBorgwardt、私は実際に何度もそれをしました。Subversionを使用するよりもずっと簡単です。すべてがローカルであるという事実は非常に役立ち、「クライアント」と「サーバー」の相互作用を説明する必要はありません。gitまたはhgのワークフローは、はるかに自然で直感的です(履歴編集などの扱いにくい部分から離れる場合)。
SKロジック

19

クライアントツールについてはまだ言及されていません。確かにコマンドラインスクリプトを使用してすべてを実行できますが、GUIを統合すると生産性が大幅に向上します。

私たちは主にVisual Studioと連携しています。IDEへの統合は、現在のGitよりもSVNの方が間違いなく優れています。これは将来変更される可能性がありますが、バージョン管理機能と同じくらいあなたの決定にこれを考慮に入れます。

他のすべてと同じように、バージョン管理システムはそれ自体が目的ではなく、目的地に到達するためのツールにすぎません。状況に応じて、最速でそこに到達するものを選択してください。


これは良い点です。人々がGitをSVNよりも好む理由の1つは、GitのCLIツールが優れているためだと思います。しかし、これはWindows上のTortoiseSVNのような優れたサードパーティSVN GUIで相殺できます。
陶酔

2
これが、Gitを介してMercurial(およびTortoiseHg)を使用した理由の1つです。分散バージョン管理適切なツールおよびIDE統合の利点。
HappyCat

15

私はGitファンです。最近、Gitの欠点の1つは、svnのリリース番号とは反対にハッシュ付きのバージョンを識別することであることを認めなければなりませんでした。リリース番号は、電話などで簡単に伝えることができます。

そして、それが私が想像できる唯一のプロです。その機能に本当に依存したい場合は、分散型および/または集中型のVCS Bazaarで使用できます。Gitには、目的に役立つタグがあります。

とにかく、素早いブランチ切り替えとスタッシングなしで開発することは想像できませんでした。これら2つの機能だけでSVNに勝るものはありませんが、同じ目標を達成するためには、ツリー全体を別々のディレクトリに作成およびチェックアウトする必要があるという同じタスクを覚えています。

いわゆる「分散バージョン管理の高度な機能」には時間が付属しているので、最初からそれらを学ぶ必要はありません。それらを怖がらないでください。邪魔をするのではなく、あなたを助けるためにここにいます。また、DVCSの中央リポジトリを設定するのに問題はありません。


1
これは実際には意味がありません。gitは、曖昧さをなくすためにハッシュの十分な部分のみを必要とします。通常は、ハッシュ全体ではなく、〜6文字で十分です。
TC1

2
実際には、gitハッシュを渡すことはありません。ハッシュの一意のプレフィックスを使用できます。通常は6〜7文字です。
-JesperE

1
@JesperE:はい。ただし、SVNのリリース番号は時間の経過とともに順次増加しますが、Gitのハッシュは、短縮してもランダムになる可能性があります。
キーストンプソン

2

SVNを使用すると、リポジトリの一部をフォルダレベルまで簡単にチェックアウトできますが、gitでは、すべての履歴を含むリポジトリ全体を取得できます。

状況に応じて、これはSVNにいくつかの利点があります。

(これには、フォルダツリー全体に隠された ".svn"ガベージなどの大きな欠点もあります)。


3
注:v1.7以降、.svnガベージはありません-すべてが単一の場所に保存されるようになりました。
gbjbaanb

これは正しくありません-gitでは、履歴なしでファイルのみをチェックアウトできます。また、必要に応じて、リポジトリの一部のみをチェックアウトすることもできます。svnよりも少し複雑ですが、容量はあります。
ベヌバード

2

「6時間で実行できるタスクがある場合、ツールの作成に6時間かかる場合でも、20分でそれを実行するツールを作成する方が良いでしょうか?」

分散バージョン管理は、取り組むべき別の獣です。開発者ごとに十分な学習が必要です。各開発者の学習プロセスに対応するバッファがある場合は、適切な分散バージョン管理システムに移行する必要があります。学習段階が終わると、分散バージョン管理は集中バージョン管理よりもはるかに優れています。

分散バージョン管理は偶然のようです。非常に長い間滞在するためにここにあります。それより早く適応する方が良いです。SVNが新しく、人々がCVSに慣れていて、SVNを使用しないことについて多くの議論が行われたとき、同じ議論を覚えていますが、最終的にSVNは最も人気のあるバージョン管理システムになりました。

会社が既存のバージョン管理システムに多くのソースコードを確立している場合、新しいシステムへの移行は大きな作業ですが、会社が小規模または新興企業の場合、新しいバージョン管理への移行は非常に簡単です。しかし、(新しいセットアップで)古いバージョン管理に固執すると、将来どこかでバージョン管理の移行を計画する必要がある将来のどこかでボトルネックにぶつかります。

多くのプロSVNコメントを見てきましたが、それらはすべて「SVNの方が良い」というよりも「SVNが悪くない」という性質のものである傾向があります。そのため、プロジェクトに分散バージョン管理(Gitなど)を選択することを強くお勧めします。

SVNに対するGITの編集の利点

  1. 専用サーバーは必要ありません 実際、両方ともサーバーなしで使用できます。
  2. ネットワークに接続しなくても開発を継続できます。
  3. ブランチ管理ははるかに簡単です。
  4. BambooなどのCIツールからのより良いサポート

誰かがSVNに固執する理由として、ツール(ビジュアルスタジオ用)に言及しました。http://gitscc.codeplex.com/は、Visual StudioのGITサポートを提供します。


6
SVN 、GitやHgよりもバイナリファイルをより適切に処理します
偽の名前

2
「将来、バージョン管理の移行を計画しなければならない将来のどこかでボトルネックにぶつかります...」申し訳ありませんが、これが今日の移行を行う正当な理由であることに同意できません。私は多くのプロジェクトに取り組んできましたが、このアプローチは必要以上に複雑になり、プロジェクトは将来のメリットを享受するずっと前にキャンセルされます。時には十分、時には十分です。YAGNIに固執し、今日の仕事をしてください。後で移行について心配するのに十分な時間があります。少なくともプロジェクトは残っています。
njr101

2
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.私はこれに完全に同意しません。状況によっては認識される利点があるかもしれませんが、svnのバージョン番号が人間が読み取れるような単純なものは、多くの組織で大きな利点です。
TZHX

1
@apeirogon-それはすべて、リポジトリに配置するものに帰着します。私が仕事をしている主要なリポジトリの1つだけのHEADは11.1 GBです!Git / bzr / hgリポジトリにある場合、おそらく100 GB以上を占有します。
偽の名前

1
もちろん、これは、この特定のリポジトリがPCBファイルと3Dモデルでいっぱいであり、これらはすべてバイナリ形式であり、スペース効率があまり高くないためです。ここでの推奨事項(Electronics.SE、PCB ddesignファイルを保存する人など)は、ソースコードを保存する人の場合とは大きく異なります。
偽の名前

1

当時Subversionを使用する特定の理由がありますか

IDEでのツールのサポートは別として(私は使用していません)、そうでもありません。もちろん、SVNはより親しみやすいかもしれませんが、それが唯一の理由であり、HgとGitの両方を非常に簡単に(そして非常に高速に)学ぶことができました。

はい、ブランチがヒルベルト空間の部分多様体をマッピングする単なる同相内在関数であると理解すると、Gitがいかに簡単であるかを説明する複雑なガイドがすべてあります。1

分かりません。しかし、あなたは何を知っていますか?関係ありません。Gitを使用するために、これらのことを知る必要はありません。

ほとんどの場合、GitとHgは使いやすく、SVNよりも明確な利点があります。部屋の象はもちろん枝分かれしています。枝はGitとHgで動作します。それとは対照的に、SVNでは、せいぜい痛みがあり、最悪の場合は破損します(複数のヘッドのマージ)。

もちろん、まだSVNを使用できます。Windows XPを引き続き使用することもできます。ただし、両方を試したユーザーの大多数は、代替案の1つが非常に優れていることに同意します。


1はい、これは冗談だとわかります。おもう。


ヒルベルト空間の部分多様体を写像する同相内体関数を持つGitチュートリアル?私はそれを読む必要があります!しかし、これはむしろ、Haskellで書かれており(これはエンドファンクター呼んでいます)、量子力学に触発された(したがって、ヒルベルト空間)Darcsには当てはまりませんか?GitとHGがこれらのことと何の関係があるのか​​、本当にわかりません。
左辺約

@leftaroundaboutそれは冗談です。説明は正確ではありません(私の知る限り)。「gitブランチは簡単に理解できたら…」で始まる多くのチュートリアルのリフであり、その後に複雑なドメイン固有のメタファーがあります。
コンラッドルドルフ

1
これらの過度に複雑なチュートリアルはすべて、理由があると考えたことがありますか?とにかく何のためですか?DVCSの群衆が分岐し、それから小さなことごとに分岐を再統合することに執着していることを理解したことはありません。それは常に問題を探す解決策のように感じられます。SVNでブランチを再統合するのは難しいです。それそもそも非常に愚かで概念的に間違っていることです。非常に説得力があります。
メイソンウィーラー

1
複数の変更を並行して処理することに関しては、少し苦痛ですが、適切な解決策は棚上げであり、次のSVNリリースで計画されています。そしてほとんどの場合、同時に複数の変更に取り組んでいる場合(特に一貫してそれを行っている場合!)、それは組織レベルで対処する必要のあるより広い問題の証拠であり、新しいツール。(上記を参照してください。「当社の製品により、間違ったことが非常に簡単になります」と、ジョエルのヒューマンタスクスイッチングに関する古典的な記事。)
Mason Wheeler

3
@KonradRudolphブランチをトランクにマージすることは、SVNの最新バージョンではうまく機能します。それは数年前から着実に良くなっており、今では非常に良い状態になっています。
アダムブルース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.