中小企業（15人の開発者）がマネージドソース/バージョン管理を使用しないのは珍しいことですか？
これは実際には技術的な質問ではありませんが、ここにはソース管理とベストプラクティスに関する他のいくつかの質問があります。
私が働いている会社（匿名のままです）は、ネットワーク共有を使用して、ソースコードとリリースされたコードをホストしています。ソースコードがリリースされているかどうか、およびバージョンとその内容に応じて、ソースコードを正しいフォルダーに手動で移動するのは、開発者またはマネージャーの責任です。さまざまなスプレッドシートが点在しており、ファイル名とバージョン、および変更点が記録されています。また、チームによっては、各ファイルの上部に異なるバージョンの詳細を記載しています。各チーム（2〜3チーム）は、社内でこれを異なる方法で行うようです。ご想像のとおり、組織化された混乱です-組織化されます。なぜなら、「適切な人々」は彼らのものがどこにあるかを知っているためですが、混乱はすべてが異なり、人々がいつ何をすべきかを覚えていることに依存しているためです。良い点の1つは、すべてが毎晩バックアップされ、無期限に保持されるため、ミスがあった場合にスナップショットを復元できることです。
私はしばらくの間、ある種のマネージドソースコントロールをプッシュするように努めてきましたが、社内で十分なサポートを得ることができないようです。私の主な議論は：
- 私たちは現在脆弱です。いつでも、誰かが私たちがしなければならない多くのリリースアクションの1つを行うのを忘れる可能性があります。これは、バージョン全体が正しく保存されていないことを意味します。必要に応じてバージョンをつなぎ合わせるのに数時間または数日かかる場合があります
- バグ修正とともに新機能を開発しており、一部の作業がまだ完了していないため、多くの場合、どちらか一方のリリースを遅らせる必要があります。また、バグ修正が必要な場合でも、新機能を含むバージョンを顧客に強制する必要があります。これは、現在取り組んでいるバージョンが1つしかないためです。
- 複数の開発者が同じプロジェクトを同時に使用しているため、Visual Studioで問題が発生しています（同じファイルではありませんが、それでも問題が発生しています）。
- 開発者は15人しかいませんが、私たち全員のやり方は異なります。私たち全員が従わなければならない標準的な会社全体のアプローチを持っているほうがいいのではないでしょうか？
私の質問は：
- このサイズのグループがソース管理を持たないのは正常ですか？
- これまでのところ、ソース管理がないという漠然とした理由しか与えられていません-どのような理由を提案しますかできるソース管理を実装するために not に対して有効であるという情報上？
- /ソース管理に武器を追加できる理由は他にありますか？
主になぜ抵抗があったのかを感じてもらいたいので、正直に答えてください。
最もバランスのとれたアプローチをとり、3つの質問すべてに答えたと思う人に答えをあげます。
前もって感謝します
- normalではないかもしれませんが、Treb says のように、おそらくnusualではないでしょう。
他の人が言ったように、あなたの規模の会社でソース管理がない理由はありません有効。したがって、無効の理由を特定して攻撃する必要があります。
a）主なものは現状のままです：「壊れていない場合は修正しないでください」。これは難しいです：機能していないすべてのことを指摘し始める可能性があります（すぐに「否定的な人物」として分類される可能性があります）、または何かが爆発するのを待つだけです起こります）、またはできましたが間違っているすべてのものを強調できます。残念ながら、中小企業の担当者は、実際に問題が発生するまで、「問題が発生する可能性がある」ことに対して比較的無防備ですdo失敗する...
b）ignorance/fear/uncertainty："ソース管理とは何なのか本当に理解していない;使い方がわからないそれ;私たちはどのツールを選ぶべきかわかりません;それは私たちのスタイルを窮屈にするでしょう」。これが私が間違いなく1つの理由であるできないそれらを送信する ここ ！それはあなた自身にとってはかなり高い注文かもしれませんが、私はあなたが「ターンキー」ソリューションを提示する必要がある可能性を最大化し、バリエーションや選択肢が多すぎないように思います。次の明確なアイデアが必要です。特定のツールを使用して作業プロセスをどのように適合/変換するか。既存のコードをバックポートする方法/方法。ユーザーを「トレーニング」して、ユーザーを稼働させることができると考える速さ。移行期間を管理する方法（ある場合）。 「費用」にかかる可能性のある金額（ドルでない場合は時間単位）。
c）他の理由があるかもしれません（たとえば、VSSの以前の悪い経験、または過度に複雑なツールについての「恐ろしい話」を読んだ）、あなたはそれらを発見したときにそれらを個別に打撃する必要があります。
十分な理由がありますfor他の回答で概説されているソース管理。私のアドバイスは、本当にあなたの会社に変化をもたらす可能性のある主要な2つまたは3つを選び、それらを磨いて、できるだけ多くの同僚との会議で発表することです。ディスカッションを誘発してみてください。すぐに説得しなくても、問題点について洞察することができます。
（ 変更機能 について読んだり聞いたりしましたか？）
ソース管理なしで機能するグループのサイズは絶対に正常ではありません。ソース管理なしで効果的に作業できるプログラマの最大グループのサイズは、1以下です。 絶対に許されないanyサイズのプロのチームのためにバージョン管理なしで機能すること、そしておそらく私は創造的だとは思っていませんが、理由を思い付くことができませんあなたはそれを忘れたいでしょう。
バージョン管理は、もう1つのツールであり、特に強力なツールであり、最小コストに比べて莫大の利点をもたらします。ブランチ、自動マージ、タグ付けなど、あらゆる種類の便利な機能を使用して、すべての変更を体系的に細かく管理することができます。 umpteenバージョンの前のバージョンをビルドする必要がある場合は、その時点からコードをチェックアウトして、他のフープを飛ばすことなくjust buildをチェックできます。
さらに重要なのは、バグ修正を作成する必要がある場合は、作業中の新機能を提供しなくても、バグ修正を更新にマージできることです。これは、別のブランチにあり、残りの開発で必要なためです。心配してください、それらはまだ存在していません。
あなたは会社の文化に挑戦しているので、抵抗を経験しています。あなたが何と言っても、彼らが調整するのには時間がかかります。あなたができる最善のことは、それを推進し続けることです。そして会社が本当にびっくりしないのであれば、開発者としてのあなたのレベルにより適した別の仕事を見つけてください。
このサイズのグループがソース管理を持たないのは正常ですか？
私の経験では、それは標準ではありませんが、ここでの他の回答が示唆するほど完全に異常ではありません。中小企業の大多数はソース管理を使用していますが、残念ながらかなりの数が使用していません。
これまでのところ、ソース管理がないという漠然とした理由しか与えられていません-上記の情報を踏まえて、ソース管理を実装しない理由としてどのような理由が妥当だと思いますか？
良い議論については SOに関するこの質問 をご覧ください。受け入れられた答えは言う：
"バージョン管理を使用しない正当な理由はありません。1つではありません。"
武器に追加できるソース管理の理由は他にありますか？
私が会ったすべての開発者とプロジェクトマネージャーの間のコンセンサス、そしてもちろんここでプログラマーとSOはソース管理が必須であることです。それは受け入れられている最高です実践誰かがそれを無視することを決定した場合、彼はこれが彼にとって正しい決定である理由（すなわち、私たちがそれを必要としなかったので、なぜあなたがこれまでに提示した議論は特定の問題に焦点を当てています、おそらく「あなたは誰もがそれをするので、私たちもなぜそうしないのか？
ソース管理は、単一の開発者チームにとっても有効です。ソース管理システムは基本的に、変更を追跡するバージョン管理システムです。一部のコードを削除した可能性があり、コードが必要になったと感じている開発者が一人いるとします。彼は古いコードを取り戻すことができますか？
あなたに役立つツールを選んでください。サイズはどこでもかまいません。品質はどこでも重要です。
すでにバージョン管理システムを使用しているようですが、あまり良くないシステムです。人々はすでにバージョン管理の必要性を認識しているようです。あなたはそれらを次のレベルに導入する必要があります-ソフトウェアバージョン管理。
もし私なら、彼らが既に行っていることの改良版としてSCMを紹介します。優れたツールを使用することで、すでに行われている多くの作業を自動化する方法を強調しておきます。
SCMシステムは、スプレッドシートに変更を記録する代わりに、何が変更されたかだけでなく、誰が変更したか、およびその理由を追跡します。
おまけとして、コードの人生のどこにでも戻って、実際にそこに何があったかを見ることができます。
異なるフォルダーに異なるバージョンのコードを置き、変更を移植するためにフォルダー間で移動/マージする必要がある代わりに、すべてを同じ場所に保持し、（さらに重要なことに）ツールにマージを実行させることができます。
他の人がすでに言ったように、私はある程度の抵抗を期待するので、私がやっているものでそれを使用することによってシステムをプロトタイプ化しました。
（ちなみに、私は実際にResumeやその他のドキュメントをSVNの下に置きました。その後、何度もConfiguration ManagerおよびIntegration Managerの役割を果たしてきました。）
これまでのところ、ソース管理がないという漠然とした理由しか与えられていません-どのような理由を提案しますかできる not ソース管理の実装に対して有効であるという情報上？
開発している製品はバージョン管理システムです。管理者は、既存の製品が新製品の設計と実装に影響を与えるのを防ぐことを懸念しています。
BASEジャンプの週末と雄牛と一緒に走る週末の間、スリルを求めるマネージャーは、すべてがまだ地獄に行っているかどうか疑問に思って、仕事に運転を楽しんでいます。
敵対的買収を回避します。このように管理されているソフトウェア開発用の服を誰が取得したいでしょうか？
武器に追加できるソース管理の理由は他にありますか？
あなたはすでにバージョン管理を行っていますが、現在は、最も効率が悪く、最も労働集約的で、最もエラーが発生しやすい方法でそれを行っています。 VCSを使用すると、費用を節約し、時間を節約し、品質を向上させることができます。
ディスク容量を節約します。ほとんどのバージョン管理システムは、ファイル間の差分のみを保存します。現在、すべてのファイルのすべてのバージョンのコピー全体を保存しています。 （これらすべてのコピーのバックアップには、多くの時間とスペースが必要です！）
複数の開発者が同時に同じファイルで作業し、あまり問題なく差異を調整できます。もちろん、VCSなしで変更をマージすることは可能ですが、その場合、誰が何を、いつ、なぜ変更したかを追跡することはほぼ不可能です。
いつでもどのバージョンでも回復できることを知っている開発者に、新しいアイデアを試す自由を与えます。
優れたプロセスにより、有能な開発者の採用と維持が容易になります。
このサイズのグループがソース管理を持たないのは正常ですか？
間違いなく違います。私が現在の会社で仕事を始めたとき、変更したコードを送信する必要がある人が1人いました。 days以内の全員にSVNを使用するように説得することができます。
これまでのところ、ソース管理がないという漠然とした理由しか与えられていません-上記の情報を踏まえて、ソース管理を実装しない理由としてどのような理由が考えられますか？
漠然とした理由しか聞かなかったのは、バージョン管理を使わない正当な理由がないからだと思います。
ソース管理に武器を追加できる理由は他にありますか？
はい、理由はたくさんあります。
- 分岐により、他の開発を妨げることなく、新しい機能を開発する可能性が得られます。
- コミットごとに、正確に何が変更されたか、誰が変更したか、いつ変更が行われたかについての情報が提供されます。
- バグ修正を簡単にコミットして顧客に展開し、未完成の新機能を省くことができます。
- 顧客が新しいバージョンへの移行を恐れている場合は、異なるバージョンを維持できます。
- 同じプロジェクト（同じソースファイルでも！）を簡単に操作できます。
- ミスを犯した後の変更を保持することで、ミスを簡単に元に戻すことができます。
一部の人々は、自分にとってより良いものを見つけるまで、現状がいかに悪いかを理解するのに苦労しています。必要なのは、優れたdemoです。改善できるタスクの実際の例をいくつか示します。 「現在のシステムを追跡するのに4時間かかりましたが、この1つのソース管理コマンドですぐにわかりました。」
私の会社では、バージョン管理にGITを使用しています。同社は1人の開発者、1人のCEO、1人の警備員、1人の清掃員、1人の担当者です。それらはすべて私です。ソースバージョン管理は常に必須です。
私は自分で多くのプロジェクトに取り組んでいますが、まだバージョン管理を使用しています。サイズは問いません。バージョン管理が常に役立つ。
Joelテストで1位になっている理由があります： http://www.joelonsoftware.com/articles/fog0000000043.html
また、リストの＃2と＃3が可能になります。
ソース管理を使用しないと、一人の開発者であっても問題が発生します。何も失うリスクを負わずに冷酷に編集できるという単純な事実は、数週間または数日で学習努力を補います。
とはいえ、マネージャーにソース管理を導入するように説得できない場合は、自分でお願いし、少なくともローカルでgitやMercurialなどを使用してください。それをした人。
WTF ?!これは私が今まで見た中で最もばかげた質問かもしれません。あなたは新しい仕事を見つける必要があります。 15人の開発者？！あなたはそれが小さなチームだと思いますか？これは非常識です。マネージャーはすぐに終了する必要があります。正直なところ、この質問を読んだ後は悪夢を見ることになります。あなたが売る製品を教えてください、そうすれば私たちは皆、それを買わないことを知っています！何が怖いのかわからない、この質問、またはこれが珍しいことではないと答える！
数年前、私たちは6人のチームと同じような立場にありました。開発者の1人が、SVNを共有サーバーのある開発サーバーにインストールし、それを使い始めました。
誰もが追随し、CI（ CruiseControl ）を実装して、自動化と品質チェックを含むようにビルドとリリースのプロセスに革命を起こすずっと前からありました。
15人の開発者がソース管理なしでどのように作業できるか想像できません。ただし、以下から：
（...）ネットワーク共有を使用してソースコードをホストします（...）
私はあなたが [〜＃〜] vss [〜＃〜] （共有フォルダにも基づく）のようなあなた自身の貧乏人のバージョン管理を作成したと思います。危険で効率的ではありません。
それがどれほど悪いかを上司に説明し、2日間のSVNまたはGITトレーニングに投資し、コードが適切な形のままで実際のバージョン管理システムの使用を開始します。
1日に数回、または少なくとも家に帰る前にコミットしないと、何かが足りない、何かがおかしいと感じます。
私はかつて1998年に、たった2人の開発者（私+長い髪の管理人）で会社で働いていました。それでも、svnを使用していました。とても便利です。
Cpではなくrm -rfの代わりにmvのようなことをしたため、私のキャリアの中で何日か仕事を失いました。絶望して街の通りを泣きながら歩き回った。
私はSEにいる13年間で5つの会社で働いており、いくつかの会議に参加したことがあり、バージョン管理を使用していない会社に出会ったことはありません。
しかし、私のお気に入りのインテリアデザイン会社である20人の従業員は、プロジェクト管理+コラボレーションにホワイトボードを使用しています。彼らはその明白な間違いを知っていますが、アップグレードする時間を見つけていないようです。どういうわけかそれは動作します。どのように私に尋ねないでください。
リーダーになる。リーダーであることは、正しいことをすることを意味します。問題を積極的に解決する。十分なコンセンサスがないため、リーダーシップは何もしていません。そして、優れたリーダーは、コンセンサスを築くべき状況といつすべきかを認識することを学びます。これは明らかに実行状況です。コードコントロールの欠如は、遅かれ早かれあなたの顔を爆破します。
多くの場合、リーダーは公式の管理職にはありません。人々は、肩書きに関係なく、優れた決定的なリーダーに従います。
あなたの決定的な努力が非難された場合、特にそれが経営陣からのものである場合、あなたがそこから地獄を抜け出すことはあなたのための明確な兆候です。それはあなたの専門能力開発の妨げです。有能な開発者と無能な管理者が混在することはなく、力のある無能者はあなたを台無しにするでしょう。
OK、フラッシュバックが私に届いている。サインオフ。幸運を。
LordScree、私はあなたとほとんど同じ苦境にあります。私の直接のチームは約15人の開発者です。ソース管理が使用されていないと私は信じられません（ほとんどホラー）。 「ソースコントロールを使用する必要があります」に対する私の最初の応答は、「実装する時間がない」です。私にとって、下着を着るように、ソース管理はオプションではありません。数か月後、MSであり、90日間の試用版が付属しているため、私も組織によって選択されたTFSの実装を承認しました。結論としては、組織がソース管理なしで問題を抱えていたときに、ソース管理の必要性を組織に納得させることは非常に困難です。特に、ファイル名またはディレクトリに日付が含まれているファイルをバックアップしている場合はいつでも、ソース管理に何かを配置する場合の例であることを開発者に伝えます。すばらしい答えはありませんが、これは珍しいと思います。私は同じ戦いを戦っています、そしてあなたは進歩について投稿し続けます。そして、うまくいけば、私は他の場所を探しているかもしれません。
- ストップウォッチを入手してください。
- バージョンを同期するためだけにスプレッドシートで費やした時間をカウントします
- 壊れたバージョンの修復に費やした時間を数える
- 人々が廊下で叫んだ回数を数えます "私はmain.c！を編集しています。他の誰も今すぐいないことを確認するためです！"。
- バグ修正に他の変更が含まれていたために顧客から受け取った苦情の数を数える
- バージョンを同期できなかったという理由だけでリリースの時間遅延を数える
- このデータでPowerPointを作成し、VCがどのように機能するかを比較します。
- 管理を表示
これはただの事故です。コードの履歴はありません。一挙に、開発者の1人が数か月の作業を一掃する可能性があります。小さな会社としては、この種の挫折は許されません。
また、その共有ドライブで非常に公開されています。優れたバックアップがあっても、作業を継続できない余裕はどれくらいありますか。 1時間、1日、1週間。新しいサーバーを設置し、バックアップから復元するのにどのくらいの時間がかかりますか。また、小規模な会社の場合、スタンバイに追加のハードウェアがないため、迅速に発送するためにお金をすぐに落とすことができない可能性があります。
オフサイトストレージについても検討してください。洪水や火事はそれほど珍しいことではありません。数時間後に建物に火災が発生した場合はどうなりますか。何ヶ月の作業が失われるか。 githubのようなマネージコードリポジトリは、このために役立ちます。ホストされたサービスで単純なSVNサーバーを使用することでさえ、この領域でのステップアップになります。
1990年の最初の真面目な仕事では、自分の部門で働いている唯一の開発者であり、ソース管理を使用することを知りませんでした。
それからまもなく、私はそれ以降、彼らが最初に立ち上げたプロジェクトの1つにならなかったプロジェクトを見たことがありませんでした。
間違ったレベルでフォルダーを削除したため、その仕事ですべての仕事がほぼ失われました。幸いなことに、私は前の週に5インチフロッピーにコピーを持ち帰り、数週間かけて数週間の作業を再現することができました。
ですから、チームの全員にとって最初のプロジェクトで誰も知らなかったとしても許容できると思いますが、1人でも実際にメリットを説明でき、チームがまだ耳を傾けていない場合は、私のカテゴリを再分類します。 「素朴な」から「危険なほど無能」までのグループの意見（このように広く実証されている利点を持つツールを使用することに抵抗があるのは、ほとんど犯罪です。つまり、チームが「コンパイラ」を信頼せず、アセンブリ言語ですべてを行うことを主張したようなものです。 ）。
私は、これを多くのことを委託しました...小規模なエンジニアリング/電子会社で、多くの組み込みソフトウェア/ハードウェアを行っています。
これらの場所では、SCMは電子工学文化の一部ではありません。通常、プロジェクトごとに1人のエンジニアがいて、最新のリリースをバックアップするだけで済みます。
したがって、分岐/マージ、さらにはコードの共有でさえ、無関係ではないと見なされます。また、これらの企業はおそらくISO9000であるため、おそらく奇妙なプロセスが文書化されています。
いずれにせよ、私や他の開発者は個人的にSCMを使い始めたばかりです。
開発スタッフは3人で、ソース管理を使用しています。私の個人プロジェクトでは、1人の開発者がいて、ソース管理を使用しています。チームの管理に役立つだけでなく、何かを破壊しようとしているのではないかと恐れずに実験的な作業に取り掛かることができるので便利です。
管理を説得する最も簡単な方法は？製品全体のリスクが少なくなり、長期的には開発者の生産性が向上します。どちらも真実であり、どちらもマネージャーにアピールします。
それは決して通常のシナリオではなく、このセットアップを会社で実現するために厳しい戦いをする必要があると思います。それははるかに大きな利益をもたらし、終末に近づいたときに同じことを実現する意味がなく、それは該当する状況ではありませんそれが壊れていない場合は修正しないでください
それを実装しない理由は、悪い仕事や、起こるのを待っている大失敗の言い訳にすぎません。
見つけやすさを伝えてください今年の1月1日のアプリの内容
この機能は3月に追加されましたが、これについてもう少し詳しく説明する必要があると思います。
このバグ154256がこのコミットで修正されました。
私はアプリを分岐して展開を送信でき、問題なく実行できます
これは何度も続く可能性があります...（後で別の質問として来るであろうコミットについてコメントを追加することを忘れないでください）
私は、1人のプロジェクトと作業プロジェクトにバージョン管理を使用しています。そこでは、30〜40人以上の人が同時に同じコードで作業しています。バージョン管理には編成上の利点がありますが、ファイルを元に戻し、変更を隠しておくことができるため、コードの管理に頭を悩ませることができます。結局、それはプログラマにとって最良のシナリオなので、コーディングに集中できます。
バージョン管理を使用しないことをサポートする理由はかなり限られています。私が考えることができるすべては、物事の技術的な側面です。
- 学習曲線が多すぎて、スタッフ全体のワークフローを変換して、バージョン管理システムを組み込んでコスト効率を高めることができません。
- プロジェクトマネージャーは、リポジトリの管理と保守のワークフローにオーバーヘッドを導入することが有益だとは感じていません。 （主に古いバージョン管理システムの問題）
バージョン管理システムを使用する理由はたくさんあります。少なくとも物事の移動を停止してください。パッチを操作します。バージョン管理システムは、あなたが言うとおりのことを正確に実行できます。
- バグの修正と同時に次のバージョンに取り組み、個別にリリースできます。
- ある場所から別の場所にファイルを移動して作業する代わりに、ブランチを作成し、完了時にそれをマスターにマージできます。
- 各開発者は、複数のマシンで同じプロジェクトを開いた場合の問題を防ぐために、独自のソースコードのコピーを持つことができます。
- コードがひどく破損した場合、事故が発生し、最後に機能しているリビジョン番号にロールバックする必要があります。
- バージョン管理は、バグ追跡システムや継続的な統合システムと組み合わせてうまく機能します。
私は個人のチームとして、バージョン管理、バグ追跡、継続的インテグレーション、コードレビュー、コード整合性チェック、ユニットテスト、Seleniumテスト、ソースコード分析を使用していますが、忘れてはならないことがあります。認めますが、学習曲線はわずかです。また、自動化する追加の手順に必要な追加の管理時間のトレードオフもあります。私の経験では、節約された労力は追加の管理時間を上回ります。
すごい、すごい。コードコントロールを処理するのに最適な方法だとは思いませんが、6人の開発者がいる会社で働いていて、ソースコントロールが使用されていなかったのはまったく珍しいことではありません。すべての変更を監督しません。実際のところ、ある種のスイッチが機能を囲む限り、新しい機能をプロジェクトに追加できるというのがマントラでした。
たとえば、PHP=で記述されたabグレードのソーシャルネットワークに取り組んでいて、クライアントはユーザープロファイルにサブスクライブできるように機能を望んでいました。基本的に、機能は次のようなチェックにラップされました== true）{次にコードを実行します}
私が働いていた場所でも、一度に複数の開発者が特定のファイルで作業することはありませんでした。ほとんどすべてがモジュール式だったので、その場合、ソース管理の必要はありませんでした。ただし、ソース管理の利点は、ほとんどの場合それがないことの欠点をはるかに上回っていると私は思います。
あなたの会社がファイルの変更を文書化したスプレッドシートに頼っているというまさにその事実と、GitやSubversionのような何かがあなたのためにそれを処理できるときに何が変更されたかは、まったくとんでもないことです。
私が働いている場所でも同じ問題があります。現在、ソースコントロールを「レーダーの下」でスライドさせて、同じ問題を回避しようとしています。私が個人的に開発しているプロジェクトには Fossil を使用しています。
最近、会社のLANにFossilサーバーをセットアップしたので、さらに便利になりました。いくつかの小規模なプロジェクトでの有用性を示しながら、抵抗を弱め、ネットワークフォルダーの現状から遠ざけることを期待しています。
Fossilまたは他のVCSを使用しないことについて私が聞いた最大の理由は次のとおりです。
- 「プログラマ」の多くはスクリプトキディであり、その使用方法を理解していません
- 学ぶことができた人は、使うのが面倒だと思う
- これらの人々は古い警備員であり、ネットワークフォルダに慣れているので、全員が
- 正しく設定する時間も、使用方法を学ぶ時間もない
- 機能は素晴らしいかもしれませんが、どれも必要ありません
ご覧のとおり、私は使いやすく、設定が簡単で、習得が簡単で、機能にそれだけの価値があることを示して、これらを回避しようとしています。
最後に、ソース管理を使用しない場合でも、すべてネットワークツリーに含まれます。 Fossilはツリー全体のすべてをバージョン管理でき、ファイルの変更が発生するたびに、または少なくとも1時間ごとに実行するように設定できます。 「ソース管理が必要なかった」いくつかのプロジェクトでそれを実行しましたが、何か問題が発生したときに適切なバージョンにロールバックできるようになりました。
それを正しく行うと、彼らはあなたがそれをしたことさえ知らないでしょう。次に、壊れたビルドを復元するヒーローになることができます。およびは、ツールの有用性を示しています。
あなたはある程度確信しているようですが、組織内の誰かがあなたにそれを実行する権限を与えていません。他のコメントから読むことができるので、そうすべきです。
ここにいくつかの情報があります： http://www.internetcontact.be/scm/?page_id=358
最も重要な要因は、顧客が最後の「不安定な」ブランチに強制されることであり、顧客との契約により不安定なバージョンの展開を担当すると、会社は損失を被ります。ここでは本当にリリースの安定性に焦点を当てるべきです。これがソース管理の主な理由であり、主な失敗のようです。他のシステムは、すでに代替システムを導入しているため、ソース管理を使用してもそれほど改善されません。
GitやMercurialのようなDVCSツールが利用可能になり、セットアップと使用が非常に簡単になったので、1（！）のチームでさえソース管理を使用しない言い訳はありません。それはチームのサイズではなく、変更のコメント付きの履歴と、新しいリリースで作業する際の本番の問題の修正、さまざまなバージョンのソースコードの状態の追跡などのワークフローをサポートする機能です。
そのサイズに達したチームで仕事を提供され、開発者の1人がVCSの使用を提案しなかった場合、または「管理」がそれを妨げていた場合、私はそれを完全に断ります。それは最近の仕事の許容できる方法ではありません。
すぐにGITバージョン管理を取得する必要があります。 Google Code Project Hostingからでも使用できます。他の人が手動でコピーしているときにクリック1つで変更をコミットしているのを見ると、おそらくそれについて考えを変えます。