複雑なプロジェクトでSVNを使用した方法

開始する

約1年前、企業で新しいプロジェクトが開始され、すでに完了しています。 私と同僚にそれを実行するように委託。



Qtライブラリが開発の基盤として選ばれ、エンタープライズのすべてのプロジェクトがDelphiで実行される前から、この強力なツールの先駆者となりました。 これ以前は、Qtライブラリを使用して商用製品を開発した人はいませんでした。



バージョン管理システム-SVNをすぐに選択しました。 すでに彼女と仕事をした経験があり、またどこかから始めなければならなかったからです。 奇妙なことに、これはその時点まで、各プログラマーが独自のディレクトリを持ち、マスターであったサーバー上のアーカイブを除いて、バージョン管理システム（SLE）に似たものは私たちの企業に実装されていませんでした。



以下で説明するすべては、QtプロジェクトでSVNを使用して、現代のビジネスの現実を混ぜ合わせた実際的な経験を指します。

リポジトリ構造（ストレージ）の開発

今後の作業を分析した後、悪名高いトランク、ブランチ、タグで始まり、さまざまな仕様で終わるリポジトリのソース（すべてのリポジトリをリポジトリと呼びます）のソースのすべてのメインフォルダーをすばやく作成しました。 フォルダー、ファイルの命名、およびコードのスタイルについて合意しました。 企業でC ++コードのスタイリングに関して以前に開発されたドキュメントは、この点で非常に役立ちました。 チームの新参者は全員、仕事前にこのドキュメントに精通しており、今後ほとんど質問はありませんでした。 次に、ユーザーを追加して開始しました。

問題の始まり

1か月の開発の後、サーバー上にすでにいくつかのストレージがありました。 メインプロジェクトの1つのメジャー。 多くの共通コンポーネントを持つ2つのメインプログラムを収容しました。 残りは、他のプロジェクトで使用されることになっていた作成済みツール、大規模サブシステム用に作成されました。



そして、最初の問題が発生しました。 マシンにシンプルなリポジトリを作成し、VisualSVNを使用して同僚にアクセスできるようにしました。 その瞬間、手はサーバー上の別個のストレージの作成に到達しませんでした。 管理者と管理者は、プロジェクトだけでなく、それ以降のすべての集中ストレージ用の自動バックアップを備えた別のサーバーを編成する要求を完全に無視しました。 しばらくの間、ストレージの管理を扱い、リムーバブルハードドライブにバックアップを作成しました。



事実、私は別の部屋に移動しなければならなかったということです。 そして、これはIPアドレスの変更です。 ストレージの場合、これは悪名高い再配置だけでなく、svn：externalsを含むフォルダーのすべてのプロパティの編集でもあります。 この小さな迷惑はすぐに打ち負かされ、作業が続けられました。 ストレージはマシンに残ります。



判定：ストレージ用に別のサーバーを編成する必要があります。

さらにもっと

2番目の問題は、サブプロジェクトリポジトリの構造の不一致でした。 一部のサブプロジェクトでは、トランク、タグ、ブランチなどの一般的なフォルダー構造も作成しました。 アセンブリでは常にトランクが使用されていましたが、トランクを含む非常に不快なパスがすべてのプロファイルで取り上げられていました。 このリポジトリ内の2つのプログラムのそれぞれに必要なすべての外部インクルードを含むフォルダーを作成することが決定されました。 共通プロジェクトをビルドするために、このフォルダーにProファイルも作成されました。 選択されたモデル、1つのプロジェクト、1つのリポジトリを考えると、今後の開発において、このような決定によるマイナスの影響はありませんでした。



判定：1つのプロジェクト-1つのリポジトリのアプローチを使用する場合、トランク、タグ、ブランチフォルダはリポジトリのルートにのみ配置するのが最適です。



プロジェクトに取り組む過程で、さらに3人のプログラマーが加わりました。全員が初心者でした。 2つは特定の制限された機能を開発しました。モジュール、何かとめったに接触しないライブラリ、1つはメインシステムの開発に私たちと一緒に参加しました。 リポジトリ内で変更と新しいコードを作成しました。 また、要件は時間の経過とともに一部の領域で大幅に変更されたため、ストレージ構造がわずかに変更され、サブプロジェクトが転送され、コードが修正されました。



