5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

バージョン管理システムについて語るスレ4

1 :デフォルトの名無しさん:2009/05/22(金) 00:02:10
バージョン管理システムについて語りましょう。

●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r11 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1215565366/
git スレッド [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1197798039/
Bazaarでバージョン管理【bzr>git,svn,cvs】 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1218083381/

●過去スレ
バージョン管理システムについて語るスレ
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/

2 :デフォルトの名無しさん:2009/05/22(金) 00:03:26
●関連サイト
CVS
http://ximbiot.com/cvs/cvshome/
Subversion
http://subversion.tigris.org/
Git
http://git-scm.com/
Bazaar
http://bazaar-vcs.org/
Mercurial
http://www.selenic.com/mercurial/wiki/
Darcs
http://www.darcs.net/
GNU arch
http://www.gnu.org/software/gnu-arch/index.html
monotone
http://www.monotone.ca/
Visual SourceSafe
http://www.microsoft.com/japan/msdn/ssafe/

●チュートリアル
Subversionによるバージョン管理(日本語訳)
http://subversion.bluegate.org/
Git入門
http://www8.atwiki.jp/git_jp/
Bazaar Documentation Overview
http://bazaar-vcs.org/Documentation
Mercurial の使い方のチュートリアル
http://www.selenic.com/mercurial/wiki/JapaneseTutorial

3 :デフォルトの名無しさん:2009/05/22(金) 00:05:18
githubの使い方を勉強するために、
誰か一緒にやりませんか?

ローグのPHP版を作るプロジェクトを。

4 :デフォルトの名無しさん:2009/05/22(金) 00:07:41
Subversion r11 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1230488758/

すまん、URLだけ間違えた

5 :デフォルトの名無しさん:2009/05/22(金) 00:10:57
ci -m '乙'

6 :デフォルトの名無しさん:2009/05/22(金) 01:08:11

  ヽ、   _ノ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   `'ー '´
     ○
      O
       o
                               , ‐'''^^"'''ー、、
                     ._..-'" ̄ ̄フ′       `'‐、
                   ./     /            \
                  /       .!                |
                 。'i        !     r',ヽ       ,!
                 i'゙          |       ヾ'-'        .l
                  '、       , '、              ,l.
                  、     ,‐'  ヽ、          ,/
                    `'┬ ' ´     ヽ、      ノ ヽ 
                     ! l´r`---z   / イ `'ルナサ
                     ヽ 'ヽ___/    /レ
                     ´_\`‐    ,__,// /:___________
                   ,.r '    ー-`  '´ - ‐  ̄     'ー 、
                  ,/  _,.                      ヽ
                  ,レ' ´                i      l
                /           ,             ,l      l
               。'i            !     r',ヽ    l l       l
        ,、r;,         i'゙            !      ヾ'-'    l. l     l
    _,r'´、l.レ'、         '、          , '、          ,/ l     ,.!v-、,_
   l L.., }   !         ハ、     , ‐'  ヽ、       ノ  /!    /`,/_,l L,
   l゙l ヘ」/   l.      /  `''┬ ' ´     `'ー----- '´ ,/ l   /  !:イ、_ノ l、

7 :デフォルトの名無しさん:2009/05/23(土) 01:00:15
ここ即氏判定あり?

8 :デフォルトの名無しさん:2009/05/23(土) 06:36:34
テンプレ追加

Bazaarメインドキュメント(ユーザーガイドやリファレンスの和訳)
http://sarabande.info/doc/bzr

9 :デフォルトの名無しさん:2009/05/24(日) 07:58:11
なんだよー、Mercurialにも名前付きブランチあるじゃねーか!はやく教えてくれよ!
チュートリアルみたら、ブランチするのにリポジトリをいちいちコピーしてたから、
ああMercurilaではGitみたいに、リポジトリの中で複数のブランチをもつことはできないんだと
ずっと思っていた。

これでgitを使う理由がなくなった。名前付きブランチ最高!


10 :デフォルトの名無しさん:2009/05/24(日) 11:16:42
svnにしとけ

11 :デフォルトの名無しさん:2009/05/24(日) 14:08:07
TortoiseHg 0.75なのですが、既存のローカルのリポジトリをcloneすると、
以下のようにファイルごとにWARNINGが出てしまいます。

WARNING: unko/my_fucker.css already has CRLF line endings
and does not need EOL conversion by the win32text plugin.
Before your next commit, please reconsider your encode/decode settings in

cloneした後は特に問題がないようなのですが、ちょっと怖いです。
どういうことなんでしょうか?

Mercurial.ini の内容
[extensions]
hgext.convert=
hgext.win32text=
hgext.win32mbcs=
fixutf8 = d:\software\Mercurial\hg-fixutf8\fixutf8.py

[encode]
** = cleverencode:

[decode]
** = cleverdecode:

12 :デフォルトの名無しさん:2009/05/24(日) 15:37:03
>>11
my_fucker.css が CRLF エンコーディングのままリポジトリに入ってるから、
コミットする前に CRLF -> LF の変換がいらないってことだと思うよ。

あと、fixutf8使うなら win32mbcs は外した方がいいと思うよ。

13 :デフォルトの名無しさん:2009/05/24(日) 16:45:35
>>12
あー、そういうことなのか…。
エラーメッセージはそのままで「CRLFで入っているから、変換が必要ないよ」ってだけか。

> あと、fixutf8使うなら win32mbcs は外した方がいいと思うよ。
了解です

14 :デフォルトの名無しさん:2009/05/24(日) 19:24:10
Windows環境において
Mercurialでfixutfを使おうと思い
http://www.asukaze.net/etc/vcs/hg-fixutf8.html

などのサイトを参考に
hg-fixutf8 を使うようにMercurial.ini の設定を行ったんですが

*** failed to import extension fixutf8 from "C:/Program Files/Mercurial/hg-fixutf8/fixutf8.py": [Errno 22] Invalid argument
というようなエラーが出てしまいます。

Mercurial 1.2.1 で 最新の hg-fixutf8 を使っているのですが、
何かほかに設定などが必要なのでしょうか?


15 :デフォルトの名無しさん:2009/05/24(日) 19:33:05
どうして茨の道を選ぶのか

16 :デフォルトの名無しさん:2009/05/25(月) 09:55:10
>>15
茨の道に立ち向かってこそ、進化するからさ。

17 :デフォルトの名無しさん:2009/05/25(月) 11:50:30
日本語環境で、あるいはWindowsでまともに動かない物をあれこれいじりまわしても
得る物は少ないと思うけど、やりたきゃやればの世界とも言える。

18 :デフォルトの名無しさん:2009/05/25(月) 12:38:41
オプソ系に参加してSVNは使っているんですが
別件で自分だけでやってるソースの管理をやろうと思っています。
非公開で手軽に運用できる組み合わせってどんな感じでしょうか?

わがままな要求としては自分で鯖は立てたくないんですが
突如サービスを打ち切る怪しさの無い外部の無料鯖で
あれば最強です。



19 :デフォルトの名無しさん:2009/05/25(月) 12:41:53
>>18
鯖立てるというか、開発マシンだか今使っているマシンだかでsvnserverを動かすのはだめなの?

20 :デフォルトの名無しさん:2009/05/25(月) 12:44:40
>>18
Windows なら TorotiseSVN 最強。

21 :デフォルトの名無しさん:2009/05/25(月) 12:44:52
>>18
svnだろうが、hgだろうが、gitだろうが、bzrだろうが、ローカルのファイルシステムにリポジトリ作れるから
それでいいんじゃなかろうか?
ローカルのファイルサーバー上でもいいし。

22 :デフォルトの名無しさん:2009/05/25(月) 12:46:39
>>14
どんな風にMercurial.ini書いたの?
部分的にうpうp

Mercurial 1.2.1はTortoiseHg付属じゃないやつ?

23 :デフォルトの名無しさん:2009/05/25(月) 13:59:53
tortoisehgは、v1.0.0になってから使っても遅くない

24 :18:2009/05/25(月) 14:33:04
>>19さん
とりあえずその方向で行ってみます。

>>20さん
オプソの方はTorotiseSVNでアクセスしてますのでクライアントは
これになりますね。

>>21さん
そうみたいですね。



25 :デフォルトの名無しさん:2009/05/25(月) 20:05:34
>>22
最初はTortoiseHg付属のものを使いましたが
>14の時と同じエラーが出たので、
TortoiseHgのMercurialをpathから取り除いて
新規にMercurial 1.2.1を公式サイトから取得してインストールしました。

Mercurial.iniで変更したのは、以下の部分だけです。

[extensions]
hgext.win32text =
fixutf8 = "C:/Program Files/Mercurial/hg-fixutf8/fixutf8.py"

hg-fixutf8は
>hg clone http://bitbucket.org/stefanrusek/hg-fixutf8/
で 24日に取得しました。

>hg version
のコマンドだけでも
*** failed to import extension fixutf8 from "C:/Program Files/Mercurial/hg-fixutf8/fixutf8.py": [Errno 22] Invalid argument
というエラーは表示されてしまいます。

26 :デフォルトの名無しさん:2009/05/25(月) 21:14:38
>>24
TortoiseSVN はリポジトリ作成も簡単に出来るぞ?

27 :デフォルトの名無しさん:2009/05/25(月) 23:12:04
せっかくなら Trac Lightning を導入するに 1 票。

28 :デフォルトの名無しさん:2009/05/26(火) 08:43:53
>>25
うちは、TortoiseHg付属のhg(1.2.1)だけど hg-fixutf8 でエラーは出ない
hg --helpしたときにちゃんと enabled extensions: の欄に入っているよ。

うちはこんな感じで大丈夫
fixutf8 = d:\software\Mercurial\hg-fixutf8\fixutf8.py

試してみて欲しいこと
・""でくくらない
・スペースを含むパスを入れない
・パス区切りを / じゃなくて \ にしてみる

29 :デフォルトの名無しさん:2009/05/26(火) 10:51:57
なにそれ

30 :デフォルトの名無しさん:2009/05/26(火) 12:32:12
TortoiseHg 0.7.5なんですが、少しお聞きします。

hg-fixutf8を導入すると、コマンドラインのhgを使う分には問題ない感じなのですが、
TortoiseHg の GUIから使おうとすると、cloneなどで経過が何もでず、
ウインドウを閉じた時にログ見なさいといわれるので、
C:/Program Files/TortoiseHg/hgproc.exe.log を見ると

Exception in thread Thread-1:
Traceback (most recent call last):
  File "threading.pyc", line 460, in __bootstrap
  File "hggtk\hglib.pyc", line 239, in run
  File "mercurial\extensions.pyc", line 112, in wrap
  File "T:\usr\local\win\develop\Mercurial\hg-fixutf8\fixutf8.py", line 140, in f
  File "T:\usr\local\win\develop\Mercurial\hg-fixutf8\win32helper.py", line 84, in rawprint
LookupError: unknown encoding: cp0

などといわれてしまいます。
TortoiseHg では、hg-fixutf8が使えないのでしょうか?

31 :デフォルトの名無しさん:2009/05/26(火) 12:49:36
いいかげんにして

32 :デフォルトの名無しさん:2009/05/26(火) 13:30:51
誰も私 わかってくれない

33 :デフォルトの名無しさん:2009/05/26(火) 14:04:18
もういやよ、こんなの

34 :デフォルトの名無しさん:2009/05/26(火) 17:40:04
いやよいやよも好きのうち

35 :デフォルトの名無しさん:2009/05/26(火) 21:21:04
>>30
GetConsoleOutputCPを非コンソールアプリから呼ぶと0を返すのが問題みたいだね
とりあえず932に決め打ちしてみたら?

36 :デフォルトの名無しさん:2009/05/27(水) 00:19:29
FIX: When you run the Visual SourceSafe 2005 Analyze.exe utility to analyze a large Visual SourceSafe database,
the Visual SourceSafe 2005 Analyze.exe utility crashes
http://support.microsoft.com/kb/969517/en-us

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=969517

37 :デフォルトの名無しさん:2009/05/27(水) 11:53:34
>>35
サンクス。該当箇所みてみたら確かに、そんな感じですね・・・。

これどこに報告すればいいんだろ?fix-utf8のフォーラムとかってあるんだろか?Issueにいきなり登録しちゃったらまずいかな?

38 :デフォルトの名無しさん:2009/05/29(金) 00:31:52
svk終了のお知らせ
lists.bestpractical.com/pipermail/svk-devel/2009-May/001224.html

* 機能追加、性能改善は行わない。
* 少なくとも1年半は最新svnへの対応を続ける。
* svn 1.6対応版は来週リリース。

おつかれさま



39 :デフォルトの名無しさん:2009/05/29(金) 22:20:32
>>38
たしかにSVKはおつかれさまだし、そうしたい気持ちも分かるんだけど、
svn同士のマージでは重宝してるんだよなぁ。
Subversionのmerge tracking試してみるかなぁ。

40 :デフォルトの名無しさん:2009/05/30(土) 05:26:49
えええっ!
じゃぁ、Windowsでsvnリポジトリを分散環境に持ち出してまた戻すってのを
実現するには、どうすりゃいいんだ?

41 :デフォルトの名無しさん:2009/05/30(土) 06:05:02
つ git-svn

42 :デフォルトの名無しさん:2009/05/30(土) 07:15:05
マジサンクス。
試してみる。

43 :デフォルトの名無しさん:2009/05/30(土) 10:35:47
>>40
bzr-svnとかどうでしょう。
bzrのWindowsインストーラには含まれてます。


44 :デフォルトの名無しさん:2009/05/30(土) 12:01:58
>>40
hgsubversionとかどうで(略

45 :デフォルトの名無しさん:2009/05/30(土) 14:27:42
次にお前は、日本語のコミットログが変換で(ry

46 :デフォルトの名無しさん:2009/05/30(土) 21:12:41
git-svn の完成度は知らない。
hgsubversion はまだ read-only.

bzr-svn は 0.6 (bzr 1.15とセット) でかなり完成度高いけど、
規模の大きいsvnリポジトリをネットワーク経由で取り込もうとすると
キャッシュを全部メモリに置こうとしてしまうので、段階的に取り込む
テクニックが必要。
次のバージョンにはキャッシュの制御が入ると思う。

47 :デフォルトの名無しさん:2009/05/30(土) 21:38:38
git-svn の完成度は高い。
どう高いかは知らない。


48 :デフォルトの名無しさん:2009/05/30(土) 21:43:22
git-svnはperlで描かれているぐらい完成度が高い。

49 :デフォルトの名無しさん:2009/05/30(土) 22:17:41
書かれている言語によってアプリケーションの完成度が決まるとは
ハツミミです

50 :デフォルトの名無しさん:2009/05/30(土) 22:46:18
git-svnは使い始めたときはちょっと不安があったけど、
実際使ってみるとまったく問題ないね。仕事で使ってる。
ただ常にsvnにrebaseしていかないといけないので、svnを止めたくなる。

51 :デフォルトの名無しさん:2009/05/30(土) 23:42:01
git-svn が今のところ一番使いやすい。たぶん今後も、そうだという気がする。
svnもgitも他mercurialやbazaar等、全部branchやrepositoryの考え方が違う。
考え方が違うものを擦り合せるなら、いろいろ出来た方が上手くいく。
ただ単体で使うなら評価は、また別。

52 :デフォルトの名無しさん:2009/05/31(日) 06:01:06
>>51
少なくともコマンド、オプション体系に関しては、gitが他の3つに対して
圧倒的に特殊で覚えにくいと思うけどなぁ。
bzr-svn はかなり透過的にsvnリポジトリを扱えるから使いやすいよ。

53 :デフォルトの名無しさん:2009/05/31(日) 11:35:01
そんな中、あくまでdarcsを使う俺なのであった

54 :デフォルトの名無しさん:2009/05/31(日) 14:18:01
svn(TortoiseSVN) が日本語に寛容なのを良いことに、俺リポジトリの俺資料メモなどで
コミットログ、ファイル名に日本語使いまくりな私が svk から移行する先で一番スムーズに
行けそうなのはなんでしょうか。

そんなものは無いから死ぬまで svk 、という現状なのかなぁ。。。 orz


55 :デフォルトの名無しさん:2009/05/31(日) 16:56:43
>>54
bzr-svn の 0.6 から encode/decode がしっかりされるようになってるよ。
bzrの GUI も開発が停滞気味だったけど最近動きが出てきた。
早ければ今年中にもbzrが最強のsvnクライアントになるんじゃないかな。

56 :デフォルトの名無しさん:2009/05/31(日) 17:36:17
bzrはなんかスペックだけは最強で実際は・・・というなんかアレに見える

57 :デフォルトの名無しさん:2009/05/31(日) 17:56:12
>>56
まだいろいろ開発中だからねぇ。
bzr 2.0 が出るくらいに移行考えればいいと思う。

58 :デフォルトの名無しさん:2009/05/31(日) 18:49:39
分散バージョン管理関係は、WindowsでTortoiseなんとかで日本語対応もとなるとあと二年は必要だな。
TortoiseSVNも3年くらいは不安定すぎてよくOS巻き込んで落としたり、日本語だめだめだったからな。

59 :デフォルトの名無しさん:2009/05/31(日) 19:09:13
>>54
UTF-8環境のUnixならどれでも好きなのを選べばいいよ

60 :デフォルトの名無しさん:2009/05/31(日) 19:10:36
文字コードはそろそろ統一してほしい

61 :デフォルトの名無しさん:2009/05/31(日) 19:59:41
>>60
WindowsはUTF-16、他は全部UTF-8、あとは相互変換、これで9割問題ない。
問題は外人がUNICODEを気にせずアプリを作ってくることだ。
いつの時代も戦争があるように、このアホな訴えは繰り返される。
いつになったら学習するんだか…。

Windowsだと、.NETアプリ=UNICODEが標準みたいに外人が作っても大体が問題なかったりする環境もあるが、
それ以外だとなかなか統一されない状況だよな。

62 :デフォルトの名無しさん:2009/05/31(日) 21:13:21
リポジトリ内での話に限定して
ファイル名はUTF-8で統一していいと思うけど
データは自由にさせてほしいなぁ。


63 :デフォルトの名無しさん:2009/05/31(日) 22:40:10
>>61
それほど単純では無いだろ
Macと*nuxでは、同じ UTF-8 でも正規化の方法が違うし
Windowsとは BOM の問題もある

64 :デフォルトの名無しさん:2009/05/31(日) 23:26:56
「〜」の誤変換も根深いよな

65 :デフォルトの名無しさん:2009/05/31(日) 23:42:02
なんで「〜」じゃないほうのフォントはぐにょってなってるんだ(MSゴシック等)
上下反転じゃだめなのか、それとも区別つきやすいようにわざとしてるのか

66 :デフォルトの名無しさん:2009/06/01(月) 00:00:47
>>61
UNICODEなのに日本語通らないプログラム書いてくれるのが、英語圏の人。
Microsoftの名前で出してるのに日本語通らないのあったりするし。

67 :デフォルトの名無しさん:2009/06/01(月) 02:39:11
>>61
コマンドプロンプトがUTF-8なりUTF-16にまともに対応してくれれば
いいんだけど。
chcp 65001 とかするとUnicode化して万歳どころか日本語全滅する。

68 :デフォルトの名無しさん:2009/06/01(月) 03:03:48
MSはMS専用 UTF規格だから、更に混乱。

しかも、マッピングを重複させているので、
正規のUTFと可逆的な相互変換は事実上不可能。

UTF間ですらコンソーシアムと共通性がない。


69 :デフォルトの名無しさん:2009/06/01(月) 05:34:08
MS専用 UTF規格?

70 :デフォルトの名無しさん:2009/06/01(月) 10:40:56
>>67
ふと思ったんだけど、PowerShellなら
どうだろうか?

71 :デフォルトの名無しさん:2009/06/01(月) 10:43:34
>>70
PowerShellだって、コマンドプロンプト上で動くシェルなのよね・・・
だから日本語をUnicodeで入力とかできない。

いつまでこんなクソ仕様のままにしてるんだろうな、MSは。

72 :デフォルトの名無しさん:2009/06/01(月) 10:45:58
M$のOSは日本語の文字コード変わりすぎなんだよ。
sjisなんかcp932なんかunicodeなんかはっきりしやがれ。

73 :デフォルトの名無しさん:2009/06/01(月) 10:46:11
>>69
メモ帳でUTF8保存すると分かる

74 :デフォルトの名無しさん:2009/06/01(月) 12:05:51
>>73
メモ帳がちょっと異常なだけだろ。


75 :デフォルトの名無しさん:2009/06/01(月) 12:06:36
メモ帳がMS規格に無理矢理更新するようになってるんだよね
VisualStudioもそうだけど

76 :デフォルトの名無しさん:2009/06/01(月) 12:21:15
MS規格ってなんなの?

77 :デフォルトの名無しさん:2009/06/01(月) 12:25:47
>>76
テキストファイルの終端を改行じゃなくいきなりEOFにするとか?

ソースで最後に
}
があるとなんとなくだけど
}[改行]
[EOF]
としたいけど
VSはなぜか
}[EOF]
とするはず

とにかく余計な事をするな

78 :デフォルトの名無しさん:2009/06/01(月) 12:27:08
http://d.hatena.ne.jp/hasegawayosuke/20041203/p3
>Unicode が必ずしも必要というわけではないアプリケーションならば、Shift_JIS や EUC-JP を利用するというのも、セキュアな実装へのひとつの手段かも知れません。

79 :デフォルトの名無しさん:2009/06/01(月) 12:48:10
>>77
いやそっちじゃなくてMSのUTFというのがわかんない

80 :デフォルトの名無しさん:2009/06/01(月) 12:49:16
>>79
ky

81 :デフォルトの名無しさん:2009/06/01(月) 13:16:46
>>78 この文脈でそれを引っ張り出してくる意味がわかんない

82 :デフォルトの名無しさん:2009/06/01(月) 14:04:18
>>79
エスパーすると
たぶんBomつきUTF8の事を言ってるのでは

83 :デフォルトの名無しさん:2009/06/01(月) 21:44:33
Mercurial で、変更箇所の一部だけをコミットすることはできますか。
Git だと git add -p file.txt とすることで、変更箇所を選択してコミットできます。
同じことをMercurialでできないかなと思い質問しました。

84 :デフォルトの名無しさん:2009/06/01(月) 22:08:01
>>82
いまどきそんな勘違いするだろうか

> UTF間ですらコンソーシアムと共通性がない。
とかいってるからもっと違う話だと思うが

85 :デフォルトの名無しさん:2009/06/02(火) 13:21:17
>>83
変更箇所ってファイル単位?だったら単純に

$ hg commit -m "hoge." file.txt

でファイル指定すればできるけど。そうでなくて?

86 :デフォルトの名無しさん:2009/06/02(火) 13:53:34
>>85
そうではなくて、ひとつのファイルの中に複数の変更箇所があった場合に、
その中から任意の変更箇所だけを指定してコミットする方法です。

たとえばあるファイルを変更したときに、新機能による変更とバグフィックスによる変更とが存在したとき、
まずバグフィックスのための変更だけをコミットし、その次に新機能のための変更を別コミットで登録したい、ということです。

87 :デフォルトの名無しさん:2009/06/02(火) 14:29:19
>>86
ある方が珍しいと思う。Git はできるのか。変わってんな。
ほかのバージョン管理ツールは、変更前にブランチなり
クローンなりするスタイルだと思う。

88 :デフォルトの名無しさん:2009/06/02(火) 17:41:11
>>86
bzrでは、bzr shelve/unshelveでできますね。
hgにもあったような気がしますが。


89 :デフォルトの名無しさん:2009/06/02(火) 17:51:46
Mercurialでもあるってsubversionスレで見た気がする(大昔だが・・・)
でも、bazaarにもあるとは知らんかった、いつの間にか分散VCSでは標準的な機能になってたんだな。

90 :デフォルトの名無しさん:2009/06/02(火) 18:08:27
>>86
バグフィックス用と新機能用とにリポジトリを分けた方が幸せになれる気がするんだが。

91 :デフォルトの名無しさん:2009/06/02(火) 18:26:38
>>86
その用途はわかるなーGit使ってるけどそういう機能しらなかったw
改造目的でソースいじってるうちにバグとか死んでる部分とか見つけちゃって、
ついそのまま流れでやってしまうことあるわ。
改造終わってからやろうとすると、そのまま忘れてしまいそうで。。。

急いでる時はそのまま混ぜてコミット作っちゃったりもするけど、
ちゃんとする時はエディタでundoして2回に分けてコミットしたりしてたw

92 :デフォルトの名無しさん:2009/06/02(火) 18:42:00
Mercurial Queuesっていうやつかな
ttp://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html

93 :デフォルトの名無しさん:2009/06/02(火) 23:46:14
>>86
record extension 使えばできる

94 :デフォルトの名無しさん:2009/06/03(水) 03:53:49
>>67
スレ違いになりますが、
WindowsだとコマンドプロンプトのUTF-8の扱い問題が結構痛いですよね。

Windows上でRuby on Railsで開発してますが、UTF-8が扱えないために
けっこう面倒な場面があります。
標準のrails console(Rails用インタラクティブシェル)でUTF-8入力したり表示したりとかがダメポ。
UTF-8のログ表示くらいは出力だけなので、cygwin+UTF-8ターミナルか、もしくはcygwin+UTF-8DLLで行けますが。
一方、rails consoleの方は、readlineのせいかcygwin上からだと何故か使えないし…。(rubyのirbもですが)

Railsに限らず、mysqlのコンソールでも同じだと思います。

chcp 65001は、最近になってから(たぶん、SPがあたってから)使い物にならなくなってしまっている現状。

