Ron BieberさんによるSVK - Distributed Version Control - Part III の翻訳です。ようやく最後です。
最後の方に、Perlで書かれてるからインストールが難しいとありますが、Debian, Ubuntu, Gentooなんかでは、packageがあるようなので、簡単なようです。また、SubversionのPerl-bindingさえ入ってればそう難しくないという話も、元記事のコメントにもあったりしました。
なお、これらのチュートリアルはsmergeの説明で終わってますが、push/pullのが簡単なんで、そっちもドキュメントで見ていただくといいかもしれません。SVK - a visual guide はなかなかよさげです。
イントロダクション
Last week we explored using a local branch and keeping it in sync with the main repository. We also explored the incremental synchronization of local mirrors on our machine. This week we will be merging our changes back into the main repository and wrapping up our discussion of SVK for now.
先週、ローカルブランチを使い、メインリポジトリとの同期を調査しました。自分のマシンとロカールミラーとのインクリメンタルな同期も調査しました。今週は、自分達の変更をメインリポジトリにマージバックし、これまでのSVKについての議論の締めくくりとしましょう。
注意
Some of the lines in the command are truncated because they are too long. I have used the ‘_’ character as a line continuation character. If you see this character, look at the next line.
コマンド行のいくつかは、長すぎるので、切り捨てています。‘_’キャラクタを行を続ける文字として使っています。この文字を見付けたら、次の行を見てください。
ローカルブランチからミラーにマージする
At the end of our last article, we had finished the work that we wanted to do and now we would like to merge our changes into the main repository so that others can access our changes. The assumption is that we have performed all of the due dillegence that software developers perform when they finalize a change and are ready to have those changes activated in the main repository, including keeping our local branch up to date with the main repository using the repository synchronization techniques outlined in previous articles and merging them into our local branch to keep our workarea current.
前の記事の最後でやりたかった作業を終えました、今度は自分の変更をメインリポジトリにマージし、他の人達がその変更にアクセスできるようにしたいと思います。前の記事で概要を説明したリポジトリの同期のテクニックを使ってメインリポジトリで、ローカルブランチ(訳註:ローカルミラーの間違い?)を最新に保ち、ローカルブランチにそれらをマージして、作業エリアを最新に保つことを通じ、開発者が変更をし終え、メインリポジトリに変更を適用させる準備が整っている時に、ソフトウェア開発者が果たす全く当然の熱心さを行っていることを前提とします。
The time has finally come where everyone who uses the main repository gets to see the changes we have been working on.
ついに、メインリポジトリを使ってるみんなが私たちが作業している変更を見て取れるところに来る時です。
When merging to a mirrored tree in SVK, we use the smerge command just like we would in our previous work, only this time the source and destination are switched. We are now merging to the mirror, however the process looks the same. The really cool thing about SVK however, is that when you perform a merge to a mirrored path, you not only update your mirror, but the repository that the mirror points to is also updated simultaneously.
SVKでミラーされたツリーをマージするとき、ちょうど前の作業でしたように smerge コマンドを使います。ただこの時に、ソースと行き先を変えます。さて、ローカルミラーにマージしているだけで、そのプロセスは同じように見えます。ですが、SVKが本当にクールなのはここです。ミラーされたパスにマージを行うとき、SVKはミラーをアップデートするだけでなく、ミラーが指しているメインリポジトリも同時にアップデートします。
So lets do it. Before actually performing the merge, connect to the network and sync your local repository.
さぁ、やってみましょう。マージを行う前に、ネットワークに接続し、ローカルリポジトリを同期します。
svk sync //bieberlabs/trunk Syncing http://subversion.bieberlabs.com/svn/bieberlabs/trunk rbieber:/~>
Now that we are synced up, we will perform an svk smerge -C command to make sure we have no conflicts.
さて、同期し終えました。svk smerge -C コマンドを使って、コンフリクトが無いことを確かめましょう。
rbieber:/~>svk smerge -C //bieberlabs/new-feature-x _ //bieberlabs/trunk Auto-merging (0, 409) /bieberlabs/new-feature-x _ to /bieberlabs/trunk (base /bieberlabs/trunk:408). Checking locally against mirror source _ http://subversion.bieberlabs.com/svn/bieberlabs/trunk. U website/index.php D website/familypictures New merge ticket: fd3a5cf1-f4e9-0310-b907-bd1e11f8034a: _ /bieberlabs/new-feature-x:409 rbieber:/~>
Some things to notice. Previously we saw quite a few changes coming from the mirrored repository to our local branch, including the re-adding of a photos directory with 68 pictures in the main repository. None of these changes are being merged back to the mirror. SVK is keeping track of the merges we have made from the main repository to our local branch and filtering them out (or skipping them) for us.
気を付けることがあります。以前の作業では、ローカルブランチにミラーされたリポジトリから、メインリポジトリで68の写真の入ったphotsディレクトリが再度追加されたのを含めても、ほんの少ししか変更がありませんでした。それらの変更は、ミラーにマージバックされることはありません。SVKはメインリポジトリからローカルブランチにしたマージの跡を保っていて、それらをフィルタリング(またはスキップ)しています。
It winds up that with all the activity between the main repository and the local branch, the final result is that the only changes made by us in this whole process were the deletion of a directory, and modifications to our index.php file − and SVK knows that. We didn’t have to spend a lot of our valueable time towards an impossible schedule to figure it out!
メインリポジトリとローカルブランチの間の全ての活動で、最後の結果は、全てのプロセスの中で私達がした変更はディレクトリの削除とindx.phpの変更だけです − そのことを、SVKは知っています。それを解決するために、自分達の価値ある時間を不可能なスケジュールに浪費するべきではありませんでした!
Now that we know there are no conflicts (it’s nice to live in a perfect world!) we can actually perform a real merge to the mirror. We do this by substituting (in this case) the -C option with the -l option to get an initial log message that reflects each of our individual commits so we know what changes have been made through the time we have been developing on our local branch.
さて、コンフリクトが無いことがわかったので(it’s nice to live in a perfect world!)ミラーに実際にマージできます。(このケースでは)-Cオプションの代わって、-lオプションでそれを出来ます、-lオプションは個々のコミットを反映したものを初期のログメッセージとします。そのため、ローカルブランチで開発している時間に作られた変更が何かがわかります。
rbieber:/~>svk smerge -l //bieberlabs/new-feature-x //bieberlabs/trunk Auto-merging (0, 409) /bieberlabs/new-feature-x to _ /bieberlabs/trunk (base /bieberlabs/trunk:408). Waiting for editor... Merging back to mirror source _ http://subversion.bieberlabs.com/svn/bieberlabs/trunk. U website/index.php D website/familypictures New merge ticket: fd3a5cf1-f4e9-0310-b907-bd1e11f8034a: _ /bieberlabs/new-feature-x:409 Merge back committed as revision 24. Syncing http://subversion.bieberlabs.com/svn/bieberlabs/trunk Retrieving log information from 24 to 24 Committed revision 420 from revision 24. rbieber:/~>
As you can see from the above messaging, a few things have happened during the actual merge:
上のメッセージからわかるように、実際のマージでは下記のことが行われています:
- We were prompted for a log message. Even though this is prepopulated, you have to add something to it to let the tool know you want to continue with the merge, just like SVN and CVS.
- Our changes were merge to the mirrored path as we specified.
- Our changes were then merged from the mirrored repository to the main repository − automatically exposing them in the main repository for other developers to subsequently pull down.
- Our mirror was automatically resynced to be current.
- ログメッセージを書くように指示されました。これは既に挿入されていますが、ツールにマージを続けたいかを知らせるために、何かを追加する必要があります。ちょうどSVNとかCVSと同じです。
- 変更は指定したミラーのパスにマージされました。
- 変更はミラーしたリポジトリから、メインリポジトリマージされ、自動的に変更を他の開発者が後で引き出せるように、メインリポジトリに見えるようにしました。
- ミラーは自動的に、最新に再同期されました。
Just to verify that our changes made it to the repository, we can go to our local installation of ViewCVS to verify the commit:
変更がリポジトリにされたかことを確かめるために、ローカルにインストールしたViewCVSでコミットを確認できます:
結論
we have the basic areas of distributed, activity based development necessary to get someone new to SVK productive. I hope that as we have walked through the use of this tool, I have illustrated the huge gains you can receive from beginning to use it.
この3つの記事には、新たにSVKを使って、生産的になれる、分散された活動に基づいた開発に必要な基本があります。SVKの使い方をざっと見て、これを使い始めれば享受できる大きな利益を説明できたと思います。
There are obvious areas in which I have neglected to cover from a conceptual level like conflict resolution, however this process under SVN is covered quite extensively in the Resolving Conflicts chapter of the SVN book written by the Subversion developers. There are also other commands and types of merges that SVK can perform that I will leave to the reader to explore.
明らかに、コンフリクトの解決のような概念上のレベルからカーバーするのを無視した領域があります、ですが、SVNにおけるこのプロセスは、SVNの開発者によって書かれた Resolving Conflicts chapter of the SVN bookで、非常に広範囲に書かれています. SVKができる他のコマンドやマージのタイプもありますが、後は読者がSVKを探検してください。
SVK is a very powerful tool. The main disadvantage of it is that is written in PERL, and therefore can be difficult to install, and slow to start up. However, these disadvantages are far outweighed by the advantages that the tool brings to the table.
SVKはとてもパワフルなツールです。その主なディスアドバンテージはPERLで書かれていることです. それゆえに、インストールが難しくなっており、始めるのを遅くしています。ですが、それらのディスアドバンテージは、このツールがもたらす利益によって帳消以上のものになります。
The ability to work while disconnected from a central repository and the automatic merge tracking features of SVK are of incredible value to anyone wanting to give flexibility and true distributed capabilities to their development staff. I highly recommend that you take the time to explore this tool and explore for yourself the new capabilities and flexibility, not to mention just plain time savings SVK brings to the table.
中心のリポジトリから切断されている間に作業できることや、SVKの自動的なマージトラッキング機能は、開発スタッフに柔軟性と真の分散の可能性を与えることを望む誰にとっても、信じられない価値があります。このツールを探求する時間を取って、自分に新しい可能性と柔軟性を探求することを強く推奨します。SVKがもたらす利益が基準内労働時間を節約するのはいうまでもありません.
