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

>>6
p4vってやつですかね。最近知りましたw 
コードの変更をコミットしたい場合、まずリポジトリを編集状態にしてchangelist
とやらを作成し、それをアナウンスしてコード変更をレビューしてもらう。 でそれが通ると初めてコミットが許される.... というルールだそうで > 今の会社

なんだかコミットの敷居が上がった感じ。コミットの意味合いが違うというべきか。
みんなローカルな変更はどう管理してるのかな。

まあ、バージョン管理システムとビルドのシステムがどう繋がっているのかにも
よるのかな。

11 ：デフォルトの名無しさん：2012/04/27(金) 10:21:00.98

こういうよくわからないベンダのバージョン管理ソフトって開発者の頭越しで
導入が決められるんだろうなぁとふと思った。

12 ：デフォルトの名無しさん：2012/04/27(金) 11:44:57.32

確かに、独自のバージョン管理ソフトとか持ってるところあるよなあ。
gitやhgを望まないまでも、とりあえず何も考えずにsvnにしとけば何の問題もないのに。

13 ：デフォルトの名無しさん：2012/04/27(金) 15:55:27.75

svnも無茶な使い方してるとこはあって
なかなか何の問題もないともいえないのよね
馬鹿な連中の行動は予想を遥かに上まわるんだ

14 ：デフォルトの名無しさん：2012/04/27(金) 21:00:18.54

こういうよくわからないソフトに慣れたやつが転職やら派遣やらで拡散してっ
て svn とかの無茶な使い方にも繋ってるんじゃないかと思ってる。

15 ：デフォルトの名無しさん：2012/04/27(金) 21:18:49.99

いや、無茶な使い方は大抵ロートルから生まれると思う。

16 ：デフォルトの名無しさん：2012/04/28(土) 01:46:23.39

ロートルもあるけどバージョン管理のことを
細かいとこまで覚えるのが面倒だと思う連中は多いのよ。
純粋に道具として見れば、まあある意味は正しいんだけど。

17 ：デフォルトの名無しさん：2012/04/28(土) 04:33:46.65

>>11
Perforceのことなら、xcodeでも対応してた(過去形)りして
それなりにメジャな製品だと思ってたけど。

18 ：デフォルトの名無しさん：2012/04/28(土) 11:01:41.20

最新のソース管理も出来ないのに便利な道具を使わないという人には困る。

フォルダ「最新のソース」
フォルダ「最新のコースのコピー」
フォルダ「最新のソース2」
フォルダ「プロジェクト名」（実はここが一番新しかったりする)

ちなみにうちは受託開発しているけれど、社内規定では利用が規則化されていないので、
プロジェクトリーダー毎に好きなのを使っているかと思いきや、誰も使っていない。

19 ：デフォルトの名無しさん：2012/04/28(土) 17:18:31.25

うちコンサルしてるけど、構成管理すらまともにできないのに、
最の新方法論（ｷﾘｯで生産性あげようとするクライアントが多くて困るわ
最後にコードがｇｄｇｄになるなら技法とか方法論なんて効果ね－よ

20 ：デフォルトの名無しさん：2012/04/29(日) 16:24:46.90

>>18
>フォルダ「プロジェクト名」（実はここが一番新しかったりする)