昨今のwebアプリ開発に不都合多いWindows涙目( ´・ω・`)

95 :デフォルトの名無しさん:2009/06/03(水) 09:40:42
>>94
railsってかRubyってコンソールに出力するencodingを自動判別とかしてくれないんだ・・・

Pythonなら print u"あいうえお" とすると、 あいうえお という Unicode 文字列を
sys.stdout.encoding (Windowsの場合はcp932) に encode してから出力するから、
cp932にencodeできる範囲では問題ない。
って、これは言語スレの話題か。

96 :デフォルトの名無しさん:2009/06/03(水) 11:00:52
それ自動判別じゃないし、出力を設定どおりにエンコードするのはRubyでもできるし

97 :デフォルトの名無しさん:2009/06/03(水) 11:17:16
>>96
sys.stdout.encoding は自動で設定されている >自動判別
出力を設定どおりにエンコードするのなら、なんでRailsはutf-8のコンソールを
用意しないといけないの?

って、本気で言語スレネタだ、止めようぜ。

98 :デフォルトの名無しさん:2009/06/03(水) 11:58:21
ちょいとgitの質問よろしいでしょうか?

 git status

だとコンソールにカラー表示されます。

 git status | less

みたいにすると、カラー表示されません。
less側のカラー対応はすでに行っていまして、ls --color(だっけ)|lessとかでちゃんとカラー表示されます。

そこで、

git config --global color.branch always
git config --global color.diff always
git config --global color.interactive always
git config --global color.status always

みたいにして、常にカラー表示しようとするんですが、
そうすると、周辺ツールなどで予期しない結果がアプリにわたってしまうためか不具合がおきます。
例えば、redmineでgitリポジトリを使うと、コミットログが反映されなかったりします。

そこでお聞きしたいのですが、
・周辺ツールでも不具合がおきない
・git status | lessではちゃんとカラー表示できる(git diffとかも)

両方を両立する方法はないでしょうか?
gitでカラー表示強制するコマンドラインオプションを探していたのですが、見当たりませんでした…

99 :デフォルトの名無しさん:2009/06/03(水) 16:36:13
hg convertでsvn->hgに変換しているんだが
hgでリビジョンを指定するときにr1234形式で書く方法ってない?
不便すぎる


100 :デフォルトの名無しさん:2009/06/03(水) 18:58:01
>>99
r1234形式のタグを付ければいいんじゃない。簡単なスクリプトで作れそう

101 :デフォルトの名無しさん:2009/06/03(水) 21:01:07
>>99
changeset: 1:82e55d328c8c
となっていたときに、以下のどちらでもOKなわけだが。
$ hg log -r 1
$ hg log -r 82e55d328c8c

ttp://www.selenic.com/mercurial/wiki/JapaneseTutorialHistory


102 :デフォルトの名無しさん:2009/06/03(水) 21:15:50
>>101
svnのリビジョンのことだと思うぞwww

103 :デフォルトの名無しさん:2009/06/04(木) 02:56:33
おれもよくわかってないけど、gitって出力先が端末かどうかで処理を変えているよね。だから・・・

>>98
>そこでお聞きしたいのですが、
>・周辺ツールでも不具合がおきない

こうするには、デフォルトの挙動を変えないようにしたまま、

>・git status | lessではちゃんとカラー表示できる(git diffとかも)

このときだけ強制的にカラー表示するように指定するしかないんじゃないかな。
つまり git diff --color | less とか毎回するわけ。
でもめんどくさいから、$HOME/.gitconfig に
[alias]
 cdiff = diff --color
と書いておけば、デフォルトの挙動を変えないまま git cdiff | less でカラー表示になる。
これくらいが落としどころでしょうか。



104 :デフォルトの名無しさん:2009/06/04(木) 03:06:39
>>91
>改造目的でソースいじってるうちにバグとか死んでる部分とか見つけちゃって、
>ついそのまま流れでやってしまうことあるわ。
>改造終わってからやろうとすると、そのまま忘れてしまいそうで。。。

まさにその通りです。

>>93
>record extension 使えばできる

ありがとうございます!これですよね。
ttp://www.selenic.com/mercurial/wiki/RecordExtension
まさに、これがほしいものでした。こんなextensionが標準でついてくるんだから、Mercurialはやればできる子。
さらに、行単位でcommitする・しないを選べるextensionもあるんですね。これは git add -p より便利そう。
ttp://www.selenic.com/mercurial/wiki/CrecordExtension
あざーっす!


105 :デフォルトの名無しさん:2009/06/04(木) 20:12:40
>>100
しかたがないので、こんなのを書いてみた:
#!/bin/sh
ERROR() {
echo "*** error ***"
exit 1
}
hg convert ${SVNREPO} ${HGREPO} || ERROR
awk '/^svn:/ {
r=$1
sub(/^svn:[-0-9a-f]*@/, "", r)
print $2 " r" r
}' .hg/shamap >.hgtags-new || ERROR
mv .hgtags-new .hg/localtags


106 :デフォルトの名無しさん:2009/06/05(金) 06:58:44
ちょいと疑問点があるんだけど聞かせてくれやしないかい?

・AとBというプロジェクトがある。
・AとBはすごく似ていて、外部依存のDB以外ほとんど同じ構造(違うのは設定ファイルくらいと少しの追加ファイル)
・イメージとしては、AとBは同じCMSを使っていて、一部プラグインと設定ファイルだけが違う
・CMSのアップデートなどがけっこう頻繁かつ面倒なので、片方の影響を簡単にもう片方に反映させるようにしたい
・ただ、AとBの一部の設定は(機密などの理由で)お互い共有したくない

この場合、分散バージョン管理など使うとしたら、
どう運用したもんだろう?
できれば、同じリポジトリから派生させて、
共通化できるところは共通化したいものなんですが
(共通化というかpull、updateで簡単に片方でアップデートしたのをもう片方に適用できないか?とか)

107 :デフォルトの名無しさん:2009/06/05(金) 07:02:12
>>106
すいません追加です。
話し聞いたら、普通に管理すれば?という感じなのですが、

> ・ただ、AとBの一部の設定は(機密などの理由で)お互い共有したくない
ここがポイントで、
片方のリポジトリを納入先とか誰かに渡す、などするときに機密情報が入っていると困るので、
同じリポジトリに両方の設定をできれば入れたくないなどという話なのです。

108 :デフォルトの名無しさん:2009/06/05(金) 09:15:00
>>107
プロジェクト固有の部分だけ Git ならローカルブランチ、Mercurial なら MQ あたりで管理するのはどうよ

109 :デフォルトの名無しさん:2009/06/05(金) 09:16:04
3つリポジトリを用意すればいいじゃん。或いは、下のようなディレクトリ構成にしておいてexport用のスクリプトを準備しておくとか。

root
|
+-config_for_A
+-config_for_B
+-common_sources

110 :106:2009/06/05(金) 12:34:29
ありがとうございます。

>>108
ローカルブランチはpushしてもリモートに送られたりしないのかな…?
ちょっと見てみます。

>>109
それも考えたのですが、
Redmineとかのプロジェクト管理ソフトだと1リポジトリしか扱えなくて、どうしたもんだろうというのがあります。

ローカルブランチ調べてたのですが、
git の submodule使ったらもしかしたら、解決できるのかな?

111 :デフォルトの名無しさん:2009/06/05(金) 22:46:15
>>110
>git の submodule使ったらもしかしたら、解決できるのかな?
submoduleはSubversionのexternalsみたいに、リポジトリ内に別のリポジトリの
ものを展開して配置したい時に使う感じなので違うと思う
(たとえばMTとその配下のプラグイン郡)

俺なら>>106のような場合には、まず両方に共通な部分を1つのブランチに
しておいて、アップデートとかのメンテはここで行う。
そんで、各々のプロジェクトではそこからフォークして固有の部分を追加
(Gitならcloneして随時rebase)
あと、共通なリポジトリにはpushできないようにReadonlyにするなりする。
って感じでどうだろね。

112 :デフォルトの名無しさん:2009/06/06(土) 09:50:40
>>106
hgならmq使えばできるし、うちでも実際にやってるな。

hg clone repos porjectA
hg clone repos projectB

cd projectB
hg init
hg qnew hoge_patch
==edit==
hg qref -g

あとは必要に応じ
hg qpop -a
hg pull
hg up
hg qpush -a

これで中央レポジトリの最新を共有できてローカルの変更を維持できる。
ローカルの変更をコミットしないで管理したいならおすすめ。

113 :112:2009/06/06(土) 09:52:41
おっとミスった。
○ hg qinit
× hg init

114 :デフォルトの名無しさん:2009/06/06(土) 14:52:27
>>112
projectBのメンバー間でパッチを共有したいときはどうする?


115 :デフォルトの名無しさん:2009/06/06(土) 21:04:46
パッチをレポジトリに入れたらええんでないの?
それがいいのかわからんが

116 :デフォルトの名無しさん:2009/06/07(日) 02:49:04
>>105
FreeBSD headでつかってみたら
r193589まであるので
hg log -l1が
2.072u 0.191s 0:02.31 97.8% 1200+1755k 0+0io 0pf+0w
だったのが、.hg/localtagsありだと
7.106u 0.478s 0:07.62 99.3% 1182+1727k 0+0io 0pf+0w
までおそくなった。


117 :デフォルトの名無しさん:2009/06/08(月) 02:10:43
subversionリポジトリをmercurialに移行しようとしたができない。
標準添付の hg convert -s svn がどうやってもエラーになる。
やっぱgitにしたほうがいいのか。

118 :デフォルトの名無しさん:2009/06/08(月) 02:34:33
bzr-svnを勧めたいところだが、hgを使いたいなら hgsubversion を使うのも良いかもな。
Python の svn から hg への移行では hgsubversion を使うことになりそう。
hg convert は、 http://www.selenic.com/mercurial/wiki/ConvertExtension を見るかぎり、
特にWindowsで動かすのは面倒そうだ。

119 :106:2009/06/08(月) 09:07:17
レス遅れた。サンクス

>>111
git の submoduleはちょっと違うのか。プラグインだけ別管理ってときなのね。

gitのrebase知らんかった。調べてみる。

>>112
面白い仕組みですね。hg の mq拡張?ですか、試してみます。

120 :デフォルトの名無しさん:2009/06/08(月) 18:05:45
>>118
>hgsubversion

これってmercurialをsubversionのフロントエンドとして使うextensionじゃね?
svnリポジトリをhgリポジトリに変換するものじゃないから、hg convert とは違うような。

121 :デフォルトの名無しさん:2009/06/08(月) 21:08:39
hgsubversionはgit-svnやbzr-svnと比べて見劣りがするな。
今のところ一長一短といった感じで、hg,git を廻して使ってるんだが、
hg convert で、git から convert する時、branch が名無し(default)に
なるのは、どうにかならないかな。

122 :デフォルトの名無しさん:2009/06/08(月) 21:30:18
『入門Mercurial』(FUJIWARA Katsunori著、秀和システム) を読んでいます。
p.70 に

> 対象となるリビジョンが、「作業領域の親リビジョンの直系の子孫となるリビジョン」の場合、
> 実はMecurialでも未コミットベースのマージを行なうことができます。

とあるんですけど、これの意味が分かりません。
「作業領域の親リビジョンの直系の子孫となるリビジョン」ってどんなのですか?

123 :デフォルトの名無しさん:2009/06/08(月) 21:39:54
>>122
glogでいうと
o
|
o
|
@
|
の状態。
作業領域の親リビジョンの直系の子孫となるリビジョンは
@よりも上にあるのoのこと。

124 :デフォルトの名無しさん:2009/06/08(月) 22:33:59
>>123
ありがとうございます。
そもそも '作業領域の親リビジョン' という表現がわかんないのですが、
これは現在作業中のリビジョンのことですか?
#なんで '親リビジョン' と呼ぶのかという疑問が。。。


125 :デフォルトの名無しさん:2009/06/08(月) 23:34:53
TortoiseHGは素晴しい
Windowsで使うには種々問題もあるが、Linuxで使う分には問題が無い
hgtk log で、GUI表示しながら、commit は CUIが、現時点で最良かもしれない

126 :デフォルトの名無しさん:2009/06/09(火) 01:01:12
>>120
svnのフロントエンドとしてhgを使うといことは、svnリポジトリからhgリポジトリの形で
checkoutできるって事だよね。

127 :デフォルトの名無しさん:2009/06/09(火) 12:01:39
>>125
nautilus 連携のやつ?
説明どおりに導入してみたけど、プロパティにカレントバージョンが表示されるだけだ。
Debian lenny だからかな。

128 :デフォルトの名無しさん:2009/06/09(火) 12:14:28
>>124
hg parentsがあるから、そういうものだとおもうしかない。
気持ちとしてはこんな感じではなかろうか

w
|
o |
| |
|/
@
|


129 :デフォルトの名無しさん:2009/06/09(火) 12:18:45
>>127
nautilus連携は、あまり使ってないな。
TortoiseHG に付属する CLIツールの hgtk だけ使ってる。
hgtk log で立ち上げとくと、commit以外のほとんどのことが出来る。
kdiff3と組合せると、更に使い易い。

130 :デフォルトの名無しさん:2009/06/09(火) 12:19:10
>>128
ずれた
w working dir
|
| o tip
| |
|/
@ parent of working dir
|


131 :デフォルトの名無しさん:2009/06/09(火) 14:21:33
>>130
何度もありがとうございます。
working dir がまだコミットされていない仮想的なリビジョンということでしょうか。
うーん、なんかしっくりこない。

132 :デフォルトの名無しさん:2009/06/10(水) 09:57:24
>>129
ああ、hgtk ね。いろいろあるからどれかわからなかった。
確かにこれはすばらしい。ログさえグラフで見られれば、
後はコマンドラインで不満はないし。

133 :デフォルトの名無しさん:2009/06/10(水) 10:27:32
Perlに逃げられたくせに必死だなw
ttp://atmarkit.blog.corp.itmedia.co.jp/archives/50859571.html

134 :デフォルトの名無しさん:2009/06/10(水) 11:13:53
>>133
Perfoce必死すぎwww

135 :デフォルトの名無しさん:2009/06/10(水) 13:48:21
お前ら、git mvならぬgit cp コマンドみたいなのはないんでしょうか?
gitではコピーしたという記録は残せない?

136 :デフォルトの名無しさん:2009/06/10(水) 14:56:55
gitで、とある文字列をコミットメッセージに含むようなコミットIDを取り出したいんですが、なにかいい方法ありますか。
mercurialの--template機能がgitにもあればいいんですが。

137 :デフォルトの名無しさん:2009/06/10(水) 15:22:00
git log --grep=PATTERN で、パターンをログに含むようなコミットだけを選ぶことができました。

138 :デフォルトの名無しさん:2009/06/10(水) 18:10:40
wordやパワーポイントのバージョン管理は無理なのでしょうか
全てバイナリーになってしまうのでしょうか

139 :デフォルトの名無しさん:2009/06/10(水) 18:22:02
そうだと思います。
バイナリでもバージョン管理は可能なので、使えばいいと思います。

140 :デフォルトの名無しさん:2009/06/10(水) 18:23:48
ごめん、書き方が悪かった。
> 全てバイナリーになってしまうのでしょうか
これについてはその通りです。

> wordやパワーポイントのバージョン管理は無理なのでしょうか
無理ではありません。
バイナリファイルでも問題なくバージョン管理できます。
ただしお使いのバージョン管理ソフトによっては、日本語ファイル名の扱いに問題がある場合があります。



141 :デフォルトの名無しさん:2009/06/10(水) 18:37:38
>バイナリファイルでも問題なくバージョン管理できます。
conflictした場合の処理が、テキストファイルの場合よりも面倒になります。



142 :デフォルトの名無しさん:2009/06/10(水) 18:39:58
ロックしろよ

143 :デフォルトの名無しさん:2009/06/10(水) 18:57:19
branch からの merge での conflict は lock だけでは対応しきれません。

144 :デフォルトの名無しさん:2009/06/10(水) 19:03:04
そんなことが出来ると思うお前の脳みそをどうにかしろよ

145 :デフォルトの名無しさん:2009/06/10(水) 19:21:48
>>141
たしかにそうでした。ごめんなさい。
バイナリファイルが衝突したときって、どうしたらいいの?
分散型だとロックできないよね。

146 :デフォルトの名無しさん:2009/06/10(水) 20:25:52
uze-yo

147 :デフォルトの名無しさん:2009/06/10(水) 21:52:01
>>135
Gitはファイルを追跡するのではなくコンテンツを追跡する何たらかんたら
なのでそういう仕組みはなし。
ただコミットを見せるときに、これはどう見ても移動したな、
と教えてくれないこともない。

148 :デフォルトの名無しさん:2009/06/10(水) 22:59:44
>>133
Yahoo!って学生だったんだな
MercurialじゃなくてGitを引き合いに出したのは
MercurialだとSunとかMozillaとかXenとかどでかいのたくさんあるからだろw

149 :デフォルトの名無しさん:2009/06/11(木) 01:33:03
>>145
Wordドキュメントなら、Wordを立ち上げて手作業でマージする

150 :デフォルトの名無しさん:2009/06/11(木) 09:07:31
実際おまいらPerfoce知ってた?俺は始めて聞いたわ。

151 :デフォルトの名無しさん:2009/06/11(木) 09:17:31
>>150
俺は「Perlは何使ってんだろ」って調べた時に知った
Gitに乗り換えるよりも結構前だけど

152 :デフォルトの名無しさん:2009/06/11(木) 09:29:59
社内で使ってるプロジェクトの話は聞いたことある。
アセット管理的な部分も含めて、性能はかなり良い、らしい。



153 :デフォルトの名無しさん:2009/06/11(木) 10:43:20
Googleの要求に耐えられるバージョン管理ソフトはPerforceだけ!

実際、Googleではバージョン管理はPerforceのリポジトリが1コだけで、
そこにすべてのプロジェクトをぶちこんでいるらしい。
それでも問題なくスケールして管理できるんだから、すごいよね。

154 :デフォルトの名無しさん:2009/06/11(木) 10:46:08
すげえええww
普通分けるよな…

155 :デフォルトの名無しさん:2009/06/11(木) 11:18:04
従業員数万人が1つのリポジトリに同時アクセス・・・
それで問題がないとは、恐れ入った。

つうか、リポジトリをひとつにしている理由がわからんが。

156 :デフォルトの名無しさん:2009/06/11(木) 11:41:15
最近Bazaar使い始めました。いいですねこれ。
bzrはちょっと打ちづらいけど…

ところで作業コピー作らないで、リポジトリ直のファイルを弄って
るんですが、そういう使い方でもいいんでしょうかね?


157 :デフォルトの名無しさん:2009/06/11(木) 11:55:40
>>156
きっと、君がリポジトリ直と思っているのは作業コピーだよ。
bzr init-repo じゃなくて bzr init したでしょ? それは stand-alone といって、
作業コピーの中の .bzr/ 以下にリポジトリが一個付いてくる形式。

158 :デフォルトの名無しさん:2009/06/11(木) 12:03:37
Perforce は会社で使ってるけど、管理者じゃないので、GUI がよくできてるく
らいしかわからないなあ。

リポジトリとローカルの作業コピーの対応関係がサーバー側に記憶されていて、
別なマシンからも見られるのはおもしろいと思った。


159 :デフォルトの名無しさん:2009/06/11(木) 12:39:02
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20010712/3/
Perforceは1ライセンス12万円?
2001年の記事だけど
今はいくらぐらいなんだろ

160 :デフォルトの名無しさん:2009/06/11(木) 12:50:41
>>159
http://www.perforce.com/perforce/price.html

商用だけれど JIRA などのツールが対応してくれているのも大きいと思う。


161 :156:2009/06/11(木) 13:10:30
>>157
はい、おっしゃる通り bzr initのほうです。
この場合はSubversionのリポジトリとはちょっとイメージが違う感じ?

Subversion使ってた頃は、
リポジトリ作って、そこにインポートして、チェックアウトして…と面倒な感じでしたが、
Bazaarだとチェックアウトしないでそのままのディレクトリで作業できるのがいいです。
自分で使う分にはもうSubversionには戻れませんね。


162 :デフォルトの名無しさん:2009/06/11(木) 23:21:48
>>155
上でも出ててけど、
はてなも確か以前はSubversionの1つのリポジトリだったはず・・・

163 :106:2009/06/11(木) 23:34:29
git rebaseをちょっと使ってみているのですが、ちょっと疑問点があり、質問させていただきます。

mergeの代わりにrebaseする(例えば git pull --rebase)
ことで、毎回常にpull元の先頭にパッチをあてた感じになる、ということは、
gitkなどでログを見て確認できました。

そこで、ちょっとテストしていてふと思ったのですが、
pullして何度かコミットした後、
git pull --rebaseすると、
何度も修正して、git rebase --continueを繰り返さないといけません。
こんなものなのでしょうか?

pushしなければ、pull元に変更点があってpullのたびに毎回何度も
git rebase --continue しないといけないと思うと面倒くさすぎるのですが、
なんとかならないのでしょうか?

164 :デフォルトの名無しさん:2009/06/12(金) 00:06:31
>>106
git rerere
http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

165 :デフォルトの名無しさん:2009/06/12(金) 06:12:25
>>163
rebaseはコンフリクトしなければ普通に終わるはずなんだけど、
originで修正するようなところをローカルでも変更する(しかもoriginには
取り込まれない)なら、rebaseじゃなくてmergeかもね。
いったいどんな部分でぶつかってるんだろう。。。まさか設定ファイルとか。。。

>>164
rerereなんてしらなかったばい!

166 :デフォルトの名無しさん:2009/06/12(金) 08:01:42
おーでかーけでーすかー

167 :デフォルトの名無しさん:2009/06/12(金) 09:56:19
レレレのレー

168 :デフォルトの名無しさん:2009/06/12(金) 11:46:20
>>164
くわしく。よんでもさっぱり意味分からん。

169 :106:2009/06/13(土) 07:28:21
>>164
うーん、よくわかんないや…(´・ω・`)
これでできるのかな


というか、>>106の用件なんですが「共通部分」と「共通部分+依存部分」とでリポジトリ分けて、
「共通部分+依存部分」から「共通部分」へ片方向の git pull(fetch, merge)だけで別に間に合う気もしてきた…。
むしろ、「共通部分+依存部分」から「共通部分」へgit pushしなくする方法ってあるんですかね。
「共通部分」のリポジトリの方に依存部分を注入したくないってだけなんですが。

170 :デフォルトの名無しさん:2009/06/13(土) 09:12:17
gitでコミットしたログを再編集することはできないものでしょうか?

Redmineなどプロジェクト管理ツールなどで、コミットログに"refs #13"のように書いておくと
チケットとコミットログを関連付けられるのですが、これがまたよく書き忘れてしまいます。
コミットした後で気づく、ということがあるのですが、
コミット後のログを編集することはできないものでしょうか?
pushなどはしていないものとします。

171 :170:2009/06/13(土) 09:24:05
>>170
調べてました。
直近なら、
  git commit --amend
で修正できるんですね。
過去のはさすがに無理ですよね?

Redmineだと何故かキャッシュのせいか、前のコミットが残っているけど、ま、いいか…。

Gitの使い方メモ | appling weblog
http://appling.sakura.ne.jp/wordpress/archives/1332

172 :170:2009/06/13(土) 09:38:46
>>170ですが、この辺が参考になりました。

