[203] Subversion文書つっちー 2006年03月31日 01:32

> ファイルの追加
http://members.at.infoseek.co.jp/sakura_editor/repositorymgmt.html
に関してコメントしたいと思います。

> ファイルの追加はコード量や機能単位を勘案して各自の判断で行って良い
> 新規ファイルは作成時に以下のを付与すること．
>
> svn:keywords (リビジョンの埋め込み)
> Author Date Id Revision
ブランチを作って、後でマージするときに大量にコンフリクトを
起こす可能性があるのでつけない方が安全だと思います。

またファイルの登録時にあらかじめ設定するプロパティを
拡張子ごとに設定することが可能です。TortoiseSVN の場合
[TortoiseSVN] -> [設定] でSubversionの設定で編集ボタンを
押すと、設定ファイルが開くので設定ファイルに指定します。

> Private領域へのファイル追加
> コンパイラの副生成物: オブジェクトファイル (*.obj)，
> Incremental linker (*.ilk)，プリコンパイルヘッダ (*.pch)等
svn:ignore 属性を設定するというルールをいれた方が
いいと思います。

> 変更者などCommit時に自動的に記録される物は記入しないこと
コミットする人と、パッチを作成した人が必ず一致するわけでは
ないので、パッチ作成者とコミットすることが違う場合
パッチ作成者を明記するような記述があった方がいいと
思います。

> 配置： sakura/tag/
ディレクトリ構成のところでは tags となっています。
(たぶんタイプミスだと思いますが)

ブランチのパスが　branch/ となっていますが
慣習的には　branches/ とするようです。

[205] Re: Subversion文書げんた 2006年04月01日 01:41

コメントありがとうございます．

>> svn:keywords (リビジョンの埋め込み)
>> Author Date Id Revision
>ブランチを作って、後でマージするときに大量にコンフリクトを
>起こす可能性があるのでつけない方が安全だと思います。
なるほど．そうですか．
1行目の$Idは変更した変更元バージョンを確認するために入れています．差分でないファイルが送られてきてもどこと差分を取ればいいのかを自己申告に依らずに明確にするためにCVS管理にしたときに追加しました．
ただ，実際には自分のCVSへimportして管理していて，リリース版とは全然関係ないバージョンが入っているケースがあり，その場合はその部分を差分から取り除く必要がありましたので，ご指摘の通りの問題は生じたことは既にあります．

何かうまい方法があれば教えて頂きたいところです．

それとファイルのリビジョンをdoxygenのファイルに埋め込めた方がいいかなと思って，Revisionを使っています．
ただ，Subversionではリポジトリへのバージョン付けなのでファイル単位のリビジョンを書く必然性は無いですね．
ファイルヘッダから一気に全部削ってしまうのも1つの方法かもしれません．

>またファイルの登録時にあらかじめ設定するプロパティを
>拡張子ごとに設定することが可能です。
こちらはSubversionの使い方のページに説明を作ってあります．一応リンクを追加しました．

>svn:ignore 属性を設定するというルールをいれた方が
>いいと思います。
そうですね．これはディレクトリに設定したらサブディレクトリにも効果が波及するんでしたっけ？

>コミットする人と、パッチを作成した人が必ず一致するわけでは
>ない
たしかにそうですね．ただソースコードの差分を見れば実際に編集した人の名前がコメントに入っているはずなので容易に判別可能なはずではありますが．ソースコードを修正した人以外にも間接的に貢献してくれる人もいますので，謝辞として記入可能としました．

>> 配置： sakura/tag/
>ディレクトリ構成のところでは tags となっています。
直しました．

