とりあえずsubversionで生きていく。

愚痴。

ゴールデンウィークですね。今年も引き籠りの年になりそうです。
来年はどうなるんですかね・・・

まぁ、そんなことはともかく。

ここ半年、gitのトレーニングをしようと、趣味用途のプログラムはほとんどgitを利用して管理してきました。
クラウドサービスでVPSのインスタンスを1個作ってリモートリポジトリとして使って勉強。

結局のところ、僕のような頭の硬いおっさんには、ちょっと肌に合わないな、と思い、結局のところ挫折してしました(-_-;)
根本的に git を理解できなかった。っていうか、gitとかsubversionでブランチを使用した開発の手法をよく理解していないのが根本的な理由かなぁ。

挫折したポイントとしては、ブランチの扱い方が Subversionとあまりに違い過ぎて、付いていけなくなった(理解できなかった)こと。
いや、issue毎、feature毎にブランチを切って、マージして、という、一連の流れは分かるんですよ。
それこそ、チュートリアル的な単純なプロジェクトだと普通に分かるんすよ。ある程度コツがつかめてきて、仕事で使おうとしてたんだけど・・・どういえばいいのかちょっと迷うんだけど・・・ブランチを切る粒度というか、それがイマイチ分からないんですよねぇ。。。

アプリのソースがあって・・・
1. ある不具合があって、masterから修正のためのブランチを切る。
2. そのブランチでバグ潰しているうちに、そのバグに関連して別のバグを発見!😭

この時、
A. masterブランチから別のブランチを切って、後々リベースすればいいのか???
B. そのブランチでついでにその関連したバグを修正すればいいのか???
C. 一旦コミットしたのち、またブランチを切りなおせばいいのか?
subversionだとそんなの構わず一気に修正して、コミットして、ログに修正項目を羅列してたんだけど・・・。要は作業記録して残してるだけ、みたいな。

さらに、客側から、新しい機能のリクエストがあって、それを featureブランチを切って・・・とかやってると、慣れない git のブランチの管理でパニック!

これがチームで開発してて、同じ git使いなら、「ねぇ、今、こっちの修正で時間かかってるんで、別のバグ修正しといてくれない?」って感じで頼めるんだろうけど、おひとり様開発なので、んなのメンドクサイから、ついでに直して一緒にコミットすればいいや、って風になってしまう。
こういうのが重なってくると git の良い所を自ら潰していってるようなもん。履歴なんて滅茶苦茶。

結局、git を仕事で使うのを断念して、Subversionで、バグがあるたびに、issueブランチを作って(コピーして)、修正したらtrunkにマージして・・・という風な感じで進めていった方が生産的じゃないか???と思いつつあります。。。

一人で開発してるのって、制約がないので自由にできるけど、逆に言えば、引き継ぎのハードルが異常に高くなってしまう。
んー、こんな煩わしいことに時間を割きたくないんだけどな・・・

最新のSubversionへ

git 使わずんば開発者にあらず。

subversionは既にオワコンらしいが・・・昔から subversionでソースやテキストを管理してきているので、その膨大な量のリポジトリとその履歴をどうやれば git にすんなり移行できるだろうか・・・? と考えた挙句・・・「そのまま subversion でええやん?」という都合のいい囁きに負け・・・しかしまぁ、新しく書く時は git/githubを活用するように習慣を変えました😀

まぁ、それはそれ。

ところで WSL2にはアップデートせずubuntu 1804をそのまま使っているんですが、いかんせん apt でインストールできるパッケージのバージョンがとても古い。subversionだと、バージョンが 1.9という古さ。 今の最新って確か1.14。で、さがせばどこかのAPTリポジトリがあるんでしょうけど、メンドクサイのでソースからビルドすることにした。その備忘録です。

WSL1/ubuntu1804だと依存関係でいろいろ入れないといけないらしく、試行錯誤した結果、以下のシェルスクリプトに落ち着いた。

いろいろ問題が出てきそうなので、aptでインストールしたsubversionを削除することにした。これでやっと TortoiseSVNのsubversionとバージョンが一致した。

TortoiseSVN 1.8.0 でクライアント認証ができず・・・

Subversionが1.8にアップデートしたので、TortoiseSVN 1.8.0を何も考えずクライアントPCにインストールした。作業コピーに変更があったみたいで、作業コピーを片っ端からアップデートアップグレードした。

・・・結果、「TortoiseSVN 1.7.7でクライアント認証が失敗する」の二の舞を踏むことに・・・orz

インストールする時一抹の不安が過ぎったけど、後先考えず、「エイヤ!」ってな感じで。結局、やっぱり失敗。

一応サーバーはCentOS 5でApache 2.2.3 + オレオレ認証局のSSL環境。TortoiseSVN1.7.12を使っていたときはちゃんとクライアント認証のプロセスが通ったが、またしても1.8.0に上げたら今度は固まったまま。subversion自体がダメなのか、それともTortoiseSVNの部分がダメなのか、調べるだけの知識がないので、もうお手上げ。

検索してみたけど、やっぱりリリース直後なのでバージョン1.8の情報が出てこない。

結局、Apacheの設定で、SSLクライアント認証を解除して、ダイジェスト認証に切り替えることで、事なきを得た。

・・・が、Windows7上でTortoiseSVN1.8.0をインストールすると、ダイジェスト認証すらなんか怪しい挙動をする。作業コピーの更新をすると、ユーザー・パースワード入力ダイアログが出るのですが、正しいユーザー名・パスワードを入れてもエラーになる、あきらめてキャンセルすると、今度は違うダイアログ(Windows7の資格情報のダイアログ?)が出てくる。なんかワケ分からない。

ダメもとで何回もユーザー・パスワードの入力をトライしてみると、認証された。

よく分からん。

とにかく、元に戻そうかと・・・思ったけど、十数個ある作業コピーのチェックアウト作業がメンドクサイので、Apacheの設定をこのままにして、バージョンアップを待つことにする。

サーバーがオレオレSSLだからダメなのかなー・・・・とか、CentOS5のApacheのバージョンが低いのが原因なのかなー・・・とか思ったけど、確かめようがない。

この際だから、サーバー上のSubversionのバージョンを1.6系列から1.7系列最新の1.7.10にソースからビルドしてアップデートした。念のため、レポジトリのダンプをとったが、こちらは何ら問題なくバージョンアップ完了。さすがにサーバー上のsubversionを1.8.0にする気がしない。。。