Git ユーザマニュアル (バージョン 1.5.3 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#fixing-a-mistake-by-rewriting-history

Git ユーザマニュアル (バージョン 1.5.3 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#cleaning-up-history

>>171
> 過去のはさすがに無理ですよね?
は、簡単でスマートに行く方法はないっぽいですね…。

173 :デフォルトの名無しさん:2009/06/13(土) 09:52:06
>>172
あるよ

174 :デフォルトの名無しさん:2009/06/13(土) 09:58:03
過去のコミットログを編集すると、コミットIDも変わっちゃうんだよね。
そうなると、そのコミットを親とする子コミットもIDが変わっちゃう(参照する親コミットIDが変わる→子コミットの内容が変わる→SHAによるハッシュ値が変わる

175 :デフォルトの名無しさん:2009/06/13(土) 10:01:09
ごめん、途中ダッタ。

過去のコミットログを編集すると、コミットIDも変わっちゃうんだよね。
そうなると、そのコミットを親とする子コミットもIDが変わっちゃう(参照する親コミットIDが変わる→子コミットの内容が変わる→SHAによるハッシュ値が変わる)。
だから、あるコミットのログを変更すると、それ以降のすべてのコミットIDを変更しなければならない。

コミットIDがSHAによるハッシュ値であり、その計算にコミットログも含まれるから、コミットIDの変更無しにログを編集するのは無理だろうね。


176 :デフォルトの名無しさん:2009/06/13(土) 10:04:38
こんな方法もあるけど、自己責任で。特に5と6。

1. git format-patch XXX で対象コミットまでのパッチを作成
2. git reset --hard XXX でそれまでのコミットをなかったことに
3. git checkout --amend でログを編集
4. git am < patch で、1 で作ったパッチを適用
5. git push origin :master で共有リポジトリのmasterブランチを削除(!)
6. git push origin master で共有リポジトリにmasterブランチを追加

つーか、チケット番号はログじゃなくてタグにしたほうがよくね?

177 :デフォルトの名無しさん:2009/06/13(土) 10:10:22
reset → amend → rebase

178 :デフォルトの名無しさん:2009/06/13(土) 10:32:31
>>172
WEB+DB PRESS Vol.50のGit特集にあった、
git rebase -i
を重宝してる。
便利なんだが使い方が複雑で、説明難しい…。

179 :デフォルトの名無しさん:2009/06/13(土) 10:47:02
>>177
>reset → amend → rebase
最後のrebaseが分からない。git commit --amend したあと、rebaseをどう使うのでしょうか。

180 :デフォルトの名無しさん:2009/06/13(土) 11:02:35
>>179
自分でやってみたほうが理解が早いと思うので一つだけ。
reset で過去の履歴に遡って、amend 付きcommitをすると、その場所から
別のブランチが発生する。後は二つのブランチを rebase で一つにする。

181 :デフォルトの名無しさん:2009/06/13(土) 11:16:49
>>180
そうすると、amend前の古いログをもったコミットが残ってしまうんじゃない?
違うかな。

182 :デフォルトの名無しさん:2009/06/13(土) 14:20:26
>>178
こんなのひっかかった。

> 二つ以上前のコミットを書き換えたいとき
>
> git rebase -i HEAD^^
>
> interacive rebaseらしい
> 修正したいコミットを pick から edit へ修正
> 書き換えする
> 書き換えが終わったら
>
> git commit --amend # コミット書き換え
> git rebase --continue # 以後のコミット書き換え

絶対復習:authorNariさんの復習表示
http://www.takao7.net/brushup/authorNari/show/687

183 :デフォルトの名無しさん:2009/06/13(土) 23:55:35
>>182
なるほど、rebase -iは便利そうだね
おれはこの方法でやってた
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/user-manual.html#rewriting-one-commit
この方法は間違えるとかなりぶっ壊すことになるので必ずcheckout -bとかして
バックアップしておかないとこわい。

>>169
>むしろ、「共通部分+依存部分」から「共通部分」へgit pushしなくする方法ってあるんですかね。
ローカルやsshならアクセス権で調整するとか、git-daemonで公開とかしたらpushできないと思うよ。

184 :デフォルトの名無しさん:2009/06/15(月) 21:17:12
毎回
git push origin master
をしているんですけど、これを
git push
で済ませるにはどうしたらいいんでしたっけ。


185 :デフォルトの名無しさん:2009/06/16(火) 13:10:28
>>184
Bazaarならリポジトリ内で
bzr push
すれば最後にpushした外部リポジトリへ自動的にpushしてくれるけど、
Gitも似たようなもんじゃないの?

186 :デフォルトの名無しさん:2009/06/17(水) 01:52:06
>>184
http://www.kernel.org/pub/software/scm/git/docs/git-config.html
push.default

Defines the action git push should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line. Possible values are:

* nothing do not push anything.
* matching push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.
* tracking push the current branch to its upstream branch.
* current push the current branch to a branch of the same name.

毎回 git push origin master ってやるほうが安全だとおもうけど


187 :デフォルトの名無しさん:2009/06/17(水) 13:14:44
リポジトリのダンプ→フィルタリング→再構築
ができるのってSubversionの他にある?

客先のサーバのパスワードを新人がソースに書き込んでコミットしちゃった
とかの笑えない状況が発生しても対処できるやつ

188 :デフォルトの名無しさん:2009/06/17(水) 13:43:46
>>187
gitかmercurialでrebaseすればいい

189 :デフォルトの名無しさん:2009/06/17(水) 14:40:42
>>188
たとえば、リビジョン(チェンジセット)が以下のようになっていたとき
A-B-C(最新)

A-C(最新)
と、Bのコミットをなかったことにしたい。
(Bはパスワードをコミットしてしまったリビジョン)
rebaseでできる?

190 :デフォルトの名無しさん:2009/06/17(水) 14:57:00
>187
mercurialは、FAQの中に「核ミサイル発射コードをコミットしてしまった時には」
みたいな項目があった気がする。

191 :デフォルトの名無しさん:2009/06/17(水) 15:30:29
>>189
git rebase -i HEAD~3
などとして出てきた一覧から要らないの消せば良いよ。

192 :デフォルトの名無しさん:2009/06/17(水) 15:43:42
>>190
www.selenic.com/mercurial/wiki/FAQ#FAQ.2BAC8-CommonProblems.I_committed_a_change_containing_nuclear_launch_codes.2C_how_do_I_delete_it_permanently.3F
これか。

193 :187:2009/06/17(水) 15:49:44
>>190-192
ありがとう。
git rebase -i
hg clone -r
でできるんだね。

194 :デフォルトの名無しさん:2009/06/18(木) 09:08:16
>>190
吹いた
>>192
本当にあるのかよ!

195 :デフォルトの名無しさん:2009/06/18(木) 23:12:15
>>193
それじゃないと思うぞ
mq使わないと無理

196 :デフォルトの名無しさん:2009/06/19(金) 12:33:10
>>193-195
mq を使い始めると何でもできちゃうから慎重にな。


197 :デフォルトの名無しさん:2009/06/19(金) 17:07:08
darcsでコミットするたびにパッチの名前きかれるのがめんどい
その時の日時を自動でいれてくれないのかな

198 :デフォルトの名無しさん:2009/06/19(金) 22:10:20
>>194 こっちにもあるよ
ttp://www.selenic.com/mercurial/wiki/JapaneseFAQ#JapaneseFAQ.2BAC8-CommonProblems.A.2BaDhlO2SDMJKITDBGMLMw.2FDDJMJJUKzCTMGBZCWb0MJIwszDfMMMwyDBXMGYwVzB.2BMEQwfjBXMF8wAjBdMIwwkmBSTkV2hDBrUkqWZDBZMIswazBvMGkwRjBXMF8wiTBEMEQwZzBZMEv.2FHw-

199 :デフォルトの名無しさん:2009/06/20(土) 18:23:21
このスレ的に一番のお勧めはhgかgitのニ択か?


200 :デフォルトの名無しさん:2009/06/20(土) 18:36:28
bzrじゃね?

201 :デフォルトの名無しさん:2009/06/20(土) 19:23:05
お勧めはbzrだけど、使ってるのはhgというのがこのスレの傾向。

202 :デフォルトの名無しさん:2009/06/20(土) 21:07:11
日本人的には「ファイル名はUnicode」のbzr推奨する所だけど、
分散バージョン管理が盛り上がり始めたころはまだ完成度が
低かったために人気が低い。

hgは「ファイル名はバイト列」という、同じ言語で文字コードが乱立する
国のこと無視の仕様だけど、hg-fixutf8を使って, TortoiseHg をファイル名を
Unicodeで扱うように修正したらなんとかなりそう。

203 :デフォルトの名無しさん:2009/06/20(土) 21:48:20
Windowsのこと考えなくていいプロジェクトでは
gitが使われ続けるだろうし、廃れることはないと思う。

一方で、
Windows環境や非プログラマ要員(日本語ファイル名を普通に使う人たち)
のことも考える必要があるプロジェクトでは hg か bzr が候補になるわけだけど、
方向性を考えると bzr のほうが期待できそうな気がする。

というか、後者の分野で bzr が優勢になったら、
hg はどっちつかずで微妙な立ち位置になりそう。

204 :デフォルトの名無しさん:2009/06/20(土) 22:22:14
gitはクセが強いから、使いやすいgitとしてhgも使われ続けると思うよ。
Pythonもsvnからhgに移行を決めたし。
Google Summer Code で hg を git のクライアントに使うプロジェクトも
できた。

205 :デフォルトの名無しさん:2009/06/21(日) 11:39:28
>>202
bzrはファイル名の文字コードの扱いをやるのはわかったけど、
ファイル本体の文字コード変換もやるの?

例えば、Makefileの中にファイル名書いてたら、
それもちゃんと変換しないとうまく動かない

206 :デフォルトの名無しさん:2009/06/21(日) 11:50:47
>>205
ほらそういうのあるじゃん。。。だからファイル名はバイナリのままで
変換なんかしないようが良いと思うよ。ファイルの中身を勝手に変換する
なんてのはもってのほか。。。
文字コードはリポジトリ内ではたいてい統一されてるだろうし、
見る側が調整すれば問題ないと思うんだけど、、、変換必要?

207 :デフォルトの名無しさん:2009/06/21(日) 13:56:46
>>205
それはMakefileの問題だから、Makefileに書くファイルは最初から
asciiファイル名を使うべき。

208 :デフォルトの名無しさん:2009/06/21(日) 13:59:41
>>206
posix ではファイル名はバイナリが許可されているけど、許可されていない
環境もある。
Makefile の中のバイナリとファイル名のバイナリを維持しても、ASCII以外の
ファイル名をクロスプラットフォームで扱える訳ではない以上、それは詭弁だよ。

209 :デフォルトの名無しさん:2009/06/21(日) 14:02:25
>>205
それは、makeがクソなだけ。
antのbuild.xmlみたいになっていれば、ファイル名がネイティブエンコーディングになっていればいい。

210 :デフォルトの名無しさん:2009/06/21(日) 14:22:51
>>208
ファイル名にバイナリ使えないってどういうこと?
ASCIIしかだめってことなら、何も問題はないんじゃないの?

211 :デフォルトの名無しさん:2009/06/21(日) 15:00:57
文字コードとそのエンコーディング、それにファイル内容の mime-type が
全部ごっちゃに議論されているみたいだぞ。

みんな、もちつけ。

212 :デフォルトの名無しさん:2009/06/21(日) 15:14:06
>>210
そう、Makefile をクロスプラットフォームで動かすには ASCII しかだめってことだから、
ファイル名をUnicodeに変換してプラットフォーム間でファイル名の文字化けを
なくしても何の問題もない。

むしろ、変換しないことによって >>209 のいうようにUnicodeに対応したプログラムで
問題が発生する。

213 :デフォルトの名無しさん:2009/06/21(日) 16:39:39
>>212
つまりファイル名もリソースもUnicodeで、プログラムもUnicode前提で
ロケール等見て判断してからファイルに到達するようにするなら
ファイル名変換されててもうまくいくだろうってことかね。

でもいったんファイルシステムに書かれてしまったら、どんなロケールで
チェックアウトしたか外部からは分からないし、けっきょくUTF-8あたりに
しとこうって話になるんじゃないか。たとえばWebサーバとかファイル名の
変換までは対応してくれないだろうし。
それだったらオリジナルのバイト列を保持しといたほうが健全だと思うがね。。。

214 :デフォルトの名無しさん:2009/06/21(日) 17:08:42
>>213
前半に関してはその通り。
今時、きちんとマルチプラットフォームに対応しているアプリケーションは
そうなっている。逆にそうじゃないアプリケーションではASCIIファイル名
使っておけば良い。

後半に関しては意味不明なんだけど、もうちょっと具体例出せない?
「結局UTF-8あたりにしとこうかな」ってのは、一つのファイルシステムを
共有している環境内では妥当で、「ファイル名はバイナリ列」システムも
「ファイル名はUnicode」システムもうまく行く。
問題は、WindowsをはじめとするロケールをUTF-8に設定できないシステム。

215 :デフォルトの名無しさん:2009/06/21(日) 17:09:57
>>213
$ printf '\xe3\x81\x8c' | xargs touch
$ echo *

$ echo -n * | hexdump -C
00000000 e3 81 8b e3 82 99 |......|
00000007

UTF-8で良さそうに見えるけど、Mac OS XみたいなOSだとこういう迷惑な仕様
になってるんだよね。

216 :デフォルトの名無しさん:2009/06/21(日) 17:17:35
ファイル名のコード体系がまちまちで混在しているというのでなければ
makeが拡張されて
- makefile自体
- コマンド引数
- ファイル名
それぞれのコード体系を指定できるようにすればok


217 :デフォルトの名無しさん:2009/06/21(日) 17:45:34
ファイル名をリポジトリメタデータにするときUTF-8に変換しとけば大丈夫って
ことにはならないだろ。

ファイルシステムで使ってるエンコーディングがUTF-8じゃなければラウンドト
リップコンバージョンの問題があるし、winとunixじゃ(MSのせいで)変換表違
うし。

メタデータは元のファイル名をそのままバイナリエクザクトに持つことにして、
変なエスケープだけしないようにするという戦略以外は破綻する。


218 :デフォルトの名無しさん:2009/06/21(日) 17:46:41
>>215
そういえば、HFS+はNFD正規化するんだったな。


219 :デフォルトの名無しさん:2009/06/21(日) 17:52:33
バイト列+エンコーディングを持ってて適切に変換してくれるならユニコードじゃなくてもいいよ。

220 :デフォルトの名無しさん:2009/06/21(日) 18:41:19
>>214
Javaなんかだったらどうにでもしてって感じかもしれないけど、
俺的には「ファイル名はバイナリ列」なシステムのほうが多いんじゃないかって
イメージだったので。
例えばUTF-8なファイル名を想定して作ったWebサイトがSubversionに入ってるとして、
EUC-JPなロケールでチェックアウトしたらファイル名はEUC-JPに変換されるけど、
それってApacheに配備したらリンク切れするんじゃないかと。
そういうわけで実行環境ってやっぱ予め想定された環境で動かすようにするんじゃ
ないかと思って。
で、結局特定のエンコーディングに決めてやるんだったら、リポジトリから
取り出す時のロケールに左右されたりするよりも、オリジナルの状態が
保持されてるほうが気持ちいい。
要は端末側が合わせればいい話、、、って思ってたけど、WindowsがUTF-8に
できないとは知らなかった。

>>215
Macって濁点が別になっちゃうんだっけ。。。おっかねぇ。。。

221 :デフォルトの名無しさん:2009/06/21(日) 19:05:30
ntfsはutf-16でfatがcp932なのにファイル名をバイナリエクザクト???

222 :デフォルトの名無しさん:2009/06/21(日) 19:25:09
>>221
winってそんなところまでvcsが面倒みてやらなきゃならんの?

223 :デフォルトの名無しさん:2009/06/21(日) 19:34:01
>>220
両方とも合法なので、Unicode対応を謳うなら、必要に応じて同一視でき
ないのが悪いんだけどね。


224 :デフォルトの名無しさん:2009/06/21(日) 19:47:51
>>222
ファイルシステム内部の文字コードは意識しないしすべきじゃないだろ。
OSの規約を守って入れたものがそのまま出てくるならそれで十分。OSの規約に
沿ったものかチェックするのはvcsだがそれぐらいはしなくちゃな。

225 :デフォルトの名無しさん:2009/06/21(日) 20:06:49
>>220
EUC-JPなロケールのApacheがUTF-8のファイル名を想定して
設定ファイルがかかれているの????

226 :デフォルトの名無しさん:2009/06/21(日) 22:07:08
>>225
EUC-JPなロケールなのはチェックアウトした人。
Apache自体にロケールってある? デフォルトキャラセットとかはこの場合関係ないと思うが。

227 :デフォルトの名無しさん:2009/06/21(日) 23:15:33
>>226
んじゃあ、Apacheに配備したらリンク切れ云々って何?

228 :デフォルトの名無しさん:2009/06/22(月) 02:11:06
>>227
Subversionからチェックアウトした時にファイル名が実質変わってしまうから。

229 :デフォルトの名無しさん:2009/06/22(月) 03:24:50
>>228
少なくともASCIIファイル名なら問題ない。

で、ApacheがUnicodeのURL受け取ったときの挙動を知らないんだが、
ApacheがUTF-8を使うとしたら、ロケールをUTF-8に設定した上で
checkout するべき。
EUC の開発環境で checkout したファイルをサーバーにrsyncか
何かでdeployする場合は、deployするときに文字コードを変換して
サーバーに送るべき。
バージョン管理してない非ASCIIファイル名のファイルをその開発環境で
作成できなかったり、文字化けしててファイル名が意味不明になるのは
問題だからね。

ファイル名をバイナリで保存したいというのは限定された環境での話で、
大抵はMacでもLinuxでもWindowsでもファイル名が文字化けすることなく
チェックアウト、チェックインできるようにするのが、汎用的なVCSのあるべき
姿だと思うよ。
限定された環境のニッチなバージョン管理ソフトとしてgitがファイル名を
バイナリで保存するのは別に良いけどさ。

230 :デフォルトの名無しさん:2009/06/22(月) 09:42:35
>>229
>EUC の開発環境で checkout したファイルをサーバーにrsyncか
>何かでdeployする場合は、deployするときに文字コードを変換して
>サーバーに送るべき。
だからさ、けっきょく意図された文字コード(たいていはUTF-8)に変換して
配備するんだったら、始めから変換する必要なんてないだろうってこと。

>限定された環境のニッチなバージョン管理ソフトとしてgitがファイル名を
>バイナリで保存するのは別に良いけどさ。
GitがWindowsのことを考えてあげてないのはその通りだと思うけど、
だからといって「ニッチなバージョン管理ソフト」という認識は間違いだと
思うぜ。採用実績をみてごらんよ。

231 :デフォルトの名無しさん:2009/06/22(月) 10:01:18
>>230
> >EUC の開発環境で checkout したファイルをサーバーにrsyncか
> >何かでdeployする場合は、deployするときに文字コードを変換して
> >サーバーに送るべき。
> だからさ、けっきょく意図された文字コード(たいていはUTF-8)に変換して
> 配備するんだったら、始めから変換する必要なんてないだろうってこと。

開発環境でファイル名が文字化けするのが問題だって上で書いてるだろ?
rsync に iconv オプションつけるくらい、ファイル名が文字化けした環境で
開発するのに比べたら全然手間じゃない。

> >限定された環境のニッチなバージョン管理ソフトとしてgitがファイル名を
> >バイナリで保存するのは別に良いけどさ。
> GitがWindowsのことを考えてあげてないのはその通りだと思うけど、
> だからといって「ニッチなバージョン管理ソフト」という認識は間違いだと
> 思うぜ。採用実績をみてごらんよ。

ascii しか使わないか、Linuxの事しか考えないプロジェクトでしか使えない
じゃん。
OSSで最近流行ってるのは知ってるけど、OSS以外も含めればまだまだ
svnに比べてニッチだろう。特に日本ではさ。

232 :デフォルトの名無しさん:2009/06/22(月) 10:40:37
bzrはよさそうだけど名前から糞esrを思い起こさせるのがいただけない

233 :デフォルトの名無しさん:2009/06/22(月) 10:57:18
alias esr=bzr

234 :デフォルトの名無しさん:2009/06/22(月) 11:07:16
>>222
そんなことはない。
Windows APIはファイルシステムの内部エンコードには関係なく、UTF16の文字列を返す。

235 :デフォルトの名無しさん:2009/06/22(月) 11:13:23
リポジトリ内のファイル名がバイナリか文字列かってポリシーも大事だろうけど、
実際のところバイナリのままでももうちょっとうまくやれるはずなんだよな。

WindowsのAPIはUTF16の文字列でパスを返すんだから、この文字列をそのままUTF8に変換してくれれば、
GitやMercurialでも実用上問題ないレベルでUNIX系と相互運用できるはず。
UNIXの場合はファイル名=バイナリのままで、Windows側だけで対処できるからリポジトリの構造変えなくていいし。


ただWin9x互換の古いAPI (Ansi API)を使ってると面倒。
旧APIはUTF16の文字列をさらにロケールに合わせて再変換したマルチバイト文字列(日本ならシフトJISとか)を返す。
現状のGitやMercurialはこの状態なのかな。
こうなるとUTF8にしようにも単純に一対一で変換出来なくなってしまう。

Cの標準関数が内部で古いAPIを使ってるから、意識しないで使ってるとどうしてもこういう問題が起きてしまう。
まぁ今更この辺をUTF8にするのも無理な話だろうが。アメリカ人は現状でも困らないしな…。
Cygwinとかもよく問題になってるな。

236 :デフォルトの名無しさん:2009/06/22(月) 11:50:14
>>235
Mercurial は fixutf8 拡張を入れるとW系APIを使うようになるよ。
GUIが子プロセス起動するときにコマンドライン引数をW系API使わないで
送ってるから、GUIはまだ対応できてないけど。

237 :デフォルトの名無しさん:2009/06/22(月) 11:51:50
>>235
utf-8 cygwinを使えばgitもW系API使うな。
msys git は無理だけど。

238 :デフォルトの名無しさん:2009/06/22(月) 13:47:54
実用レベルに達したWindows向けGitクライアント「TortoiseGit」でGitを始めよう
ttp://sourceforge.jp/magazine/09/06/19/0340248

hg派としてはとてもうらやましいです

239 :デフォルトの名無しさん:2009/06/22(月) 16:05:44
>>238
TortoiseHg って、まだダメダメだったりするん?

240 :デフォルトの名無しさん:2009/06/22(月) 17:45:51
>>238
うーん...
>  TortoiseGitでは内部的にmsysgitを使用している。そのため、日本語ファイ
> ル名の扱いも現状ではそれに準じたものとなり、ファイル名はシフト
> JIS(CP-932)で保存される。

241 :デフォルトの名無しさん:2009/06/22(月) 18:15:46
結局ファイル名はバージョン管理どれ使うにしてもascii使え、
ascii使えば機能は大差無いから好きなの使っとけってこと?

242 :デフォルトの名無しさん:2009/06/22(月) 21:17:33
Mac使えば糞面倒な事やらなくてもTimeMachine一発なのにな

243 :デフォルトの名無しさん:2009/06/22(月) 21:40:33
>>242
君のは単なる勘違い
他のMacユーザーに迷惑だから認識を改めてくれ


244 :デフォルトの名無しさん:2009/06/22(月) 22:03:11
>>238
Windows上だとhgのがずっと筋がいいから遠からず追いつくと思う。
win環境でgitからhgに変えて速いのにびっくりした。

245 :デフォルトの名無しさん:2009/06/22(月) 23:16:00
Tortoiseの完成度
Hg > Git > Bzr

246 :デフォルトの名無しさん:2009/06/22(月) 23:56:36
Bzr がんばれ
応援してる







Git使いだけど。

247 :デフォルトの名無しさん:2009/06/23(火) 01:03:40
>>246
とりあえず日本語ディレクトリ名がだめなのは、bzr自体がUnicodeコマンドラインオプション
受けとるようになったから、TortoiseBZRのバグトラッカーにそれを使うようにするパッチを
置いといた。
それ以外に何か足りてないのがあれば、言ってくれたら暇な時に対応するよ。

今、 BzrExplorer ってのがハイペースで開発されてる。
Tortoiseは重くなるのがいやだからこっちに期待してる。

248 :デフォルトの名無しさん:2009/06/23(火) 01:58:03
Tortoiseは統合してくれないかなぁ…

249 :デフォルトの名無しさん:2009/06/23(火) 07:30:32
>>238
飛ばし記事乙
何が、実用レベルだ。

>>240の問題があり、>>237しないといけなくて、
TortoiseGitではUTF-8 cygwinは微妙に対応が変
UTF-8日本語ファイル名は化けたり、オーバーレイアイコンが付かなかったりするする

250 :デフォルトの名無しさん:2009/06/23(火) 07:35:30
>>242
何が一発なの?MacでWindowsの日本語ファイル周りの問題を解決できるの?

251 :デフォルトの名無しさん:2009/06/23(火) 09:01:57
正直、もう Explorer にくっついてる意味無いと思うんだよね。
ほとんど作業用のウィンドウ開くだけじゃん。
WinCvs のような独立アプリがいいんだけどなあ。

252 :デフォルトの名無しさん:2009/06/23(火) 09:51:36
>>251
つBzrExplorer
まだ一般向けベータになったばかりだけどね。

Tortoiseの欠点は、ファイルやディレクトリ一つ一つにオーバーレイをするかどうかを
問い合わせるので、PC全体の動作が遅くなること。
同じシェル拡張でも、「このディレクトリでBzrExplorerを開く」を出すくらいだと
軽くていいのにな。

253 :デフォルトの名無しさん:2009/06/23(火) 09:54:51
>PC全体の動作が遅くなること。
どんだけしょぼいマシン使ってるんだよw
オーバーレイの設定次第でやたら重くなったような気もするけど
デフォルトで使ってる限り欠点として挙げるほどのものでもないよ。

254 :デフォルトの名無しさん:2009/06/23(火) 09:57:33
TortoiseSVNの話だが、最近はそれほど気になる速度低下はないよ。
キャッシュとか色々工夫してるみたい。
少なくともワーキングフォルダ外ではToetoiseの影響は感じない。Explorerのクラッシュも見ないし。

むしろ速度重視のせいか、オーバーレイアイコンがちゃんと更新されてない場合も多いがw

255 :デフォルトの名無しさん:2009/06/23(火) 10:02:17
>>253
svn みたいに各ディレクトリに .svn ディレクトリがあるとまだマシなんだけど、
hg/bzr/git みたいにルートにしか管理リポジトリが無いと、あるディレクトリ
アイコンのオーバーレイをするには、

1. そのディレクトリ自体がリポジトリじゃないかチェックする
2. そのディレクトリの親やさらにその親に .?? がないか探す
3. 1か2であったら、リポジトリを開く
4. リポジトリの内容を検索し、該当ディレクトリがバージョン管理されているか
確認する。
5. 管理されていたら、そのディレクトリの中の子ディレクトリ、孫ディレクトリを
再帰的にチェックしていき、一つでも変更されているファイルが無いか
確認していく。あればそのディレクトリは変更されているアイコンを、なければ
up to date アイコンを表示する。

って感じで、親方向にも子方向にもトラバースしないといけないんだよ。
SSD じゃないノートPCだとHDDのランダムアクセス遅いから明らかに重くなる。

256 :デフォルトの名無しさん:2009/06/23(火) 10:04:10
>>254
svn は .svn が分割されているから速いんだよね。
もちろん、他の Tortoise 系が重いのはまだキャッシュ管理が
適当だったりするのもあるんだけどさ。

257 :デフォルトの名無しさん:2009/06/23(火) 10:24:54
そもそもエクスプローラから操作できてもあんまりうれしくはないんだよなあ。
統合環境使うならそっち経由で操作できることの方が重要だし、
キーボードでコーディングしている以上、別にコマンドラインでも苦にならないし。

258 :デフォルトの名無しさん:2009/06/23(火) 12:50:21
まあ、実際俺も、不具合多すぎて、コマンドライン版ばかり使ってるわw

259 :デフォルトの名無しさん:2009/06/23(火) 13:43:00
ちなみに、Unicode対応をうたうbzrは今までコマンドラインオプションを
コードページでデコードしていたのでコードページに対応していないUnicode
文字はコマンドラインから指定できなかった。
1.16 からは、 GetCommandlineW() を使うようになって、cp932で表せない
ファイル名もコマンドラインで扱えるようになった。

hg の場合は fixutf8 拡張を入れると、GetCommandlineW() を使ってくれる。
git の場合はutf-8 cygwin で同じく可能だった。
二次配布とか拡張に依存しないのは素晴らしいけど、もっと早く対応しろよ>bzr

260 :デフォルトの名無しさん:2009/06/23(火) 13:54:57
>>259
hg/bzrでのsys.argvの問題はpython側の実装が根本的な原因。GetCommandlineWを直接呼ぶのはハックの一種。
gitは言わずもがなcygwin側の問題。utf-8 cygwinを本家にマージさせようとする奇特な人は皆無。

261 :デフォルトの名無しさん:2009/06/23(火) 14:42:18
utf-8 cygwinじゃなくて、cygwin-1.7系だと何かマズいんかな。






262 :デフォルトの名無しさん:2009/06/23(火) 14:45:49
>>260
Python 3.0 では、 main(int argc, char** argv) が wmain(int argc, wchar_t** argv) になって、
何もしなくてもUnicode文字列が得られるんだけどね。
まだまだ Python 2.x が主流だから仕方ない。

263 :デフォルトの名無しさん:2009/06/23(火) 20:40:41
bazaarでssl client cert file はどこで指定するんだ?

264 :デフォルトの名無しさん:2009/06/23(火) 21:02:48
>>263
SSL って?
bzr webdav で https 経由で push するとか?

265 :デフォルトの名無しさん:2009/06/24(水) 14:44:25
linux板から

ファイルの先頭部分のコメントあたりで
 /*
  ....
  * $ Header: ... (なんかかいてある) $
  */

これってバージョン管理ソフトに読ませるための情報だったんですね
どのバージョン管理ソフトも対応してるのかな

266 :デフォルトの名無しさん:2009/06/24(水) 18:45:01
>>265
してない。
してるほうが少ないのでは。


267 :デフォルトの名無しさん:2009/06/24(水) 18:53:43
>>265
rcs、cvs、svn(標準で無効)、git(標準で無効)、bzr (bzr-keywordsプラグイン・標準で無効)は対応してたはず。hg? 知らね。

268 :デフォルトの名無しさん:2009/06/24(水) 19:07:25
hgは拡張で対応
ttp://mercurial.selenic.com/wiki/KeywordExtension

269 :デフォルトの名無しさん:2009/06/24(水) 23:06:17
バージョン管理ソフトに読ませるための情報じゃなくて、
バージョン管理ソフトが人間に読ませるための情報じゃないの?

270 :デフォルトの名無しさん:2009/06/25(木) 01:31:13
>>175
> 過去のコミットログを編集すると、コミットIDも変わっちゃうんだよね。
> …
> コミットIDがSHAによるハッシュ値であり、その計算にコミットログも含まれるから、
> コミットIDの変更無しにログを編集するのは無理だろうね。

よく分からないのですが、IDが対応したリビジョンを一意に特定できれば良いのだから、
後からログを変更したとしても、IDを再計算する必要はないのではないでしょうか。
ログが変更できない理由になっていないと思うのですが、どうなのでしょう。

271 :デフォルトの名無しさん:2009/06/25(木) 01:53:26
>>270
IDがハッシュ値だっていう意味はわかってます?


272 :デフォルトの名無しさん:2009/06/25(木) 02:19:12
>>271
そうか、ハッシュが衝突するログを掻けばいいのか。

273 :デフォルトの名無しさん:2009/06/25(木) 05:59:46
>>270
>IDが対応したリビジョンを一意に特定できれば良いのだから、

原理的にはそうなのですが、分散VCSでは複数のリポジトリが互いに独立して存在するので、
再計算しない場合は、同じIDなのに内容が異なるリビジョンの存在を許してしまいます。
それはまずいので、再計算する必要があります。

これが分散型でないなら、ID発行元が一元管理されているので、再計算の必要はありません。

274 :デフォルトの名無しさん:2009/06/25(木) 23:00:40
>>273
なるほど〜。良く分かりました。

となると、ログを後から楽に変更できる分散VCSを作ろうと思ったら、
ハッシュ値の計算にログの情報を含めなければいいんですかね。
でも、ログもリビジョンの重要な要素だと考えるなら、この設計はまずいかもしれませんね。

ありがとうございました。

275 :デフォルトの名無しさん:2009/06/25(木) 23:27:52
>>274
>ハッシュ値の計算にログの情報を含めなければいいんですかね。
その設計はありだと思います。
あるいは、コミットとはべつにあとからログを付加できる仕組みを追加するとか。
たとえばどのVCSでもコミットに対してあとからタグを付けられますけど、
これと同じ感覚でログをあとから付けたせるようにし、それがあればそちらを優先して表示するけど
なければコミット時のログを表示する、というのでもいいかもしれません。
なんというか、コミットに対してあとからメタ情報を付加できる仕組みがほしいですよね。
タグはちょっとプリミティブすぎる。

276 :デフォルトの名無しさん:2009/06/26(金) 00:41:48
ハッシュ値の計算に親コミットIDを含めずに計算するとかはどうかな。
これだと、データを変更したコミットのIDと、その子コミットの親コミットIDを変更するだけで、
子以下のコミットのIDを再計算しなくても良いはず。

編集していない子以下のコミットのIDを変更してしまうのには多少違和感があるけど、
(同じコミットにもかかわらず、他のリポジトリのコミットとIDが変わってしまう)
これだと回避できるかな。
mergeの処理もこの方が速いかもしれない。
もっとも、後からデータを変更する需要がどれ程あるかは分からないけど。

277 :デフォルトの名無しさん:2009/06/26(金) 00:58:26
>>276
分かりにくい表現ですみません。
一応訂正。

> 編集していない子以下のコミットのIDを変更してしまうのには多少違和感があるけど、
編集していない子以下のコミットのIDを再計算して変更してしまうのには多少違和感があるんだけど、

278 :デフォルトの名無しさん:2009/06/26(金) 02:29:30
Gitの場合だけど、ログの内容もコンテンツも全て同一でコミットし直しても
ID変わっちゃうんだよね…ID作る時に日時も使ってるからだと思うんだけど。
親が同じでコンテンツの内容も同じなら同じIDでもいいんじゃないかな〜とは思う。
ただログの内容が違う場合はID変わるのはしょうがないかな〜
世界中で同じコミットだとして認識するにも関わらずログの内容がばらばらだと
ちょっとおかしなことになりそう。ログを考えなければ同じモノなんだけどねぇ。

279 :デフォルトの名無しさん:2009/06/26(金) 13:04:25
git の仕様を分散VCS一般みたいにされてもな・・・
Bazaar は sha1 じゃなくて uuid を使って、
その代わりにコミットに署名をできるようにしている。

280 :デフォルトの名無しさん:2009/06/26(金) 13:13:24
これは……

281 :デフォルトの名無しさん:2009/06/26(金) 14:43:54
>>279
>Bazaar は sha1 じゃなくて uuid を使って、

違いを詳しく教えてください。uuidとやらを使うと、コミットの内容とは関係なくコミットIDを発行できるということ?

282 :デフォルトの名無しさん:2009/06/26(金) 17:17:02
>>281
コミットの内容と関係ない revid は発行されるが、昔のコミットのコメントを
書き換えるようなコマンドは無いな。

ちなみに、普通は長い revid ではなく短くてブランチローカルの revno を
使って作業する。

283 :デフォルトの名無しさん:2009/06/26(金) 22:10:48
>>278
>ID作る時に日時も使ってるからだと思うんだけど。
>親が同じでコンテンツの内容も同じなら同じIDでもいいんじゃないかな〜とは思う。
お前アホだろwww

284 :デフォルトの名無しさん:2009/06/27(土) 03:08:03
Bazaarは署名+擬似乱数をIDにしてる訳ね。
それなら、コミットの内容を後から変更したとしても、
GitのようなIDの再計算はいらないな。

285 :デフォルトの名無しさん:2009/06/27(土) 06:13:52
>>283
くわしく

286 :デフォルトの名無しさん:2009/06/27(土) 10:25:34
>>284
厳密に言うと、id がハッシュじゃないと同じハッシュのリビジョンを偽装できるから、
誰かがこっそり変なコードを紛れ込ませる事が可能になってしまう。
だから id と別に署名が付けられるようになっているだけで、署名は付けなくても良いし、
署名は id の一部じゃない。

287 :デフォルトの名無しさん:2009/06/27(土) 13:38:59
>>286
署名の必要性がいまいち理解できないわ。
そんなに神経質になる必要あるのかな。

例えばsvnに偽装防止の仕組みってあったっけ?

288 :デフォルトの名無しさん:2009/06/27(土) 13:43:30
>>287
> 例えばsvnに偽装防止の仕組みってあったっけ?
svnはsshなりhttpsなりで認証しているのが前提だからな

289 :デフォルトの名無しさん:2009/06/27(土) 22:30:53
>>287
例えば、 bzr send -o バンドルファイル みたいにすると、バンドルっていう
パッチセット+リビジョン情報みたいなファイルができる。んで、それを
メールで送ったり、掲示板に貼り付けたりするから、man-in-middle に
改ざんされる恐れがある。

まぁ、神経質な人が使えば良い機能。俺は使ってない。

290 :デフォルトの名無しさん:2009/06/28(日) 08:00:18
おまえら、悲惨な目にあったんですが、助けてください。

Mercurialで元ファイルがCRLFの改行コードのテキストファイルを突っ込んでいたのですが、
ある日一部ファイルが壊れたので、元に戻そうと hg revert hogeしたわけですよ。

そうしたら、LFの改行コードで元にもどったわけですよ。
途中まで、気づかずにリポジトリ管理下に入れてたアプリがおかしな挙動して、すげー時間くったわけですよ。
LFになったくらいなら、CRLFに変換すればいいんですが、
毎回、取り出した際に、LFになっとるってこんなことあるんですかい?

これって、どうやったら、CRLFそのままで管理してくれるんでしょうか?
もしかして、リポジトリ作り直し…?(; ´д`)

環境:Windows Vista SP2, Mercurial 1.2.1 (TortoiseHg0.7.5付属のもの)

291 :290:2009/06/28(日) 08:20:31
ごめん、一発で解決したw

Mercurial.iniに以下のように hgext.win32text とその諸設定を書き忘れてた(´・ω・`)

[extensions]
hgext.win32text=

[encode]
** = cleverencode:

[decode]
** = cleverdecode:

hgext.win32mbcs外す時に一緒にコメントアウトしていたらしい・・・

しかし、hgext.win32text組み込んだ時って、コミットしたファイルがLFでリポジトリに突っ込まれているのか…。
以前にコミットしたのは、全部hgext.win32text組み込んでたんで、LFになってるみたいだ。

この勝手に変換するのって、もしかして、場合によってはヤバくないですか?
例えば、cygwinのshって、LFでないとエラーはくんですが、リポジトリから吐いてCRLFになってるとマズイじゃん?

292 :デフォルトの名無しさん:2009/06/28(日) 11:21:47
>>291
そもそもwin32textに頼らなきゃいいんじゃね?
改行コード混在の環境は想定されてないんだし。

293 :デフォルトの名無しさん:2009/06/28(日) 11:35:43
>この勝手に変換するのって、もしかして、場合によってはヤバくないですか?

この手の変換って悩ましいけど
まぁよくあることなので
慣れちゃうんじゃないかなー


294 :290:2009/06/28(日) 16:55:00
>>292
> 改行コード混在の環境は想定されてないんだし。

だよねーだよねー

そうか、win32textを始めからつかわなきゃいいのか。
でも、そうすると過去にwin32textで入れた奴だけwin32text使うわけか。
イチイチきりかえ面倒クセー!!
悩ましいなw

295 :デフォルトの名無しさん:2009/06/28(日) 17:12:00
>>294
1. win32text を外す
2. checkoutし直す
3. LFになってるファイルを全部CRLFに書き換える
4. commit

296 :290:2009/06/28(日) 20:12:02
>>295
やっぱりそれしかないか…

297 :デフォルトの名無しさん:2009/06/29(月) 09:36:16
>>291
> この勝手に変換するのって、もしかして、場合によってはヤバくないですか?

今ごろこんなこと言う奴がいるとは驚いたな。
テキストの場合、行単位での管理として特定の改行コード(たいていは LF)でリポジトリは統一、
チェックアウトの際に、それぞれのプラットホームに合わせて改行コードを変更。
至極当然な動作だと思うがね。

298 :デフォルトの名無しさん:2009/06/29(月) 09:54:05
少しお聞きいたします。

git で 普段 pull, push するのは リモートA で、
ある時だけ、リモートB から pull を指定したいということはどのようにしたら可能でしょうか?
リモートAは自由に出し入れ(マージというか)するのですが、
リモートBにはpushしたくないので、指定した時のみ片方向にpullしたいという感じです。

299 :デフォルトの名無しさん:2009/06/29(月) 11:06:27
>>291
>この勝手に変換するのって、もしかして、場合によってはヤバくないですか?
俺はヤバいというより気持ち悪いね。勝手なことはして欲しくない。
ソースコード内の改行なんて、エディタに任せとけばいいよ。

>>298
git pull リモートB master
とかすればいいと思うよ。
http://www.kernel.org/pub/software/scm/git/docs/git-pull.html
http://www.kernel.org/pub/software/scm/git/docs/git-push.html

300 :デフォルトの名無しさん:2009/06/29(月) 11:34:54
288ではないですけど>>299をみて思い出したので質問します。
git で origin/master と指定するときと origin master と指定するときの2種類が
あるみたいですけど、この違いってなんでしょうか。
どういうふうに使い分けるかよくわかりません。

301 :デフォルトの名無しさん:2009/06/29(月) 11:52:03
>>300
origin/master は リモート"origin"の"master"ブランチの指定で、
origin master は<repository>と<refspec>がスペースで区切られて並んでいる状態。
git pull <options> <repository> <refspec>…

302 :デフォルトの名無しさん:2009/06/29(月) 12:16:14
>>301
ですから、その違いは何かということなんですけど。
たとえば git pull origin master は OK で git pull origin/master は NG とか
そういう違いがあったとして、なぜ git pull origin/master は NG となるのか。
origin/master を指定できるところには origin master は指定できるのかできないのか、
逆に origin master を指定するところに origin/master と指定していいのかどうか。
できないとしたら、それはなぜか。両者にどう違いがあるのか。

303 :デフォルトの名無しさん:2009/06/29(月) 14:22:45
>>302
ですから、origin/masterはブランチなので、<repository> ってなってるところに
指定したらそりゃNGになるということなんですけど。
git pull origin master ==> git pull <repository> <refspec>
git pull origin ==> git pull <repository> (<refspec>は省略)
http://www.kernel.org/pub/software/scm/git/docs/git-pull.html

Git入門 - トップページ
http://www8.atwiki.jp/git_jp/

304 :デフォルトの名無しさん:2009/06/29(月) 14:48:55
>>299
改行を統一しないと差分が正しく取れないから変換するしかない。

305 :デフォルトの名無しさん:2009/06/29(月) 16:28:40
そもそも win32text という改行を変換するextentionを入れておいて
勝手に変換するというのは難癖だろ

306 :デフォルトの名無しさん:2009/06/29(月) 19:01:07
>>304
取れないってことはないでしょ。
改行混合でもちゃんとうまくやって
ほしいなあ。

たぶんsvnはできてるんだよね?


307 :デフォルトの名無しさん:2009/06/29(月) 19:54:07
>>306
LFの文書が入ってるところにCRLFの文書がコミットされたら、差分をどういう状態で格納すればいいのかと。

svnも、リポジトリに入れるのは全部LFだよ。入れるときと取り出すときにクライアント側に合わせて自動変換。
最初からWindowsや旧Macの事も考えられてるから、使う側は意識しなくてもうまくやってくれてる。

308 :デフォルトの名無しさん:2009/06/29(月) 20:26:07
svnはそんな変換しなくね?

309 :デフォルトの名無しさん:2009/06/29(月) 20:47:48
え?

310 :デフォルトの名無しさん:2009/06/29(月) 21:13:29
subversion は svn:eol-style で改行の振舞いを決める
default はそのまま
勝手に変えることは無いよ

311 :デフォルトの名無しさん:2009/06/29(月) 21:57:35
ttp://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5
デフォルト(=無変換), native (=クライアントに合わせる), CRLF, LF, CR、の5種類だね。

312 :デフォルトの名無しさん:2009/06/29(月) 23:43:55
>>303
うーん、伝わらない。
Gitの素人なんで中身はよくわからないままの質問なんですけど、
git pull origin master って、リモートのリポジトリとブランチを指定しているんですよね。
だから git pull origin/master でいいじゃんと思うんですけど、おかしいですか。
git pull origin # リモートリポジトリを指定
git pull origin/master # リモートリポジトリとブランチを指定
素人目からみて、あるコマンドでは git xxx origin/master を使い、
別のコマンドでは git xxx origin master と指定しなきゃいけないのは、
わかりにくくてしょうがいないです。


313 :デフォルトの名無しさん:2009/06/30(火) 00:12:47
>>312
乱暴な言い方かもしれないが、思想の違いなんだろうな
同じような機能(元々同じ目的だから)を有するmercurialともリポジトリの
考えが違う
gitのブランチは各々違うレポジトリを差すことができる

314 :デフォルトの名無しさん:2009/06/30(火) 04:25:25
>>299
サンクス
指定すればいいわけね。

Cheat Sheetsにもリモートを指定する例がそのまま載ってた。
Git Cheat Sheets JP
http://hail2u.net/documents/git-cheat-sheets-jp.html#remote-repository


つまり、
 git remote add remoteB repos/m_project
 git pull remoteB
ということだな。

>>300
むしろ、origin/masterと指定するときってどんな時があったけ?

315 :デフォルトの名無しさん:2009/06/30(火) 09:10:30
>>306,310
ごめん。すっかりeol-style=nativeに慣れきってしまっていた。
無変換だと改行コード混在したらまともにdiffは取れなくなるという話が>>311に載っている。

316 :デフォルトの名無しさん:2009/06/30(火) 09:34:10
>>312
$ git branch -a
* master
origin/HEAD
origin/gitk-for-paulus
origin/html
origin/maint
origin/man
origin/master
origin/next
origin/offcuts
origin/pu
origin/todo
いま、ローカルリポジトリのmasterブランチに居る。
リモートリポジトリ"origin"にも、masterという名前のブランチがある。
ただmasterと指定した場合、ローカルリポジトリのmasterブランチのことに
なる。
リモートリポジトリ"origin"のmasterブランチを指定したい場合は、
リモート名付きでorigin/masterとしてあげなければいけない。
git log master はローカルリポジトリのmasterブランチのログリスト。
git log origin/master はリモートリポジトリ"origin"のmasterブランチのログリスト。
git log todo はローカルにはそんなブランチは無いのでエラーになる。
git log origin/todo ならOK。
ごく自然な書き方だと思うんだけど。。。

つかチュートリアル読んだ?

317 :デフォルトの名無しさん:2009/06/30(火) 12:00:14
>>312
>だから git pull origin/master でいいじゃんと思うんですけど、おかしいですか。
origin/masterを指定する書き方だと、git merge origin/master になる。

git pullの書式は git pull <options> <repository> <refspec> だから、
書くとしたらgit pull origin master とかいう感じになるんだけど、
なんでそうなのかというと、pullはfetchとmergeの合わせ技だから。
<repository>はgitが最初にfetchを行うリモート、
<refspec>はgitがmergeを行うブランチ。
で、これらはconfigのbranch.<name>.remote と branch.<name>.merge の設定によって、
それぞれ省略できるようになっている。
git pull remote1 fork1 (remote1をfetchしてfork1ブランチをマージ)
git pull remote1 (remote1をfetchして設定済みブランチをマージ)
git pull (設定済みのリモートをfetchして設定済みのブランチをマージ)

よくあるパターンとしてgit cloneで開始してるとローカルmasterブランチの
remoteはorigin、mergeはmasterに設定されているので、git pull だけで
git pull origin masterと同じことになる。
この状況でoriginの違うブランチからマージしたい場合は git pull origin experimental
って感じになる。

pullの書式は省略してgit pullだけで使った時に便利だから、
分かりにくいなら手動でfetchしてmergeしたほうがすっきりするかも知れない。

318 :デフォルトの名無しさん:2009/06/30(火) 12:49:07
>>316
まるっきり外れた回答ありがとうございます。
できればもういちどもとの質問を読んでみてください。
「origin/master」の意味を聞いているわけじゃないです。

>>317
>なんでそうなのかというと、pullはfetchとmergeの合わせ技だから。
なるほど、fetchはリポジトリ名を、mergeはブランチ名を引数にとるから、
pullも引数が別々にわかれているわけですね。
これはわかりやすい説明でした。ありがとうございます。
ただ初心者の観点からいうと、「git pull origin/master」と指定できるようにしたほうが
統一感があってわかりやすいかなと思いました。
(技術的には何の問題もないですし。)


319 :デフォルトの名無しさん:2009/06/30(火) 13:01:46
>>318
git pull origin masterと、git pull origin/masterでは意味が違うことにも気づけないの?

320 :デフォルトの名無しさん:2009/06/30(火) 13:07:10
>>318
単に使い方を教えて欲しいのか、なぜコマンドがそうなってるのかの理由を
質問してるのか、はっきりしないからなんじゃないかと思うが。
初心者アピールする前に少しはドキュメント読んだほうがいいんじゃない?

321 :デフォルトの名無しさん:2009/06/30(火) 13:42:02
なんか難しそうだからgitは触れない方がよさそうだな

322 :デフォルトの名無しさん:2009/06/30(火) 13:48:40
Subversionで充分です

323 :デフォルトの名無しさん:2009/06/30(火) 13:51:40
RCSで十分とかCVSで十分とかいちいち宣言しなくてもいいような

324 :デフォルトの名無しさん:2009/06/30(火) 13:52:09
実際、hg, bzrとgit, darcsは、難度のレベルが違う。
後者は永久に一般受けしないと思う。

325 :デフォルトの名無しさん:2009/06/30(火) 13:53:16
>>323
ドキュメントまともに読めないやつはSubversionで十分だと言いたいんじゃ

326 :デフォルトの名無しさん:2009/06/30(火) 15:47:44
317のおかげで収まったのに。

>>319
落ち着こう。その2つの書き方は分かりにくいから、後者に統一したほうがいいよねという話。
もうちょっと読解力を持とうよ。

>>320
使い方の質問なんてしてないよ。
あえていえば origin master と origin/master の使い分けについての質問。
もうちょっと読解力を持とうよ。



327 :デフォルトの名無しさん:2009/06/30(火) 15:51:21
全部他人のせいなんですよね


( ´Д`) <はぁー ・・・

328 :デフォルトの名無しさん:2009/06/30(火) 15:53:47
ドキュメントの読解もできない間抜けが何を言っているのやら。
パラメータを二つ指定するのと、一つ指定するのでは意味が違うってなんで判らないの?
折角の>317の解説さえ理解できていないじゃないか。

329 :デフォルトの名無しさん:2009/06/30(火) 16:06:25
>>326はやっぱり理解してねえなw
>あえていえば origin master と origin/master の使い分けについての質問。
使い分けとかいうレベルじゃないからw 別ものw
スペースで区切ったら別のパラメータなんですよ〜たまたま並んでるだけw

330 :デフォルトの名無しさん:2009/06/30(火) 21:28:58
>>328,329
そんなに理解するのが難しいこと言っている?
引数を2つ指定している場合でも、gitが引数の解釈をちょっと頑張ればひとつにできて、
かつ他のコマンドと同じ書き方ができると言っているだけなんだけど。

>パラメータを二つ指定するのと、一つ指定するのでは意味が違うってなんで判らないの?
だから、パタメータがひとつでも、指定の仕方で2通りに解釈させることができるってことが分からない?
git checkout なんか引数にファイル名やブランチ名を指定できるでしょ?パラメータをひとつだけ指定した場合でも、
git コマンドが適切に解釈して別々の動作をしてくれるよね。
git の他のコマンドはそのくらい柔軟にコマンド引数を解釈してくれるんだから、git pull も origin と origin/master の区別ぐらいつけたらいいのにという話。

>スペースで区切ったら別のパラメータなんですよ〜たまたま並んでるだけw
だから、引数の解釈をもう少し頑張れば別々のパラメータにしなくても済むよねという話なんだけど。
#これふざけて言ってるのかな。それともマジで読解力がないの?ゆとりすげーな。

331 :デフォルトの名無しさん:2009/06/30(火) 21:36:07
こんな所で自分の妄想話を披露してる暇があるんなら自分で作れよアホ

332 :デフォルトの名無しさん:2009/06/30(火) 21:44:02
>>330
git pull origin master
の origin は remote 'origin' で, master は手許の repository の branch 'master'.
つまり, branch 'master' が track している remote branch と merge をするわけだ.

git pull origin/master
と書けたとして, origin/master は remote 'origin' の branch 'master'.
さて手許の branch のどれを merge するのかな? origin の master を track している手許の branch 全部?

まー, 文句あるならこんなところでぶーたれてないで patch 書いて送ればいいんじゃないの?

333 :デフォルトの名無しさん:2009/06/30(火) 21:56:13
>>330
これお前だろ。いつのまにGitのUIを俺好みにしろって話になったんだ?
300 :デフォルトの名無しさん:2009/06/29(月) 11:34:54
288ではないですけど>>299をみて思い出したので質問します。
git で origin/master と指定するときと origin master と指定するときの2種類が
あるみたいですけど、この違いってなんでしょうか。
どういうふうに使い分けるかよくわかりません。

334 :デフォルトの名無しさん:2009/06/30(火) 22:08:08
>>330
だからさ、ちゅーとりある読んだー?
ドキュメント読まずに私初心者ですけど使いにくいですもっとこうだったら
いいと思うって、どんな?
git pullの書式はこう書けたらもっと良いと思うんだけどどうかな? って
始めから書いてたら、
スルーしてたと思うけど。だってそうは思わないからね。

335 :デフォルトの名無しさん:2009/07/01(水) 00:24:00
何か伸びてると思ったら...

336 :デフォルトの名無しさん:2009/07/01(水) 01:31:13
>>332
>master は手許の repository の branch 'master'.
>つまり, branch 'master' が track している remote branch と merge をするわけだ.
この部分は違うような気がする。masterはリモートのmasterのことだと思う。
<refspec>は<src>:<dst>とも書けて、例えば git pull origin master:test1
とした場合はoriginをfetchした後にoriginのmasterをローカルのtest1 にmergeする。
git pull origin master とした場合は、いま居るブランチにリモートのmasterをマージ。
<refspec>を省略して git pull origin とした場合は今居るブランチがtrackしてる
リモートのブランチをマージ。

だからといって git pull origin/master だと意味が通らないなとは思う。
そうするなら git merge origin/master が意味的に合ってる。
pullはfetchするからね。

ただ最近、git checkout --track -b hack origin/hack ってしないといけなかったのが
git checkout --track origin/hack だけでいい感じにしてくれるようになったりしてるので、
git pull origin/masterでそれっぽく動くようになる可能性もゼロではないかも。
>>330のパッチに期待。

337 :デフォルトの名無しさん:2009/07/01(水) 09:41:51
そんなことよりそろそろ出るMercurial 1.3が楽しみだ

338 :デフォルトの名無しさん:2009/07/01(水) 10:39:13
>>330
> >>328,329
> そんなに理解するのが難しいこと言っている?

内容は一切読んでないので難しいかどうかはわからんが、説明のやりかたがド下手。
まず、読む気にならない。

339 :デフォルトの名無しさん:2009/07/02(木) 12:27:08
hg commit . が
abort; xxx/yyy/zzz: file not tracked!
となるんだが、仕様変更なの?

340 :デフォルトの名無しさん:2009/07/02(木) 12:28:01
hg 1.3 出たね。

341 :デフォルトの名無しさん:2009/07/02(木) 12:39:40
>340
俺が気になったとこ
# add patch.eol config setting to work with cross-platform patches
# performance improvements, especially on Windows
# much improved zsh completion
# improved Danish, Japanese, Italian and simplified Chinese translations

今回加わった、サブリポジトリって、bzrとかgitにも有るの?

342 :デフォルトの名無しさん:2009/07/02(木) 19:24:21
bazaar の1.16.1も出てるよ!


343 :デフォルトの名無しさん:2009/07/02(木) 19:52:40
>>342
おそっ

344 :デフォルトの名無しさん:2009/07/03(金) 11:46:00
hg cloneすら失敗するとかどうなってるの?!>hg1.3

……と思ったらwin32mbcsが有効になってるせいだった
切ったら普通にいけた……

345 :デフォルトの名無しさん:2009/07/03(金) 18:02:18
Marcurial 1.3登場、リポジトリをまとめる"サブリポジトリ"
ttp://journal.mycom.co.jp/news/2009/07/03/047/index.html

346 :デフォルトの名無しさん:2009/07/03(金) 19:18:22
おーっ、わざわざシェルスクリプト書いてやってたのが
本体機能として実装されそうなんだな。

347 :デフォルトの名無しさん:2009/07/03(金) 19:21:21
>>346
今までもforest extensionでほぼ同じ事が出来てただろ

348 :デフォルトの名無しさん:2009/07/03(金) 22:56:32
>>347
知らなんだぜよ…。orz
Extension は全然チェックしてなかった。

でも木になってないとダメなのか。微妙だな。
サブリポジトリはどうなんだろう。やっぱり木でないとダメなのかな。
それはそれであるといいんだけど、違ってたらやっぱりスクリプトも必要だな。

349 :デフォルトの名無しさん:2009/07/05(日) 12:12:32
Virtual SVN(ver1.71)について質問です。

リポジトリを削除したいのですが、できません。
VirstualSVN Managerでリポジトリを開いて右クリックすると、リポジトリの持ってるファイルは削除できるようなのですが
(ちなみに、Managerから消えてるだけで、DBファイルの実体は残っているようです)、
リポジトリそのものを選択して右クリックメニューから削除しても、10秒くらい反応が返ってこなくなるだけで、
結局消えてくれません。

リポジトリのディレクトリをそのまま消しちゃっても良いのでしょうか?

350 :デフォルトの名無しさん:2009/07/05(日) 13:29:07
日本語ファイル名を扱えるWindows GUI環境という条件で、
git,mercurial,bazaarのツール群を試してみたが、現時点では
QGit2.3 + UTF-8 cygwin(又は cygwin 1.7)git が一番マシかな。
というかこれ以外はまだ実運用できるレベルじゃない。
確認してないツールもあるかもしれないから、これは使えるという
ものがあったら教えて。

351 :デフォルトの名無しさん:2009/07/05(日) 13:30:09
>>350
bzr 1.16.1 + qbzr の trunk + bzr-explorer

352 :デフォルトの名無しさん:2009/07/05(日) 14:10:45
>>351
bzrexplorerはbranchのlocal pathに日本語が含まれると不具合があった
新たなbranchを作る時等
trunkでは直ってるのかな?

353 :デフォルトの名無しさん:2009/07/05(日) 15:39:47
hg forgetなんてのが追加されてるのにnewsにはかいてないな。
しかも日本語ヘルプでhg addをみたらhg revertを見ろとなってるし。
gettextでこの辺の管理ってできないんだっけ?
間違ったヘルプを出すくらいなら英語のをそのまま表示してくれよ。

354 :デフォルトの名無しさん:2009/07/05(日) 16:13:33
>353
日本語ヘルプで思い出して、Windows版hg 1.3を入れてみたが、
これ、WindowsなのにLANG環境変数の設定が必要なんだな。

しかも、訳が付いてるコマンドって半分もないような。

355 :デフォルトの名無しさん:2009/07/07(火) 07:58:32
>>350
あと、2,3年後にきたら少しはよくなったいると思うよ

356 :デフォルトの名無しさん:2009/07/07(火) 09:55:02
hg の ML でも bzr が楽しみとかの話題になってるし、依然として開発チームは
Unicode に理解を示さないようだし、hg ダメかな。
bzr 試してみるかな。もう検証疲れたよ…。

357 :デフォルトの名無しさん:2009/07/07(火) 10:06:23
Python 3系になればきっと

358 :デフォルトの名無しさん:2009/07/07(火) 10:06:57
>>356
開発者の中には、無駄なプライドを背負いこんでるやつらが時々いるんだよな〜。
hgのUnicodeも「やらないって言ったらやらない」って感じだと思うな。


359 :デフォルトの名無しさん:2009/07/07(火) 10:16:08
まあ英語圏では本来 Unicode は必要なものじゃないから、
気持ちはわからないでもないんだけど、全世界で使われるものである以上、ねえ。
bzr は配慮してくれてるわけだし。
はー、bzr 用の仮想マシン用意するか。データはどうするかな…。

360 :デフォルトの名無しさん:2009/07/07(火) 13:00:52
>>359
>全世界で使われるものである以上
それはいいがかり。
向こうには使わせる義理も、こっちには
使う義理もないのだから。

もうとっとと見切りをつけるべきでは。
かわりにbzrとかあるんだし。


361 :デフォルトの名無しさん:2009/07/07(火) 14:17:31
>>357
Python-dev で、Unicodeにデコードできないファイル名どーするよ?という話題に
なったときに、hgの開発者が「文字列(=Unicode)ではなくバイト列でのファイルシステム
へのアクセスは必要だから、例外的な回りくどい方法にしないでくれ」みたいな
事を言ってた。
mercurialはPython3kになってもきっとファイル名はバイト列のまま。

362 :デフォルトの名無しさん:2009/07/07(火) 14:59:14
githubでもbzrが使えればbzr使うんだが

363 :デフォルトの名無しさん:2009/07/07(火) 15:01:31
githubよりlaunchpadの高機能な気がするが、どうしてもgithubでbzrを使いたいならbzr-git使えば良くね?

364 :デフォルトの名無しさん:2009/07/07(火) 17:07:05
>>363
bzr-git は、pull と gitプロトコルでのserveしか対応してないからムリポ。
stacked branch とか bzr の良いところを利用するにはやっぱり launchpad。
wikiが無いのは…

365 :デフォルトの名無しさん:2009/07/07(火) 17:43:58
素直にgit使った方がいいんじゃない?
使ってりゃ慣れるよ。
余計なことしないからUTF-8環境なら逆に問題は少ないし。

366 :デフォルトの名無しさん:2009/07/07(火) 20:34:32
> 使ってりゃ慣れるよ。
いまひとつ信じ難い
コマンドの名前はともかくとして、本当にあのオプション設計に慣れるのか?

367 :デフォルトの名無しさん:2009/07/07(火) 23:03:22
>>361
WindowsとUnix系の違いってのは理解してもらえないもんなのかねぇ。

368 :デフォルトの名無しさん:2009/07/07(火) 23:13:31
今の世の中、Windows は避けて通れないのに、
なぜかおざなりにされるんだよね。

369 :デフォルトの名無しさん:2009/07/07(火) 23:30:58
>>368
逆に考えるんだ

370 :デフォルトの名無しさん:2009/07/07(火) 23:43:48
憎まれっ子世に憚ると申しまして。


371 :デフォルトの名無しさん:2009/07/08(水) 00:09:44
>>366
道具に人間の手の方を合わせるのはバカげているという考えには同意する。
ただ質問の答えなら YES だ。
(それにgitがそれほどバカげた道具だとも思わない。名前以外は。)

372 :デフォルトの名無しさん:2009/07/08(水) 00:23:55
>>367-368
Windows対応もマルチバイトファイル名も開発者が(コミッタ?)その環境で使ってないから、につきる。
何が酔狂に好き好んで、自分の使ってないマシンとか環境の面倒も見なけりゃ意見のだ?
金貰ってやってるような仕事じゃないんだぜ?

よくあるだろ、Windowsのフリーソフトのフォーラム覗いたら、
「Mac版も作ってください」「知るかボケ(やんわりと)」って受け答え

373 :372:2009/07/08(水) 00:25:39
俺はWindowsを非難しているわけじゃないぞ。おれ自身はむしろ、Windowsもクライアントで、Linuxも鯖で使ってる方だからな。

374 :デフォルトの名無しさん:2009/07/08(水) 00:38:00
別にcp932だけが悪い訳じゃなくて、UTF-8でも正規化の問題とか、Mac OS Xで
あったりするじゃん。
svnを置き換えるような、クロスプラットフォームで汎用のバージョン管理ソフトには、
やっぱり環境依存なファイル名の扱いを吸収してくれる機能が必要なんだよな。

Linuxだけでファイル名のエンコーディングも全nodeでそろえられるような限定された
環境か、Windowsにはcygwin入っているのが当たり前っていう人のコミュニティの中で
しかgitはムリだと思う。

375 :デフォルトの名無しさん:2009/07/08(水) 00:46:46
>>372
rubyのmatzがそれでMacもらったりしてたよな
実際にMacの対応が良くなったかどうかは知らんが

376 :デフォルトの名無しさん:2009/07/08(水) 02:26:10
やったことないけどGitでCP932にそろえればいいんじゃね?
UTF-8はうまくいってる気がする。

377 :デフォルトの名無しさん:2009/07/08(水) 02:51:58
>>376
UNIX側でCP932をデフォルトエンコーディングにすると確実に死ねると思うのだが。
何処に行ってもUTF-8にするのが無難な解。
# とは言え、そっちはそっちでNFC vs NFDとかWAVE DASH問題とか……orz

378 :デフォルトの名無しさん:2009/07/08(水) 08:35:31
Unix(というかPOSIX)ではファイル名は単なるバイナリ列なんだよね
'\0' と '/' が特別扱いされるだけで

この意味では hg/git のやり方にも一理ある

379 :デフォルトの名無しさん:2009/07/08(水) 12:17:29
>>377
>UNIX側でCP932をデフォルトエンコーディングにすると確実に死ねると思うのだが。
滅多にやらないけど、ロケールSJISってなんか問題あるっけ?

>何処に行ってもUTF-8にするのが無難な解。
そりゃそうなんだけど、Windowsの人が日本語ファイル名ダメだって言うから。

380 :デフォルトの名無しさん:2009/07/08(水) 13:05:00
>>378
>Unix(というかPOSIX)ではファイル名は単なるバイナリ列
それはファイルシステムの話だろ。
シェルやアプリケーションがどのように
扱うかはまた別の話。


381 :デフォルトの名無しさん:2009/07/08(水) 13:40:11
>>379
2バイト目が0x5c
>>380
posix api の話
>>378
gitにとってはWindowsは公式サポート外だから別に良いけど、
hgはWindowsも公式サポートされている。

382 :デフォルトの名無しさん:2009/07/08(水) 16:27:52
NEWSはShift-JISがデフォだったけどな

383 :デフォルトの名無しさん:2009/07/08(水) 16:29:21
昔のHP-UXもShift-JIS。 今は知らない。

384 :デフォルトの名無しさん:2009/07/08(水) 17:05:45
またcygwinはwindowsじゃないというトンデモか

385 :デフォルトの名無しさん:2009/07/08(水) 20:07:56
>>378
Unix系は問題ないんだよ。 
Windowsでは文字列として扱ってもらわないと困るって話。

Cygwinは、UTF-8 Cygwinが標準になってくれれば…。

386 :デフォルトの名無しさん:2009/07/08(水) 21:49:47
Windowsも使わないし日本語ファイル名も使わないわしにとっては別にどうでもいいなと思った

387 :デフォルトの名無しさん:2009/07/08(水) 23:26:23
>>361
デフォルトはそれでもいいから、extensionとかで簡単にbzr的な扱いにもかえ
られるとうれしいんだけどな

388 :デフォルトの名無しさん:2009/07/09(木) 01:49:07
>>385
Cygwin-1.7入れてLANG=ja_JP.UTF-8を設定すればおk。
日本語ファイルだらけのワーキングコピーでsvn updateしても無問題。
6月正式リリース予定だったのに、まだMLでproblemだのissueだのPATCHだののSubjectなメールが飛び交ってるが……。

389 :デフォルトの名無しさん:2009/07/09(木) 01:55:36
>>379
全てのコマンドがそれに対応していれば問題ない。>>382-383はそういう環境だな。
しかし、コマンドラインやファイル名を単なるバイト列と思ってるコマンドが1つでもあると、そのコマンドを使った時点で破綻する可能性が出てくる。

390 :デフォルトの名無しさん:2009/07/09(木) 03:19:48
ここは間をとって、バイト列とエンコーディングのペアで保存すればいいんじゃね?

ruby の文字列がそんな感じだったような。

391 :デフォルトの名無しさん:2009/07/09(木) 09:35:35
>>390
改行で1バイト削るためにLFにしちゃうような人種がそんな無駄をするはずがない気が・・・

392 :デフォルトの名無しさん:2009/07/09(木) 09:52:15
>>391
改行を LF にするのは当然で、2バイト以上使うのがただの無駄だろ。
それに日本語について考えれば、 UTF-8 で統一するのに比べて Shift_JIS や EUC-JP を
使ったほうが、容量的にはむしろ節約になる。

エンコーディングとペアで保存する場合の問題は、デコード時の処理負荷のほうでしょ。

393 :デフォルトの名無しさん:2009/07/09(木) 14:13:45
リポジトリに何でも入れられるようにして出力側で変換するよりも、
リポジトリに突っ込むときに正規化したほうが、いろいろな環境間で
データをやりとりするプログラムにとっては正しいデザイン。

394 :デフォルトの名無しさん:2009/07/09(木) 14:15:51
現にUTF-8 で統一してるSubversionにケチ付けてる環境の人って居るの?

395 :デフォルトの名無しさん:2009/07/09(木) 14:31:26
>>393
じゃ、おまえはこれから英語しかしゃべるな


396 :デフォルトの名無しさん:2009/07/09(木) 14:36:53
>>393
正しいなんて言うのはどうかしてる。
そんな機能は後回しになるのが普通だろ。

397 :デフォルトの名無しさん:2009/07/09(木) 15:03:12
>>394 OSXとWindowsで、濁点がついている文字が入っていたりするとうまく動作しない。(NFD問題)

398 :デフォルトの名無しさん:2009/07/09(木) 15:04:31
>>397
ファイルシステムで吸収すべき問題なのか、
アプリでがんばるべきか、前者な気はする。


399 :デフォルトの名無しさん:2009/07/09(木) 15:12:38
>>397
それも、バージョン管理システムがどうにかするべき問題だよな。
リポジトリに入れるときにはどれかの正規化をしておいて、取り出すときに
その環境の慣習に沿った形式に切り替えればいい。

400 :デフォルトの名無しさん:2009/07/09(木) 16:14:00
>>397-399
こういうのがある
http://d.hatena.ne.jp/fujisan3776/20081231/1230700127
本家には取り込まれてないみたいだけど

401 :デフォルトの名無しさん:2009/07/09(木) 16:51:22
>>386
まあ、作ってる側もこういう感じなんだろうな。

402 :デフォルトの名無しさん:2009/07/10(金) 13:02:23
>>401 >>386
まさにそのとおりだな・・・

直すにはマルチバイト件のやつらが、でかい声を上げて手を上げていかなきゃならない。

Subversionのときは、どうだったけ?TortoiseSVNがちゃんと日本語扱えるようになるまで、
けっこう時間かかった覚えがあったけど。大体2,3年くらい科方と簿絵がある

403 :デフォルトの名無しさん:2009/07/10(金) 14:11:07
しかしパッチも受け付けない姿勢には共感しかねる。

404 :デフォルトの名無しさん:2009/07/10(金) 20:05:17
パッチを受け入れるのって面倒だぞ。
対応だけで手一杯になる。

405 :デフォルトの名無しさん:2009/07/10(金) 20:14:05
だからGitにしろと(マテ

406 :デフォルトの名無しさん:2009/07/10(金) 23:13:43
今更ファイル名の取り扱いを変更したら互換性が崩壊するから十中八九無理だろうよ

407 :デフォルトの名無しさん:2009/07/10(金) 23:16:55
cygwin上のgitも速くなったから実際のところ悪く無い。
GUIがgit.exeを呼び出す形で分離されてるから locale の問題ではむしろ
良い方に働いてる。

408 :デフォルトの名無しさん:2009/07/11(土) 07:40:05
TortoiseHg 0.8 だが、win32mbcsを設定したとたん
コミット等まともに動かなくなるようなのだが。
以前はそんなこと無かったのに。

409 :デフォルトの名無しさん:2009/07/11(土) 09:40:19
>>408
誰かが壊したっぽい。

410 :デフォルトの名無しさん:2009/07/11(土) 09:41:36
win32mbcsを作ったひとが直してくれてるから、次のリリースでは大丈夫だろう
ttp://groups.google.com/group/mercurial-ja/browse_thread/thread/59c4fe5b7409e509

411 :デフォルトの名無しさん:2009/07/11(土) 15:58:24
マルチバイトファイル名公式非サポート、
これでWindowsで普及させようなんてアホすぎる・・・

412 :デフォルトの名無しさん:2009/07/11(土) 17:10:21
win32mbcsは公式コンテンツですよ

サポートが弱いのはその通りだと思うけど
だからって妄想はほどほどに

413 :デフォルトの名無しさん:2009/07/12(日) 02:18:36
>>412
公式?w


414 :デフォルトの名無しさん:2009/07/13(月) 17:16:49
Vista SP2 上で cygwin の最新 git 1.6.1.2 を使っています。

.gitconfig に git status を git st で alias 登録しました。

プロジェクトの toplevel では git st で正常に動くのですが、
下の階層のディレクトリに降りて git st すると
全ファイルが modified: とだーっと表示されます。

なので今は git status を書いたバッチファイルを使っているのですが、
解決策をご存知の方はいませんか?


415 :デフォルトの名無しさん:2009/07/14(火) 00:35:35
>>414
gitスレでやれ

416 :デフォルトの名無しさん:2009/07/14(火) 08:34:48
>>415
Gitスレでこっち誘導されてる。
あっちはLinux板だからCygwinならこっちのほうが知ってる人いるかもね。

417 :414:2009/07/14(火) 10:03:20
>>415-416
すみません。。。そして、ありがとうございます。
同じ状態の人はいないのでしょうか。

418 :デフォルトの名無しさん:2009/07/15(水) 12:31:48
>>414
再現しない
環境:Vista SP2, cygwin (UTF-8DLL) , git version 1.6.1.2

最低限再現するgitリポジトリを用意して、githubにでもうpれ

419 :デフォルトの名無しさん:2009/07/16(木) 01:23:14
質問なんですが mercurial で commit 時にある特定のファイルにその commit 時の
hash 値を自動で埋め込むってことをしたいのですができますかね。

[extensions]
hgext.keyword =
[keyword]
* =

とかして、
$Revision$ を埋め込んでるんですけど、どうやらそのファイルが
更新されたときしかリビジョン番号の更新をしてくれないみたいで
困ってます。

420 :デフォルトの名無しさん:2009/07/16(木) 08:48:05
>>419
自分の体重を計るときにその計測結果の1/10の重さのおもりを持って
計測できるか?

421 :デフォルトの名無しさん:2009/07/16(木) 18:59:05
>>420
わかりにくいたとえ。


422 :デフォルトの名無しさん:2009/07/16(木) 19:29:25
>>419
後処理でそれをやってくれるスクリプトを書かないとムリじゃね?

423 :デフォルトの名無しさん:2009/07/16(木) 20:20:21
>>419
[hooks]
pretxncommit = コマンド名

とすることで、新しいリビジョンをコミットする寸前にコマンドを実行することができますので
そこで埋め込むとよいと思います。
新しいリビジョンのハッシュ値は、環境変数 HG_NODE に格納されて渡されます。

参照:Chapter 10. Handling repository events with hooks
http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:pretxncommit

424 :デフォルトの名無しさん:2009/07/16(木) 22:26:45
>>423
どうもありがとう!!
まだ試してないですけど、フック使うって手法で
がんばってみます。


425 :420:2009/07/17(金) 00:55:21
>>421 うん、ごめん。 >>423-424 見て反省してる。

>>423-424
ムリ。ハッシュ値ってのは、コミットする内容を元に計算しているから、
ハッシュ値をコミットする内容に含めるとハッシュ値が変わってしまう。

pretxncommit は、コミットする内容が確定してリビジョンまで決まった後の
コマンドだから、その段階でファイルを弄ってもコミットには反映されない。

426 :デフォルトの名無しさん:2009/07/17(金) 10:07:39
たぶん、ハッシュ値を使って何を実現したいかを説明した方がいい気がする。
バイナリかリリースするソースにハッシュ値を埋め込んでおきたいのかな、
という気はするけど。

427 :デフォルトの名無しさん:2009/07/17(金) 12:25:58
>>419
ファイルが更新されないとリビジョンも更新されないんだから当たり前だろwww

428 :デフォルトの名無しさん:2009/07/17(金) 14:14:40
>>427
CVSやSVNならそうなんだけどね。
ttp://hgbook.red-bean.com/read/behind-the-scenes.html
hgリビジョン番号ってfigure4.2でいうところのchangelogのrevidじゃないのかなぁ。


429 :デフォルトの名無しさん:2009/07/17(金) 14:42:38
hg tagしたら自動生成されたコミットログが日本語になっとる。

430 :デフォルトの名無しさん:2009/07/17(金) 17:11:09
>>428
それはリポジトリのリビジョンでファイルのリビジョンじゃねーだろwww

431 :デフォルトの名無しさん:2009/07/17(金) 18:11:23
>>430
それはそうだが、
hgではファイルのリビジョンを知る方法はないよ。
hg debugindexをつかえば、一応見られるが。

432 :デフォルトの名無しさん:2009/07/17(金) 18:49:34
>>431
logで見れるだろwww
debugindexってまだあるの?

433 :デフォルトの名無しさん:2009/07/17(金) 19:01:26
hg tip ファイル名
で見れない?

434 :433:2009/07/17(金) 19:02:18
すいません、
hg parent ファイル名
でした。

435 :デフォルトの名無しさん:2009/07/17(金) 20:31:51
>>434
出てくるのは00changelog.iのリビジョン番号だし、
ちゃんとchangeset:って書いてあるし。

436 :デフォルトの名無しさん:2009/07/17(金) 20:40:26
>>435
すまん、問題を取り違えてたわ。

437 :デフォルトの名無しさん:2009/07/19(日) 19:31:01
今まで一つのリポジトリを研究室と自宅で操作してて、
コミットし忘れが結構な頻度で発生して面倒だったんだけど、
OSの起動時にフックして自動的にpull/pushしてくれるようなソフトない?
使ってるVCSはbazaarだけど、これがあるならgitだろうがmercurialだろうが移行するぜ。

なかったら言い出しっぺの法則で暇を見て作ろうと思います。
ちなみに皆さんはどうやって同様の問題を解決してますか?

438 :デフォルトの名無しさん:2009/07/19(日) 19:36:49
>>437
リモートログインしてpushすればいいんじゃね?

439 :デフォルトの名無しさん:2009/07/19(日) 19:50:48
>OSの起動時にフックして自動的にpull/pushしてくれるようなソフトない?
Windowsでしょ?バッチファイルをスタートアップに入れておけばいいんじゃね?



440 :437:2009/07/19(日) 20:08:47
>>438
出先のPCは電源を落としてるので、リモートログインはできないのです。
もっとも研究室のPCなので外からログインできるかは微妙ですが
(VPN使う手もありますが、なにかとまずそうなので・・・)

>>439
主にubuntu使ってますが、windowsも開発で使わなければならないときもあるんで、まあ両方ですね。
linuxでもdaemonとかいう、いわばサービスにファイルを登録するだけで起動/終了時にスクリプトを走らせることができます。
ただ、それだけでは終了時のpushができなかったり、スタンバイやハイバーネート、スリープなどに対応できないと思いますので、
結局フックやらを考えないといけないとは思いますが・・・


現在考えてるソフトウェアの構成はこんな感じです。

・VCSをpull/pushするスクリプト(おそらくRubyかPython)
・OSに上のスクリプトを走らせるためのソフトウェア(Windowsならサービス、Linuxならdaemon?)

最初はbazaarとlinuxで試してみて、それが出来次第他のVCSやWindowsもできたらいいなと思っています。

441 :デフォルトの名無しさん:2009/07/19(日) 20:25:00
.bash_profileと.bash_logoutじゃいけない理由でもあるの?
まぁ、logoutする習慣がないなら泣け。

# しかし、本質的にはその辺りは自動にするより習慣付けるのが一番ではある。

442 :デフォルトの名無しさん:2009/07/19(日) 20:28:07
自宅のPCにリモートで入ればいいじゃん

443 :437:2009/07/19(日) 20:30:25
>>441
まあその辺の手も考えなくはなかったのですが、
普段もっぱらscreenを使用してるので.bash_logoutスクリプトが自動的に呼ばれないことと、
複数のリポジトリを更新してほしいときなどに面倒なので、それならいっそリポジトリのパスを含めた設定ファイルと、
それをpull/pushする簡単なスクリプトを書こうと思ったわけです。

> # しかし、本質的にはその辺りは自動にするより習慣付けるのが一番ではある。
まあおっしゃる通りなんですが、分散型を使ってるとcommitはともかくpushは忘れがちで・・・。

444 :デフォルトの名無しさん:2009/07/19(日) 21:03:22
馬鹿じゃない?

445 :デフォルトの名無しさん:2009/07/19(日) 21:06:46
>>443
screen使用とログアウトしないこととの関連が判らんが、
「複数のリポジトリを更新して欲しいとき」という要求が発生するタイミングがあるなら
まさしくその瞬間に自分でpushするスクリプトを起動すればよいのでは?
pushを忘れるのが嫌なら、例えばコンパイル時にpushするようにMakefileを書けばいいだけだし、
やっぱり何をしたいのか判らない。

446 :デフォルトの名無しさん:2009/07/19(日) 21:16:55
cronで定期的にhg outgoingみたいなので未pushの一覧を出力してメールで飛ばせ。

447 :デフォルトの名無しさん:2009/07/19(日) 21:19:22
>>443
pushを忘れがちというのには同意。
pushされた側でupdateをわすれがちなのもあるよね。

448 :437:2009/07/19(日) 21:46:26
>>445
> screen使用とログアウトしないこととの関連が判らんが、
screenがバックグラウンドでシェルの状態を保持するために、ターミナルを閉じても.bash_logoutが呼ばれないのです。
それに、OpenOfficeのファイルなどをGUIから編集するときなどでもpush(commit)してほしいので、
シェル起動が前提の仕組みはちょっと・・・。

> pushを忘れるのが嫌なら、例えばコンパイル時にpushするようにMakefileを書けばいいだけだし、
ソースコード以外のファイルも同期したいので、Makefileに書くのは難しいかと思います。

> やっぱり何をしたいのか判らない。
すいません、きちんと書いたつもりだったのですが、へたくそな文章でいまいちうまく伝わってなかったようです。
要は、登録された作業コピーを、OS起動時にupdate/pull、終了時にcommit/pullしたいのです。
それでいちいち分かりきった作業をせずに済みますし、なによりupdate(pull)しなければいけない、と考える必要がなくなります。

>>446
なるほど、それならメールをチェックしていればどれをpushしていないのか分かりますね。
でも、例えば長時間起動してcommitしながらOS終了時にpullするような使い方だと、
チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
一回だけだと逆に終了時に忘れてしまうような気がします。

>>447
自分もうっかりものなのでよく起こしてしまいます。
特に自分のホームディレクトリの同期などはコンフリクトが起こらないことが明確なので、
自動的にpull/pushしてくれればいちいち気にせず使えて便利だと思ったわけです。

449 :437:2009/07/19(日) 21:49:57
>>448
すいません、一部言葉足らずな部分があったので修正させてください。

> >>446
> なるほど、それならメールをチェックしていればどれをpushしていないのか分かりますね。
> でも、例えば長時間起動してcommitしながらOS終了時にpullするような使い方だと、
> チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
> 一回だけだと逆に終了時に忘れてしまうような気がします。

でも、例えば長時間"PCを"起動してcommitしながらOS終了時にpullするような使い方だと、
"cronの"チェック時に毎回メールするようだとメールがどんどん増えていってやがて見なくなるでしょうし、
"差異を発見した一回目"だけだと逆に終了時に忘れてしまうような気がします。

450 :デフォルトの名無しさん:2009/07/19(日) 21:54:50
>>449
cronでpushしちゃえよ。人間になれない人にはぴったりだ。

451 :デフォルトの名無しさん:2009/07/19(日) 22:00:54
DropBox使えば?

452 :デフォルトの名無しさん:2009/07/19(日) 22:01:47
>>450
>人間になれない人
???

453 :437:2009/07/19(日) 22:11:52
>>451
まさにそのDropBox的な使い方をしたいのですが、
DropBoxだと容量に制限があったり、履歴管理に柔軟性がなかったりするので、
できればVCSを使って同様の機能を実現したいのです。

454 :デフォルトの名無しさん:2009/07/19(日) 22:22:56
間抜けってことか。

455 :デフォルトの名無しさん:2009/07/19(日) 23:12:37
>>437
bzr なら branch じゃなくて checkout したら良いじゃん。

456 :デフォルトの名無しさん:2009/07/20(月) 01:09:08
分散型使うのやめればいい

457 :デフォルトの名無しさん:2009/07/20(月) 01:25:31
そもそも437の使い方で、push忘れは大きな問題になるのか?
逐一pushしなくても問題がないのなら、思い出した時にだけpushすればいいと思うんだが

458 :デフォルトの名無しさん:2009/07/20(月) 06:58:39
USBメモリにリポジトリをおけば解決?

459 :デフォルトの名無しさん:2009/07/20(月) 08:13:16
>>458
大丈夫、>437ならそれでも忘れてくれる。

私はそうしているけどね。

460 :437:2009/07/20(月) 09:16:21
>>455
>>456
その手は全然考えてませんでした。
ですが、集中型を使ってもやっぱりcommitを忘れると同様のことが起きそうですね。

>>457
研究室で編集したものをpushし忘れると、
自宅に帰って続きをしようとしたときにせっかく変更したファイルを得られなくなるんです。
実際にはそういったことが何度もあったわけではないのですが、
分かりきった作業に毎回毎回気を配るのは面倒だと思った次第で、それなら自動化できないかと思いました。

>>458
すいません、ローカルリポジトリ/中央リポジトリどっちをUSBメモリに置いたときの話でしょうか?

461 :デフォルトの名無しさん:2009/07/20(月) 09:30:56
>>460
さすがにcommitを忘れるようなら、集中だろうと分散だろうと自動pushしようとどうにもならんよ
まさか任意のタイミング(シャットダウン時)で自動commitするわけにもいかんだろう

462 :デフォルトの名無しさん:2009/07/20(月) 10:17:29
たしかに commit 忘れも救うってのはダメだな。
何のための commit なのかわからなくなる。

必要なのは VCS+α じゃなくて自動ファイル同期機構だろう。

463 :デフォルトの名無しさん:2009/07/20(月) 10:52:57
>>460
自宅で作業するときに pull すりゃいいんじゃねーの?
push に気を使うよりか作業前に pull する方が習慣として
楽なんじゃないかと思うんだが。

464 :デフォルトの名無しさん:2009/07/20(月) 14:15:37
>>463
そもそもpushされてないのに、どうやってpullしろと。

スケジュールかtodoでpushアラート出して、自分を誘導して実行していくのが確実な気がする。
アラート無視はもうやる気がないとしか。

465 :デフォルトの名無しさん:2009/07/20(月) 14:17:39
素直に集中型のVCS使ったほうがいいんじゃね?

466 :デフォルトの名無しさん:2009/07/20(月) 14:38:25
ってか、gfsとかcLVMとかを使って作業コピーや分散リポジトリのあるディレクトリを
丸ごとどこか外に追い出せば済む話みたいに聞こえるんだが。
SCMとか以前の問題だろ。

467 :デフォルトの名無しさん:2009/07/20(月) 15:49:16
コーディング用のノートパソコンを一台用意する
commit忘れちゃう437を救うにはこれしかない

468 :デフォルトの名無しさん:2009/07/20(月) 16:16:26
いっそのことコード書くのも忘れちゃうというのはどうか


469 :デフォルトの名無しさん:2009/07/20(月) 18:09:16
>>460
VisualStudioとかの統合環境にプラグイン入れれば、閉じるときに更新されてれば
commitするか聞いてくれるよ。

470 :デフォルトの名無しさん:2009/07/20(月) 19:20:21
>>460
研究室と自宅で同じ作業するなら中央もローカルも USB 上でやればいいだろ

471 :デフォルトの名無しさん:2009/07/20(月) 20:13:04
>>465
問題はコミットし忘れなんだから、集中型だろうがだめだろ


472 :デフォルトの名無しさん:2009/07/21(火) 12:24:31
>>469
437なら閉じずにハイバネートするだろうな

473 :デフォルトの名無しさん:2009/07/21(火) 13:19:03
SCMを使わずにNFS/Sambaで同じディレクトリを共有。
開発もその上でやれば、保存した瞬間に同期される。

474 :デフォルトの名無しさん:2009/07/21(火) 13:49:07
>>473
437ならファイルを保存し忘れる可能性もある

475 :デフォルトの名無しさん:2009/07/21(火) 14:04:54
437なら自分が何者で、どこに帰って良いのか忘れてしまう可能性もある

476 :デフォルトの名無しさん:2009/07/21(火) 14:31:25
Launchpad is now fully open source
http://beuno.com.ar/archives/144

477 :デフォルトの名無しさん:2009/07/21(火) 23:23:36
437のことはもう許してやれよw

478 :デフォルトの名無しさん:2009/07/22(水) 10:17:38
許してやるから出てこいよ

479 :デフォルトの名無しさん:2009/07/22(水) 10:31:18
Mercurialのextdiffでフルパス送る方法ないですか?

480 :デフォルトの名無しさん:2009/07/22(水) 12:33:40
>>479
extdiffはテンポラリにcdしてからファイル名のみを渡します。
pwdを拾うラッパーを書けばよいのではないでしょうか。

481 :479:2009/07/22(水) 14:07:58
>>480
ありがとうございます。やっぱそれしかないんですね。
もうPython勉強して自分でパッチ書いた方がいいかな……。

482 :デフォルトの名無しさん:2009/07/23(木) 12:05:42
/home 以下を全部差分バックアップするのにお勧めなのはどれになるのでしょうか
そういう使い方するものではないのでしょうか?

483 :デフォルトの名無しさん:2009/07/23(木) 12:09:37
>>482
あくまで俺の感想だけど、SCMはバックアップ用途には使いにくいと思う。
リポジトリも増える一方だし。

個人的にはバックアップではrdiff-backupを使ってる。
rsyncに履歴をつけたようなやつ。

484 :デフォルトの名無しさん:2009/07/23(木) 20:34:08
Canonical、LaunchpadのソースコードをAGPL 3で公開 - スラッシュドット・ジャパン
" Ubuntuの開発でも知られるCanonicalが、ソフトウェア開発プロジェクト管理システム「Launchpad」のソースコードをGNU Affero General Public License(AGPL)v3で公開した(SourceForge.JP Magazineの記事、Launchpad development Wiki)。

Launchpadはバージョン管理ツールBazaarをメインに据えたソフトウェア開発支援システムで、バグトラッカーや翻訳支援ツール等の機能を備えている。

なお、今のところLaunchpadはUbuntu 8.04〜9.04でのみビルド可能とのこと(dev.launchpad.netのインストール方法解説ページ)。"
http://slashdot.jp/it/article.pl?sid=09/07/23/0535203

485 :デフォルトの名無しさん:2009/07/24(金) 06:17:42
おっ、ついにきたのね。さっそく試してみるか。

486 :デフォルトの名無しさん:2009/07/24(金) 06:25:36
なんでウブンツでしかビルドできねーんだ

487 :デフォルトの名無しさん:2009/07/24(金) 10:18:08
これまでCanonicalが使って来た分に関してはそれで十分なわけで。


488 :デフォルトの名無しさん:2009/07/24(金) 10:21:33
Mercurial 1.3.1出たね
win32mbcsがこけてたのが直ってる

489 :デフォルトの名無しさん:2009/07/24(金) 10:37:23
なにィ、昨日サーバー設定してて、1.3 入れたばかりなのに。
まあ蓄積用のサーバーだから細かいことはいいんだけど。

490 :デフォルトの名無しさん:2009/07/24(金) 10:39:48
AGPL に注意

491 :デフォルトの名無しさん:2009/07/24(金) 18:35:35
>>489
わかちこ、わかちこ

492 :デフォルトの名無しさん:2009/07/25(土) 03:20:53
昨日1.3落としたけど
バージョン上げるのマンドクセ('A`)で放置した俺は勝ち組w

493 :デフォルトの名無しさん:2009/07/25(土) 03:49:14
TortoiseHg0.8.0入れたらcommitのUIとか立ち上がらない…。
みんな使えてるの?

494 :デフォルトの名無しさん:2009/07/25(土) 08:44:42
>>493
亀hg0.8はhg1.3内蔵で、
hg1.3はwin32mbcsが壊れてるのでそうなる。
有効にしてない?

495 :デフォルトの名無しさん:2009/07/25(土) 08:54:39
TortoiseHg 0.8.1(with Mercurial 1.3.1)
ってもうできてるんじゃん。
ttp://bitbucket.org/tortoisehg/stable/downloads/

496 :デフォルトの名無しさん:2009/07/25(土) 14:51:07
hgsccも新しいの出てた。
てっきり最初のバージョンだけで放置してると思っていたが
5月にも更新されてたんだな。

497 :デフォルトの名無しさん:2009/07/25(土) 21:58:15
>>494
有効になってた。
ありがとう!

hg0.8.1だと、win32mbcsでエラーはないが、ダメ文字はコミットできないみたいね…。

498 :デフォルトの名無しさん:2009/07/30(木) 20:34:23
Mercurial、エディタの制御まともにできないの直ってる?
コミットメッセージ再編集不可なのはどうせ直ってないんだろうなあ
まともな分散型が使えるようになるまであと何十年かかるかな

499 :デフォルトの名無しさん:2009/07/30(木) 22:55:38
レポートされなかったバグはないのと同じ

500 :デフォルトの名無しさん:2009/07/30(木) 22:56:32
no

501 :デフォルトの名無しさん:2009/07/31(金) 08:35:20
ちょっと試すぐらいの気概もないならやめちゃえば。

502 :デフォルトの名無しさん:2009/07/31(金) 21:03:37
darcsで日本語ファイル名は使えますか?

503 :デフォルトの名無しさん:2009/08/03(月) 05:02:18
単発の設定ファイルなんかをいちいちリポジトリを作らずに
スナップショットとるようなツールってないのかな。
ボリュームシャドーコピーやTortoiseSVNのような使い勝手で
スナップショットとるタイミングはユーザーが明示できるようなもの。

ちょっとしたINIファイルなんかを念のためバージョン管理下に置いておきたいんだけど
かといって従来型のはちょっと面倒と言う時に気軽に使いたい。

504 :デフォルトの名無しさん:2009/08/03(月) 08:51:24
設定ファイルをシンボリックリンクで一箇所に集める。


505 :デフォルトの名無しさん:2009/08/03(月) 10:03:47
hg, bzr,git
ソースを読みやすいのはどれ?

506 :デフォルトの名無しさん:2009/08/03(月) 10:14:15
>>503
UNIX ならそういう用途だと自分はいまだに RCS 使っちゃうなあ。
/etc の下のファイルいじるときに、あまり自信のないときには ci してから編集したり。

507 :デフォルトの名無しさん:2009/08/03(月) 13:31:28
>>506
俺もRCS使う。
同じ用途でMercurialも使うけど、RCSほどインストールされてない。

508 :デフォルトの名無しさん:2009/08/03(月) 15:15:45
git 使うようになった

509 :デフォルトの名無しさん:2009/08/03(月) 16:26:35
etckeeper使うときのメリットってある?

510 :デフォルトの名無しさん:2009/08/06(木) 02:33:10
リポジトリをUSBフラッシュメモリに入れられて、
それをWindowsからでもLinuxからでも使えるような
バージョン管理システムってあるでしょうか?

機能だけならDropboxでも十分なのですが、ネットワークが
ないところでも使えてデータはローカルに置いておきたいです。

511 :デフォルトの名無しさん:2009/08/06(木) 02:34:09
svn

512 :デフォルトの名無しさん:2009/08/06(木) 02:49:35
>>510
分散型なら普通にできるんじゃない?

513 :デフォルトの名無しさん:2009/08/06(木) 10:56:44
>>511
Subversionはリポジトリ内のロックファイルやフックスクリプトの改行コードが
OSに依存しているみたいだから、そのまま使えないかも。

514 :デフォルトの名無しさん:2009/08/06(木) 15:09:38
他のプログラムが頻繁によばれるような使い方するなら
cで書かれたgitが一番速度も速いし安心なのか

515 :510:2009/08/06(木) 23:40:03
svnのリポジトリってOSに依存してるのかと思ってましたけどFSFSなら
大丈夫そうですね。USBメモリ上のリポジトリでWindowsとLinuxの両方から
co, ciしてみましたがちゃんと動いているようです。

しばらくバックアップ取りながらこれで使ってみます。
ちなみにUSBメモリはFAT32、WindowsではCygwinを使っています。

>>512
全然詳しくないですけど、分散型でもリポジトリのデータは
OSに依存してるものとかあるんじゃないですかね?

>>513
今回はロックもフックも使わないので大丈夫そうです。
ただ、どこかで問題が起きるのではと心配しています…。

516 :デフォルトの名無しさん:2009/08/07(金) 07:37:54
リポジトリがOS依存ってw
そんなの使い物にならなくないか?

ていうかあるの?
Bzr, git, hg, SVNを平行して使ってるんだけど、こええな

517 :デフォルトの名無しさん:2009/08/07(金) 08:39:45
分散型だからといってOS非依存が条件なわけでもないだろ
クライアントやプロトコルがOS依存って話でもないのに何を怖がってるんだ?

518 :デフォルトの名無しさん:2009/08/07(金) 10:26:34
>>515
SubversionでもBazzarでもUSBにリポジトリを置いているけど問題ないよ。

519 :デフォルトの名無しさん:2009/08/07(金) 11:51:42
>>517
USBの中に入ってるレポジトリがOS依存だったら大問題だろ

520 :519:2009/08/07(金) 12:12:22
補足
USBメモリの中に入ってるレポジトリが、たとえばWindowsに依存していたら
LinuxからそのUSBメモリを開いたとき、レポジトリの中身が見られなくなる、という意味ね

521 :デフォルトの名無しさん:2009/08/07(金) 12:15:36
改行コードとかは属性付けておけば良いだけだし
フックスクリプトなんてWin用とLinux用でも作っておけば良いじゃん

522 :デフォルトの名無しさん:2009/08/07(金) 13:28:05
>>519
アホ?

523 :デフォルトの名無しさん:2009/08/07(金) 13:30:01
>>519
リトルインディアン嘘つかない

524 :デフォルトの名無しさん:2009/08/07(金) 13:34:47
>>520
そのことと>>517に何の関係があるんだ?

525 :デフォルトの名無しさん:2009/08/07(金) 16:08:08
分散型であることとリポジトリ自体が異なるOS間で可搬であることは何の関係も無いよね。
リポジトリ自体の物理的な保存場所をOSまたいで持ち運ぶような用途が想定されているかどうかだけ。
物理的な格納の仕方の話だからファイルシステムも関係ある。
分散は関係ない。

526 :デフォルトの名無しさん:2009/08/07(金) 17:28:55
なにこれ

527 :デフォルトの名無しさん:2009/08/07(金) 18:13:26
ぐだぐだ曖昧論を繰り返すより
510の用途でトラブルが発生するツールを上げた方が有用だろう。
トラブルが出ないものはいくつか挙げられた。

528 :デフォルトの名無しさん:2009/08/07(金) 18:19:35
>>510 が好きなのを試してみて、使えたかどうか報告してくれると有難い

529 :510:2009/08/07(金) 22:02:05
>>528
515に書いたようにsvnで満足しそうなのでこれでいいかなと思っています。
何か問題が起きたらまた相談に来ます。

530 :デフォルトの名無しさん:2009/08/08(土) 04:51:01
>>527
たぶん、ビッグエンディアンのマシンでBDBで作ったSubversionリポジトリをコピーしてリトルエンディアンのマシンに持ってくと壊れると思われ。
そういう特殊ケース以外は結果的に問題ないんじゃね? 根拠はないけど(ぉぃ

531 :デフォルトの名無しさん:2009/08/08(土) 11:35:16
>>530
マジで?

DBDはバージョンアップのたびにアップデート必要だったり散々な思い出しかないわw
svnのBDBってかなりヤバイイメージ・・・

頼むから、同じ過ちを繰り替えささないで、とは思う

532 :デフォルトの名無しさん:2009/08/08(土) 12:58:28
BDBの存在意義がわからない

533 :デフォルトの名無しさん:2009/08/08(土) 13:01:32
今じゃFSFS使えば困らないからね…と思ってたがRubyをsvnsyncした時は心が折れかけたw
BDBの代わりにSQLite使ったらどうなるんだろうか

534 :デフォルトの名無しさん:2009/08/09(日) 20:31:01
svnのバックに汎用のRDBをもってこれないの?

535 :デフォルトの名無しさん:2009/08/09(日) 21:06:40
svnのバックエンドにgitってのはあるみたいね

536 :デフォルトの名無しさん:2009/08/09(日) 22:23:01
JavaEE5を用いたシステムで
ソースとEAR等のアーカイブ以外に、
クラスもバージョン管理したいって上司が言ってるんですが、
そんなこと普通するのでしょうか・・・
皆さんのご経験をお聞かせ願えますか?

537 :デフォルトの名無しさん:2009/08/09(日) 22:35:11
>>536
しない。

ビルドターゲットの違いを心配してるんだろうけど
わざわざ、クラスの管理はしない。
もしするんだとしても、開発用とは分離したレポジトリだな。

538 :デフォルトの名無しさん:2009/08/09(日) 22:43:23
>>536
流石にそんな経験はないな。

539 :デフォルトの名無しさん:2009/08/09(日) 23:29:53
>>536
むしろ、してはならない類いの一つ。

540 :デフォルトの名無しさん:2009/08/10(月) 00:20:33
>>537,538,539
貴重なご経験教えて頂き、皆さんありがとうございます。
何とか上司を説得してみます。

541 :デフォルトの名無しさん:2009/08/10(月) 11:08:58
必要最小限の機能しか使わないならcvsでいいのかな

542 :デフォルトの名無しさん:2009/08/10(月) 11:22:21
流石にこれから導入ならcvsよりはsvnじゃね?

543 :デフォルトの名無しさん:2009/08/10(月) 12:30:51
git だろ

544 :デフォルトの名無しさん:2009/08/10(月) 12:41:59
俺もsvnを使う。
cvsはディレクトリの移動に対応していないし
同時にコミットしてもファイルごとに別のリビジョンになるので
他のSCMに慣れた今では気持ち悪い。

545 :デフォルトの名無しさん:2009/08/10(月) 12:54:43
>>543
cvsとgitはぜんぜん別物じゃん

546 :デフォルトの名無しさん:2009/08/10(月) 12:55:08
LinusがSVNは糞ってゆってた

547 :デフォルトの名無しさん:2009/08/10(月) 12:59:26
CVSは論外ともな

548 :デフォルトの名無しさん:2009/08/10(月) 13:00:54
mercurial か bazaar だよ

549 :デフォルトの名無しさん:2009/08/10(月) 20:23:08
CVS使うぐらいならSVN使った方がいいよなぁ。
上位互換って感じだし。

分散系はどれが主流になるかわからんから
今のところ趣味レベルでいい気はするわ。

550 :デフォルトの名無しさん:2009/08/10(月) 20:31:22
今から使うならCVSでなくSVN使うけど、SVNはタグとブランチの扱いが不満。

551 :デフォルトの名無しさん:2009/08/10(月) 22:14:22
>>550
svnのタグってコピーだもんね。


552 :デフォルトの名無しさん:2009/08/10(月) 22:18:21
>>546-547
Linux Kernelの開発には機能不足でまるで使えないそうな。
まぁそうだろうなとは思う。
あそこまで大規模かつ分散した開発形態なんて、CVSが出た頃には考えもつかなかっただろうし。

553 :デフォルトの名無しさん:2009/08/10(月) 22:20:24
>>541
何が必要かによるんじゃない?

用途によってはRCSで充分なこともあれば、gitじゃないと困ることだってある。

554 :デフォルトの名無しさん:2009/08/10(月) 23:11:27
>>552
gitの入門を読んだ限りでは、自分や他人の作業について、非同期性を如何に上げるか(如何に妨げず/妨げられず、かつ如何に追随する/させるか)という点を重視してる感じがする。
だから、そういう部分に需要がない場合はgitは使いづらいんじゃなかろうか。

とは言え、新規に立てるなら、コミットの単位がトランザクショナルじゃないCVSは今さらありえないけど。
先日ものすごく久々にCVSを使ったとき、「この差分はどこを起点にしていると説明すればいいのだろう」と一瞬固まったもんな。

555 :デフォルトの名無しさん:2009/08/11(火) 00:02:50
CVSに誤解があるようなので弁護すると
コミットするとき関係するディレクトリに書き込みロックをとるのでトランザクションになっている。
CVSで問題なのはトランザクションで更新されたファイルを後から調べる方法が用意されてないところ。

556 :デフォルトの名無しさん:2009/08/11(火) 00:49:05
Winで色分けして表示してくれるコマンドラインのdiffってないかな。

557 :デフォルトの名無しさん:2009/08/11(火) 03:58:38
>>556
vimdiff

558 :デフォルトの名無しさん:2009/08/11(火) 12:36:21
他のメンバーに、ちょっと試したいことがある時とかはすぐブランチ切れって言ってるんだけど、
面倒らしくなかなか切ってくれない。
trunk一本でやろうとしてて、試行が上手く行かなかった結果をコミットしたくない、とか言い出す。
そのわりに、上手く行かなかったのってどんなことやったの?ってレビューするときに、コミットしてないから忘れた、
とか言い出すw

そういうのは、ブランチ切っておいて、間違ったらコミットはするけど、そのブランチは放置しとけばいいって言ってるんだけど
どうしたもんかね。

svnって分散系に比べてブランチきるのがすげー面倒なイメージは確かにある
分散だったら極端な話、cloneするだけでそれでも一応ブランチになるし。

559 :デフォルトの名無しさん:2009/08/11(火) 12:38:00
>>556
おれはむしろ、色分け表示してくれるGUIのdiffビューアがほしい…

560 :デフォルトの名無しさん:2009/08/11(火) 12:43:28
winmergeじゃ駄目なん

561 :デフォルトの名無しさん:2009/08/11(火) 12:52:44
>>558
同感
実装が終わってないといって何週間もコミットしてくれなくて困った
進捗状況がまったく見えないし間違った方向に進んでいるかもしれないし
書きかけのコードをコミットさせる工夫はある?

562 :デフォルトの名無しさん:2009/08/11(火) 12:56:58
>>558
Subversion+MQで使えばいいと思います

563 :デフォルトの名無しさん:2009/08/11(火) 13:01:37
安易ブランチ切るなって所もあるけどな

ブランチ切るのめんどくさいって言って言う事聞かないやつには
svkでも他の分散型でも薦めたところでめんどくさくて使ってくれないだろうな

564 :558:2009/08/11(火) 13:03:00
> 書きかけのコードをコミットさせる工夫はある?

うちは、そういうのやってないなー。

チケット駆動開発してて、切りのいいところでコミットしてほしんだけど(コミットログでチケットに関連付ければいいし)、
あるメンバーはタスク1個につき、1コミットかもしくは、まとめて数タスクやってコミットとかする
そのメンバーとはプロジェクト一緒じゃないからいいけど、もうちょっとまめにコミットしようぜって言ってるw

俺は、なるべくバンバンコミットしてる方だけど。
ただ、切りがよくても動かないコードはさすがにコミットしづらい。それこそ、ブランチなんだろうけどね。

>>558
ちょっと見てみる

565 :558:2009/08/11(火) 13:08:44
> ただ、切りがよくても動かないコードはさすがにコミットしづらい。それこそ、ブランチなんだろうけどね。

ごめん、このくだり意味がわからんな。俺も読み直して意味がわからん

>>563
そうそう、面倒くさがってしまうもんだよねー

以前、TortoiseSVN使ってもらってた時も、あるメンバーがなかなかコミットしないようになったから、
なんで?って問いただして後ろから作業見てたら、
OS再インストール時にsshのパスワード入力をある程度省略するpageantの導入してくれてなくてだな
(ちゃんとインスコ方法とか俺社内マニュアルに書いたのによー)
何かことあるごとに、パスワード入力しなくちゃならないのが面倒なようだった。

TortoiseSVNで素のsvn+sshだと、コミットウインドウ開くとか、リスト取得とかログ見るとかコミットするとか、
何かするたびに頻繁にパスワードを聞かれて、俺でもいやになるわw

566 :デフォルトの名無しさん:2009/08/11(火) 13:09:28
朝一と昼に cron とかで自動的に nightly ブランチに突っ込ませてるよ。
最初、昼だけだったんだけど、
朝一は今日やる作業を戻したい時用に使ってる。

567 :デフォルトの名無しさん:2009/08/11(火) 13:10:56
めんどくさがる割にコードレビューには参加してくれるんでしょ
やり方の問題なんじゃね?

ちょっとお試しでのコミットがtagsでやって欲しいけど

568 :デフォルトの名無しさん:2009/08/11(火) 13:14:32
>>558
svnはワーキングコピーをリポジトリに直接コピー可能だから、事前にブランチ作らなくても良いのにな。
trunkで作業してて、ブランチにしたくなったらワーキングコピーをブランチにコピー、その後スイッチ。

進捗見せないとか、成果物残ってないやつは寝てるのと同じだから、俺は直ぐクビにしたい。
ソースもドキュメントもSCMで管理されていない状況は許さない。

569 :デフォルトの名無しさん:2009/08/11(火) 13:15:56
>>565の後ろの話で何がいいたいかというと、ちょっとした面倒なことでも
導入や運用のマイナスになるよね、っていいたい。

仕事だから覚えろ、とか使え、ではなかなかすまない話。人は、面倒なら使ってくれないよな。

そういう意味あいで、Dropboxってバージョン管理の利点を学ばせるのにはよかった。
全然ソースコード管理には向かないけど、「履歴が残るのは便利だ」ってのをあまり面倒なく実感できるからね。

うちのバージョン管理使ってない部署で、Dropboxが一気に広まってから、
急に、バージョン管理ソフト使おうと言い出したことがあった。
(俺が同時にVCS導入すると便利だよ、といつも啓蒙活動していたせいもあるが)

連投スマソ

570 :デフォルトの名無しさん:2009/08/11(火) 13:43:27
基本的に>>558のプロセスは糞だと思うに一票。
つか、研究かなんかか?

571 :デフォルトの名無しさん:2009/08/11(火) 13:52:47
それは言えてるな。
svnよくわかってない人間に>>558みたいな操作はやらせたくないし。

開発の人はsvnの凝った操作を憶えるのが仕事じゃないから、「こうやればできる」
って言っても「そんなわけのわからん操作が必要なツール使うのがおかしくね?」
ってことになる。


572 :デフォルトの名無しさん:2009/08/11(火) 14:05:23
うちはそう言う事をやらせたいんならドキュメント書けって言われる

書いても見てくれないんだけどね

573 :デフォルトの名無しさん:2009/08/11(火) 16:04:25
シッタカでブランチ切ってマージできないんですけど
って毎度泣きつかれるのも面倒だぞw
頼むから trunk で作業してくれとうまく丸め込むのに苦労した


574 :デフォルトの名無しさん:2009/08/11(火) 17:06:32
うちなんてバージョン管理を俺しか使ってないという…無意味にもほどがある。
バックアップ代わりになるから一人でも使ってるんだけどね。
二人以上で同一のファイルに触るなら、バージョン管理したいんだけど、小規模すぎて使う必要ないんかな…。

575 :デフォルトの名無しさん:2009/08/11(火) 17:08:21
一人でも慣れちゃうと無いと困るけど
ひとそれぞれかな


576 :デフォルトの名無しさん:2009/08/11(火) 17:42:42
>>574
そういう人にはbazaarですよ。
うちでは個人ではローカルで更新続けて、コンパイル完了で中央で上げるって運用している。

577 :デフォルトの名無しさん:2009/08/11(火) 22:07:20
俺も一人でも使ってるなぁ。
試し事してるときに、直ぐに戻せるってのは嬉しい。

578 :デフォルトの名無しさん:2009/08/12(水) 10:47:39
タイムスタンプ信者がうるさくてSVNに移行してくれない人が数人いるかな

579 :デフォルトの名無しさん:2009/08/12(水) 11:23:29
>>578
チェックアウトやアップデートで
mtimeをコミット時刻にしてほしいという人はいたな。
昔ながらにfind -mtimeで変更ファイル一覧を取得したかったらしい。

580 :foi.americanprogress.org:2009/08/17(月) 17:49:45
自動焼人 ★ = 自動保守 ◆KAWORUKOFI = 自動保守#K9K?_D[L

名言集 その2
『お前が規制系キャップ取れるか審査してやるよ』

http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/ ID:PVAf+dux0 = 自動焼人 ★

> 36 :以下、名無しにかわりましてVIPがお送りします [sage] :2009/08/10(月) 00:31:30.02 ID:PVAf+dux0
> >>33
> キャップとコテハンの違いは何?

> 46 :以下、名無しにかわりましてVIPがお送りします [sage] :2009/08/10(月) 00:38:05.34 ID:PVAf+dux0
> >>45
> その回答では落ちるなw
> 答えは教えないがw

> 50 :以下、名無しにかわりましてVIPがお送りします [sage] :2009/08/10(月) 00:41:29.96 ID:PVAf+dux0
> Q.キャップとコテハンの違いは何?
> A.2ちゃんねるのボランティアの登録制度

> それがお前の答えかw

> 52 :以下、名無しにかわりましてVIPがお送りします [sage] :2009/08/10(月) 00:43:10.06 ID:PVAf+dux0
> まぁ、どうせ正解が出るわけもないし、次の問題。
> 君が思う面白いスレはどんなの?
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください

581 :デフォルトの名無しさん:2009/08/25(火) 23:04:52
Mercurialのスレ立てたので宣伝
http://pc12.2ch.net/test/read.cgi/tech/1251208950/

582 :デフォルトの名無しさん:2009/08/26(水) 05:38:47
ちょいとお聞きしたいのですが、
とあるプロジェクトAが匿名でとってこれるsvnで用意されてありまして、しかしながら、私はコミット権はもっておりません。

その状態で、そのプロジェクトのパッチを作ったり、弄ったりしつつ、自分の弄った範囲をバージョン管理したいのですが、
よい方法はありませんでしょうか?

通常、分散であれば、cloneとかしたものは、ローカルならコミットできると思うのですが、
svnで匿名で持ってきたものはコミットできませんよね?

ただ単に、svnで匿名アクセスしローカルにもってきて.svnディレクトリを削除し、
ローカルのgitかhg(bzr)に突っ込む、
つまり、単純にソースのみ持ってきて、過去のバージョン管理を破棄し、新たに分散管理するという方法だと、
利便性がない、と感じています。

何かよい方法、ないものでしょうか?

583 :デフォルトの名無しさん:2009/08/26(水) 05:46:26
git-svn

584 :デフォルトの名無しさん:2009/08/26(水) 08:22:20
bzr-svn

585 :デフォルトの名無しさん:2009/08/26(水) 09:27:30
>>582
svk

586 :デフォルトの名無しさん:2009/08/26(水) 09:28:10
>>585
いまさらsvkは無いだろ・・・

587 :デフォルトの名無しさん:2009/08/26(水) 12:37:53
hg convert

588 :デフォルトの名無しさん:2009/08/26(水) 14:35:09
>>587
それじゃ要件を満たしていない。
bzr-svnの場合
1. svn (匿名) からチェックアウトした bzrのブランチA を作成
2. A に変更点をコミット
3. A から 新たなbzrのブランチBを作成
4. Bにさらに修正
5. Bから元のsvn(コミット権あり)にpush
6. A が svn(匿名) から pull しても、 (2) で作成されたリビジョンの同一性が保持されて (4) の
   リビジョンのみupdateされる。

1-2,6 はsvnにコミット権を持たない外部のコントリビュータの作業
3-5 はsvnにコミット権を持つ人の作業

589 :582:2009/08/26(水) 14:48:50
とりあえず、git-svnでやってみました。

リビジョン2300くらいのをhttpごしで取得してみたいのですが、
2000取得したところで、エラーでて止まっちゃう。

git gcが失敗しているみたいなんだけど、どうしたもんでしょうか。これ。

r2000 = ea22187600531bedc9f955737c171a106eaae475 (git-svn)
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 15372, done.
Compressing objects: 100% (15178/15178), done.
Writing objects: 100% (15372/15372), done.
Total 15372 (delta 10985), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
/usr/sbin/git-core//git-repack: line 137: /usr/sbin/git-core/git-update-server-info: Permission denied
error: failed to run repack
gc --auto: command returned error: 255

手動でgit gcしても同じエラーがでてしまいます。

環境は、cygwin git version 1.6.1.2、cygwin UTF-8
リポジトリは マッスルリベンジャーです

>>588
ありがとう。機会があったら、bzr-svnも試してみる

590 :582:2009/08/26(水) 14:49:31
コピペミスった・・・

> リポジトリは マッスルリベンジャーです
リポジトリは、http://rubygems.rubyforge.org/svn/ です。

591 :デフォルトの名無しさん:2009/08/26(水) 15:46:52
どういうミスだよ

592 :デフォルトの名無しさん:2009/08/26(水) 15:52:25
ワロタ

593 :デフォルトの名無しさん:2009/08/26(水) 16:20:41
>>588
hg converでsvnからとりこんでhg mergeでいける。
あるいはMQをつかう。

594 :588:2009/08/26(水) 16:32:33
>>593
すまん、svnへのpushが要件に含まれて居ないことに今気づいた。

595 :デフォルトの名無しさん:2009/08/26(水) 19:28:55
>>589
Cygwinなのが問題なのかも知れない、俺もLinuxでやってみよーと思ったけど、
r2300もフェッチしたらすごい時間かかりそうだし、rubyforgeにもちょっと悪いので、
githubで探してみたら、ミラーがありました。unofficialだけど。
http://github.com/vvs/rubygems/commits/trunk

それでこの後なんだけど、ここのミラーが更新されるのを待つのならば
このまま普通にgitで追いかければいいんだけど、git-svnで追いかけるのであれば、
git-svnのmanページのBASIC EXAMPLESに、やり方が載っています。
しかし、私の経験上、そのままだと何故かうまくいかないので、ちょっとやり方を紹介します。

$ git clone git://github.com/vvs/rubygems.git
$ cd rubygems
$ git svn init --stdlayout http://rubygems.rubyforge.org/svn
$ cat .git/refs/heads/master > .git/refs/remotes/trunk
$ git svn rebase

これでgit svn rebaseがエラーにならなければ、この後普通にgit-svnが使えると思います。

あと、マッスルリベンジャーってなに?w

596 :デフォルトの名無しさん:2009/08/26(水) 20:33:05
bzrのミラーもあるよ
https://code.launchpad.net/~vcs-imports/rubygems/trunk

597 :デフォルトの名無しさん:2009/08/26(水) 23:58:07
じわじわくるな、マッスルリベンジャー

しかしこれももはや年がばれる系に入ってきてるのか

598 :デフォルトの名無しさん:2009/08/27(木) 00:23:23
何度見ても笑ってしまう

599 :デフォルトの名無しさん:2009/08/27(木) 00:25:55
最高だw
俺もマッスルリベンジャーの名に負けないソフトウェアを作りたいと思う。

600 :582:2009/08/27(木) 07:29:22
>>595
おお!githubにミラーがあったんですね!
試しにforkして、cloneで引っ張ってきたらあっという間にローカルに持ってこられました。
自分とこでコミットしたり変更して、パッチ作って送る分にはgithubでいいのかな・・・。

git-svnのやり方も紹介していただいてありがとうございます。
後で試してみたいと思います。

>>596
launchpadにもミラーが!サンクス!!
こういうときには、ミラーがあると助かりますね。


> あと、マッスルリベンジャーってなに?w

・・・たぶん、キン肉マンの動画いろいろ見てたからクリップボードにはいってたんだと思う・・・
YouTube - キン肉マン・キン肉星王位争奪編°マッスル・リベンジャー
http://www.youtube.com/watch?v=sBv49dL2fGs

601 :デフォルトの名無しさん:2009/08/31(月) 17:34:08
git-svn って >>588 みたいに一つの svn リポジトリと不特定多数の git リポジトリの間で
分散バージョン管理できるの?
それとも、svnを中央リポジトリとして使わないといけなくて、git <-> git 間でやり取りしたリビジョンと
svn上のリビジョンの整合性は取れなくなる?

602 :デフォルトの名無しさん:2009/08/31(月) 19:14:09
>>601
git-svnは、svnリポジトリを中央にしないとダメだと思う俺の知る限り。けっこうこれキツい。
git同士ならぐるっと回って上流から戻ってきたコミット(内容は一緒だけどハッシュ値は違う)
があっても、rebaseした時にいい感じに上流のを採用してくれたりするんだけど、
svn <=> git<->git<->git という感じだと、すべてのgitはsvnにrebaseしていかないといけない。

Subversion1.5のmerge-trackingを利用して、mergeコミットぽく解釈したりできれば、、、とか
妄想するんだけど、できないもんかね。

svkが終了したので、svn <=> svn間のマージもどうしたらいいもんか、悩み中。

603 :デフォルトの名無しさん:2009/09/01(火) 00:01:58
>600
>launchpadにもミラーが!サンクス!!

何故かlaunchpadを「 レ オ パ ル ド ン 」と空目してしまった。
明日眼科逝って来る。

604 :デフォルトの名無しさん:2009/09/01(火) 10:51:14
なんだこのスレ肉マニアのおっさんばっかりかw

605 :デフォルトの名無しさん:2009/09/01(火) 15:51:45
>>604
レオパルドンは肉じゃなくて、たぶん…

まぁ、止めておこう…



606 :デフォルトの名無しさん:2009/09/01(火) 16:03:56
    ヘ⌒ヽフ
   ( ・ω・) d
   / ~つと)


607 :デフォルトの名無しさん:2009/09/02(水) 12:21:54
 ||   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(+)< 次峰レオパルドン逝きます!
    \____________

   ||     / ̄ ̄ ̄ ̄ ̄ ̄ ̄
  (+)  < グオゴゴゴ!
 /( ┴ )ヽ \_______
  ヽ_/
  / \三 )))

             ||     / ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ノーズフェンシング!! \(+)/ < ぎゃあぁぁ!