>慣習的には　branches/
実際にもbranchesですので，直しました．(csv2svnがちゃんと名前を付けてくれていました^^;)
- [206] Re2: Subversion文書つっちー 2006年04月01日 11:49
  
  > 1行目の$Idは変更した変更元バージョンを確認するために入れています．
  > 差分でないファイルが送られてきてもどこと差分を取ればいいのかを
  > 自己申告に依らずに明確にするためにCVS管理にしたときに追加しました．
  マージする側でいちいち適用しないといけないリビジョンあるいはブランチを
  特定するのはかなり手間がかかります。
  
  それを考えるとSubversion のパッチ形式でない場合は適用しないという
  運用ポリシーもありだと思います。(Subversion を使ったことのひとの方が
  多数派だと思うのでいきなりは難しいかもしれませんが)
  
  マージ作業を簡単にしておかないと、せっかく作成してもらったパッチも
  適用されずにたまってしまう可能性があります。
  
  > ただ，Subversionではリポジトリへのバージョン付けなのでファイル単位の
  > リビジョンを書く必然性は無いですね．
  > ファイルヘッダから一気に全部削ってしまうのも1つの方法かもしれません．
  私も、CVS を使っていた頃は必ず $Id$ をつけていました。
  CVS がファイル単位でバージョン管理するためにどのバージョンか明確に
  するためでした。
  
  しかし Subversion を使うようになってからは $Id$ などをつけなくなりました。
  (最初はすこし抵抗がありましたが)
  リポジトリ全体にリビジョンが振られるので特にファイル単位でリビジョンを
  管理する必要がなくなったためです。
  
  >
  > >svn:ignore 属性を設定するというルールをいれた方が
  > >いいと思います。
  > そうですね．これはディレクトリに設定したらサブディレクトリにも
  > 効果が波及するんでしたっけ？
  基本的には設定したディレクトリのみです。
  
  TortoiseSVN の場合プロパティを設定する画面で「再帰的」という
  チェックボックスをつけて設定した場合はサブディレクトリにも
  設定されます。
  
  > sakura/
  > branches/ (official branch)
  > tags/ (official release tag)
  > trunk/ (main stream)
  >
  > help/
  > branches/
  > tags/
  > trunk/
  あと help がエディタ本体と別の場所にありますが、本来ヘルプと
  プログラムは一対一対応するはずなので同じ場所に入れた方が
  よいのではないでしょうか?
  - [207] Re3: Subversion文書げんた 2006年04月01日 22:58
    
    >それを考えるとSubversion のパッチ形式でない場合は適用しないという
    >運用ポリシーもありだと思います。(Subversion を使ったことのひとの方が
    >多数派だと思うのでいきなりは難しいかもしれませんが)
    所定の書式以外は門前払いまでしなくてもよいかなとは思いますが，放置するなら門前払いの方がいいですかね？
    ただ，今まで受け入れていた通常のPatchを門前払いはちょっとやりすぎかなと．
    パッチなら多少対象バージョンが違っても当該箇所だけならうまく当たることが多いですし．
    
    >マージ作業を簡単にしておかないと、せっかく作成してもらったパッチも
    >適用されずにたまってしまう可能性があります。
    実際これはその通りです．私も人間ですので面倒なパッチほど後回しになってしまいます．
    パッチ形式であってもConflictするとそれを解決するのがいやになることもあります．
    Subversion導入で最新状態を誰でも見られるようにしたのは，この差分同士の衝突を差分を作った人にお任せしたいという意図もありました．
    
    >私も、CVS を使っていた頃は必ず $Id$ をつけていました。
    >しかし Subversion を使うようになってからは $Id$ などをつけなくなりました。
    (._.) φ メモメモ
    
    >> >svn:ignore 属性を設定するというルール
    >基本的には設定したディレクトリのみです。
    了解です．
    
    >あと help がエディタ本体と別の場所にありますが、本来ヘルプと
    >プログラムは一対一対応するはずなので同じ場所に入れた方が
    >よいのではないでしょうか?
    正論ではあるのですが，実は私もヘルプファイルを全然編集したことが無くて，ヘルプをメンテナンスしてくださる方のご厚意に甘えております．プログラムの変更とヘルプの更新が全然同期しておらず，同じtrunk配下に入れてもヘルプとコードが同時にcommitされないと考えて別になっています．
    
    RTFだったのをヘルプデザイナの形式に変換して頂いてからは，テキストベースでバージョン管理もちゃんと出来るんですけどね．
    ヘルプファイルが更新されないから知る人ぞ知る機能だらけになってあんまりよくないんですけどね...
    - [208] Re4: Subversion文書つっちー 2006年04月02日 09:28
      
      > 所定の書式以外は門前払いまでしなくてもよいかなとは思いますが，
      > 放置するなら門前払いの方がいいですかね？
      > ただ，今まで受け入れていた通常のPatchを門前払いはちょっとやりすぎかなと．
      > パッチなら多少対象バージョンが違っても当該箇所だけならうまく当たることが多いですし．
      パッチを送っても拒否されるならともかく単に音沙汰が
      ないのは寂しすぎます。
      
      なのでパッチの種類によって優先度を明示するようにしては
      いかがでしょうか?
      
      優先度の高い順に
      1. Subversion形式の patch
      2. 通常の patch
      3. 単に変更したファイルのみなど適用するバージョンが
      不明確でマージが難しいもの
      
      ※ コンフリクトが起こる場合優先度が下がるという条件を
      つけておいてパッチ作成者側でコンフリクトを解消して
      くださいと明記しておく
      
      優先度を明示すれば、早くパッチを適用してもらいたい人は
      なるべく優先度の高い形式で送るようになると思います。
      
      優先度の低い形式で送った人に関しても優先度が低い
      ことがあらかじめ知っているので、放置されていても
      まだ納得できるかと思います。
      
      > >あと help がエディタ本体と別の場所にありますが、本来ヘルプと
      > >プログラムは一対一対応するはずなので同じ場所に入れた方が
      > >よいのではないでしょうか?
      > 正論ではあるのですが，実は私もヘルプファイルを全然編集したことが
      > 無くて，ヘルプをメンテナンスしてくださる方のご厚意に甘えております．
      > プログラムの変更とヘルプの更新が全然同期しておらず，同じtrunk配下に
      > 入れてもヘルプとコードが同時にcommitされないと考えて別になっています．
      現状ヘルプを更新しようと思うと、ソースコードを解析するか実際に使用して
      こんな機能があるというのを調べた上でヘルプに反映させるということをする
      必要があります。これではヘルプをメンテナンスしてくださる方の負担が
      大きすぎて継続的にヘルプを更新することは難しいと思います。
      
      パッチ作成者側で機能追加を行う場合や既存機能でUI上での操作が変わる場合に
      簡単なテキスト形式でもいいので、機能の説明や操作方法などを簡単にまとめて
      同時に送ってもらうということをルール化したほうがいいように思います。
      
      ヘルプを作成する人はこれらの文章をまとめたりレビューしたりするだけで
      OKというような仕組みを作ればヘルプの更新も進むのではないでしょうか?
      
      現状でのヘルプとプログラムの乖離を改善もしないといけないですが