せめて「プロジェクト名-YYYYMMDD-追番」にしようよ。(w

21 ：デフォルトの名無しさん：2012/04/29(日) 16:52:45.92

VCS使わないなら、日付をフォルダ名にするのが一番手軽で確実だよね

22 ：デフォルトの名無しさん：2012/04/29(日) 17:39:23.14

確実なもんか。
コピーした日付けの奴と作成した日付けの奴が混ざって混乱するのが関の山だ。

23 ：デフォルトの名無しさん：2012/04/29(日) 18:25:55.82

>>21
DropBoxとかに入れてしまえば、自動でバージョン管理できるんじゃね？

24 ：デフォルトの名無しさん：2012/04/29(日) 18:40:05.93

>>22
>コピーした日付けの奴と作成した日付けの奴が混ざって混乱するのが関の山だ。

いったい何を作成した日付をつけるんだ？
さすがにそんなアホに付ける薬はないだろうなぁ。

25 ：デフォルトの名無しさん：2012/04/29(日) 21:49:27.56

ダメなプロジェクトほど
フォルダツリーのコピーを作りたがる

で、最新という名のフォルダが最新じゃないという

26 ：デフォルトの名無しさん：2012/04/29(日) 22:59:56.72

ほげプロジェクト_最新 - コピー

27 ：デフォルトの名無しさん：2012/04/29(日) 23:21:22.21

最新のはずなのにVisualStudioプロジェクトファイルだけ更新されていたりする

28 ：デフォルトの名無しさん：2012/04/29(日) 23:33:04.71

そしてフォルダの更新時刻がフォルダをコピーした時刻
（≠個々のファイルの更新時刻）

29 ：デフォルトの名無しさん：2012/04/30(月) 00:07:18.13

フォルダ方式で管理しているうちの常駐先だと、バグ表に「先祖帰り」とかいう
項目があったｗ

さらに、ファイルをコピーしたつもりがムーブしてマスターファイルが
消えちゃったということが多いｗｗ

30 ：デフォルトの名無しさん：2012/04/30(月) 00:54:36.00

>>29
>先祖帰り

それは別にフォルダ方式じゃなくてもよくあるタイプのバグじゃ?
と思ったがもしかして「先祖返り」と「先祖帰り」を区別して使っていたりして。
いいなあ先祖帰りバグ。

31 ：デフォルトの名無しさん：2012/04/30(月) 03:15:09.10

Windows界隈ではVisualStudioの設定だけは手でやるのって普通なの?
すげえうざいんだけどあれ

32 ：デフォルトの名無しさん：2012/04/30(月) 03:45:06.32

>>30
>それは別にフォルダ方式じゃなくてもよくあるタイプのバグじゃ?

そのとおりだわ。過去にいたフォルダ方式じゃないところでもあったが、
今の現場だと、週に１回、多い時だと週２，３回位くらいで頻発してるので、
先祖返り＝フォルダ方式のバグと脳内で勝手に思ってた。

先祖帰りは間違ってた

33 ：デフォルトの名無しさん：2012/04/30(月) 09:42:47.93

>>31
VisualStudio の設定が何をさすのか知らんけど、
*.user とか *.suo はバージョン管理してはだめだよ。

まあ、VisualStudio は *.sln で GUID ポイもので管理してるけど、
なんかの操作でそいつを書き換えたりするので、コンフリクトしやすいし
コンフリクトの解消が面倒。

なので、大きな設定変更をやるのは注意した方がいい。

TFS とか使えば、ここら辺は楽になるんだろうか。

34 ：デフォルトの名無しさん：2012/04/30(月) 10:00:16.56

.slnは管理すべきだろ

35 ：デフォルトの名無しさん：2012/04/30(月) 11:14:12.80

チェックアウトして何も考えずに .sln 開いてビルドできるレベルまではバージョン管理するでしょ
コンフリクトしたら素直に上書きで

36 ：デフォルトの名無しさん：2012/04/30(月) 13:46:12.92

>>34-35
誰も管理するなとは言ってないよ。
管理するのに注意が必要って言ってるだけ。

コンフリクトしたら上書きでと言うけど、そうすると一方の変更が反映されないよ。
なので、設定変更する時は他の人がやってないように注意しないとえらく面倒だよ。

みんなそういう経験ないのかなぁ…

37 ：デフォルトの名無しさん：2012/04/30(月) 13:57:05.49

インクルードパスとかはVS2008までユーザ（開発者）が個別に管理する必要があったけど
VS2010からはもっと合理的に管理できるようになった

でファイルフォーマットとしては合理的になったが
IDEが生成するファイルが合理的じゃないので台無し

38 ：デフォルトの名無しさん：2012/04/30(月) 14:00:23.04

ソースコードじゃないのにソースコードのように管理できないよって言われても困っちゃうよね

39 ：デフォルトの名無しさん：2012/04/30(月) 14:16:57.78

>>36
経験の結果、設定のコンフリクトなら上書きが良いと気づいたのさ

40 ：デフォルトの名無しさん：2012/04/30(月) 15:05:48.64

>>38
え゛っ、ひょっとしてソースコードしかバージョン管理してないとか？

>>39
いや、俺もコンフリクトしてしまったらそうするしかないと思う。
なので、なるべくコンフリクトしないようにしようと注意せざるを得ない。
VisualStudio が凝ったことしてないなら、もっと楽できたはずなんだが…

41 ：デフォルトの名無しさん：2012/04/30(月) 16:08:31.11

VisualStudio やっぱ素直にはいかないのかな。

42 ：デフォルトの名無しさん：2012/04/30(月) 16:54:04.37

ああ、色々書いてるけど、普通のソース管理は問題なく出来るよ。
ただ、ソースファイルの構成を変えたりするのにちょっと注意が必要というだけ。

43 ：デフォルトの名無しさん：2012/04/30(月) 18:14:52.12

てかEclipseもNetBeansも似たようなもんでしょ

44 ：デフォルトの名無しさん：2012/05/16(水) 23:35:14.51

XCodeだって管理ファイルのコンフリクトがおきたときはどうしようもないしね。
現段階ではIDE使うならしょうがないんじゃない？

その辺はソースほど頻繁に書き換えるものでもないんだから、
結局お互いにコミュニケーションとって解決するのが一番早いし問題が起こらないという結論に達した。

45 ：デフォルトの名無しさん：2012/06/30(土) 12:02:29.43

Eclipse コミュニティサーベイ 2012
http://www.infoq.com/jp/news/2012/06/eclipse-survey

世の中git だねー

46 ：デフォルトの名無しさん：2012/06/30(土) 19:37:10.63

gitは手軽なのがいい。
たとえばちょっとしたメモ（や簡単なシェルスクリプト等）を書く場合でも、どこかにディレクトリを作ってそこに保存するとして
mkdir memo
cd memo
vim a.txt

簡単にmemoをリポジとリーとしてしまえる。
git init
そして適当な時点で a.txt の現在の状態をコミットしてスナップショット保存してしまえば良い
git add a.txt
git commit -m"aaa"

こうしておけば、なにかの間違えで rm * や > a.txt などで消去しまっても git clone や git checkout などで元に戻せるし
過去の時点での a.txt の状態へと行き来も git branch と git checkout で簡単に行える。

バージョン管理が無い場合だと、影響の大きい変更をする場合に、例えばファイルをコピーして a.txt.日付などとして残してから編集したり、
または
// a = 123;
a = 456;
のように古いコードを消さずに、（将来戻したい時用にw）コメントアウトして残したり、をする必要が無い。gitでバージョン管理してれば
ソースコードをバッサリ削除することも躊躇せず行える。なぜなら簡単に git checkout で過去の状態に戻れるから。

超古典的なバージョン管理だとファイル名にサフィックス.bakを付けて保存する方法が昔は多かったけど、同じことがgitならもっと簡単に半自動的にミス無く行えるので、unix系の人は是非gitを使ったほうがいいと思う。古典的な.bakではなく。

47 ：デフォルトの名無しさん：2012/06/30(土) 19:45:36.78

最近バージョン管理を使い始めた人なのかな？

48 ：デフォルトの名無しさん：2012/06/30(土) 20:07:52.85

コピペじゃね？

49 ：デフォルトの名無しさん：2012/06/30(土) 20:13:57.97

rcsでも通用しそうな話だよな。

50 ：デフォルトの名無しさん：2012/06/30(土) 20:17:23.05

gitは２年前から使い始めたから最近。

bugzillaレベルの場所ならgit://でアドレス貼れば補足無しで通じるし、外人は平気でewfanao34uo3no3n3jl23jjn3123j34jnここだとか言ってコミットID張り付けて一行レスだけだったりするのだけどそれで通じるから楽でいい。
しかし日本だとまだまだgit clone git://... ってフルコマンド書かないと通じない雰囲気なのが面倒（プログラム板ですらgit://だけだと半分くらいにしか意味が通じなさそうな不安を感じる）
もっとgitに普及してほしい。いちいち git log でcommit id の一覧を見て...的な説明添えるのが面倒くさいので。

51 ：デフォルトの名無しさん：2012/06/30(土) 20:28:03.44

>>50
>フルコマンド書かないと通じない雰囲気
それで通じないとしたら、そいつはgit使ってないんだろ
かってに変な雰囲気作るな

52 ：デフォルトの名無しさん：2012/06/30(土) 20:38:47.05

>>50
アスペなのは何年前からなのでしょうか？

53 ：デフォルトの名無しさん：2012/06/30(土) 20:44:20.77

windows持ってないので分からないのだが、
相手がwindowsの場合だと、git環境整備が異常に大変そうな気がして気をつかってzipを用意する必要があったりで面倒。
最近のwindowsだとgitはどの程度簡単に使える？まだcygwin内限定とかの状態？それともlinux同様に普通に使える状態？

54 ：デフォルトの名無しさん：2012/06/30(土) 21:23:24.19

>>53
GitHub for Windows でもバニラな環境は入るからそれで入れてしまえば
シェルからもひとまずは使えてそう困らない。
拡張や周辺ツールまで考えてるなら結局はCygwinやSFUみたいなのが楽かも。
実行ビットや改行コードや国際化ファイル名まで含めると微妙。

55 ：デフォルトの名無しさん：2012/06/30(土) 23:25:52.50

msysgitが正式版でUTF-8ファイル名対応したからだいぶマシになったよね

56 ：デフォルトの名無しさん：2012/07/30(月) 00:12:27.84

ExcelとかWordのドキュメントファイルまで含めてバージョン管理したい場合でも
svn使っとけば大丈夫なの？
いや、以前にそれをCVSでやろうとしてなんか痛い目にあった記憶があるので。

マージ考えない、排他ロックでいい場合は結局TFSが一番良いのかなーとも思う
んだけど、ソース以外のドキュメントファイル管理でもsvn使ってる人います？

57 ：デフォルトの名無しさん：2012/07/30(月) 00:29:07.19

いるよ。

58 ：デフォルトの名無しさん：2012/07/30(月) 00:34:29.05

>>56
CVSでドキュメント管理する場合の問題って、日本語ファイル名とか改行コードとかキーワード展開とか？
SVNならどれも問題ないはず。(ファイル名は設定が必要かも。)

59 ：デフォルトの名無しさん：2012/07/30(月) 00:53:10.02

RCSで自由自在にバージョン管理できる奴だけが「TFSでいい」て言う資格があると思う

60 ：デフォルトの名無しさん：2012/07/31(火) 03:20:59.77

SVNでVSの管理してるとうっかりやるのが、プロジェクトにファイル追加したときに
セーブせずに更新かけたときとかかな。

セーブしてりゃマージされるんだが、更新で上書きされると巻き戻る。

ファイルの追加なんで大した被害でもないけど。

61 ：デフォルトの名無しさん：2012/08/01(水) 06:30:58.37

svn update する前に気をつける、くらいかな。
まめに保存する（ctrl-Sする）とか、ビルド前に自動保存するとか、
プロジェクトやソリューションの設定を変えたらすぐに保存するとか。
VSならAnkhSVN 併用したり、MS-Officeならmsofficesvnを併用したりとか。

62 ：デフォルトの名無しさん：2012/08/01(水) 22:23:32.35

無難にsubにするかーと思ったが、なんとTeamFoundationServerに無料版が
出るらしいので折角だからTFSを選ぶことにした。

63 ：デフォルトの名無しさん：2012/08/02(木) 00:07:22.73

>>61
> MS-Officeならmsofficesvnを併用したりとか。

ありゃ、こんなもんがあるんだ、ちょっと試してみようっと。

64 ：デフォルトの名無しさん：2012/08/04(土) 11:26:19.97

会社が「VSSのチェックアウト管理台帳」使ってた…死にたい…

65 ：デフォルトの名無しさん：2012/08/04(土) 13:45:32.83

　　　　　∧＿∧
　　　　　( ﾟωﾟ　)　チェックアウトは任せろー
　ｶｷｶｷＣ□l丶l丶
　　　　　/　　(　　 )　やめて！
　　　　（ノ￣と、　ｉ
　　　　　　　　しーJ

66 ：デフォルトの名無しさん：2012/08/04(土) 15:56:24.37

うちなんか日付と名前入りのディレクトリがいっぱいでバージョン管理システム使ってないorz

67 ：デフォルトの名無しさん：2012/08/04(土) 16:19:11.74

>>64 >>66
ああ、これは「本人も誰も改善要求せず50年後も同じ状態が続く」フラグだ…

68 ：デフォルトの名無しさん：2012/08/04(土) 19:38:55.76

上が無能だとほんと苦労するよね

69 ：デフォルトの名無しさん：2012/08/04(土) 19:45:48.51

無能でもいいんだよ、邪魔さえしなければ。

無能なくせに、有能と勘違いしてる上司がマジ邪魔。

70 ：デフォルトの名無しさん：2012/08/04(土) 20:44:10.78

それは空気であって無能ではない

71 ：デフォルトの名無しさん：2012/08/04(土) 23:26:41.49

>66
うちも以前はその状態だったが、俺が一人でバージョン管理システム導入して
他の人の代わりにコミットしてあげてたら、そのうち全員が使うようになった。

72 ：デフォルトの名無しさん：2012/08/08(水) 23:38:03.31

ファイルのタイムスタンプで管理してる(´・ω・｀)

73 ：デフォルトの名無しさん：2012/08/09(木) 04:22:28.21

それは最早管理とはいえない。

74 ：デフォルトの名無しさん：2012/08/09(木) 08:03:52.96

>>71
素晴らしい！

75 ：デフォルトの名無しさん：2012/08/23(木) 14:39:26.25

sf.netは10年たっても残ってそうだけど
githubが心配なんでsf.net使ってる

76 ：デフォルトの名無しさん：2012/08/23(木) 15:27:42.29

やっぱりそれは言語がアレだからか？ｗ

77 ：デフォルトの名無しさん：2012/08/26(日) 03:08:53.11

派遣先に行く -> 放置されているsvn鯖があるので使ってみる -> みんな使い出す
自社 -> （俺を除いて）だれも使わない

何だろこの差は

78 ：デフォルトの名無しさん：2012/08/26(日) 09:22:42.68

githubは、gitベースのソーシャルコーディングという
スタイルに特化してる分、
そのスタイルが廃れれば、githubは消えるだろう。
そのときでもsf.netは、時久の流行りのシステムを
取り込んで生き延びると思う。
svnとかgitとか、今までもそうだったろ

79 ：デフォルトの名無しさん：2012/08/26(日) 10:34:07.09

自分の感覚では、githubとかソーシャルコーディングは
定着した感が強いなぁ。
といってもgithubは数年しか経ってないんだよね。
それで、ここまで来るのも凄いけど。

80 ：デフォルトの名無しさん：2012/08/27(月) 14:33:04.16

githubいいでえ～
簡単にfolkして修正してpull出来る。まじ簡単w

81 ：デフォルトの名無しさん：2012/08/27(月) 15:12:47.38

githubの文化があと5年存続したら乗り換えよう

82 ：デフォルトの名無しさん：2012/08/27(月) 15:38:45.89

結論：githubなんかに手を出すな！

83 ：デフォルトの名無しさん：2012/08/27(月) 19:48:20.93

折角無料にしてくれたんだし、みんなでTFS使おうぜ

84 ：デフォルトの名無しさん：2012/08/28(火) 14:06:06.78

githubいいでえ～
馬鹿発見器として

85 ：デフォルトの名無しさん：2012/08/28(火) 14:10:58.34

そのうち2ch以外の全てが馬鹿発見器呼ばわりされるな

86 ：デフォルトの名無しさん：2012/08/28(火) 14:18:42.13

>>85
マテ、2chはバカしかいないだろw

87 ：デフォルトの名無しさん：2012/10/10(水) 20:52:03.98

bitbucketがシンプルなUIになって良い感じ

88 ：デフォルトの名無しさん：2012/10/14(日) 12:52:30.79

>>86
2chは発見するまでも無いが、本人特定が難しいからなｗ

89 ：デフォルトの名無しさん：2012/10/18(木) 15:34:07.37

「サーバの不要なバージョン管理システム」って無いのかな

90 ：デフォルトの名無しさん：2012/10/18(木) 15:44:16.47

ローカルでやるだけじゃん

91 ：デフォルトの名無しさん：2012/10/18(木) 15:59:35.29

>>90
一人ならそれでいいけど、二人以上だとローカルじゃ済まない

92 ：デフォルトの名無しさん：2012/10/18(木) 16:10:02.22

GitでもMercurialでも、共有フォルダでできるよ。

93 ：デフォルトの名無しさん：2012/10/18(木) 16:10:40.43

>>92
そうなんだ、ありがとう
gitってサーバ立てなくてもいいのか

94 ：デフォルトの名無しさん：2012/10/18(木) 16:31:55.96

共有フォルダだってローカルのうちだろ

95 ：デフォルトの名無しさん：2012/10/18(木) 18:23:37.91

>>94
じゃあダメなの？
普通のファイルサーバを使ってバージョン管理したいんだけど

96 ：デフォルトの名無しさん：2012/10/18(木) 18:27:07.11

サーバ不要でローカルで管理してるだけだろう。
そのローカルのファイルの置き場所がファイルサーバにあるだけだろ？

97 ：デフォルトの名無しさん：2012/10/18(木) 18:36:28.26

svnはローカルでもロックファイル作るけど、gitはどうだっけな

98 ：デフォルトの名無しさん：2012/10/18(木) 21:36:19.29

>>95
ググって見た
ttp://stackoverflow.com/questions/750765/concurrency-in-a-git-repo-on-a-network-shared-folder

O_EXCLに該当する機能（排他的にファイルを作る機能？）が有れば万々歳
そうでない場合は、ファイルが壊れたりするような致命的なことは起こらないけど、
pushが成功したように見えて実は失敗してたとか、面倒なことになる可能性がある

まで読んだ（超斜め読み）

99 ：デフォルトの名無しさん：2012/10/19(金) 00:22:03.28

共有フォルダに作ってfile:でアクセスしていたリポジトリを
file:でアクセスできるようにしたまま、後からサーバ立ててgit:とかssh+svn:とかで配信することできる？

100 ：デフォルトの名無しさん：2012/10/19(金) 12:00:52.54

svn でならやってる。
デスクトップでは file: で Checkout して、ノートでは svn://192.168... で Checkout してる。
リポジトリにどのプロセスがアクセスするかだけなんだから、できて当然じゃないかと思うけど。

101 ：デフォルトの名無しさん：2012/10/19(金) 14:53:35.53

>>100
いや、チェックアウトとか、アクセスするプロセスとか関係無いし。

リポジトリを作る方法が同じならばできるし、違えばできない（だろう）ということ。

102 ：デフォルトの名無しさん：2012/10/19(金) 21:53:39.87

>>89
Mercurial最高です。

103 ：デフォルトの名無しさん：2012/10/19(金) 23:15:31.90

Bazaar最高！

104 ：デフォルトの名無しさん：2012/11/04(日) 14:20:11.98

ぶっちゃけsfは広告の多さ、見づらさ、使いづらさ、レスポンスの悪さがピカイチすぎて
いまんとこGitHubに勝る点がないんだよな。なんかこう、強みが古いってだけ

105 ：デフォルトの名無しさん：2012/11/16(金) 19:05:23.52

Windowsのドキュメント　フォルダをまるごとバージョン管理したいのですが
日本語ファイル名扱えるのってsvnしかないですよね
ローカルで管理したいのですが
仮想マシンにsvnサーバーたてるとかしかないのでしょうか

106 ：デフォルトの名無しさん：2012/11/16(金) 19:09:02.08

bzrでも大丈夫だよ。
でも、オフィスのファイルなどのバイナリファイルが多いならDropbox辺りを使った方がいいかもしれない。

107 ：デフォルトの名無しさん：2012/11/16(金) 19:26:03.15

同一pcで完結できるぞ

108 ：デフォルトの名無しさん：2012/11/16(金) 19:58:58.07

svn は file:// とかでローカルリポジトリ作れた気がする

109 ：デフォルトの名無しさん：2012/11/16(金) 20:55:28.45

bzrの日本語ファイル名対応は、互換漢字が全部直されてしまうから、異体字が区別できない
まあ気にならんだろうけど

110 ：デフォルトの名無しさん：2012/11/16(金) 21:19:40.79

bzrは開発が止まったって噂があるが？

111 ：デフォルトの名無しさん：2012/11/16(金) 21:32:36.13

うん。もう枯れた技術として忘れ去られる運命にある。

112 ：デフォルトの名無しさん：2012/11/16(金) 23:02:49.38

枯れた技術ってわりとポジティブな使い方をされると思うけど

113 ：デフォルトの名無しさん：2012/11/17(土) 00:10:22.26

TCPスタックなんかは枯れてないと怖くて使えないしね

114 ：デフォルトの名無しさん：2012/11/17(土) 00:29:44.31

中身継ぎ接ぎだらけってのもあるからなぁ。
それまでのノウハウを元に一回作りなおしたほうがいいかとも思うものもある。

115 ：デフォルトの名無しさん：2012/11/17(土) 01:45:59.22

今の msysgit (Git for Windows) はUTF-8公式サポートしてるから日本語ファイル名もOK

116 ：デフォルトの名無しさん：2012/11/17(土) 07:30:15.37

>>115
でも結局バイナリ多そうなドキュメントまるごとバージョン管理には向いてないこと無い？

117 ：デフォルトの名無しさん：2012/11/17(土) 11:18:57.90

gitは頻繁にマージすることを前提にしたシステムだから、バイナリを上手く管理するには向いてなさそう

118 ：デフォルトの名無しさん：2012/11/17(土) 11:44:32.64

SVNはいまいちっていうか、日本だけダントツで使用率高いあたりガラパゴスしてきてる
世界に取り残されてる感ある

分散リポジトリじゃないことのメリットってファイルロックくらいだと思うけど、
ロックしないといけないようなファイルの更新が頻繁にぶつかる事自体稀だし、
頻繁にぶつかる場合は運用になんか問題ありそうだから、そっちを見直したほうが確実

Git使ってみたけど、ブランチが全部インデックスだから早くて快適だったよ
マスターにプッシュしなけりゃいいわけだからローカルで複数作業を平行してしやすいのがステキ

119 ：デフォルトの名無しさん：2012/11/17(土) 12:08:42.29

>>116-117
バイナリのサイズと比率が大きいならPerforceやAlienbrainの検討を、てなっちゃうかねぇ

>>118
BSD界隈になるとまだCVS使ってるところもざらだよ…
分散型はやっぱ「手元にレポジトリ持てる」＝「じっくりかつ気軽にcommit, amend, rebaseできる」のが大きいよね

120 ：デフォルトの名無しさん：2012/11/17(土) 12:22:11.26

>>119
cvsだとCVSROOT切り替えや周辺ツールで手元にリポジトリミラーしたりして
意外と運用で回避できるし公式にgitミラーあったりするし

121 ：デフォルトの名無しさん：2012/11/17(土) 12:50:58.96

やっぱり、日付フォルダが最強だろ

122 ：デフォルトの名無しさん：2012/11/17(土) 13:04:40.47

>>121
君ぐらいの能力だとそうだろうね。

123 ：デフォルトの名無しさん：2012/11/17(土) 13:23:19.70

>>122
お前の母ちゃんよりはマシだけどな

124 ：デフォルトの名無しさん：2012/11/17(土) 13:25:33.21

小学生かよ…

125 ：デフォルトの名無しさん：2012/11/17(土) 19:44:49.29

SVN環境でGitとかみたいな分散管理するいい方法ってないかな
最近運用都合(リリース作業とか)でコミット禁止になることが多くて、細かいコミットしたりがしづらくて適わん
ブランチは使い方わからないとかいってまったく使おうとしないし、いろいろアレすぎて…

やるとしたら、ローカルにSVNのリポジトリのミラー作って普段はそっち使って、
変更結果をマスターの作業フォルダーに手動でマージしてコミット、とかしかないかな…？

126 ：デフォルトの名無しさん：2012/11/17(土) 20:08:51.48

よくしらんけど、git-svn とかを使えばいいんでないの？

127 ：デフォルトの名無しさん：2012/11/17(土) 20:11:27.06

ローカルで git, merurial, bazzar を使い、subversionとの連携機構を使う。
全員でsubversionを止めてgit,mercurial,bazzar,perforceやbitkeeperにする。
更新が止まったsvkを使って何とかする。
svkを自分で引き継ぐ。
subversionの開発に加わって、分散バージョン管理機能の開発を手伝う。

128 ：デフォルトの名無しさん：2012/11/17(土) 20:29:37.41

>>105
>Windowsのドキュメント　フォルダをまるごとバージョン管理
フリーなものならbzrってことでいいのかな？

129 ：デフォルトの名無しさん：2012/11/17(土) 21:39:59.62

>>128
MSのTeamFoundationServerExpressでええやん。無料やし。
無料やし。

130 ：デフォルトの名無しさん：2012/11/17(土) 22:17:52.03

分散が不要ならsvn一択だろ
Windowsへの対応も、バイナリファイルの扱いが一番上手いのもsvnだよ

いや一番かはわからんけど

131 ：デフォルトの名無しさん：2012/11/18(日) 03:10:07.46

ブランチが使われてないなら、勝手に使って適当にマージすりゃいいんじゃね？

132 ：デフォルトの名無しさん：2012/11/18(日) 03:27:10.29

ブランチって何ですか？

133 ：デフォルトの名無しさん：2012/11/18(日) 04:00:47.98

>>130
バイナリ扱うならperforceが優秀svnはギガ単位の大きなファイル扱うにはちょっと重い
Alienbrainは興味あるんだが使ったこと無いので比較できない。
だれか両方使ったことある人がいたら簡単なレビューしてもらえると助かる

134 ：デフォルトの名無しさん：2012/11/18(日) 04:51:46.23

Windowsって言ってるんだから、まともなのはTFSしか選択肢はないのでは？

135 ：デフォルトの名無しさん：2012/11/18(日) 07:09:53.10

MS の製品が全てまともだと思ってるのか…

幸福な人生を歩んできたんだな。

136 ：125：2012/11/18(日) 11:07:23.41

勝手にインスコしていいとか、自分で使うためのブランチを切ってよければそれでよかったんだけど
SVNしかない状態でどうにかできないかなーと
やっぱ手はなさそうだし、手動マージする方向で考えてみるわ…

137 ：デフォルトの名無しさん：2012/11/18(日) 11:43:29.52

>>127 がかわいそうだ…

138 ：デフォルトの名無しさん：2012/11/18(日) 12:48:50.20

>>127は1行目は126とほぼ同じで2行目からはただのネタじゃ
>>125はSVN以外がインストール禁止のお堅い糞職場なんだろ

一番いい解決策は転職じゃねーのｗ

139 ：デフォルトの名無しさん：2012/11/18(日) 13:45:29.93

今ならBazaarを自分の好きなように改造できるぞー

140 ：デフォルトの名無しさん：2012/11/18(日) 14:28:48.08

>135 の頭の幸せさにﾜﾛｽｗ

141 ：デフォルトの名無しさん：2012/11/18(日) 14:43:20.96

使ったこともないTeamFoundationServerを頭ごなしに馬鹿にするやつは、ほぼ底辺IT企業に勤めている。

142 ：デフォルトの名無しさん：2012/11/18(日) 14:47:48.94

>>141
Windowsを使っているところが底辺IT企業では？

143 ：デフォルトの名無しさん：2012/11/18(日) 15:21:46.47

Windows、Microsoftつー単語で思考停止する >142 みたいなのを雇ってるのが底辺IT企業ｗ

MSはOS「以外」には優秀なプロダクトが多い。VSとかExcelとか。
でもまあTFS使うかといわれるとちょっと微妙だけど。
多機能＆大きすぎて小回りが利かない。

144 ：デフォルトの名無しさん：2012/11/18(日) 16:51:34.99

>>136
git-svnなどを自分のPCに入れるのをなんとか許可取れるよう説得してみたら？
サーバーに入れるわけじゃないし他人に迷惑かけないという辺りを説明して

145 ：デフォルトの名無しさん：2012/11/18(日) 19:09:54.22

VSSは糞だろうが

146 ：デフォルトの名無しさん：2012/11/18(日) 19:23:04.09

git-svnは糞

147 ：デフォルトの名無しさん：2012/11/18(日) 22:57:39.73

>>145
いきなりどうしたの？VSSで時代が止まっちゃってる人？

148 ：デフォルトの名無しさん：2012/11/18(日) 23:29:08.69

VSとVSSを勘違いしたんじゃないかと思う
まぁスレタイ的にVSとかはスレチだし仕方がない気はするｗ

149 ：デフォルトの名無しさん：2012/11/18(日) 23:30:17.02

>MSはOS「以外」には優秀なプロダクトが多い。

に対するVSSは糞って意味だったんだが

150 ：デフォルトの名無しさん：2012/11/18(日) 23:42:43.85

>>143
硬直した異様な操作性でExcelなんて最悪な部類だと思う。
Ctrl-Cを押した時のセルのまわりのちらちら四角形なんて殺意すら覚える。
スレチすまん。

151 ：デフォルトの名無しさん：2012/11/18(日) 23:58:57.88

Excelを越える同系アプリが何一つ存在しない事実。
しかもExcelはバージョン管理にも大いに使えるしなー。

誰もが名前を知ってる大手カード会社のバージョン管理がExcelだった悪夢。

152 ：デフォルトの名無しさん：2012/11/19(月) 00:05:03.29

>>136
だからよー。そのSVNでブランチ切れよ。

153 ：デフォルトの名無しさん：2012/11/19(月) 22:51:56.19

勝手にブランチ切るのを許してないんだろ。

154 ：デフォルトの名無しさん：2012/11/20(火) 01:43:13.39

どうしようもない状況なら転職が最良の解決策ってのは間違いではない
既存を常に正と信じきってしまってるところはどう頑張っても改善しようとしないからな

155 ：デフォルトの名無しさん：2012/11/20(火) 07:40:23.22

2chのことか

156 ：デフォルトの名無しさん：2012/11/24(土) 11:55:48.87

>>152-154
Mercurialのいいところは、他人を説得しなくてもいいことなので
よほどでかいソースじゃなかったら自分だけはさっさとMercurial化しちゃうのが吉。
これで仕事のストレスはかなり軽減された。
未だにCVSとかSVNとかやってられんが、Mercurial化を個人でやるには誰も困らない。

157 ：デフォルトの名無しさん：2012/11/24(土) 12:12:23.98

別に SVN だって個人でやる分には誰も困らんと思うが…

まさかサーバー必須とか思ってないよね？

158 ：デフォルトの名無しさん：2012/11/24(土) 18:57:03.47

旧式なCVSやSVNを使いたくないから、個人でなんとかできるか？って話だろ
頭沸いてるのか

159 ：デフォルトの名無しさん：2012/11/24(土) 19:28:19.50

svn 嫌なら、git なりでローカルリポジトリ作ればいいだけだろ。

応用力もないのか？

160 ：デフォルトの名無しさん：2012/11/24(土) 21:12:14.92

社内ネットワークがインターネットから遮断されてたり、
そうでなくとも自PCに何か入れようと思ったら管理者に申請＆許可が必要な職場もあるんだが

161 ：デフォルトの名無しさん：2012/11/24(土) 21:21:46.40

うん、そういう職場は珍しくない、うちも許可が必要だし。

でも、そういう職場だと >>156 もだめだよね。

162 ：デフォルトの名無しさん：2012/11/25(日) 01:01:06.89

ＳＶＮでも使いたくないとかそんなに便利なのかよ。

プロジェクトの規模がでかくてＳＶＮ遅くてたまんねぇってのはあるが。

163 ：デフォルトの名無しさん：2012/11/25(日) 01:58:02.06

>>161 うん、>>156,159に向けて言ったんだ
>>162 分散型は実際、便利だよ。ローカルで気軽にコミットできるのとできないのとでは大違い

164 ：デフォルトの名無しさん：2012/11/25(日) 19:23:22.96

日本は頭固い企業多いからな
しかも技術者の不勉強度も高い
SVNがいつまでも使われ続ける環境が多いのは、新しい技術に手を出す層がいないからだと思う

165 ：デフォルトの名無しさん：2012/11/25(日) 22:21:44.26

>>161
そこだけは根性出すしか無い。
これは開発に必要なツールです（キリッ

166 ：デフォルトの名無しさん：2012/11/25(日) 22:25:43.76

あんたが変えることを諦めたらその会社では30年後もsvnのままだぞ

167 ：デフォルトの名無しさん：2012/11/25(日) 23:36:46.08

まて、お前がSVNを分散型に改造すれば良いんじゃないのか？

168 ：デフォルトの名無しさん：2012/11/25(日) 23:38:45.15

svkを引き継いでくれたら嬉しいんだけど、svnがローカルコミットに対応するほうが早いんだろうなあ

169 ：デフォルトの名無しさん：2012/11/26(月) 01:33:34.09

SVNを利用してるのはTortoiseSVNが神なうえに、バイナリにも強いからでしょ。
プログラマ以外がｴｸｾﾙとかコミットするのにもお手軽。

gitはよく名前みるけど、乗り換えるほどのものなのかイマイチ印象が。

SVNだとブランチきって、ある程度の段階でマージとか分散チックにも出来ると思うけど
やっぱサーバーのパフォーマンス次第になるんかね。

１度使ってみるか。

170 ：デフォルトの名無しさん：2012/11/26(月) 06:40:31.57

Subversion で、チームのリポジトリと別に、ローカルにもリポジトリを作って作業してる。
それぞれに作業コピーを作って、ローカルのリポジトリの作業コピーで作業してる。
それぞれの作業コピー同士を WinMerge でマージして、それぞれに Update/Commit。
実験的ブランチをホイホイ切れるので気が楽。

171 ：デフォルトの名無しさん：2012/11/26(月) 07:43:57.64

作業ミスしてお釈迦にする悪寒。

172 ：デフォルトの名無しさん：2012/11/26(月) 08:35:08.16

VCS使ってるのはプログラマだけじゃないからなぁ

デザイナやら企画屋やら広報やらみんな使うんだし、
結局そのプロジェクトに参加してるメンバー全員のツールに対する
理解度考えるとSVNを選択することって多いよ。

プログラマは当然git使いたがるけど、プログラマ以外の人達に
採用を納得させるだけのアドバンテージがsvnとgitの間には無いんだよな。

173 ：デフォルトの名無しさん：2012/11/26(月) 10:33:20.39

公式用と俺様用で別のVCS使うと間違える可能性がかなり減らせていいぞ

174 ：デフォルトの名無しさん：2012/11/26(月) 11:44:12.29

そういう意味ならgitの方が良くね？

175 ：デフォルトの名無しさん：2012/11/26(月) 12:01:50.45

は？
gitはVCSじゃないとでも？

176 ：デフォルトの名無しさん：2012/11/26(月) 12:04:23.78

svnよりgitの方がってことだろ。JK
そんなこと、>170以外はみんな判っていることだけどな。

177 ：デフォルトの名無しさん：2012/11/26(月) 12:10:07.43

gitってバックアップにも使える？
ネットワークドライブ上のフォルダをレポジトリ？っていうの？
ローカルのディスクをワークスペース？っぽくして
バージョン管理兼バックアップしたい

178 ：デフォルトの名無しさん：2012/11/26(月) 12:33:10.84

179 ：デフォルトの名無しさん：2012/11/26(月) 12:39:28.91

ゲームのセーブデータのバックアップに最適

Gitの作業フォルダにゲームをインスコして、コミットしまくると完璧

180 ：デフォルトの名無しさん：2012/11/26(月) 13:16:15.19

gitはバックアップとして使えないよ。
push -fすれば全部パー。

181 ：デフォルトの名無しさん：2012/11/26(月) 13:21:10.94

そらそうよ

182 ：デフォルトの名無しさん：2012/11/26(月) 13:56:44.23

SCMはSCMであってバックアップツールでもアセット管理ツールでもないからなぁ

183 ：デフォルトの名無しさん：2012/11/26(月) 14:00:52.24

いや、「push -fすれば全部パー」だし、「rm -rfすれば全部パー」だよ
「SCMはバックアップツールにはならないけどちゃんとしたバックアップツールは別にあるので買いなさい」
は違うんじゃないかと

184 ：デフォルトの名無しさん：2012/11/26(月) 14:02:01.96

resetしたら負け

185 ：デフォルトの名無しさん：2012/11/26(月) 14:28:51.43

SCMとは別にバックアップしてたって、そのバックアップ先でrm -fしたら全部パーだろ
消去不能な外部メディアを使えってことなのか？

俺の場合gitのリポジトリは複数の場所に複製が勝手に作られるんで、
手元でpush -fしても全部パーにはならない

186 ：デフォルトの名無しさん：2012/11/26(月) 14:30:00.64

>>185
> 俺の場合gitのリポジトリは複数の場所に複製が勝手に作られるんで、
> 手元でpush -fしても全部パーにはならない

？？？？？？？？？

187 ：デフォルトの名無しさん：2012/11/26(月) 14:39:57.19

>186
馬鹿ですね
わかります

>185
ネットワークドライブ側のバックアップを世代管理しとけば良いだけの話じゃね？

188 ：デフォルトの名無しさん：2012/11/26(月) 14:45:53.35

>>187
まあ、世代管理みたいなもんだよ
ただバックアップツールとか使わず、gitだけでやってるってだけで

189 ：デフォルトの名無しさん：2012/11/26(月) 14:49:59.76

>>187
force updateをご存知ないようで

190 ：デフォルトの名無しさん：2012/11/28(水) 18:22:11.64

結局、>>177みたいなことは出来るってこと？

191 ：デフォルトの名無しさん：2012/11/28(水) 18:26:35.01

>>190
git gc(prune)でリビジョンが破棄されるということを知らない馬鹿が出来る信じていた。

192 ：デフォルトの名無しさん：2012/11/28(水) 20:06:46.21

破棄されるのはrebaseとかしてどこからも参照できなくなったリビジョンだろ
根っこが勝手にpruneされたらそっちの方が問題だわ

193 ：デフォルトの名無しさん：2012/11/28(水) 20:25:57.27

>>192
push -fしたら元のブランチのリビジョンが破棄される。
>>185 が具体的に何をしているかわかないが、fetchしているとしても、
そこでも元のブランチのリビジョン破棄される。

194 ：デフォルトの名無しさん：2012/11/28(水) 21:07:33.23

特定の人のみがpushする、かつpush -fは使わないって運用前提なら問題無いのでは？

195 ：デフォルトの名無しさん：2012/11/28(水) 21:15:14.15

じゃあ>>177みたいなのはできないってことか・・・
横着せずちゃんとした同期ソフト買うか

196 ：デフォルトの名無しさん：2012/11/28(水) 21:59:53.10

馬鹿と鋏は使いよう

197 ：デフォルトの名無しさん：2012/11/28(水) 22:03:37.12

いいこと聞いた
コミット権限持ってるあのレポジトリとかこのレポジトリとか全部push -fでぶっ壊してやろうかねぇｗ

198 ：デフォルトの名無しさん：2012/11/28(水) 22:19:28.22

ブランチが消えても実際にコミットがgcで消えちゃうまではかなり時間があるから戻すのは簡単だし、
どこにもcloneされてない孤立して放置されたレポジトリでもない限り、
とくにダメージは無い。

199 ：デフォルトの名無しさん：2012/11/28(水) 22:31:09.32

>>197
別にいいんじゃね
あんたに権限渡したプロジェクトが悪いんだから

200 ：デフォルトの名無しさん：2012/11/29(木) 18:20:39.33

hgならpush -fしても何も消えることはないから安心

201 ：デフォルトの名無しさん：2012/11/29(木) 18:45:20.94

gitのpushは次のリリースで仕様が変わるんじゃなかったっけ？
gitは使ってないからよく知らないけど

202 ：デフォルトの名無しさん：2012/11/29(木) 18:52:12.85

git はpushの仕様が怖くて、試しで使ったプロジェクト限りで封印してる……
まだSubversionから離れられない……Mercurialのマルチバイト対応はまだか……

203 ：デフォルトの名無しさん：2012/11/30(金) 12:29:12.65

Bazaar でいいじゃん。

204 ：デフォルトの名無しさん：2012/11/30(金) 13:59:27.53

>>193
gitはpushされるほうがreceive.denyNonFastforwards = trueなら、push -f は拒否られるんじゃ無いの？
この指定も無視する方法あんの？

205 ：デフォルトの名無しさん：2012/11/30(金) 14:16:38.19

>>204
つgithub

206 ：デフォルトの名無しさん：2012/11/30(金) 14:31:42.33

>>205
自分で用意したリポジトリなら設定できるだろ？

あと、master以外はブランチごと削除して置き換えるとかできるから、
receive.denyDeletes = trueも設定しとけばいいのか

207 ：デフォルトの名無しさん：2012/11/30(金) 18:56:50.16

gitとmercurialって、どっちが強いの？教えてエロい人

208 ：デフォルトの名無しさん：2012/11/30(金) 19:07:37.70

イデオン

209 ：デフォルトの名無しさん：2012/11/30(金) 19:28:19.12

最初の敷居の低さではhgだろ
gitは自由度が高すぎるというかVCSでは避けたいことも簡単に道を踏み外せるし
熟練者にとってはそれが魅力なんだろうが

210 ：デフォルトの名無しさん：2012/11/30(金) 19:32:27.03

>>207
Bazaar

211 ：デフォルトの名無しさん：2012/11/30(金) 21:19:32.52

gitは無茶やってもリカバリーできないことはほとんど無いし
ちゃんとリカバリーできたかどうかもわりとはっきり確認できるし
その辺まで仕組みが理解できればわりと快適

212 ：デフォルトの名無しさん：2012/11/30(金) 21:25:42.03

>>211
ドカタにそれが理解できるのが何％いるのだろうか？

213 ：デフォルトの名無しさん：2012/11/30(金) 22:01:15.78

チームにはアホもいるからmercurialと言いたいが
以前真性アホがいてsvnよりvssのほうが良かったとか言い出しやがったからな

214 ：デフォルトの名無しさん：2012/12/01(土) 12:02:06.49

gitの敷居はVCSの中でも低い方だと思うの

215 ：デフォルトの名無しさん：2012/12/01(土) 13:33:21.34

導入は楽だわな
アクセス制御もユーザーアカウントもないんだから
ただ、運用となると
アホがひとり混じる→誰かが直してあげる
と言うコストが発生してしまう

216 ：デフォルトの名無しさん：2012/12/01(土) 13:40:51.55

アホには無理

217 ：デフォルトの名無しさん：2012/12/01(土) 16:40:33.61

この業界アホが増えてきたからちょっとしたスキルが必要なものも採用に躊躇される、って会社は少なくない気はする
スキル重視な会社少なすぎじゃね…

218 ：デフォルトの名無しさん：2012/12/01(土) 16:45:46.27

うちの会社でも検討したが、gitはややこしすぎて無理。
mercurialでもかなりギリギリって感じ。

219 ：デフォルトの名無しさん：2012/12/02(日) 22:14:35.26

プログラマのチームだったら、そんな理解力でまともな製品作れるのかと思うことしきりだが、
まぁ俺マじゃないからどうでもいいや

220 ：デフォルトの名無しさん：2012/12/02(日) 22:20:46.69

そして>>218の会社では大量の日付つきzipファイルが

221 ：デフォルトの名無しさん：2012/12/03(月) 04:52:47.72

zipなら未だいいよ。
某所の開発用端末には日付けフォルダが多層化しちまってる。
カレントにある日付けフォルダごと別の日付けフォルダにコピーする馬鹿って何考えているんだろうね。

222 ：デフォルトの名無しさん：2012/12/03(月) 05:24:26.25

自分の部屋も整頓できないタイプだな

223 ：デフォルトの名無しさん：2012/12/03(月) 07:17:31.09

だから Windows 8 のスタートはあんな風になってしまったの

224 ：デフォルトの名無しさん：2012/12/03(月) 13:46:59.08

subversion導入だけでも半年以上掛かったからなぁ。
mercurialは1年以上は掛かるな。

225 ：デフォルトの名無しさん：2012/12/03(月) 13:48:37.53

年月がかかっても導入される事例はあるんだな
希望は捨てずにいようと思う

226 ：デフォルトの名無しさん：2012/12/03(月) 18:11:47.18

何かBazzarが最近オチ担当みたいになってて笑える
>>218
プログラマだってツールへの習熟度は大事だって。
理解すれば大丈夫なことでも理解間違いがあってレポジトリが壊れると怖い。
壊れなくても復旧に時間が掛かる状況はなるべく避けたいし。

227 ：デフォルトの名無しさん：2012/12/03(月) 19:58:50.06

Bazzar は変態用だからな

228 ：デフォルトの名無しさん：2012/12/03(月) 20:21:14.95

っていうか技術に興味もたない職業マが増えすぎて、スキルレベルがわりと酷い
とくに中途半端な大手やそのグループ企業のマの質は劣悪

229 ：デフォルトの名無しさん：2012/12/03(月) 21:13:25.05

いつと比べて増えたって言ってるんだ。昔から底辺は広かった。

230 ：デフォルトの名無しさん：2012/12/03(月) 21:36:59.71

昔は、ある程度のスキルが有る連中しかバージョン管理システム使ってなかっただけだよね。
そんなのあるの知らない人が多かったという。

231 ：デフォルトの名無しさん：2012/12/04(火) 09:08:20.99

VSSが馬鹿を増やした

232 ：デフォルトの名無しさん：2012/12/04(火) 15:11:16.32

しかし、VSSでも神と呼ばれた時代があった。
問題は「VSSは良い物だ」と言う考えを変えられなかった人達にある。
数年前にMS自身がVSSを放棄したことで、このスレに来たって人も居るんじゃないかな？

俺だ

233 ：デフォルトの名無しさん：2012/12/04(火) 19:35:16.00

VSSでもなんでも、バージョン管理してるだけで
してない連中の200倍は偉いだろ

234 ：デフォルトの名無しさん：2012/12/04(火) 20:24:42.11

俺にとっては「21世紀のRCS」でしかないが、まあ使ってない奴らよりは少しだけマシ＞VSS

235 ：デフォルトの名無しさん：2012/12/05(水) 01:19:55.57

GitがSVNを駆逐できないのってなんで？マイグレーションパスも用意してるのに。

日本語対応に問題があるのはわかるけど、英語圏でもまだまだSVNが使われてるよね。なんでだろう。

236 ：デフォルトの名無しさん：2012/12/05(水) 03:59:01.72

移行コストに見合うメリットがないからじゃない
SVNで十分とも言える

237 ：デフォルトの名無しさん：2012/12/05(水) 06:28:42.66

オフラインで作業する人がいない

238 ：デフォルトの名無しさん：2012/12/05(水) 07:47:01.05

>>235
gitに移行することよるデメリットの方が大きいから

239 ：デフォルトの名無しさん：2012/12/05(水) 07:50:17.18

デメリットｋｗｓｋ

240 ：デフォルトの名無しさん：2012/12/05(水) 08:01:24.63

>>239
・ファイルのコピー・リネーム
・空っぽのディレクトリ
・ブランチの違い

241 ：デフォルトの名無しさん：2012/12/05(水) 08:47:55.72

それが「大きいデメリット」なんだ、へー

242 ：デフォルトの名無しさん：2012/12/05(水) 09:04:37.69

http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/74676
> Re: Bzr development stopped
>
> I think git is a nice version control system but I could never use it
> because it lacks formal rename support and this is very important as a
> Java developer.

243 ：デフォルトの名無しさん：2012/12/05(水) 10:14:15.24

空っぽのディレクトリは確かに大きなデメリットだ

244 ：デフォルトの名無しさん：2012/12/05(水) 11:29:08.07

ディレクトリに何かファイルを置くというバッドノウハウはあるけどな

245 ：デフォルトの名無しさん：2012/12/05(水) 12:23:21.71

このディレクトリは削除しないでください.txt

246 ：デフォルトの名無しさん：2012/12/05(水) 12:53:47.83

管理させてるソースがGPL汚染されそうで怖いとか？

247 ：デフォルトの名無しさん：2012/12/05(水) 14:13:29.09

IDE組み込みの存在じゃない？
最新のやつを使えない事情があると、svnはあってもgit無かったりするし。

248 ：デフォルトの名無しさん：2012/12/05(水) 14:21:15.47

なんだかんだ言って、Windowsで気軽にgitを使える環境が事実上存在しないのが問題。

249 ：デフォルトの名無しさん：2012/12/05(水) 14:29:56.15

ちょっとググったんだが、WindowsではいまだにmsysGitしか無いのか？

250 ：デフォルトの名無しさん：2012/12/05(水) 15:19:52.26

プログラマーにとってGitは便利だけどデフォルト状態で出来ることが多すぎて、スキルレベルがまばらな多人数チームでの運用は難しい。
プログラマー以外が多い職場ではGUIがまともなSubversionか、分散型ならデフォルトで出来ることが制限されているMercurialを使ってるとこが多いと思う。
個人的にはGitを使ってるけど「Gitだけあれば万能！」って事は今のところ無いと思う。

251 ：デフォルトの名無しさん：2012/12/05(水) 15:27:49.81

>>240
追加
・ユーザーアカウント
・アクセス権制御(フォルダ単位ファイル単位)
・ファイルロック

252 ：デフォルトの名無しさん：2012/12/05(水) 22:50:10.68

単に学習意欲がないからだろ
SVNもコミットとログ閲覧くらいしか理解してない奴ばかりだし

253 ：デフォルトの名無しさん：2012/12/05(水) 23:02:49.19

日常的なワークフローが、コミットとログ閲覧で充分ならSVNから他へ乗り換える理由もないからな。

254 ：デフォルトの名無しさん：2012/12/05(水) 23:21:37.39

それだけをうまくやれるフロントエンドあってもよさそうなもんだけどな
素のインターフェースを使ってもらうとステージングやマージではまってよく呼ばれる

255 ：デフォルトの名無しさん：2012/12/06(木) 01:11:50.49

git submodule では svn:external の代替にならんので移行できずにいる。

256 ：デフォルトの名無しさん：2012/12/06(木) 03:10:49.50

>>250
結局まともなGUIが無いことが大きいんだよな
デザイナにGUIが無いけど機能的にはいい物なんだなんて説得は通用しない

それに対してAlienbrainへの食いつきは凄かった。
まぁMayaやフォトショップ上で過去バージョンが確認出来るとか、
デザイナにとっては有効なものが多いから当然かもしれないけど。

257 ：デフォルトの名無しさん：2012/12/06(木) 13:34:40.60

デザイナが作ればいいじゃん。
作らないでないないとか知らんわ。
プログラマは現状で問題ないし。

258 ：デフォルトの名無しさん：2012/12/06(木) 15:28:41.51

世の中には想像を絶するアホがいるものだなぁ・・・・

259 ：デフォルトの名無しさん：2012/12/06(木) 17:56:33.12

あるコミュニティにとって使いやすいものが別のあるコミュニティにとって使いやすいとは限らないだけのことだろ
M$ならcvsとsvnは恐ろしく使いやすいからな
俺はgitが必要になるようなことやらねえし

3年ほど前だがgitは導入が糞まんどかったが改善されたのか?

260 ：デフォルトの名無しさん：2012/12/06(木) 18:35:02.03

>>259
3年ほど前: apt-get install git-core
今: apt-get install git
大幅な改善！

261 ：デフォルトの名無しさん：2012/12/06(木) 18:54:15.37

>>259
> あるコミュニティにとって使いやすいものが別のあるコミュニティにとって使いやすいとは限らないだけのことだろ
> M$ならcvsとsvnは恐ろしく使いやすいからな
Bazaarは？

262 ：デフォルトの名無しさん：2012/12/06(木) 20:49:13.11

コマンドラインだとなにもできないレベルのにわかコード屋も増えてきてるからなぁ
つってもGitでGUI欲しいならとーたすでいいんじゃないのって気がするけど

263 ：デフォルトの名無しさん：2012/12/06(木) 20:55:24.79

コマンドラインで自慢とかw

264 ：デフォルトの名無しさん：2012/12/06(木) 21:03:39.98

CLI使えない奴には自慢に聞こえてしまうわけですね

265 ：デフォルトの名無しさん：2012/12/06(木) 21:05:12.11

CLI使えない奴には自慢に聞こえてしまうわけですねw

266 ：デフォルトの名無しさん：2012/12/06(木) 21:10:13.53

大事なことなので

267 ：デフォルトの名無しさん：2012/12/06(木) 21:18:17.47

CLI使えない奴には自慢に聞こえてしまうわけですねw

268 ：デフォルトの名無しさん：2012/12/06(木) 21:22:03.32

顔真っ赤ですけど、そんなに悔しかったの？

269 ：デフォルトの名無しさん：2012/12/06(木) 22:06:21.63

mercurialで日本語が使えないという誤解
Winで統一されてるならTortoiseHgが鉄板

270 ：デフォルトの名無しさん：2012/12/06(木) 22:23:11.82

TortoiseHgはTortoise系の中では一番完成度が高いね
日本語ファイル名がUTF8で通るようになったら、Windows系の案件で使ってみたいところ

271 ：デフォルトの名無しさん：2012/12/06(木) 22:25:27.01

>>270
TortoiseSVNよりも？

272 ：デフォルトの名無しさん：2012/12/06(木) 22:30:54.24

>>271
うん
実はTortoiseHgってTortoiseの名前は付いてるんだけど、かなり拡張されててねｗ
別物と思った方がいいｗ

273 ：デフォルトの名無しさん：2012/12/06(木) 22:48:59.61

>>269
ファイル名に「表」だとか「ロ」(カタカナ)が含まれてるとだめなんじゃない?

274 ：デフォルトの名無しさん：2012/12/06(木) 22:53:18.88

>>273
それが誤解

275 ：デフォルトの名無しさん：2012/12/06(木) 22:56:36.30

>273
ディレクトリ名の最後の文字が「表」「申」「能」だとだめだな

276 ：デフォルトの名無しさん：2012/12/06(木) 23:01:05.50

>>275
それが誤解

277 ：デフォルトの名無しさん：2012/12/06(木) 23:54:22.81

Macの日本語ファイル名も大丈夫なの(´・ω・｀)？

278 ：デフォルトの名無しさん：2012/12/07(金) 00:12:49.71

俺の調査では、Subversionユーザのうち、ちゃんとrenameが出来る人は4割、
mergeが出来る人は1割しか居ない。

279 ：デフォルトの名無しさん：2012/12/07(金) 02:41:38.80

うん。
よく「>>>>>」がついたままのファイルがチェックインされてるわ。

280 ：デフォルトの名無しさん：2012/12/07(金) 19:46:42.54

コマンドライン操作って自慢する事だったのなﾜﾗﾀｗ

うちの職場でも、ソースコードの移動やクラス名変更に伴うリネーム時に、
移動とか使わずに削除して追加してたりする奴が後を絶たないわ
酷いやつになると、デバッガの繋ぎ方すらわからず、Alertさせてデバッグ()してる馬鹿もいたりするし…

こんな職場じゃGitとか絶対無理だろうなーって思っちゃう

281 ：デフォルトの名無しさん：2012/12/07(金) 20:22:54.02

＞Alertさせてデバッグ()してる馬鹿
そうやって人を見下す暇があったらだな…(呆

282 ：デフォルトの名無しさん：2012/12/07(金) 20:54:21.87

馬鹿には無理

283 ：デフォルトの名無しさん：2012/12/10(月) 15:12:29.69

printf("ここは通過\n");

284 ：デフォルトの名無しさん：2012/12/10(月) 21:20:16.27

デバッガ繋げる環境でアラートデバッグとかはさすがにないわな。

285 ：デフォルトの名無しさん：2012/12/11(火) 12:41:45.37

>>270
CVS のときも亀が吸収していたし、なんとかしてほしいね。Bazaar は望み薄だし。

286 ：デフォルトの名無しさん：2012/12/11(火) 23:21:01.25

>>277
正規化はもう簡単な解決は諦めて、文字ごとにどれかに寄せて管理することにしないとダメなんじゃないかなぁ……

287 ：デフォルトの名無しさん：2012/12/12(水) 21:21:48.75

>>285
望み薄どころか、Bazaar自体がもう開発終了してる

288 ：デフォルトの名無しさん：2012/12/12(水) 22:57:19.76

ぼくBazaar好きだったんよ(´・ω・｀)しょぼーん

289 ：デフォルトの名無しさん：2012/12/13(木) 15:18:27.07

TortoiseHg の日本語マニュアルだれも更新してないのか？

290 ：デフォルトの名無しさん：2012/12/13(木) 23:15:19.25

簡単すぎていらんだろ

291 ：デフォルトの名無しさん：2012/12/14(金) 16:07:26.26

>>287
Wikipediaより
> 最新版 2.5.1 / 2012年5月30日（6か月前）
> 最新評価版 2.6b2 / 2012年7月24日（4か月前）

終…了？

292 ：デフォルトの名無しさん：2012/12/14(金) 16:48:14.58

それ英語出来ないアホが流したデマ
アンチTDDのロシア人が開発辞めるポストをML
でしただけ

293 ：デフォルトの名無しさん：2012/12/14(金) 17:32:45.35

>>292
http://www.ohloh.net/p/bazaar

294 ：デフォルトの名無しさん：2012/12/14(金) 17:38:41.70

>>292
https://lists.ubuntu.com/archives/bazaar/2012q4/075330.html

Canonicalから大勢人が去って代わりになる人がいない。
フォークする動きも見れないから終了ととらえて良いだろう。

295 ：デフォルトの名無しさん：2012/12/15(土) 09:48:28.83

開発が終了しただけで、使用できなくなるわけでもなければ配布が終わるわけでもない。

296 ：デフォルトの名無しさん：2012/12/15(土) 16:54:10.31

派生元のサブディレクトリと同じに見えるブランチとか
設計がダメすぎるから滅びるのは当然

297 ：デフォルトの名無しさん：2012/12/16(日) 17:19:40.51

かちゅ～しゃ使いから見れば、開発が終了してからこそが本番といえる

298 ：デフォルトの名無しさん：2012/12/16(日) 21:09:52.13

かちゅーしゃ使いだがソース管理はGit派だ
悪いな、俺は先に行くよ…

299 ：デフォルトの名無しさん：2012/12/17(月) 02:50:13.91

Gitなんて7年も前のツールだろ
時代遅れ

300 ：デフォルトの名無しさん：2012/12/17(月) 13:24:45.04

Linuxなんて20年も前のOSだろ
時代遅れ

301 ：デフォルトの名無しさん：2012/12/17(月) 14:39:24.39

やっぱり今はWindows8だね

302 ：デフォルトの名無しさん：2012/12/17(月) 14:52:32.36

■Windows開発新責任者、「Windows 8」UIを語る--「大多数のPCは今後、タッチ技術に対応」
http://japan.cnet.com/news/service/35025790/

やはりこのおばさんが黒幕でしたね

303 ：デフォルトの名無しさん：2012/12/17(月) 17:42:04.70

DOSがウィンドウズの1アプリになったように、デスクトップがウィンドウズの1アプリになった。

しかし、可愛いおばさんだな

304 ：デフォルトの名無しさん：2012/12/17(月) 21:03:51.08

開発責任者が変わるというのは、もうどこのコードのせいか分からなくなって、直せないバグが山ほどできることと同義

305 ：デフォルトの名無しさん：2012/12/17(月) 21:14:30.62

まあ、ドキュメント通りにプログラマがコードを書いているとは限らんしな。

306 ：デフォルトの名無しさん：2012/12/18(火) 15:19:53.90

>>305
それはプログラマを罰するべき話であって

307 ：デフォルトの名無しさん：2012/12/18(火) 16:05:34.97

プロレスラー

308 ：デフォルトの名無しさん：2012/12/20(木) 19:12:28.01

なんでhg qpush失敗してしまうん？

309 ：デフォルトの名無しさん：2012/12/21(金) 11:50:00.15

失敗しないよ

310 ：デフォルトの名無しさん：2012/12/24(月) 22:47:49.64

Git初心者なんだけど、クライアントはsourceTreeでいいんか?
なんか日本語対応されているとか知って使ってみたらもろ機械翻訳なんだけど・・・

311 ：デフォルトの名無しさん：2012/12/24(月) 23:17:35.19

馬鹿には無理

312 ：デフォルトの名無しさん：2012/12/25(火) 00:39:04.30

>>310
bzr-git
http://methane.hatenablog.jp/entry/20111224/1324698755

313 ：デフォルトの名無しさん：2013/01/19(土) 16:36:48.00

Subversion1.8でローカルコミット対応するっていうからｗｋｔｋしてたのに
機能開発が遅延して1.9までおあずけになっちまったようだ・・・。

314 ：デフォルトの名無しさん：2013/01/19(土) 17:22:18.52

だがもううちの職場もGit乗り換えだわ
バイバイSVN

315 ：デフォルトの名無しさん：2013/01/21(月) 14:11:52.54

>>310
ちゃんと翻訳者に投げろと言ってやって下さい。作者が遠慮して機械翻訳で済まそうとするので、
却って手間がかかってたり…^^;

316 ：デフォルトの名無しさん：2013/02/06(水) 21:24:33.93

Android系だとgitとかrepoとか覚えないといけないみたいですね。
とりあえずrepo syncに鬼のように時間がかかっている。

317 ：デフォルトの名無しさん：2013/03/27(水) 22:39:07.84

853 名前：デフォルトの名無しさん [sage]： 2013/03/27(水) 20:39:52.44
Gitの話題なので貼っておこうか…
ttp://cpplover.blogspot.jp/2013/03/kde_26.html

318 ：デフォルトの名無しさん：2013/04/04(木) 21:00:08.42

GitはZFSと合わせて運用しないと危ないZE！ってことだな。
Linusは、OracleのbtrfsをポイしてZFSをくれって言おう！

319 ：デフォルトの名無しさん：2013/05/13(月) 00:07:09.45

VSS6.0はUnicodeファイルを壊す事があるんですか？

320 ：デフォルトの名無しさん：2013/05/13(月) 01:16:00.27

VSSは2005からUnicode対応だったはずだが、それ以前のバージョンでどういう挙動になるかは知らない。

321 ：デフォルトの名無しさん：2013/05/13(月) 07:26:08.00

>>319
バイナリで登録すれば問題ない
テキストで登録すると変な改行が挿入されることがある

322 ：デフォルトの名無しさん：2013/05/13(月) 07:27:16.33

ちなみに変な改行が挿入されるのは
日本語で終了する行のうち
一部の文字で終わる行だけだったはず

323 ：デフォルトの名無しさん：2013/05/13(月) 23:26:54.57

>>321-322
ありがとうございます。助かりました。

324 ：デフォルトの名無しさん：2013/06/22(土) 21:54:33.64

Subversion 1.8.0 age

325 ：デフォルトの名無しさん：2013/07/15(月) NY:AN:NY.AN

バージョン管理のセオリーについて初心者質問いいすか？

branchを作る場合、trunkの作業コピーを置くフォルダと
branchの作業コピーを置くフォルダは分けるべき？

それとも、いろんなバージョンの同名ソースがあちこちのフォルダに
入り乱れるのは混乱の元なので、trunkの作業コピーを削除して
同じフォルダにbranchのファイルをチェックアウトして作業するべき？

326 ：デフォルトの名無しさん：2013/07/15(月) NY:AN:NY.AN

svn?
svn switchでいいんじゃ?

327 ：デフォルトの名無しさん：2013/07/15(月) NY:AN:NY.AN

作業コピーは作業者の好きにしたらいいんじゃねの？

なんとなく、svn, bzr は前者、
hg は後者、って感じがするが…

328 ：325：2013/07/15(月) NY:AN:NY.AN

ありがとうです。使用ソフトはsvnです。
なぜこんなことを聞くかというと、
branchが完成してtrunkにマージする際、
trunkの作業コピーに対してマージが行われると
ヘルプにあったためです。
マージに必要であるということは、trunkの作業コピーは
消してはいけないのでは？と思った次第です。

329 ：デフォルトの名無しさん：2013/07/25(木) NY:AN:NY.AN

亀だが、質問内容が違うやん。

330 ：デフォルトの名無しさん：2013/08/18(日) NY:AN:NY.AN

gitで共有リポジトリの作成とリソースの初期コミットを１回のコマンドでできますか？
やっぱり、初期コミットもローカルリポジトリを作ってからpushするしかないのかな？

331 ：デフォルトの名無しさん：2013/08/20(火) NY:AN:NY.AN

お望みの機能はないけれど(っていうかbareリポジトリは作業ツリー持たないからコミット出来ない)
pushをしない、って目的を達成するだけなら、最初はローカルリポジトリだけで作って、
共有の必要が出た時にcloseして共有するためのbareリポジトリを作るって手もあるよ

332 ：デフォルトの名無しさん：2013/08/21(水) NY:AN:NY.AN

>>331
ありがとう！おかげさまでわかりました！！
私が知りたかったことは、Gitのスマートな共有リポジトリの作り方でした。

今まで、共有リポジトリ作った後にローカルリポジトリを作るという固い頭になってました。
考え方は逆で、ローカルリポジトリで共有リポジトリにしていい状態まで整備して
「$ git clone --bare {ローカルリポジトリパス}」ってやればいいんですね。

closeのスペル違いには「そんなコマンドあったんだ」と騙されましたがｗ。

333 ：デフォルトの名無しさん：2013/08/23(金) NY:AN:NY.AN

typoだ許して

334 ：デフォルトの名無しさん：2013/08/23(金) NY:AN:NY.AN

あと今更だけど、リモートに空bare作っておいて、ローカルで新規にリポジトリ作って、
最初のコミットを行った後にリモートへpushしたほうが多分楽だと思うで

pushならローカル→リモートの通信ができればいいが、リモートからcloneする場合リモート→ローカルの通信必要だから
後者のリモートにローカルをcloneするほうが、前者よりも面倒な事が多いと思う

335 ：デフォルトの名無しさん：2013/10/04(金) 03:08:36.44

コンパイルしたバイナリファイルはバージョン管理に含めないのが普通？

336 ：デフォルトの名無しさん：2013/10/04(金) 03:09:36.48

コードの書き換えでバイナリサイズが減ったか知りたいんだけど
これはバージョン管理システムでやることではない感じ？

337 ：デフォルトの名無しさん：2013/10/04(金) 03:19:38.10

ローカルでやるぶんには好きにやれとしか
公開するならコンパイル後のファイルは含めないのが普通。そもそも環境毎に違うしな

git notesとかそういうのにサイズをメモっていくのはどうだろう

338 ：デフォルトの名無しさん：2013/10/04(金) 04:24:26.87

なるほどね
ありが㌧クス

339 ：デフォルトの名無しさん：2013/10/04(金) 05:11:52.48

一番ナウくてイケてるバージョン管理システムって何ですか？git？hg？

340 ：デフォルトの名無しさん：2013/10/04(金) 08:15:39.24

>>337
> そもそも環境毎に違うしな

コンパイル日時を埋め込んだりするから、環境同じでも異なることが多いよ。

341 ：デフォルトの名無しさん：2013/10/04(金) 11:52:28.87

>>335
うちの場合リリース版だけ入れてる。

342 ：デフォルトの名無しさん：2013/10/04(金) 12:06:06.70

俺は客に出す時にソースとビルド出力一式圧縮して別にコミットしてる

343 ：デフォルトの名無しさん：2013/10/04(金) 14:52:32.83

バイナリは入れないのが普通だろJK
ソースがあるんだからビルドすればバイナリ出来るんだし
そんな事をやっているOSSは見たこと無い

344 ：デフォルトの名無しさん：2013/10/04(金) 14:53:48.92

大体そんなものを入れたらマージする度コンフリクトするだろ

345 ：デフォルトの名無しさん：2013/10/04(金) 14:54:57.75

>>343
> ソースがあるんだからビルドすればバイナリ出来るんだし
これで、いつでも誰でも簡単にリリース時のバイナリを復元できると思ってるなら、考えが甘い。

> そんな事をやっているOSSは見たこと無い
OSS以外の事情は考える気もしないのかな。

346 ：デフォルトの名無しさん：2013/10/04(金) 14:59:24.97

バイナリなんかバージョン番号をつけたzipで良いじゃん

347 ：デフォルトの名無しさん：2013/10/04(金) 15:19:45.49

社内で一部にJNI使ったJavaライブラリを開発使用していて、これに関してはCのコードから
生成されるネイティブバイナリもソースツリーの一部としてバージョン管理に入れている。

これはCの部分を直接触る人は開発チームの中でもごく一部で、他の人は触るにしてもJavaの
コードだけでJNIは必要なネイティブバイナリを落として使えればよいという事情なので。
Cのソースを弄ってVCSにプッシュするとJenkinsがそれを本番環境と同じ環境でコンパイル・
テストしてネイティブバイナリを生成、VCSにプッシュし直している。

ただこれはこのライブラリに限った特殊事情で基本的にリリース版のビルド出力の保存管理
はArtifactoryで行っているかな。

348 ：デフォルトの名無しさん：2013/10/04(金) 15:30:22.31

画像ファイルや音声ファイルもバージョン管理には含めないもの？

349 ：デフォルトの名無しさん：2013/10/04(金) 15:50:12.29

巨大なファイルならともかく、ウェブアプリ等の開発であればページに貼り付ける
固定画像の類は普通はバージョン管理に含めると思う。

上で議論になっているのはバイナリテキストの違いではなく、既にバージョン管理
されているソースファイルから生成できる物もバージョン管理に含めるか否かかな。
実際は事情によって色々。

画像ファイルの件でいえば単にpngやjpeg画像ではなく、それらのエキスポート元で
あるイラストレーターやフォトショップのファイルもバージョン管理に含めている。
画像の修正には必須なので。
他方でpngやjpegはイラレ等の元ファイルからいつでもエキスポート出来るとはいえ
これらをバージョン管理に含めないということは無い。デザイナーさん以外の多数
はエキスポートされたファイルしか必要としていないからね。

350 ：デフォルトの名無しさん：2013/10/04(金) 16:00:24.48

>>346
だよなぁ。
アーカイブなりインストーラなりを、ファイルサーバに置いとけばOK

351 ：デフォルトの名無しさん：2013/10/04(金) 17:25:59.36

>>349
エキスポートって何だよ！！
エクスポートの方が英語の発音に近いだろ
http://ejje.weblio.jp/content/export

352 ：デフォルトの名無しさん：2013/10/04(金) 19:28:00.13

マッスルポーズ

353 ：デフォルトの名無しさん：2013/10/04(金) 21:01:41.66

> バイナリなんかバージョン番号をつけたzipで良いじゃん
ソースなんかバージョン番号をつけたzipで良いじゃん

これを本気で言い出す人がいて困る。

354 ：デフォルトの名無しさん：2013/10/04(金) 22:11:31.40

diffやマージに意味があるかないかの違いがあるだろ

355 ：デフォルトの名無しさん：2013/10/07(月) 13:26:33.39

>>353
VCS使ってても、数日に1回くらいしかcommitしない奴が言いそう

356 ：デフォルトの名無しさん：2013/10/07(月) 14:43:33.76

書きかけのものでもコミットしたほうがいいの？

foo(a + b + bar(c

という感じに開き括弧までは書いたけど(複雑になる予定の)引数や閉じ括弧書いてないのとか
（その日はそこで作業を中断せざるを得なくなった事態が生じたとケースを想定して）

A. この状態でファイル保存とコミットすべき？
B. この状態でコミットはせずファイル保存だけすべき？
C. 書きかけの行を削除してからファイル保存とコミットすべき？
D. 書きかけの行を削除してからコミットはせずにファイル保存だけすべき？

357 ：デフォルトの名無しさん：2013/10/07(月) 14:44:16.42

コミットとは動く状態のソースコードに対してのみ行うべきなの？

358 ：デフォルトの名無しさん：2013/10/07(月) 15:07:01.56

Subversion でいえば trunk は動く状態のみにすべき。ミスはしゃーないけど。
動かないものは branch を切ってそちらへ。分散 VCS ならローカルは好きに、外部には動くものだけ。

359 ：デフォルトの名無しさん：2013/10/07(月) 15:30:02.02

okわかった
ありがと

360 ：デフォルトの名無しさん：2013/10/07(月) 16:02:20.72

自分しか使わないならどうでもいい
他の人も使うならビルドは出来る状態にする

361 ：デフォルトの名無しさん：2013/10/07(月) 17:10:35.87

コンパイル出来ないバージョンを公開することで、他の開発メンバーを混乱させることができる

362 ：デフォルトの名無しさん：2013/10/07(月) 17:44:14.00

しかも会社から解放されて自由になれる

363 ：デフォルトの名無しさん：2013/10/07(月) 18:58:15.29

書きかけの状態を管理したい時ってまぁないなあ

364 ：デフォルトの名無しさん：2013/10/07(月) 20:30:08.41

書きかけとはちょっと違うけど、終電ギリギリでなんとかコミットしようとして
ビルドは出来るけど、くだらない不具合残したままコミットした事がある
条件判定が逆になってるのと、除算の右辺左辺が逆だった

365 ：デフォルトの名無しさん：2013/10/07(月) 21:03:09.27

比較的最近gitスレでそんな話題を見たな
http://toro.2ch.net/test/read.cgi/tech/1369103196/369-387

366 ：デフォルトの名無しさん：2013/10/07(月) 22:12:26.96

終電がコミットの基準になってるとか変なルールだな

367 ：デフォルトの名無しさん：2013/10/08(火) 07:00:50.30

少なくともbranchは切るよな。
まぁでもコンパイル通らないコードもどんどんcommitするなぁ俺は。
個人的には380に同意だわ。

368 ：デフォルトの名無しさん：2013/10/08(火) 11:47:41.22

なんでわざわざ>380にパス出すかなw

369 ：デフォルトの名無しさん：2013/10/08(火) 12:15:45.85

書きかけ中断はGitならstashかcommitして後で修正
Mercurialならmqでパッチ化かな

370 ：デフォルトの名無しさん：2013/10/08(火) 14:26:54.78

>>368
野暮だけど
どう読んでもgitスレの380だろ

371 ：デフォルトの名無しさん：2013/10/08(火) 14:42:11.82

>>370
んなもん、判るかいw

それはさて、bzrで書き掛けなら棚上げ(shelve)だな。

372 ：デフォルトの名無しさん：2013/10/08(火) 14:42:43.67

360のタイプミスかと思ったがそっちの380だったか

373 ：デフォルトの名無しさん：2013/10/08(火) 14:48:40.94

gitはcommitだけじゃ公開にはならんけどpushしたら今までのcommit全部上げられるから書きかけのcommitはそれはそれでどうなの

374 ：デフォルトの名無しさん：2013/10/08(火) 14:49:25.90

>>373
え？

375 ：デフォルトの名無しさん：2013/10/08(火) 15:08:51.05

>>373
イミフ

376 ：デフォルトの名無しさん：2013/10/08(火) 15:41:21.41

俺はわかるけど

377 ：デフォルトの名無しさん：2013/10/08(火) 15:45:15.06

意味わかってるからこその「何言ってんのコイツ」

378 ：デフォルトの名無しさん：2013/10/08(火) 15:52:47.80

日本語の文章としておかしいのに意味分かるとかエスパーかよ！

379 ：デフォルトの名無しさん：2013/10/08(火) 16:12:38.84

squashしてからpushすればいいよ

380 ：デフォルトの名無しさん：2013/10/08(火) 16:40:48.41

> gitはcommitだけじゃ公開にはならん
> pushしたら今までのcommit全部上げられる
> 書きかけのcommitはそれはそれでどうなの

どこの意味が分からないんだろうか。

381 ：デフォルトの名無しさん：2013/10/08(火) 18:56:49.60

書きかけのcommitを放置したままpushするってそれはそれでどうなの

って言いたいんだが……

382 ：デフォルトの名無しさん：2013/10/08(火) 19:02:23.26

ミスではなく意図的にそんなことやっている事例があるのなら教えてほしい
少なくとも>>365で参照されている範囲では読み取れない

383 ：デフォルトの名無しさん：2013/10/08(火) 19:24:41.34

najeira: Gitの運用ルール、ワークフローを考えてみた 2
ttp://najeira.blogspot.jp/2013/04/git-2.html

>好きなタイミングでコミットしてよい。
>この時、そのコミットがテストされた状態である必要はない。
>ブランチでは、デプロイ可能な状態を常に保つ必要はなく、あくまで、masterにマージする段階でテストされていればよい。

384 ：デフォルトの名無しさん：2013/10/08(火) 19:33:11.21

> masterにマージする段階でテストされていればよい。

385 ：デフォルトの名無しさん：2013/10/08(火) 19:40:25.22

とどのつまり

386 ：デフォルトの名無しさん：2013/10/08(火) 20:40:05.64

Linuxのワークフローと同じじゃないか
masterにマージするのは権限を持つものだけが行なえる
みんなmasterを改変できる権限を持つから取り決めが必要になる

387 ：デフォルトの名無しさん：2013/10/08(火) 20:50:50.93

一部分だけ変更できる権限とかを各人に与えられるようになるといいのにね

388 ：デフォルトの名無しさん：2013/10/08(火) 20:54:44.90

gitならsubmoduleに分けて、それぞれ権限を分割すればいいんじゃね？

389 ：デフォルトの名無しさん：2013/10/08(火) 22:36:51.63

>>373
全部じゃなくて一部だけpushすればいいだろ

390 ：デフォルトの名無しさん：2013/10/09(水) 03:06:16.04

まあついpushしちゃうこともあるから
ちょっと長めの修正作業になるときなんかは
pushするブランチから別のブランチを切ってそこで適当にコミットしながら作業
公開してもいい状態になったらコミットを整理整頓しながらpushするブランチにマージ
その後pushとかすればいいんでない

391 ：デフォルトの名無しさん：2013/10/09(水) 21:56:42.51

Subversionがさっさとshelveを実装しないから・・・。
1.8で実装されるはずだったのに。

392 ：デフォルトの名無しさん：2013/10/11(金) 15:12:51.99

Java SE 7 パッケージバージョン識別関連 API & 開発者ガイド
http://docs.oracle.com/javase/jp/7/technotes/guides/versioning/index.html

393 ：デフォルトの名無しさん：2013/10/21(月) 19:33:59.42

今まで、ひとりで自己流でWebサービス作って来たんだけど、
１人で開発するときでもGitみたいなバージョン管理システム
って必要あるの？
先祖返りとか上書きの予防なら、Dropboxだけでもいいような。

394 ：デフォルトの名無しさん：2013/10/21(月) 19:38:02.04

コミットメッセージを適当に書く奴には価値がわからない

395 ：デフォルトの名無しさん：2013/10/21(月) 19:49:38.14

>>394
ああ、なるほど。
Gitは、どこを誰がどう直したかを全部記録しておくためのツールなのか。
ソース内のコメントでやろうとすると、ごちゃごちゃになりがちだし。

396 ：デフォルトの名無しさん：2013/10/21(月) 19:55:11.35

今俺何修正したっけ？ってのを簡単にdiffとるために使ってる

397 ：デフォルトの名無しさん：2013/10/21(月) 20:22:37.99

コメントにごちゃごちゃ履歴を書いてるのって絶対に古いバージョンに戻らない。
ときにはコンパイルすら通らない。

398 ：デフォルトの名無しさん：2013/10/21(月) 20:22:48.20

何か問題が起きたときに、以前のバージョンで正常に動いていたなら
正常だったときのコードを取り出して比較できるので
いつから問題が発生したのか、どこをどう直したせいなのか調べるのに役に立つ

399 ：デフォルトの名無しさん：2013/10/22(火) 08:23:51.09

>>393
正直、好きにしたらいいと思う

400 ：デフォルトの名無しさん：2013/10/22(火) 10:38:37.87

>>395
社内プロダクトで、プログラマは実質俺一人な場合があるけど、そういう時でもTicket切って
コミットコメントにはrefs #1234とか書いて、Redmineと統合してる。

401 ：デフォルトの名無しさん：2013/10/22(火) 11:43:27.53

未来の自分のためにツール使っとくのがいいよね……

402 ：デフォルトの名無しさん：2013/10/22(火) 13:23:05.58

つうかよくバージョン管理無しでコード書けるな。
って思うよ。使い方わかると。
バージョン管理無しでコード書くのはセーブなしで RPG やるようなもんだ。

403 ：デフォルトの名無しさん：2013/10/22(火) 13:38:10.91

>>402
うちの会社の別チームは、たまに「先祖返りがー」とかまだ言ってる。
一応ことあるごとにSCMを導入しろと言ってるんだが、聞く耳持たない。
そのチームはリリースミスもたまにやらかすわ。

404 ：デフォルトの名無しさん：2013/10/22(火) 14:07:25.67

>>400
一人自営だが、全く同じ
これは依存症かもしれんが、もうRedmineとSVN無いと不安で仕事できないな

>>403
理解できない人には駄目みたいね
客先に打合せ行った時に「最新のソース下さい」とか言ってるの漏れ聞くと、もうアホかとバカかと

別の会社で協業した時には俺が半ば無理矢理VSSを導入させたんだが、
数年後に訪れて見た別案件では1ヶ月前に全ソースチェックアウトしたままで作業してた
途中何度もリリースしてるのにもう完全放置状態

405 ：デフォルトの名無しさん：2013/10/22(火) 14:26:10.21

SCM（も自動テストも）をやってない人達が言いがちなセリフ：

「前はちゃんと動いてたはずなんだけど・・・」

前に戻ることもできないし、テストもできませんから。

406 ：デフォルトの名無しさん：2013/10/22(火) 14:38:22.74

過去のコードが全部コメントで残ってたりするわけだｗ

407 ：デフォルトの名無しさん：2013/10/22(火) 14:44:47.27

>>406
それを強要してくるクライアントも未だ未だ多いよ。
履歴と過去のコードを全て消したら1/3になったりする。

408 ：デフォルトの名無しさん：2013/10/22(火) 19:32:33.06

>>406
そして、そのコメントアウトした過去のコードが
同じ箇所に色んな日付のコードが混じったり
同じ日の変更が多数のファイルに渡ってて
特定の日付の状態を再現するだけで小一時間掛かって
やっと戻ったと思ったらあれれ動かない、と
戻す作業ミスったかな？と思って原因調べていったら
実は戻しの作業はミスってなくて自社ライブラリのバージョンだったりするんですね

409 ：デフォルトの名無しさん：2013/10/22(火) 20:42:58.41

昔、バージョン管理ソフト導入しているのに
コメントで履歴を残しているプロジェクトに遭遇したことあるけど
誰も不思議に思わなかったのかなぁ

410 ：デフォルトの名無しさん：2013/10/22(火) 22:18:57.89

You can't be serious!

411 ：デフォルトの名無しさん：2013/10/23(水) 15:33:29.49

エクセルで管理してる情報が面倒なんだよなぁ
マージとかができないし……

412 ：デフォルトの名無しさん：2013/10/23(水) 15:47:01.85

>>409
あえて残すことはあるな。

413 ：デフォルトの名無しさん：2013/10/23(水) 22:57:17.81

>>411
csvで済まないの?

414 ：デフォルトの名無しさん：2013/10/24(木) 08:01:34.01

>>412
理由は？

旧来のやり方しか知らないリーダーの説得に疲れはてたとか、そう言うポリシーのお客さんのコードは修正してるとか、辺りしか思いつかない。

415 ：デフォルトの名無しさん：2013/10/24(木) 08:10:33.87

何かしらの理由でバージョン管理システムのデーモンが稼働してるサーバに繋げられない時でも
ロールバックが出来るっていうメリットはある

416 ：デフォルトの名無しさん：2013/10/24(木) 08:12:53.93

投げ捨てろよそんな中央集権システム

417 ：デフォルトの名無しさん：2013/10/24(木) 08:17:35.32

>>413
Excel で管理したがる人って下手すると内容よりフォーマットに凝ってたりするし...

418 ：デフォルトの名無しさん：2013/10/24(木) 08:20:05.00

>>415
コメント頼りにロールバック？
日付フォルダ管理の方がマシじゃね？

419 ：デフォルトの名無しさん：2013/10/24(木) 08:27:00.31

>>415
分散型ならローカルで戻すだけだと思うがな

420 ：デフォルトの名無しさん：2013/10/24(木) 08:52:04.72

>>409
ファイルを選択して履歴を見れば良い

と誰も思わなかったのが不思議

421 ：デフォルトの名無しさん：2013/10/24(木) 12:49:02.88

>>414
クソ仕様のクソコード引き継いだとき残したな。
しかも一から書き直せないとか。
何が合ってるんだか合ってないんだか曖昧みたいな。
ブランチの差分だと、変更点が多くなってくると辛くなってくるじゃない。
普通の仕事だとまずないけど、極端なケースだと無くはないって感じ。
何かいい方法ないかな。

422 ：デフォルトの名無しさん：2013/11/02(土) 16:50:29.20

sjisのtexと
utfのtexを統一してバージョン管理する方法ないですか？

423 ：デフォルトの名無しさん：2013/11/02(土) 21:14:02.55

>>422
gitの思想としてはrepositoryに保存されるのはバイト列であって処理する方で加工しろということだと思う
適当なフィルタを通せばいいんじゃないかな？

<.gitattributes>
*.tex diff=nkf show=nkf blame=nkf

<.gitconfig>
[diff "nkf"]
textconv = nkf -w -d
[show "nkf"]
textconv = nkf -w -d
[blame "nkf"]
textconv = nkf -w -d

424 ：423：2013/11/02(土) 21:15:06.40

すまんgitスレだと勘違いしてたわ

425 ：デフォルトの名無しさん：2013/11/15(金) 04:04:39.35

個人開発でバージョン管理ソフトを使う場合
開発のどの段階からバージョン管理ソフトを導入したらいいの？
まだファイルもない開発の始めから？アルファ版が出来たくらいから？
それともベータ版やリリース版が出来きたくらいから？
それとも実験的な改造したくてブランチ切って作業したくなったとき？

426 ：デフォルトの名無しさん：2013/11/15(金) 07:10:10.28

>>409
プログラムでソースを解析する時に目印が有ると楽じゃん

427 ：デフォルトの名無しさん：2013/11/15(金) 11:15:44.38

>>425
自分は最初から
この実装糞だからやっぱやめるわ、となった時に捗る

428 ：デフォルトの名無しさん：2013/11/15(金) 11:28:47.85

俺も最初からだね
たとえソフトの開発を途中で諦めて完成しなかったとしても
後々別のソフトを開発するときにコードの一部を再利用できるかもしれない
そんなに容量取るもんじゃないし
少しでも書いたものはバックアップも兼ねてリポジトリに放り込んでおく

429 ：デフォルトの名無しさん：2013/11/15(金) 17:33:15.11

同じく。空っぽの関数書いただけでもとりあえずコミットしておく。

430 ：デフォルトの名無しさん：2013/11/15(金) 17:34:52.54

「コミット」の意味が、svnユーザとgitユーザでちょっと違う

431 ：デフォルトの名無しさん：2013/11/15(金) 18:17:38.66

どう違うんだい？

432 ：デフォルトの名無しさん：2013/11/15(金) 18:42:16.33

>>425
途中から使い出す理由が思いつかない

433 ：デフォルトの名無しさん：2013/11/15(金) 19:10:59.96

svnでのコミットは
gitでは公開リポジトリへのpushに相当するのかな

434 ：デフォルトの名無しさん：2013/11/15(金) 19:19:32.22

それはちょっとどころじゃないね

435 ：デフォルトの名無しさん：2013/11/15(金) 21:23:09.71

gitでのコミットはローカルリポジトリへのコミット
gitでのaddはコミット対象の追加

http://www.backlog.jp/git-guide/reference/basic.html
add:
-p オプションを付けると、ファイルの変更箇所の一部のみを登録することができます。

これsvnに入ったらしいね

436 ：425：2013/11/16(土) 00:30:20.28

>>427-432
参考になりました
ありがとうございました

437 ：デフォルトの名無しさん：2013/11/16(土) 13:40:35.94

>>432
と言うか、途中まで使わない理由がわからん

438 ：デフォルトの名無しさん：2013/11/16(土) 14:23:39.80

バージョン管理システムの存在を知っていて、いつでも導入可能の状態であるのに、「開発の途中から使う・開発の途中まで使わない」理由が分からない

という意味です

439 ：デフォルトの名無しさん：2013/11/16(土) 14:25:12.51

バージョン管理システムの存在を全く知らなかった人や、システムの導入が困難な状況にあった人が、「開発途中から使い始める・開発途中まで使ってない」理由が分からないわけではないのです

440 ：デフォルトの名無しさん：2013/11/16(土) 14:39:48.92

cvsや昔のsvnだとディレクトリの再構成やりにくいしサーバー設定いるしで
概形はかたまってからバージョン管理始めたいって気持ちも分かる

gitやhgだとなんかするときにまずgit initしときゃいい

441 ：デフォルトの名無しさん：2013/11/16(土) 19:03:38.11

>>440
> 昔のsvnだとディレクトリの再構成やりにくいし

いつの話だよ...

> サーバー設定いるし

レポジトリはローカルファイルシステムにも作れるぞ

442 ：デフォルトの名無しさん：2013/11/16(土) 20:13:57.27

>>433
個人でローカルリポジトリでやるならコミットに差は無いのでは？

443 ：デフォルトの名無しさん：2013/11/16(土) 20:16:59.23

ローカルで1人でも差分管理が楽だからやる価値はある

444 ：デフォルトの名無しさん：2013/11/16(土) 21:19:37.35

>>442
gitのローカルリポジトリへのコミットは
後でコミットを複数に分解したり複数のコミットをひとつにしたり
もしくは内容自体を修正するつもりで作ってもいいからね
svnの場合はローカルリポジトリ用意してもそういう使い方は面倒

445 ：デフォルトの名無しさん：2013/11/16(土) 21:26:30.84

ブランチ切っときゃ何やったってダイジョウブだろん

446 ：デフォルトの名無しさん：2013/11/16(土) 21:36:21.70

一人でやるならsvnよりgitやhgのが手軽だよな
会社の縛りでもない限り、もはやsvnの意味無しだね

447 ：デフォルトの名無しさん：2013/11/16(土) 21:56:10.35

capistrano 3 がsvn対応を外した(後回しにした?)のが個人的には印象深い。

448 ：デフォルトの名無しさん：2013/11/16(土) 22:06:13.67

>>445
svnは最近触ってないけどコミットのrebaseは出来るようになったのん？

449 ：デフォルトの名無しさん：2013/11/17(日) 02:51:42.07

リポジトリをdropboxにおけばいろいろ楽チンだよう、まあお一人様でやっているからだけど

450 ：デフォルトの名無しさん：2013/11/17(日) 03:21:30.14

自動同期とかなんか怖いんだよねdropbox、だから導入できないわ。

451 ：デフォルトの名無しさん：2013/11/17(日) 03:22:36.18

だからオープンソース用のリポジトリサービスでいいかなって

452 ：デフォルトの名無しさん：2013/11/17(日) 03:25:47.10

「dropbox リポジトリ」でググると結構あるね

453 ：デフォルトの名無しさん：2013/11/17(日) 03:32:10.70

dropbox使ったgitリポジトリの話多いけど、ローカルに同じリポジトリを２つ保持するってことになるのか？

454 ：デフォルトの名無しさん：2013/11/17(日) 04:07:43.94

Dropbox+hgならやってる

ローカルに同じリポジトリが2つあるんだけども
Dropbox側はinitはするが、生ファイルが必要無いので.hgだけだな

gitで同じかどうかは知らん

あと、俺はDropbox使用マシンが全て常時接続してるからいいが
同期が切れるマシンが存在するなら
Dropbox同士でコンフリクト起こした場合が面倒そうだなw

455 ：デフォルトの名無しさん：2013/11/17(日) 08:08:33.35

Dropbox+bzr なら checkout/bind 使ってリポジトリ１つで push/pull なしでも運用できる。

通信気になる環境なら unbind で切り離して、何回か comitt した後でまとめて push できる。

割としょっちゅう「これ bind されてるっけ？」って気が気でなくなるので、お勧めできないが…

456 ：デフォルトの名無しさん：2013/11/17(日) 11:09:49.14

その点、bzrなら融通が利くじゃんw

457 ：デフォルトの名無しさん：2013/11/19(火) 04:36:22.15

一人で使う場合、ブランチ作るまでもないから、GitやMercurial使う必要性あまりない

458 ：デフォルトの名無しさん：2013/11/19(火) 04:44:24.63

途中までやってて、「やっぱこれらの変更全部なし」にしたいってとき、ブランチ捨てるだけってのは簡単なんじゃないの
前のリビジョンとかまでに戻すのって結構簡単なん？

459 ：デフォルトの名無しさん：2013/11/19(火) 05:50:25.34

ローカルのみで使う場合とか一人で使う場合はなおさらGitやMercurialを使うデメリットが
思いつかない。

460 ：デフォルトの名無しさん：2013/11/19(火) 06:54:49.37

>前のリビジョンとかまでに戻すのって結構簡単なん？

そんな難しくはないけど、
でもブランチにしておいて「もうやーめた」と放っておく方がなお簡単。
とにかく何かするときにはとりあえずブランチって習慣にしてればだけど。

461 ：デフォルトの名無しさん：2013/11/19(火) 09:38:00.49

>>459
ローカルで1人だとIDEに統合されてるやつがいいね

462 ：デフォルトの名無しさん：2013/11/19(火) 09:52:35.48

>>461
つまり、IDEに組み込めるgitやbzrがいいわけですね?w

463 ：デフォルトの名無しさん：2013/11/19(火) 10:42:21.67

しかしIDEはまだまだタコなとこ多いから、結局専用アプリとコマンドライン併用になりがちなんだよなー

464 ：デフォルトの名無しさん：2013/11/19(火) 11:37:00.53

Dropbox+hgはやってるわ、Dropboxが自動pullとバックアップしてくれてると思うと便利
誰か、Dropboxの代わりにBittorrent Sync使ってる奴は居ないのかな？

465 ：デフォルトの名無しさん：2013/11/19(火) 12:00:43.63

それはsvnに加えてgitやmercurialに習熟してる場合だろ
ブランチを使わない作業フローなら、svnから移行するメリットない

466 ：デフォルトの名無しさん：2013/11/19(火) 14:32:31.56

>>465
そう言われればそうだわな

467 ：デフォルトの名無しさん：2013/11/19(火) 14:53:21.99

>>465
まぁそれもgitやhg以前に既にsvnに習熟していてブランチ切らない縛りがある場合。

これからバージョン管理を使ってみようという人であれば今更あえてsvnを選ぶメリットも無い。
作業フローについてもブランチをガンガン切るやり方から初めても良いよね。

468 ：デフォルトの名無しさん：2013/11/19(火) 14:59:31.78

>>467
svnの中央集中リポジトリ型の方がシンプルで布教しやすいというメリットは依然としてある。

469 ：デフォルトの名無しさん：2013/11/19(火) 15:07:39.18

(え～)

470 ：デフォルトの名無しさん：2013/11/19(火) 15:36:43.38

gitはgit initするだけでどこでもすぐ使えるんだけどsvnもそんな感じなの？

471 ：デフォルトの名無しさん：2013/11/19(火) 16:05:36.61

hgもhg initするだけでディレクトリがバージョン管理下に入るな。

svn・・・svnadmin?

472 ：デフォルトの名無しさん：2013/11/19(火) 16:50:01.65

巨大バイナリを扱うならsvnしか選択肢がないだろ
もちろん分散も含めてハイブリッド環境にするべきだろうけど

つうか、ホントにsvnを知らないアフォが増えてきたな・・・

473 ：デフォルトの名無しさん：2013/11/19(火) 16:58:14.29

gitだけで別に困らないし

474 ：デフォルトの名無しさん：2013/11/19(火) 17:00:05.21

巨大バイナリをバージョン管理するのなんてやめてgitやhg使ったほうがいいよ

475 ：デフォルトの名無しさん：2013/11/19(火) 18:12:00.65

バイナリ扱うならSVNでも無理だ
有料になるけどAlienbrainどうよ

476 ：デフォルトの名無しさん：2013/11/19(火) 19:03:54.49

ファイルサイズが大きくなるようなバイナリフォーマットは
大抵元から圧縮がかかってるんで、
SVNのメリットが出てこないんだよね。

SVNで管理できる程度のバイナリなら、gitでも管理できる。

477 ：デフォルトの名無しさん：2013/11/19(火) 21:02:48.76

入門やとっかかりの話をしていたところが急に特殊ケースを持ち出してがんばる人がでてきたでござる。

478 ：デフォルトの名無しさん：2013/11/19(火) 21:56:08.02

>>476
SVNは巨大ファイルでもメモリーをあまり食わない。他のはたいていファイルサイズ以上の
メモリーを食う。だからと言ってSVNを進んで使おうとは思わないが。

479 ：デフォルトの名無しさん：2013/11/19(火) 22:09:20.74

クライアントの話？

480 ：デフォルトの名無しさん：2013/11/20(水) 00:06:36.76

gitとかの分散型の方がより高機能なのは確か
だが、subversionのような中央集権型の方が分かりやすいというメリットは大きい

481 ：デフォルトの名無しさん：2013/11/20(水) 00:25:40.31

なんかループしてるぞ

482 ：デフォルトの名無しさん：2013/11/20(水) 00:50:50.24

個人でやるなら好きなほうを使えばええ
組織でやるならトップの決めたほうに従えばええ
おまえさんが組織のトップなら・・・

483 ：デフォルトの名無しさん：2013/11/20(水) 04:28:36.93

>>458
Mercurial はどこからでも枝生やせるし、どこにも push してないなら mq で消せる。
最近は push しててもフェーズ変更できるみたいだけど。
まあ自分は失敗もひとつの歴史としてそのままにしとくけど。思いがけず役立つ時があるかもしれないし。

484 ：デフォルトの名無しさん：2013/11/20(水) 04:51:53.49

全然分かってない人に説明するコストは、依然としてSubversionが最も低い。

485 ：デフォルトの名無しさん：2013/11/20(水) 06:33:17.82

初学者が実作業を通じて独習する場合もsvnよりGitやMercurialの方が良い気がしている。
まずローカルで独習する場合はpushやpullが不要なので分散型特有の面倒は無い。

で、一本のブランチにただコミットするだけならさして難しくはない。しかしコミット
だけ出来てもあまり役に立たない。集中型だろうが分散型だろうが一番悩ましくて故に
実体験から学んでおいてほしいのはむしろマージなんだよね。

しかし他の人との共同作業ならともかく一人で一本のブランチにコミットするだけだと
マージをする機会が極端に少ない。

なので出来れば分散型云々とは別としてもまずトピックブランチを切って後でメインに
マージする開発スタイルを試してみることで、マージの回数を一度でも多くこなして
みると良いんじゃ無いかと思う。
となるとブランチの扱いに長けたgitやhgの方が学習効率もよいのではないかと。

486 ：デフォルトの名無しさん：2013/11/20(水) 07:51:20.28

ドキュメントも全て差分取るのが普通だよね？

487 ：デフォルトの名無しさん：2013/11/20(水) 08:31:53.80

ソース等から生成するのは管理対象外
オフィスドキュメントは校閲機能使って管理対象外

全てとか気軽に言っちゃう奴の普通は知らん

488 ：デフォルトの名無しさん：2013/11/20(水) 16:12:28.91

>485
いや、実体験として、Subversionはデザイナとかでもすぐ使えるようになるが、
GitとMercurialはプログラマでも無理な人は無理。教えるのは苦行だよ。

>487
ビルド成果物でも、「3年後に他人が1時間でビルド出来そう」と思えなかったら
入れる。悩ましいところだが。

489 ：デフォルトの名無しさん：2013/11/20(水) 17:00:14.96

>>488
これも実体験として語るけれども、新人やインターンにMercurialを教えることを
結構な回数こなしてきたけれども極端に難しいことは無かったなぁ。
GitやMercurialが無理なプログラマというのもちょっと想像出来ない。

ただ目的はVCSを教えることではなく、VCSはあくまで道具で目的はそれを使った
開発フローの回し方を教えることなんだよね。
チケットもらってブランチ切ってからマージされてクローズするまで、フローの
中の一連の作業で使うhgのコマンドはある程度決まっているから最初のとっかかり
は別に難しくは無い。あとは実作業を通じてMercurialそのものの使い方の理解を
深めていってもらえば良い、みたいな。

マージに関してはsvnだろうがDVCSだろうが悩みどころだと思う。コンフリクトの
解決がいい加減な人は本当に困る。

490 ：デフォルトの名無しさん：2013/11/20(水) 17:09:34.23

>>489
> GitやMercurialが無理なプログラマというのもちょっと想像出来ない。

なんかこういうこと言う人嫌い。

491 ：デフォルトの名無しさん：2013/11/20(水) 17:13:11.71

自分が想像できない世界は存在しない事にするのが一番楽

492 ：デフォルトの名無しさん：2013/11/20(水) 17:36:34.19

普通に勉強すれば大抵は使えるようになるってこと。

493 ：デフォルトの名無しさん：2013/11/20(水) 17:38:45.29

できるようになるまで普通に勉強できない人もいる

494 ：デフォルトの名無しさん：2013/11/20(水) 17:39:23.79

人間には超えられない能力差があるもんです
あなたは真面目に勉強すれば医者にでも法律家にでも官僚にでもなれるんですか？違いますよね
普通に勉強したって出来ることには個人差があります

495 ：デフォルトの名無しさん：2013/11/20(水) 18:24:26.75

スイッチオン

496 ：デフォルトの名無しさん：2013/11/20(水) 18:27:45.35

まあでも、git程度も使えない奴をプロのプログラマとは認めたくないよな

497 ：デフォルトの名無しさん：2013/11/20(水) 18:32:17.98

世の中、金を払ってプロを名乗るような世界もあるんです
能力が無くたってプロを名乗ってもいいじゃないですか

498 ：デフォルトの名無しさん：2013/11/20(水) 22:41:46.51

cvs/svnより、git/hgのが学びやすいと思う
ディレクトリを対象にできるrcs、って感じのお手軽な使い方ができるのが良い
そりゃもちろん、push/pullまで修得してこそ本領発揮なんだろうけどさ

499 ：デフォルトの名無しさん：2013/11/20(水) 22:49:04.92

ソースコード中のコメントで誰々が変更しましたなんてやってる連中にSVNで新しい
プロジェクトを始める方法を教えるなんて嫌だ。

500 ：デフォルトの名無しさん：2013/11/20(水) 22:50:49.91

プログラムで修正担当者がわかるからコメントは必須だろバカ

501 ：デフォルトの名無しさん：2013/11/21(木) 00:04:29.65

バージョン管理が要らない画期的システムだな

502 ：デフォルトの名無しさん：2013/11/21(木) 00:22:31.07

ブランチはフォルダでいいな

503 ：デフォルトの名無しさん：2013/11/21(木) 00:29:16.59

誰かと共同で何かするんじゃなくて、一人自宅で使うつもりで、とりあえず
http://www.backlog.jp/git-guide/
を読みながら Git (Windows)を使い始めてみようと思うんだけど、
1.8 系で始めるのと 1.7系で始めるのどっちが良い？
上記のサイトでは 1.7系っぽいので合わせたほうが無難なのか
最初から 1.8系で行ったほうが良いのか。

504 ：デフォルトの名無しさん：2013/11/21(木) 00:33:36.32

つまり、1.7系と1.8系の違いが知りたいと

505 ：デフォルトの名無しさん：2013/11/21(木) 00:46:28.85

そうですね。最終的には 1.8系ということに落ち着くんでしょうけど、
1.8系の新しい方から始めても大きく戸惑うようなことが無いのか、
ガラッと変わってるから 1.7系で取っ掛かりを掴んだほうが良いのか
その辺の状況がわかれば。

506 ：デフォルトの名無しさん：2013/11/21(木) 02:05:02.23

大した違いはないから1.8にしとけ

507 ：デフォルトの名無しさん：2013/11/21(木) 04:06:12.13

gitは特定のファイルに対する変更追いづらいな
玄人のお前らはそんなのどーしてんの?

508 ：デフォルトの名無しさん：2013/11/21(木) 04:07:04.55

IDE上でShow history

509 ：デフォルトの名無しさん：2013/11/21(木) 04:31:25.43

GitHub上で更新頻度の多いファイルを開いたのBlameやらHistoryやらでそのファイルの細かい更新見られるし、
おそらくgitコマンドにそういうのあるんじゃないの？もしくはgitのGUIクライアントにそういう機能があったりするんじゃないの

510 ：デフォルトの名無しさん：2013/11/21(木) 04:33:47.32

こういう感じ
ファイル
https://github.com/hub2ch/hub2ch/blob/master/README.md

Blame
https://github.com/hub2ch/hub2ch/blame/master/README.md

History
https://github.com/hub2ch/hub2ch/commits/master/README.md

511 ：デフォルトの名無しさん：2013/11/21(木) 04:38:25.18

一応msysgitでもしょぼいがファイル単位の変更履歴見られるけど

512 ：デフォルトの名無しさん：2013/11/21(木) 07:49:37.57

>>506
ありがとう、1.8系ではじめてみる。

513 ：デフォルトの名無しさん：2013/11/21(木) 09:20:54.95

普通に
$ git log README.md
$ git blame README.md
とは違うのか？

514 ：デフォルトの名無しさん：2013/11/21(木) 09:31:41.24

Atlassian SourceTreeええな。

515 ：デフォルトの名無しさん：2013/11/21(木) 21:45:28.10

【ネット】 GitHubに「総当たり」攻撃、安易なパスワードが破られる…セキュリティ対策を強化へ
http://uni.2ch.net/test/read.cgi/newsplus/1385019870/

516 ：デフォルトの名無しさん：2013/11/23(土) 15:46:39.29

>>514
git/Hg両対応のSourceTreeがMac/Win版揃っちゃったせいでもう新規でSVN使う理由無くなっちゃったな
「うちのデザイナーはLinux使ってるんです＞＜」な奴このスレにはおらんだろうし

517 ：デフォルトの名無しさん：2013/11/24(日) 02:14:56.73

若いヤツに辛抱強くGit教えてたんだけど、あまりに理解しないんでこりゃもうダメだなって
諦めてたんだけど（まあ何やらしても基本ダメなヤツだし）
最近になって急に意味が分かってきたみたいで、驚いてる。

たぶん、Subversionを先に覚えちゃうと、分散型は逆に理解しずらいのかもしれない。
デザイナーとかにも少しずつGit使ってもらうようにしてるんだけど、どうしてもsvnで言うとアレ、
みたいにしてやってしまうようで、それが却って障壁になってるんだと思った。
で、彼は長い時間かけてやっとsvn思考の呪縛から開放されて、新しいことを覚える気になったらしい。

518 ：デフォルトの名無しさん：2013/11/24(日) 05:30:29.85

分散型でもGitは特に分かりづらい

519 ：デフォルトの名無しさん：2013/11/24(日) 05:47:18.88

他の分散型は差し置いてGitが急速に普及しつつあるのは何故か

520 ：デフォルトの名無しさん：2013/11/24(日) 08:20:46.12

>>519
ニワトリが先か卵が先かみたいな話になるかもしれないけど、オープンソースの世界で Github を使うことが多くなっている影響もあると思う
採用試験の時に、あなたの Github を見せてくださいっていうこともあるみたいだし

521 ：デフォルトの名無しさん：2013/11/24(日) 12:43:36.51

Linuxで使われてるからだろうな
それとGithubの影響

522 ：デフォルトの名無しさん：2013/11/24(日) 15:43:51.00

>>521
俺もこの2点に尽きると思う
会社で分散型使うなら正直hg押しだわ

523 ：デフォルトの名無しさん：2013/11/24(日) 16:25:52.90

日本だとGitHubがRailsで作られてる影響もあるだろうな
海外だとFacebookもgitからhgに移行してると社員が言っているし

524 ：デフォルトの名無しさん：2013/11/24(日) 17:13:39.85

svnの退潮とgitの流行はSourceForgeの退潮とGitHubの流行とも関連していると思うな。

どっちが卵でどっちがニワトリか判然としないけど。

525 ：デフォルトの名無しさん：2013/11/24(日) 20:17:09.86

GitHubたんもSourceForgeをオススメしてるんだよ

https://help.github.com/articles/distributing-large-binaries

526 ：デフォルトの名無しさん：2013/11/24(日) 21:27:00.17

ストレージコストのかかる用途を体よくSFにオフロードしているようにしか見えんw

527 ：デフォルトの名無しさん：2013/11/24(日) 21:48:57.54

>>427-432
gitとかを使う場合は作業開始からブランチ切ってやるの？それともずっとmasterブランチ？

528 ：デフォルトの名無しさん：2013/11/24(日) 22:15:45.64

作業ブランチは毎回つくる
切りが良いところでmasterにmerge

529 ：デフォルトの名無しさん：2013/11/24(日) 23:21:18.23

gitだと気にせず後からブランチにしてmasterは巻き戻すとかできるから
複数作業が混ざらないようにしてれば適当でもいいよね

530 ：デフォルトの名無しさん：2013/11/25(月) 01:30:13.93

>>528-529
なるほど、参考になったサンクス

531 ：デフォルトの名無しさん：2013/11/25(月) 13:56:03.23

>522
俺も、会社で使うならMercurialの方が向いてると思う。
Subversion脳からの移行も、gitより簡単だし。

532 ：デフォルトの名無しさん：2013/11/25(月) 15:37:54.89

multiple heads でハマるんですね。

533 ：デフォルトの名無しさん：2013/11/25(月) 15:50:50.80

同一ブランチに同時に複数人が変更をコミットした状態の表現としてマルチヘッドは有る意味
自然だと思うのね。

534 ：デフォルトの名無しさん：2013/11/25(月) 16:45:45.51

>>533
> 自然だと思うのね。

俺は全くそうは思わない。

535 ：デフォルトの名無しさん：2013/11/25(月) 16:58:59.30

JapaneseDownload - Mercurial
http://mercurial.selenic.com/wiki/JapaneseDownload

>TortoiseSVN 同様、作業コピーとリポジトリについてはインデックスサービスを止め、ウィルススキャンから除外するようお勧めします

これってどういう理由からなん？

536 ：535：2013/11/25(月) 16:59:35.65

これってgitとか他のバージョン管理ツールでもインデックスサービスとかを止めたほうがいいってこと？

537 ：デフォルトの名無しさん：2013/11/25(月) 17:02:02.87

>>535
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2437253

538 ：535：2013/11/25(月) 17:10:41.13

>>537
㌧
つまりTortoise系列の固有の問題でバージョン管理システムの問題というわけではないわけね

539 ：デフォルトの名無しさん：2013/11/25(月) 17:24:55.13

>>538
> つまりTortoise系列の固有の問題でバージョン管理システムの問題というわけではないわけね
そういう結論なのかなぁ

540 ：デフォルトの名無しさん：2013/11/25(月) 17:29:21.42

>>534
そうかな。
Mercurialは子リビジョンを持たないリビジョンをheadと呼んでいるだけであって、
作業ブランチでの他の人の変更をpullした場合、それらをmergeするまでは大抵は
同一ブランチ内でマルチheadな状態だよ。

単に未merge状態の呼称の仕方の問題だと思う。

541 ：デフォルトの名無しさん：2013/11/25(月) 17:36:44.74

アンチウィルスソフトやインデックスサービスと競合起こすってことは
ローカルでリポジトリ作るたびにそれぞれ除外設定してかないといけないのか
Windowsだと面倒なんだね

542 ：デフォルトの名無しさん：2013/11/25(月) 17:44:23.37

TortoiseCVS
TortoiseSVN
TortoiseGit
TortoiseHg
TortoiseBzr

543 ：デフォルトの名無しさん：2013/11/25(月) 17:46:12.13

全部入れたら右クリックメニューが酷いことになりそう

544 ：デフォルトの名無しさん：2013/11/25(月) 17:55:13.58

>>540
「同一ブランチに複数人が変更をコミットした状態」を「マルチヘッドと呼ぶのが自然」というのが同意できない箇所。
じゃぁどう呼ぶのが自然かとかそういうことではなくて。
これがあるからMercurialは分かりづらいんだと思うんだが。

545 ：デフォルトの名無しさん：2013/11/25(月) 18:20:20.56

>>541
> Windowsだと面倒なんだね
C:\reposとかC:\projとかにフォルダを限定して作業すればそうでもないよ。

546 ：デフォルトの名無しさん：2013/11/25(月) 18:21:56.88

個人で趣味のプロジェクトなら何が良いですか？
作業マシンは書斎のWindows7, トイレのWindowsXP, 布団用のSurface Pro 2
サーバはScientific Linuxを使う予定です
ダサい恥ずかしいコードなので外に出したくないです
なのでローカルエリアで完結していると助かります

547 ：デフォルトの名無しさん：2013/11/25(月) 18:26:42.26

>>545
そういう手もあるな
その場合は外からリポジトリ持ってくるときは手動でウィルスチェックかけなきゃならんだろうけど

548 ：デフォルトの名無しさん：2013/11/25(月) 18:27:00.53

「入門Git」でマルチヘッドになったツリーをmergeなりrebaseなりで合成する図を見て
これがGitの醍醐味か、と感動したもんだ

549 ：デフォルトの名無しさん：2013/11/25(月) 18:28:15.47

トイレで作業ができるほど長く籠ることがあるのか、それに驚き

550 ：デフォルトの名無しさん：2013/11/25(月) 19:03:16.27

トイレより精神が平穏に満ちた空間はないよ
まさに文化の極みだね

551 ：デフォルトの名無しさん：2013/11/25(月) 19:18:28.54

multiple heads の意味が理解できないプログラマも居るから注意が必要だ。
適当に解消してソース壊しまくったオッサン。
結局プロジェクト掻き回しただけで逃げ出したけどな。

552 ：デフォルトの名無しさん：2013/11/25(月) 19:42:36.50

分からないことがあって
自分で調べても尚わからない、もしくは至急解決する必要があるとき
分かる人に訊いてもいい雰囲気が大事

553 ：デフォルトの名無しさん：2013/11/25(月) 21:10:44.71

>>546
Mercurial

554 ：デフォルトの名無しさん：2013/11/25(月) 23:36:40.33

>>546
何だか羨ましいと思った。
全部LANで繋がってると楽しそう。
俺はトイレに雑誌置いてて、気が付くと
お尻だしたまま寝てる。

555 ：デフォルトの名無しさん：2013/11/26(火) 00:26:50.64

>>544
分散型ではMercurialが初めてだった自分にはわかりやすく自然に思えるんだが、Gitから入った人にはそうは思えないかもね
Mercurialではブランチはチェンジセットに付けられる名前で、ブランチに関係なくリポジトリ内に存在する全てのチェンジセットが常に見えていて、枝分かれがあって初めてヘッドが増える
Gitではブランチはコミットを指す目印で、コミットから親をさかのぼる形でのみ履歴が見えていて、枝分かれが起こり得る部分はあらかじめ異なるブランチになるようにできている
ブランチの概念が全く別物であることがわかってしまえばどちらも理解できると思う

556 ：デフォルトの名無しさん：2013/11/26(火) 00:41:56.07

マジかよ
ブランチの概念ってそれぞれのシステムごとに違うのかよ

557 ：デフォルトの名無しさん：2013/11/26(火) 05:30:16.21

>>555
わかりやすい対比感謝。
ちなみに自分もMercurialから入ったのでマルチプルヘッドは呼称も概念も自然。
Gitのブランチはパス、Mercurialのブランチはサブツリーやサブグラフってとこかな。

558 ：デフォルトの名無しさん：2013/11/26(火) 10:06:06.53

bzrとの対比を誰か書いてくれないものだろうか。
どうも今一つbzrから乗り換える気にならんのだよ。

559 ：デフォルトの名無しさん：2013/11/26(火) 11:19:19.37

svnだと、HEADと言えばある一点のみを常に指し示すので非常にわかりやすい

560 ：デフォルトの名無しさん：2013/11/26(火) 13:37:19.27

svnはブランチが上の方から別ツリーになるから何か調べようとしたときにわかりやすいよな

561 ：デフォルトの名無しさん：2013/11/27(水) 08:12:00.44

svnは最高だ

562 ：デフォルトの名無しさん：2013/11/27(水) 15:27:54.03

バージョンシステムごとの概念の違いの比較の表とかあればいいのいね

563 ：デフォルトの名無しさん：2013/12/01(日) 01:51:03.22

リポジトリって何？
VisualStudioで出てくるソリューションみたいなもの？

564 ：デフォルトの名無しさん：2013/12/01(日) 06:47:11.58

VSで言うソリューションのディレクトリの、その時その時の現状を
バージョン管理システムへ報告していった、
そのデータを蓄積する場所がリポジトリ、かな

565 ：デフォルトの名無しさん：2013/12/01(日) 11:27:55.82

>>563
履歴を含んだデータの入れ物

566 ：デフォルトの名無しさん：2013/12/01(日) 14:29:32.30

なるほど、わからん

567 ：デフォルトの名無しさん：2013/12/01(日) 15:17:39.02

取り敢えず、入れもんをカッコつけて言ってるだけだよ。

568 ：デフォルトの名無しさん：2013/12/01(日) 15:38:09.27

例えば、VisualStudioのソリューション(の現在の版)をMercurialのリポジトリへコミットする。
そのリポジトリには過去の版からの履歴が入ってる。
…という感じ。何となくニュアンスが分かればOKかと。

569 ：デフォルトの名無しさん：2013/12/01(日) 17:17:34.41

>>564-568
㌧
なんとなくわかった気がしなくもない

570 ：デフォルトの名無しさん：2013/12/01(日) 18:22:44.82

いやVisual SourceSafeのドキュメントににVisualStudioに沿った説明があるのではとおもったが
VSS自体がお亡くなりになっていたのね。知らんかった。

571 ：デフォルトの名無しさん：2013/12/01(日) 20:46:50.13

いかん、この様子だとGitとかMercurialどころかTFSにも乗り換えられずVSSに一生閉じ込められたままだ
なんとしても脱出するんだ！

572 ：デフォルトの名無しさん：2013/12/01(日) 20:49:37.55

GitってPC9801みたいにすぐに主流から消えちゃう？

573 ：デフォルトの名無しさん：2013/12/01(日) 21:04:49.69

すぐに主流から消えちゃう程度のクソソフトだと思う？
Gitを殺すほどのキラーソフト候補って今何かある？

574 ：デフォルトの名無しさん：2013/12/01(日) 21:33:43.01

gitは俺が使い出したから後3、4年で廃れるよ

575 ：デフォルトの名無しさん：2013/12/01(日) 22:05:21.97

hgがgitより良いっていう話をよく聞くから主流はそのうちhgに

576 ：デフォルトの名無しさん：2013/12/01(日) 22:45:54.87

Hard Gay

577 ：デフォルトの名無しさん：2013/12/01(日) 23:29:21.86

最後まで残るのはsvn

578 ：デフォルトの名無しさん：2013/12/01(日) 23:44:49.67

WindowsよりMacが良いって話もよく聞くけど、今までシェアが逆転したことはあったか？

gitとhgも同じだよ。
gitは既にデファクトスタンダード。

hgにも良い点はあるが、gitと比べて圧倒的に優れてるわけでもないし
もう逆転は不可能。

githubの地位は安泰。他のgithubもどきは凋落の一途。
CodePlexでhgを猛プッシュしていたMicrosoftも、今ではgitがVisualStudio標準の分散VCSに。
hgクライアントだったSourceTreeは、今ではgitクライアントとして有名に。

世の中git!git!git!!!!! gitにあらずんば分散VCSにあらずという状況さ。

579 ：デフォルトの名無しさん：2013/12/02(月) 00:24:12.06

それを聞いて安心した
バージョン管理システムにどれを導入しようか迷ってたが
Gitに決まり

580 ：デフォルトの名無しさん：2013/12/02(月) 00:40:55.13

うわぁ…

581 ：デフォルトの名無しさん：2013/12/02(月) 00:41:23.21

てか、Linuxの開発用に使われ続けられるから廃れることはない。主流から外れることはあるだろうが。

582 ：デフォルトの名無しさん：2013/12/02(月) 00:44:07.34

非分散型ならこれ使っとけ
ってやつはある？

583 ：デフォルトの名無しさん：2013/12/02(月) 00:44:53.55

非分散型？
集中型以外にもあるのか

584 ：デフォルトの名無しさん：2013/12/02(月) 00:50:55.82

最近出てきたやつだろなんて言ったかわすれたが

585 ：デフォルトの名無しさん：2013/12/02(月) 01:17:56.07

集中型って和名なのか
英語圏だとクライアントサーバー型となってる

586 ：デフォルトの名無しさん：2013/12/02(月) 01:20:04.75

英語圏のWikipediaだと比較表とかもあるのね、

Comparison of revision control software - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

587 ：デフォルトの名無しさん：2013/12/02(月) 01:25:18.88

バージョン管理も和名か、というよりバージョンが和製英語的な使い方か

588 ：デフォルトの名無しさん：2013/12/02(月) 06:44:05.39

>>586
gitのメインテナーがリーナスだと思ってたら、濱野純になってる

589 ：デフォルトの名無しさん：2013/12/02(月) 07:42:24.92

>>578
スタバだとMacのシェアが圧倒的

590 ：デフォルトの名無しさん：2013/12/02(月) 07:48:47.08

最近はsurface pro 2が伸びて来てるね
やはりビジネスマンは圧倒的に窓pcだよ
ガキやアーティスト気取りはMacで満足かもだけどね

591 ：デフォルトの名無しさん：2013/12/02(月) 07:49:17.62

>>588
いつのまにかどころかほとんど濱野さんのはず
Linus君にはLinuxがあるからね

592 ：デフォルトの名無しさん：2013/12/02(月) 08:04:31.96

都内で行われてる IT 系の勉強会だと Mac の率がものすごく高いけど。

593 ：デフォルトの名無しさん：2013/12/02(月) 08:07:25.70

>>578
> WindowsよりMacが良いって話もよく聞くけど

それ、一部の声の大きい人が騒いでるだけだから (w

594 ：デフォルトの名無しさん：2013/12/02(月) 08:13:42.70

両方使ったがシンプルさと美しさは断然Macだね
ハードまで含めてすべてが調和してる
でも開発するならWindowsだな
Macは開発環境がしょぼすぎる
あくまでクライアントのためのマシン

595 ：デフォルトの名無しさん：2013/12/02(月) 08:13:45.19

>>588
これ見ると Git の開発で濱野さんがどれだけ commit してるかわかるよ
パンダのアイコンが濱野さんね
https://github.com/git/git/graphs/contributors

596 ：デフォルトの名無しさん：2013/12/02(月) 08:16:11.26

ぶっちゃげ.net関連を除けば開発環境としてWindowsにメリットは今では殆ど無い。

むしろデプロイするターゲットがLinuxなどのUnix系だと素でUnixであるOSXの方が
開発には便利でWindowsとかかえって面倒。
Cygwinでビミョーにお茶を濁したりLinuxの仮想環境をわざわざ入れるまでして
Windowsにこだわる理由が無い人が増えてきたと言うこと。

597 ：デフォルトの名無しさん：2013/12/02(月) 08:18:39.62

ビジネスでは窓が殆どだからねぇ
Linuxの利点なんて今やタダなだけだし

598 ：デフォルトの名無しさん：2013/12/02(月) 08:19:37.25

Winで無いとダメという人は、具体的にどんな開発環境を使っているの?

599 ：デフォルトの名無しさん：2013/12/02(月) 08:21:38.05

Web 系、サーバー系の開発だったら Unix マシンである Mac の方が良いと思う

600 ：デフォルトの名無しさん：2013/12/02(月) 08:22:38.59

vsだろ
これ以上の開発環境なんかないよ

601 ：デフォルトの名無しさん：2013/12/02(月) 08:24:01.22

マカーはxcodeとか使うのか？

602 ：デフォルトの名無しさん：2013/12/02(月) 08:26:03.35

Eclipse、IntelliJ、Netbeansに必要な言語プラグインを入れて使う。

603 ：デフォルトの名無しさん：2013/12/02(月) 08:37:32.65

EclipseやVim、金出すにしてもIntelliJといったところか。iOS開発も抱えているのであればXcode。
.net以外はWindowsいらないよ。

604 ：デフォルトの名無しさん：2013/12/02(月) 08:46:06.40

エクリプスなんかでよく満足できるな

605 ：デフォルトの名無しさん：2013/12/02(月) 08:56:58.43

むしろEclipse慣れてるとVSなんかでよく満足できるな、になるけどな

606 ：デフォルトの名無しさん：2013/12/02(月) 09:00:26.28

>>598
禿丸

607 ：デフォルトの名無しさん：2013/12/02(月) 09:02:15.37

>>593
これ思い出した
ttp://www.youtube.com/watch?v=HNJ7wI79qRE
ttp://rocketnews24.com/2011/10/07/138206/

608 ：デフォルトの名無しさん：2013/12/02(月) 10:36:51.98

MacでWindowｓは使えるけど、WindowsPCでMacOSは使えない。
只使われているだけのIT土方と違って、まともなエンジニアはMac比率が高くなるのも当然。

609 ：デフォルトの名無しさん：2013/12/02(月) 13:57:47.44

>WindowsPCでMacOSは使えない

あった気がするけど
hackintosh.com だか hackInt0sh.org だか

610 ：デフォルトの名無しさん：2013/12/02(月) 14:27:58.66

OSｘ86の話はスレ違い

611 ：デフォルトの名無しさん：2013/12/02(月) 14:47:59.13

多彩なハードウェアに対応するWindows
限られたハードウェアでしか動かいないMac

つまり、Windowsは優秀だって話だな

612 ：デフォルトの名無しさん：2013/12/02(月) 15:08:35.57

OS依存の少ないWebアプリを作ればいいのよ

613 ：デフォルトの名無しさん：2013/12/02(月) 16:14:31.18

WebアプリはIEでの動作確認という壁が・・・

614 ：デフォルトの名無しさん：2013/12/02(月) 16:44:11.07

おまえらバージョン管理システムについて語れよ！

615 ：デフォルトの名無しさん：2013/12/02(月) 17:44:08.59

ふぉー

616 ：デフォルトの名無しさん：2013/12/02(月) 17:46:56.12

マカーがディレクトリごと固めて公開するとゴミが大量に入るんだよねw

617 ：デフォルトの名無しさん：2013/12/02(月) 17:55:42.05

.DS

618 ：デフォルトの名無しさん：2013/12/02(月) 18:05:28.06

.DS_Store ._.DS_Store に対して言いたいこと
http://anago.2ch.net/test/read.cgi/mac/1384074458/

619 ：デフォルトの名無しさん：2013/12/02(月) 18:09:04.11

マカー自体がゴミなのだから仕方ない

620 ：デフォルトの名無しさん：2013/12/02(月) 19:57:26.84

>>611
> 多彩なハードウェア
NetBSD「ﾌﾟｯ」

621 ：デフォルトの名無しさん：2013/12/02(月) 22:27:44.68

>>613
IE10だかはけっこうHTML5準拠度高くなかったっけ？

622 ：デフォルトの名無しさん：2013/12/02(月) 23:04:21.22

>>621
何れにしてもテストはしなきゃならん。

623 ：デフォルトの名無しさん：2013/12/02(月) 23:14:35.88

どっちでもいいから破滅してひとつに統一してよ

624 ：デフォルトの名無しさん：2013/12/02(月) 23:25:38.81

git か hg か好きな方使うといいよ

625 ：デフォルトの名無しさん：2013/12/03(火) 03:01:11.08

>>616
thumbs.dbのこと？

626 ：デフォルトの名無しさん：2013/12/03(火) 04:00:45.88

>>613 >>621-622
http://furoshiki.hatenadiary.jp/entry/2013/11/26/032352
http://www.slideshare.net/kawada_hiroshi/internet-explorerie?ref=http://furoshiki.hatenadiary.jp/entry/2013/11/26/032352
http://furoshiki.hatenadiary.jp/entry/2013/11/27/203728
http://furoshiki.hatenadiary.jp/entry/2013/11/25/014726
http://furoshiki.hatenadiary.jp/entry/guideline
http://msdn.microsoft.com/ja-jp/library/dn384049.aspx
http://msdn.microsoft.com/ja-jp/library/ie/dn384051(v=vs.85).aspx
http://msdn.microsoft.com/ja-jp/library/ie/ff986088(v=vs.85).aspx
http://msdn.microsoft.com/ja-jp/library/ie/gg130949(v=vs.85).aspx
http://msdn.microsoft.com/ja-jp/library/ie/hh920754(v=vs.85).aspx

627 ：デフォルトの名無しさん：2013/12/03(火) 20:40:21.99

bzrのことも忘れないであげてください

628 ：デフォルトの名無しさん：2013/12/03(火) 22:39:34.47

>>627
もう成仏させてやれよ

629 ：デフォルトの名無しさん：2013/12/04(水) 20:10:44.74

多彩なハードウェアっていう言い方だと誤解を招くかもしれないが、周辺機器なんかでWindows用のドライバしかないなんてものはたくさんあるわけで、
そういう機器を使ったものを作りたい限り、Windowsで開発するしかない。
なんか、別にWindowsに限ったことじゃないけど、事情もよくわからず勝手な決め付けで「○○を使ってる奴は時代遅れ」っての、すごく頭悪そう。

630 ：デフォルトの名無しさん：2013/12/04(水) 20:39:23.43

マカーは時代の流れ見えてないよね
これからはlinuxの時代さ

631 ：デフォルトの名無しさん：2013/12/04(水) 20:45:06.92

svnを使ってる奴は時代遅れ

632 ：デフォルトの名無しさん：2013/12/04(水) 21:08:08.97

うるせえばか
髪の毛むしり取るぞ

633 ：デフォルトの名無しさん：2013/12/04(水) 21:51:35.52

hgがハゲを連想させるから移行できない

634 ：デフォルトの名無しさん：2013/12/05(木) 00:09:10.56

>>629
そういうのを作らないのであればWindowsは不要だし、最近より一般化してきたウェブ系やUnix系の作業の
場合はOSXの方が便利でWindowsはかえって不便というだけの話。

時代遅れとか関係ない。純粋に適材適所の問題。

635 ：デフォルトの名無しさん：2013/12/05(木) 00:14:11.73

OSXなんて生産性もコストも最悪だろ
そうでなければもっと売れるし案件も増える
しかし現実は厳しいね

636 ：デフォルトの名無しさん：2013/12/05(木) 00:41:34.11

パソコンソフト作ることしか頭にないんだな>>635は

637 ：デフォルトの名無しさん：2013/12/05(木) 01:05:02.78

議論に熱くなってしまうのは仕方ないことだが
OSの議論ならOSのスレでやってくれ

638 ：デフォルトの名無しさん：2013/12/05(木) 01:08:42.59

>>636
どこの分野でも同じだよ
反論したいなら開発環境としてOSXのシェアがトップの分野を挙げてみろよ

639 ：デフォルトの名無しさん：2013/12/05(木) 02:12:54.16

>>638
iOS

640 ：デフォルトの名無しさん：2013/12/05(木) 10:44:34.04

こいつWindows極めるまで10年かかりましたって顔してるな
そりゃ他のOS触りたくないわけだわ

641 ：デフォルトの名無しさん：2013/12/05(木) 20:50:20.74

この発想の貧困さがマカーだよな()

642 ：デフォルトの名無しさん：2013/12/06(金) 12:07:08.70

常に新しい物には触れてみたいけど時間がなくなってくる感覚はなんなの！
老化だね。

643 ：デフォルトの名無しさん：2013/12/06(金) 15:40:57.16

いいえ、社畜化です。

644 ：デフォルトの名無しさん：2013/12/06(金) 15:49:44.66

社畜なら口開けて待ってりゃ餌出て来るから良い身分だよ

645 ：デフォルトの名無しさん：2013/12/07(土) 11:02:08.19

>>640
そもそもWindowsって、どんどんUIいじくり倒されるから
いくら学んでも次のバージョンで役に立たなくなる知識が多い

…まあ、だからこそWindows一辺倒の人には
「君ならOSXもLinuxもすぐ慣れるよ」と言ってやりたい
あんだけ振り回されて使ってる人なら実際すぐ使えるようになるだろて

646 ：デフォルトの名無しさん：2013/12/07(土) 11:44:52.55

お前らいい加減にしろ。

647 ：デフォルトの名無しさん：2013/12/07(土) 12:08:40.61

Windows のひとに限らないけどさ
開発者ってなんで UI 変えちゃうんだろうな
仕事でアプリ使ったことないのかな

648 ：デフォルトの名無しさん：2013/12/07(土) 12:15:47.83

Mac の人に限らないけどさ
お前らってなんでスレ違いの話題続けちゃうんだろうな
仕事でも間違ったまま進めることが多いのかな

649 ：デフォルトの名無しさん：2013/12/07(土) 12:22:49.34

UI変えたぐらいであたふたするのがマカー技術者なんだよな
基本的な設計がなってないからそうなるんだろうなあ

650 ：デフォルトの名無しさん：2013/12/07(土) 12:45:18.49

>仕事でも間違ったまま進めることが多いのかな

激しく同意させていただきます

651 ：デフォルトの名無しさん：2013/12/07(土) 12:46:23.06

>>649
あいつら機能を意味で覚えないで場所で覚えてる人種だからな

652 ：デフォルトの名無しさん：2013/12/07(土) 12:58:08.64

MacでもWindowsでもスレタイ読めない奴は無能

653 ：デフォルトの名無しさん：2013/12/07(土) 13:16:23.78

>>647
UI買えないと売れない。
一般消費者にとって、UI＝性能。
どんなに内部設計が超絶進化してても、
UIが進化していない＝何もが変わってないから買う必要がない
となる。

654 ：デフォルトの名無しさん：2013/12/07(土) 13:40:36.55

デザイン変えるだけなら理解できるが場所まで変えられたら
間違い探ししてるみたいでイライラするわ

655 ：デフォルトの名無しさん：2013/12/07(土) 19:49:57.66

バージョン管理システムのUIってIDEと統合されていてナンボだと思う。

マージ後にそれぞれのバージョンと比較してコミット前に微調整の編集を加えたりとか。
不具合出たときにあるファイルの過去のバージョンと比較して問題の更新を特定したり。
バージョン管理とはいえ途中でファイルの編集もするし、開発中にサクサク履歴を参照
出来ると非常に便利。

今はIDEとは別にSourceTreeも併用しているけれども、良いアプリながら所詮別アプリ
なのでこの辺りの作業がし難い。
他方でEclipseのプラグインとかも出来や安定性が微妙なんだよね・・・

SourceTreeをIDEに統合して欲しい。ホントに。

656 ：デフォルトの名無しさん：2013/12/07(土) 19:57:23.30

ようするにVS使えですな

657 ：デフォルトの名無しさん：2013/12/07(土) 21:38:54.57

VisualStudioもEclipseに統合できるなら考えても良い。

658 ：デフォルトの名無しさん：2013/12/07(土) 22:08:58.77

>>634
開発にWindows使ってる奴が、ファイル名の大文字小文字考慮しないで作っていて
本番系の環境に持って行ったらビルドできなくてしばらくハマってたな。
気づけば何の事ないことなんだが、普段の環境では大丈夫だからなかなか気づかない。

659 ：デフォルトの名無しさん：2013/12/07(土) 22:17:37.05

Microsoft以外は倒産してプラットフォームを統一するべき

660 ：デフォルトの名無しさん：2013/12/07(土) 22:47:59.71

自分はどんどん Bitbucket や Github に push しちゃって、過去の履歴は Bitbucket や Github の方で見てる。
開発マシン上では Git をコマンドラインのみで使ってる。

661 ：デフォルトの名無しさん：2013/12/07(土) 23:03:32.49

>>658
少し昔にsubversionsでそんなトラブルを経験したことがあったな。
Windowsは短いファイル名の場合大文字小文字を区別しないとうかデフォですべて
大文字扱いしたので、Unix環境とファイル名の不整合がおきて短い名前のファイルが
毎度更新対象になったり変な動作をおこした。

662 ：デフォルトの名無しさん：2013/12/08(日) 03:34:35.93

>>660
正解

663 ：デフォルトの名無しさん：2013/12/08(日) 03:35:58.71

>>661
FATにしてた馬鹿ですね

664 ：デフォルトの名無しさん：2013/12/08(日) 04:55:28.80

NTFSでも起こるよ?

665 ：デフォルトの名無しさん：2013/12/08(日) 05:38:02.29

むしろ大文字小文字区別するのはファイルシステム側の怠慢としか（どうせ簡易なコードで収まるとかそんな理由だろ？）
ユーザ側の使い勝手からすれば同じ名前なのに違うファイルとか混乱のもとでしかない
クラスに同姓同名の生徒がいたら先生も名前だけで呼びづらいだろう

同名ファイルを同一フォルダに入れてるプロジェクトあったら
Windowsマシンではダウンロードできないな

666 ：デフォルトの名無しさん：2013/12/08(日) 06:24:49.32

６６６
http://developers.slashdot.jp/comments.pl?sid=429722&cid=1468089

667 ：デフォルトの名無しさん：2013/12/08(日) 08:03:25.46

>>665
NTFSだって大文字小文字は区別するよ。
問題は8.3形式のファイル名は特別扱いして区別しない場合もあると言うこと。
理由はMS-DOSとかの古い時代のファイル名にも対応するため。

そんな古い時代のものに関してまで互換性を維持しようとするのは関心するけれども、
それはあくまでMS界隈で閉じた話であるべきだし、色々なOSがアクセスするVCS界隈に
持ち込まれても迷惑だしトラブルだって起こる。

668 ：デフォルトの名無しさん：2013/12/08(日) 08:50:24.19

ren ahoaholongname.txt AhoAhoLongname.txt
これは NTFS でも通らないな

669 ：デフォルトの名無しさん：2013/12/08(日) 09:06:53.17

>>668
おいらのWin7ではできた。CYGWINのmvコマンドではだめだったような気がしたけど
これもできた。

670 ：デフォルトの名無しさん：2013/12/08(日) 09:16:50.66

exoplorerがダメなんだろ
.hogeとかも作れないし

671 ：デフォルトの名無しさん：2013/12/08(日) 10:16:30.27

バカな仕様に今まで疑問も持たずにやってきたのが間違い
Microsoftは来然として間違った慣習は正すからイイよね

672 ：デフォルトの名無しさん：2013/12/08(日) 11:44:18.56

>>665
賢いな
ついでにかたかなも廃止してひらがなに統一しようぜ

673 ：デフォルトの名無しさん：2013/12/08(日) 11:57:17.75

いわゆる全角の「ａ」と「Ａ」も同一視されるのにはびっくりしたもんだ。
あと「:」とか「AUX:」とか変な制限もあるからVCSにWindowsを混ぜるのはやっかいだ。

674 ：デフォルトの名無しさん：2013/12/08(日) 15:27:24.97

Hoge.cppとhoge.cppはWindowsでは共存できないんだよ、Windowsで大文字小文字の区別はファイル名の見た目だけなんだよ

675 ：デフォルトの名無しさん：2013/12/08(日) 18:29:49.17

NTFS上は区別できる。OS上で同一視しているだけ。

676 ：デフォルトの名無しさん：2013/12/08(日) 18:49:17.56

Windows使いは我々のプロジェクトには参加しないでもらいたい

677 ：デフォルトの名無しさん：2013/12/08(日) 19:31:58.11

Hoge.cppとhoge.cppが共存して、かつ敢えて使い分けるプロジェクトに
我々を巻き込まないでもらいたい

大文字小文字よりもUnicode正規化の方が
バージョン管理システムとしては頭痛いところだと思うけど
別に某OSをバッシングする気は無い

678 ：デフォルトの名無しさん：2013/12/08(日) 19:39:43.22

32年前は大文字と小文字を区別しなくて良い画期的なシステムだった

未だにその呪縛から逃げられていないのだけど

679 ：デフォルトの名無しさん：2013/12/08(日) 19:43:06.85

ここで、OSX登場

680 ：デフォルトの名無しさん：2013/12/08(日) 19:45:26.02

拡張子で区別とか、まだ残っているな

681 ：デフォルトの名無しさん：2013/12/08(日) 19:49:51.63

>>677
趣味でOS/2をつついてたころ、わりと有名なオープンソースソフトウェアで大文字と
小文字の違いだけのファイル/ディレクトリがあった覚えが。
うろ覚えだがCONFとconfだったか? どっちかがディレクトリ。
OS/2のファイル名も大文字と小文字を無視するものだった。

682 ：デフォルトの名無しさん：2013/12/08(日) 19:50:58.21

これがWindows三大汚点だ！！！

・大文字小文字同一視
・ファイルパス長制限
・プロセス引数長制限

すぐに解決するかと思われたが、互換性維持のために永遠に残ることが決定したぞ！

683 ：デフォルトの名無しさん：2013/12/08(日) 19:53:29.09

ファイルパス長の制限って、WindowsのShell系ライブラリの制限か？

684 ：デフォルトの名無しさん：2013/12/08(日) 20:21:08.91

で、肝心のSVNやらGitやらのバージョン管理システムは、そういうファイル名の違いは配慮してくれるの？

685 ：デフォルトの名無しさん：2013/12/08(日) 20:24:35.08

TortoiseSVNは割と丁寧に配慮してくれた

git？何を期待しているんですかｗｗ

686 ：デフォルトの名無しさん：2013/12/08(日) 20:26:39.58

gitってのは正に>>676だからな。

687 ：デフォルトの名無しさん：2013/12/08(日) 20:30:24.79

コンフリクトしますた

688 ：デフォルトの名無しさん：2013/12/08(日) 20:31:11.21

WindowsやOSXはcase-preservingだけどcase-insensitive。
つまりファイル作成時に名前の大文字小文字の違いはちゃんと保存される。
でもファイルを読み込むときに大文字小文字は区別されない。

他のUnix系のシステムはcase-preservingでcase-sensitive。
大文字小文字の違いはちゃんと保存されるし読み込み時も区別される。

VCSも多くはcase-preservingでcase-sensitiveと想定するのが無難じゃないのかな。
例えばファイル名だけでは無く.ignore等のパターンに関しても大文字小文字の違い
は注意した方が良い。

689 ：デフォルトの名無しさん：2013/12/08(日) 20:48:27.57

そもそもどういう需要があって大文字小文字を区別するファイルシステムになったんだろうな

690 ：デフォルトの名無しさん：2013/12/08(日) 20:54:37.70

それは、なんで8+3字のファイル命名法を変えてしまったのか、と言うのに似ている

691 ：デフォルトの名無しさん：2013/12/08(日) 21:06:12.80

Progra~1の暗黒歴史を思い出すな

692 ：デフォルトの名無しさん：2013/12/09(月) 00:48:46.92

>>689
WindowsのNTFSやOSXのHFS+はファイル名を保存する文字コードをUnicodeに決め打ってる。
だから大文字小文字を区別「しない」処理をドライバ内に書ける。

Unix一般ではそういうことはしてないので、ロケールを変えたらファイル名も一緒に化けるのが通例。
そんな状況でドライバ内に文字種を決め打つ処理を入れられるわけがない。

ただしZFSみたいな新しいファイルシステムは例外。

693 ：デフォルトの名無しさん：2013/12/09(月) 00:59:23.81

あとgitの動作はLinuxのファイルシステムに忠実という点では価値がある。Linuxのために作られたんだから。

bzr(や、svnの将来のプラン)は、ファイル名に対してUnicode正規化をかける。
全ファイルシステム中でファイル名の正規化をするのはHFS+とZFSのふたつだけ(と思う)なんだけど
bzrもsvnも、このふたつのファイルシステムとは違う正規化ルールを使う糞っぷり。
誰も幸せにならない。

694 ：デフォルトの名無しさん：2013/12/09(月) 05:03:38.50

unicodeであってもAとaは区別されているから単にポリシーの問題
むしろ別に割り当てられているものを同一視するほうがどうかしてると思うが

695 ：デフォルトの名無しさん：2013/12/09(月) 12:01:59.09

こんな百済ない話題で盛り上がれるおまいらがどうかしてる

696 ：デフォルトの名無しさん：2013/12/10(火) 09:12:46.11

時代はケース・インセンシティブだろ。

697 ：デフォルトの名無しさん：2013/12/10(火) 23:02:44.38

ファイル名は文字列なんだから大文字小文字区別すべき。

698 ：デフォルトの名無しさん：2013/12/10(火) 23:04:35.07

大文字小文字区別するのはコンピュータの仕組み上の都合でしょ
コンピュータを使う人間にとっては大文字小文字の違いで別物だなんて感覚がまずない

699 ：デフォルトの名無しさん：2013/12/10(火) 23:18:02.29

>>697
人間が「か」＋「゛」と「が」を区別できるってんなら同意してやる

700 ：デフォルトの名無しさん：2013/12/10(火) 23:20:59.96

プログラムからアクセスするためのライブラリが充実してるバージョン管理システムと言えば？

701 ：デフォルトの名無しさん：2013/12/10(火) 23:29:54.22

プログラムからアクセスって
普通コマンド叩くだけ（パイプ）じゃないの？

702 ：デフォルトの名無しさん：2013/12/10(火) 23:35:38.53

VSCをアプリのプラグインで埋め込むとかそういう話？

703 ：デフォルトの名無しさん：2013/12/10(火) 23:37:38.16

コンピュータの都合でハイフンとダッシュとマイナスが同一記号で表現されてるし

704 ：デフォルトの名無しさん：2013/12/10(火) 23:45:32.44

>>701
そういう雑な作りではなくちゃんとしたライブラリとしてまとまっているもの

705 ：デフォルトの名無しさん：2013/12/11(水) 00:37:18.44

ソフトウェア開発用途に関してはCamelCaseをファイル名に使う流儀もあるから
一律にcase insensitive
にするのも微妙だなぁ。

706 ：デフォルトの名無しさん：2013/12/11(水) 01:02:07.34

CamelCaseをファイル名に使う流儀において
case insensitiveだと何が微妙なの？
Non-case-preservingな糞システムを使いたいって？

707 ：デフォルトの名無しさん：2013/12/11(水) 01:37:52.61

大文字と小文字を区別したくないってのは人間側の都合なのではないかという見方もあるんじゃゃないか？
日本語だとひらがなとカタカナは区別しないなんていう仕様だったら暴動が起きるわけだしさw

708 ：デフォルトの名無しさん：2013/12/11(水) 01:43:35.70

英語のアルファベットの大文字と小文字は一対一対応だけど
ひらがなとカタカナは一対一対応じゃないから等価には扱えないよ。　ヴ　とかね

709 ：デフォルトの名無しさん：2013/12/11(水) 01:50:36.26

「バージョン管理システム連携」でググった感じからすると
ライブラリがありそうな雰囲気は感じてくる

710 ：デフォルトの名無しさん：2013/12/11(水) 02:01:06.16

いやつまり何が言いたかったかっていうと、等価に扱いたいかどうかってのは人間側の都合によって大きく変わるだろう、という話。
一対一対応じゃないから等価に扱えないってのは技術的にはそうかもしれないけど、
そもそも一対一対応ではない理由としてひらがなとカタカナは等価であるっていう意識が利用者にないからそういうことになるわけで。
英語だったとして、ある文字列の大文字小文字違いのものがあったとして、等価であるかどうかってケースバイケースだろうから、正解はないんじゃないの？
Case-preservingかつCase-insensitiveなファイルシステムって一貫性なくて気持ち悪い感もあるが、現実的な落とし所だろうなと個人的には思うけど。

711 ：デフォルトの名無しさん：2013/12/11(水) 02:25:05.66

TortoiseSVNやTortoiseHGのフォルダ見るとSVN用のDLLがいっぱいあるけど

712 ：デフォルトの名無しさん：2013/12/11(水) 05:50:37.95

ケースセンシティブかどうかは各プラットフォームの中で閉じる分にはそれぞれ自由に
ポリシー設定して良いけど、色々なプラットフォームが関わるプロジェクトの場合には
厳しい方に合わせないとダメだよ。

例えばLinuxとWindowsが相乗りするプロジェクトの場合はWindows側が配慮して大文字
小文字をゲンミツに扱わないと他方が困る。念のため、これは優越の問題では無くて、
そうしないとプロジェクトが回らないということ。

VCSに複数人がコミットするプロジェクトの場合とかで無くても、例えばデプロイ先が
LinuxのウェブアプリをWindows上で開発する場合も大文字小文字は要注意だよね。

713 ：デフォルトの名無しさん：2013/12/11(水) 05:56:52.16

大文字小文字ならまだいいさー
:が入っててM$じゃ取得すらできなくなるのどこかにあったからな

714 ：デフォルトの名無しさん：2013/12/11(水) 09:04:24.42

>>712
>例えばLinuxとWindowsが相乗りするプロジェクトの場合はWindows側が配慮して大文字
小文字をゲンミツに扱わないと他方が困る。

逆じゃないの？
Linuxで大文字と小文字の違いで別のファイル作られるとWindows側が困る

大文字と小文字を勝手に書き換える糞なアプリケーションもあるけど
それはOSの問題じゃないし
開発ツール関係でそんな酷いのはない
大文字と小文字を区別せずにハードコーディングするのも糞プログラマの問題

715 ：デフォルトの名無しさん：2013/12/11(水) 10:28:08.71

Windowsしか使わないクライアントにいじられないように、
設定ファイルの名前をauxにしたのは懐かしい思い出w

716 ：デフォルトの名無しさん：2013/12/11(水) 11:36:10.99

>>714
C言語でクロスプラットフォームのプロジェクトだったけど、
includeするヘッダファイルについて、Windows上がりは考慮が浅い奴が居るのよ。
#include "XxxYyy.h" って書いてるんだけど、ファイル名は xxxyyy.h とか。

717 ：デフォルトの名無しさん：2013/12/11(水) 12:21:23.66

だからそれはシステムの問題じゃなくてユーザの問題だろ
そういうポカが見過ごせない程度にあるなら
数行のスクリプト書いてテストに入れるだけ

718 ：デフォルトの名無しさん：2013/12/11(水) 12:47:37.30

>>707
半角カナ涙目

719 ：デフォルトの名無しさん：2013/12/11(水) 15:08:00.10

>>717
ユーザの問題だよ。
ファイル名の大文字小文字に無頓着でもWindows上だとビルドも通って正常に動いた
プロジェクトがケースセンシティブな環境に持ち込んだとたんに動かなくなることが
あるので、相乗りプロジェクトの場合はWindowsで参加している人もちゃんと大文字
小文字に配慮する必要があると言うこと。

720 ：デフォルトの名無しさん：2013/12/11(水) 15:32:24.65

Winは未だに内部名とシェル上の表示名をすり替えるとかやってるから
意識して書き分ける方がナンセンス

721 ：デフォルトの名無しさん：2013/12/11(水) 15:48:59.17

MSですらソースでは#include <windows.h>とか全部小文字なのに
実際のファイル名がWindows.hとか嫌な状態だ

722 ：デフォルトの名無しさん：2013/12/11(水) 15:57:05.95

UNIXから持ってきたツールだとcase sensitiveでソートするから意識した方が良い
Windowsに限った話でも、explorer上で大文字と小文字が混合しているのは醜い

723 ：デフォルトの名無しさん：2013/12/11(水) 16:05:15.67

8.3ルールを徹底しているのならそれでもよい

724 ：デフォルトの名無しさん：2013/12/11(水) 16:41:29.69

結論としてはファイル名はユーザーが大文字小文字意識しなさいってことだな。
そろそろスレ違いになりそうだ。

725 ：デフォルトの名無しさん：2013/12/11(水) 17:14:47.17

ケースセンシティブなVCSやプロジェクトをケースセンシティブで無いファイルシステム上で
扱うのであれば最終的にはユーザーにその辺り注意する役割が降ってくるよね。

726 ：デフォルトの名無しさん：2013/12/11(水) 18:19:43.57

リポジトリだって仮想ファイルシステムのようなもんなんだから
どのフォーマットをエミュレートするか指定できる機能があればいいんだけどな

727 ：デフォルトの名無しさん：2013/12/11(水) 21:09:42.76

バージョニングファイルシステム上にリポジトリが構築されて
リポジトリはバージョニングファイルシステムをエミュレート
……あれ？

728 ：デフォルトの名無しさん：2013/12/11(水) 21:27:58.76

おまえら色々苦労してきたんだな
他のOSの奴と共同プロジェクトしたことないから全くついていけん

729 ：デフォルトの名無しさん：2013/12/11(水) 21:53:10.64

俺の感覚では、同じフォルダにWindows.hとwindows.hが有って、それぞれが
別の役割を持つほうが異常に感じる。
ぜひ同一視してほしいし、Windows.hがすでに有るなら、windows.hを新規作成
出来ないようにしてほしい。
これらは同じもののように見える。

730 ：デフォルトの名無しさん：2013/12/11(水) 22:12:21.86

だらしないOSの仕様をVCSが吸収してやればいいのですよ

731 ：デフォルトの名無しさん：2013/12/11(水) 22:48:29.72

>>729
変数 Bar と bar があって別の役割を持つプログラム言語は使うべきじゃないな
CとかC++とかJavaとかC#とか
ぜひ同一視してくれるBASICを使うべきだ

732 ：デフォルトの名無しさん：2013/12/11(水) 22:49:01.35

お前ら本当にIT従事者なんか？
仕事する前にファイル名を制限するコードを先に書けよ

733 ：デフォルトの名無しさん：2013/12/11(水) 22:51:39.16

ファイル名をいい加減に決めるから不幸になる

つまるところファイル名を連番にするというシンプルかつ厳格なルールが
市民を幸福にさせるのですね！

734 ：デフォルトの名無しさん：2013/12/11(水) 22:52:10.22

>>731
俺はプログラミングはBASICから入ったからCを知ったときはマジ驚いたわ、

735 ：デフォルトの名無しさん：2013/12/11(水) 22:53:06.84

連番ファイル名の悲劇

100.txt
1000.txt
1100.txt
2.txt
32.txt
4.txt

736 ：デフォルトの名無しさん：2013/12/11(水) 22:58:52.82

NTFSがCase-sensitiveなのはWindowsをPOSIX準拠にする為に仕方無く従った仕様だしな

737 ：デフォルトの名無しさん：2013/12/11(水) 23:09:08.60

>>735
解決策
3.txt
3.1.txt
3.14.txt
3.141.txt
3.1415.txt
3.14159.txt

738 ：デフォルトの名無しさん：2013/12/11(水) 23:18:04.92

>>733
数字だとネットワークでの分散管理で破綻するのでハッシュ値にすべきだな

739 ：デフォルトの名無しさん：2013/12/11(水) 23:22:49.77

ハッシュ値は完全に一意に作られるわけでは無いので運が悪いと・・・

740 ：デフォルトの名無しさん：2013/12/12(木) 04:07:46.06

>>698
ホんトニソう思うカ？
たトエバ wInDOwS, lINuX ガオなじニミエるのカ？
ヒラガなトかタカなノチがイヲイしキシナいのカ？

741 ：デフォルトの名無しさん：2013/12/12(木) 04:09:32.09

× > たトエバ wInDOwS, lINuX ガオなじニミエるのカ？
○ > たトエバ wInDOwS, lINuX ガ Windows, Linux トオなジにミえルノカ？

742 ：デフォルトの名無しさん：2013/12/12(木) 04:15:29.98

画像認証みたいｗ

743 ：デフォルトの名無しさん：2013/12/12(木) 05:47:15.10

才ナツ゛二Ξ工ﾉﾚ

744 ：デフォルトの名無しさん：2013/12/12(木) 07:22:15.71

>>729
UNIXには、makefileとMakefileがあったらmakefile優先と言うコマンドが
PWB/UNIX(V6,V7)の頃から存在するのだ

745 ：デフォルトの名無しさん：2013/12/12(木) 08:22:15.36

そもそもargv[0]の値見て挙動変えたりするしな

746 ：デフォルトの名無しさん：2013/12/12(木) 18:09:15.46

気持ち悪い仕様だな
やはりWindowsが一番いいね

747 ：デフォルトの名無しさん：2013/12/12(木) 22:00:09.03

NTFSにはWindows.hとwindows.hが同時に存在しうるが、Windows OSからは片方しか見えない
この状態を解消するには、二回 remove するしか無いという糞みたいな仕様は何とかならんのか

748 ：デフォルトの名無しさん：2013/12/12(木) 22:09:11.86

>>747
両方存在してるってどうやって確認するの？

749 ：デフォルトの名無しさん：2013/12/12(木) 22:20:42.24

>>744
それってメリットなの？

750 ：デフォルトの名無しさん：2013/12/12(木) 22:36:15.19

バージョン管理システムが無かった時代にMakefileを使い分けてたとかじゃね

751 ：デフォルトの名無しさん：2013/12/12(木) 22:48:04.47

それだと単に盲腸になってるだけな気が

752 ：デフォルトの名無しさん：2013/12/13(金) 01:58:37.37

ファイルが見えなくなるって怖いな。
DIRコマンドでも片方しか見えないの？

753 ：デフォルトの名無しさん：2013/12/13(金) 02:12:54.70

コマンドプロンプトで
echo hoge > hoge.txt
echo HOGE > HOGE.TXT
をやっても最初のに上書きされるだけだったけど・・・
エクスプローラーでも同一ファイル扱いになるし
>>747の再現ってどうやるのさ

754 ：デフォルトの名無しさん：2013/12/13(金) 02:21:12.14

>>753
NTFSを使えるWindows以外の大文字小文字を区別するシステムで作るのでは？

755 ：デフォルトの名無しさん：2013/12/13(金) 02:23:11.43

SFUとかSUAを使う
あるいはLinux等の別OSからNTFSをmountする

756 ：デフォルトの名無しさん：2013/12/13(金) 02:24:00.13

LinuxのだとNTFS領域は読み込みはOkだけど書き込みは自己責任って感じで怖すぎて試せないお

757 ：デフォルトの名無しさん：2013/12/13(金) 05:25:16.38

>>753
cygwinでもできると思うよ。>715のauxはvygwinなら作れるから。

758 ：デフォルトの名無しさん：2013/12/13(金) 10:28:55.55

>>730
だらしないってどっちのこと言ってる？
処理としてはケースセンシティブの方がだらしないのはわかってるよね？

759 ：デフォルトの名無しさん：2013/12/13(金) 15:32:23.34

処理においても文字列比較等で strict match とか loose matchって言うよね

760 ：デフォルトの名無しさん：2013/12/13(金) 15:32:25.08

>>757
auxはcygwinなら作れるけど、 hoge.txtとHOGE.txtの作り分けはできなかったな。レイヤの違う問題っぽい。
cygwinなら作れるならJavaのプログラムとかからなら作れるかな？って思ったけど、無理だった。
てか、auxってNTFSかFAT32か関係なく作れなくて、hoge.txtとHOGE.txtの問題はNTFSだけで起こるんだとしたらそりゃまあレイヤが違うよね。

>>730 >>758
いい加減「だらしない」とか「クソ」とか「腐った」とか言って自分の嫌いなOSの仕様をdisるのはやめないか？なにも生み出さない。
ファイル名の同一性はどうあるべきかってのを固定観念なしにもっと丁寧に論じるべきだろ。
大文字小文字を同一視するとして、Unicodeファイル名が当たり前となった今ではアルファベットだけ特別扱いでいいのかって話になってくるわけだし、
「だらしない」かどうかなんて要求するシチュエーションによって180度変わってくると思うんだが。
極論を言ってしまえば、だらしなさの根本は違うコードポイント列を同一視したりしなかったりする人間そのものだろ。

761 ：デフォルトの名無しさん：2013/12/13(金) 15:39:45.56

だらしないといえば、まずUnicodeを決めてる連中もだらしないからなあ
Unicodeを基準にすると、Unicodeのバージョンに縛られることになってHFS+の惨状があちこちで起こることになる

762 ：デフォルトの名無しさん：2013/12/13(金) 16:42:32.58

>>760
> いい加減「だらしない」とか「クソ」とか「腐った」とか言って自分の嫌いなOSの
> 仕様をdisるのはやめないか？なにも生み出さない。

まったくその通り。

アルファベットにしても欧州諸言語におけるアクセント記号とかエスツェットなど
合字の扱いとかあるので難しい。正直使用目的に応じたケースバイケースだと思う。

ただ様々なシステムが相乗りするようなプロジェクトの場合は概ね無難な最大公約数
としてはファイル名はASCII文字だけ、case preservingかつsensitiveただし小文字
等にそろえた場合に同じになるファイル名は避ける、といったあたりだと思う。

763 ：デフォルトの名無しさん：2013/12/13(金) 19:30:10.93

HFS+の惨状は主に林檎独特の方言に起因してるんじゃないのか？

764 ：デフォルトの名無しさん：2013/12/13(金) 19:47:16.60

>>763
方言(互換漢字の扱い)もそうだけど、使われているUnicodeテーブルのバージョン自体も古いので
最新のテーブルを使ってしまうと食い違いが酷い＆新しく追加された文字は正規化されない

Unicodeが「バージョンアップ」する仕様である以上は、ファイルシステムを作った時点で
Unicodeのバージョンも固定しないといけないわけで
するとアプリはバージョン違いのテーブルをいくつも抱え込む必要が出てくるわけで

HFS+だからといってその辺のライブラリを適当に使ってNFD変換するアプリでこの辺の差異に遭遇すると
まだ何の対応もなく素通ししてくれたほうがマシに思えるレベルで軽く絶望できる。
svnのunicode_pathパッチとか、bzrとかな。

765 ：デフォルトの名無しさん：2013/12/13(金) 21:34:46.60

Unicodeの継ぎ接ぎ拡張って、調べれば調べるほど人間がいかに好き勝手に文字という概念を取り扱ってるかという印象しか抱けないな。
アルファベットくらい世界が単純だといいんだろうけれど、漢字は複雑だしローカル拡張が多すぎて(元の字は違うのに見た目は同じ略字とか)
意味も見た目もちゃんと取り扱える文字コードを作るってこと自体幻想なんだろうなと思ってしまう。
つまるところ、人間がよくないw

766 ：デフォルトの名無しさん：2013/12/13(金) 22:43:42.95

誰もこんなことになるとは予想してないから仕方ない。
人工的に作って実用になった文字はハングルしか知らないし。

767 ：デフォルトの名無しさん：2013/12/13(金) 23:20:00.90

チェロキー文字は、まぁちょっと特殊か。

768 ：デフォルトの名無しさん：2013/12/13(金) 23:36:11.11

バージョン管理うんぬんではなく
共同プロジェクトに関する問題だよね
ここまでの不毛な議論の連続は

769 ：デフォルトの名無しさん：2013/12/14(土) 23:09:26.90

様々な環境で運用する事案は、それぞれの環境に配慮した運用をするべきであって
嫌われるのは、自分の環境を前提として、他の環境を考慮しない無知と傲慢。
俺様ルールを主張すること自体は別に構わないが、そのテリトリーから一歩も出て
もらっては困る。迷惑だから。

770 ：デフォルトの名無しさん：2013/12/14(土) 23:44:13.94

そんなことより
バージョン管理システムについて語ろうぜ

771 ：デフォルトの名無しさん：2013/12/15(日) 02:41:50.56

http://toro.2ch.net/test/read.cgi/motenai/1381308314/242-257

この感じからするとITへの就職を考えるならgitよりsvnのほうがいいの？

772 ：デフォルトの名無しさん：2013/12/15(日) 03:08:35.15

gitメインにしつつ両方やっとけ

773 ：デフォルトの名無しさん：2013/12/15(日) 03:19:34.95

>>771
svnはバージョン管理ツール。
gitはバージョン管理もできる開発ツール

svnはバージョン管理するぐらいしか出来ないが、
gitはソースコードの修正とコミット（リリース）を
適切に行うための各種機能が付いている。

具体的にはローカルで大規模な開発しながらも
その開発でできた機能のうち先にリリースできる部分や
小さい修正に分離したり整理することで
大きなものを小さく開発の連続にすることが可能になる。

774 ：デフォルトの名無しさん：2013/12/15(日) 03:41:39.05

おｋ
gitやりつつsvnも覚えることにする

775 ：デフォルトの名無しさん：2013/12/15(日) 03:47:10.39

Gitって、ソース修正できるような、エディタ機能もあるんか

776 ：デフォルトの名無しさん：2013/12/15(日) 07:57:51.96

シェルスクリプトで楽々自動コード修正です。

777 ：デフォルトの名無しさん：2013/12/15(日) 12:44:13.91

エディタ機能があるのと充実しているのでは全く違う
バージョン管理はバージョン管理だけしていれば良いし
エディットは他のシステムの仕事だ
こんな基本もわからない素人がgitだなんだなんて駄作に走る
プロはみんなsvnみたいなシンプルで応用や連携が効くものを選ぶ

778 ：デフォルトの名無しさん：2013/12/15(日) 13:02:37.83

>>775 がgithubのことを言ってるのか、giのコマンドが登録されたエディタを呼ぶ機能のことを言ってるのかわからんが
>>777 はただの無知

779 ：デフォルトの名無しさん：2013/12/15(日) 14:28:57.55

よく考えたら扱うシステムのが複雑なのだが、バージョン管理が複雑に見えて戸惑う

780 ：デフォルトの名無しさん：2013/12/15(日) 16:59:30.29

>>778
ハゲろ

781 ：デフォルトの名無しさん：2013/12/15(日) 20:51:22.69

>>780
ハゲにハゲろっつってもダメージ無いよ

782 ：デフォルトの名無しさん：2013/12/15(日) 21:03:33.91

何て言えばハゲは傷つくの？

783 ：デフォルトの名無しさん：2013/12/15(日) 21:31:12.13

生えろ

784 ：デフォルトの名無しさん：2013/12/16(月) 15:04:02.25

>>775
別にソースコード修正機能＝エディタとは限らんだろ
patchコマンドだってソースコードを修正するツールだし

785 ：デフォルトの名無しさん：2013/12/16(月) 15:12:03.97

gitだとコミットを複数に分割してその中のいくつかを取り除いたりとかできるからな
これはソース修正してるのとかわらんかもしれん

786 ：デフォルトの名無しさん：2013/12/16(月) 22:01:58.23

それはtortoisesvnにもついてるらしいけどな
http://toro.2ch.net/test/read.cgi/tech/1381929347/413

787 ：デフォルトの名無しさん：2013/12/16(月) 22:06:27.16

SVNのコミットに相当するのはGitだとプッシュだって言ったじゃないですかー

SVNのコミット　≠　Ｇｉｔのコミット
SVNのコミット　≒　Gitのプッシュ

788 ：デフォルトの名無しさん：2013/12/17(火) 00:03:58.47

>>787
この文脈ではSubversionでもGitでもコミットと呼ばれる操作についての話だと思うぞ。
SubversionのコミットはGitでいうところのコミット+プッシュだろう。おおまかに言えば。

789 ：デフォルトの名無しさん：2013/12/17(火) 00:29:41.12

>>786
それは今編集中のファイルの一部をコミットする方法かな？
>>785で言ってるのは、過去にコミット済みの修正の特定部分の削除を
gitコマンド操作だけでできるってことね

790 ：デフォルトの名無しさん：2013/12/17(火) 23:25:45.09

SVN次期バージョンでcheckpointやshelfといったローカルコミット機能が実装されるようだから、
そうなるとまた話は変わってくるな。

791 ：デフォルトの名無しさん：2013/12/20(金) 16:43:01.31

git cloneてresume できないんですね。
ダウンロード速度が遅かったのでctrl-cで止めて寝て、今日やり直したら
また最初から全部ダウンロードやり直しとか。

792 ：デフォルトの名無しさん：2013/12/20(金) 16:48:56.04

マジかよ
それは酷いな

793 ：デフォルトの名無しさん：2013/12/21(土) 03:49:57.95

gitはデフォだと遅いけど、まあぐぐって幸せになりやがれ

794 ：デフォルトの名無しさん：2014/02/04(火) 20:31:50.62

Windows用に特化された分散管理システムきぼんぬ
GitやHGはLinux向きだし

795 ：デフォルトの名無しさん：2014/02/04(火) 20:43:59.05

MSが自分で作れなくて、白旗を上げてGitサポート初めた時点で終わった

796 ：デフォルトの名無しさん：2014/02/04(火) 21:15:05.55

gitは改行コードが

797 ：デフォルトの名無しさん：2014/02/04(火) 21:30:45.30

>>794
Veracity
http://www.sourcegear.com

798 ：デフォルトの名無しさん：2014/02/04(火) 22:43:37.41

Comparison of revision control software - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

いっぱいあるよ

799 ：デフォルトの名無しさん：2014/02/05(水) 08:09:43.61

>>795
> MSが自分で作れなくて、

TFS も知らんのか？
まあ、売れてないみたいだけど。

800 ：デフォルトの名無しさん：2014/02/05(水) 10:26:31.49

>>799
http://sourceforge.jp/magazine/13/01/31/0559255
> TFSはTeam Foundation Version Control（TFVC）と呼ばれる独自の集中型バージョン管理システムを
> 搭載しているが、近年ではGitやMercurialといった分散型バージョン管理システムが注目され普及も
> 進んでいることから、TFSでも分散型バージョン管理システムの導入を決定したという。
> そこでGitを選択した理由としては、Gitがほかの分散型バージョン管理システムと比べて勢いがあり、
> また新たな分散型バージョン管理システムを作ることは難しいと思われたことが挙げられている。

801 ：デフォルトの名無しさん：2014/02/05(水) 14:11:13.49

特許を取得できそうなアイデアがすでにオープンソースで使われてしまってたってとこかな

802 ：デフォルトの名無しさん：2014/02/05(水) 16:02:58.49

新しいDVCSを別にイチから作るより既に普及しているGitを使った方が時間と手間の
有効活用になるってことだろうね。
http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx

803 ：デフォルトの名無しさん：2014/02/05(水) 16:08:53.93

他所のオープンソースソフトウェアなんか導入しちゃってどこから利益を得ようって考えなんだろね

804 ：デフォルトの名無しさん：2014/02/05(水) 17:02:06.55

VSからじゃない?

805 ：デフォルトの名無しさん：2014/02/14(金) 00:00:32.95

趣味でプログラミングを始めようと思ってます
VCSにはSVNやらGITやら色々あるようですが
VCSを覚えるならどれがどのVCSがオススメですか？

806 ：デフォルトの名無しさん：2014/02/14(金) 00:02:48.11

svnでおk

807 ：デフォルトの名無しさん：2014/02/14(金) 00:03:11.25

趣味ならGitでいいんじゃない？VisualStudioでもサポートしたらしいし

808 ：デフォルトの名無しさん：2014/02/14(金) 00:11:20.72

Mercurial一択

809 ：デフォルトの名無しさん：2014/02/14(金) 02:00:04.37

Bazaar

810 ：デフォルトの名無しさん：2014/02/14(金) 02:36:36.24

個人ならCVSで十分やろ～

811 ：デフォルトの名無しさん：2014/02/14(金) 11:02:44.88

CVSは最新版が使い物にならなかったりするからな@ms

812 ：デフォルトの名無しさん：2014/02/14(金) 11:37:35.02

新規で CVS はない
git か svn でいいだろ

813 ：デフォルトの名無しさん：2014/02/14(金) 15:56:47.74

Mercurial...

814 ：デフォルトの名無しさん：2014/02/14(金) 16:18:13.36

mercurialかgitで良いと思う。
一人だとsvnは手間。

815 ：デフォルトの名無しさん：2014/02/14(金) 16:28:03.66

svnは今更だと思う。新規に学ぶのであればDVCSからでは。

816 ：デフォルトの名無しさん：2014/02/14(金) 16:32:18.25

両方こなせる Bazaar 択一！

817 ：デフォルトの名無しさん：2014/02/14(金) 17:03:57.54

cvsだけは絶対無い100%無い

818 ：デフォルトの名無しさん：2014/02/14(金) 17:16:37.05

Bazaar は死んだでござる

819 ：デフォルトの名無しさん：2014/02/14(金) 21:51:59.06

ソースコードなどのテキストデータではなく
画像などのバイナリデータについてバージョン管理したいと考えています。

差分とかは気にせず、単純に失敗したら前のバージョンに戻ったりしたいだけです。
以前、ソフト開発していたころに使っていたGitを使っていますが、
ソースコード以外の用途にも耐えうるか心配です。

Gitでも大丈夫でしょうか。他にオススメがありましたら、ご教授願います。

820 ：デフォルトの名無しさん：2014/02/14(金) 22:22:31.63

git使えるならとりあえずgitで
パフォーマンスに不満が出てからもう一度検討すれば？

明らかに駄目そうなら予め使い方書いてもらわないと

821 ：デフォルトの名無しさん：2014/02/14(金) 22:28:09.24

別にgitでも困らないとは思うけど、バイナリを差分で格納して欲しいならsvnかなあ
gitでも手動でアレコレ指定してrepackすればいけるけど

822 ：デフォルトの名無しさん：2014/02/14(金) 22:35:20.44

横レスだが
バイナリの差分保存って保存方法として有用なのか？
ビットマップのような非圧縮の生データで多少の変更ならともかく
圧縮がかかってるデータだとほぼ別ファイルくらいになるんじゃないのか？

823 ：デフォルトの名無しさん：2014/02/14(金) 22:50:29.23

>>822
まあその辺はアルゴリズム次第としか。

824 ：デフォルトの名無しさん：2014/02/14(金) 22:50:31.18

非圧縮のビットマップだって
人間の眼ではほとんど区別できない程度にトーンカーブいじっただけで
全く別のバイト列になる

有用な使い方もあるし逆効果な使い方もある
だからVCSがどちらを優先するかは技術的優劣というよりはポリシーによる

825 ：デフォルトの名無しさん：2014/02/14(金) 23:30:57.99

>>820-821
回答ありがとうございます。
とりあえずGitでやってみます。

826 ：デフォルトの名無しさん：2014/02/14(金) 23:34:03.79

ブランチ使わず画像やバイナリデータを管理するなら
ディレクトリ別に分けて圧縮しとくだけでいいと思う

827 ：デフォルトの名無しさん：2014/02/14(金) 23:51:25.68

差分圧縮と言えばMercurialだろ

828 ：デフォルトの名無しさん：2014/02/15(土) 10:58:39.30

>>819
一人で使うとか個々のファイルがそれ程大きくないならgitでいいと思う
まぁその「大きい」ってのも曖昧なんだけど

gitはリポジトリ全体を使う人全員にコピーするようなものなのね
だから、巨大ファイルを大人数で共有するならsvnの方が有利と言われていたような

829 ：デフォルトの名無しさん：2014/02/15(土) 11:15:40.05

数百MBとかのあまりに巨大なファイルはそもそもバージョン管理すべきじゃない気がする
Mercurialにはlargefileという巨大ファイル管理用の拡張があるが、これを使うのは最終手段的な扱い

830 ：デフォルトの名無しさん：2014/02/15(土) 12:07:37.89

一人で使うならgitやhgはメリットない
面倒臭いsubversionに過ぎなくなる

831 ：デフォルトの名無しさん：2014/02/15(土) 12:22:46.92

gitやhgはファイルを管理するというよりパッチを管理するという方が正確
同時に他人が同じファイル編集しててもパッチを当てられる(たまにパッチ失敗するが)
なので、gitを使うにはpatchコマンドとdiffコマンドの概念を理解出来てる事が前提
画像ファイルのようなバイナリはdiffが取れないのが根本的な問題だけど、他にもgitの実装上の理由で不都合な事がいくつかある

832 ：デフォルトの名無しさん：2014/02/15(土) 12:29:00.77

>>830
一人で使うならsvnの方がめんどいわ
むしろgit/hgの方がお手軽

833 ：デフォルトの名無しさん：2014/02/15(土) 12:37:01.88

2MB程のテキストファイルでもgitでやると恐ろしいペースでリポジトリが肥大化してくもんだ
で、時々repackしてみるとこれまた笑えるぐらい一気に縮む

834 ：デフォルトの名無しさん：2014/02/15(土) 14:25:56.65

デザイナーが使ってsvnよりgitやhgにメリットあるって勧めてるのはプログラマーのステマ

835 ：デフォルトの名無しさん：2014/02/15(土) 15:32:47.57

gitやhgはSourceTreeが使えるからね。あれは良いものだ。
デザイナーも多く使うOSXで使えるSVNのGUIクライアントとしては現在一番まとも。

836 ：デフォルトの名無しさん：2014/02/15(土) 15:33:43.85

> SVNのGUIクライアント

間違えた。VCSのGUIクライアントだ。

837 ：デフォルトの名無しさん：2014/02/15(土) 15:47:57.03

gitやhgはコマンドラインで使うもの
コマンドラインに降りてこなければgitならではの利点は活かせない

838 ：デフォルトの名無しさん：2014/02/15(土) 15:51:40.21

gitk便利だよん

839 ：デフォルトの名無しさん：2014/02/15(土) 16:26:57.30

ロブ・パイクのUNIX環境本でvcsの基本って学べるの？

840 ：デフォルトの名無しさん：2014/02/15(土) 17:53:19.32

Gitの設計的にバイナリデータを含めるのはよろしくないってのはわかってるけど、
GUI的な要素を含むソフトウェア開発では画像とかのリソースも一緒に管理したいから、なんとも難しいところだね。というかどうすればいいんだろう。

841 ：デフォルトの名無しさん：2014/02/15(土) 18:20:52.46

>>814
> 一人だとsvnは手間。

どこが手間なの？
個人ならリポジトリをローカルファイルにも作れるし。

842 ：デフォルトの名無しさん：2014/02/15(土) 18:39:40.48

一人でもブランチの多用やマージやチェリーピックは便利なんで
両方使える環境ならあえてsvn選びはしないな

gitの場合むしろ超巨大プロジェクトの分割管理が鬼門で
Linux方式にしろAndroid方式にしろ面倒そう

843 ：デフォルトの名無しさん：2014/02/15(土) 18:42:14.61

>>842
hgは、Facebookが1つの超巨大リポジトリに全部突っ込む為に、色々改良してるらしいな。

844 ：デフォルトの名無しさん：2014/02/15(土) 18:46:53.13

bazaarは置いてけぼりなの？
GNUプロジェクトこういうの多くてかなしい

845 ：デフォルトの名無しさん：2014/02/15(土) 18:51:02.01

>>844
残念だけど諦めたほうがいいよ。
svnからの移行もしやすく好きだったんだけど…

846 ：デフォルトの名無しさん：2014/02/15(土) 19:09:50.50

最もセキュリティが高い（盗聴してるIP履歴を発見できる）バージョン管理システムを教えてください。

847 ：デフォルトの名無しさん：2014/02/15(土) 19:13:37.97

盗聴されてる時点でセキュリティも糞も無いと思うが

848 ：デフォルトの名無しさん：2014/02/15(土) 19:17:35.64

ニダーさんが覗いています

849 ：デフォルトの名無しさん：2014/02/15(土) 19:22:57.03

>>844
GNU Emacsがbazaarやめてgitにしようとか言ってる時点で
bazaarは終わりでござる
RMSもべつにかまわんとか言ってるし

850 ：デフォルトの名無しさん：2014/02/15(土) 19:47:48.44

Linux版のSubversionを使い始めて
早速最新版をビルドしようとしたが
依存ソフトがいろいろあって難儀している
OSのパッケージシステムに登録されてる版は
古すぎてお話にならず
みんなはこれくらいへっちゃらなのか？

851 ：デフォルトの名無しさん：2014/02/15(土) 20:04:28.20

bazaarは名前がダメだわ。一昔前に流行ったバズワードじゃねぇか。

852 ：デフォルトの名無しさん：2014/02/15(土) 20:10:29.19

>>850
パッケージシステムのはいくつなん？

853 ：デフォルトの名無しさん：2014/02/15(土) 20:44:34.91

gitやhgがsvnに比べて有利なのは複数のプログラマーが同時に開発するプロジェクトでソースコードの管理する場合だね

854 ：デフォルトの名無しさん：2014/02/15(土) 20:53:54.49

ひとりでローカルにブランチいっぱいつくって
とっかえひっかりしたり、マージしたり、いろいろ加工できるのが
gitの利点なのに

855 ：デフォルトの名無しさん：2014/02/15(土) 20:57:24.87

>>852
Ubuntu12.04LTSで1.6.17
Windows用クライアントは既に1.8.4という大差

856 ：デフォルトの名無しさん：2014/02/15(土) 21:16:21.21

精神分裂病のプログラマーでもないかぎり、とっかえひっかえブランチ切り替えてコード書いたりしないと思う

857 ：デフォルトの名無しさん：2014/02/15(土) 21:50:04.82

新しい機能を実装するために新しい機能ブランチ切るだろ。
その機能ブランチに細かくコミット重ねながら機能を実装していく。
途中で実装方法迷ったときとかそこから更に新しいブランチ切る。
いくつかコミット重ねて修正してみて、その実装方法に確信が持てたら元の機能ブランチにマージ。
納得できなかったらとりあえずそのブランチは行き止まりにして元の機能ブランチに戻る。
それを繰り返してると行き止まりにしたブランチに捨ててきたコミットが使えることに気づいて、
そのコミットをチェリーピックで復活とかもしたくなる。
そんなのを多段に繰り返して機能実装完了したら機能ブランチを整理してオリジナルにマージ。
機能ブランチの整理のときも、安全のために機能ブランチとは別のブランチ作ってリベース。

858 ：デフォルトの名無しさん：2014/02/15(土) 22:06:52.93

目標に向かって一直線にプログラム書いていけるようなプロジェクトやってる人も
手法20個試して1個の当たり見つけるようなのやってる人も居るだろ

後者のようなのをsvnでやってるときはifdefやコメントアウトのほうが便利だし
そんなにブランチいらんだろと思ってたが、
gitに慣れてくるとブランチとマージのコストが低いからちょいちょいブランチ切るようになった

859 ：デフォルトの名無しさん：2014/02/15(土) 22:48:41.33

> gitに慣れてくるとブランチとマージのコストが低いから

これに尽きるなぁ。結果として作業中のコミットの頻度も上がるんだよね。良い意味で。
コミットするたびにコンフリクトやマージを気にする必要があり、かといって細かい単位で
トピックブランチを切る文化もないsvnだとどうしてもコミットの間隔が長くなる。

860 ：デフォルトの名無しさん：2014/02/15(土) 22:55:42.18

それぞれ若干用語の意味がズレるからアレだけれども
枝を分けたり、それらをマージすることに対する敷居が
Subversionに比べてGitもMercurialもすんごい低いんよね

861 ：デフォルトの名無しさん：2014/02/16(日) 01:37:45.01

Gitだとブランチ作って作業、Mercurialだと名前もつけずにupdateで古い
チェンジセットに戻してそこに積み上げることもできるし、
頻繁に行き来したり最後にまとめたりする時はmqが便利だよね

SVNは昔使ってたけど、ローカルで使っててもGitやMercurialに比べて動作が遅すぎたよ

862 ：デフォルトの名無しさん：2014/02/16(日) 01:46:26.92

手法20個も試したことないわ

863 ：デフォルトの名無しさん：2014/02/16(日) 03:55:11.27

mqって

864 ：814：2014/02/16(日) 11:38:40.28

>>841
リポジトリを作るのが手間
git/hgなら今ローカルにあるフォルダをそのままリポジトリにできるじゃん？
svnはリポジトリ自体の配置設計をしなければならないのがめんどい

865 ：デフォルトの名無しさん：2014/02/16(日) 15:35:35.12

そんな必要ないけどパラレルワールドに生きてるのかな(笑)

866 ：デフォルトの名無しさん：2014/02/16(日) 15:56:10.10

だな

867 ：デフォルトの名無しさん：2014/02/16(日) 16:01:09.30

なんだ？SVNはリポジトリ作らんでもいいようになったのか？

868 ：デフォルトの名無しさん：2014/02/16(日) 16:18:55.42

作業コピーとリポジトリが別の場所なのが嫌だってことなんじゃ

869 ：デフォルトの名無しさん：2014/02/16(日) 16:32:18.81

git/hg/bzrをメインで使っている人にとっては
svnは枯れていることに意義があるので
svnの進歩には興味ないどころか
余計なことしやがってと思っていても不思議ではない

870 ：デフォルトの名無しさん：2014/02/16(日) 17:00:59.91

>>865
kwsk

871 ：デフォルトの名無しさん：2014/02/16(日) 17:40:14.45

自分が管理しているわけでもないSVNリポジトリ触るのって苦痛じゃない？

872 ：デフォルトの名無しさん：2014/02/16(日) 18:24:58.38

ソースコード管理するのにローカルにリポジトリ作れるのは大してメリットないと思うな
UNIXのドットファイルみたいな設定ファイルを管理する場合はローカルに作れるといいかも

873 ：デフォルトの名無しさん：2014/02/16(日) 18:38:07.68

ローカルにリポジトリ作れてありがたがっている人を前にして
その発言に何の意味があるんだ？

874 ：デフォルトの名無しさん：2014/02/16(日) 18:40:44.14

新しいプログラムを作り始めるときに、ローカルリポジトリから始められるのはすごくいい。

875 ：デフォルトの名無しさん：2014/02/16(日) 18:48:56.80

~/repos/projectA/

これだけの話だろ
なんで同じ場所だといいんだ？
ドットファイルもシンボリックリンクでいいじゃん

876 ：デフォルトの名無しさん：2014/02/16(日) 18:53:55.63

VCSはバージョン管理の道具であると同時に共同作業のためにも使われるあたりも議論が
ごっちゃになりがちな原因だと思う。
「一人で開発しているのでVCS不要」とか。

877 ：デフォルトの名無しさん：2014/02/16(日) 19:00:46.06

>>875
そのprojectAって名前を他のリポジトリかぶらないように考えるのすら面倒

878 ：デフォルトの名無しさん：2014/02/16(日) 19:03:13.87

>>864
同意するけど、毎日リポジトリを作る訳じゃないし、そんなに大きな違いか？

879 ：デフォルトの名無しさん：2014/02/16(日) 19:08:00.84

>>878
頻繁にやるわけじゃないからこそさ、
いざリポジトリ作ろうと思ったとき git init だけで作れるのがいいんだよ

880 ：デフォルトの名無しさん：2014/02/16(日) 19:13:49.67

Subversionで管理してた計1GBぐらいの画像ファイルの管理をMercurialに移行したら
レスポンスが速くなったよ
たいした機能は使ってないけどね

881 ：デフォルトの名無しさん：2014/02/16(日) 19:47:06.74

gitとhgってどっちがいいんだろう

882 ：デフォルトの名無しさん：2014/02/16(日) 19:51:20.54

Mercurial良いよと言いたいところをグッとこらえて素知らぬ顔でいやぁ～gitが
グローバルスタンダードですよねとか言ってみる。

水銀たん・・・

883 ：デフォルトの名無しさん：2014/02/16(日) 20:16:04.00

>>877
だな

884 ：デフォルトの名無しさん：2014/02/16(日) 20:20:17.44

>>880
そ、それは、、、
分散型と最も相性の悪い事の一つでは…

885 ：デフォルトの名無しさん：2014/02/16(日) 20:24:11.69

>>884
880だけど、俺以外が更新する事なんか、滅多にないから大丈夫だよ
実際、かち合った時にどうなるのかは体験してないから、よくわからん

>>882
コードの管理で言うと、一般企業にはMercurialが、オープンソースプロジェクトにはgitが向いている
たぶんね

886 ：デフォルトの名無しさん：2014/02/16(日) 20:29:46.21

>>878
俺は手軽だからこそリポジトリ化する頻度が上がったな
会社の方針で共有ソースコードはSVNだけど、個人pc内にあるほとんどの自作物(検討ソースコードやofficeドキュメント類も)をhgで版管理してるよ

887 ：デフォルトの名無しさん：2014/02/16(日) 20:33:15.81

>>884
どうして分散型と相性が悪いの？

888 ：デフォルトの名無しさん：2014/02/16(日) 20:46:25.80

>>884
分散型はリポジトリ全体をコピーするからかな
巨大ファイルを入れてしまうと、そこからのクローン全部に入ってしまう
また画像のようなバイナリファイルは差分を取りにくいので版を重ねるたびに巨大になっちゃうとか

だから>>885さんのように一人で使う分には問題ないよ
その場合「分散型」自体の意味が無いけど、それでも一人でgit/hgを使うメリットはあると思う

889 ：888：2014/02/16(日) 20:46:59.62

すまん
>>888は>>887宛ね

890 ：デフォルトの名無しさん：2014/02/16(日) 21:20:47.03

>>888
880だけど、Mercurialにはlargefiles拡張っていう、でかいファイルは最新版しかコピーしない機能があるよ

で、クライアントにTortoiseHG使ってると、ファイル追加する時に
「当然使いますよね」的なダイアログを出してくるので、その機能使ってる

891 ：デフォルトの名無しさん：2014/02/16(日) 23:26:40.46

>>890
それは知っているけど、それはmercurialが分散型の弱点の一つをカバーする為に集中型の特徴を部分的に取り入れただけだよ
原理的に分散型の苦手部分だという事に変わりはないよ
まあ、分散型・集中型できっちり区分けする必要も無くて、ツールとしては良いとこ取りして進化していってくれたらそれで良しだけどね

892 ：デフォルトの名無しさん：2014/02/16(日) 23:28:16.22

gitのHEADが参照してるBLOBだけDLしてくれればな

893 ：デフォルトの名無しさん：2014/02/17(月) 00:01:54.46

SVNも最近のバージョンはマージのコスト下げるために色々やってるね。
あとは前々から予告されているローカルコミットさえ実装されてくれれば・・・。

894 ：デフォルトの名無しさん：2014/02/17(月) 00:13:28.67

SVNや分散型のそれぞれのいいとこ取りしたVCSが出てくればいいのにね

895 ：デフォルトの名無しさん：2014/02/17(月) 02:58:44.41

gitのコマンド体型って誰が考えたんだろう
^^とかさ

896 ：デフォルトの名無しさん：2014/02/17(月) 03:04:49.52

ああいうのは頭のいいバカが考えたものだと相場が決まっておる

897 ：デフォルトの名無しさん：2014/02/17(月) 05:42:00.62

>>893
> あとは前々から予告されているローカルコミットさえ実装されてくれれば・・・。

ほんとそれ

898 ：デフォルトの名無しさん：2014/02/17(月) 06:04:56.80

svnのアップデートを待つよりもうそれMercurialで良いのではないかと思うw

899 ：デフォルトの名無しさん：2014/02/17(月) 08:54:18.94

Mercurialは土方でも使えるよ

900 ：デフォルトの名無しさん：2014/02/17(月) 12:34:20.79

土方歳三

901 ：デフォルトの名無しさん：2014/02/17(月) 13:05:41.22

Mercurial推しの奴が（見た目）大いんだが、そんな流行ってるのか？

902 ：デフォルトの名無しさん：2014/02/17(月) 13:14:12.72

分散型は、gitとhgの2強時代だと言っていいんじゃないの？
公式採用とかは、gitやや優勢かなと思うけど、誤操作での被害を考えると個人的にはhgを推したい気はする。
俺は、unicodeファイル名への対応をどうするかで決めたいと思ってまだ様子見。

903 ：デフォルトの名無しさん：2014/02/17(月) 13:51:25.96

git>>>>>>>>>>>>>>>>>hgでしょ

904 ：デフォルトの名無しさん：2014/02/17(月) 13:52:25.53

SourceForge.JPの作業部屋って言う個人リポジトリだとhg使えるらしいしそこで試してみるは

905 ：デフォルトの名無しさん：2014/02/17(月) 14:06:15.80

gitもhgも試すだけなら自分のPCだけでできるだろ

906 ：デフォルトの名無しさん：2014/02/17(月) 15:00:13.28

mercurialってgithubみたいなのあるの？

907 ：デフォルトの名無しさん：2014/02/17(月) 15:00:33.60

ああいうリポジトリサービスは
どうでもいい個人が登録して使ったらアカンやろ

908 ：デフォルトの名無しさん：2014/02/17(月) 15:01:52.89

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

909 ：デフォルトの名無しさん：2014/02/17(月) 15:04:14.92

>>907

Comparison of open-source software hosting facilities - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities#Available_version_control_systems

910 ：デフォルトの名無しさん：2014/02/17(月) 16:15:17.98

全体的にはhgが好きなんだけど、日本語ファイル名の扱いがいつまで経ってもウンコなのと
名前付きブランチをマージした後の扱いが気に入らない。

911 ：デフォルトの名無しさん：2014/02/17(月) 16:29:14.08

gitの方がより複雑で、svnからの移行はhgの方が多少しやすいと思う
あと、gitはwindowsクライアントがろくなのない

912 ：デフォルトの名無しさん：2014/02/17(月) 16:38:10.99

gitが複雑・・・？

913 ：デフォルトの名無しさん：2014/02/17(月) 17:11:59.92

>>906
つbitbucket

914 ：デフォルトの名無しさん：2014/02/17(月) 17:13:56.92

俺もhg押し派なんだけど、ネット上に存在する日本語の資料の量は圧倒的にgitの方が多いよね

915 ：デフォルトの名無しさん：2014/02/17(月) 17:16:24.47

>>907
kwsk

916 ：デフォルトの名無しさん：2014/02/17(月) 19:13:07.50

誰かがhgを分かりやすく解説してくれないとな
文才のある奴じゃないと

917 ：デフォルトの名無しさん：2014/02/17(月) 20:45:52.81

ここではhg押しが多いのにスレが全然進んでない不思議
http://toro.2ch.net/test/read.cgi/tech/1321109748/

918 ：デフォルトの名無しさん：2014/02/17(月) 20:50:31.81

ROMりにいってやるよ

919 ：デフォルトの名無しさん：2014/02/17(月) 21:14:53.07

gitはgithubで名前が知れたからな
けど、俺はhgの方がsvnの次のステップとして適してると思う
ま、svnで十分だったらsvnのままでもいいが

920 ：デフォルトの名無しさん：2014/02/17(月) 21:20:10.52

GitとHg共通の機能や操作に使用感の違いはあります？

921 ：デフォルトの名無しさん：2014/02/17(月) 22:40:57.29

>>920
hgにはステージが無い

よね？

922 ：デフォルトの名無しさん：2014/02/17(月) 23:03:14.20

ブランチの扱いが随分違うな
gitじゃメモ代わりにブランチ作ったり消したりできるぐらいお手軽なものだけど
hgでは名前つきブランチっていうのはある程度計画的に作るべきものなのか

923 ：デフォルトの名無しさん：2014/02/17(月) 23:04:59.43

hgのほうがいろいろ縛りが厳しい

924 ：デフォルトの名無しさん：2014/02/17(月) 23:57:36.51

hgだと作業途中での変更が大変そうだし他のとこ見ても
Gitのほうがスッキリ作業できそうなのでGit使い続けることにします
レスありした

925 ：デフォルトの名無しさん：2014/02/17(月) 23:58:18.81

コミットメッセージ書くの面倒臭すぎて「ちょっと修正」とか「いろいろ変更」にしてしまう
一人で趣味でやってるだけだから周りに迷惑かけてないからこれでいいけど
みんなはこんな面倒なことしてるのかな

926 ：デフォルトの名無しさん：2014/02/18(火) 00:07:15.10

gitならブランチ分けて、途中までは「作業中」でコミット、
最後にmerge --squashするときに、ちゃんと書く…とか
hgならmq使うとか、色々やり方はあるかと

927 ：デフォルトの名無しさん：2014/02/18(火) 00:26:39.07

>>922
そもそも、Subversionのブランチ並のことやらん限りブランチ要らんかと

928 ：デフォルトの名無しさん：2014/02/18(火) 00:29:52.35

>>925
もっと細かい修正でコミットすればよくね？
あとで見返したときに「ちょっと修正」や「いろいろ変更」で中身が思い出せるエスパーなら止めはしないけども。

929 ：デフォルトの名無しさん：2014/02/18(火) 00:32:33.78

複雑な樹形ブランチを管理保存出来るなんてvcs凄いわ。

930 ：デフォルトの名無しさん：2014/02/18(火) 00:59:34.79

>>928
そもそもコミットが面倒臭い
理想は機能一つ、修正一つ毎にコミットなんだろうけどうまく出来ないんだよな

931 ：デフォルトの名無しさん：2014/02/18(火) 01:07:07.35

作業する前に何の作業をするのか言葉にしてから作業を開始しろ

932 ：デフォルトの名無しさん：2014/02/18(火) 01:08:06.33

俺の集中力も分散型

933 ：デフォルトの名無しさん：2014/02/18(火) 01:26:47.81

そもそも機能と修正ごとにブランチ切るべき

934 ：デフォルトの名無しさん：2014/02/18(火) 01:52:46.77

>>930
hgならmqで簡単な名前だけ入れて残して、細かい修正は行ったり来たりしながら作って、
後で整理してきれいなコミットにするんだよ

935 ：デフォルトの名無しさん：2014/02/18(火) 01:55:38.24

Update hoge.c and create hoge() in hoge.c

hoge()関数を実装した
------------------

Update hoge() in hoge.c for bug fix

hoge()関数のゼロ除算するバグを除いた

------------------

Update hoge() in hoge.c for format

hoge()関数のif文からswitch文に直して処理の流れを分かりやすく整形した

936 ：デフォルトの名無しさん：2014/02/18(火) 01:59:29.83

hgはiOS、gitはandroidって感じ

937 ：デフォルトの名無しさん：2014/02/18(火) 02:03:36.37

ググって見たが、hgのmqややっこしいな
gitで普通にコミットしてrebase -iで順番入れ替えるほうが簡単でいいわ

938 ：デフォルトの名無しさん：2014/02/18(火) 02:05:40.52

ブランチ作らずに一本道で見るのは一番最後にコミットしたものだけって使いかたしてるけど
これならsubversionの方がいいんだろうな

939 ：デフォルトの名無しさん：2014/02/18(火) 02:07:59.94

>>938
本当に「見るのは一番最後にコミットしたものだけ」ならバージョン管理いらん

940 ：デフォルトの名無しさん：2014/02/18(火) 02:23:26.20

作業時間を測りたいから
作用開始コミットと終了コミットを打つ

941 ：デフォルトの名無しさん：2014/02/18(火) 02:35:08.34

機能ごとにコミットしてきちんとコミットメッセージ書くのがいいけど、面倒だからな
TortoiseSVNはコミットメッセージか空でもエラーにならないよね
その運用で困らないならそれでいいと思う

942 ：デフォルトの名無しさん：2014/02/18(火) 02:51:52.80

>>904
そんなくだらん目的のためにリソース食うバカは死ぬべき

943 ：デフォルトの名無しさん：2014/02/18(火) 04:11:57.57

>>930
だからgit merge --squashやMercurial Queueじゃあかんの？

944 ：デフォルトの名無しさん：2014/02/18(火) 04:17:19.57

hgに関するブログ記事ってのは古すぎて現状に即してないのが多いかな。

>>937
MQって最近はほとんど使う必要ないよ。拡張機能で対応できる。
ブランチの派生元の変更がrebase、コミットの順番入れ替えがhistedit

履歴編集関係でhgにあってgitにない良い機能にフェーズってのがあって
ローカルでコミットしただけの変更はフェーズがdraftになっていて、
pushすると自動的にpublicに変わる。
publicになると編集できなくなるので、うっかりpush済みの部分を編集しちゃった
なんてミスが起きない。

>>922
実はhgの無名ブランチと、gitのブランチが構造的には全く同じもの。
メモ代わりにブランチ作ったりするなら、そもそもhgは名前を付ける必要もない。
枝を生やしたい根本に移動してコミットしたら枝ができる。
また、hgにはブックマークって機能もあって、これがgitのブランチと全く同じもの。

>>924
stashのことなら、hgにもshelveってのがあるけど、hgならむしろ作業途中で
コミットしてしまって無名ブランチで移動する方が手軽かも。
作業途中のブランチをpushしたくなければ、フェーズをsecretにしておく。

945 ：デフォルトの名無しさん：2014/02/18(火) 04:17:49.62

安価ミス？

946 ：デフォルトの名無しさん：2014/02/18(火) 04:32:58.80

三日も経てばコマンドを忘れてしまってまた学習し直し
よってフォルダコピーで済ませるようになった
バージョン管理ソフトはメリットに比して学習・運用コストが高すぎる

947 ：デフォルトの名無しさん：2014/02/18(火) 05:05:52.72

使用頻度の低いコマンドも覚えようとしてんじゃねえの

948 ：デフォルトの名無しさん：2014/02/18(火) 05:11:36.67

いやメインのコマンドだよ
三日くらい集中して開発してふう一息って感じで
コミットするスタイルだから
その間に忘れてしまうんだ

949 ：デフォルトの名無しさん：2014/02/18(火) 05:12:58.44

３日に１回は低頻度だろ

950 ：デフォルトの名無しさん：2014/02/18(火) 05:14:59.05

コマンドじゃなくバージョン管理の一連の流れを覚えるのが大事であってだな

951 ：デフォルトの名無しさん：2014/02/18(火) 08:32:41.87

>>946
そんな記憶力でソースなんて書けるんか？
printf ってなんだっけ、とか言ってそう (w

952 ：デフォルトの名無しさん：2014/02/18(火) 09:00:48.28

普段会社ではMercurialなので時々思い出したようにgitやsvnを使う必要があるときは
細かいコマンドをウェブで検索してしまうな。

953 ：デフォルトの名無しさん：2014/02/18(火) 09:53:58.65

そういう人のためのGUIフロントエンドですよ
別にコマンド丸暗記しなくたって、恩恵は受けられる

954 ：デフォルトの名無しさん：2014/02/18(火) 10:37:43.29

IDE組み込みじゃないとなかなか使ってくれない・・・

955 ：デフォルトの名無しさん：2014/02/18(火) 11:37:58.48

そゆのはバッチ書いてやれば楽になるぞ>>946

956 ：デフォルトの名無しさん：2014/02/18(火) 12:32:31.92

>>955
同意するわ。
コマンド覚えられないならg.shのようなスクリプト書いて流れ作業全部をスクリプトに暗記させればいいだろ。
実際おれはコマンド辞典の丸暗記なんかしてないよ。暗記作業はpcに任せて自分は最大限に手を抜くのが正義だと思ってるわ。
沢山のコマンド名を暗記して人間百科事典みたいな事してるやつは、頭はいいとは思うけど、バカだな。と思うわ。

957 ：デフォルトの名無しさん：2014/02/18(火) 12:36:09.70

そしてスクリプトの名前を丸暗記してるのですね

958 ：デフォルトの名無しさん：2014/02/18(火) 12:48:04.67

>>944
hqの無名ブランチがgitのブランチと構造的に同じだとしても
好きな名前付けられないんならメモ代わりにはならないんじゃないの？

mq使う必要無いって、このスレでmq、mq言ってるやつは何なんだよ

959 ：デフォルトの名無しさん：2014/02/18(火) 15:32:27.24

mq は、TortoiseHg Workbench が対応してやっと理解できた。
今はめっちゃ使ってる。
なくても困りはしないけど。

960 ：デフォルトの名無しさん：2014/02/18(火) 15:50:58.13

GUIは色々なリビジョンの変更履歴を確認したりrebaseしたりと、コマンドラインだと
リビジョン番号を手打ちする必要のある作業のときに特に重宝するな。
SourceTree楽だ。

961 ：デフォルトの名無しさん：2014/02/18(火) 17:29:53.07

>>957
シェルの補間機能がうまく働くような名前にしとくといいよ

962 ：デフォルトの名無しさん：2014/02/18(火) 17:36:37.93

昔のおっさんには、人間アセンブラな人、マシンのブートコード丸暗記してる人がいたらしい。

963 ：デフォルトの名無しさん：2014/02/18(火) 17:39:12.64

現代のゆとりにはミリ

964 ：デフォルトの名無しさん：2014/02/18(火) 17:42:55.79

もうゆとり教育終わってるんだけどな

965 ：デフォルトの名無しさん：2014/02/18(火) 17:46:18.09

ゆとり教育終わってから小学校に入った人はまだ高校生
途中で終わった人はどういう扱いなんだろ

966 ：デフォルトの名無しさん：2014/02/18(火) 17:47:14.14

>>958
いや、そのレス先に書いてあるように、bookmark機能を使えば、gitと同じ状態になる。

967 ：デフォルトの名無しさん：2014/02/18(火) 17:57:20.59

gitのブランチと同じってことはそのままリモートにpushできるのか

968 ：デフォルトの名無しさん：2014/02/18(火) 19:17:09.24

>>962
昔のおっさんといっても、その辺のレベルの人現役で結構いるけどな。
ハードに近いところの仕事してると普通に会う。
で未だに現役な人達は50こえてるだろうに知識に貪欲で色々勉強しててびっくりする。
自分があの歳になってもああなれるか自信ないわ・・・

969 ：デフォルトの名無しさん：2014/02/19(水) 01:28:24.23

>>957
スクリプトのショートカットを好きなところに置いておけばクリックするだけなんだよ
ターミナル開く必要もない
スクリプトにヘルプ表示も付ければそのスクリプトのオプション覚える必要もない

ちなみにこれはどれも実際に俺自身が複数一度に処理できるように作って実践している

970 ：デフォルトの名無しさん：2014/02/19(水) 12:01:04.91

外部記憶の活用

971 ：デフォルトの名無しさん：2014/02/19(水) 23:34:27.90

posh gitやposh hgは良くできてる

972 ：デフォルトの名無しさん：2014/02/22(土) 03:39:52.07

バージョン管理もできないweb屋と仕事すると頭痛い

973 ：デフォルトの名無しさん：2014/02/22(土) 12:14:59.46

結構あるからな。
自分だけでもバージョン管理しとくといいよ。

974 ：デフォルトの名無しさん：2014/02/22(土) 13:52:23.18

バージョン管理ソフトは
学習コストがけっこう高いからねえ
万人が使えるとは言えないのが痛いところ
将来はシステムが自動でバージョン管理してくれる
方向に進むと思う

975 ：デフォルトの名無しさん：2014/02/22(土) 14:27:11.73

>>974
vs2010のC#でプログラミング勉強しとります。
この環境でvcs使いたいんですが何が良いあるか？

976 ：デフォルトの名無しさん：2014/02/22(土) 14:29:10.63

gitで良いあるよ

977 ：デフォルトの名無しさん：2014/02/22(土) 14:45:22.37

VS統合ならAnkhSVNがまあまあ良かった

978 ：デフォルトの名無しさん：2014/02/22(土) 14:53:29.42

2010だとGitサポートは無いのか

979 ：デフォルトの名無しさん：2014/02/22(土) 15:40:13.53

2013からどす

980 ：デフォルトの名無しさん：2014/02/22(土) 15:59:35.64

そういえば、MSがGitを取り込むんだったっけ
よく知らんけど、今のバージョンなら使えるの？

981 ：デフォルトの名無しさん：2014/02/22(土) 16:01:38.53

MSは日本のソフトウエア業界を蹂躙したインベーダー。

982 ：デフォルトの名無しさん：2014/02/22(土) 19:05:48.95

>>974
> 将来はシステムが自動でバージョン管理してくれる
> 方向に進むと思う

それはない。

なぜならバージョン管理ソフトというのは
ソフトウェアのバージョン（機能の違い）を
管理するためのものであって、ファイルのバージョンを
管理するものではないから。

ファイルのバージョンとソフトウェアのバージョンは一致しない
ファイルはコンパイルすら通らないような修正中であっても保存できる。
だがこれはソフトウェアのバージョンになるとは限らない。

ソフトウェアにおいてある機能が出来たとされるバージョン（＝コミット）
これを判断するのは人間しかできない。

983 ：デフォルトの名無しさん：2014/02/22(土) 19:11:52.99

gitにおいてはもはやバージョンを管理するものだけではなく
別のバージョンの機能の一部を取り込んだり、
ソフトウェアにおけるバージョンを綺麗に直すことも出来る。
こういうのは人間が判断することでシステムには無理。

984 ：デフォルトの名無しさん：2014/02/22(土) 19:20:09.37

VCSの用途としては共同作業ツールの側面もあるからね。

985 ：デフォルトの名無しさん：2014/02/22(土) 19:53:29.03

>>975
VC拡張でgitのがあるはず
公式なやつは2010でもあったと思う

986 ：デフォルトの名無しさん：2014/02/22(土) 19:54:56.26

ごめん逆、MS公式なやつはもっと先のバージョンだけど、非公式なやつは2010から

987 ：デフォルトの名無しさん：2014/02/22(土) 21:53:04.00

馬鹿がバージョン管理ソフトを使うと
普通考えられない使い方をすることがある
それなら使わない方が効率いい的な

988 ：デフォルトの名無しさん：2014/02/22(土) 21:54:08.37

そんなゴミはプログラマにしない方が効率が良い

989 ：デフォルトの名無しさん：2014/02/22(土) 22:03:15.00

「なんだかよくわからないけど動かなくなりました」
「なんだかよくわからないけど動くようになりました」
この必殺技に対する抑止力として、馬鹿にこそ使わせるべき

990 ：デフォルトの名無しさん：2014/02/23(日) 07:21:31.59

馬鹿に使わせると動かない状態をコミットして、動く状態をコミットしないんだよな。

991 ：デフォルトの名無しさん：2014/02/23(日) 07:22:23.70

VSのアドオンであるけど、普通にTortoiseHgとか組み合わせて使えばいいんじゃない

992 ：デフォルトの名無しさん：2014/02/23(日) 07:28:01.34

ソリューションディレクトリでgit initしてhttps://github.com/github/gitignore/blob/master/VisualStudio.gitignoreを入れておけばいい

993 ：デフォルトの名無しさん：2014/02/23(日) 12:27:56.48

>>991
やっぱり統合されてるのは便利だよ
Tortoise も便利なんだけどね

994 ：デフォルトの名無しさん：2014/02/23(日) 14:29:08.81

VCSがエディタ画面とうまく統合されてるとおそろしく快適だわ

995 ：デフォルトの名無しさん：2014/02/23(日) 17:20:44.78

バージョン管理システムをバージョン管理に使わない例を聞いて頭をかかえたことが

996 ：デフォルトの名無しさん：2014/02/23(日) 17:35:04.48

svnもhgも、IDEに統合された中途半端なやつ使うより、専用のTortoise*使った方が
使いやすいと思うわ。差分見るのも、ExamDiff Pro使って見たいし。

997 ：デフォルトの名無しさん：2014/02/23(日) 17:42:01.90

差分を確認する時とかブランチをどうこうする時は別の使うけど
VisualStudio上からすぐコミット出来るのは便利だった
コミットしてないファイルがどれかもわかるし

998 ：デフォルトの名無しさん：2014/02/23(日) 17:52:17.19

Tortoiseで操作するような部分はコマンドラインでいいや
それよりも、ソース編集するツールがVCSと統合されてdiffやblameを常時チェックできるような状態になってるのが嬉しい
いまIntelliJ IDEA使ってるんだけど、これで行単位のaddとかも編集画面でそのままできたら言うことはないな(できるのかな？)

999 ：デフォルトの名無しさん：2014/02/23(日) 17:56:46.68

>>997
え、差分確認せずにコミットしてるの？

コミットしてないファイルは、適切な無視ファイルパターン入れてれば、
Tortoise*でも自明でしょ？

1000 ：デフォルトの名無しさん：2014/02/23(日) 17:59:08.60

つづく！

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。