===============⇒※;)   \_______
            ヽ_/∴.:
            / \∵;.;

           ミ
        \   /  ズン!!
         二二+=
        /   \

608 :デフォルトの名無しさん:2009/09/02(水) 12:23:56
うざい

609 :デフォルトの名無しさん:2009/09/03(木) 18:37:56
>>602
svn merge で cherrypick merge とかどうなん?
bzr-svn でも bzr merge で cherrypick merge できるし。

610 :デフォルトの名無しさん:2009/09/05(土) 03:54:52
IBMのRationalClearCase(クリアケース)って言う
バージョン管理システムって相当酷いものだと聞いた。

http://www-06.ibm.com/software/jp/rational/products/scm/cc/

担当部署の人間の話だと
値段は凄まじく高い上に、制限が多いとかでほとんど使い物にならない詐欺に近い製品って話だ。
IBMのぼったくり商法に騙されたのかも知れないけど、
うちの会社もこのRationalClearCaseをCVSから一部切り替えて運用し始めてしまって引っ込みが付かなくなってしまった。
「CVSは無料だし機能的にもよっぽど使いやすい、有料ならVSSを使った方がマシ・・・」とは担当者談。
そもそもこのIBMRationalClearCase(クリアケース)はメジャーなソフトではないので、設計や導入にもかなり苦労するようだ。
CVSからの移行の工数を聞いただけでぞっとした。
こんなの売りつけられたなら、その会社はIBMのカモにされてると思ってほぼ間違いないんじゃないかと思う。


