バージョン管理システムについて語るスレ7
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001前スレ858=879
2010/09/06(月) 22:48:42●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/
【分散型バージョン管理】 Mercurial 【hg】
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
0809デフォルトの名無しさん
2011/01/01(土) 17:33:52svnにブランチはない
0810デフォルトの名無しさん
2011/01/01(土) 17:39:30> svnにブランチはない
あ、そうか、bzrが意味不明なことを言いつづけているのはそのせいか
0811デフォルトの名無しさん
2011/01/01(土) 17:45:53Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。
Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。
Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。
0812デフォルトの名無しさん
2011/01/01(土) 17:50:34gitじゃない方がその目的には適してるんじゃないかな
git-svnを使うのはgitらしい運用だ！と主張するなら話は別だけど、それはナイト新字体
0813デフォルトの名無しさん
2011/01/01(土) 18:08:49組み込みの機能か否かの差だけで、svnの運用上一般的な概念としてブランチはあるだろうが。
0814デフォルトの名無しさん
2011/01/01(土) 19:43:421. 同時に一人しか編集できないロック機構が必要ですか？
│
├(YES)→ Subversionをおすすめします。ただし、オンラインでしか開発できなくなります。
(NO)
↓
2. 日本語のファイル名が存在し、リポジトリをMS-Windows（CP932）とLinuxやMacintosh OS X（UTF-8）で同期を取りますか？
│
├(YES)→ Bazzarをおすすめします。ただし、特殊記号の取扱いが重要な場合は、Subversionを選択してください。
(NO)
↓
3. 実験的なソースコードを頻繁に作成しますか？
│
├(NO)→ Bazzarをおすすめします。Bazzarは他のDVCSに比べると分岐が手間ですが、それ以外は遜色ありません。
(YES)
↓
4. MS-Windowsでの利用をしますか？
│
├(YES)→ Mercurialをおすすめします。日本語コミット文やCP932のファイル名も取り扱えます。
(NO)
↓
0815デフォルトの名無しさん
2011/01/01(土) 19:44:38│
├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
↓
6. シンプルな操作がお好みですか？
│
├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
0816デフォルトの名無しさん
2011/01/01(土) 19:46:45> ├(YES)→ Bazzarをおすすめします。ただし、特殊記号の取扱いが重要な場合は、Subversionを選択してください。
「が」が特殊記号？
0817デフォルトの名無しさん
2011/01/01(土) 19:50:37日本語でおk
0819デフォルトの名無しさん
2011/01/01(土) 20:55:54同じUTF-8でも、NFC形式とNFD形式があって「が」のような平仮名キャラクタでも、異機種互換性が無いケースがある。
0820デフォルトの名無しさん
2011/01/01(土) 21:15:081. 同時に一人しか編集できないロック機構が必要ですか？
│
├(YES)→ Subversionをおすすめします。ただし、オンラインでしか開発できなくなります。
(NO)
↓
2. 日本語のファイル名が存在し、リポジトリをMS-Windows（CP932）とLinuxやMacintosh OS X（UTF-8）で同期を取りますか？
│
├(YES)→ Subversionを選択してください。WindowsとLinuxでなら、Bazzarで日本語ファイル名の同期も可能かも知れません。
(NO)
↓
3. 実験的なソースコードを頻繁に作成しますか？
│
├(NO)→ Bazzarをおすすめします。Bazzarは他のDVCSに比べると分岐が手間ですが、それ以外は遜色ありません。
(YES)
↓
4. MS-Windowsでの利用をしますか？
│
├(YES)→ Mercurialをおすすめします。設定で、日本語コミット文やCP932のファイル名も取り扱えます。
(NO)
↓
0821デフォルトの名無しさん
2011/01/01(土) 21:15:48│
├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
↓
6. シンプルな操作がお好みですか？
│
├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
（チェンジセット: 4:ae4c01d241ab）
0822デフォルトの名無しさん
2011/01/01(土) 21:18:31今後期待できるMercurialでいいやｗ
0823デフォルトの名無しさん
2011/01/01(土) 21:23:320824デフォルトの名無しさん
2011/01/01(土) 21:26:380825デフォルトの名無しさん
2011/01/01(土) 21:35:240826デフォルトの名無しさん
2011/01/01(土) 21:43:560827デフォルトの名無しさん
2011/01/01(土) 21:49:10-rw-r--r-- 1 user group 0 1 1 20:47 テスト.txt
これをOS XのGitでコミットすると、エスケープされる。
"\343\203\206\343\202\271\343\203\210.txt"
0828デフォルトの名無しさん
2011/01/01(土) 21:52:41git config --global core.quotepath false
0829デフォルトの名無しさん
2011/01/01(土) 22:01:580830デフォルトの名無しさん
2011/01/01(土) 23:09:11ちゃんとしたテストつきの修正をLaunchpadに登録してマージリクエストをだしたら
すぐにでも治る。
正規化以前にUnicodeファイル名に対応する気がそもそも無いhgよりはずっと
期待できそうだけど？
0831デフォルトの名無しさん
2011/01/02(日) 00:01:100832デフォルトの名無しさん
2011/01/02(日) 00:25:19そもそもは、pythonの文字列の扱いが糞なのが問題の出発点なんでしょ？
0833デフォルトの名無しさん
2011/01/02(日) 00:53:10過去にM$がまともな仕事をしてればunicodeに関する問題は
ここまで混乱は広がっていなかったと思われる
0834デフォルトの名無しさん
2011/01/02(日) 01:34:39githubぶっつぶしたいから
>>805
ひと括りに出来ない気がするな
Unicode対応という(目標)のはいいんだが
0835デフォルトの名無しさん
2011/01/02(日) 01:40:34gitのブランチはチェンジセットへのポインタで、場所を指しているだけと思っていたのだけど
違うのかな
何かブランチのメタ情報みたいなものをチェンジセットに含んでたりする？
0836デフォルトの名無しさん
2011/01/02(日) 01:42:40BazzarはUNICODE正規化してどのプラットフォームで共有させられるようにという
前人未到の領域に挑もうとしているんだぞ
おいそこ笑うな！
0837デフォルトの名無しさん
2011/01/02(日) 01:45:58対応する気がないというより、ファイル名はバイト列で扱う物という指針なら
Python3でも直されない気がするんだ
>>833
同時にMacもdsiってんじゃねーぞ
0838デフォルトの名無しさん
2011/01/02(日) 01:53:06>Bazzarは
>おいそこ笑うな！
zが多すぎる・゜。・(ノД`)・゜・。
0839デフォルトの名無しさん
2011/01/02(日) 02:05:09ブランチ間に依存関係が無いと言いたいのでは？
チェンジセットにブランチの情報が含まれていないから、あるブランチを消しても、他のブランチに影響が無い。
0840デフォルトの名無しさん
2011/01/02(日) 02:37:50Python3でも変えないって中の人が既に宣言してたと思う。
MSからの圧力でどうにかして欲しいな。
0841デフォルトの名無しさん
2011/01/02(日) 02:52:09Mercurialで出来てBazzarで出来ない事ってある？
0842デフォルトの名無しさん
2011/01/02(日) 02:56:12Mercurialの方が、スペルを誤解されることが少ないようだ。
0843デフォルトの名無しさん
2011/01/02(日) 02:58:10よってBazaarが一番だな
0844デフォルトの名無しさん
2011/01/02(日) 02:59:45ハサーはにほんこはかんへき
0845デフォルトの名無しさん
2011/01/02(日) 03:06:060846デフォルトの名無しさん
2011/01/02(日) 03:50:02ファイル名以外のコメントとかで非ASCIIを使うのは
問題ないんだっけ？
0847デフォルトの名無しさん
2011/01/02(日) 05:04:59MercurialもGitも、UTF-8（NFC形式）なら問題ない。
Mercurialなら、WindowsのCP932も%USERPROFILE%\Mercurial.iniに以下を書いておけば、問題ない。
[defaults]
commit = --encoding cp932
Windowsでgit-guiなどのツールは、UTF-8でコミットメッセージを書いてくれるそうだ。
0848デフォルトの名無しさん
2011/01/02(日) 05:12:310849デフォルトの名無しさん
2011/01/02(日) 10:13:540850デフォルトの名無しさん
2011/01/02(日) 14:21:56指針を持つのはいいんだけど、Python自体のJoinメソッドの処遇なんか見比べると
なんか筋が通ってないように感じるなぁ・・・
なるようにしかならんのだろうけど
0851デフォルトの名無しさん
2011/01/02(日) 15:00:29bzrのように複数のcloneによって自然に生じるblanch。
gitの機能を取り込む為の、pointer型のblanch。
それにnamed/anonymous blanchが混在してしまうから。
0852デフォルトの名無しさん
2011/01/02(日) 15:17:51Python2もPython3も、ファイルシステムはUnicodeでもバイト列でも利用可能。
複数のエンコーディングが混じってる等がありえるUnix系で全てのファイル名に対応できる
バイト列のファイル名を使うか、WindowsでネイティブでUnix系でもエンコーディングが正しければ
大丈夫なUnicodeファイル名を使うかは、アプリケーションが選択する問題。
bzrはUnicodeを、Mercurialはバイト列を選んだだけ。
ちなみにPython3.1からは、Unicodeにデコードできないバイト列も扱えるような
サロゲートエスケープという方法が提供されていて、デコードできないファイル名を扱える。
0853デフォルトの名無しさん
2011/01/02(日) 15:24:13用語の定義の問題で、普通ブランチと言った場合、名前付きブランチのことを言う。
あとはリポジトリ・ヘッドと言えば大抵通じる。
他のVCSから来る人のために名無しブランチとか紹介されているだけ。
0854デフォルトの名無しさん
2011/01/02(日) 15:42:10> 生じるblanch。
> のblanch。
> blanchが
なんで最初だけ正しいスペル？
何か意図があるのか
0855デフォルトの名無しさん
2011/01/02(日) 15:50:27ぶっちゃけ、英語の事しか考えてなかったのを
後から問いただされて「い、いや、混在してる場合もあるから」
って正当化しただけでしょ。
ML見れば分かる。
混在なんか滅多にないのに。
全か無かで考えるのは典型的な思考ロジックミス
0856デフォルトの名無しさん
2011/01/02(日) 16:05:09伝説のなんたらかんたらってやつ？
0857デフォルトの名無しさん
2011/01/02(日) 17:37:40いに実現できれば受け入れられない訳ないと思うが、なぜかここではそれをあ
きらめてしまってる>>837みたいな書き込み多いよな
0858デフォルトの名無しさん
2011/01/02(日) 17:54:17Pythonが元凶なんじゃねえの？
0859デフォルトの名無しさん
2011/01/02(日) 18:01:160860デフォルトの名無しさん
2011/01/02(日) 18:20:380861デフォルトの名無しさん
2011/01/02(日) 20:39:49Pythonの話？Mercurialの話？
Pythonの話であれば、Python1の頃は確かに英語やlatin1の事しか考えられてなかったろうな。
今のPythonは、いわゆるLLの中ではUnicodeの扱いがマシな方だよ。
混在が滅多にないとは言い切れない。Unixはマルチユーザーシステムで、ロケールはユーザー毎に切り替わる。
あるユーザーは LANG=ja_JP.EUC-JP を使ってて、別のユーザーは LANG=ja_JP.UTF-8 を
使っていると当然各ユーザーのホームディレクトリ内はそれぞれ別のエンコーディングに
なっていて、しかもそれを管理している root は LANG=C で運用している、なんてのはよくある話。
rootが各ユーザーのファイル一覧を舐めるようなスクリプトを、ファイル名をUnicodeで扱うように
書いたら、LANG=Cだと非ASCIIファイル名全部がデコードできなくてUnicodeDecodeErrorが
発生しているのがPython3.0以前のPython。
0862デフォルトの名無しさん
2011/01/02(日) 22:11:25たぶん論点がちゃってる。
つか、VCS側はbyte列で十分、プラットフォーム側で会わせる問題じゃねぇのか？
0863デフォルトの名無しさん
2011/01/02(日) 22:44:07しかも、コードが異なるとマッピングできない文字もあるし。
0864デフォルトの名無しさん
2011/01/02(日) 22:45:57どっちかが正解でどっちかが間違いって事はないだろ。
CVSで利用者のミスでSJISとEUCが混じったりして管理に苦労して、svnのUnicode対応を喜んでる
人だって確実にいる。
0865デフォルトの名無しさん
2011/01/02(日) 22:49:26そのレベルの話はもう時代遅れで、今はUnicodeに統一しても正規化や結合・分解文字の扱いで苦労している。
で、gitやhgって、NFCのUTF-8ファイル名をLinuxでコミットして、Macでチェックアウトしたら、
UTF-8-MAC問題で勝手に分解文字にリネームされたりしないの？
Macの問題はファイル名をバイト列で扱ったら解決できるような簡単な問題じゃないと思うんだけど。
0866デフォルトの名無しさん
2011/01/02(日) 22:54:25GitやMercurialのファイル名の文字コードは、このレベルの話だから困っているのでは？
0867デフォルトの名無しさん
2011/01/02(日) 22:58:10> CVSで利用者のミスでSJISとEUCが混じったりして管理に苦労して
ファイルの中身は？
VCSは改行の変換はするけど、文字コードの変換しないよね？
ファイルの中身がUTF-16というものもあるし
0868デフォルトの名無しさん
2011/01/02(日) 23:04:20git、hgのファイル名はたいした問題じゃない
0869デフォルトの名無しさん
2011/01/02(日) 23:25:53zipは展開したあとにconvmvするとか、どうにでもなる。
バージョン管理ソフトで継続的に管理するファイルのファイル名だから困るんだろ。
0870デフォルトの名無しさん
2011/01/02(日) 23:31:370871デフォルトの名無しさん
2011/01/03(月) 08:09:23何が困るの？ファイル名を変換するなら、Makefileなどファイル名が書かれているもの全て変換しないと
辻褄合わないよね？
0872デフォルトの名無しさん
2011/01/03(月) 08:27:08Makefileに書くような種類のファイルには、日本語ファイル名は使われない。
日本語ファイル名多用する現場であっても。
知ってるくせに。何でとぼけるの？
0873デフォルトの名無しさん
2011/01/03(月) 08:30:00日本語.dat、日本語.yamlを使っているところはあるぞ
0874デフォルトの名無しさん
2011/01/03(月) 08:36:25Javaのクラス名は日本語使わない？
0875デフォルトの名無しさん
2011/01/03(月) 10:34:57JavaならantとかMavenとかだろ。Makefileと違って設定ファイルがxmlで、設定ファイルの
エンコーディングとファイルシステムのファイル名のエンコーディングが違ってても大丈夫。
>>873
そういう事をするのは、実行環境が限られている、非ポータブルなMakefileだけだろ。
それならUnicodeでもバイト列でも問題ない。
実際、svnはUnicodeでファイル名を扱っているけど、長年デファクトスタンダードとして
利用されてきた。
今分散型に押されているのはコミット権が無いとブランチが作れなかったり
オンラインじゃないと作業できなかったりマージが弱かったりするからであって、
ファイル名をUnicodeで扱うからじゃない。（ちなみにマージは改善されたし
ローカルコミット・ブランチも開発中らしい）
0876デフォルトの名無しさん
2011/01/03(月) 10:53:33> >>874
> JavaならantとかMavenとかだろ。Makefileと違って設定ファイルがxmlで、設定ファイルの
> エンコーディングとファイルシステムのファイル名のエンコーディングが違ってても大丈夫。
本当か？
xmlはutf-8と定義してあるのに、ファイル名がEUC-JPで書かれていても問題ないのか？
パセーントエンコードしないと不整合だぞ
0877デフォルトの名無しさん
2011/01/03(月) 11:44:42>xmlはutf-8と定義してあるのに、ファイル名がEUC-JPで書かれていても問題ないのか？
「ファイル名がEUC-JPで書かれていても」というのは、xmlの中に？それともファイルシステムに？
xmlはもちろんUTF-8で書くよ。
<?xml version="1.0" charset="UTF-8" ?>
<project><target name="test">
<copy file="foo.txt" tofile="あほ.txt" />
</target></project>
と書いて、 touch foo.txt したあと、 LANG=ja_JP.utf8 ant test すると、ファイル名が
UTF-8でエンコードされたあほ.txtができて、 LANG=ja_JP.euc_JP ant test すると、
ファイル名が EUC-JP でエンコードされた あほ.txt ができる。
xml内の情報はJava内で一端全部Unicode文字列に変換されて、さらにそれを実行するときに
環境のエンコーディングが利用されるので、xmlファイル内のエンコーディングと環境のエンコーディングは
独立している。
antの用にUnicode対応したツールの場合は Makefile と逆で、 svn や bzr だとLANGが違う環境でも動いて、
git や hg だと LANG が違う環境で動かなくなる恐れがある。
0878デフォルトの名無しさん
2011/01/03(月) 11:49:030879デフォルトの名無しさん
2011/01/03(月) 12:08:19それよりUnix/LinuxのUTF-8とWindowsでまともに動かすにはどうすればいいか考えようぜ。
NFCなりNFDなりはその次のステップだ。
0880デフォルトの名無しさん
2011/01/03(月) 12:13:00それはbzrとsvnはデフォで対応しているし、gitやhgはutf-8 cygwin使ってutf-8に統一すればおｋだろ
0881デフォルトの名無しさん
2011/01/03(月) 12:16:19> 今どき ja-JP.euc_JPなんてゴミ環境無視していいよ。
君はLatin-Nの人に同じことを言えるか？
0882デフォルトの名無しさん
2011/01/03(月) 12:48:32えー今でもLatin-1なのｗ
UTF-8で全部包含してるからen_US.UTF-8にしなよｗ
なに？「俺の読めない漢字が入ってるJIS2004ケシカラン」とかいう人？
0883デフォルトの名無しさん
2011/01/03(月) 12:49:53ということをLatin-1の人と英語で議論できるか？
0884デフォルトの名無しさん
2011/01/03(月) 13:25:350885デフォルトの名無しさん
2011/01/03(月) 13:41:15英米人だけでなく、ヨーロッパ大陸の人でもLatin-1で十分と思っているからね。
そもそも、Latin-1とUTF-8の区別が付いているかどうかも疑問。
日本人は化け方でJISかEUCかSJISか分かっちゃうけど、
Latin-1の人は文字化けの経験があるのだろうか、と思ってしまう。
0886デフォルトの名無しさん
2011/01/03(月) 14:02:390887デフォルトの名無しさん
2011/01/03(月) 15:34:47だったからファイル名がUnicodeに限定されていても問題がなかっただけでしょ
今時のバージョン管理システムは一般ファイルのバージョンを管理するバックエンドとしての用途
も視野に入っているから今更Subversionの時代にまで退化しろと言われてもちと困る
0888デフォルトの名無しさん
2011/01/03(月) 15:35:550889デフォルトの名無しさん
2011/01/03(月) 15:41:11個々のファイルのリビジョンしか管理しないCVSにちょびっと毛が生えた程度。
0890デフォルトの名無しさん
2011/01/03(月) 15:48:50> Subversionはソースコードに特化
・・・
何を見てそう思ったの？
0891デフォルトの名無しさん
2011/01/03(月) 15:56:48gitもhgもファイルのタイムスタンプその物は保存しない。
（svnは論外にしても）一般ファイルのバージョン管理に向いてるとはとても思えない。
0892デフォルトの名無しさん
2011/01/03(月) 16:04:59ファイルじゃなくてチェンジセットなの
だから個々のファイルのタイムスタンプは意味ないの
タイムスタンプもgitとhgはrebase、hgはMQを使えば時間順には並ばない
0893デフォルトの名無しさん
2011/01/03(月) 16:48:19個々のファイルのタイムスタンプを保存しないのは、チェンジセットとは関係ない。
VCSに個々のファイルのタイムスタンプを以前の状態に戻されると、makeが混乱するので却って
邪魔になるというのが元々の理由。
世代管理可能なバックアップツールであれば、個々のファイルのタイムスタンプも保存して元に
戻すのが当然だが、VCSであるsvn/git/hgは個々のファイルのタイムスタンプを保存しない。
よって、gitやhgが一般ファイルの管理にも向いているという >>887 の意見には同意できないと
主張しているだけ。
0894デフォルトの名無しさん
2011/01/03(月) 16:53:34> Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム
ちょっとわかりづらいな。
一般ファイル以外だとシンボリックリンクとかのイメージなんだが。
0895デフォルトの名無しさん
2011/01/03(月) 17:06:46分かってて言ってるとは思うけど
Subversionはバイナリを扱うのが得意なのが特徴の1つなのだけど
0896デフォルトの名無しさん
2011/01/03(月) 17:25:34VCS でファイルのタイムスタンプを保存されてうれしいことでもあるのか？
VCS まともに運用できないおっさんの屑管理者か?
0898デフォルトの名無しさん
2011/01/03(月) 19:31:44Subversionって、WebDAVで一般ファイルのバージョンを管理するバックエンドとして開発が始まったんじゃなかったっけ。
0899デフォルトの名無しさん
2011/01/03(月) 20:27:42>Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム
なにを根拠にいってるのかな？
>>893
>個々のファイルのタイムスタンプを保存しないのは、チェンジセットとは関係ない。
ですよねー
0900デフォルトの名無しさん
2011/01/04(火) 01:40:49いやそのblogの人に。
0901デフォルトの名無しさん
2011/01/04(火) 08:44:030902デフォルトの名無しさん
2011/01/04(火) 13:58:28ファイルのタイムスタンプを絶対視するヴァカは世の中に一杯いる。
特に窓ユーザには多いようだ。
タイムスタンプ信者に限ってTortoiseSVN使ってたりするし。
Subversionはこういうヴァカも大勢相手にしなきゃいけないから大変だよ。
0903デフォルトの名無しさん
2011/01/04(火) 14:17:01タイムスタンプに頼らざるを得ないからな
0904デフォルトの名無しさん
2011/01/04(火) 22:40:02src_20110104_copy3b_ver12_yamada_c.zip
0905デフォルトの名無しさん
2011/01/04(火) 22:46:49なんで？
TAG辺りをversion.hだかなんだかに放りこんどけばええんちゃう？
あとはdiffって下さいですまへんか？
0906デフォルトの名無しさん
2011/01/04(火) 23:21:53配布パッケージをつくるときは、各ソースモジュールのタイムスタンプが
last committed time になってる方がかっこよくないか? という私見。
つか git はどーだったか忘れたが、cvs, svn はそうなってた IIRC
0907デフォルトの名無しさん
2011/01/05(水) 00:59:55ずっと昔から、個人的に、タイムスタンプなんて信用しないからなぁ
# touch されたらその場でアウト
0908デフォルトの名無しさん
2011/01/05(水) 16:23:05レス数が900を超えています。1000を超えると表示できなくなるよ。