開発者がVSSを希望する場合、VSSの使用を許可する必要がありますか?


14

私は自分の部署にMercurialを紹介しました。私はそれが大好きですが、それは私の最初のバージョン管理の経験です。Web開発用にNetBeans PHPで使用しています。

社内のアプリケーションで作業する別の開発者は、Visual Source Safeの使用を好み、切り替えたくないと考えています。彼はVisual Studio環境で働いています。

他のすべての開発者は、これを除いてMercurialに買収しました。しかし、ほとんどの場合、私たちは皆独立して仕事をしています。

私はこの部門を正しい方向に動かそうとしています。Kilnのアカウントで全員を設定しました。Fogbugzを使用しているすべての人にも道を譲りたいと思っていました(現在、バグデータベースが維持されていないため) VSSを使用したことはありませんが、非常に悪いことを聞いています。

それが彼が好むものであるなら、彼にVSSの使用を続けることを許可するほうが良いでしょうか、それともMercurialで彼を乗せるのが最善の利益でしょうか?


stackoverflow.com/questions/961878/…面白いかもしれません。

自分のプライベートVCSを使用している開発者の1人は、コードが適切にバックアップされていない1人の開発者に危険なほど近づいています。Mercurialリポジトリのバックアップ(オフサイト!)を行っていると思います。それはあなたの一人を除いてすべてをカバーします。VSSリポジトリについても同じことをしていますか?これらのバックアップで何か問題が発生した場合、誰かが気づくでしょうか?など
デロバート

8
プログラミングのために便座に座り、残りの従業員が椅子を使用したい開発者のようです。
ムハンマドハサンカーン


1
落ち着いた人々( '-')VSSはそれほど悪くない!私はVSSから始めました。私はもはやVSSを使用していませんが、人々がそれを作るほど悪くはありません(どちらも素晴らしいことではありません)。思想私はバランスのいくつかの種類...置く
Darknight

回答:


50

それが彼が好むものであれば、単に彼がVSSを使用し続けることを許可する方が良いでしょうか

いいえ。2つの異なるソース管理システムを並行して実行しても意味がありません。これは、すべての開発者が同じリポジトリに接続しており、それを最大限に活用しているという考えに反します。

異なるシステムを単独で使用する単一の開発者は、チームから効果的に隔離されます。プロジェクトが交差しなくても、それはまだ悪いことです。

ここでは、両方のシステムのメンテナンス作業を2倍にすることも別の議論です。

権限を使用するか、問題を管理者にエスカレートして、VSSからMercurialにコンテンツをすばやく移行し、VSSをシャットダウンする必要があると思います。

PS VSSといえば、チェックインを失うことや、予期しないときにコードに損害を与えることで有名です。それは動作しますが、定期的に神経に行きます。より良い代替手段がある場合は、VSSを避けてください。


42
NOBODYはどのような状況でもVSSを使用する必要があります。名前は嘘です。VSSには安全なものはありません。
CaffGeek

17
これに同意し、学んだことを追加したいと思います。VSSを使用しても、VSSを使用しないことの大きな利点によってすぐに相殺されない利点はありません。
ベンホフシュタイン

+1ありがとう、それも私が考えていたことであり、私はそれを発行する前に他の人の意見を求めていました。
JDアイザックス

2
@Ben:します、そして人々が「Who's Hoffstein?」私は彼らを
glみ

2
チームがSourceSafeまたはTFSまたはSVNを使用しており、不正な開発者がGitまたはMercurialを使用している場合、同じ答えをしますか?
キラレッサ

16

不正な開発者が他のチームとは異なるソース管理システムを使用することを許可することは決して考えません。

ソース管理は、自分がやったことの以前のバージョンを見つけることができるだけでなく、他の人がそれら(および現在のバージョン)を見つけることもできます。これは交渉不可能です。彼がバスを離れたり、バスにひかれたりして、他の誰も自分のコードにアクセスできない場合はどうなりますか?

他の誰もVSSを使用していないため、彼のソース管理コードは自分のマシン上にのみ存在する可能性があると仮定しています)彼はあなたの残りの人に見てほしいと思わないのですか?