611 :デフォルトの名無しさん:2009/09/05(土) 04:20:04
>>610
元々のRationalがIBMに買収される前はそれなりだったらしいが、
買収されて以降殆ど更新されてないのだろうからいい訳がない。
つーか、企業で導入って、どんな情報弱者だよw

612 :デフォルトの名無しさん:2009/09/05(土) 04:23:30
無能担当者とその暴走を抑えられない体制はどうでもいいとして。
IBMにしてみれば顧客が居るから捨てられないんだろ。
Linuxを推し進めているのにAIXの開発から手を引かないIBMらしいエピソードだね。

613 :デフォルトの名無しさん:2009/09/05(土) 04:39:15
つーか、IBMにとっちゃRationalTeamConcertとかRationalAppScanが欲しくて買収したらおまけについて来たようなもんだろ。

614 :デフォルトの名無しさん:2009/09/05(土) 08:23:18
評価もせずにホイホイ導入するのか
普通の会社なら潰れる

615 :デフォルトの名無しさん:2009/09/05(土) 09:14:25
評価版もあるのにねぇ。

616 :デフォルトの名無しさん:2009/09/05(土) 10:33:37
うちは弱小ソフトハウスなので、その辺の事情ってよくわからんのですが、
評価はともかく(いや必要だけど)、評判とか情報が少ない製品をなぜ選ぶもんなんでしょうか?
いくら商用で、サポートとかあっても、そんなんなら、まだ情報が大目のOSSとか選びたくなるもんですけど。

