もうファイル管理で困らない！ デザイナーのためのSubversion/TortoiseSVN入門
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに はじめまして、Yahoo!検索のデザイナー担当の竹内美帆と申します。 今Yahoo! JAPANでは、プロジェクト毎にバージョン管理システムを使い分けていますが、Subversionを使用しコードを管理しているプロジェクトもあります。2011年1月～3月には、デザイナーが所属する部署でもデザイナーが作成するHTML・CSS・JavaScriptファイルなどをバージョン管理システムであるSubversion（サブバージョン）で管理しようという動きがありました。 デザイナーにとってはとっつきにくい印象がある「バージョン管理」ですが、うまく利用すれば「あのファイルどこいった？（汗）」「いつこのファイル書きかえたっけ？（汗）」「
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
プロジェクトの構成要素を探す手順
第1回「ファイルバージョンの管理だけで十分ですか？」では、構成管理を検討、導入するための6つのステップについて簡単に見てみました。今回は、6つのステップの中でも、皆さんが最も気になっていると思われる、構成管理そのものについて書きます。構成管理の詳細は、各組織、プロジェクトごとに異なり、それらは構成管理プランや構成管理ガイドと呼ばれるドキュメントに定義されます。そこには、構成管理要素、変更管理、ステータス管理、監査などについて記述するということは、前回記したとおりです。 （1）構成要素 構成要素には、どのようなものがあるのでしょうか？ 前回は、プロジェクトのいつの時点においても、要求／タスク／成果物の依存関係とともに、コスト、障害情報なども把握し、プロジェクトオーナーに提示できなければならないと書きました。ここでの“要求”という言葉は、“要求仕様“という狭義の意味ではなく、まさに、プロジェク
Git - Wikipedia
Git（ギット[2][3]）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナは濱野純 (英語: Junio C Hamano) で、2005年7月から担当している。 Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。 背景および概要[編集] Linuxカーネ
Insider's Computer Dictionary：ビルド番号 とは？ - ＠IT
プログラムの開発工程において、コンパイルやアセンブル、リンクなどの作業を経て最終的な実行プログラムを生成することをビルドするというが、ビルドされた実行プログラムを識別するために付けられたユニークな番号のことをビルド番号という。通常は、1回ビルドするたびにビルド番号を1つずつ増加させ、どのビルド（によって生成されたプログラム）であるかを識別するために使われる。 ビルド番号はバージョン番号と似ているが、その意味は異なっている。バージョン番号は、プログラムの機能や開発時期、リンクするライブラリ・モジュールのバージョンの違いなどに応じて異なる番号が与えられるが、ビルド番号は単にビルドした回数を反映した、最終生成物の識別用の番号に過ぎない。例えば、些細なバグ・フィックスやメッセージの変更、ユーザー・インターフェイスの修正（ボタンの位置や色、形状の変更）など、プログラムの開発中は、バージョン番号を変え
.NET TIPS アセンブリにバージョン情報を設定するには？ - C# VB.NET VS.NET - ＠IT
アセンブリのバージョン情報 .NETアセンブリ（.EXEファイルや.DLLファイル）には、次の画面で示しているようないくつかのバージョン情報を設定することができる。この画面は、エクスプローラでファイルを選択し、そのプロパティを表示させているところだ。 .NETアセンブリ（asmverinfo.exe）のバージョン情報を表示したところ。バージョン情報を表示するには、エクスプローラで.NETアセンブリ・ファイル（.EXEファイルや.DLLファイル）を右クリックして表示されるコンテキスト・メニューから［プロパティ］を選択する。もしくはファイルを選択した状態でショートカット・キー［Alt］＋［Enter］キーを押す。するとファイルのプロパティ画面が開くので、その画面の［バージョン情報］タブをクリックすれば、バージョン情報が表示される。
バージョン番号の衰亡 | OSDN Magazine
私はソフトウェアバージョン番号マニアを自認しているが、その立場から言わせてもらえば、最近のFOSS界はどこか変である。ユーザも開発者も、混乱と釈明のブラックホールに自ら足を踏み入れているようだ。 最初にそう実感したのは1週間前のことである。私はScott Robert Laddが書いたGCC 4.0についてのレビューを読んでいた。このレビュー自体は的確で、しっかりした根拠もあり、よく考えられたものだった。読み応えのある記事だったと思う。問題は、記事の締めくくりに書かれた次の一文だ。 そんな馬鹿な。歴史的に見ても、x.0リリースと言えば完成した製品を指すはずである。だからこそ、リリースチームは、最後のバグ退治を進めている最中の成果物にギリシャ文字の接尾辞や貴金属名のあだなを付け、最終的な製品と区別していたのだ。それがいつ変わってしまったのか？ 私は悩んでしまった。果たしてx.0リリースはきち
バージョン番号の謎
昨年暮、広辞苑のバージョン5(第5版)が刊行された。今回は、 ソフトウェアのバージョン番号にまつわる話題をいくつか紹介してみよう。 メジャー番号とマイナー番号 ソフトウェアの多くは、とくにフリーソフトウェアの世界では、 プログラムの特定に名前とバージョン番号を用いる場合が多い。 そのバージョン番号は、X.Y あるいは X.Y.Z といった二つもしくは三つの数字の組合せで表現されることが一般的だ。 頭の番号をメジャーバージョン番号、 二つめ以降の番号をマイナーバージョン番号といい、通常、 おびただしく機能が増えたり、 はなはだしい変更がなされた場合にはメジャー番号が繰り上げられる。 それに対し、細かな修正だけが加えられたバージョンアップの場合には、 マイナー番号を増やすだけにとどまる。 バグ修正をまとめた程度のバージョンアップでは三つめのバージョン番号が使われることが多い。 あるいは最後尾に
ソフトを作成する上でのバージョン番号のつけ方に悩む・・ - SourceChord
最初の一桁がメジャーバージョンで，次の桁がマイナーバージョン，っていう事を守っていれば，個人的なプログラムだったらある程度適当でいいと思うのですが，どのくらい機能が増えたらマイナーバージョンを増やそうか，とか無駄なことで悩んでいます・・ｗ で，バージョン番号のつけ方に関してちょっと調べて見ました． <メジャーバージョン><マイナーバージョン><ビルド番号><リビジョン>タイプ exeファイルには，プログラムのバージョン情報を埋め込めるようになっているのですが，そのデータは４つの部分から構成されています． プログラムのexeファイルへのバージョン情報の埋め込み方の解説サイト↓ http://www.atmarkit.co.jp/fdotnet/dotnettips/187asmverinfo/asmverinfo.html <メジャーバージョン><マイナーバージョン><ビルド番号><リビジョ
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
[Think IT] 第4回：チケットとソースコードを連携せよ！ (1/3)
【バグ管理の作法】Trac徹底活用！ 第4回：チケットとソースコードを連携せよ！ 著者：masuidrive 公開日：2007/12/27（木） Tracの最大の利点はSubversionとの連携にあり さて、最終回の今回はTracのチケットとソースコードの連携を実際に試していく。 コードを書く開発者から見た場合、Tracの最大の利点は普段使い慣れたSubversionから、Tracを使うことができる点にある。開発者は自分の環境に新たなツールをインストールすることなく、Tracへ情報を送ることができる。 Tracの操作は通常Webから行うが、すべての操作をコマンドラインからでもできる。この機能とSubversionへコミット時に自動的にコマンドを呼び出すフックという機能を組み合わせることで、開発者がリポジトリへコミットするとTracを操作するという処理を自動化できるのである。 Subver
Subversionのブランチの使い方[Subversion]
プログラムPBは、機能Aと機能Bを持っている。 プログラムPCは、機能Aと機能Cを持っている。 こんな時、Subversion上ではどのようにソースを管理すれば良いだろうか。 案1 trunk/に機能Aを入れ、PBとPCはbranches/PBとbranches/PCとする trunk/ branches/PB/ branches/PC/ この方法だと、もしPBやPCをbranchしたくなった時には、ディレクトリの構成が複雑になってしまう。 (trunkであるべき)メインの開発をbranch上でやる事は避けるべき。 案2 PBとPCを別のフォルダに分け、それぞれtrunk,branchesを作る PB/trunk/ PB/branches/ PC/trunk/ PC/branches/ 機能Aへ変更が入った時には、PBをPCにマージ(またはその逆)を行う事になる。 機能Aの大きさが小さくB
Subversion メモ
基本概念と特徴 リポジトリ Subversion は共有情報の一元管理システムであり、情報はリポジトリに格納される。 リポジトリは情報をファイルシステムツリー（一般的なファイルとディレクトリの階層構造）の形で保持する。 Subversion ではリポジトリの場所は URL によって表現される。 リポジトリにアクセスするための URL には以下のようなものがある。 file:/// リポジトリへの直接アクセス (ローカルディスク上) http:// Apacheサーバ への WebDAV プロトコル経由でのアクセス https:// http:// と同じだが、SSL による暗号化 svn:// svnserve サーバに対する独自 TCP/IP プロトコル経由でのアクセス svn+ssh:// svn:// と同じだが、SSH トンネルを利用する ほとんどの場合、Subversion の
バグトラッキングシステムTracをつかう/SubversionとWikiとチケットの連携 - きのさいと
Tracでは、Wikiとチケット、Subversionのソースリポジトリとそこへのコミットログなどというドキュメントを管理・閲覧することが出来ますが、これらのドキュメントで相互にリンクを張りたいときがあります。Tracにはあらかじめ便利な変数が備わっていて、その変数を埋め込むことでリンクを張ることができます。 具体的には † 具体的には以下のようなシーンを想定しています。 Eclipseでsvnにコミットしたときに、そのコミットのトリガとなったチケット*1に、コミットログを追記したい。その追記した文言にはそのコミットのチェンジセットへのリンクが張られる。 つまりチケットからチェンジセットへのリンクですね。ちなみにコミットログでチケットを更新したり、チケットを閉じたりする方法は「コミット時に処理を行う」が参考になると思います。 Wikiである機能に関するチュートリアルを書いていて、チュートリ
Rational ClearCase - Wikipedia
Rational ClearCase は、ソースコードなどのソフトウェア開発資産のためのバージョン管理システム（構成管理、SCMも含む）である。IBM のラショナル部門が開発している。ClearCase は中規模以上の大きな商用ソフトウェアプロジェクトでよく使われ、数百人から数千人の開発者を管理できる。 ClearCase 本体にも SCM 機能があるが、それとは別に UCM という SCM 機能もある。Linux、Solaris、Windowsといった様々なプラットフォーム上で動作する。巨大なバイナリファイルや多数のファイル、巨大なリポジトリを扱える。分岐、ラベル付け、ディレクトリのバージョン付けなどが可能。 歴史[編集] ClearCase は1992年、Atria Software が UNIX 向けに開発し、後に Windows 版もリリースされた。Atria の開発者の一部はそれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Software | IBM
Edge Components 概念、計画とインストール / WebSphere Application Server
Edge Components 概念、計画とインストール / WebSphere Application Server