MacのSubversionであらためてバージョン管理をはじめた - F.Ko-Jiの「一秒後は未来」
今更ですが、これまで作ってきたサービスのソースコードやファイル群のすべてを、Subversion管理することにしました。 Windowsのノートを使っていたときもローカルにSubversionを入れていましたが、きちんとコミットしておらず、それぞれのファイルの変更がいつの変更なのか分からなくなり、もういいや、という感じになってました。 マシンがMacBook Airになり、Subversionをターミナルから使えるようになったし、バージョン管理の必要に迫られた、という理由でSubversionの導入です。 LeopardにはSubversionが最初からインストールされているので(多分)、ローカルから使うならすぐに使い始められます。 以下はMacでの利用例です。 # リポジトリ作成 $ svnadmin create ~/repos/fkoji.com # インポートしたいファイルのあるデ
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
バージョン管理システム構築(Subversion) - CentOSで自宅サーバー構築
バージョン管理システムを構築する。ここでは、広く普及しているバージョン管理システムであるCVSの改良版であるSubversionでバージョン管理システムを構築する。 ※Webサーバー構築済であること [root@centos ~]# vi /etc/httpd/conf.d/subversion.conf ← Apache用Subversion設定ファイル編集 以下を最終行へ追加 <Location /repos> DAV svn SVNParentPath /var/www/svn SVNAutoversioning on 内部からのみアクセスする場合(ここから) Require local Require ip 192.168.1.0/24 ← 内部ネットワークアドレスを指定 内部からのみアクセスする場合(ここまで) # Limit write permission to list o
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
デザイナにバージョン管理(subversion)を使ってもらうために人柱を建てた - LAPISLAZULI HILL#diary
というわけで，説明+ハンズオンを2時間ほどやった．最初に人柱になったデザイナは自分とつきあいもそこそこ長く，コンピュータのリテラシも高め．案件の規模も手頃．経験も積んでいることもあって，利点はすぐに理解してもらえたようだ．うまくいくかはわからないけど始まったのは大きい．今回の導入の前提や考えてるポイントとか列挙 前提 デザイナは全部で8人 3人はコンピュータ使用のリテラシもモチベーションも高め，アプリも使いこなす 2人は新しいツール・習慣に拒否反応を示す可能性アリ 現在のファイル管理は共有フォルダを使って，日付でバックアップ作成（＞＜） プログラマだと「バージョン管理使わないのは幼稚園児までだよね」とかで済む（ぉ）のだけど，デザイナはそうも云ってられない 目的 度々作業中に先祖返りなどが起こり，そのたびに四苦八苦している バックアップが面倒なので解消したい プログラムチームとの共同作業も多
git - 簡単ガイド
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
gitをテキトーに使って生産性を向上したユースケース - 西尾泰和のはてなダイアリー
バージョン管理とかgitとかが「おおげさでめんどくさいもの」だと思う人は多い。でも、それは生産性向上のチャンスを逃していると思う。特に業務として多人数で開発している人たちの「変更前にはまずトピックブランチ」というやり方が、それはそれでよい方法なんだけど、いかにもめんどくさそうで尻込みさせてしまうのではないか。 先日の日曜日に、テキトーなgitの使い方をして、とても役に立ったのでユースケースとして報告しておこう。ただし、若干特殊な環境なのでここでやった方法が直接そのまま皆さんの所で使えるとは限らないが。 まず環境の説明。プロジェクトは「次の日曜日、新感覚シューティングゲームを展示します」で紹介している、テーブル型ディスプレイで動くシューティングゲーム。メインは @tokoroten で、ソースコードをバリバリ変更している。土曜日にとりあえず動くところまでは行った。改善点は山積みだ。使える時間
個人用に無料で使えるSubversionホスティングサービス3つ - takayukisの日記
個人用に使える = 非公開で使えるサービスです。 Beanstalk (10MB) Unfuddle: Free Source Control, Bug and Issue Tracking (15MB) Assembla (200MB) 10MB・15MBと言っても、コミットを繰り返すとすぐに使い果たしてしまうので、お試し用と考えた方が良いかもしれません。その点ではAssemblaは太っ腹の200MBなので、容量的には安心です*1。 同様のサービスでは、Subversionの他にWikiやTracなどが利用できます。Beanstalkではそれらを持たない代わりにBasecamp, FogBugz, Lighthouseと統合する機能があるようです。 Subversionだけ使っている分には問題無いのですが、いずれもユーザーインターフェースは英語です。日本語で使えるサービスとしては、Bac
[CentOS][SVN]Subversionの導入 - Linux編
Redhat Enterprise互換ディストリビューションであるCentOS上に、Subversionサーバを構築します 構築したSubversionサーバへはWebDAV経由でリポジトリへのアクセスを行える様にします また、利用ユーザ(グループ)毎に細かいアクセス制限ができる様にします WebDAVを使うという事で、apache2の導入も必要になります ここではapache2の導入が終わっていることを前提での手順を記載します
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
3分間 開発環境クッキング 2012.07 #pyfes
http://www.infinite-wave.com/my_first_blog/2009/03/fedorasubversionsubclipse.html