617 :デフォルトの名無しさん:2009/09/05(土) 12:09:43
>>616
・自分より詳しい奴がいるのが嫌。
・コンサル/営業に吹き込まれた。
・キックバックをもらった。


618 :デフォルトの名無しさん:2009/09/05(土) 13:05:48
「あのIBMが出してる製品なんだから、間違いありませんよ」
なんて言われて真に受けちゃったとか。

619 :610:2009/09/05(土) 14:30:01
>>611-618
IBMRationalClearCase(クリアケース)なんて採用する時点で
上層部の人間が情報弱者(プロダクトの詳細も知らない、実際の現場の内情も知らない)というのは認めるが、
パートナーのIBMにすすめられてしまったら断れないという政治的な理由もあって、
一度決まったらトップダウンで話が進んでしまうんだよな。
いわゆる、上層部双方が自己満足して、後々になって現場だけが苦労するパターン。
IBMRationalClearCase(クリヤケース)がIBMに買収されてからというもの
更新もなく将来性が全くなくなったプロダクトになり下がっているのに
敢えてリスクを冒す必要があるのか?とか、
今までCVSやVSSで問題なく運用できているのに、
この不景気に無駄な資金をかけてまで果たしてやる必要があるのか?ということが問題になっているみたいだ。
CVSやVSSの開発やサポートが終了するから移行しなければならないというような必然的理由があるならまだしも
すでにある程度シェアを持っているCVSやVSSみたいなメジャーソフトが早々になくなるわけもない。
今までならCVSやVSSはどこの部署でも使っているから新たにバージョン管理を構築する際もハードルは低かったんだけど
IBMRationalClearCase(クリアケース)は超マイナープロダクトだから、
メンテナンスをする人員も新規に育成しなければならないし、
他部署向けの勉強会やらでコストだけが発生しているみたいだ。
今は、一部の部署でIBMRationalClearCase(クリアケース)になっているんだが、
他部署もそこに相乗りしろという話になってきているらしく大迷惑を被っている。
うちの部署に限って言えば、IBM製品はホームページビルダーやノーツを導入させられた経緯があるけど、
もしクリアケース導入ということになるとインパクトはでかいかも知れない。
というか、みなさんが言うように、クリヤケースはプロダクトの質が悪すぎるので積極的に使いたいとは思えない。


620 :デフォルトの名無しさん:2009/09/05(土) 15:13:12
わかった!

git-clearcase とか、 bzr-clearcase とかを作って、
自分たちは、好きなSCMをつかって、うpするとき clearcase にすれば良いんだ。


あっ、そうか!!

っていうか、cvs-clearcase とか作れば、今まで手順そのままで、
うpするときだけ、clearcase に…




621 :デフォルトの名無しさん:2009/09/05(土) 15:16:59
>>619
そういった分野では、今でもCVSやVSSが主流なんでしょうか。
gitやbzrとは言わないまでも、せめてSubversionぐらいにはならないのでしょうか。


622 :デフォルトの名無しさん:2009/09/05(土) 15:20:09
これ買ってもらえ
http://www.clearvision-cm.com/clearvision-products/clearcase-and-git-bridge-cc2git/ash_flypage.tpl.html

623 :デフォルトの名無しさん:2009/09/05(土) 15:38:39
CVSのところは某有名SIerを含めて未だ未だ多いよ。
VSSは流石に減ってきているようだけど。
皮肉なことに、逸早くCVSを導入したところほど移行できなくなっている傾向がある。

624 :デフォルトの名無しさん:2009/09/05(土) 17:14:04
IBMのSynergyっていう構成管理ツール、使ったことある人いませんか?

625 :デフォルトの名無しさん:2009/09/05(土) 17:37:08
>>619
現場の意見虫で、パートナーの提案をはいはい聞いちゃうのってすごいなー。

例えば、パートナーが「アナルセックスがしたい」と言い出したら、はいはいとケツ突き出すんだよなあ。
あげくに、パートナーが「スカルファックしたい」とか言い出した日には・・・
考えられねえ・・・

626 :デフォルトの名無しさん:2009/09/05(土) 18:47:08
>>625
ケツ突き出すとかは論外だけど、>>619みたいにパートナー製品を持ち上げることによって
受注が見込まれて事業が継続できるのなら、会社組織としてはしょうがないかもね。
利益が出せなければ事業縮小してバージョン管理どころじゃなくなるとか。
そういうのを肯定するわけじゃないけど、そういう弱い立場の事業経営をやらなくてはいけない場合も
現実としてあるのだろう。

627 :デフォルトの名無しさん:2009/09/05(土) 18:53:35
>>625
何も考えずに批判する立場って楽だよね。

628 :デフォルトの名無しさん:2009/09/05(土) 18:54:59
まるで野党だなw

629 :デフォルトの名無しさん:2009/09/05(土) 19:06:00
バージン管理システムってなんかヤラシイな・・・


630 :デフォルトの名無しさん:2009/09/05(土) 19:06:41
むしろ肯定するためにあえてあのように書いた可能性もあるが
626は大人だな。

631 :デフォルトの名無しさん:2009/09/05(土) 19:24:06
共通部だけCVSやSubversionにしといて個人個人は分散系の使うって方法もある

