バージョン管理システムについて語るスレat TECH
バージョン管理システムについて語るスレ - 暇つぶし2ch116:デフォルトの名無しさん
07/12/08 04:27:36
>>110
>Gitのサーバを建てる手間はどれくらいですかね?
サーバといってもいろいろなやり方があるんですが、、、
gitプロトコル以外にhttpとかsshとかWebDavとか。
全部やったわけじゃないけど、まあ難しくないです。
とりあえずFreeBSDならportsにGitありますよ。

>>113-114
>多くのユーザがその用途で使ってるわけだし、それ以外の用途の為の変更で
>カーネル開発がしにくくなるのは本末転倒なんだな。
俺は普通にGitで不便だと思うことは何にも無いけどなぁ。
Linuxカーネル開発用途以外のものが無いなんてこともないし(俺はカーネル開発
じゃなくてJavaに使ってる)
有名どころだと、xorg、compiz、samba、FedoraあたりがGitを採用してる。
あとGCCもGitが有力らしい。

117:デフォルトの名無しさん
07/12/08 04:36:38
>>115
タグを付けてあればそれになると思うけど、、、(release_x_xとか)
もっと詳細に特定するならSHA1ハッシュがコミットのユニークなIDになってるので、
それで指定できる。

118:デフォルトの名無しさん
07/12/08 14:38:41
>>117
何のハッシュ? コミットログのハッシュ?


119:デフォルトの名無しさん
07/12/08 15:35:53
実物みたほうが速いんじゃない。
URLリンク(gitweb.freedesktop.org)
みたいにコミットとツリーにそれぞれid(tree-ish、commit-ishの識別子)がつく。

120:デフォルトの名無しさん
07/12/08 15:41:53
ちょうどそのログはgit-cherry-pickな奴だった。
(cherry picked from commit 7caf51d1a5a86ae884e0087795636222c082962c)
はコミットid 7caf51d1a5から拾ってきたっつーことね…。

121:デフォルトの名無しさん
07/12/09 14:19:00
Learning Git
URLリンク(www.simplicidade.org)

122:デフォルトの名無しさん
07/12/09 14:59:23
gitは使いこなすとスゴそうだけど、インタフェースが複雑で最初は大変そう
URLリンク(www.jukie.net)

Subversoinですらやっとこさ導入してるリーマンドカタ的現場では、とても無理そうだな。
というか、おまえらんとこってどうなん?
お前らって、「あって当たり前のSCMを手配してくれる人」?
「面倒なことを言い出すウザイ奴」的立場?

導入やお守り、簡単な説明はいいけど、手順書一式用意しろ、には参った。

123:デフォルトの名無しさん
07/12/09 15:18:50
必要ならリポジトリにプロジェクト作るから言ってね、って言われる立場

まだ CVS だけど

