作業コピーにあるすべてのバージョン化されていないオブジェクトを再帰的に追加するには、 $ svn add * --force とやる。 svn add * だと、既にバージョン管理下にあるディレクトリのまだバージョン管理下にないファイルが追加されないから、--force を付けているのだが、この場合、実行したディレクトリ直下のsvn:ignore属性に設定した無視ファイルや無視ディレクトリも追加されてしまう。 また、既にバージョン管理下にあるファイルも追加しようとするので、警告が出て汚い。 結局、svnだけではいい方法はない。 無視ファイルや無視ディレクトリを除いて、Subversionのバージョン管理下にないファイルをまとめてaddしたり、バージョン管理下にあるのになくなった(物理的に削除された)ファイルをまとめてdelするには、svn status の出力をgrepでフィルタしてsed
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。(書く順番が逆っぽい) 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している(Git Lover)と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう? 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです(たぶん)。 それが今で
最近、諸事情あってsubversionからgitへプロジェクトの半ばでバージョン管理を変更しました。その際にちょっと変わった形でgit-svnの運用を行う事になったのでやりかたに関して簡単にログを残しておきます。 プロジェクトを取り巻く事情 今まではSubversion(仮にメインとします)を用いた運用を行っていたのですが、気軽にtrunkに対してコミットする事が出来ない事情がありました。では、メインSubversion上にbranchをたてればいいじゃんという話になるのですが、ブランチすら気軽に切る事が出来ない状態でした。その上、メインのSubversionにコミットすることが可能なのはコミッターだけとなっておりコミッターの負担が増えつつありました。 今までの運用 今まではメインSubversionとは別に 同期しないSubversion(仮にローカルとします)を別途立てて、なんと手動で
まず、管理の定義書を作ってみてはいかがでしょうか? 大雑把にはフォルダ構成と、アクセスのパーミッションを書いたものです。 たとえば、projectフォルダ以下に各プロジェクト名のフォルダを作成し、そのプロジェクトに関係する人間にのみ書き込み権限を与える、と言うような事です。 うちでは prj_fix : 各プロジェクトのファイルを保管する。確定したファイルのみ置くことにし、読み書きはできるが、変更/削除は管理人を通す prj_svn : VSS等のバージョン管理システム用フォルダ。ここのフォルダはバージョン管理システムに読み書き制御はお任せ。ステータスが作業中->確定となったものは、prj_fixに移動する home : このフォルダ以下に各人の個人フォルダを作成し、個人管理とする。個人フォルダ内は読み書き変更自由だが、他人のフォルダは読み出しのみで書き込み/変更は不可 data : その
うまくいかない日に仕込むラペ 「あぁ、今日のわたしダメダメだ…」 そういう日は何かで取り返したくなる。長々と夜更かしして本を読んだり、刺繍をしたり…日中の自分のミスを取り戻すが如く、意味のあることをしたくなるのです。 うまくいかなかった日のわたしの最近のリベンジ方法。美味しいラペを…
ネットで調べてもようわからんかったので、調査してみました。 SVNのsvnauthzファイルでSVNはアクセスを制限しています。 が、この設定が不可解な挙動をするので調べてみました。 デフォルトでは [/] admin = rw * = rw guest = r とあります。 guest = r と、ありますが、このままではguestユーザでのコミットは可能です。 どうも「svnauthz」ファイルの権限は「加算方式」で * = rw ⇒ 全員readもwriteも可能 guest = r ⇒ guestはreadが可能 となっているので、guestもコミット可能、ということになるようです。 「guest = rがあるのでguestだけは弾かれる」ということはありません。 (デフォルトでこう書いてあるとまるで絞り込めるみたいですが) ですので、 guest = r を常に利かせたいのであれ
スキルチェックの目次へ SVN の使い方を覚えてほしい時,この記事を読んでもらう。 初級と,中級がある。 初級編 覚えるべきこと 学習用のリンク集 中級編 覚えるべきこと 学習用のリンク集 初級編 覚えるべきこと: Tortoise SVNの導入について: 「Tortoise SVN」を,正しく読めること。(トータス・エスブイエヌ) Tortoise SVNを,自分のWindowsマシン上にインストールできること。 SVNが「バージョン管理ツール」である,という点を理解すること。 リポジトリとチェックアウトについて: 「リポジトリ」上のファイルと,「ワーキング・コピー(WC,作業コピー)」上のファイルとの,違いを理解すること。 「チェックアウト」「SVN コミット」「SVN 更新」の意味を理解すること。 既に存在するリポジトリから,自分のローカルフォルダに,「チェックアウト」を実行できるこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く