また、VSSはバグで有名です。彼のコードはそこでも安全ではありません。


10

誰もVSSを使用して始めてはいけません。

開発者にVisual StudioのMercurialプラグインを入手するように伝えます。


このプラグインの経験はありますか?

私はそれを使用しました-それはうまく動作します。
MetalMikester

@ThorbjørnRavn Andersen:いいえ。職場では転覆を使用しています。
ディマ

1
説明がなければ、他の誰かが反対意見を投稿した場合、この答えは役に立たない可能性があります。たとえば、「だれもが最初からVSSを使用することをお勧めします。必ず、Visual StudioのMercurialプラグインを使用しないでください」などの主張を投稿した場合、この答えは読者が2つの反対意見を選ぶのにどのように役立ちますか?それをより良い形に編集することを検討してください
gnat

3

全員が同じソース管理システム上にいる必要があります。また、最終的な目標は、すべての人を同じバグ追跡システムに参加させることでもあります。すでに緊密に統合されたソリューションを見つけるのに正しいことをしました。

乗り換えに問題がある場合は、キャリアの観点からアプローチしてみてください。彼らが将来どこかで働いているなら、その将来の雇用主は、おそらく統合されたバグ/ソース管理アプリケーションのセットアップで働いた経験を見たいと思うでしょう。


1
+1ですが、それがセールスポイントかどうかはわかりません。私は、ソース管理が何であるかわからない、VSSがソース管理のすべてであると考えている、または統合されたセットアップを見たいと思っている企業よりもソース管理を不十分に使用している企業をはるかに見つけました。私が見たもののほとんどは、バグ追跡アプリを使用していなかった、または非常に基本的な社内の「タスクシステム」を持っていました。
ウェインモリナ

コメントへの+1。スタックキャリアに再び投稿されたバラ色のメガネと仕事を通して世界を見ています。あなたが正しい。私たちと一緒に働いているチームが約4年前にbarえ始めたまで、私たちの店でさえそのようなものを持っていませんでした。
マットナドロフスキー

3

他の人が言ったことをエコーし​​ます。MercurialではなくVSSを使用できるようにするのは悪いことです。ただし、Devil's Advocateをプレイして、必要に応じて他の人が彼の作品にアクセスできるように、Mercurialにコミットしている場合にのみ、DevilのAdvocateをスライドさせることができます。他の人が必要とする可能性のある作業に他の人がアクセスするのを妨げない限り、お好みのツールを使用してもIMOに問題はありません。もちろん、VSSはガベージなので、何を使用しても使用しないでください:)

たとえば、私はSVNを使用しているが、リポジトリが適切に設定されていない会社で働いており(ブランチ/タグ/トランクはなく、すべてが1つのリポジトリの下にスローされます)、これは誰も修正方法を知らないいくつかの問題を引き起こします。たとえば、Gitをローカルで使用していても、git-svnを使用してSVNにデータをプッシュして、チームの残りのメンバーが使用できる場合、問題は発生しません。それは理にかなっていますか?


はい、それは理にかなっていますが、SVN以上のGitの利点のチームメイトを啓発検討すべきである
JD Isaacks

100%合意し、私が試してみると信じていますが、彼らはある種の方法で設定されています。私はそれをこのように言います。彼らは、.NET 1.1であるかのように.NET 3.5を書きます。LINQ、新機能、ジェネリックもありません。SVN から VSS に切り替え、VSSをより良いものにするように実際に試みようとしていた人たちがいます(残念ながら、そのうちの1人は開発マネージャーですが、幸いなことに、私たちはまだその道を行っていません...)。
ウェインモリナ

あなたは彼にここでProgrammers.stackexchange.comで「VSS」を検索させるべきです。それは彼を怖がらせるだろうと思う

0

1人の開発者が別のソース管理ツールを使用するのは良くありません。ソース管理を使用する目的の1つは、チームワークを改善することです。そして、彼はこのルールを破っていて、後でかなりのトラブルを引き起こすかもしれませんが、最近はかなり独立して仕事をしています。彼にVSSを好む理由を尋ね、この方法で作業することの欠点を伝えます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.