124:デフォルトの名無しさん
07/12/09 15:50:17
学生サークルだが、subversionどころかバージョン管理そのものについてまったく知らないのがほとんど。
お前ら趣味でプログラムしてるのとちゃうのかと小一時間(ry

125:デフォルトの名無しさん
07/12/09 16:11:31
お前が導入して便利さを知らしめてやればおk

126:デフォルトの名無しさん
07/12/09 16:15:22
>>122
>gitは使いこなすとスゴそうだけど、インタフェースが複雑で最初は大変そう
確かに最初は覚えるのに苦労するかも知れないなぁ。
ただ俺が思うのは、CVSにしろSubversionにしろ、初めて使う時にはそれなりに
頭を悩ませただろうし、他人に使い方を覚えてもらうなんてのはさらに面倒だった
だろうということ(CVS->Subversionはとても似てるからすんなりかも知れないけど)
特に今現在インフラとして使ってるSCMがある人の場合、抵抗感は大きいと思う。
(viからemacsに乗り換えるようなもので。。。)
だから、Gitは一切SCMを使ったことの無い人のほうが覚えやすいかもしれない。
って、hgもそれは同じだと思うんだけどなぁ。そんなにGit複雑かなぁ。

127:デフォルトの名無しさん
07/12/09 16:49:53
>>125
導入しただけで済めば苦労はない。
コミットとか管理の概念もないし、理解したかと思っても、
日付毎のディレクトリを掘ってコミットする奴とか、zipに固めたのをコミットする奴とか…。

128:デフォルトの名無しさん
07/12/09 17:01:36
そもそも理解してないんだよな、VCSの便利さを。
どれだけ便利か本人たちが理解すれば、前向きに勉強してくれると思うんだが・・・。

129:デフォルトの名無しさん
07/12/09 17:12:01
Gitインストールした。

$ ls /usr/local/bin/git* | wc -l
145

これはないわ。


130:デフォルトの名無しさん
07/12/09 17:13:25
$ cd /usr/local/bin; ls git*

git git-gui git-relink
git-add git-hash-object git-remote
git-add--interactive git-http-fetch git-repack
git-am git-imap-send git-repo-config
git-annotate git-index-pack git-request-pull
git-apply git-init git-rerere
git-archimport git-init-db git-reset
git-archive git-instaweb git-rev-list
git-bisect git-local-fetch git-rev-parse
git-blame git-log git-revert
git-branch git-lost-found git-rm
git-bundle git-ls-files git-runstatus
git-cat-file git-ls-remote git-send-email
git-check-attr git-ls-tree git-send-pack
git-check-ref-format git-mailinfo git-sh-setup
git-checkout git-mailsplit git-shell
git-checkout-index git-merge git-shortlog
git-cherry git-merge-base git-show
git-cherry-pick git-merge-file git-show-branch
git-citool git-merge-index git-show-index
git-clean git-merge-octopus git-show-ref
git-clone git-merge-one-file git-ssh-fetch
git-commit git-merge-ours git-ssh-pull
git-commit-tree git-merge-recursive git-ssh-push
git-config git-merge-resolve git-ssh-upload


131:デフォルトの名無しさん
07/12/09 17:14:22
git-convert-objects git-merge-stupid git-stash
git-count-objects git-merge-subtree git-status
git-cvsexportcommit git-merge-tree git-stripspace
git-cvsimport git-mergetool git-submodule
git-cvsserver git-mktag git-svn
git-daemon git-mktree git-svnimport
git-describe git-mv git-symbolic-ref
git-diff git-name-rev git-tag
git-diff-files git-pack-objects git-tar-tree
git-diff-index git-pack-redundant git-unpack-file
git-diff-tree git-pack-refs git-unpack-objects
git-fast-import git-parse-remote git-update-index
git-fetch git-patch-id git-update-ref
git-fetch--tool git-peek-remote git-update-server-info
git-fetch-pack git-prune git-upload-archive
git-filter-branch git-prune-packed git-upload-pack
git-fmt-merge-msg git-pull git-var
git-for-each-ref git-push git-verify-pack
git-format-patch git-quiltimport git-verify-tag
git-fsck git-read-tree git-whatchanged
git-fsck-objects git-rebase git-write-tree
git-gc git-rebase--interactive gitk
git-get-tar-commit-id git-receive-pack
git-grep git-reflog


これはひどい

132:デフォルトの名無しさん
07/12/09 17:24:22
ふと思った。
-l してみたら実体は1個で、argv[0] で振り分けてたりしそうだと。

133:デフォルトの名無しさん
07/12/09 17:33:39
ディスクサイズを問題にしているわけじゃない。
gzipとgunzip程度ならそれでもいいけど、こんだけファイルを散らかしているのをなんとも思わないのかな。
たぶんcommand completionしたいがために、sub commandを使わないようにしたんだろうけど。

134:デフォルトの名無しさん
07/12/09 17:34:13
ちゃんと読もうぜ
We divide git into high level ("porcelain") commands and low level ("plumbing") commands.
URLリンク(www.kernel.org)

まあPorcelainでもその中で通常使うのはいくつかしかない
URLリンク(ktown.kde.org)

135:デフォルトの名無しさん
07/12/09 18:26:31
>>128

VCSとは?



136:デフォルトの名無しさん
07/12/09 18:34:10
>>135
Version Control System

137:デフォルトの名無しさん
07/12/09 18:36:12
SCM のほうが一般的だと思うけどな。


138:デフォルトの名無しさん
07/12/09 18:42:30
どのぐらい?

139:デフォルトの名無しさん
07/12/09 18:50:01
hg歴1週間の私が Git 使ってみましたよ。
gitk が面白いね。

で、branch を切り換える、って考え方がすげーしっくりきた。
これで Git に移行する気マンマンになりつつある。

一番気になるのは database の頑健性なんだけど、これはしばらく使ってみないと分からんな。
git-fsck というコマンドが存在する、ということが却って不安を煽るんだが…

>>126
> って、hgもそれは同じだと思うんだけどなぁ。そんなにGit複雑かなぁ。
俺も実際に使う前は、Git てコマンドたくさんあるらしいし、覚えるまでが大変そう、と思ってたけど、
実際に使ってみると基本的な作業は CVS とかと大差ないと思った。
むしろインターフェース的には CVS と Git の方が CVS と hg より近い (ほんのちょっとだけどね)
とすら思った。
ただ、git co とできないのが不満。ln -s git-checkout git-co とかすりゃいいのか? (w

ところで、git commit --help で No manual entry for git-commit とか言われるのは、インストールに
失敗してる?

140:デフォルトの名無しさん
07/12/09 19:17:15
>>139
>git-fsck というコマンドが存在する、ということが却って不安を煽るんだが…
どうだろうね、けっこう有名なプロジェクトでガンガン使われてるのが安心を
もたらすと思うんだけどねー。

俺の場合は仕事ではまだSubversionなので、個人的にGitで開発して
中央とのやり取りの時に git-svn で Subversionレポとやり取りしてます。
誰も気づかないよw
コラボしなくても、個人使用だけでずいぶん楽しいですよGit。

>ただ、git co とできないのが不満。
URLリンク(git.or.cz)
俺は~/.gitconfig をこんな感じにしてます
[alias]
st = status
co = checkout
br = branch

>ところで、git commit --help で No manual entry for git-commit とか言われるのは、インストールに
失敗してる?
してるかも。。。make install-doc かな?

141:デフォルトの名無しさん
07/12/09 20:03:56
今はSubversionを使ってて、
GitとMercurialをちょっとかじってみたいなと思ってるんだけど。
作業履歴も含めたバックアップはそれぞれどうやるの?

例えば、ある1つのプロジェクトを自分1人で扱うとして、
元リポジトリをいくつかに複製してそれぞれで個別の作業をして、
時折"リリース版"を作る場合:
1. リリース用リポジトリを1つ作って変更点を集める
2. そのリポジトリのバックアップを取る → 具体的には?
とかなのかな。イメージがいまいち掴めてないかも。


142:デフォルトの名無しさん
07/12/09 21:18:20
単にリリース用リポジトリ複製して保存しとけばいいと思うけど。

143:デフォルトの名無しさん
07/12/09 21:41:27
>>134
ごめん、なにがいいたいのかわからん。
high levelとlow levelに分類したところで、コマンドの数が多すぎる理由になるの?

144:デフォルトの名無しさん
07/12/09 21:48:44
cg cg-commit cg-reset
cg-add cg-diff cg-restore
cg-admin-cat cg-export cg-rm
cg-admin-ls cg-fetch cg-seek
cg-admin-lsobj cg-help cg-status
cg-admin-rewritehist cg-init cg-switch
cg-admin-setuprepo cg-log cg-tag
cg-admin-uncommit cg-merge cg-tag-ls
cg-branch-add cg-mkpatch cg-tag-show
cg-branch-chg cg-mv cg-update
cg-branch-ls cg-object-id cg-version
cg-clean cg-patch cg_annotate
cg-clone cg-push

あ一個変なの入ったけど、cgとかもあるよw stgitとかも。
git用のもあるbashcompは便利だがメインzshなんだよな。。。
zshcompはまだ使ってないんだがどうなんだろ。スレ違い…

145:デフォルトの名無しさん
07/12/09 22:40:15
>>143
コマンドの数が多すぎるのが問題なの?

146:デフォルトの名無しさん
07/12/10 00:13:05
gitってリポジトリの一部だけをcloneとかcheckoutすることって出来る?

147:141
07/12/10 00:31:52
>>142
普通のファイル群として保存すればいい(それ以外にない)ってことか。thx。
いや、svnのdump/loadみたいなものはあるんかなと思ってね。


148:デフォルトの名無しさん
07/12/10 10:31:56
>>146
分かってないだけかもしれないけど、それは無いような希ガス
Gitはファイルとかディレクトリではなくてコンテンツで考えるモノ、らしい

149:デフォルトの名無しさん
07/12/10 11:49:13
分散型でアクセス権をディレクトリ毎に制御できるものってない?

150:デフォルトの名無しさん
07/12/10 17:15:30
>>149
subversionではそういうのあったっけ。

151:デフォルトの名無しさん
07/12/10 17:29:23
svnserveとかWevDAV経由なら出来るんじゃなかったかな。
リポジトリの下のconfにそれっぽいのがあるでそ。


152:デフォルトの名無しさん
07/12/10 22:53:46
mercurialはrenameの前後でdiffとれない?

153:デフォルトの名無しさん
07/12/11 00:26:48
OpenJDK が Mercurial を使うことにしたそうだ。

154:デフォルトの名無しさん
07/12/11 00:56:26
svnはエンコード混在環境でもコミットログを内部utfで処理してくれますが、gitやhgのコミットログのエンコードは何が使われるのでしょうか?

乱暴ないい方するとWindows,ubuntu,旧soralisでs-jis,utf-8,eucなエディタでコミットしたときにログを相互に読めますかって話です (svnは相互にログは読めました、cvsはダメだった)

155:デフォルトの名無しさん
07/12/11 06:02:16
>>154
とりあえずGitはデフォでUTF-8だけど、設定ファイルに書いたらできたよ。

この手の質問って、hgとGitどっちにするか評価中ってことなのかな?
それならこんな細かいことじゃなくて、機能の核心が重要なんじゃないかと
思うんだが。まずは使ってみたほうがいいと思うよ。

156:デフォルトの名無しさん
07/12/11 08:56:02
154にとっては、それが核心機能のひとつなんじゃないかな。
異機種異環境混在環境でも動作するというのは案外大事。

157:デフォルトの名無しさん
07/12/11 10:28:37
>>156
まああれだ、どうもSubversionの機能をGitやMercurialに当てはめていくような
アプローチをしたがるみたいなんだが、そうじゃなくて頭真っ白にして考えないと
うまくいかないと思うんだおれは。
実際に使ってみれば、ログの文字コードを心配する前に、もっとドラスティックな
ことが起きるはず。

158:デフォルトの名無しさん
07/12/11 10:55:13
SVNの説明にも必ずCVSではこうだったみたいなのがあるじゃん
最初からHGやGit使うなら良いが既にSVNとかを利用している人からすれば
どうしても機能の当てはめ等は必要
自分は良くても他の人が移行に納得しない

159:デフォルトの名無しさん
07/12/11 11:11:07
おれsvnからgitに移行したけど、gitはsvnに当てはまらないことばっかだよ。。。

160:デフォルトの名無しさん
07/12/11 11:18:45
当てはまらない事だらけって事は利用者は使い方を学ばなければならないって事だ
中々覚えようって気にはなってくれないから難しい

161:デフォルトの名無しさん
07/12/11 11:24:06
Git - SVN Crash Course
URLリンク(git.or.cz)
最初はこれ見てやってみたんだけど、やっぱこれでgitが分かるってことはないわけで
Tutorialをやってみるのが近道だった。
中央集権型と分散型なんだから、簡単に移行できないのはしょうがないかもね。


162:デフォルトの名無しさん
07/12/11 13:16:41
gitかhgに移りたいけど、eclipseのプラグインがでるまで我慢。

163:デフォルトの名無しさん
07/12/11 13:20:22
俺はWindows Explore連携ができないと、移る気がしない

164:デフォルトの名無しさん
07/12/11 14:35:49
svkだって亀が使えたらって思うが

165:デフォルトの名無しさん
07/12/11 20:23:44
まぁ、人口に膾炙するためには、日本語リソースが充実しないとな

166:デフォルトの名無しさん
07/12/12 00:35:58
gitとかsvnとかhgとかみてたら、2chの略語に見えてきた。
もうさ、2chのVCS/SCMつくろうぜ。

kwsk -> 詳細ログ表示
ktkr -> 取り出し
wktk -> 更新があるかチェック
up -> コミット



167:デフォルトの名無しさん
07/12/12 02:15:31
gitとhgをcygwin上でTutorialをこなしたけど、
gitは branch と gitkが すごく よいと 思いました。
って 思いつつ、hg リファレンス を読んでたら、branch在るんですね。
Tutorial 見て、cloneでどんどんレポジトリ増やしていくしかないと思ってしまったorz

気づいた差異は、こんな感じ
速度
hg > git
hgは一瞬、gitは一秒程度かかるもの(checkout, commit)がある

commit
hgは、更新ファイルがデフォルトでコミットできる
gitは、更新ファイルもaddを使って追加するかcommit -a をする

マージのコンフリクト時の挙動
gitは衝突部位を両方持ったファイルを作成する
hgは衝突ごとに随時衝突部位を両方持ったファイルをエディタで開いて修正を求める。

あと hgは、狙ったのかホームポジションの隣で両人差し指一打ですむのが楽

168:デフォルトの名無しさん
07/12/12 02:17:42
>>167
hgといえばやっぱりアレだろ

169:デフォルトの名無しさん
07/12/12 02:31:11
>>168
どれだよ。

170:167
07/12/12 02:42:06
ああ
gitはcommitせずに複数マージできるが抜けてました。

>168
何でしょ?

171:デフォルトの名無しさん
07/12/12 12:18:08
$ hg foo

172:デフォルトの名無しさん
07/12/12 16:20:44
gitやhgが流行ってるみたいですが、いまいちsvnとの使い方の差が掴めません。
実際にsvn->git,hgへ移行して、使い方がどう変わったかだれか教えてもらえませんか?

173:デフォルトの名無しさん
07/12/12 17:14:51
cvsからsvnへ変わったのとは違う
どう変わったか?と言うより、概念そのものが違う

174:デフォルトの名無しさん
07/12/12 17:21:26
gitに移行しない奴をアホ呼ばわりする奴は何なの?

175:デフォルトの名無しさん
07/12/12 17:27:18
会社でアホ呼ばわりされたのか?
チラシの裏にでも書いておけ。


176:デフォルトの名無しさん
07/12/12 19:22:44
>>174
Git信者以外に考えられないのですが・・・・
本人は否定しているのですか?

>>172
大きな違いはローカルコミットができる点じゃないかな?
自分の作業が一段落するまで他の人に影響を与えず手元で変更履歴をとって管理できる。
それができないってのが、昔TeamwareからCVSに移行したとき不便だと思った所なんだけど。

177:デフォルトの名無しさん
07/12/12 19:29:05
>>176
なるほど、それは使い方が大きく変わりそうですね。

178:デフォルトの名無しさん
07/12/12 19:31:39
ローカルコミットか・・・
確かに便利そうだ

誰かgitとhgとsvn使っている人、違いをまとめてうpしてくんろ

179:デフォルトの名無しさん
07/12/12 19:58:46
svnもsvk使えばローカルにコミット出来るけどな

180:デフォルトの名無しさん
07/12/12 21:28:01
gitはどうかしらないけどhgはCVSとか.svnに相当する.hgディレクトリがルートにしか作られないのがすき。
それ + .hg自体がリポジトリなのでリポジトリの作成が気持ち的に軽い気がする。
なんかのファイルをいじるときにとりあえずhg initってのをよくやるようになった。

181:デフォルトの名無しさん
07/12/12 21:33:46
↑追記: バージョン管理というよりdiffを簡単に取るためだけど

182:デフォルトの名無しさん
07/12/12 22:44:52
>>180
gitも同じっすね


183:デフォルトの名無しさん
07/12/12 23:40:26
>>179
確かにsvkはローカルコミットできるね
俺はsvkからGitに変えたんだけど、外見はけっこう似てるかも知れない。
svkはどこどこのrevいくつまでマージした、っていう情報をもとにsmergeするけど、
Gitは各コミットにハッシュが振られているので、もっとぐちゃぐちゃにマージさせても
けっこう大丈夫。なので、何かしようと思うたびにローカルでブランチ作って、
ひと区切りついたら本線にマージしてそのブランチは廃棄、っていうのを繰り返す、
というのがフローとして使える。
svkも同じような使い方してたんだけど、svkはマージが遅くて辛かった。Gitは鬼速い。
あとsvkのswitchがGitのcheckoutにあたるようなイメージなんだが、svkでswitchしまくる
というのはちょっと気持ちよくないんだけど、Gitはそれが普通なので気持ちいい。
まーあとはGitならでは(hgにもありそう?)のresetとかrebaseとかの、やりたい放題が
気持ちいいかな。過去のコミットを遡って修正なんて、最初はかなり驚いた。

184:デフォルトの名無しさん
07/12/12 23:57:29
> Gitは各コミットにハッシュが振られているので、
> もっとぐちゃぐちゃにマージさせてもけっこう大丈夫。
svn使いの俺様から見るとコンフリクトしまくりそうなんだが...。


185:デフォルトの名無しさん
07/12/13 00:14:15
そういう複雑な運用がサポートされてても実際に使えるかどうかは難しいよね

186:デフォルトの名無しさん
07/12/13 00:20:53
>>162
hgにはある

187:デフォルトの名無しさん
07/12/13 00:22:33
>>184
行レベルでぶつかればコンフリクトしますな、さすがに。
でも追加した変更が誤解されてばっさり元に戻されたりとかはないし、
共同作業でもきちんと分担が為されてれば、同じファイルの同じ行がぶつかる
ということはそれほど無いはず。

>>185
慣れ、だと思いますよ。

188:デフォルトの名無しさん
07/12/13 01:06:09
>>103
そういう使い方をしたいなら
darcs、StGit、Mercurial+MQを使うべきだろ。

ここにいるGit使いは、darcsに移ったほうが幸せになれるかもしれない。

189:デフォルトの名無しさん
07/12/13 01:28:12
darcsって何がいいの?スケールしないって問題はおいといて。
バージョン管理じゃなくて、パッチ管理システムらしいけど、
それって何が違ってどう嬉しいんだ?

もっとわからんのは、darcs-git。
gitにdarcsのコマンドUIを載せたものと理解してるけど、darcsはUIがよいって事?
ってか、自慢のパッチ管理システムは実はどうでもいいのか?

190:デフォルトの名無しさん
07/12/13 02:17:54
quiltに似てるらしい。>darcs
quiltって何か知らんけど。

191:デフォルトの名無しさん
07/12/13 03:14:57
git って、「ぎっと」なの?「じっと」なの?

192:デフォルトの名無しさん
07/12/13 03:29:10
北森セレ2.6で、ロゴ野郎に買った!
…裏技だけど。

193:デフォルトの名無しさん
07/12/13 03:29:49
>>192誤爆スマソ

194:デフォルトの名無しさん
07/12/13 04:21:38
>>191
URLリンク(www.youtube.com)
linusは「ぎっと」と読んでいる



195:デフォルトの名無しさん
07/12/13 07:02:22
RapidSVN使ってるけどリポジトリのあるPCの電源を落としたまま
コミットしようとすると更新情報ぶっ壊れて全部とりなおすハメになるのは
他のツール使ってもいっしょですか?

196:デフォルトの名無しさん
07/12/13 07:57:00
>>195
ウサギはもう開発終わってるからなるべく使わない方がいいよ。
一々挙げないけど、それ以外にもいろいろ不具合あるし。

197:デフォルトの名無しさん
07/12/13 08:16:34
>>196
そうなんかぁ・・・
他のツールってなんかあんまりなじまなかったんだけど?w
GUIでスタンダードなツールって何?
なんかあんまりブラウザと合体するとか好きじゃない

198:デフォルトの名無しさん
07/12/13 08:24:42
>>197
俺も昔そう思ってた口で、ウサギオンリーで行こうとしたんだけど、
あまりの使いにくさに断念した。今は亀で妥協中。
どうしても亀が嫌なら、javaのクライアントがあったはずだから試してみたら?
たしかsvnスレの最近100レスぐらいに名前が挙がってたはず。

199:デフォルトの名無しさん
07/12/13 22:48:05
ウサギと亀w
Rapid と Tortoise にはなんか因縁でもあるんか

200:デフォルトの名無しさん
07/12/13 23:51:43
>>187
ありがとう。なぜか親近感がわいてきた。

会社のリポジトリは数年前にCVSからSubversionに移行させたんだが、
そのうちオレオレリポジトリみたいな使い方からgitを試してみるかも。


201:デフォルトの名無しさん
07/12/14 00:33:24
>>191

>ちなみに,'git'は英国俗語由来だそうです,そうであれば発音は'ギット'です
URLリンク(www.netfort.gr.jp)


だって。

202:デフォルトの名無しさん
07/12/14 01:02:16
俗語ってなんだろう。犬の糞とかかなw

203:デフォルトの名無しさん
07/12/14 01:16:17
>>202
ばかだなあ

204:デフォルトの名無しさん
07/12/14 01:16:58
これか?
URLリンク(en.wikipedia.org)
> Git is a relatively mild British slang term, used to denote a silly, incompetent, stupid, annoying, or childish person.

205:デフォルトの名無しさん
07/12/14 01:20:22
リーダーズ英和辞典
git[名] <俗> ろくでなし、ばか者、いやなやつ [get]
get[名] <俗> ばか、とんま


206:デフォルトの名無しさん
07/12/14 07:58:33
犬の糞という訳をしてもあながち間違いではないような

207:デフォルトの名無しさん
07/12/14 10:32:08
喪前等m-wを使おうぜ。発音も意味も両方判るんだから。
URLリンク(www.m-w.com)

どうでもいいが、ci-gitとすると墓碑銘になるからaliasを作るときは要注意だw

208:デフォルトの名無しさん
07/12/14 11:01:13
>>200
まずsvkを使ってみてはどうか
CVSからSVNへ移行したのと
SVNからGitは敷居が全然違うと思うよ

209:デフォルトの名無しさん
07/12/14 12:48:40
Rapid


は、ウサギじゃないと思う・・・・

210:デフォルトの名無しさん
07/12/14 12:59:42
>>200
gitはディレクトリがそのままリポジトリ&作業コピーになるから、
一人で始めるのはすぐにできますよ。
git-svnでgitからSubversionに直でコミットするのは、俺svnリポジトリで
練習してからのほうが良いと思います(意外にアッサリ実行して
しまうので)

>>208
それも良い手だと思います
俺も未だにSubversion同士のマージはsvk重宝してる

211:デフォルトの名無しさん
07/12/14 13:23:25
>>209
そのとおりなんだが、RapidSVNのロゴがウサギなんだ。
RapidSVNのサイト見てみ?

212:デフォルトの名無しさん
07/12/14 17:18:14
以前も言ったように、ユーザーパッチでの開発とかいう文化が存在しない
bsdやsolarisはことごとくmercurial。これは犬臭いのを避けたかったから。
犬臭いといっても、mercurialもgitもどっちもlinuxのバージョン管理システムだった
bitkeeperの代替のために作られた。ただもう一方の作者がカーネル作者だったため、
採用は当然そっちになっただけさ。開発スピードの差はリポジトリ見れば明らかだよ。

213:デフォルトの名無しさん
07/12/14 17:50:37
>>212
つまりどっちが活発に開発されてるの?

214:デフォルトの名無しさん
07/12/14 17:58:07
>>211
うぉ!しらなんだ・・・・いつの間に・・・・
昔は無かった・・・よね?

215:デフォルトの名無しさん
07/12/14 22:58:52
gitはsh依存がなけりゃな...

216:デフォルトの名無しさん
07/12/14 23:31:25
>>215
無知な質問で恐縮だが、shってシェルのこと?

217:デフォルトの名無しさん
07/12/15 07:26:30
shというかbashのつもりで書いたけどシェルでもいいよ

218:デフォルトの名無しさん
07/12/15 10:03:14
>>217
それじゃあzshなんかでは動かないのか?
というか、bashすらないwindowsではどうやって動かすの?cygwinオンリー?

219:デフォルトの名無しさん
07/12/15 11:01:54
SFU(だっけ?)でも入れるんじゃねーの?


220:デフォルトの名無しさん
07/12/15 15:43:14
Mercurial も Python 要るよね


221:デフォルトの名無しさん
07/12/15 16:30:16
gitのwindows版はcygwin or msys(の一部?)環境が必要
mercurialはpy2exeでランタイム同梱だからpythonのインストールは必要ない
どっちも一括パッケージになってるインストールの手間はとくになさそう
でもgitはもしかしてdosプロンプトから普通につかえなさげ?(shに入る必要あり?)

222:デフォルトの名無しさん
07/12/15 16:56:49
Mercurial死ぬほど重くて、管理システムとしてどうとかいう以前に日常的に使うツールとして使い物になんね。
管理対象のファイルが20個程度のところに glibc と gcc 展開してあったんだけど、
20個分のdiffとるのに数分も待たされたぞ。

それはそれとして、darcsでローカルにrecordしてある状態でpullしてもrebaseしてくれないのだが、
パッチの順番変えるのってどうやるの?

223:デフォルトの名無しさん
07/12/15 17:03:58
Mercurialは.hgignoreで

syntax: glob
*

しとかないとエライことになる場合があるな。


224:デフォルトの名無しさん
07/12/15 18:51:33
>>221
msysのやつインストールしてみたらmsysとMinGWとperlといろいろインストールされたよorz
msysのshの中からじゃないと使えないっぽい

225:デフォルトの名無しさん
07/12/15 18:53:03
>>222
svnとgitの数字もうp

226:デフォルトの名無しさん
07/12/15 19:36:04
>>222
darcsってけっこう使われてるのかな?
俺のまわりでは一人だけ居るけど、「使ってみたけど挫折気味」な感じだった。

227:デフォルトの名無しさん
07/12/15 20:10:46
>>222
> 管理対象のファイルが20個程度のところに glibc と gcc 展開してあったんだけど、
> 20個分のdiffとるのに数分も待たされたぞ。

管理対象外のディレクトリは直接展開せずシンボリックリンクを張るようにするとどうかな?

228:デフォルトの名無しさん
07/12/15 22:27:26
>>227
いや、明らかに管理対象のファイルだけスキャンすればいいのに、まるごとdiffとってから必要部分だけ抜き出す
というアホい実装になってるか、最初から死ぬほど遅いかのどっちかだから、もう評価するのやめた

229:デフォルトの名無しさん
07/12/15 22:28:24
>>225 svnは最初から評価対象外だから知らんが、gitもdarcsもせいぜい数秒だったぞ

230:デフォルトの名無しさん
07/12/15 22:30:40
>>226 Haskell 使いではほぼデフォじゃないかな?よくシランが
とこれで、やっぱりどうやってもパッチの順序かえたり rebase ができないのだが、識者タノム

231:デフォルトの名無しさん
07/12/15 22:41:19
だれかgit,hg用のeclipseプラグイン作ってくれねーかな。

232:デフォルトの名無しさん
07/12/16 01:36:31
>>228は、そんな辛口を言っておきながら、
「べ、べつにHgの為じゃないんだからね」とか言って
今晩にもそのアホい実装を修正するパッチを投稿してくれるに違いない。

233:デフォルトの名無しさん
07/12/16 14:02:28
俺も欲しい。
>>231 よろしく。

234:デフォルトの名無しさん
07/12/16 15:03:26
>>231
>>233

URLリンク(git.or.cz)
> Java GIT/Eclipse GIT (by Shawn Pearce) is a Java GIT library and
> plugin for Eclipse IDE

URLリンク(www.vectrace.com)
> Mercurial Eclipse is a plugin for the Eclipse platform to use
> Mercurial version system.





235:デフォルトの名無しさん
07/12/16 17:37:01
気になったから、やってみたんだけど。

新規repositoryにgcc 4.1.1と4.1.2を順にcommit して、
diffを出力したときのtimeの値

* git
real 0m13.339s
user 0m6.798s
sys 0m1.461s

* hg
real 0m27.871s
user 0m21.249s
sys 0m1.406s

参考になるかわからんけど。

pythonものは、 起動の時間(で通じる?)の遅さが気になる。

特にCUIの場合は、GUIのツールと違って、実行しっ放しで使わないから。


236:デフォルトの名無しさん
07/12/16 19:16:39
git スレ、たてました。
遊びにきてね。

git スレッド@ Linux 板
スレリンク(linux板)

237:デフォルトの名無しさん
07/12/16 19:22:33
>>235
userとrealが二倍以上違うな。

238:デフォルトの名無しさん
07/12/16 22:04:06
バージョン管理
いろいろ言われてるけどろくなソフトがないなw
まともなのはEclipseにくっついてるのとVSSぐらいだなマジで
これ以外むかつくから使わないほうがいいよ

バグったときの動作が最悪
通信途中で切れたときとかなにのにあるっていったり
更新中だからちょっとまってろって、お前、いつまでまたせるつもりかとw
いい加減、その操作あきらめてもとの状態に戻しておけよw
ってそんなこともできねぇし、ソースコードの履歴と修正には敏感だけど
自己のソフトのバグには鈍感とかありえねぇ動作してんじゃねぇよw
作った奴なにかんがえてんねんw

239:デフォルトの名無しさん
07/12/16 22:40:18
>>238
で、どこを縦読みしたらいいんだ?

240:デフォルトの名無しさん
07/12/16 22:44:23



ここかな?

241:デフォルトの名無しさん
07/12/16 22:58:45
>>235 なんでそんなに早いの?折れの環境が悪いのか?

242:デフォルトの名無しさん
07/12/17 10:31:48
>>238
読む気はしない、が

実際のところ、クラッシュ耐性が
どのくらいあるのか気にはなる。
fsやdbもこういう所が重要だし。

svnはfsfsを時間をかけてやってるけど、
他のは大丈夫なのかな。


243:デフォルトの名無しさん
07/12/17 15:10:04
mercurialで、ファイルを含んでいるディレクリがあって、ファイルはaddせずにディレクリだけaddすることはできますか。
subversionだと svn add -N dir1 でできるんですが、hg add だとそれっぼいオプションが見つかりませんでした。

244:235
07/12/17 16:52:20
>>237
git 、hg両方とも、real - user をしてみるとわかるけど、大体6~7秒差がある。
端末の描画速度かと。

一応、出力を/dev/nullに向けた値を張ります。
* git
real 0m6.806s
user 0m6.365s
sys 0m0.428s
* hg
real 0m21.640s
user 0m20.819s
sys 0m0.780s

>>241
速いって言われても、何とも言えないけど。
関係ありそうな環境。

CPU Pentium4 2.4c
memory 1G
file system ext3
terminal mlterm
kernel 2.6.22
GNU C Library stable release version 2.6.1
git version 1.5.3.6
GNU bash, version 3.2.17(1)-release
Mercurial Distributed SCM (version 0.9.3)
Python 2.4.4


245:デフォルトの名無しさん
07/12/17 17:49:16
>>244
実験乙。
>>235の結果と比べると、さらに差が広がってるな。
これは速度的にgitが圧倒的に有利ということでいいのだろうか?

しかし、>>112のMercurial側の主張によると、
> In terms of performance, Git is extremely fast. In several cases,
> it is faster than Mercurial, at least on Linux, while Mercurial performs better on other operations.
> However, on Windows, the performance and general level of support that Git provides is,
> at the time of writing, far behind that of Mercurial.
パフォーマンスの点では、Gitは非常に速いです。
ほかのOS上ではMercurialの方が速いものの、少なくともLinux上ではいくつかの場合Mercurialよりも早いです。
しかしながら、ウィンドウズ上では、Gitのパフォーマンスと提供するサポートの一般水準は(おそらく周辺のソフトウェアのことを指すex:TortoiseHgなど)、
書いている現時点で、Mercurialには遠く及びません。
(厨房レベルの訳スマソ)

・・・らしいので、windows側でも検証せにゃならんということだろうか。

246:デフォルトの名無しさん
07/12/17 18:06:20
> on other operations

247:デフォルトの名無しさん
07/12/17 18:07:07
/dev/nullにリダイレクトしてパフォーマンス測れよ・・・

248:デフォルトの名無しさん
07/12/17 18:08:39
えーと、適当なこと言うけど、windowsでcygwin使ってるならstat劇遅だからな

249:デフォルトの名無しさん
07/12/18 11:25:24
昔、cygwinが遅いからbcc使ってたなぁ・・・

250:デフォルトの名無しさん
07/12/18 12:08:49
>>228
diffするとstatusを呼ぶから遅い。

251:デフォルトの名無しさん
07/12/18 13:23:33
えーっと、つまり Git は Windowsに弱いらしい、ということ?

252:デフォルトの名無しさん
07/12/18 14:31:31
そもそも日本語をちゃんと使えない時点でダメダメ

253:デフォルトの名無しさん
07/12/18 14:37:27
使ってない俺が言うのもアレだが、Cygwin依存のツールは使いたくない。
異なるバージョンのcygwin1.dllがいたりすると、他のツールが使えなくなったりしてイライラする。


254:デフォルトの名無しさん
07/12/18 14:46:44
依存してないけど?

255:デフォルトの名無しさん
07/12/18 15:23:03
Mercurial を使ってるんだけど
hg view
で出てくる GUI (gitk) ではコミット時の説明文の日本語が文字化けする…

256:デフォルトの名無しさん
07/12/18 16:31:24
>>254
gitはcygwinで使うのが普通だと思ってたけど、今は違うのか?

257:デフォルトの名無しさん
07/12/18 17:24:41
>>256
msysgit

258:デフォルトの名無しさん
07/12/18 17:32:12
>>255
tcl-tkだからUTF-8にすればたぶん読めるはず

259:デフォルトの名無しさん
07/12/18 17:34:02
>>257
安定していないものは、仕事では使えません

260:デフォルトの名無しさん
07/12/18 17:46:07
>>259
cygwin の git って msysgit より安定してる?

261:デフォルトの名無しさん
07/12/18 18:27:29
なんでwin使ってんだw

262:デフォルトの名無しさん
07/12/18 18:34:13
サーバはともかく、クライアント側はWinで良いと思うが

263:デフォルトの名無しさん
07/12/18 22:11:28
Mercurialも、日本語ファイル名をどうやってうまく扱えばいいのかわからんです。
Linuxサーバ上で、cgi経由のレポジトリを置いて、
WindowsとMacOSX間で管理しようとしてるんだけど・・・・

264:デフォルトの名無しさん
07/12/19 04:41:22
>>263
URLリンク(www.selenic.com)

>However, there is a following error when I want to add file/directory which
>filename contains non-ascii character.

>abort: No such file or directory: c:\hg-repo\test??.txt

>Error also appears when I use ``hg status`` or ``hg log``.

>To reproduce this error, you can try to create a file named 'test中文.txt'
>and add this file to your branch to verify this problem.

これのことだよね。hg status および hg log でも起こる現象で
hg add file/dir でエラーが出ちゃう罠… add status log... であぼーん

265:デフォルトの名無しさん
07/12/19 09:22:42
使えねー

266:デフォルトの名無しさん
07/12/19 11:18:15
日本語ファイル名なんて使ってるやつはばかです

267:デフォルトの名無しさん
07/12/19 11:30:08
% git-status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: 白黒
#
no changes added to commit (use "git add" and/or "git commit -a")

% git-log -p -1
"\347\231\275\351\273\222"
commit 242e3908ecd84cf05f79aa416ad735ce2e6f541f
Author: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Date: Wed Dec 19 11:25:21 2007 +0900

test commit

diff --git "a/\347\231\275\351\273\222" "b/\347\231\275\351\273\222"
index e69de29..f4d9ed8 100644
--- "a/\347\231\275\351\273\222"
+++ "b/\347\231\275\351\273\222"
@@ -0,0 +1 @@
+あああgitって馬鹿だな。


とりあえずgitで日本語(UTF-8)で使ってみたが大丈夫だけど、
ログおよびgit-ls-filesはエスケープ処理される。他はファイル名表示はされるようだが。

>>266
どーい

268:デフォルトの名無しさん
07/12/19 11:30:11
ソースだけ管理してれば良いけどね
ドキュメントまで管理し始めるとそうはいかない

269:デフォルトの名無しさん
07/12/19 11:38:11
まあでもSJIS使うのは避けたほうが無難だろう

270:デフォルトの名無しさん
07/12/19 11:55:16
まあね・・なるべくなら管理したくないんだけどね

271:デフォルトの名無しさん
07/12/19 11:56:31
つまり、Windowsお断りってことですな

272:デフォルトの名無しさん
07/12/19 12:24:55
>>264 はファイル名の扱いがコードページ依存 (unicode apiを使ってない)って話じゃないの?
日本語版windowsなら日本語ファイル名でも問題ないし。

別環境でcheckoutしたときにファイル名を適切に扱えるかどうかはそれとは別の問題なわけで

273:デフォルトの名無しさん
07/12/19 20:16:44
Subversionではファイルパスを内部ではUnicode扱いしてるからうまくいく。
ファイル名をレポジトリの内部管理対象にするときに
ネイティブのパス名からUnicodeに変換してから管理するようにすればいいのに・・・と思う。

274:デフォルトの名無しさん
07/12/19 22:01:25
合成文字(濁点つきのかな文字とか)が入るとうまくいかないようだ。

Mac OS Xで、
svn add ガチョーン.txt (&commit)

他の環境(Linuxとか)で
svn up
U ガチョーン.txt
touch ガチョーン.txt (作れてしまう)
ls
ガチョーン.txt ガチョーン.txt (「ガ」が同じようで実は違う)
for f in *.txt; do echo -n "$f: "; echo -n $f | wc -c; done
ガチョーン.txt: 22
ガチョーン.txt: 19

svn add ガチョーン.txt (addできてしまう &commit)

Mac OS Xに戻って
svn up
svn: Failed to add file 'ガチョーン.txt': object of the same name already exists

Macのファイルシステム上は合成文字は分解した形に正規化されているが、
そうしない環境のほうが多いよな。


275:デフォルトの名無しさん
07/12/20 01:10:51
バージョン管理システムを嫌がるアホ
スレリンク(software板)

276:デフォルトの名無しさん
07/12/20 02:39:00
osxが特殊かと。

277:デフォルトの名無しさん
07/12/20 03:42:45
>>274
それは、実は大文字小文字混在問題と同じじゃないかなぁ。

278:デフォルトの名無しさん
07/12/22 10:00:27
GNU archってもう駄目なのかなあGNUウェアではよく使われてるみたいだけど

279:デフォルトの名無しさん
07/12/22 14:57:52
スレ違いかもしれないけれど…

あるフォルダに対して普段はサブフォルダ作成やファイル削除まで全ての操作を許すけど
いざとなったら任意の時刻のフォルダ状態に戻したいっていうのは
バージョン管理システムを使った運用で可能?
それとももっとスマートなやり方がある?

280:デフォルトの名無しさん
07/12/22 17:12:29
スレ違いだけど、
Plan9だとそういうのがネイティブで出来そうに見えるんだよね。


281:デフォルトの名無しさん
07/12/22 18:41:52
スレ違いっぽいけど
fuseとかで簡単に作れたりしないかな

282:デフォルトの名無しさん
07/12/22 18:47:52
スレ違いなのか…orz

283:デフォルトの名無しさん
07/12/22 19:01:52
>>279
スレ違いっぽいけど
URLリンク(fsvs.tigris.org)

284:デフォルトの名無しさん
07/12/22 19:45:50
スレ違いっぽいけど
>>283 thx

285:デフォルトの名無しさん
07/12/23 02:14:21
スレ違いっぽいけど、ZFSのスナップショットで戻したい時刻のデータを残しとけばいいような・・・
意識せずにした操作なら駄目だけど。

286:デフォルトの名無しさん
07/12/23 16:35:37
すれ違いっぽいけど、今日の昼飯なに食った?
俺ちりめんおにぎり1個…

287:デフォルトの名無しさん
07/12/23 17:07:20
>>279
日単位で巻き戻しならcron+pdumpfs。
任意のタイミングでスナップショットを取りたいならコード弄るしかないかな。

288:デフォルトの名無しさん
07/12/23 20:04:54
任意のタイミングは駄目なのか

289:デフォルトの名無しさん
07/12/24 03:49:41
kumaryu.net - (Prog) monotoneを使ってみる
URLリンク(www.kumaryu.net)(Prog)+monotone%A4%F2%BB%C8%A4%C3%A4%C6%A4%DF%A4%EB

*手軽
monotoneのリポジトリは単一ファイルです。
リポジトリはSQLiteのデータベースファイルで、ファイル1つに全部突っ込むことになります。バックアップとかのリポジトリの管理がとても楽です。
また分散型なのでサーバーとか気にせず簡単に試せます。気軽にコミットできます。

*マージが強力
3wayマージで良い感じにマージしてくれます。

*国際化対応
ファイル名、コメント等の国際化対応がされています。
データベースには軒並みUTF-8で入ることになります。

*移植性が高い
SQLite3、Lua、Boostだけあればビルドできます。
どれも移植性が高いです。多分。

これどうかな*国際化対応がされてるという一点に置いて
とても心惹かれるものがあるような…でも余り話題になってないような
もうちょっと調べてみる

290:デフォルトの名無しさん
07/12/24 07:40:03
SQLiteだとリポジトリがでっかくなったら苦しくならないんだろうか?


291:デフォルトの名無しさん
07/12/24 07:59:07
>>290
だから人気がないwww

292:デフォルトの名無しさん
07/12/24 09:54:25
> Lua、Boostだけあれば
はいアウト

293:デフォルトの名無しさん
07/12/24 11:18:23
>>288
pfumpfsの話なら、フォルダを
2007/12/24/
みたいに掘るから
一日に二度以上できないってだけで
2007/12/24_11_17_09
みたいに時間も含めてやれば好きなタイミングでスナップショットを取れるようになるよ。
当然1・2行ソースの修正が必要になるが。

294:デフォルトの名無しさん
07/12/29 03:26:43
コマンドラインメンドクサス・・・

TortoiseHg安定せんかな・・・
TortoiseSvkでもいいけど

Rakefile書きまくっても、
結局コンソール(Poderosa)立ち上げるのが面倒で、batファイルつくって、
ファイラーから、ポチクリやってしまう

ちゅーか、IDEにターミナルエミュレータついてくれればいいのに・・・

295:デフォルトの名無しさん
07/12/29 03:31:27
Mercurialは、
バイナリファイルと国際化が弱いようですね。
Subversionはその辺しっかり、してたからなー

296:デフォルトの名無しさん
07/12/29 04:03:15
あー、あと、空のディレクトリを消すのが解せない・・・

297:デフォルトの名無しさん
07/12/29 07:33:04
そういえば関係ないけどsvnはdiffの出力も翻訳されちゃうからいつも翻訳無効にしてる
パッチ投げるときに困るんだよね

298:デフォルトの名無しさん
08/01/03 09:32:04
分散型バージョン管理システムはどれが良い?

URLリンク(slashdot.jp)

299:デフォルトの名無しさん
08/01/09 15:29:42
Subversion > Mercurial の移行を考えて
Mercurial使ってるんですが、
Subversionだとhookを使ってできていたコミット通知が欲しいと思って調べています。
対応する操作は、push になるかと思うんですが
push をしたときに、何かをするってのはどうすればいいかアイデアありませんか?

300:デフォルトの名無しさん
08/01/09 18:29:37
マニュアルに書いてあるのだが……

301:デフォルトの名無しさん
08/01/09 19:45:02
どうも、最近安易に聞く癖が付いてしまっているようです。
ググレカスり直してみました。
[hooks] の incoming フックで何とかなりそうですね。
ちょっと検索キーワードがまずかったみたいです・・・・
今までマニュアルだと思って見てたのは、チュートリアルだったし。

302:デフォルトの名無しさん
08/01/09 21:29:30
mercurialについてググろうとしてついhgでググっちまった。

フォーーーーーーーーーー

303:デフォルトの名無しさん
08/01/12 08:18:37
MercurialにMBCS対応エクステンションがコミットされてたぞ

304:デフォルトの名無しさん
08/01/13 14:07:29
ファイルやディレクトリのアクセス権を版管理できる
バージョン管理システムは何かあります?
ぐぐってもみつからず。

305:デフォルトの名無しさん
08/01/13 17:29:47
>>304
そんな超複雑なもん作ってどうする気だw

リポジトリ別にしたらいいじゃない

306:デフォルトの名無しさん
08/01/13 18:41:06
>>305
仕事の政治上の都合が有って
checkout したworking copyの一部のディレクトリを他の
Linux上のログオンユーザに見れないようにしたい。
checkout したあといちいちchmodするのは面倒だし、
し忘れが出るので。reposわけてもこれは解決できんと思います。
subversionにcheckoutのhookがあったらそれでもよかったけど。
やはりないんですかね。


307:デフォルトの名無しさん
08/01/13 19:36:54
>>306
Linuxのumaskじゃあかんの?

308:デフォルトの名無しさん
08/01/13 20:28:52
>>304
ないんじゃない? ファイルシステム依存(= 環境依存)な類のものでしょ。
Linuxのアクセス制御と関係するのは、subversionにはsvn:executableしかないかも。

checkout+chmodするスクリプトを作ってお茶を濁すとか。


309:デフォルトの名無しさん
08/01/13 21:23:15
>>308に一票。

310:デフォルトの名無しさん
08/01/13 21:37:36
みんなサンクス。

>>307
まるっきりダメじゃないけど、working copy下の他のディレクトリは
関係者に見てもらうことも有るので、umaskで全部マスクするのも
ちょと困る感じです。

>>308, 309
やはり、やるにしてもそれぐらいしかないですね。
あきらめてそうしておきます。


311:デフォルトの名無しさん
08/01/14 04:33:39
>>310
umaskを変更したユーザアカウントを一つ作っておけばいいんでない?
手間としては>308と変わらなくなる気もするけれど。

312:デフォルトの名無しさん
08/01/14 12:13:47
Subversionでauthzとか。
ワーキングコピーを共有するなら無理だけど。

313:312
08/01/14 13:11:19
よく読んでなかった、ワーキングコピーは共有する前提か。


314:デフォルトの名無しさん
08/01/14 19:57:47
Linux板行った方がもっといい方法がみつかるかもしれない

315:デフォルトの名無しさん
08/01/15 09:33:41
ここのスレを大変参考にしつつmercurialの0.9.5を数日試してるんだけど、
過去のレスに補足すべきと思うようなものも見かけるのでかいて美馬s。

>>41,152
名前を変更したファイルのdiffについては、hg diffに--gitオプションをつければ
望み通りにならない? というか、

~/.hgrcに

[diff]
git = True

を加えておいた方がいろいろよさげだと思う。

>>243
そもそもディレクトリを管理しないんだそうだ。

URLリンク(www.selenic.com)

自分もsvn add -Nをよくやるので少し不安なんだけど、今考えてみるとディレクトリ
を管理したいことなんてまずないかも。svn add -Nをやる理由ってSubversionの
仕様によるものがほとんどだと思う。

316:デフォルトの名無しさん
08/01/15 22:42:36
>>315
空のlogディレクトリだけ作られて欲しいこともあるけど(logファイル書けないぜエラーが出る)
まあそういうのはインスコスクリプトなりで対応すべきなんだろうな

317:デフォルトの名無しさん
08/01/15 23:50:13
> svn add -Nをやる理由ってSubversionの
> 仕様によるものがほとんどだと思う。

それは自分を納得させるための言葉に見える…。
空のディレクトリを管理できるからといって
便利なことはあっても不便なことはない。
ディレクトリもバージョニングできるのが
Subversionの売りのひとつだと思ったけど。
思想の違い。

318:デフォルトの名無しさん
08/01/17 23:45:47
空のディレクトリに readme.txtを置くだけの簡単な仕事です

319:デフォルトの名無しさん
08/01/19 03:38:45
>>318 がcoolな解決法だと思う。
シンプルなツールにシンプルな運用。

320:デフォルトの名無しさん
08/01/23 01:16:31
mercurialで、手元のcloneにいくつかcommitしてあるとして、
そのうち一部はローカルの環境固有の修正なのでpushしたくない、
他はpushしたいというときはどうすればいいのでしょう?

hg push -r REV というのがそれかと思って試してみたのですが、
ローカルで
changeset: 1:cae50e295c29
changeset: 2:af0665dee890
という状態でhg push -r2としたら全部pushされてしまい、
hg push -r1としたら1だけがpushされました。
1のchangesetはpushせず2だけpushしたいのです。

2をexportしてコピー元に送ってimportしてもらい、
その後ローカルでpullとするのでしょうか。


321:デフォルトの名無しさん
08/01/23 10:14:40
1.pushしたいチェンジセットをexport
2.同じリポジトリを別途clone
3.新たにcloneしたほうで
3-a.exportしたチェンジセットをimport
3-b.おもむろにpush
4.もとのclone側でpull

これでいいのかな。なんか手間だが。


322:デフォルトの名無しさん
08/01/25 11:54:41
mercurialで不要になったnamed brancheを消したいんだけどどうすればいい?

323:デフォルトの名無しさん
08/01/26 00:57:21
>>85
> VCSならとりあえずsubversioin。一番普及してるし、IDEのプラグインなんかも多い。
> SCMならgitかmercrial。今流行ってるし、おそらく今後SCMのsubversion的ポジションに着くはずだから。
> どっちも無料なんで、自分で試して決めてくれ。

初歩的な質問ですみませんが、VCSとSCMの違いはなんですか?

VCS(Version Control System)      :バージョン管理システム
SCM(Software Configuration Management):ソフトウェア構成管理

違いが今ひとつ分かりません。

324:デフォルトの名無しさん
08/01/26 02:31:38
>>323
VCS→一人用
SCM→まともなバージョン管理システム

325:デフォルトの名無しさん
08/01/26 08:19:06
>>324の言ってることも間違いじゃないが、>>323の聞きたいことはもっと具体的なことだろ。

違いを一言で言うと、分散型と集中型の違いで、
具体的にどう違うかというと、リポジトリが一つか複数かということ。
VCSは一つのリポジトリにみんなでコミット、マージするけど、
SCMは一人一人がリポジトリを持って、適時リポジトリ間でマージする感じ。

どっちが便利かというと、>>324の言うとおり個人ならVCSで十分だと思う(プラグインもあるし)
グループで開発するとか、ノートPCでネットワークがつながらない場所でもバリバリ開発したいならSCMも有り。
(ただし、svkという手も十分ある)

326:デフォルトの名無しさん
08/01/26 09:36:44
SCM と VCS ってそんなに意味が明確に定義されている用語?
どちらも意味は同じで、
subversion や git や mercial を含むバージョン管理システムのことを表してない?

327:325
08/01/26 09:44:12
>>326
あー、確かに誤解してたかも知れない。
俺の中で、
集中型=VCS
分散型=SCM
だと思ってた。
wikiでもバージョン管理システムの項で分散型も紹介してるし、要は同じってことかも。

328:デフォルトの名無しさん
08/01/26 09:50:07
Software Configuration Managementは、
リリースサイクルやバグの管理まで含む概念であって、
版管理はその一機能とみなせる。


329:デフォルトの名無しさん
08/01/26 13:21:51
wikiってどのwikiだよ

330:デフォルトの名無しさん
08/01/26 13:23:03
pediaしらねーのかよpedia
まったくこいつはとんだゆとりだぜギャハー

331:デフォルトの名無しさん
08/01/26 14:19:01
>>330
つれますか?


332:デフォルトの名無しさん
08/01/26 14:50:31
pgr

333:デフォルトの名無しさん
08/01/26 14:51:25
ペギラ

334:デフォルトの名無しさん
08/01/26 17:34:36
ゴン

335:デフォルトの名無しさん
08/01/26 18:55:39
Wikipediaをwikiって略す奴は、wikiを知らないんだろうな。

336:デフォルトの名無しさん
08/01/26 20:27:17
>>328
なるほど。
VCSは版管理のみを提供して、SCMはそれに追加機能があるという訳ですね。
となると、ここで論じられてるCVS、Subversion、Mercurial、git、darcs、Bazaar、arch等々は
それぞれどちらに分類されるのでしょうか?
今までこれらのソフトをVCSの視点でしか見てこなかったので、
この中にSCMがあれば、その活かし方などを教えてもらいたいです。

337:デフォルトの名無しさん
08/01/27 00:59:48
>>328
何言ってるの?
ここで言ってるSCMはSource Code Managementのことだろwww
だれもここでSoftware Configuration Managementの話なんてしてない。

338:デフォルトの名無しさん
08/01/27 01:11:39
>>337
>>323


339:デフォルトの名無しさん
08/01/27 01:12:15
というか323の時点で間違ったわけか。


340:デフォルトの名無しさん
08/01/27 01:36:38
WikipediaではSubversionがSoftware configuration managementに分類されてるな。
なんでだろ
URLリンク(en.wikipedia.org)

341:デフォルトの名無しさん
08/01/27 02:00:33
不審に思ってPurposesの節を読んだが、やっぱSubversonが入るのは
おかしいかな、ま、Wikipediaは言葉の定義をするとこじゃないから……

……とか思いながら定義を調べたら
URLリンク(www.dwheeler.com)
URLリンク(cs.wwc.edu)
URLリンク(www.cmcrossroads.com)
混用されすぎててワロタ。自信満々の>>337-339が涙目になるくらい。


342:デフォルトの名無しさん
08/01/27 02:07:51
すまん>>337-339じゃなくて>>328だわな。
要は初期の定義ではCMってのがあって、その後SCMの概念が出てくる。

現在でこそ、定義を全部満たすのがSCMでVCSはその機能の1つっていう
人もいるが、初期のSCMの定義ではCVSはおろかMakeなんかもSCMに含めてて
もうなんなんだという感じ。

343:デフォルトの名無しさん
08/01/27 02:34:40
そういえば、こんな文章もあったな。
URLリンク(www.sodan.org)


344:デフォルトの名無しさん
08/01/27 03:01:18
そこで、PMS(パッチ管理システム)ですよ。
darcs2はスケーラビリティ改善されるんだろうか。

345:デフォルトの名無しさん
08/01/27 03:48:17
>>344
darcsは興味あるなぁ
パッチ管理って、もうやりたい放題できそうだな

346:デフォルトの名無しさん
08/01/27 04:08:51
>>341-343
SCM (Software Configuration Management)の用法は統一されてないようだね
VCSと同義であったり、VCSをさらに多機能化したものとして言及されたり、
文脈によってまちまちみたいだね
ということで、とりあえずこのスレではSCM (Source Code Managementも含めて)もVCSも
バージョン管理システムを指すということでOK?

347:デフォルトの名無しさん
08/01/27 05:42:13
NMS (Nandemo Management System)

348:デフォルトの名無しさん
08/01/27 09:38:36
PMSは月経前症候群?
SCMはサプライチェーンマネジメント?
NMSはネットワークマネジメントだな

349:デフォルトの名無しさん
08/01/28 22:55:37
なます…

350:デフォルトの名無しさん
08/01/29 01:07:11
GitかHgに移行したいんだが、どうにも勇気が出ない。
TortoiseHgってTortoiseSVNと共存できる?
それとsvnからgitかhgに移行して、どう使い方が変わったとかだれか教えてくりゃれ。

351:デフォルトの名無しさん
08/01/29 01:27:18
>>350
使い方が変わるわけないだろwww

352:デフォルトの名無しさん
08/01/29 09:31:21
Winの場合、Python3.0が出るまでHgは使いにくいと思う

353:デフォルトの名無しさん
08/01/29 09:35:00
>>352
何で?

354:デフォルトの名無しさん
08/01/29 09:39:21
HgってPythonせいだっけ

355:デフォルトの名無しさん
08/01/29 10:24:15
今のPython2.5は文字列型が2つある。
入出力の部分で文字コード変換すれば問題は無いんだが、
1バイト圏の連中はASCII前提で何もしないから困る。

Python2.5
 str型: 1バイト1文字
 unicode型: 多バイト1文字(UCS-2 or UCS-4)
Python3.0
 str型: 多バイト1文字(UCS-2 or UCS-4)

UTF-8なら今のものでも問題ないと思う。
でもWindowsはShiftJISだから日本語を使うと問題が出るときがある。

Python3.0になるとUnicodeで作ることを強制されるので
たぶん自然に改善されるはず。


356:デフォルトの名無しさん
08/01/29 10:27:08
>>355
期待ageだな
でも、枯れるまでにはもう少し時間が必要か

357:デフォルトの名無しさん
08/01/29 16:28:14
Pythonがマジで多カ国語対応されるまでは、
Mercurialはファイル名、ファイルパスはASCIIで使っておけということだな。

358:デフォルトの名無しさん
08/01/29 21:52:31
これではダメかな?
URLリンク(selenic.com)

ちょっと試した限りでは問題ない感じ。


359:デフォルトの名無しさん
08/01/29 23:47:57
ユニコードファイル名に対応しないと根本的な解決にはならないんじゃないかな

360:デフォルトの名無しさん
08/01/30 03:19:57
マジレスすると
Pythonは多各語滞欧しているし海栗コードファイル名にも対応している

361:デフォルトの名無しさん
08/01/30 03:33:15
しかしお前は日本語に対応してないんだな

362:デフォルトの名無しさん
08/01/30 07:22:06
pythonは対応してるけどhgは対応してない

363:デフォルトの名無しさん
08/01/30 11:23:21
>>358
バイナリインストールの環境だと使えない

364:デフォルトの名無しさん
08/01/30 13:12:03
Windowsだけど、Hgインストールすると、
Python入ってるのに、自前でPythonインストールされる気がする。

365:デフォルトの名無しさん
08/01/30 15:20:12
>>357
そっかー、Pythonの文字列の問題なのか。
悩ましい問題だ。

SVNはその点、楽だったのになあ

366:デフォルトの名無しさん
08/01/30 17:56:08
>>357
対応してるだろ
適当なことを言うな

367:デフォルトの名無しさん
08/01/30 19:47:39
>>366
俺としては、基本的な文字列操作をしたらUnicodeで扱うことになったら、という意味だった。
Javaレベルでネイティブロケールを隠蔽してロジックが書ければ、と。

# そりゃ、Unicodeで扱うことによる問題はでるけどさ。
# デフォルトがUnicodeになって欲しい、と。

368:デフォルトの名無しさん
08/02/01 07:29:29
u'hoge' でいいじゃん

369:デフォルトの名無しさん
08/02/02 10:35:54
git-svnよいねぇ。
svnで開発するのは無理自慰だし、svkなんか微妙だし(エラーハンドリングが微妙)、git使いやすいから楽だ。

370:デフォルトの名無しさん
08/02/02 21:32:56
>>364
だがそれがいい。
VBはDLLを要求しやがるから困る。

>>368
その記法はPython3000だとエラーなんだよな~
これに限らず、いまhgを完全にUnicode化しても、
新たに作業が発生しそうで躊躇する。


371:デフォルトの名無しさん
08/02/02 22:18:52
Mercurial vs git
ここ分かりやすいな 短いけど
URLリンク(www.atmarkit.co.jp)

372:デフォルトの名無しさん
08/02/02 22:26:51
>>371
2005っていつの記事だよ、と思ったらやっぱり三年前じゃねえか。
こんなの今と相当違ってるぞ?

373:デフォルトの名無しさん
08/02/02 22:30:17
>>372
メインはsvnだけど 気になる2人なので基本的な情報を集めようとしてるんだけど
やっぱりそうですか。
すんません

374:デフォルトの名無しさん
08/02/02 23:37:34
>>369
> git-svn
kwsk

手元でgitで、サーバー側のsvnにコミットする手法?

375:デフォルトの名無しさん
08/02/03 02:32:45
TortoiseHg 0.3 が出たな

376:デフォルトの名無しさん
08/02/03 09:23:46
>>374
まぁそういうこと。コミットもできるけど、まだしてない。(権限がなす)
BTSにパッチ上げる開発用にローカルでつかってる。
普段のそー言うのは、git-svn cloneのほうでブッコ抜き。
git-svnimportの方はログコンバーターなのでリポジトリをgitに移行するときだけですね。

377:デフォルトの名無しさん
08/02/03 10:33:35
ブランチをマージしようとしてsvn mergeがフリーズしたので、
代わりにgit-svn で git上でマージできてよかった。

だけど、svn:externals とかgit-svnは扱ってくれないのね。
svn:ignoreはgit-svnで一応扱えるけど、機能が微妙。


378:デフォルトの名無しさん
08/02/03 17:43:28
【10.1】 「日本語ファイル名を追加できない」
URLリンク(python.matrix.jp)

379:デフォルトの名無しさん
08/02/03 18:46:02
・既出
・ググればすぐ出る
・直リン

380:デフォルトの名無しさん
08/02/04 13:59:43
直リン?

381:デフォルトの名無しさん
08/02/07 15:08:37
燃料?
URLリンク(texagon.blogspot.com)


382:デフォルトの名無しさん
08/02/07 19:30:51
お前初めてかhgは?
力抜けよ

383:デフォルトの名無しさん
08/02/07 20:21:09
>>381
文章の先頭から大嘘じゃないかwww

384:デフォルトの名無しさん
08/02/07 22:18:11
>>383
ごめん,どこが?

385:デフォルトの名無しさん
08/02/08 19:10:44
subversion での svn update は、git では git pull でしょうか。
git clone したリポジトリがあって、これを更新したいんだけど、git pull だけでいいのでしょうか。
なんかうまくいってるのかどうか分からなくて。

386:デフォルトの名無しさん
08/02/08 20:44:36
>>385
それで合ってる
git branch -r でorigin(pullしてくる元)が表示されるはず

git スレッド
スレリンク(linux板)

387:デフォルトの名無しさん
08/02/12 15:47:32
>>303
使い方がよくわからないんですが、Mercurialを新しくするだけではだめなんでしょうか?

$ hg add
adding クソ.txt
ク・.txt does not exist!

みたいになってしまいます。

388:デフォルトの名無しさん
08/02/12 18:55:56
sjisファイルネームは通らない。

389:デフォルトの名無しさん
08/02/12 23:14:55
SVN(TortoiseSVN)だとその辺もやってくれるんだけど、Hgはやってくれないか

390:387
08/02/13 13:33:47
>>387
extentionを有効にしてなかったせいでした。
Mercurial.iniの[extensions]に

hgext.win32mbcs =

を足したらちゃんとaddできるようになりました。

391:デフォルトの名無しさん
08/02/14 00:06:24
はじめてMercurialを使ってメッセージの意味がわからない…

Rev.1から 2 と 3 を分岐させて(>hg heads で 2と3が出る)、作業ディレクトリが
Rev.3の状態で 2の枝とマージすることを意図して
>C:\Temp\repo>hg merge 2
ってすると(設定しているWinMergeが立ち上がって編集保存すると)
>merging a.txt
>merging a.txt failed!
>1 files updated, 0 files merged, 0 files removed, 1 files unresolved
>There are unresolved merges, you can redo the full merge using:
> hg update -C 3
> hg merge 2

fail とか unresolved とか不吉な単語が見えるけれど、
>hg commit -m "..."
すると、ちゃんと Parentsに 2と3を持つ Rev.4 が出来ている。
編集した a.txt はちゃんと編集後の状態を保ってる。

これって正しい動作なんでしょうか。

392:デフォルトの名無しさん
08/02/16 17:58:43
rms曰く、we should use Bzr
URLリンク(lists.gnu.org)

393:デフォルトの名無しさん
08/02/17 11:10:01
mercurial で、heads と tips の違いがわかりません。だれかおしえて。

394:デフォルトの名無しさん
08/02/17 11:17:55
>>393
URLリンク(www.selenic.com)

395:デフォルトの名無しさん
08/02/17 12:47:28
>>394
ありがとう。とりあえず、tip は heads のうちのひとつ、ということまではわかった。
でも、なんで head が複数できるのかわからない。head は子を持たない changeset ということだが、普通に作業してたら head はひとつしかないように思うんだが。

396:デフォルトの名無しさん
08/02/17 13:30:19
>>395
複数人が編集したらheadが増える

397:デフォルトの名無しさん
08/02/17 19:03:49
>>396
ひとつのリポジトリを複数人で編集・・・するわけはないか。
>>394のページを見ると、他のリポジトリからhg pull したらheadが増えるみたいなんだが、そういう理解であってますか?

398:デフォルトの名無しさん
08/02/17 19:23:02
つまり
>>396
>複数人が編集したらheadが増える
というのは、他人のリポジトリから hg pull したら head が増えるということを意味してますか、という質問です。


399:デフォルトの名無しさん
08/02/17 20:52:17
>>398
一つの changeset に対して複数の commit をすれば head は増える。

$ hg init .
$ echo "line 1" >> test.txt
$ hg add test.txt
$ hg commit -m "init"
$ echo "line 2" >> test.txt
$ hg commit -m "head 1"
$ hg update 0
$ echo "line 3" >> test.txt
$ hg commit -m "head 2"
$ hg heads
$ hg tip

他人のリポジトリには自分のとは違う変更が commit されているだろうから、
それを pull してくれば head は増える。

400:デフォルトの名無しさん
08/02/20 00:51:46
TortoiseHGをインストールすると、Sambaの共有フォルダ一覧が
表示されるのがかなり遅くなってしまいました。
Wiresharkでキャプチャしてみると、\\Samba\.hgなるものを
何度もチェックしているからのようでした。
アンインストールすると元通りの速度になったのですが、この現象を
回避する方法はないのでしょうか?

401:デフォルトの名無しさん
08/02/20 09:36:27
TortoiseSVNには、アイコンオーバーレイのネットワークドライブなどでの除外指定ができるけど、
HGはできないの?

402:デフォルトの名無しさん
08/02/20 11:03:38
/var/logも.hgで埋まるから困る

403:デフォルトの名無しさん
08/02/23 06:58:06
バージョン管理システム管理下のファイルだけを対象にできる「auto-save-buffers-enhanced.el」
URLリンク(d.hatena.ne.jp)

404:デフォルトの名無しさん
08/02/23 07:30:24
>HGはできないの?

出来る、ドキュメント嫁。

405:デフォルトの名無しさん
08/02/23 11:26:19
>>403
バージョン管理下以外のファイルには自動保存したくないっていう
状況がよく分からないんだけど、なんでだろうね。

auto-save-buffers に慣れきったから自動保存されないことが
怖くてしょうがない。

406:デフォルトの名無しさん
08/02/23 12:06:16
>>405
間違って更新されたら元に戻せなくなる可能性があるからじゃない?

407:デフォルトの名無しさん
08/02/24 06:40:24
xyzzy使いだけど、おれは自動でバックアップファイルを作るのを使っているな。
ただし、セーブしたらバックアップファイルが消えるっていうやつ。
もし落ちても問題なし

408:デフォルトの名無しさん
08/03/01 13:08:03
GitTorrent Protocol -- GTP/0.1
URLリンク(gittorrent.utsl.gen.nz)

409:デフォルトの名無しさん
08/03/06 21:08:19
URLリンク(gihyo.jp)
git の特集だそうです。

410:デフォルトの名無しさん
08/03/06 23:06:08
なんか最近Gitが盛り上がってるなあ。

411:デフォルトの名無しさん
08/03/07 01:07:26
俺的にはTortoiseGitが無いのが糞だな
ところでTortoiseVSSって無いのかな?


412:デフォルトの名無しさん
08/03/07 02:23:30
最近はBazaarがgitとmercurialのいいとこ取りをしてますよーと、結構ドキュメント書いてるなぁ。
ちなみにgitのメインメンテナって日本人っぽいよね?(ハマノさん?)
俺的にはqgitがもうちょい使いやすくなれば嬉しいんだが、最近あんまアクティブでないよな…。

413:デフォルトの名無しさん
08/03/07 14:14:41
>>411
ないだろうし、これからも作られんだろ。
基本的に有償のソフトウェアには有償のサードパーティ・ソフトウェアしかでない。

414:デフォルトの名無しさん
08/03/07 14:44:55
>>413
> 基本的に有償のソフトウェアには有償のサードパーティ・ソフトウェアしかでない。

その理論(理解)はおかしい。

415:デフォルトの名無しさん
08/03/07 16:21:09
Tortoiseほにゃららはどうでもいいんだが
Cygwin環境でのgitの挙動があれで自分はmercurial

いちいち .git/hooks を弄らなきゃいけないのは苦痛だ

416:デフォルトの名無しさん
08/03/09 21:02:44
>>412
よければその記事どこにあるか教えてくれ。

417:デフォルトの名無しさん
08/03/09 21:07:12
しかしまあ、CVS->Subversionと来て次のスタンダードはどこになるんだろうな?
GitとMercurialに決定的な差異がない以上、ハッキリと明暗分かれることは当分ないんだろうが・・・。
ブルーレイvsHD DVDみたくどっちかが撤退という訳にも行かんし、
環境ごとにGit使ったりMercurial使ったりするのは勘弁してほしいなあ。

418:デフォルトの名無しさん
08/03/09 21:55:29
svn, git, hg のリポジトリを透過的に扱える、クライアント専用の第三のツールが出て一人勝ちに一票

419:デフォルトの名無しさん
08/03/09 22:13:33
>>418
スゲー欲しい。
ここは言い出しっぺの法則で作ってくだされ!
しかもWindows用にヨロw

420:デフォルトの名無しさん
08/03/09 22:26:23
たぶんEmacsにならすでに有りそうな気がする。


421:デフォルトの名無しさん
08/03/09 23:32:06
Emacs だと vc とか DVC とかかねぇ。


422:番組の途中ですが名無しです
08/03/10 15:30:23
>>418
サーバとクライアントって、分散SCMを否定してるなw
あるいは、IETFあたりで、分散SCMプロトコルのRFCとか決めて、なんでも繋がるようにしたら面白いかも。


ところで、Darcs2はどうなってる?

423:デフォルトの名無しさん
08/03/10 15:31:49
別に否定ではないだろ
親と子の関係はあるんだから

424:デフォルトの名無しさん
08/03/10 19:48:50
>>422
>IETFあたりで、分散SCMプロトコルのRFCとか決めて
「インターネット」が関係ないがな!w

425:デフォルトの名無しさん
08/03/12 12:16:18
TortoiseSVNだけを各々のPCにインストールして
TortoiseSVNでリポジトリを共有サーバに作る
そのリポジトリと各々のTortoiseSVNで使うって使い方は問題ない?

本来ならサーバにSubversionをインストールしてうんぬんかんぬんって
やらないとダメだと思うんだけど
ちょっと今の環境だと難しいんで上記の方法でやろうかなぁと

426:デフォルトの名無しさん
08/03/12 12:23:16
Windowsの場合、Subversionは管理ツールだと思え
必須って訳じゃない
その代わり、file:///でやることになるし、ユーザ名が
Windowsのユーザ名になるし、いくつか制限が出てくる
単純なソース管理しかしないならそれでも十分

427:デフォルトの名無しさん
08/03/12 12:28:58
>>426
おお素早い回答ありがとうございます。

単純なソース管理しかしないのでTortoiseSVNだけでOKってことですね
一先ず運用してみます。

428:デフォルトの名無しさん
08/03/13 00:46:12
Windowsで、一人ないしは少人数で扱うバージョン管理システムなら
Subversion(TortoiseSVN)が現状、最良且つ唯一の選択肢だろうな。
それ以上のことをやろうとするから、いろいろ悩むわけだ。

429:デフォルトの名無しさん
08/03/13 01:40:30
1人ならHgの方が手軽じゃない?
っつっても、Tortoiseがまだまだだからなぁ。

430:デフォルトの名無しさん
08/03/13 06:44:59
すまんですが、普通のバージョン管理システムで一万個ぐらいのファイルを最初にリポジトリに登録しようと思ったら、どのぐらい時間かかるもの?
VSSだと3時間かかっても終わらん・・・orz

431:デフォルトの名無しさん
08/03/14 11:43:24
PCのスペック、各ファイルの容量によって全然変わるし一慨にこうだとは言えない気がするが
うちが管理してたやつは30分もかからずに終わった
(Subversion管理)

432:デフォルトの名無しさん
08/03/15 03:08:26
上の方でgit-svnが話題になってたが、同じように既存のCVSリポジトリとやりとりできるやつある?
git-cvsexportcommit ってのでいいんだろうか。しかし日本語の情報とかさっぱりないな。
別にgitじゃなくてもいいんだが。

433:デフォルトの名無しさん
08/03/15 13:34:58
mercurial
URLリンク(www.selenic.com)
そろそろ来るのかな?

434:デフォルトの名無しさん
08/03/15 15:42:56
URLリンク(www.atmarkit.co.jp)
これは駄目だろ

435:デフォルトの名無しさん
08/03/15 19:58:48
TortoiseHg 0.3 を入れてみた。
日本語ファイルの追加や削除もマウス操作でうまくいったよ!

実験に使ったファイル名: ソース表示.txt

やったことは、インストールした場所にある Mercrial.ini の
[extensions]
hgext.win32mbcs = !
の感嘆符(!)を削除しただけ。

ファイル選択やコミットの画面で日本語ファイル名が化けるけど、そのまま動くよ。
コメントは入力・表示ともに日本語でOKだった。

436:435
08/03/15 20:33:36
↑すまん、環境は WinXP SP2。書き忘れた。

437:デフォルトの名無しさん
08/03/16 01:55:28
そりゃ動くだろうけど、ほとんどの機能が結局ダイアログが出てきてコマンド入力だったような。

438:デフォルトの名無しさん
08/03/16 03:50:20
>>434
1.5.4rc1で起こってたんだな。知らなかった。
教えてくれてありがとう。アンチも役に立つんだな。

439:435
08/03/17 10:50:04
>>437
・現在の Mercuriel の hg はファイル名とコメントに日本語が入っているとエラー停止する
・TortoiseHG 3.0 に付属の hg なら日本語ファイル名が扱える(mbcs エクステンションが入っている)
という事前情報があり、hg(コマンドライン)目当てで TortoiseHG を入れたところ、予期せず GUI でも日本語ファイル名の追加・コミットができたので、報告の意味で書き込んでみました。

440:デフォルトの名無しさん
08/03/18 14:44:55
ああ、そういえばSDのgit特集、今日発売か

441:デフォルトの名無しさん
08/03/18 17:38:51
SD読んだよ。クオリティ高かった。
かなり硬派な内容で、バリバリ使ってる人でも面白く読めると思う。

442:デフォルトの名無しさん
08/03/24 13:24:47
ネットの情報で十分でした

443:デフォルトの名無しさん
08/03/24 15:27:58
gitもhgもやりたいやりたいとは思うんだが、TortoiseSVNになれた身では移行しづらい。
やっぱフロントエンドが充実するにはもうすこし時間が必要かなあ。

444:デフォルトの名無しさん
08/03/24 15:40:01
必要ならお前が作れよ

445:デフォルトの名無しさん
08/03/24 17:40:42
gitはファイル名とログの日本語対応に不安がありすぎるんだが。

446:デフォルトの名無しさん
08/03/24 21:20:53
>>445
問題ない。

447:デフォルトの名無しさん
08/03/24 22:13:59
SD読んだよ

448:デフォルトの名無しさん
08/03/24 23:25:49
>>445
俺もふつうに日本語使えてるけど

449:デフォルトの名無しさん
08/03/24 23:44:07
SVNすら着いて来てくれないのにgitとか無理だお・・・

450:デフォルトの名無しさん
08/03/24 23:54:56
>>449
いつかgit使える日が来るさ。

451:デフォルトの名無しさん
08/03/25 15:32:06
mercurial-1.0.tar.gz 24-Mar-2008

452:デフォルトの名無しさん
08/03/25 19:54:31
コミットログを英語で書く人のためによさげな記事みつけてきた

Changelogのための英文テンプレート集 - ぴょぴょぴょ? - Linuxとかプログラミングの覚え書き -
URLリンク(d.hatena.ne.jp)

453:デフォルトの名無しさん
08/03/25 21:52:39
>>451
釣りかと思ったらマジだったのでage

454:デフォルトの名無しさん
08/03/25 22:47:52
今日のパッケージアップデートで知ったけど、x264がgitに移った模様。

455:デフォルトの名無しさん
08/03/26 03:06:05
>>454
ん~、なんだか大規模プロジェクトはMercurialよりGitに移る傾向があるみたいだね。
Mercurial使ってる有名なオープンソースとかあったっけ?

456:デフォルトの名無しさん
08/03/26 04:42:34
mozillaとかsun回りとかいろいろ。

457:デフォルトの名無しさん
08/03/26 08:50:37
TortoiseGit 作って (はーと)

458:デフォルトの名無しさん
08/03/26 13:44:38
TortoiseSVNの右クリックで表示されるメニューなんだけど
---
SVN更新
SVNコミット
TortoiseSVN
---
の3つなんだけど、ココに「変更のチェック」を加えて
---
変更のチェック
SVN更新
SVNコミット
TortoiseSVN
---
にしたいんだけど方法ないですかね?

459:デフォルトの名無しさん
08/03/26 14:00:53
TortoiseSVN > Settings で Look and Feel

460:デフォルトの名無しさん
08/03/26 14:10:20
>>459
それだとTortoiseSVNの下のメニューを変えるだけです><;
トップのメニューを変える方法は無いのかな

461:デフォルトの名無しさん
08/03/26 14:13:42
>>460
俺は459じゃないけど、説明良く見てないだろ
チェックを外せばトップメニューに表示されるんだよ

462:デフォルトの名無しさん
08/03/26 14:26:59
>>457
みんなTortoiseに依存しまくってるんだな....
SDによるとWindowsの場合CygwinでGit使えるみたいだけど、
GUIじゃないと嫌なの?

463:デフォルトの名無しさん
08/03/26 14:30:39
>>460-461
本当だ!ごめんなさい、ありがとうございます。

464:デフォルトの名無しさん
08/03/26 14:32:52
自分しか使わないならそれで良いんじゃないの
普通の人が触りやすい形態を考えれば分かる事だろ

465:デフォルトの名無しさん
08/03/26 15:17:31
>>462
ここに書き込みするような人たちほど リテラシーがないんですよ。
使い勝手によいGUIがあれば、バージョン管理システムの導入も
してもらいやすい。
「コマンドベースでやってね」 なんて言ったら、誰にも使ってもらえないだろう。

直感的に変更点判るし、ツールとして良くできているしね

466:デフォルトの名無しさん
08/03/26 15:30:20
差分見るのはGUIじゃなきゃやだ

467:デフォルトの名無しさん
08/03/26 15:34:35
ファイラーはどう考えてもGUIのほうが便利だしなあ

468:デフォルトの名無しさん
08/03/26 15:56:43
gitの場合、中身がシェルスクリプトだからTortoiseはちょっと難しそうだな、
と素人目に思った。

469:デフォルトの名無しさん
08/03/26 15:58:22
>>467
そうか?

470:デフォルトの名無しさん
08/03/26 16:03:33
>>464-465
Gitは開発者全員Gitにしないとダメなんてことないよ。
中央をsvnリポジトリにして自分だけGitでも問題なし。俺はそうしてる。
HGは使ったことないから分からないけど、Gitから分かれたモノだから
同じような感じではないかな?

>>466
CUIでもキレイに差分見れるけどね、、、

471:デフォルトの名無しさん
08/03/26 16:56:54
>>455


472:デフォルトの名無しさん
08/03/26 17:04:01
>>457
Git Cheetah

473:デフォルトの名無しさん
08/03/26 17:21:18
Mercurial で リポジトリの一部を消すとか、リポジトリを分割するとかってできますか?
やりたいことは Subversion でいえば
svnadmin dump | svndumpfilter | svnadmin load
のようなことなのですが…。

474:デフォルトの名無しさん
08/03/26 17:39:14
Bazaarバージョンが上がってすごい事になってるみたい
URLリンク(bazaar-vcs.org)

Bazaar vs Git URLリンク(bazaar-vcs.org)
Bazaar vs Mercurial URLリンク(bazaar-vcs.org)
Benchmarks  URLリンク(bazaar-vcs.org)

昔と比べて恐ろしいくらい速くなってる。

475:デフォルトの名無しさん
08/03/26 18:56:03
へー、bzr速くなったのか。まー、あまり速さは求めてない。
設定ファイルと自作スクリプトの管理にしか使ってないけど。

不思議なのは、bzrってbazaarの後継?らしいんだけど、
使い勝手が全然違ってどこが後継なのか良く分からない。

hgよりも便利機能が多い(UTF-8ファイル名でおk)けど
なぜか、hgの方が情報が多い。

あたりが疑問点かな。

476:デフォルトの名無しさん
08/03/26 19:00:00
>>475
昔Mercurialにうんこと言われるぐらい遅かったからだろ。

477:デフォルトの名無しさん
08/03/26 19:13:55
BazaarNGが本家乗っ取ったんだっけ?

478:デフォルトの名無しさん
08/03/26 19:45:03
>>477
急に速くなってたから驚いたけど
そういう理由があったのか

479:デフォルトの名無しさん
08/03/26 19:53:44
適当なことを言う前に URLリンク(bazaar-vcs.org) でも読んどけ。

480:デフォルトの名無しさん
08/03/26 19:56:27
Bazaar。。。。名前がいまいちなのがなぁ・・・・

481:デフォルトの名無しさん
08/03/26 20:30:04
Bizarreよりは普通だと思う

482:デフォルトの名無しさん
08/03/27 01:17:45
>>480
ゴザールを作るんだ


483:デフォルトの名無しさん
08/03/31 01:30:18
”ファイルのディレクトリ構造”ごと登録して、
その後、バージョン管理システム外で変更された、
”ファイルのディレクトリ構造(多少のファイルの増減あり)”を
チェックアウトなしで、そのままチェックインできるツールって、ありますか?

開発拠点が国内と、海外に数ヶ所と、
バージョン管理システムの導入を徹底できないので、困っております。

484:デフォルトの名無しさん
08/03/31 01:58:11
Subversion

485:デフォルトの名無しさん
08/03/31 08:13:17
svn_load_dir とかいうスクリプトがあったな。
他のツールにそういうのは無いのかな?

486:デフォルトの名無しさん
08/03/31 23:15:55
>>483
質問の内容に合っているかわかりませんが、Mercurialでリポジトリのあるところにファイルを展開して
hg addremove
hg commit
をすると、増えたファイルをリポジトリに追加、なくなったファイルをリポジトリから削除してくれます。

487:デフォルトの名無しさん
08/04/04 18:23:30
話題が途切れたので、ちょいと Mercurial を使った感想を…。

CVS → Subversion と集中リポジトリのリビジョン管理ツールを使ってきましたが、
Mercurial を使ってからというもの、
「サッとリポジトリが作れる」というのがとても気持ちよく、気に入っています。

ローカルの作業ディレクトリは、すぐに hg でリポジトリ化し
修正やコミットをかけた後、完成したらリポジトリ部だけ削除してます。

「作業ディレクトリにリポジトリがくっついている」という発想は
とても便利で面白いと思います。

488:デフォルトの名無しさん
08/04/04 18:29:55
続きです。

いままでしばらく Subversion+svk を使っていましたが、
いまでは Subversion+Mercurial という構成で使っています。

Subversion+svk のときは、svk で自分の手元に持ってきてから
ローカルで開発し、結果を svk smerge で一括送信していましたが、
今は Subversion でチェックアウトした内容をそのまま Mercurial に突っ込み、
Mercurial でさんざん修正・コミットした後、
最後に Subversion でコミットしています。

開発中に Subversion のリポジトリ上に修正が入っていた場合には、
Mercurial のブランチとして取り込んで、Mercurial 上でマージしています。

この方法だと svk みたいに自動化されていませんが、
構成がすっきりして全体の見通しがよく、作業がひとつひとつ理解できるので
安心感があります。

489:デフォルトの名無しさん
08/04/04 18:34:30
Subversion + Mercurial って
それいいな、俺もやってみるか

490:デフォルトの名無しさん
08/04/04 18:43:27
>>488
昔、CVS+Teamwareで俺がやってたのと同じ感じかな・・・と思ったけど逆だ・・・
俺のときは、Teamware側が共用できるやつでCVSがローカル環境・・・・
なんでそんな事したのか思い出した・・・eclipse対応してるかどうかだ・・・

MercurialならMercurialだけでIDE含めて完結できるのが一番楽なんだろうけどねぇ・・・

491:デフォルトの名無しさん
08/04/04 21:18:50
>>488
熱いレポート乙!
参考にさせてもらいます。


492:デフォルトの名無しさん
08/04/05 02:45:13
GitHubって招待制なの?
だれか invite してくれ

493:デフォルトの名無しさん
08/04/05 03:15:59
>>492
そんなのあるんだね、知らなかった
とりあえずsignupしてみたけど、いつになるやら
SourceForgeもGitサポートすればいいのになぁ

494:デフォルトの名無しさん
08/04/05 04:03:16
>>488
ちなみに hgsvn を使用しているのですか?

495:デフォルトの名無しさん
08/04/05 05:58:53
どこをどう読んだらそうなるんだ

496:デフォルトの名無しさん
08/04/05 13:56:25
>>492
なんか知らんがinviteされた(たぶん中の人?)
メアド晒してくれればinviteするよ

497:デフォルトの名無しさん
08/04/05 13:59:02
>>494
hgsvn は使っていません。
いまは Subversion でエクスポート
→ .svn 以外をそのまま新規に Mercurial 管理下に入れる(手作業)
という感じです。

Subversion に戻すときは、Subversion のリポジトリをチェックして
更新されていなかったら、そのまま Subversion でコミット。
更新されていたら、Mercurial のブランチとして取り込んでマージしてから
Subversion でコミット、です。
すべて手作業です。

498:デフォルトの名無しさん
08/04/05 13:59:32
Git と Mercurial の比較ってだれかやってません?

499:デフォルトの名無しさん
08/04/05 16:05:53
>>498
URLリンク(www.opensolaris.org)
OpenSolaris が Mercurialを選ぶときに行ったレビュー。
粒度が揃っているとは言えないがまあ参考に。(下の方にあります)

500:デフォルトの名無しさん
08/04/05 21:36:34
URLリンク(weblog.rubyonrails.com)
まー政治的にpythonは選べないだろうなw

501:デフォルトの名無しさん
08/04/05 21:38:53
>>500
でもTrac使ってるぜ。


502:デフォルトの名無しさん
08/04/05 21:55:56
railsではbtsは難しいということですか、分かりません><

503:デフォルトの名無しさん
08/04/05 22:06:23
いまならredmineとかretrospectivaとかに移行してもよさそうなものなのにね>rails


504:デフォルトの名無しさん
08/04/05 22:08:45
データの引っ越しの手間が馬鹿にならないとか?



505:デフォルトの名無しさん
08/04/05 23:05:56
>>500
Ruby界隈はMatzが使っているという理由でGit一択です

506:デフォルトの名無しさん
08/04/06 00:03:18
matzって基本的にオールドタイプだから新しめの道具は使ったことなさそうなイメージ。
cvsからsvnに切り替えるのもかなりもたついてたような。


507:デフォルトの名無しさん
08/04/06 01:04:24
>>506
svnに切り替えるときに、ローカルでの管理用としてgitを導入した。
URLリンク(www.rubyist.net)

508:デフォルトの名無しさん
08/04/06 02:29:54
StGITは、git導入したというのだろうか。

StGITローカルパッチ管理に使ってるが便利だ。
でもドキュメント少ないな
>>507 の記事とかチュートリアルの翻訳くらいしか日本語の記事が無いので
公式見てもチュートリアルの元記事しかなかった…。

509:デフォルトの名無しさん
08/04/06 03:00:10
StGITは「git使ってることを意識しなくて済むツール」なのではなかろうか。


510:デフォルトの名無しさん
08/04/06 12:06:25
当時はgitって本当にバックエンド用のplumbingコマンドしかなかったからね。
今でこそフロントエンド用のporcelainコマンドも充実してるけど。

511:デフォルトの名無しさん
08/04/06 13:15:50
>>501-504
BTS も rails 製の Lighthouse に移行するよ。

って >>500 に書いてあるじゃん。読まずに脊髄反射してんだなw

512:デフォルトの名無しさん
08/04/07 15:36:59
Rubyが好きじゃない俺はどうすればいいですか?

513:デフォルトの名無しさん
08/04/07 16:54:05
>>512
自己暗示


514:デフォルトの名無しさん
08/04/07 17:47:12
>>512
ブール代数的に言うと、好きじゃないということは、嫌いじゃないかもしれない。道は残ってるね。


515:デフォルトの名無しさん
08/04/07 21:22:00
>>512
安心しろ、Joel Spolsky も Ruby が嫌いみたいだから。
URLリンク(www.joelonsoftware.com)

っと、これだけだとスレと関係なくなってしまうので。
… Python に走って Mercurial 使えば?

516:デフォルトの名無しさん
08/04/07 21:40:52
>>512
言語の好き嫌いがある内は只の厨房だと自覚するべきだと思うよ。
自分の得意不得意のせいであんまり好きになれない言語があるのはしょうがないとおもうし、結構あるしorz


517:デフォルトの名無しさん
08/04/07 22:03:50
>>497
詳細な説明&レポートとても助かります。

TortoiseSVN で管理している svnワーキングコピーに、
なんの疑問もいだかずに TortoiseHG で真剣に管理しようとしていた俺は・・・


518:デフォルトの名無しさん
08/04/07 23:27:46
韓国語が嫌いだ

519:デフォルトの名無しさん
08/04/08 00:34:50
>>514
ブール代数的なら「好きじゃない」イコール「嫌い」だろ。
3値で「好きじゃない」なら「嫌い」か「興味ない」。

520:デフォルトの名無しさん
08/04/08 02:47:04
>>512の突っ込みどころは、Ruby好きじゃないのにrails使うのかよってところじゃないのか



次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch