情報科学屋さんを目指す人のメモ（FC2ブログ版）

SubclipseよりSubversiveのほうが良さそう

結論を言うと、SubversiveのほうがSubclipseより良いと思います。とくに、ポート周りがとてもいい（後述）。

Subversiveとは

Eclipse上でSubversionを利用するプラグインです。同じようなプラグインにSubclipseがあります。今回利用したSubversiveは、

http://download.eclipse.org/technology/subversive/0.7/update-site/

からインストールしたものです。インストールすると、Connectorsのインストールが引き続き行われますが、そのときどれをインストールするか選択を迫られますが、とりあえず全部入れてしまえばOKです。

詳しいインストール法は、ここ→ http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php

Subversiveメモ

以下、SubversiveでSSH接続をしたときに気がついたこと。および、Subclipseとの違いをメモします。

URLの指定が利用される

URLに

svn+ss：//(ユーザ名)@(ホスト名):(ポート名)/(サーバ内フルパス)

のように入力すると、ユーザ名とポート名は、このURLで指定されているものになります。

Subclipseだと、レポジトリごとのポート指定がろくに出来ないので、すばらしいことです。この点だけ比較してもSubversiveに移行する価値があると思います。

ポートが指定可能

上記の通り、sshでの接続先ポートを簡単に指定できます。すばらしい。

環境変数SVN_SSHの設定が不要

SSHクライアントを用意して、そのパスをSVN_SSHに指定する必要がありません。Windowsでの利用が中心なので、subclipse利用時にはPuTTYに付属するplink.exeを指定していましたが、その必要はありません。便利。

割と早い

通信にかかる時間がsubclipse+plink(PuTTY)よりもちょっと速い気がする。

プロキシ設定が設定画面で出来る

接続に利用するプロキシの設定がPreferenceのGeneral>Network Connectionsから出来ます。Subclipseの場合は、「server」というテキスト形式の設定ファイルを直接変更する必要がありました（あったはず）。それに比べると、Subversiveは便利かと思います。

全く同じ設定のレポジトリをSVNレポジトリーViewに登録できる

見出しの通りです。Subclipseだと、重複を指摘され、登録できません。登録できる反面、指摘してくれないのはデメリット。

まとめ

もともと最低限の超基本的な機能しか使っていないので、しっかり使っている人の参考にはならないのですが、使ってみた感じでは、全体的に、Subclipseと同じ、もしくは、それ以上の点が多かったような気がします。ただ、ポートをちゃんとレポジトリごとに簡単に設定できる点だけをとっても、私にとってはSubversiveのほうを利用したいと思いますsubclipse+puttyでconfigファイルのtunnelセクションをいろいろ試しても出来なかっただけなので、うまくやれば出来るのかもしれません

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)
実用 Subversion 第2版
入門Subversion―Windows/Linux対応

Subversive

Eclipse用SubversionプラグインといえばSubclipseだと思うのですが、それも次第にSubversiveに変わっていくんだと思います。きっと。ということで、Subversiveをインストールしてみました。

というか、Subclipseでレポジトリごとに異なるポートを使いたいのに、いくら設定してもまるで-pオプションを反映してくれないので嫌気がさし、Subversiveをインストールしただけです。

感想

使ってみての感想は、なんだか設定項目が多いってことと、SVNレポジトリViewでディレクトリを開くときにあまり時間がかからないってこと。ただ、なんだか何が必要な設定項目だか今現在よく分かってないので、ちゃんと実験してみてメモろうかと思います。ちなみに、現在はsvn+sshでの接続です。

Apache Subversion

ふとダウンロードしようと思ったら、Subversionの公式サイトが移動されていた→「現在のSubverion公式サイト」

一人利用だとsubversionを利用していてもコミット時に衝突することなどなかったのですが、実際に衝突してみて分かったことをメモ

subclipseでの衝突表示

update(更新)実行時に、自分が変更を加えたリビジョン(rev9)より新しいリビジョン(rev10)がすでにコミット済みで、変更位置が重なっていた場合、衝突が発生します。つまり、編集箇所がかぶってしまった場合に発生するわけです。

衝突が発生すると、衝突が発生した箇所に

<<<<<<< .mine
=======
>>>>>>> .r10

という3つの行が現れます。どうやらこれらは、