開発の開始から約8か月後（テストグループがないため、プログラマーはテストに従事しています）、2人のプログラマーが再びプロジェクトに取り組み始めたとき、別の重大な間違いを犯したことに気付きました。 リポジトリの内容をマージすると、追加の操作なしでは何もアセンブルできず、各プログラマーは自分のモジュールのみをアセンブルする方法を知っていました。 状況は、大量のコード、多数のモジュール、およびそれらの依存関係によって悪化しました。 解決策は表面にあった。



最初に、同じモジュールに対して異なるプロファイルを作成し始めましたが、コンパイルパスが異なり、最終的なバイナリファイルの場所が異なります。 第二に、すべてのサブモジュールは、ライブラリである場合はプロファイル、またはどこかにインクルードする必要があるコードだけである場合はプリファイルとともにリポジトリに配置され始めました。 これで、メインプロジェクトを組み立てる前のメインのプロファイルが、すべての依存ライブラリを収集しました。



次に、includeフォルダーとlibフォルダーの最も重要なpro-fileがあったフォルダーのルートに作成しました。 includeフォルダーに、拡張子のないヘッダーファイルを配置し始めました。このファイルには、ほぼ次の内容の1行が含まれています：#include“ ../modude1/src/modile1.h”。 これにより、ヘッダーファイルを含むディレクトリを1つだけ含めることができ、必要なファイルの場所を心配する必要がなくなりました。 また、libフォルダーには、サブプロジェクトから収集されたすべてのライブラリーが配置されていました。 したがって、途中でディレクトリを1つだけ登録したため、すべてのライブラリ依存関係を除外しました。



判定：リポジトリからマージして問題なく収集するという原則を維持することは非常に重要です。



開発の終わりに向かってますます醸造されていた私たちの文明化されたリポジトリを作成するという考え。 プログラマーの一人と、アイドル状態のマシンを見つけました。 Debian、SVN、FTPがインストールされました。 すべてのストレージをそれに転送しました。 数か月後、作業中のマシンでハードドライブに障害が発生したため、生成されたコードのバックアップと集中アーカイブの重要性は否定できません。



判定：コードを保存するために別のサーバーを用意する必要があるだけでなく、そのアーカイブを構成することも重要です。



サーバー作成のイニシエーターを制御した後、アーカイブとサーバーのパフォーマンスを監視するために回答する必要があります。



冬に、仲間のバスケットボール選手がバレーボールを発見し、2週目に足の靭帯を引き裂きました。 一般的に、プロジェクトは非常にトラウマです。 これに先立ち、チーフデザイナーは足を骨折しました。 別のプログラマーは車に見舞われましたが、幸いなことにそれほど多くはありませんでした-彼は一週間で仕事に行きました。 すでに秋-事件はありません！ 一般に、プログラマーは3か月間行動を停止しましたが、自宅で働き続けました。



これは、分散バージョン管理システムの欠如を感じた唯一の時間です。 同僚が戻ってきたとき、コードは総当たりで、つまり手作業で正常にストアに追加されました。



判定：パッチの使用方法とマージ方法を学習する必要があります。

ほぼ終わり

そして先週、プロジェクト全体をまとめる必要があり、汗をかかなければなりませんでした。 ほぼすべてがすでにバージョンに従って組み立てられているという事実にもかかわらず、バージョンをマージして組み立てましたが、一部の部分（最新の開発）はまだリポジトリにまったく追加されていませんでした。 一部の場所では、誤った構成ファイルがあったか、テストがリポジトリに追加されませんでした。



評決：タスクの作業を開始しました-主にリポジトリに配置します。

結論

プロジェクトはほぼ完了しています。 小規模なチームで絶え間ない情報不足、要件の変更、機械のクラッシュと機器の燃焼、急速な開発のペースを経験しました。 今日、予備承認が成功し、誰もがすべてを気に入っており、ソフトウェアはエラーや失敗なしに機能し、国家委員会は先を行っています。 ソースリポジトリはほぼ整頓されています。 このプロジェクトでは、将来SVNで作業する際のエラーに対して十分なバンプが得られたことがわかります。これを繰り返さないことを望みます。 バージョン管理システムの優れたチームワーク！