SVNは時代遅れですか?[閉まっている]


9

Visual Source SafeからSVNに移行してから数年しか経っていません。そして、私にとってのSVNはまだ「WOW!たくさんのことができます!SVNはとてもクールです!」

しかし、私の周りの多くの人々は、「SVN?本当に?私は...」と言い続けます。

そしてそれらの多くが私が心配しているほどたくさんあります。私のチームをGit / Mercurialまたは他の素晴らしいものに移動する必要がありますか?私はばかげているように聞こえますが、明白な答えは「あなたのために働くものにとどまる」でしょう。SVNは私のために機能します...しかし、リポジトリに新しいプロジェクトを作成するたびに、私は自分自身に尋ね続けます-これが移動する時でしたか?

それで... SVNは本当にそんなに悪いのですか?それに固執することで大きなチャンスを逃しませんか?


これは興味深い読みかもしれません:stackoverflow.com/questions/161541/svn-vs-git
fouronnes

あなたはスタンドアロンの開発者ですか?
TeaDrinkingGeek

6
私はいつもGITを使いました。今、私は仕事でSVNを使わなければなりません... ... ... ... ... ... ... ... RAGE。
Ivo Wetzel

@TeaDrinkingGeek:OPは「チームを移動する必要がありますか?」 )。
FrustratedWithFormsDesigner

笑すみません、ラップトップで12時間後、目が少しぼやけています。:)
TeaDrinkingGeek

回答:


8

それは完全に使用法に依存します。

部屋に1つのチームのチームがいて、彼らがそこでほとんどの作業を行う場合、すでに好きなビルドおよびデプロイプロセスがあり、コードを広く人々と共有することを望んでいない場合(オープンソースプロジェクト)、それからあなたはそれを発汗するべきではありません。

おそらく1年前にSubversionからgitに切り替えました。そのほとんどローカルなユースケースにもGitは完全に適切ですが、それが本当に優れているのは分散開発です。ローカルで使用する場合は、githubをリモートバックアップとして使用し、コードへのかなりのウェブインターフェースを使用すると便利です。これにより、請負業者が簡単に参加できるようになります。しかし、Subversionから取得していなかったので、今はあまり効果がありません。


8

絶え間ない誇大広告の流れに流されないでください。あなたは機能するものを持っています、何か他のものでよりよく満たされるビジネス要件があるまでそれを使い続けます現在使用しているものよりも優れたビジネス要件を満たすために)。

SVNがあなたの組織で機能するのであれば、何かに移動するために必要なお金/時間/労力を投資する理由はありません。

いいえ、それは(JBKが考えているように)「チーム」次第である決定ではなく、すべての関係者(少なくともシステム管理者を含む)と相談した後の管理次第です。技術スタックではなく、テクノロジースタックの変更にお金をかけるのはビジネス上の決定です。


できれば100万回賛成します。
HLGEM

5

私は無知から決断を下すべきではないと思います。何が不足しているのかわからない場合は、十分な時間をかけてgit outを試してみてください。分散制御へのジャンプは、実際に試してみたり、古い習慣を手放したりせずに理解することはできません。DVCSのほとんどの機能は、必要な理由にかかわらず、必要な数のブランチを作成できることです。1か月試してみて、少なくとも5つのブランチを作成していない場合は、独自の条件でテストしていません。これは、gitを「取得」しないほとんどの人の間違いです。その後、svnに戻ると、少なくとも自分の理由がわかります。


5
私はほとんどの決定を相対的な無知から行うことに強く賛成です。あなたは彼がgitを試すのに1ヶ月かかることを勧めます。それは本当の仕事です。彼はそれが彼の状況をはるかに良くすると信じる何らかの理由がある場合にのみそれをするべきです。それ以外の場合は、おそらく彼が1か月の実験に費やすべき何かがあるでしょう。たとえば、redis、mongo、rails、node.js、BDDなど、同じようにホットな新しいものがあります。
William Pietri 2011年

しかし、Git 非常に新しいものです。そして、多くのGitユーザーの経験は、それ彼の状況をより良くすること示唆しています。
キラレッサ2011

3

私はGitを使用していませんが、Mercurialを使用しましたが、何が重要なのか本当にわかりません。チェックインやチェックアウトなどの基本的なものがより複雑であることを除いて、SVNによく似ています(1つではなく2つのステップが必要です)。見返りに、私が実際にはるかに単純にするために必要とすることのなかった、より高度なものをたくさん作ることになっています。DVCSが本質的に優れているという主張に対する私の反応は、基本的に、「OK、確かに、私はあなたの言葉を採用します」であり、私はSVNを続行します。


DVCSの大きな問題は、すべての作業を「オフライン」で行えることです。その1つの機能により、DVCSには、リベースとブランチを処理できる強力なマージメカニズムが必要になります。集中型VCSでは簡単に実行できない種類のタスク。人々が主張する優越性は、技術的な優越性ではなく、有効化されたワークフローに由来します。そのようなワークフローを使用しない、または必要としない場合も、それで問題ありません。
greyfade 2011年

1
これは、DVCSにチェックインとチェックアウトが存在しないためです。hgを本来の方法で使用するのではなく、hgをSVNの代わりとして使用しています。同じことがすべてのDVCSに適用されます。
代替

@Mathepic:必要に応じて名前を変更できますが、ローカルの作業用コピーと公式リポジトリの間でデータを転送するという基本的な概念は、どのソース管理システムにも存在します。
メイソンウィーラー

1
いいえ、違います。DVCSにはそのような操作はありません。
代替

3
はい、あります。「マスター」バージョンをプッシュする中央リポジトリのポイントは、バックアップ、ビルドサーバー、リリース管理、またはチーム間でよりよく調整するための非常に有効なユースケースです。
gbjbaanb

-2

ここでの明白な答えは、チームが誰もにとって最良の選択肢は何かを決定して話し合うようにすることです。対処すべきさまざまな意見や懸念があるかもしれませんが、何を使用するかについて独裁的であるようにするのではなく、コンセンサスの回答を求めることをお勧めします。


3
あるソース管理システムから別のソース管理システムに変更する際の工数のコストや、新しいシステムの初心者が既存のコードの変換を間違えた場合にプロセスで物事を失うリスクについて何か考えがありますか?これはチームの決定ではありません。これはビジネス上の決定であり、現在のシステムでは対応できない実際のニーズがある場合にのみ実行してください。
HLGEM
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.