(衝突に関係ないところ)
<<<<<<< .mine
(updateしようとしたときの作業コピーの内容)
=======
(すでにコミットされていたレポジトリrevision10の内容)
>>>>>>> .r10

(衝突に関係ないところ)

という意味みたいです。つまり、自分の作業コピーの内容に戻すには、「=======」から「>>>>>>> .r10」までを削除すればいいわけです。

修正してコミットしてみる

上記のように、衝突時、ファイルに>や<が大量に書き込まれてしまうので、手元でファイルを修正してコミットします。しかし、以下のようなエラーが発生してしまいます。

'SVNコミット' has encountered a problem.

org.tigris.subversion.javahl.ClientException:
A conflict in the working copy  obstructs the current operation
svn: Commit failed (details follow):
svn: Abortingj commit:
'D:\...\workspace\作業コピーの場所\ClassName.java'
remains in conflict

衝突を修正したはずなのにどうすればよいのか。

どうすればいいのか

衝突していた場所を適切に修正したのにエラーが表示されたわけですが、ではいったいどうすればいいのか。

エラー本文に「remains in conflict」とありますが、これは内容的な衝突が残っているということではなく、とあるファイルが残っていることを示しています。たとえば、ClassName.javaファイルが衝突していた場合、同じファイル階層に

ClassName.java.mine
ClassName.java.r9
ClassName.java.r10

の3つが作成されているはずです。「.mine」ファイルが自分の作業コピー、「.r9」が自分が変更を加えていたリビジョン、「.r10」がすでにレポジトリにコミットされていた内容を表したファイルです。これらが削除されるまで「remains in conflict」が残ってしまいます。つまり、これら３ファイルを削除すればOKです。

具体的な方法

まず、.java.mine、.java.r??ファイルなどを参考にしながら、もともとの作業コピーである.javaファイルを修正します。

続いて、「Package Explorer」上の.javaファイルを右クリックして、「Team>解決済みにマーク」をクリックし、「解決済みにマーク」ダイアログを表示させます。

What do you want to do?

• Conflicts have been resolved in the file.
• Resolve the conflict by using my version of the file.
• Resolve the conflict by using the incoming version of the file.
• Resolve the conflict by using the base version of the file.

ここで、「Conflicts have been resolved in the file」を選択すれば完了ですcf. $svn help resolved

強制的に上書きしたいときは

このような衝突時に強制的に自分の作業コピーでレポジトリを上書きしたい場合は、「Resolve the conflict by using my version of the file.」を選択すればOKです。

まとめ

衝突したときは、機械的に生成される「.mine」「.r最新の番号」「.r古い番号」という3ファイルをどうにかして削除する必要があり、削除には、「解決済みにマーク」を利用するのがよい。

バージョン管理ってすごく便利だけど、機能がたくさんあって難しい。

なんかSubclipseでsvn+sshを利用するとき、ポート番号を指定しても意味がないというか反映されていないようなので報告メモ

Subclipseでポート番号を指定してみる

Subclipseでsvn+sshを利用するときに、ポート番号(port)を

svn+ssh://username@hostname:port/repos/myrepos

のようにして、ポート番号の指定をしてみました。ただ、そのポート番号の様子がおかしい。

ポート番号にどんな番号を指定しても、常にSSHのデフォルトである22番ポートを使っているような気がしてきたので、Wiresharkで調べてみると、確かにどんな番号を指定しても22番ポートを利用しています。なので、

svn+ssh://username@hostname:10000000000/repos/myrepos

なんていう無茶な設定から

svn+ssh://username@hostname:99/repos/myrepos

なんていう微妙な設定まで、どう設定しようと22番ポートを利用しているようなのです。

Subclipseのソースコードをちょっと読んでみた

Subclipse自体のソースコードをチェックしてみたところ、URLのパース自体はちゃんとやっているみたい。ただ、それ以上どのタイミングでポート番号を指定して利用しているかがちょとすぐには見つからないのではっきりしません。すいません。

ポート指定方法はあるけれど

Subclipseの設定ファイルを利用して、ポート番号を指定することは確かにできるみたいなのですが、レポジトリごとの設定ができない模様。不便すぎる。

まさか

実は上記のポート番号の指定方法が間違っているのかもしれないんですけど、とりあえず、適当に入力しても何のエラーにもならないのは問題かと。とりあえず、もうちょっと調べてみようかな。

Subversion実践入門
実用SSH
Eclipse 実践開発入門