VSSが相変わらずフルボッコすぎる件について - 神様なんて信じない僕らのために
「ゲームコーディング・コンプリート」より引用。 常識的に考えて嫌われすぎだろ……。 Microsoft製Visual SourceSafe Visual SourceSafeはMicrosoftのVisual Studioで使われているソースリポジトリである。「安かろう悪かろう」の良い例だ。 多くの人がこの製品に惹かれるのは、GUIインターフェイスが使いやすく、セットアップがとても簡単だからだ。タイプするのが遅くなければ、10分で起動できる。 SourceSafeの一番の問題点は、ソースリポジトリをどうやって格納するかだ。リポジトリが格納された共有ファイルを探ってみると、AAAAAAAB.AAAとかAAACCCAA.AABのような奇妙な名前のついたファイルからなる大きなツリー構造のデータディレクトリがある。こうしたファイルの中身はプレーンテキスト（バイナリ化されていない）かそれに近い形だ。
平等分散リポジトリの見せる夢
身の周りで起きること、起こすことの記録、それが lifelog。 自分で作るモノの置き場所、それが repository。 はじめての Git LOG+REPOのテンプレートや素材、そして記事を保全するために Git で管理することにした。まずは「入門git」の第三章、「最初のプロジェクトを作る」に書かれた手順を追ってみた。 git init がすべての始まり。CVS や Subversion とは違い、中央リポジトリは存在しない。昨日までの作業場所がそのままリポジトリの置き場所にもなる(↓)。 (入門git; p.25) Git で自分のリポジトリがあるのは、自分の作業ツリーとまったく同じ場所にある .git ディレクトリの中だ。 ファイルを作ったら git add、そして git commit。変更しても git add、そして git commit。さっき何を変更したかを忘れたら g
分散バージョン管理入門 (イラスト入り) - tcha.org
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
Re:Re:mercurialでチケット駆動開発 - logiqboard
元記事 mercurialでチケット駆動開発 - logiqboard id:monjudoh から懸念点を指摘されたのでもーちょっと考えてみる。 Re:mercurialでチケット駆動開発 - monjudoh’s diary confirmで動作してもdefaultでの動作が保障されない 例えばデカい機能の新規リリースが控えている場合、「チケットxxxが、confirmにマージされたその変更に依存して正常動作している」という状況が起こりえる。 ただ元記事でも言われているように、この運用はサービスリリース後のバグフィックス・機能修正フェーズに入った後に固めた方法なので、 問題がおこらなかったという感じでしょうか。 認識を改める confirmブランチは、実情として "修正、機能追加の確認をする場所" ではなく "リリース済み成果に対する修正内容を確認する場所" という運用がされていたとい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散バージョン管理システムの詳細なガイド