- [209] Re2: Subversion文書つっちー 2006年04月02日 12:53
  
  > >> svn:keywords (リビジョンの埋め込み)
  > >> Author Date Id Revision
  > >ブランチを作って、後でマージするときに大量にコンフリクトを
  > >起こす可能性があるのでつけない方が安全だと思います。
  > なるほど．そうですか．
  > 1行目の$Idは変更した変更元バージョンを確認するために入れています．差分でないファイルが送られてきてもどこと差分を取ればいいのかを自己申告に依らずに明確にするためにCVS管理にしたときに追加しました．
  > ただ，実際には自分のCVSへimportして管理していて，リリース版とは全然関係ないバージョンが入っているケースがあり，その場合はその部分を差分から取り除く必要がありましたので，ご指摘の通りの問題は生じたことは既にあります．
  コメントするのを忘れていましたが、
  これらのキーワードには文字化けする可能性があるという問題もあります。
  
  http://arch.bluegate.org/pipermail/subversion-jp/2005-February/000252.html
  http://subversion.tigris.org/issues/show_bug.cgi?id=2332
  
  国際化対応のためにキーワードの部分の展開でロケールの設定が日本語になっている場合
  日本語に展開されるのですが、常にUTF-8で表現されるため Shift-JIS のコメントの入った
  ソースコードだとキーワード展開された部分が文字化けします。
  
  ※ 解決するパッチも出ているようですが解決したかどうか未確認です。
  - [210] Re3: Subversion文書げんた 2006年04月02日 23:03
    
    >国際化対応のためにキーワードの部分の展開でロケールの設定が日本語になっている場合
    >日本語に展開されるのですが、常にUTF-8で表現されるため Shift-JIS のコメントの入った
    >ソースコードだとキーワード展開された部分が文字化けします。
    これはちょっといやですね．
    
    ですが，既にCommitされたものを見たところ，
    2006-03-31 17:16:51Z
    のように入っていたので，今のところはセーフかな．
    - [211] Re4: Subversion文書つっちー 2006年04月02日 23:18
      
      ▼ げんたさん
      > >国際化対応のためにキーワードの部分の展開でロケールの設定が日本語になっている場合
      > >日本語に展開されるのですが、常にUTF-8で表現されるため Shift-JIS のコメントの入った
      > >ソースコードだとキーワード展開された部分が文字化けします。
      > これはちょっといやですね．
      >
      > ですが，既にCommitされたものを見たところ，
      > 2006-03-31 17:16:51Z
      > のように入っていたので，今のところはセーフかな．
      本当ですね。なんでだろ?

[203] Subversion文書 つっちー 2006年03月31日 01:32

[205] Re: Subversion文書 げんた 2006年04月01日 01:41

[206] Re2: Subversion文書 つっちー 2006年04月01日 11:49

[207] Re3: Subversion文書 げんた 2006年04月01日 22:58

[208] Re4: Subversion文書 つっちー 2006年04月02日 09:28

[209] Re2: Subversion文書 つっちー 2006年04月02日 12:53

[210] Re3: Subversion文書 げんた 2006年04月02日 23:03

[211] Re4: Subversion文書 つっちー 2006年04月02日 23:18

[203] Subversion文書つっちー 2006年03月31日 01:32

[205] Re: Subversion文書げんた 2006年04月01日 01:41

[206] Re2: Subversion文書つっちー 2006年04月01日 11:49

[207] Re3: Subversion文書げんた 2006年04月01日 22:58

[208] Re4: Subversion文書つっちー 2006年04月02日 09:28

[209] Re2: Subversion文書つっちー 2006年04月02日 12:53

[210] Re3: Subversion文書げんた 2006年04月02日 23:03

[211] Re4: Subversion文書つっちー 2006年04月02日 23:18