632 :625:2009/09/06(日) 07:11:11
冗談でいったんだけど(´・ω・`) ギャグ通じてない・・・

633 :デフォルトの名無しさん:2009/09/06(日) 10:13:07
>>631
そういうふうにやってみたがコミットが二度手間になって面倒くさくて
メリットがかなり薄くなってしまうように感じた。
gitかhgに余所のリポジトリ/ディレクトリとコマンド一発で同期してくれる
ような機能ってつかないものかな

634 :デフォルトの名無しさん:2009/09/06(日) 11:36:41
>633
二度手間ってローカル分とリモート分ってことだよな?
これを分けない上で分散型が得るメリットってなんだろう?

635 :デフォルトの名無しさん:2009/09/06(日) 11:47:14
>>634
commitとpush+pulllじゃなくて
1プロジェクトがsvnとgit/ghに分かれるのがいやといっているのではないか

636 :デフォルトの名無しさん:2009/09/06(日) 11:52:54
>>633
git-svnとかhgsvnではなく?

637 :633:2009/09/06(日) 14:20:08
欲しいのはgit-svnのようなものなんだけど、中央リポジトリがsvnやcvsのような
メジャーなものじゃないからgit-svnみたいな便利なものはないし誰かが作ってく
れることも期待できないんだ。
でまぁそういう理由で余所で更新され続けるディレクトリをあまり手間をかけずに
上手く同期してくれるような機能が組み込みであればなぁと。
まぁそんなんじゃ何かの拍子に壊れてどうにもならなくなりそうなのでほんとに
欲しいのは「git-svnの作り方」みたいなドキュメントかもしれない・・・。
ちょっと言葉足らずで誤解させたようですまんかった。

638 :デフォルトの名無しさん:2009/09/07(月) 00:07:07
>>619
なかなか縁がないアプリだし、価格がいくらなのかは全く知らないが、Clearcaseっつーのが糞ソフトだということはよーく分かった。
そもそもIBMがそんなもんを出してることすら知らんかったわ。
まあ、フツーに考えてCVSでいいだろ。
しかしうわかたの連中ってどこまでお馬鹿なんだ?
ネット検索して製品情報ぐらい集めるだろフツー。


639 :デフォルトの名無しさん:2009/09/07(月) 08:47:08
>>632
それはギャグじゃなくて皮肉だ

640 :デフォルトの名無しさん:2009/09/07(月) 09:43:01
rational と言えば、有用なのって purify くらいだと思ったけど…
rational の BTS 使ったことあるけど、あれもひどかった。

641 :デフォルトの名無しさん:2009/09/07(月) 19:17:23
>>640
Roseは?
これがメインだと思ってたが。


642 :デフォルトの名無しさん:2009/09/07(月) 19:56:27
>>641

さらば「Rational Rose」、買収製品に順次移行へ - ニュース:ITpro
ttp://itpro.nikkeibp.co.jp/article/NEWS/20081007/316339/

643 :デフォルトの名無しさん:2009/09/07(月) 21:10:42
RationalRoseなくなったら
もはやRationalじゃないじゃんって感じだね。
つか、テレロジックのRhapsodyってのはどうなのよ?
RationalRose無き後は
RasionalClearCaseを看板にすればいいかもね。


644 :デフォルトの名無しさん:2009/09/07(月) 22:57:55
VisalTestバリバリの俺が通りますよ

645 :デフォルトの名無しさん:2009/09/08(火) 01:05:29
今って何が流行なの?

みんなで書いてるソースはサーバーにsvn+sshと
なんかTracとか言うwiki連動させて
wikiでバグとか要求管理してんだけど

個人でやる場合はトータスSVNで普通に自分のマシンにリポジトリ作ってるだけだな

646 :デフォルトの名無しさん:2009/09/08(火) 01:06:53
TracのWiki使ってるとかマゾヒストか

647 :デフォルトの名無しさん:2009/09/08(火) 01:11:52
>>646
15人くらいのプロジェクトだけどガチで書いてる
マジめんどいから俺は嫌なんだ・・・

まあバグをあげるとき、要求をあげるとき、ToDoをあげるときって
wikiの雛形は決まってるんだが
いちお、svnと連動もしてるしな、その機能使ったこと無いけど・・・

バグ管理は何が流行なんだ?もちろんフリーでだ

648 :デフォルトの名無しさん:2009/09/08(火) 01:15:04
普通はチケットの方を使わないか

649 :デフォルトの名無しさん:2009/09/08(火) 01:19:42
>>648
あー、チケットももち使ってるぞ
マイルストンに向けて、openなの何個みたいな感じで
ただ、詳細な情報を書くときにwikiになるんだわ、これがだるい

650 :デフォルトの名無しさん:2009/09/08(火) 01:32:10
Tracのwikiのクソさには定評がある
RedmineだろJK

651 :デフォルトの名無しさん:2009/09/08(火) 01:37:37
>>650
さんくす、Redmineな
軽く環境作ってみて、よさげだったら提案してみるわ

652 :デフォルトの名無しさん:2009/09/08(火) 02:22:10
詳細な情報もチケットに書くのが普通だと思う
添付ファイルとかつけられるでしょ
Wikiの部分はサーバ設定とかそういう共有情報をまとめる所じゃね

653 :デフォルトの名無しさん:2009/09/08(火) 06:51:58
うちはRedmineでやってるが、何故チケットを使わんのだw Tracのチケット管理はそんなにクソなのか?w

654 :デフォルトの名無しさん:2009/09/08(火) 07:10:20
>>646, >>650
そうなの?Trac Wikiの方が書きやすいと思うけど?どの辺が気になるの?
好みの問題もあると思うけど、textile記法とmoinmoin記法ではmoinmoinの方が
Wikiコードをメールに貼り付けた時に読み易いし、いいと思うんだけど。
(慣れが大きいと思うけど)

Wikiめんどくせとかいうけど、
用語定義とか、まとめに使う分には参照・更新両方のバランスを考えるとかなり効率的な部類なのでは?


655 :デフォルトの名無しさん:2009/09/08(火) 08:34:24
Tracは基本的に良いけど、Wikiの編集はローカルでテキストエディタでしたい。
Wikiの内容を分散バージョン管理したい。

今、Launchpad4の要望調査で(Bazaarでバージョン管理された)Wikiというのが
要望高いから、moinmoinのバックエンドをBazaarに置き換えたのが開発されないか
wktkしてるところ。

656 :デフォルトの名無しさん:2009/09/08(火) 11:05:26
>>654
うちはRedmine使ってるけど、Wikiはページ名を決めるのが面倒くさい。
イテレーションごとの仕様書とかはリポジトリに突っ込むから、
そっちの補足情報とかはWikiではなくチケットに書いてる。

657 :デフォルトの名無しさん:2009/09/08(火) 12:17:21
gitの質問よいでしょうか?
指定のリビジョンの指定のファイルを取り出したいのですが、どうしたらよいのでしょうか?
git checkoutはなんか取り消す?というような記述で違うようですし・・・

658 :デフォルトの名無しさん:2009/09/08(火) 12:19:46
git show?

659 :デフォルトの名無しさん:2009/09/08(火) 21:36:47
Trac の Wiki が弱いのはわかっていますが、
うちの会社では未だに {{{ほげほげ}}} でチケットを書いてくるような池沼を相手にしなきゃいけないので、
Trac とか何とか、それ以前の状況でつ。 (鬱

660 :デフォルトの名無しさん:2009/09/08(火) 22:43:28
ちゃんとpreformatted textの指定してくれるだけましじゃんw

661 :デフォルトの名無しさん:2009/09/08(火) 23:24:43
>>659
あー、全文preで書いてんのかw 見るねそれw
textileとかmarkdownとかはてな記法とか、いっぱいありすぎて頭こんがらかってくるけど、
どれもやりたいことは数パターンで、使ってるうちに憶え、使わないうちに忘れる。
最近trac使ってないから忘れちまったなぁ。

662 :デフォルトの名無しさん:2009/09/08(火) 23:29:49
gitはギトギトしててキモイ
いかにもオタソフトって感じがダメダ

消えてなくなれ

663 :デフォルトの名無しさん:2009/09/08(火) 23:41:03
たまに居るね〜、アンチGit。なんだかなぁ。。。

664 :654:2009/09/08(火) 23:50:00
>>656
うちも仕様書等の補足情報はTicketに記述するようにしてる。仕様書作成タスクとして定義する感じで。
確かにWikiページ名はある程度課題を走らせてからでないとしっくりこないですね。

Ticketとの比較という意味で、WikiのいいところはTrac上の記述内にWikiページ名である時に自動的にリンクが生成されるところですね。
なるべくWikiには再利用される可能性が高い用語を定義するようにしてるんだけど、
Ticket内の記述が自然にマークアップされるようになるとWikiってすげーって思える。

>>659
人によっては改行が全くない状態で入れられたり。。
そういう人が多数派にならないように地道にまともな記述を増やしています。


665 :デフォルトの名無しさん:2009/09/09(水) 00:33:38
そろそろうざいんですが

666 :デフォルトの名無しさん:2009/09/09(水) 01:02:28
そういえばDAVは動きは無いのかな?
記憶が確かならVはバージョニングだったハズ

667 :デフォルトの名無しさん:2009/09/09(水) 02:52:26
そもそもBTSスレってなかったっけ、と思ったらあった。
http://pc12.2ch.net/test/read.cgi/tech/1244347242/

668 :デフォルトの名無しさん:2009/09/09(水) 07:31:51
BTSスレ池

669 :デフォルトの名無しさん:2009/09/10(木) 13:58:01
ファイルが巨大だったり沢山ありすぎるような場合は
git以外の選択肢はないのでしょうか

670 :デフォルトの名無しさん:2009/09/10(木) 14:10:24
別に何でもいいと思う
巨大ってのが1ファイルでギガとかじゃなければ

671 :デフォルトの名無しさん:2009/09/10(木) 14:14:16
squidのキャッシュフォルダーをまるごと管理しようと思っているのでギガのファイルもあるかもしれないです

672 :デフォルトの名無しさん:2009/09/10(木) 17:10:56
>>671
なんか面白そうだな。archive.orgみたいなものを作るの?

673 :デフォルトの名無しさん:2009/09/10(木) 17:54:54
>>671-672
ついでキャッシュの情報をp2pで共有できたら、
ペッパーランチみたいな事件で大活躍だな

P2Pと相性よさそうなのはdarcsか?しかし日本語がなあ

674 :デフォルトの名無しさん:2009/09/10(木) 18:27:01
分散バージョン管理をバックエンドにしたp2pのwebアーカイブ(キャッシュ、魚拓)みたいなのかw面白いなそれ

675 :デフォルトの名無しさん:2009/09/10(木) 18:40:10
>>669
gitでも何でも厳しいだろ。jk
ファイルコピーだけでもかなりの時間が。


676 :デフォルトの名無しさん:2009/09/10(木) 19:37:09
ポスグレのblobなんかで自作したほうが早い希ガス

677 :デフォルトの名無しさん:2009/09/11(金) 09:34:41
git か何かはバイナリも差分で管理しなかったっけ

678 :デフォルトの名無しさん:2009/09/11(金) 11:10:27
gitは差分じゃなくて圧縮してまるごとだから、逆に向かないような

679 :デフォルトの名無しさん:2009/09/11(金) 11:27:30
バイナリの扱いは、
svnはxdelta
cvsはそのまま
gitはまるごと(バイナリ以外も)
ほかは知らない

680 :デフォルトの名無しさん:2009/09/11(金) 11:27:36
そうか。何かバイナリを差分で扱うのがあったような。BitKeeper?

681 :デフォルトの名無しさん:2009/09/11(金) 11:44:44
>>680
>>679にあるsvnのxdeltaってのはバイナリ差分(のアルゴリズム)だよ。


682 :デフォルトの名無しさん:2009/09/11(金) 12:07:17
>>679
> gitはまるごと(バイナリ以外も)

  イ`ヘ
 /: :| ヽ
/ : :/  ヽ ___   _,,,:. .-: :´彡フ
_ノ\_∠: : : : : : : : :`: :-: :,:_:/彡 /
      ( : : : : : : : : : : : : : : `ゝ  /
  マ  r::/: /: : | : : : : : : : : ::\ /
      //: /: : : |: : | |: : |: _: : : :ヽ
  ジ  {/ 7|`\/i: /|:|/|´: : : : :|ヽ
     〉 ,‐-‐、`|7 || |_::|,_|: : :|:::|: |
  で / r:oヽ`    /.:oヽヽ: :|: | :|
     { {o:::::::}     {:::::0 }/: :|N
  っ  | ヾ:::ソ     ヾ:::ソ /|: : |
 !? ヽ::::ー-.. /ヽ ..ー-::: ヽ::| r--ッ
-tヽ/´|`::::::::::;/   `、 ::::::::::: /: i }  >
::∧: : :|: |J   \   /   /::i: | /_ゝ
. \ヾ: |::|` - ,, ___`-´_ ,, - ´|: : :|:::|
   ヽ: |::|\     ̄/ /|  |: : :|: |

683 :デフォルトの名無しさん:2009/09/11(金) 12:08:39
クリアケースは糞


684 :デフォルトの名無しさん:2009/09/11(金) 12:42:21
>>682
それでもリポジトリのほうが小さかったりするけどね。
例えばlinux-2.6はソースが404M、全履歴含むリポジトリが352M。

685 :デフォルトの名無しさん:2009/09/11(金) 13:35:59
まるごとつーても、packはあるからな。


686 :デフォルトの名無しさん:2009/09/11(金) 15:43:59
>>685
packって
差分を取り出すかわりに
複数の履歴を一まとめに圧縮することで重複をなくすってことか?

687 :デフォルトの名無しさん:2009/09/11(金) 16:53:30
そろそろCVSから移行しようかと思うんですが、
subversionとmercurialのどちらがおすすめですか?


688 :デフォルトの名無しさん:2009/09/11(金) 16:54:59
そう言う聞き方をするバカにはSVN使ってれば良いと思います

689 :デフォルトの名無しさん:2009/09/11(金) 17:35:13
そう言う聞き方をするバカにはCLEARCASE使ってれば良いと思います

690 :デフォルトの名無しさん:2009/09/11(金) 17:48:35
git がいいと思うけどなー

691 :デフォルトの名無しさん:2009/09/11(金) 18:06:47
集中型に比べた分散型のメリットがわからないのでsvnのまま現在に至る。

692 :デフォルトの名無しさん:2009/09/11(金) 18:39:00
>>687
CVS→Subversionの方がCVS→Mercurialよりも覚えることが少ないので
まずはSubversionを使うのがいいと思います。

693 :デフォルトの名無しさん:2009/09/11(金) 18:39:32
フリーでバイナリー差分ができるのがsvnのみってことでいいの?

694 :デフォルトの名無しさん:2009/09/11(金) 18:45:34
>>693
バイナリ差分って具体的に何?
バイナリファイルのdiffをパッチとして送るってこと?
それともリポジトリの格納形式を気にしてる?

695 :デフォルトの名無しさん:2009/09/11(金) 18:50:43
svn updateしてdllとか更新されたときにmergeって表示される時があるけど
恐いから削除して更新し直してる

696 :デフォルトの名無しさん:2009/09/11(金) 22:19:03
>689
cleacaseってそんなにいいの??


697 :デフォルトの名無しさん:2009/09/11(金) 22:28:03
Rubyでできたオブジェクト指向なバージョン管理システムはありませんか?

698 :デフォルトの名無しさん:2009/09/11(金) 22:31:26
そういえばRuby製は聞かないな。
オブジェクト指向なVCSってのは何を指してるのかわからんが。

699 :デフォルトの名無しさん:2009/09/11(金) 22:56:38
>>691 俺もそう思う。
分散型といっても最終的にはマージしなくちゃならないんだから、差異が多くなる前にマージしないと競合が激しくなるんじゃないのかな。
こまめにマージするなら集中型と変わらないんじゃないかな?


700 :デフォルトの名無しさん:2009/09/11(金) 23:13:14
>>699
分散型は、よくあるコミット権云々のしがらみから解放される。
パッチ送ったのになんで取り込まないんだよ云々からも解放される。

701 :デフォルトの名無しさん:2009/09/11(金) 23:21:00
誰でもコミット(push?)できるの?怖くない?

702 :デフォルトの名無しさん:2009/09/11(金) 23:26:57
>>701
自分ちにコミットしても誰も怒らないよ

703 :デフォルトの名無しさん:2009/09/11(金) 23:43:48
それなら集中型でも俺んちリポジトリを作れば一緒のような気がする。
元が更新されても差分を俺んちリポジトリにマージすればいいんだし。


704 :デフォルトの名無しさん:2009/09/11(金) 23:49:22
3way mergeうんぬん

705 :デフォルトの名無しさん:2009/09/11(金) 23:58:59
>>704なるほど。
分散型はmergeが偉いという認識でいいの?


706 :デフォルトの名無しさん:2009/09/11(金) 23:59:28
>>703
その通りなんだが、集中型はもともとそういう用途向けに作られてないし、
そうやって俺んちリポジトリにマージしながら使うのって、
『集中』してないよな…
そういう用途には分散型が適してる。

707 :デフォルトの名無しさん:2009/09/12(土) 08:38:01
>>679 >>684
本当だ。700kbのexeバイナリつっこんで、毎回コンパイルするのを想定して、バイナリエディタで弄ったのをコミットしたら、
毎回圧縮されたと思わしき、400kbずつリポジトリが増えていった。

githubにexe突っ込むのやめないといけないな、これは。

708 :デフォルトの名無しさん:2009/09/12(土) 08:39:25
>>703
使い方がまさに分散型なのだがw

709 :デフォルトの名無しさん:2009/09/12(土) 08:44:50
実効ファイルの差分ならgoogleが凄いの出してたな。courgetteってやつ。逆アセしてdiff取るらしい。

710 :デフォルトの名無しさん:2009/09/12(土) 09:43:04
>>709
Chromeの更新に使ってるやつだね。
確かに逆アセまでやるところがすごいと思ったわw

711 :デフォルトの名無しさん:2009/09/12(土) 10:08:21
>>709
Google Chromeのソフトアップデート用圧縮技術Courgetteが面白そうなのでちょっと考えてみた (blog@browncat.org)
http://blog.browncat.org/2009/07/google_chrome_courgette.html

これか。
逆アセしてテキストで差分とる?だろ、パッチあてるときどうすんのかな。
パッチあてるexeを逆アセして、パッチあてて、またアセンブルするってことか?

712 :デフォルトの名無しさん:2009/09/12(土) 10:33:38
完全な逆アセンブルまではしてないんじゃないかなあ。
単なるバイト列じゃなくて、各命令の境界やオペコードとオペランドの境界を見た上で
いろいろやるってことじゃないかという気がする。
オペランドに即値やアドレス指定がある場合にも何かやるんだろうけど。

713 :デフォルトの名無しさん:2009/09/12(土) 10:39:07
>>697
MercurialもBazaarも、Python2.4から2.6で動く。2.4が出たのは2004年だ。
Rubyだと1.8.2が出たころだけど、Rubyで1.8.2から1.8.7までサポートするのはPythonよりも
大変だろう。
WindowsのサポートもPythonに比べてRubyは貧弱。
使い捨てWebアプリならともかく、VCSをRubyで作る利点は無いな。

714 :デフォルトの名無しさん:2009/09/12(土) 15:30:26
Ruby界隈であんだけgit広まってるわけで、わざわざ作る理由がないな

715 :デフォルトの名無しさん:2009/09/14(月) 03:38:00
git logしたときに,コミットメッセージが長いとターミナルに全部表示されないんだけど,
長いメッセージを自動で折り返すようにするにはどうしたらいいの?
ちなみにcygwin上で使ってます.

716 :デフォルトの名無しさん:2009/09/14(月) 07:59:23
>>713
>Rubyだと1.8.2が出たころだけど、Rubyで1.8.2から1.8.7までサポートするのはPythonよりも
>大変だろう。

まったく逆。Rubyは1.8.6まではバグフィックスが主だから、1.8.xをサポートするのは簡単。1.8と1.9の両方をサポートするのも難しくない。
Pythonは2.4と2.5と2.6で機能が大幅に強化されている。2.5や2.6の新機能を使うと2.4ではうごかないし、新機能を使わないとコード書くのが面倒。
しかも2.xと3.0の両方で動かすのはほぼ無理。hgとbzrが3.0で動くようになる日はいつだろう。


717 :デフォルトの名無しさん:2009/09/14(月) 09:41:20
>>716
Ruby脳に犯されていないか?言語仕様だけでなく標準ライブラリのことも考えてる?
Ruby は x.y.z の z の変更だけで新機能が入る。 Python は z の変更はバグフィックスonly.
Ruby で 1.8.2 〜 1.8.6 に対応しようと思ったら、Pythonの 2.4 〜 2.6 と同じく途中から入った
機能は使えない。
後はどれくらいバージョン間の互換性が取られていたり移行がサポートされているかだけど、
Pythonは互換性を破壊するような変更は基本入らない。どうしても古いAPIと互換性の無い
拡張をしたかったら、urllibとurllib2があるようにパッケージを分けて互換性を壊さない。

実際問題、Rubyは使い捨てWebアプリでよく使われていて、Pythonはいろんな場所で継続して
使われてるだろ。

718 :デフォルトの名無しさん:2009/09/14(月) 10:35:46
>>717
最近のRubyしか知らない人なら、大きな差と言えば1.8.6前後や1.9の差
くらいしか知らないだろうから、それ以前の差異を軽く見てるかもしれな
いけど、それ以前からRuby使ってるなら>>716みたいなたわごとは言わ
ない。1.8系間での互換性のなさは身を持って知ってるはずだから。


719 :デフォルトの名無しさん:2009/09/14(月) 10:37:24
>>717
>Ruby は x.y.z の z の変更だけで新機能が入る。

具体的にどんな機能?1.8.7はそうだけど、それ以前ではめぼしい物は思いつかない。
あとRubyは x.y.z.p だからね。Pythonとバージョン番号の付け方が異なるのに、同じように論じてる717は可哀想なひと。

> Ruby で 1.8.2 〜 1.8.6 に対応しようと思ったら、Pythonの 2.4 〜 2.6 と同じ> く途中から入った
> 機能は使えない。

だから具体的にどんな機能が1.8.xで入ったの?

720 :デフォルトの名無しさん:2009/09/14(月) 10:39:43
>>719
わかっててきくな。

お前らそろそろアンチRubyスレにいけ。鏡で顔見ろ

721 :デフォルトの名無しさん:2009/09/14(月) 10:39:58
>>718
>1.8系間での互換性のなさは身を持って知ってるはずだから。
具体的にどうぞー!

722 :デフォルトの名無しさん:2009/09/14(月) 10:43:11
>>720
なにこいつ、具体的な内容なにひとつわかってないのに罵詈雑言まきちらしてたわけ?アンチRubyキモー!

723 :デフォルトの名無しさん:2009/09/14(月) 10:47:08
これぐらいで満足していただけないでしょうか?
http://www.ruby-lang.org/ja/man/html/ruby_1_8_2_feature.html
http://www.ruby-lang.org/ja/man/html/ruby_1_8_3_feature.html
http://www.ruby-lang.org/ja/man/html/ruby_1_8_4_feature.html
http://www.ruby-lang.org/ja/man/html/ruby_1_8_5_feature.html

724 :デフォルトの名無しさん:2009/09/14(月) 11:20:43
それ読んだのか?基本的にバグフィックスと、軽微な仕様変更だけじゃないか。
互換性がなくて困るほどの仕様変更ってどれさ?1.8.2から1.8.7までをサポートするうえで困る仕様変更って何?
>>718
>1.8系間での互換性のなさは身を持って知ってるはずだから。
1.8.2から毎日使ってるけど、互換性のなさで困ったことはRuby本体ではない(Railsはしょっちゅう)。
おまえが困った非互換性ってどんなのがあったの?まじで教えてほしいんだけど。


725 :デフォルトの名無しさん:2009/09/14(月) 11:39:54
ruby は1.9.2 がstableになった後、gemが安定し始めたら、test始めていいんじゃないかと。
そこそこ混乱するだろうけど、収束は早いのではないかと。

Python は外部ライブラリに頼る物は、世代移行や後方互換が難しい上に、
多方面に影響するので、php4、php5の様に、2.5.4 と3.1.1は別枠で投入された方が良いと思う。


726 :デフォルトの名無しさん:2009/09/14(月) 12:17:04
pythonとrubyの戦いは言語スレでやってちょ。

727 :デフォルトの名無しさん:2009/09/14(月) 14:36:07
スレタイよめよ・・・

728 :デフォルトの名無しさん:2009/09/14(月) 14:37:01
>>720-726
誘導
【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】
http://pc12.2ch.net/test/read.cgi/tech/1248487404/

729 :デフォルトの名無しさん:2009/09/14(月) 14:47:57
haskellでいいじゃん

730 :デフォルトの名無しさん:2009/09/14(月) 15:34:52
Python 3.0 は過去のしがらみを捨てた大掃除なんだから、比べるとしたらRuby 1.9じゃなくてRuby 2.0だろ常考・・・

731 :デフォルトの名無しさん:2009/09/14(月) 22:02:51
Ruby1.6 の頃から使ってる俺拡張ライブラリがあるけど
ヘッダが #ifdef だらけでえらいことになっとるw

StringPtrとかARRAY_LENとかrb_io_tとか


732 :デフォルトの名無しさん:2009/09/15(火) 07:42:27
どっちもどっちのくだらない言語のはなしはいいよ
スレタイ2回読んでくれ


733 :デフォルトの名無しさん:2009/09/15(火) 13:39:59
日本語のテキストって、utfにしとけばバイナリじゃない扱いになるの?

734 :デフォルトの名無しさん:2009/09/15(火) 14:29:48
>>733
バージョン管理システムによっても違うと思います。
自分が使っているSubversion、Mercurialは
UTF-8はテキストとして差分表示できます。

735 :デフォルトの名無しさん:2009/09/15(火) 16:25:41
>>733
Subversionは、確実な方法としてversioned propertyというものを
設定できるので、それで mime-type やら encoding やらを設定しておけば良い。
hgとbzrは、今のところファイル内に '\0' バイトがあるかないかでバイナリファイルか
否かを判別してたと思う。
bzrは将来的にsvnと同じようなプロパティをサポートする雰囲気。

736 :デフォルトの名無しさん:2009/09/15(火) 20:21:04
>>735
> bzrは将来的にsvnと同じようなプロパティをサポートする雰囲気。
その点、hgは絶望的だ・・・orz

737 :デフォルトの名無しさん:2009/09/15(火) 20:32:06
bzrはsvnと志向が似てる分、svnと同じように完成度が上がるのに時間がかかってる気がする。
もうすぐ2.0になってまともなリポジトリフォーマットがデフォルトになるけど、そのあとにもNestedTreeとか
HistoryHorizonとか、コピーとか、なんでこれがまだねーんだよという機能が保留されてる。

738 :デフォルトの名無しさん:2009/09/15(火) 20:56:38
>>737
NestedTreeとHistoryHorizonについて解説よろしく

739 :デフォルトの名無しさん:2009/09/15(火) 21:12:42
>>738
NestedTreeは、svnのexternal reference.
ツリー内に他のツリーを含める事。

HistoryHorizonは、git の --depthオプション相当。
古い履歴を切ることで、大きいプロジェクトを初めてチェックアウトするときに
短時間で出来るようにする。

今でも stacked branch とか lightweight checkout という機能があるんだけど、
これは古い履歴を見えないようにするんじゃなくて外部から取ってくる機能なので、
リモートからlightweight checkoutとかしたらオフラインで作業が出来なくなる。
gitのdepthはpushを保障していないけど、bzrはきちんと整合性を維持できる形で
実装したい気持ちはある。気持ちがあるだけで今のところ実装始まってない。

740 :デフォルトの名無しさん:2009/09/17(木) 03:22:40
InkscapeのDVCS決めでBzr派とGit派が対立中。
http://www.nabble.com/DVCS-Discussion---Vote-to25430189.html

741 :sage:2009/09/17(木) 16:06:42
Mercurial + TortoiseHgの日本語パス及び
日本語ファイル名の問題ってまだ解決できていないのでしょうか?
(SJISというかcp932問題ですかね)
パッチが登録されているようですが、
このパッチが救世主になってくれるのかな?
ttp://mercurial.selenic.com/bts/issue1828

742 :デフォルトの名無しさん:2009/09/17(木) 16:43:52
こんなんで、domain 取っちゃうのなw
ttp://bzrvsgit.com


743 :デフォルトの名無しさん:2009/09/17(木) 18:22:51
>>741
まだ解決できてない。
fixutf8はフォルダでバグるし…早く何とかしてくれ。

744 :デフォルトの名無しさん:2009/09/17(木) 18:37:22
bzr-hgがpushにも対応したら、utf8が完全に動くhgクライアントの出来あがりw
いや、マジでそっちの方が早い気が・・・

745 :741:2009/09/17(木) 18:39:25
>>743
そうなんですね…。
ここさえなんとかなれば文句ないんですけれど。

746 :デフォルトの名無しさん:2009/09/18(金) 04:45:26
NetBeansのIDEの組み込みのMercurial拡張がUTF8対応してるかもw

747 :デフォルトの名無しさん:2009/09/18(金) 05:36:21
>>744
bzr-hgってバックエンドにhgのコード使ってたような…

748 :デフォルトの名無しさん:2009/09/18(金) 09:34:57
>>747
うん、使ってるよ。
リポジトリを読むところはhgを使っても、それで取り出したUTF-8をBazaarがUnicodeとして
扱ってWindowsのUnicode APIを使ってファイルを保存してくれたら問題解決。
ある意味、fixutf8代わりにBazaarを使うの。
残念ながらまだpushできないから実用にならないけどね。

749 :デフォルトの名無しさん:2009/09/19(土) 05:22:34
> 残念ながらまだpushできないから実用にならないけどね。

ダメじゃねーかw
でも期待したいなー
bzrがフロントエンドでBitbucket.orgとか使えるようになるかもしれないんだよね?

750 :デフォルトの名無しさん:2009/09/19(土) 17:55:57
windowsでまともに使えるのは、いまだにsvnだけ?
hgなら日本語ファイルさえ使わなければ、ソースのコメントに日本語書いても大丈夫?

751 :デフォルトの名無しさん:2009/09/19(土) 18:04:44
>>750
問題ない。さすがにファイルの中身については。
TortoiseHgでもちゃんとdiff見れます。

752 :デフォルトの名無しさん:2009/09/19(土) 20:52:08
>>750
日本語ファイルでもWindowsのみで運用するなら次のバージョンでほぼ解決かも。
ttp://groups.google.com/group/mercurial-ja/browse_frm/thread/2a25b275f631cea3/1eda88c133016111?hl=ja#1eda88c133016111

753 :デフォルトの名無しさん:2009/09/19(土) 23:34:16
>>752
おっ。そんなものが公開されてたのか。
win32mbcs.pyを入れ替えたらTortoisehg0.8.2でも日本語が通るようになった。
フォルダの化け文字についてはまだだめか。

754 :デフォルトの名無しさん:2009/09/20(日) 01:06:32
>>753
うまくいったのは日本語ファイル名?
もしファイル名がうまくいったらフォルダ名でもいけると思うけどなぁ。

755 :デフォルトの名無しさん:2009/09/20(日) 02:32:06
>>754
管理表.xlsって日本語ファイル名。
ちなみに化け文字が入ったファイル・フォルダを直接コミットしようとすると反応しない。

756 :デフォルトの名無しさん:2009/09/20(日) 04:03:23

0x5C

757 :デフォルトの名無しさん:2009/09/20(日) 04:06:18
VSSの誰かが触ってる間に絶対に触れないって仕組みが納得いかない
アップする気はないけどちょっと弄らないと動かないときってあるだろ
バカヤロー

758 :デフォルトの名無しさん:2009/09/20(日) 04:19:19
よく考えないアホには一見正しそうな気がする仕組みだからねぇ
複数のファイルから成るプロジェクトだと気休め以下のゴミ仕様

759 :デフォルトの名無しさん:2009/09/20(日) 10:23:05
日付フォルダーをいっぱい作ってる人って、なかなかバージョン管理システムを
使わないね。何でだろう?


760 :デフォルトの名無しさん:2009/09/20(日) 10:35:20
聞いてみたら? たぶん学習するのがめんどくさいからだろう。

761 :デフォルトの名無しさん:2009/09/20(日) 10:44:46
>>759
日付フォルダーは目に見えるからわかりやすいんだろうな。
そもそもそういう人たちはバージョン管理システムなんてものを知らないだろう。

762 :デフォルトの名無しさん:2009/09/20(日) 10:53:52
ブランチ作るのは仰々しい by新入社員

763 :デフォルトの名無しさん:2009/09/20(日) 11:01:11
聞いたらこれでうまく行ってるって言うが、必ずどれが最新かフォルダ主に聞かないと使い物にならない。
日付が新しくてもリリース版とは限らないんだなこれが。


764 :デフォルトの名無しさん:2009/09/20(日) 11:17:16
>>755
あー、そうそう。ダメ文字はあいかわらずダメなんだよね。
ttp://www.asukaze.net/etc/vcs/hg-fixutf8.html

765 :デフォルトの名無しさん:2009/09/20(日) 11:50:14
>>755
直接っていうのは、エクスプローラでそのファイルを右クリックして、
TortoiseHgのメニューからって意味かな?
シェル拡張関連は右クリックメニュー、アイコンオーバーレイ共にダメかもしれん。
だけど TortoiseHg 0.8.2 と >>752 のメールに添付されてるwin32mbcsで
コミットダイアログから「管理表.xls」を追加したらエラー出なくて、コミットも問題なく通った。
win32mbcsを無効にしてやったらもちろん失敗。

766 :デフォルトの名無しさん:2009/09/20(日) 11:53:53
>>764
完全にだめってわけじゃない。
ダメ文字を持つファイル・フォルダを右クリック→コミットの動作は出来ない。

767 :デフォルトの名無しさん:2009/09/20(日) 12:01:00
bzr-svnってbzr branchのとき、changesetごとに何かデータ構造をメモリ上に作ったりする?
実メモリが少ないのでスラッシング起こしてbzr branchが終わらないwww


768 :デフォルトの名無しさん:2009/09/20(日) 12:56:17
>>759
バージョン管理重過ぎね?
ソース程度ならできるけどソース限定な気がする
仕様書とか無理だろ超重い

769 :デフォルトの名無しさん:2009/09/20(日) 12:58:14
1MB前後のレポート作成する限りではTortoiseSVNで管理しても全然重くない

770 :デフォルトの名無しさん:2009/09/20(日) 13:47:57
>>768
プロジェクト全体をフォルダに毎回コピーするよりも、変更分だけをコミットするほうが断然軽いよ。
極端な話、ファイルを一回修正保存するたびにコミットしたって問題ないくらいだ。


771 :デフォルトの名無しさん:2009/09/20(日) 15:05:41
>>757
Visual SourceSafe のこと?

誤解されがちだけど、オプションに
「複数ユーザによる同一ファイルのチェックアウトを許可」ってのがあるよ。
マージもできる

772 :デフォルトの名無しさん:2009/09/20(日) 17:29:59
>>768いったい何ギガの仕様書ですか?
遅いのはLANのせいとか。無線LANだと凄く遅いぞ


773 :デフォルトの名無しさん:2009/09/20(日) 19:46:56
>>771
マジか!
しかし、チェック入れてくれないだろーなー
デフォルトの糞さを呪うぜ・・・

>>772
30MBぐらいだよ
たったこんなんだけど数が増えてくるとすっげ遅いの
もう10個もコピーしてっと半日作業だよ

774 :デフォルトの名無しさん:2009/09/20(日) 19:59:20
>>767
バージョンは何?
bzr-svnのメモリ馬鹿食いが完全に直ったのは決行最近のバージョンだよ。


775 :デフォルトの名無しさん:2009/09/20(日) 20:07:11
>>773
30Mを10個で半日というのはあまりにも遅すぎる。何か別の問題ではないか

776 :デフォルトの名無しさん:2009/09/20(日) 22:28:40
>>773
とりあえず別のPCとか環境で試してみたらどうよ?

777 :デフォルトの名無しさん:2009/09/20(日) 22:42:35
履歴の多さが遅さに直結してるような気がするなぁ〜

778 :デフォルトの名無しさん:2009/09/20(日) 23:09:44
svnのdumpをsvnで管理したらどうなるかなと思って1G位のdumpをsvnに食わせて試したことも有るけど平気だったけどなあ。
何でだろう。


779 :デフォルトの名無しさん:2009/09/20(日) 23:44:28
>>773
そもそもコミットする気がないなら、ローカルファイルのリードオンリー属性外せばいいだけじゃないか?
VSSはしばらく使ってないが、最近はそれだけじゃローカルファイルを編集できなくなったのか?

780 :デフォルトの名無しさん:2009/09/21(月) 00:03:13
>>779
結構しつこく撥ねられるんだぜ

781 :デフォルトの名無しさん:2009/09/21(月) 00:27:48
そういやTortoiseSVN使ってて、SVNレポジトリをNAS(LinkStation)に置いてたら妙に遅かったな
明らかにネットワーク的遅さとは異質だった

782 :デフォルトの名無しさん:2009/09/21(月) 11:04:51
>>781 おいらのNASもそうだ。ファイルの転送速度は十分有るけど。新規ファイルの作成、伸張が遅いようだね。
NASにリポジトリ置くとローカルに比べてチェックアウトの時間は1.5倍、コミット時間は6倍になったよ。


783 :デフォルトの名無しさん:2009/09/21(月) 11:19:52
>>782
そもそもHDDのスペックが貧弱なんじゃないの?

784 :デフォルトの名無しさん:2009/09/21(月) 11:31:14
>>780
編集したいファイルが沢山あるってこと?
なら、ブランチを作成したほうがいいのでは?
vssはブランチ作成は簡単に出来た記憶がある。
でも、マージは面倒だったっけ?

785 :デフォルトの名無しさん:2009/09/21(月) 11:39:28
VSSもマージは簡単だった


786 :デフォルトの名無しさん:2009/09/21(月) 11:42:26
使ったことないけど、ではVSSが叩かれるのはなぜ?

787 :デフォルトの名無しさん:2009/09/21(月) 11:52:07
昔vssで今svnだけどvssが悪いとは思わないな。
ロックによる方法が古臭いと思うけど、モジュール分けを丁寧にすればロック競合なんて問題にならないし。
しいて言えば、バージョンアップのニュースは聞かないし、高いって所かな。
あとはマイクロソフトだからじゃないか?


788 :デフォルトの名無しさん:2009/09/21(月) 12:05:43
元々個人向けあるいは小規模チーム用の製品で MS 自身も使ってない上に
本当かどうかはわからないけどデータが壊れやすいみたいな話があったように思う

789 :デフォルトの名無しさん:2009/09/21(月) 13:04:05
>ロックによる方法が古臭いと思うけど、モジュール分けを丁寧にすればロック競合なんて問題にならないし。

そりゃ悪いとは思わないだろうなぁ。


790 :デフォルトの名無しさん:2009/09/21(月) 20:53:19
ロック型は複数ファイルを扱うツールやバッチファイルなんかと相性が悪い。
基本的にファイルを書き換える前にロックしなければいけないから、利便性の
ためにツールのプラグインとしてそのロック操作が組み込まれたりするが、そ
のプラグインが大抵親ソフトのバージョンアップについて行かないんで、バー
ジョン管理ツールの都合で開発ツールのバージョンがロックインされてしまう
ということが起こる。

791 :デフォルトの名無しさん:2009/09/21(月) 22:40:30
>>788
MSがドッグフードしてないってのはわりと有名な話だよ・・・

792 :デフォルトの名無しさん:2009/09/22(火) 02:56:11
MSの内部で
VSSを試したら直したはずのバグがいつの間にか元通りとか。
MS Projectで工程管理していたらスケジュールが破綻したとか。

まあ都市伝説みたいなものだと思うが。


793 :デフォルトの名無しさん:2009/09/22(火) 03:14:31
これね
ttp://d.hatena.ne.jp/softether/20060202#p2
[質問](中略)現在ではどういうツールを使ってバージョン管理を行っているか?
自社内で共通のソースコード管理ツールがあるのでそれを使う。
ソースコードの流れで、たとえばバージョン分岐などの管理もこれでうまくできる。

[質問] では、Visual SourceSafe などは使っていないのか?
Visual SourceSafe は使わない。あれはビギナー (初心者) 向けのソフトだ。



794 :デフォルトの名無しさん:2009/09/22(火) 06:15:50
Team Foundation Serverがあるしねぇ。





795 :デフォルトの名無しさん:2009/09/22(火) 11:57:23
Visual SourceSafe は 2010 もでないようだし
そろそろフェードアウトくさいけどね

796 :デフォルトの名無しさん:2009/09/22(火) 12:10:43
IBMのクリアケース使いにくい・・・


797 :416:2009/09/22(火) 12:38:19
bzr-2.0rc2-5 にTBZR 0.3 が入ったのはいいんだけど、シェル拡張部分だけなぜか
0.2の物が入ってて、オーバーレイされるアイコンが間違ってるorz

ちなみに、 TBZR 0.3 では、 >>561 の対策が半分入ってる。
THGと同じように、'unversioned' アイコンをキャッシュされてないファイルにオーバーレイ
表示してる。

798 :797:2009/09/22(火) 12:39:03
Bazaarスレに書き込むつもりが誤爆した・・・スマソ

799 :デフォルトの名無しさん:2009/09/22(火) 15:45:49
>>797
TBZRは中の人、一人で頑張ってるから勘弁してやってくれ。
つか、こんなとこでボヤいてないでバグトラッカーに報告すればいいのに。

800 :デフォルトの名無しさん:2009/09/22(火) 16:39:59
>>799
あえて突っ込む必要があるのかわからんが、(>>797の)416 はTortoiseBzrのTop contributorなわけだがw

801 :デフォルトの名無しさん:2009/09/22(火) 16:51:40
>>740の結果、InkscapeはBazaarを使うことになった模様。
http://www.nabble.com/DVCS-Vote-Tally-td25502877.html

802 :デフォルトの名無しさん:2009/09/22(火) 20:29:18
LinuxやUnix専用のツールはgitで十分、クロスプラットフォームアプリの開発なら
Bazaar、っていう方向性になってきたのかな。
Mercurialは使いやすいgitという感じで、キャラが中途半端だな。

803 :デフォルトの名無しさん:2009/09/23(水) 14:09:07
>>774
既知の問題だったんだ。情報どうもありがとう。
bzr-1.18 + bzr-svn-0.6.5 でダメだったから、さっきbzr-1.18 + bzr-svn-1.0.0rc1 で
やってみたけど、メモリ食いまくりは変わらずだった。
BTS見てみたら、メモリ消費関連でまだつぶせてないバグあるみたいだから、
もう少し様子みてみることにするよ。


804 :デフォルトの名無しさん:2009/09/23(水) 16:00:13
>>796
クリアケースみたいなろくに書籍も情報もないようなアプリ使うなよ・・・
おとなしくCVSかSubVersion使うことをおヌヌめする


805 :デフォルトの名無しさん:2009/09/23(水) 16:00:36
>>803
あちゃー。なんだろ。tdbが有効になってない場合とかにまだ穴があるのかな・・・

806 :デフォルトの名無しさん:2009/09/23(水) 22:10:53
>>804
いやいや、クリアケースを使っているということは
恐らく使わざるを得ない状況にあるんだろう

807 :デフォルトの名無しさん:2009/09/24(木) 06:35:30
クリアケースってCVSなんかと比べるとかなり後発なんじゃないの?
後発でもダメなソフトっていっぱいあるけどな


808 :デフォルトの名無しさん:2009/09/24(木) 20:28:10
ダメでも、IBMと提携してるからとかいう理由で使っているんじゃね?

809 :デフォルトの名無しさん:2009/09/27(日) 11:27:25
darcsからbzrにのりかえようとしてるんだけど
bzrはこんなことできます?

python2.5用に作ったコードを別ブランチで管理
python3.0用を別ブランチで管理

必要に応じてpython2.5からpython3.0への変更を残したまま
python2.5用に作った新機能をpython3.0にとりこむ
その逆もする

810 :416:2009/09/27(日) 13:10:49
>>809
多分、cherrypickのことを言ってるんだよね。
まだ翻訳中だけどドキュメントはこちら
http://methane.sakura.ne.jp/bzr/user-guide/adv_merging.html

811 :デフォルトの名無しさん:2009/09/28(月) 10:50:14
bzr重いね
windowsで使ってると何度も最新に更新ボタンおさないといけない

812 :デフォルトの名無しさん:2009/09/28(月) 12:46:45
>>811
それはbzrが重いのかエクスプローラが重いのか、或いはbzrの周辺ツールが重いのか解っているのかな?
ついでに言えば、何と較べて重いと思っているのかな?

813 :デフォルトの名無しさん:2009/09/28(月) 13:09:16
>>812
torrtizeSvn使ってた時はもっと軽かった

814 :デフォルトの名無しさん:2009/09/28(月) 13:42:54
bzrが重いって言ってるのに、何でエクスプローラの話題を持ち出すのか

815 :デフォルトの名無しさん:2009/09/28(月) 14:23:49
>>814
>813
どうやらtortoiseSVNとtortoiseBzrを較べているらしいよ。

816 :デフォルトの名無しさん:2009/09/28(月) 16:23:09
は?

817 :デフォルトの名無しさん:2009/09/28(月) 22:42:19
>>811
TortoiseBZRの開発者です。よかったら、バージョンとか、具体的な症状とかを
Bazaarスレかgoogle groupsのbazaar-jaに書き込んでください。
何度も更新ボタンを押さないといけないというのは、 '?' アイコンが表示されるから
最新のステータスを見るために押すのか、それとも何かの作業をした後で古い
ステータスが表示されたままなのか・・・両方かな。

個人的にはステータスが '?' のときに幾つかのメニューが表示されないのが一番の
問題と思ってるのですが、いつでも最新のステータス見たいですか?
いつでも最新の状態を見せようとすると、今の設計のままだとバックグラウンドで
動かしてるキャッシュプロセスの方が重くなってしまうから、なんとかしないとなぁ。

818 :デフォルトの名無しさん:2009/09/29(火) 01:54:54
え?

819 :デフォルトの名無しさん:2009/09/29(火) 02:07:41
プロファイラで分析してキャッシュプロセス高速化するしかなくね?

820 :デフォルトの名無しさん:2009/09/29(火) 02:21:16
>>819
ファイルアクセスに時間かかってる気がする。
最適化してもたいして速くならないんじゃないかなぁ。

821 :デフォルトの名無しさん:2009/09/29(火) 05:53:16
TortoiseBZRをエクスプローラでなくX-Finderで使うと
何もない場所で右クリックしたときのメニューがおかしい
アイコンの並び替えが、途中に混ざる

ファイルを右クリックした場合は問題ない

X-Finder側の問題?

822 :デフォルトの名無しさん:2009/09/29(火) 08:34:28
x-finderは挙動が怪しい時があるね

823 :817:2009/09/29(火) 10:36:00
ステータスチェックって、bzrの本体にやらせてるけど、多分、最新リビジョンから
取り出したファイルとディスク上のファイルを普通に比較してるんだと思う。

NTFSって、ファイルのCRCか何かをファイルの中身を読まないで取得することって
できるんだっけ?できるんだったら、それ使って独自の高速化が考えられるかも。

824 :デフォルトの名無しさん:2009/09/29(火) 11:08:01
割切ってタイムスタンプだけ見るとか

825 :デフォルトの名無しさん:2009/09/29(火) 11:12:05
どうでもいいけど、各論は各ツールのスレでお願いしたい。

826 :820:2009/09/29(火) 11:26:10
>>823
TortoiseHg開発者(というかpatch contributor)です。
TortoiseHgでアイコンオーバーレイを現状のC++ではなくPythonで実現している頃、
そのあまりの遅さにコミットダイアログのファイル一覧に持たせるアイデアがありました。
つまり、ファイル一覧をWindowsエクスプローラのようなツリービューにしてしまって、
そこにファイル状態を示すアイコンをオーバーレイしよう、という感じです。

このアイデアは忘れ去られつつありますが、C++実装の今でもまだ利点があります。
まず巨大リポジトリではアイコンオーバーレイが遅くて使い物にならないので、
アイコンオーバーレイの機能をオフにしている人にとっては有効。
加えてアイコンオーバーレイの空きスロット問題が起きた時のフォールバックとして有効。
みんながTortoiseSVNのTortoiseOverlaysを使えばこの問題はほぼ回避できるのですが、
TortoiseOverlaysを利用していないアプリがあるとスロットが占有されてしまいます。
あとWindows 7とかではWindows自体がリザーブしてるスロット数がXPより多いとかで
空きスロット問題が再発してたりもします。

おそらくこのあたりを考慮して(開発リーダー)SteveのTODOリストには項目が残っていて、
このissueもopenなままになっています:
http://bitbucket.org/tortoisehg/stable/issue/2/status-dialog-tree-view-using-overlay

ただ、これが次期0.9で実現される可能性はかなり薄いですが・・・。

> NTFSって、ファイルのCRCか何かをファイルの中身を読まないで取得することって
> できるんだっけ?できるんだったら、それ使って独自の高速化が考えられるかも。

残念なことにチェックサムは常に0だそうな・・・
http://iss.x0.com/software/useful/filesystem.html


827 :817:2009/09/29(火) 13:19:16
>>826
ええっと、Twitterでつながってる人ですよね。その節はお世話になりました。
空きスロット問題は悩ましいですね。いまさらTortoiseSVN開発者に
"LockedなんていらないからUnversionedアイコン優先しろ!"とか言えない。

TortoiseBZRが提供している機能は基本的にシェル周りだけで、
コミット画面等はQBzrに丸投げしてます。
アイコンオーバーレイをオフにして、コンテキストメニューはコンテキストに依存しないで
常にフル表示するオプションがあるといい気もしますね。

828 :デフォルトの名無しさん:2009/09/29(火) 15:49:57
>>826-827
>>825

829 :名無し募集中。。。:2009/09/29(火) 17:06:09
まあ出会いがある事は良い事じゃないか
やりすぎなければね

830 :デフォルトの名無しさん:2009/09/29(火) 19:15:28
人との出会いは大切にしたい。
と、ぼっちの俺はいつも思ってる。 。・゚・(ノД`)・゚・。


831 :デフォルトの名無しさん:2009/09/30(水) 04:07:45
異なるバージョン管理ツールの開発者が似た機能について語り合ってるのは
スレタイにふさわしいと思うぞ。

832 :デフォルトの名無しさん:2009/09/30(水) 08:36:06
>>779
できない
他のユーザーがチェックアウト中です
ってメッセージが出て編集できない
アド民の人に複数ユーザで使えるようにチェック入れてもらうしかない

833 :826:2009/09/30(水) 13:43:54
>>827
> ええっと、Twitterでつながってる人ですよね。その節はお世話になりました。

いえいえ、こちらこそPythonの参照関連のアドバイスは本当に助かりました。

> 空きスロット問題は悩ましいですね。いまさらTortoiseSVN開発者に
> "LockedなんていらないからUnversionedアイコン優先しろ!"とか言えない。

たしかに。ぶっちゃけいらないアイコンの方が多いんですよね。

> TortoiseBZRが提供している機能は基本的にシェル周りだけで、
> コミット画面等はQBzrに丸投げしてます。

あ、そうなんですか。
となるともしやるならQBzrに相談が必要ですねぇ。面倒だ。

> アイコンオーバーレイをオフにして、コンテキストメニューはコンテキストに依存しないで
> 常にフル表示するオプションがあるといい気もしますね。

その機能は是非THGにも欲しいですね。
というより、現状のTHGのコンテキストメニューはあまり賢くないんです。
コンテキストに依存しないオプションの前にもっとコンテキストに依存する方を改善すべきかもw

834 :デフォルトの名無しさん:2009/09/30(水) 22:42:45
開発者は有意義に議論してくれ
素人は指加えてROMってるわ

835 :デフォルトの名無しさん:2009/10/01(木) 10:14:07
Windowsでまともに使えるモノにしてからリリースしろアホ

836 :デフォルトの名無しさん:2009/10/01(木) 10:36:33
>>835
バグレポート書かないで文句だけ言うのは建設的じゃない。
まともにつかえなかったのはhg?bzr?TortoiseHG?TortoiseBZR?
具体的な問題点は何?

837 :デフォルトの名無しさん:2009/10/01(木) 10:38:39
えーマジWindows? キモーイ Windowsが許されるのは小学生までだよねー

838 :デフォルトの名無しさん:2009/10/01(木) 10:44:40
>>836
・TortoiseGit UTF-8未対応な件。
cygwin 版git(UTF-8 DLL導入済み)において、マルチバイトファイル名を使うと正しくアイコン、ファイル名が表示されず、コミット不能。

・TortoiseHG
結局、マルチバイトファイル名使うには何がいいの?

839 :デフォルトの名無しさん:2009/10/01(木) 11:46:16
Windowsって大変なんだな...

840 :デフォルトの名無しさん:2009/10/01(木) 11:48:43
Windowsが大変なんじゃない、Windows対応が大変なんだ。

841 :デフォルトの名無しさん:2009/10/01(木) 11:58:15
>>840
マルチバイト対応が大変なんだろ。
THGだって、日本語使わなきゃまともに動くし。

842 :デフォルトの名無しさん:2009/10/01(木) 14:42:45
マルチバイトファイル名なんか使うやつはばかです

843 :デフォルトの名無しさん:2009/10/01(木) 14:43:05
ソースの日本語コメントがdiff窓で文字化けしてて読めない
そんなwindows

844 :デフォルトの名無しさん:2009/10/01(木) 16:39:24
Windowsにこだわるやつってなんなの? 死ぬの?

845 :デフォルトの名無しさん:2009/10/01(木) 16:49:39
Windows対応が大変というより、最初UNIXべったりで作ったのをそれ以外に持っていくのが大変なんだと思うよ。
今はWindows以外は全部UNIXになってしまっているからWindowsが叩かれるけど、OS/2やBeOSが生き残っていたら話は違ってたと思う。

846 :デフォルトの名無しさん:2009/10/01(木) 16:51:58
異端児Windowsカワイソス

847 :デフォルトの名無しさん:2009/10/01(木) 17:15:23
>>836
Windowsユーザは、新しいバージョンがリリースされるたびに評価し落胆し疲れ果ててるんだよ・・・

848 :デフォルトの名無しさん:2009/10/01(木) 17:21:35
>>845
つ Haiku

849 :デフォルトの名無しさん:2009/10/01(木) 17:59:35
>>845
>今はWindows以外は全部UNIX
ところが、総量では逆転。w


850 :826:2009/10/01(木) 22:19:12
>>838
> ・TortoiseHG
> 結局、マルチバイトファイル名使うには何がいいの?

Windowsだけで運用するという条件付きですが、最新のwin32mbcsと
TortoiseHg 0.8.2で動作確認できています。経緯はここ:
http://groups.google.com/group/mercurial-ja/browse_frm/thread/2a25b275f631cea3?hl=ja#

MLにある通り、Mercurial 1.3.1に含まれているwin32mbcsは古いので、
今すぐ使いたい場合は最新のwin32mbcsに差し替えてください。
「そういうのよくわからない」って場合は次のリリースまで待ってください。
たぶんMercurial 1.3.2のリリースと共にTortoiseHg 0.8.3も出ますので。

それと日本語関連の情報はWikiにもまとめてあります:
http://bitbucket.org/kuy/thg-ja/wiki/Japanese

851 :デフォルトの名無しさん:2009/10/01(木) 22:44:58
>>849
なにその中国人思考


852 :デフォルトの名無しさん:2009/10/02(金) 22:01:31
> Windowsだけで運用するという条件付きですが、

これがダメ。もうバケバケになったログを解読するのはいやだお

853 :デフォルトの名無しさん:2009/10/02(金) 22:19:35
また馬鹿なbzr厨が現れたのかwww
邪魔だからここに来るな

854 :デフォルトの名無しさん:2009/10/02(金) 22:24:58
必死だな

855 :826:2009/10/02(金) 23:23:56
>>852
> これがダメ。もうバケバケになったログを解読するのはいやだお

ログ?コミットログのこと?

856 :デフォルトの名無しさん:2009/10/03(土) 01:22:16
>>855
log -v でコミットログがutf-8で、ファイル名がcp932に混ざったりしない?
ひどい例だと、古いCVSリポジトリにutf-8とeucとcp932のファイル名が
混ざってたなぁ。

857 :826:2009/10/03(土) 06:28:23
>>856
うーん、最近のutf-8がデフォのLinuxでコミットしていて、Windowsからも
そのリポジトリにコミットすると確実に混ざるはずです。

「あれ、相互運用できちゃってるよ?」っていう例もあるんですが:
http://twitter.com/wtnabe/status/3977926464
http://twitter.com/wtnabe/status/3978688525
http://twitter.com/wtnabe/status/3979217435

ただ、リポジトリ内でエンコーディングがバラバラってのは
さすがにbzrでもsvnでも同じような状況になる気がするんですが・・・。


858 :デフォルトの名無しさん:2009/10/03(土) 06:31:49
>気がする
>気がする
>気がする

859 :デフォルトの名無しさん:2009/10/03(土) 10:44:40
>>857 気のせいw
svnとbzrはファイル名とかコミットログはunicodeで保存するから、それは平気。


860 :デフォルトの名無しさん:2009/10/03(土) 11:21:09
svnはもうその辺数年前に通り過ぎた道

>>850
fix-utf8でなくて、win32mbcs?
win32mbcsてマルチバイドのフォルダとかファイル名大丈夫だっけか…??
って、自分で確認しないと菜・・・

>>847
俺もういやになった
面倒だから、Tortoise系みすてて、cygwin gitでUTF-8で突っ込みまくってるwww
git statusとかでも、ファイル名が数字のコードででてきてワロスw

861 :デフォルトの名無しさん:2009/10/03(土) 11:25:45
みんなそんなに日本語のファイル名付けるん?

>>860
CygwinってUTF-8ダメなの?

862 :デフォルトの名無しさん:2009/10/03(土) 12:02:46
>>861
UTF-8 Cygwin と、Cygwin-1.7(+LANG=ja_JP.UTF-8)ならおk。
あと、ソースにはさすがに日本語ファイル名付けないけど、
「01.詳細仕様書/テーブル定義.xls」とかはふつーにあるわ。

863 :デフォルトの名無しさん:2009/10/03(土) 12:47:41
>>862
ファイル名にスラッシュを入れても大丈夫なの?
unixでどうなるんだろ。

864 :826:2009/10/03(土) 12:49:37
>>859
> >>857 気のせいw
> svnとbzrはファイル名とかコミットログはunicodeで保存するから、それは平気。

ああ、もうsvnも完全にunicodeなんですか。知りませんでした。
適当なこと言ってしまってすみません。

865 :826:2009/10/03(土) 13:07:36
>>860
> >>850
> fix-utf8でなくて、win32mbcs?
> win32mbcsてマルチバイドのフォルダとかファイル名大丈夫だっけか…??
> って、自分で確認しないと菜・・・

fixutf8をフォークしたfixutf8-jpは改良が断念されました。
http://groups.google.com/group/mercurial-ja/msg/5b6952f29f8ae561

win32mbcsが唯一今のところ問題のない手段です。Windows限定で。
Linuxとの相互運用の場合は確実な手段がありません。

コマンドプロンプトでログが化けても、TortoiseHgではちゃんと表示できる
のは、TortoiseHgが正しくエンコードできるまで複数の文字コードで試すからです。
この場合、コミットログがShift_JISでファイル内容がUTF-8でも表示されます。

866 :デフォルトの名無しさん:2009/10/03(土) 13:37:50
ファイル名は最悪我慢するにしても、コミットのメッセージがうっかりミスでSJISとEUC混在とかなったら死ねる
DVCSだと過去のメッセージの書き換えとかできなそうだし。

867 :デフォルトの名無しさん:2009/10/03(土) 13:50:48
bzrもhgも、コミットログを設定されたエンコーディングでデコードしてutf-8にエンコードするね。
でも、うっかりcp932の設定のままutf-8の文字列がcp932と勘違いされてデコードされ、
デコードエラーにならずにutf-8にエンコードされて格納されてしまったことが一度だけある。
cp932こえーわ。

868 :デフォルトの名無しさん:2009/10/03(土) 13:56:44
>>862
んじゃUTF-8 Cygwinなら、UTF-8のファイル名は化けないのかな。
UTF-8つってもMacの人が混ざると濁点がおかしくなりそうだけど…

>>866
ターミナルなら混ざってても | nkf -w とかやればそれっぽく見れるんだけどねぇ

869 :デフォルトの名無しさん:2009/10/03(土) 21:04:55
>>863
すまん、そいつはディレクトリセパレータだ。
単に日本語ディレクトリ名 + 日本語ファイル名の例を出したかっただけなんだ。

>>868
yes. Macに関しては試したことがないからわからん。お察しの通りのような気がするけど。

ただ、ファイル名がUTF-8のときにファイルの中身がShift_JIS/CP932だと、差分を見たときなどに泣ける。(テキストのドキュメントとか)

870 :デフォルトの名無しさん:2009/10/03(土) 21:31:57
結局、Unicodeを採用すると言いつつnormalizationで手を抜いてるんだなー。


871 :デフォルトの名無しさん:2009/10/03(土) 22:05:16
bzr付属のdiffが色分けしてくれて便利だ
しかし、その画面のままここだけマージしてほしい、他はだめとかしてくれないのね
emacsからすればその辺便利なのかな

872 :デフォルトの名無しさん:2009/10/03(土) 23:38:17
>>870
手を抜いているというか、手が回ってない感じだな。
svnだって対応するのに時間がかかったんだ、許してやってくれ。
https://bugs.launchpad.net/bzr/+bug/172383

873 :デフォルトの名無しさん:2009/10/04(日) 01:21:04
>>865
fixutf8-jpでも駄目な条件を知っていれば問題ないだろ。

874 :デフォルトの名無しさん:2009/10/04(日) 04:19:20
Eclipse環境(on Windows)でgitを試してみようかと思ってるんだけど、
msysgitとかeclipse用のgitプラグインとか、現状で完成度はどんなもんなんだろう。

875 :デフォルトの名無しさん:2009/10/04(日) 16:42:10
>>865
> fixutf8をフォークしたfixutf8-jpは改良が断念されました。
マジ!?期待してたのに駄目になったのかよ!

> win32mbcsが唯一今のところ問題のない手段です。Windows限定で。
> Linuxとの相互運用の場合は確実な手段がありません。
Windows限定www
いや、駄目だろそれはw
OSSなんかの開発で(bitbucket.orgに突っ込んだ場合でもいいけど)
Linuxとか他の環境と相互にできなかったらあかんわー

hgは大変だな・・・コミットするのはマズイけど、
表示だけはTortoiseHgでできる?ということでいいんでしょうか?
確かに前試した時もマルチバイト非対応時のときも見れてはいた気もします。

このとき逆にhgは(TortiseHgがね)マルチバイト対応だと思ってWindowsから突っ込みまくった、痛いリポジトリが残ってるんだよな・・・

876 :デフォルトの名無しさん:2009/10/04(日) 16:46:29
>>865のmercurial-jaのログ見たら
fixutf8-jpレベルではムリ、本家を弄れば可能性ある、ってことなのね。
>>875でちょっといいすぎてしまった、スマソ

877 :デフォルトの名無しさん:2009/10/04(日) 17:20:56
fixutf8-jpはTortoiseHgとの連携とリポジトリパスに日本語を含む場合のみ対応していない。
TortoiseHgとの連携に関してはfixutf8-jpを改良したやつがある。
リポジトリパスはプラグインを読み込む前に、リポジトリパスを設定しているから対応できない。
0x5cを含んでなくてもトランザクションファイルを作成するときにopenを使っているので動かない。

878 :デフォルトの名無しさん:2009/10/06(火) 15:25:55
Hgは、コードよりも開発者の頭の中をハックしなくちゃね・・・・
SVNなんて設計段階から、Unicode前提だったのに。

まぁ、Pythonで書き始めたときにPythonのUnicodeサポートが弱かったのが
原因なんだろうなぁ・・・・

Python3以降に開発されてるCoolなバージョン管理システムないのかな?

879 :デフォルトの名無しさん:2009/10/06(火) 16:29:53
つか、クライアントアプリは、ネイティブアプリにしてくれったら!

880 :デフォルトの名無しさん:2009/10/06(火) 19:47:40
Python 2.xのUnicodeは正直クソだと思う

881 :デフォルトの名無しさん:2009/10/06(火) 19:53:47
BazaarはPython2でもUnicodeベースで動作するんだから、Pythonの問題じゃないだろ。
ファイル名をバイト列として扱うのかUnicode文字列として扱うのかは単なる設計ポリシーの問題だ。

クロスプラットフォームのことを考えていろいろな問題に立ち向かうならUnicode、Posixの
世界に引きこもっていろいろな問題から逃げるならバイト列。

882 :デフォルトの名無しさん:2009/10/06(火) 21:01:40
>>881
unicodeの時点でTRONコードを扱えないわけで
どのへんで妥協するかの問題だな。生きていく上では重要だけど。

883 :デフォルトの名無しさん:2009/10/06(火) 21:06:04
Pythonの問題じゃない
Unicodeは正直クソ

884 :デフォルトの名無しさん:2009/10/06(火) 23:45:58
Python使ってるのが糞

885 :デフォルトの名無しさん:2009/10/07(水) 00:11:01
全く論理的な根拠を示さずPythonを攻撃しているのは大抵Ruby厨。

886 :デフォルトの名無しさん:2009/10/07(水) 00:14:24
Perl厨「計画通り!」

887 :デフォルトの名無しさん:2009/10/07(水) 00:18:27
Java厨「通りがかりです」

888 :デフォルトの名無しさん:2009/10/07(水) 01:37:23
実際rubyとpython両方使ってるとpythonはいい
食わず嫌いでrubyしかやらないのはもったいない


889 :デフォルトの名無しさん:2009/10/07(水) 01:38:54
pythonのどの辺がRubyよりいいの?

890 :デフォルトの名無しさん:2009/10/07(水) 01:52:59
Rubyのどの辺がpythonよりいいの?

891 :名無し募集中。。。:2009/10/07(水) 02:34:42
時と場合により両方使えって事ですよ

892 :デフォルトの名無しさん:2009/10/07(水) 08:54:34
そろそろスレタイ見ような

893 :デフォルトの名無しさん:2009/10/07(水) 14:04:13
日本語spam filterがrubyで書かれてるの見て、日本語処理はrubyなのかなと思うこともある

894 :デフォルトの名無しさん:2009/10/07(水) 14:15:18
Rubyに特別spam filter書きやすいような日本語対応が入っているわけじゃないし、
いい加減スレチだからLLスレにでも行ってくれ。

895 :デフォルトの名無しさん:2009/10/07(水) 14:18:31
言語的にVCSを作るには全く向いていないんだよ、Rubyは。
もしHgやGitを淘汰できるVCSがRubyでできたら俺は切腹してやってもいい。

896 :デフォルトの名無しさん:2009/10/07(水) 16:41:20
本体がPythonで書かれてると勘違いするアホまで登場する始末

897 :デフォルトの名無しさん:2009/10/07(水) 22:09:23
本体って何の本体?

898 :デフォルトの名無しさん:2009/10/07(水) 22:43:41
Mercurialはほぼpythonだろ.

899 :デフォルトの名無しさん:2009/10/08(木) 06:53:51
ある意味yumもバージョン管理システムな訳で

900 :デフォルトの名無しさん:2009/10/08(木) 06:58:15
>>899
それはほんとに ある意味 だね

901 :デフォルトの名無しさん:2009/10/08(木) 08:32:47
え?MercurialってほぼPythonなの?
糞過ぎるわ

902 :デフォルトの名無しさん:2009/10/08(木) 08:56:55
>>895
>言語的にVCSを作るには全く向いていないんだよ、Rubyは。
何を根拠にいってるんだ?Rubyに対してかれはどんなトラウマを抱えているのだろう。

>もしHgやGitを淘汰できるVCSがRubyでできたら俺は切腹してやってもいい。
今、githubの連中がGitをまるごとRubyに移植中だから、完成したらWindowsでGitを使う時の定番になるだろう。Mercurial死亡フラグ。
そのときがきたらぜひ切腹してくれ。

903 :デフォルトの名無しさん:2009/10/08(木) 09:43:55
>>902
マイナーバージョン間でも互換性がないとかなんとか

904 :デフォルトの名無しさん:2009/10/08(木) 09:56:00
>>903
それはVCSはおろか中長期的に使われるあらゆるツールに向いてないだろJK

905 :デフォルトの名無しさん:2009/10/08(木) 09:57:12
git を ruby で実装って何の意味があるんだろう? 処理が速いことが重要なんじゃなかったのか git は……

906 :デフォルトの名無しさん:2009/10/08(木) 10:27:49
>>905
Windowsで使うときにPosix互換レイヤが必要ないとかシェルやPerlが必要ないとか。
PythonでもdulwichというPure Python(一部は速度のために拡張モジュールあり)の
git リポジトリライブラリがあって、それを使ったbzr-gitが開発中。
既にWindowsで bzr branch git://foo.com/bar.git できる。

907 :デフォルトの名無しさん:2009/10/08(木) 11:46:10
頼むから、C/C++で実装してくれ

908 :デフォルトの名無しさん:2009/10/08(木) 12:37:23
gitにC++はおそらくない、というのは既知。


909 :デフォルトの名無しさん:2009/10/08(木) 16:18:08
>>904
だからWeb専用言語から脱却出来ないんじゃね?
PHP4なみに変更あるからな

910 :デフォルトの名無しさん:2009/10/08(木) 17:13:13
>>909
噂では聞いてるが本当にそんなに変わるの?
マイナーアップデートですら互換性ないとか言ったらWeb専用でも使いたくない。

911 :デフォルトの名無しさん:2009/10/08(木) 17:26:08
pythonもrubyも使うが、
rubyは標準ライブラリがpythonより多いので、そう感じるだけでは?
基本的なメソッドの上位互換性で言ったら、pythonの方が差異が大きいと思う。


912 :デフォルトの名無しさん:2009/10/08(木) 17:27:24
>>901
たとえばこのバージョンのRailsではこのRubyじゃないと動かないって縛り結構あるよ

913 :デフォルトの名無しさん:2009/10/08(木) 17:29:55
pythonは再利用が多いけど
rubyは書き捨てが多いな
なんでだろ

914 :デフォルトの名無しさん:2009/10/08(木) 17:34:17
>912


915 :デフォルトの名無しさん:2009/10/08(木) 17:46:26
互換がしっかりしてるのなんてメジャー言語だと逆にCとJavaとPerlくらいだぜ

916 :デフォルトの名無しさん:2009/10/08(木) 18:18:43
このバージョンのVCSはこのバージョンの○○では動かない

917 :デフォルトの名無しさん:2009/10/08(木) 18:30:22
>>907
C/C++で書くと、Subversionみたいに成熟度が上がるまでにすごく時間がかかるぞ。
速度が必要な部分だけCで、それ以外はPythonというのは、Linuxの世界では
かなり浸透しているんだけど、何か問題ある?

918 :デフォルトの名無しさん:2009/10/08(木) 18:34:26
>>915
それだったらC++もいれろ。


919 :デフォルトの名無しさん:2009/10/08(木) 18:36:40
>>918
C++は入れなくていい。

……っつか、コンパイルする言語だと、非互換性はあんまり意味ないんだよな。
実行ファイル作ってしまえば関係ないので。

920 :デフォルトの名無しさん:2009/10/08(木) 18:42:09
>>919
dynamic link

921 :デフォルトの名無しさん:2009/10/08(木) 19:27:54
言語レベルだけの互換性を考えても仕方ない。
HTTPリクエストするには?ディレクトリツリーをたどるには?ファイルの属性を取得するには?

Pythonを使うと、たとえばPythonのAPIだけでは足りないときにもctypesが標準ライブラリに
入っていたりして、クロスプラットフォームアプリをすごく作りやすい。

922 :デフォルトの名無しさん:2009/10/08(木) 19:47:47
日本語環境で実用レベルで使い倒せるものが出てくるなら言語なんて何でもいい

923 :デフォルトの名無しさん:2009/10/08(木) 19:53:20
emacs lispならどんな言語でもいける。

924 :デフォルトの名無しさん:2009/10/08(木) 20:41:36
MozillaのHg移行後も長いこと揉めてたBugzillaのDVCS、「圧倒的多数の支持」によってBazaarに決定

http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/0d275b79724cab9a
Mercurial嫌われすぎワロタ

925 :デフォルトの名無しさん:2009/10/08(木) 20:47:59
最近の動静を見てると、Bazaarの方が伸びそうな気はする。
名前が格好悪いのが何とかなれば使いたいレベル。

926 :デフォルトの名無しさん:2009/10/08(木) 20:51:32
ばざぁw

927 :デフォルトの名無しさん:2009/10/08(木) 21:44:21
心の中で、ござーる、と呼んで勝手に親しんでいるのは俺だけじゃあるまい

928 :デフォルトの名無しさん:2009/10/08(木) 21:55:49
ばざーるでござーる、とか突然浮かんで困ったことは以前あった

929 :デフォルトの名無しさん:2009/10/08(木) 22:18:58
会社のプロキシがWebDAVを通さなくて、httpでもsvnのチェックアウトがコケるんですが、
回避策を知ってる人がいたら教えてください。

930 :デフォルトの名無しさん:2009/10/08(木) 22:21:11
hgやbzrならWebDAVではない単なるPOSTなので、通る……たぶん。

931 :デフォルトの名無しさん:2009/10/08(木) 23:52:01
httpsなら単なるトンネルだからWebDavも通してくれるんじゃね?

932 :デフォルトの名無しさん:2009/10/08(木) 23:58:50
切腹宣言とか勇者すぎ。逃げるなよー。

933 :デフォルトの名無しさん:2009/10/09(金) 00:12:40
>929
https なら通るよ。
または ssh で隧道を掘る

934 :デフォルトの名無しさん:2009/10/09(金) 00:16:55
>>933
具体的に言うとGoogle Codeにホスティングしているプロジェクトのレポジトリなのですが、
あれってdeveloper以外でもアクセスする方法はあるんでしょうか。
何度か試してみた感じ、パスワードを要求されてしまうようです。

935 :デフォルトの名無しさん:2009/10/09(金) 00:21:47
Google Codeは、http=読み取りのみ、https=書き込み権あり、の使い分けだからなー。
……ノーマルhttpでも個々のファイルは見えるので、wgetで取っちゃえば?

936 :デフォルトの名無しさん:2009/10/09(金) 00:26:09
>>935
それしかないかもしれないですね。
そのプロジェクト、svn:externalsでよそのレポジトリから大量にコードをインポートしてくる
みたいなのですが、暇を見つけてぼちぼち落とすとします。。

937 :デフォルトの名無しさん:2009/10/09(金) 05:28:17
ええええ〜
今の流れはbzrなん?
hg使い始めたばかりなのに・・・


938 :デフォルトの名無しさん:2009/10/09(金) 07:14:07
いや、bzrが微妙に伸びてるけどgitの方が主流だよ。
hgは知らね。

939 :デフォルトの名無しさん:2009/10/09(金) 07:18:34
hgはじめました

940 :デフォルトの名無しさん:2009/10/09(金) 09:06:36
svnが主流だよ。gitは3%くらいのシェアをとっててbzrは1%だけど、bzrが追い上げてきてる。

941 :デフォルトの名無しさん:2009/10/09(金) 13:03:48
仕事で日本語ファイル名を使うならSubversionが有利だと思う

942 :デフォルトの名無しさん:2009/10/09(金) 13:14:20
伸び的には git だと思うなぁ

と各自出典を出さずに話すのであった

943 :デフォルトの名無しさん:2009/10/09(金) 13:55:58
git 日本語ファイルダメなんでしょ?

と、いいつつ Mercurial 使っているのであった。


944 :デフォルトの名無しさん:2009/10/09(金) 14:15:29
rebaseが便利でhgからgitに移ったよ
bzrはどうなんだろ?

945 :デフォルトの名無しさん:2009/10/09(金) 14:19:01
bzr-rebaseはあるけど、基本的にbzr-svnでしか使わないなぁ。
普通にマージしたほうがいい。

946 :デフォルトの名無しさん:2009/10/09(金) 14:19:06
git は魅かれるんだけど
概念を覚えるのが面倒でなぁ
何かきっかけがないと


947 :デフォルトの名無しさん:2009/10/09(金) 14:20:33
会社がWindows中心で動いてるのでSubversionですん

948 :デフォルトの名無しさん:2009/10/09(金) 14:31:00
会社はWindowsだけど、ファイル名に日本語はないからgitですん

949 :デフォルトの名無しさん:2009/10/09(金) 14:32:40
うちではSubversionとは言わないな
TortoiseSVNと呼ばれている

950 :デフォルトの名無しさん:2009/10/09(金) 14:35:01
うちでは TortoiseSVN が Subversion とか SVN とか呼ばれてる。
わからんでもないんだが、見聞きするたびに気持ち悪い。

951 :デフォルトの名無しさん:2009/10/09(金) 14:56:47
うちではBzrと言えばbzrのことで、BazzarといえばTortoiseBzrのことだ。

952 :デフォルトの名無しさん:2009/10/09(金) 15:00:37
progit.pdfいいね。やっとgitがわかってきた。hgとの違いにびっくりだわ。ばざぁーはいいドキュメントある?

953 :デフォルトの名無しさん:2009/10/09(金) 15:01:47
うちはCVSをたまにCSVというよ

954 :デフォルトの名無しさん:2009/10/09(金) 15:51:15
>>917
速度が必要な部分までPython使ってるから文句言ってんだけど。

955 :デフォルトの名無しさん:2009/10/09(金) 15:53:37
具体的にどこ?

956 :デフォルトの名無しさん:2009/10/09(金) 17:14:05
>>953
単に間違ってるだけだろw

957 :デフォルトの名無しさん:2009/10/09(金) 20:54:43
なんかみんな流されてない?
CVSで十分っしょ。


958 :デフォルトの名無しさん:2009/10/09(金) 21:01:30
>>957
ありえねwwwwwww

959 :デフォルトの名無しさん:2009/10/09(金) 21:07:22
選択の基準は、フロントエンドの操作性だろやっぱり。


960 :デフォルトの名無しさん:2009/10/09(金) 23:14:59
とりあえず、日本語ファイル名を封印する分には、
DVCSはどれも日本語環境でも大丈夫なのかな

961 :デフォルトの名無しさん:2009/10/09(金) 23:16:48
お前ら技術者なら日本語言わないでマルチバイトって言ってくれ
ローマ字も日本語だ

962 :デフォルトの名無しさん:2009/10/09(金) 23:22:58
マルチバイトといっても日本語が通るとは限らないんじゃね

963 :デフォルトの名無しさん:2009/10/09(金) 23:54:30
>>961 ローマ字も日本語
ja_JP.asciiになるのかな?

964 :デフォルトの名無しさん:2009/10/10(土) 00:44:40
>>960
コミットログとかもあるでよ。

965 :デフォルトの名無しさん:2009/10/10(土) 00:49:04
言語と用字とエンコーディング


966 :デフォルトの名無しさん:2009/10/10(土) 00:50:29
>>964
コミットログが大丈夫なのはどれ?

967 :デフォルトの名無しさん:2009/10/10(土) 00:53:57
ファイル名・ログ両方ともbzr以外全滅じゃなかったっけ

968 :デフォルトの名無しさん:2009/10/10(土) 01:00:30
bzrとsvnが大丈夫。

969 :デフォルトの名無しさん:2009/10/10(土) 01:10:32
いや、DVCSだろ

970 :デフォルトの名無しさん:2009/10/10(土) 14:19:46
>>953
あるあるw

971 :デフォルトの名無しさん:2009/10/10(土) 15:19:59
クリアケースおわっとるわ。
インターフェース超最悪。
ほんとにバージョン管理できんのかこれ?
もうちょっと弄ってみるが。


972 :デフォルトの名無しさん:2009/10/10(土) 15:32:57
bzrとsvnは大丈夫、他はヤヴァイ

973 :デフォルトの名無しさん:2009/10/10(土) 15:34:01
うちは、CSV形式のことを延々とプロジェクト終了までCVS、CVSと言い放った上司がいてだな・・・
指摘しても直さないから、h

974 :デフォルトの名無しさん:2009/10/10(土) 16:02:58
最近clearcaseがクソだって話題が定期的に出るけど、使ってる人けっこう居るのかな?

俺は触ったことないけど、Wikipedia見たら
>欠点
>トランザクションがアトミックでない。
>コードベースが古く、新規機能追加が遅い。
>非常に複雑で、構成設定に注意を要する。
>遅い。単純なコミットやチェックアウトが数分かかることも稀ではない。
って書いてあって引いた。業務上使わざるを得ないんだろうけど、同情するわ。

975 :デフォルトの名無しさん:2009/10/10(土) 21:38:02
bzrはさくっとWindowsにインストールできるようになったの?

976 :デフォルトの名無しさん:2009/10/10(土) 22:06:19
これ系のツールの総称ってVCSなの?RCSなの?
どっちが通りがいいんだろう。

977 :デフォルトの名無しさん:2009/10/10(土) 22:16:58
>>976
RCSって名前のVCSはあるね。

978 :デフォルトの名無しさん:2009/10/10(土) 22:17:59
RCSって固有名詞じゃなくて総称名詞として使われることなんてあるのか?

979 :デフォルトの名無しさん:2009/10/10(土) 22:20:31
VCSか、あるいはSCM(Source Code Management) かな…
Software Configuration Managementだと違うレベルの話になる。

980 :デフォルトの名無しさん:2009/10/10(土) 22:20:39
どっちもgoogleのトップには出てこないという

981 :デフォルトの名無しさん:2009/10/10(土) 22:28:15
SVC

982 :デフォルトの名無しさん:2009/10/10(土) 23:16:25
バ管ス

983 :デフォルトの名無しさん:2009/10/11(日) 00:57:59
日本放送協会がNHKなんだから
バージョン管理システムはBKSだろ

984 :デフォルトの名無しさん:2009/10/11(日) 01:51:52
版管理系統 HKKだろ

985 :デフォルトの名無しさん:2009/10/11(日) 10:22:04
>>975
むしろwindows でインストールして使い始めるのはbzrが一番簡単だと思う

986 :デフォルトの名無しさん:2009/10/11(日) 10:39:22
>>975
Ubuntuインストールするのが一番手っ取り早いと思う

987 :デフォルトの名無しさん:2009/10/11(日) 10:46:39
>>985
え?svnが一番簡単じゃないの?

988 :デフォルトの名無しさん:2009/10/11(日) 10:49:14
使い始める場合だと、リポジトリを作らないといけないsvnよりbzrの方が簡単だろうな。
昔、svnで file:///C:/ のスラッシュがひとつ足りなくてハマッた覚えがある。

989 :デフォルトの名無しさん:2009/10/11(日) 10:58:47
tsvnはリポジトリは右クリックですぐ作れるけど

bzrはリポジトリが無くてもいいの?


990 :デフォルトの名無しさん:2009/10/11(日) 11:43:06
file:

991 :デフォルトの名無しさん:2009/10/11(日) 12:03:01
>>989
bzrでもhgやgitでも、純粋にバージョン管理したいだけならリポジトリ&ブランチ&作業ツリーを
一箇所にまとめられるから、一度で全部作れる。
svnはリポジトリを作成してからチェックアウトしないといけない。

992 :デフォルトの名無しさん:2009/10/11(日) 15:20:08
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/

993 :デフォルトの名無しさん:2009/10/11(日) 16:16:18
リポジトリが同じ場所にあるってことは、ディレクトリごと消してしまったら履歴ごと消えるというわけで……
不安じゃない?
皆さんどんな用途で使ってる?

994 :デフォルトの名無しさん:2009/10/11(日) 16:20:18
>>988
TortoiseSVNで普通のパス指定できるようなバージョンアップってしないのかね。
あれ面倒なんだよな。

>>993
ソースコード管理とは別に毎日robocopyやpdumpfsでバックアップすればいいんじゃね。

995 :デフォルトの名無しさん:2009/10/11(日) 16:24:13
全部dropboxに突っ込んどくとか?

996 :デフォルトの名無しさん:2009/10/11(日) 16:30:24
>>994-995
いや、バックアップもするなら最初から履歴付きのバックアップツール使えばいいと思うんだ。
push/pop先無しの単独リポジトリということは、他のPCと共有しないものを入れるということで
設定ファイルや個人的なドキュメントが主用途かなあ?と想像するのだけど
それならOSにはじめからあるバックアップと復元センターやTimeMachineの方が優秀な気がして。

997 :デフォルトの名無しさん:2009/10/11(日) 16:42:05
そらローカルに置くなら個人用だろ。
別にそれしかできないわけじゃないし。

バージョン管理とバックアップは別もんだし
併用しちゃいけないなんて縛りはどこにもない。
保険は多い方がいい。

998 :デフォルトの名無しさん:2009/10/11(日) 17:08:52
>>991
bzrはいつブランチをまとめれるようになったんだ?

999 :デフォルトの名無しさん:2009/10/11(日) 17:12:41
>>998
bzr-local-branchesプラグインが出来てから

1000 :デフォルトの名無しさん:2009/10/11(日) 17:15:58
( * )ここ

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

271 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)