トップページ⇒tech
1001コメント265KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2012/04/19(木) 01:32:12.56
バージョン管理システムについて語りましょう

●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/
バージョン管理システムについて語るスレ8
http://toro.2ch.net/test/read.cgi/tech/1295493964/
0002デフォルトの名無しさん2012/04/19(木) 01:32:50.44
●関連スレ
CVS 1.3 [UNIX板]
http://toro.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://engawa.2ch.net/test/read.cgi/linux/1154701996/
Subversion r14 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1326806859/
Git 4
http://toro.2ch.net/test/read.cgi/tech/1329234309/
【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 3
http://toro.2ch.net/test/read.cgi/tech/1297704483/
0003デフォルトの名無しさん2012/04/19(木) 01:33:18.78
●関連サイト
CVS
ttp://ximbiot.com/cvs/wiki/ （消滅）
Apache Subversion
ttp://subversion.apache.org/
Git
ttp://git-scm.com/
Bazaar
ttp://bazaar.canonical.com/en/
Mercurial
ttp://mercurial.selenic.com/wiki/
Darcs
ttp://www.darcs.net/
GNU arch
ttp://www.gnu.org/software/gnu-arch/index.html
monotone
ttp://www.monotone.ca/
Visual SourceSafe （単体販売終了）
ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx

●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://subversion.bluegate.org/ (アクセスできない場合は↓) （消滅）
ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork （消滅）
Git入門
ttp://www8.atwiki.jp/git_jp/
git チュートリアル (バージョン 1.5.1 以降用)
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html
5分でわかるBazaar － Bazaar v2.6.0dev2 documentation
ttp://doc.bazaar.canonical.com/latest/ja/mini-tutorial/
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial
0004デフォルトの名無しさん2012/04/19(木) 01:34:43.24
テンプレ終わり
関連サイトのCVSとチュートリアルのSubversionは
移転情報があるなら次スレで直してください
0005デフォルトの名無しさん2012/04/19(木) 13:36:10.79
Perforce使ってる人いる?
転職した先の会社で使ってることが判明して。
0006デフォルトの名無しさん2012/04/19(木) 15:28:54.45
>>5
いちおう会社で使ってる。ほとんど GUI しか触ったことないけど。
0007デフォルトの名無しさん2012/04/19(木) 16:01:10.05
Perforce って cui あるの?
使い勝手はどんな感じなんだろう
0008デフォルトの名無しさん2012/04/20(金) 04:57:23.36
マニュアル読めよ
http://www.toyo.co.jp/ss/perforce/download_manual.html
0009デフォルトの名無しさん2012/04/20(金) 05:46:58.41
RTFM!
0010デフォルトの名無しさん2012/04/22(日) 21:27:33.14
>>6
p4vってやつですかね。最近知りましたw

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

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

まあ、バージョン管理システムとビルドのシステムがどう繋がっているのかにも
よるのかな。
0011デフォルトの名無しさん2012/04/27(金) 10:21:00.98
こういうよくわからないベンダのバージョン管理ソフトって開発者の頭越しで
導入が決められるんだろうなぁとふと思った。
0012デフォルトの名無しさん2012/04/27(金) 11:44:57.32
確かに、独自のバージョン管理ソフトとか持ってるところあるよなあ。
gitやhgを望まないまでも、とりあえず何も考えずにsvnにしとけば何の問題もないのに。
0013デフォルトの名無しさん2012/04/27(金) 15:55:27.75
svnも無茶な使い方してるとこはあって
なかなか何の問題もないともいえないのよね
馬鹿な連中の行動は予想を遥かに上まわるんだ
0014デフォルトの名無しさん2012/04/27(金) 21:00:18.54
こういうよくわからないソフトに慣れたやつが転職やら派遣やらで拡散してっ
て svn とかの無茶な使い方にも繋ってるんじゃないかと思ってる。
0015デフォルトの名無しさん2012/04/27(金) 21:18:49.99
いや、無茶な使い方は大抵ロートルから生まれると思う。
0016デフォルトの名無しさん2012/04/28(土) 01:46:23.39
ロートルもあるけどバージョン管理のことを
細かいとこまで覚えるのが面倒だと思う連中は多いのよ。
純粋に道具として見れば、まあある意味は正しいんだけど。
0017デフォルトの名無しさん2012/04/28(土) 04:33:46.65
>>11
Perforceのことなら、xcodeでも対応してた(過去形)りして
それなりにメジャな製品だと思ってたけど。
0018デフォルトの名無しさん2012/04/28(土) 11:01:41.20
最新のソース管理も出来ないのに便利な道具を使わないという人には困る。

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

ちなみにうちは受託開発しているけれど、社内規定では利用が規則化されていないので、
プロジェクトリーダー毎に好きなのを使っているかと思いきや、誰も使っていない。
0019デフォルトの名無しさん2012/04/28(土) 17:18:31.25
うちコンサルしてるけど、構成管理すらまともにできないのに、
最の新方法論（ｷﾘｯ で生産性あげようとするクライアントが多くて困るわ
最後にコードがｇｄｇｄになるなら技法とか方法論なんて効果ね－よ
0020デフォルトの名無しさん2012/04/29(日) 16:24:46.90
>>18
>フォルダ「プロジェクト名」（実はここが一番新しかったりする)

せめて「プロジェクト名-YYYYMMDD-追番」にしようよ。(w
0021デフォルトの名無しさん2012/04/29(日) 16:52:45.92
VCS使わないなら、日付をフォルダ名にするのが一番手軽で確実だよね
0022デフォルトの名無しさん2012/04/29(日) 17:39:23.14
確実なもんか。
コピーした日付けの奴と作成した日付けの奴が混ざって混乱するのが関の山だ。
0023デフォルトの名無しさん2012/04/29(日) 18:25:55.82
>>21
DropBoxとかに入れてしまえば、自動でバージョン管理できるんじゃね？
0024デフォルトの名無しさん2012/04/29(日) 18:40:05.93
>>22
>コピーした日付けの奴と作成した日付けの奴が混ざって混乱するのが関の山だ。

いったい何を作成した日付をつけるんだ？
さすがにそんなアホに付ける薬はないだろうなぁ。
0025デフォルトの名無しさん2012/04/29(日) 21:49:27.56
ダメなプロジェクトほど
フォルダツリーのコピーを作りたがる

で、最新という名のフォルダが最新じゃないという
0026デフォルトの名無しさん2012/04/29(日) 22:59:56.72
ほげプロジェクト_最新 - コピー
0027デフォルトの名無しさん2012/04/29(日) 23:21:22.21
最新のはずなのにVisualStudioプロジェクトファイルだけ更新されていたりする
0028デフォルトの名無しさん2012/04/29(日) 23:33:04.71
そしてフォルダの更新時刻がフォルダをコピーした時刻
（≠個々のファイルの更新時刻）
0029デフォルトの名無しさん2012/04/30(月) 00:07:18.13
フォルダ方式で管理しているうちの常駐先だと、バグ表に「先祖帰り」とかいう
項目があったｗ

さらに、ファイルをコピーしたつもりがムーブしてマスターファイルが
消えちゃったということが多いｗｗ
0030デフォルトの名無しさん2012/04/30(月) 00:54:36.00
>>29
>先祖帰り

それは別にフォルダ方式じゃなくてもよくあるタイプのバグじゃ?
と思ったがもしかして「先祖返り」と「先祖帰り」を区別して使っていたりして。
いいなあ先祖帰りバグ。
0031デフォルトの名無しさん2012/04/30(月) 03:15:09.10
Windows界隈ではVisualStudioの設定だけは手でやるのって普通なの?
すげえうざいんだけどあれ
0032デフォルトの名無しさん2012/04/30(月) 03:45:06.32
>>30
>それは別にフォルダ方式じゃなくてもよくあるタイプのバグじゃ?

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

先祖帰りは間違ってた
0033デフォルトの名無しさん2012/04/30(月) 09:42:47.93
>>31
VisualStudio の設定が何をさすのか知らんけど、
*.user とか *.suo はバージョン管理してはだめだよ。

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

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

TFS とか使えば、ここら辺は楽になるんだろうか。
0034デフォルトの名無しさん2012/04/30(月) 10:00:16.56
.slnは管理すべきだろ
0035デフォルトの名無しさん2012/04/30(月) 11:14:12.80
チェックアウトして何も考えずに .sln 開いてビルドできるレベルまではバージョン管理するでしょ
コンフリクトしたら素直に上書きで
0036デフォルトの名無しさん2012/04/30(月) 13:46:12.92
>>34-35
誰も管理するなとは言ってないよ。
管理するのに注意が必要って言ってるだけ。

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

みんなそういう経験ないのかなぁ…
0037デフォルトの名無しさん2012/04/30(月) 13:57:05.49
インクルードパスとかはVS2008までユーザ（開発者）が個別に管理する必要があったけど
VS2010からはもっと合理的に管理できるようになった

でファイルフォーマットとしては合理的になったが
IDEが生成するファイルが合理的じゃないので台無し
0038デフォルトの名無しさん2012/04/30(月) 14:00:23.04
ソースコードじゃないのにソースコードのように管理できないよって言われても困っちゃうよね
0039デフォルトの名無しさん2012/04/30(月) 14:16:57.78
>>36
経験の結果、設定のコンフリクトなら上書きが良いと気づいたのさ
0040デフォルトの名無しさん2012/04/30(月) 15:05:48.64
>>38
え゛っ、ひょっとしてソースコードしかバージョン管理してないとか？

>>39
いや、俺もコンフリクトしてしまったらそうするしかないと思う。
なので、なるべくコンフリクトしないようにしようと注意せざるを得ない。
VisualStudio が凝ったことしてないなら、もっと楽できたはずなんだが…
0041デフォルトの名無しさん2012/04/30(月) 16:08:31.11
VisualStudio やっぱ素直にはいかないのかな。
0042デフォルトの名無しさん2012/04/30(月) 16:54:04.37
ああ、色々書いてるけど、普通のソース管理は問題なく出来るよ。
ただ、ソースファイルの構成を変えたりするのにちょっと注意が必要というだけ。
0043デフォルトの名無しさん2012/04/30(月) 18:14:52.12
てかEclipseもNetBeansも似たようなもんでしょ
0044デフォルトの名無しさん2012/05/16(水) 23:35:14.51
XCodeだって管理ファイルのコンフリクトがおきたときはどうしようもないしね。
現段階ではIDE使うならしょうがないんじゃない？

その辺はソースほど頻繁に書き換えるものでもないんだから、
結局お互いにコミュニケーションとって解決するのが一番早いし問題が起こらないという結論に達した。
0045デフォルトの名無しさん2012/06/30(土) 12:02:29.43
Eclipse コミュニティサーベイ 2012
http://www.infoq.com/jp/news/2012/06/eclipse-survey

世の中git だねー
0046デフォルトの名無しさん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ではなく。
0047デフォルトの名無しさん2012/06/30(土) 19:45:36.78
最近バージョン管理を使い始めた人なのかな？
0048デフォルトの名無しさん2012/06/30(土) 20:07:52.85
コピペじゃね？
0049デフォルトの名無しさん2012/06/30(土) 20:13:57.97
rcsでも通用しそうな話だよな。
0050デフォルトの名無しさん2012/06/30(土) 20:17:23.05
gitは２年前から使い始めたから最近。

bugzillaレベルの場所ならgit://でアドレス貼れば補足無しで通じるし、外人は平気でewfanao34uo3no3n3jl23jjn3123j34jnここだとか言ってコミットID張り付けて一行レスだけだったりするのだけどそれで通じるから楽でいい。
しかし日本だとまだまだgit clone git://... ってフルコマンド書かないと通じない雰囲気なのが面倒（プログラム板ですらgit://だけだと半分くらいにしか意味が通じなさそうな不安を感じる）
もっとgitに普及してほしい。いちいち git log でcommit id の一覧を見て...的な説明添えるのが面倒くさいので。
0051デフォルトの名無しさん2012/06/30(土) 20:28:03.44
>>50
>フルコマンド書かないと通じない雰囲気
それで通じないとしたら、そいつはgit使ってないんだろ
かってに変な雰囲気作るな
0052デフォルトの名無しさん2012/06/30(土) 20:38:47.05
>>50
アスペなのは何年前からなのでしょうか？
0053デフォルトの名無しさん2012/06/30(土) 20:44:20.77
windows持ってないので分からないのだが、
相手がwindowsの場合だと、git環境整備が異常に大変そうな気がして気をつかってzipを用意する必要があったりで面倒。
最近のwindowsだとgitはどの程度簡単に使える？まだcygwin内限定とかの状態？それともlinux同様に普通に使える状態？
0054デフォルトの名無しさん2012/06/30(土) 21:23:24.19
>>53
GitHub for Windows でもバニラな環境は入るからそれで入れてしまえば
シェルからもひとまずは使えてそう困らない。
拡張や周辺ツールまで考えてるなら結局はCygwinやSFUみたいなのが楽かも。
実行ビットや改行コードや国際化ファイル名まで含めると微妙。
0055デフォルトの名無しさん2012/06/30(土) 23:25:52.50
msysgitが正式版でUTF-8ファイル名対応したからだいぶマシになったよね
0056デフォルトの名無しさん2012/07/30(月) 00:12:27.84
ExcelとかWordのドキュメントファイルまで含めてバージョン管理したい場合でも
svn使っとけば大丈夫なの？
いや、以前にそれをCVSでやろうとしてなんか痛い目にあった記憶があるので。

マージ考えない、排他ロックでいい場合は結局TFSが一番良いのかなーとも思う
んだけど、ソース以外のドキュメントファイル管理でもsvn使ってる人います？
0057デフォルトの名無しさん2012/07/30(月) 00:29:07.19
いるよ。
0058デフォルトの名無しさん2012/07/30(月) 00:34:29.05
>>56
CVSでドキュメント管理する場合の問題って、日本語ファイル名とか改行コードとかキーワード展開とか？
SVNならどれも問題ないはず。(ファイル名は設定が必要かも。)
0059デフォルトの名無しさん2012/07/30(月) 00:53:10.02
RCSで自由自在にバージョン管理できる奴だけが「TFSでいい」て言う資格があると思う
0060デフォルトの名無しさん2012/07/31(火) 03:20:59.77
SVNでVSの管理してるとうっかりやるのが、プロジェクトにファイル追加したときに
セーブせずに更新かけたときとかかな。

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


ファイルの追加なんで大した被害でもないけど。
0061デフォルトの名無しさん2012/08/01(水) 06:30:58.37
svn update する前に気をつける、くらいかな。
まめに保存する（ctrl-Sする）とか、ビルド前に自動保存するとか、
プロジェクトやソリューションの設定を変えたらすぐに保存するとか。
VSならAnkhSVN 併用したり、MS-Officeならmsofficesvnを併用したりとか。
0062デフォルトの名無しさん2012/08/01(水) 22:23:32.35
無難にsubにするかーと思ったが、なんとTeamFoundationServerに無料版が
出るらしいので折角だからTFSを選ぶことにした。
0063デフォルトの名無しさん2012/08/02(木) 00:07:22.73
>>61
> MS-Officeならmsofficesvnを併用したりとか。

ありゃ、こんなもんがあるんだ、ちょっと試してみようっと。
0064デフォルトの名無しさん2012/08/04(土) 11:26:19.97
会社が「VSSのチェックアウト管理台帳」使ってた…死にたい…
0065デフォルトの名無しさん2012/08/04(土) 13:45:32.83
　　　　　∧＿∧
　　　　　( ﾟωﾟ　)　チェックアウトは任せろー
　ｶｷｶｷＣ□l丶l丶
　　　　　/　　(　　 )　やめて！
　　　　 （ノ￣と、　ｉ
　　　　　　　　しーJ
0066デフォルトの名無しさん2012/08/04(土) 15:56:24.37
うちなんか日付と名前入りのディレクトリがいっぱいでバージョン管理システム使ってないorz
0067デフォルトの名無しさん2012/08/04(土) 16:19:11.74
>>64>>66
ああ、これは「本人も誰も改善要求せず50年後も同じ状態が続く」フラグだ…
0068デフォルトの名無しさん2012/08/04(土) 19:38:55.76
上が無能だとほんと苦労するよね
0069デフォルトの名無しさん2012/08/04(土) 19:45:48.51
無能でもいいんだよ、邪魔さえしなければ。

無能なくせに、有能と勘違いしてる上司がマジ邪魔。
0070デフォルトの名無しさん2012/08/04(土) 20:44:10.78
それは空気であって無能ではない
0071デフォルトの名無しさん2012/08/04(土) 23:26:41.49
>66
うちも以前はその状態だったが、俺が一人でバージョン管理システム導入して
他の人の代わりにコミットしてあげてたら、そのうち全員が使うようになった。
0072デフォルトの名無しさん2012/08/08(水) 23:38:03.31
ファイルのタイムスタンプで管理してる(´・ω・｀)
0073デフォルトの名無しさん2012/08/09(木) 04:22:28.21
それは最早管理とはいえない。
0074デフォルトの名無しさん2012/08/09(木) 08:03:52.96
>>71
素晴らしい！
0075デフォルトの名無しさん2012/08/23(木) 14:39:26.25
sf.netは10年たっても残ってそうだけど
githubが心配なんでsf.net使ってる
0076デフォルトの名無しさん2012/08/23(木) 15:27:42.29
やっぱりそれは言語がアレだからか？ｗ
0077デフォルトの名無しさん2012/08/26(日) 03:08:53.11
派遣先に行く -> 放置されているsvn鯖があるので使ってみる -> みんな使い出す
自社 -> （俺を除いて）だれも使わない

何だろこの差は
0078デフォルトの名無しさん2012/08/26(日) 09:22:42.68
githubは、gitベースのソーシャルコーディングという
スタイルに特化してる分、
そのスタイルが廃れれば、githubは消えるだろう。
そのときでもsf.netは、時久の流行りのシステムを
取り込んで生き延びると思う。
svnとかgitとか、今までもそうだったろ
0079デフォルトの名無しさん2012/08/26(日) 10:34:07.09
自分の感覚では、githubとかソーシャルコーディングは
定着した感が強いなぁ。
といってもgithubは数年しか経ってないんだよね。
それで、ここまで来るのも凄いけど。
0080デフォルトの名無しさん2012/08/27(月) 14:33:04.16
githubいいでえ～
簡単にfolkして修正してpull出来る。まじ簡単w
0081デフォルトの名無しさん2012/08/27(月) 15:12:47.38
githubの文化があと5年存続したら乗り換えよう
0082デフォルトの名無しさん2012/08/27(月) 15:38:45.89
結論：githubなんかに手を出すな！
0083デフォルトの名無しさん2012/08/27(月) 19:48:20.93
折角無料にしてくれたんだし、みんなでTFS使おうぜ
0084デフォルトの名無しさん2012/08/28(火) 14:06:06.78
githubいいでえ～
馬鹿発見器として
0085デフォルトの名無しさん2012/08/28(火) 14:10:58.34
そのうち2ch以外の全てが馬鹿発見器呼ばわりされるな
0086デフォルトの名無しさん2012/08/28(火) 14:18:42.13
>>85
マテ、2chはバカしかいないだろw
0087デフォルトの名無しさん2012/10/10(水) 20:52:03.98
bitbucketがシンプルなUIになって良い感じ
0088デフォルトの名無しさん2012/10/14(日) 12:52:30.79
>>86
2chは発見するまでも無いが、本人特定が難しいからなｗ
0089デフォルトの名無しさん2012/10/18(木) 15:34:07.37
「サーバの不要なバージョン管理システム」 って無いのかな
0090デフォルトの名無しさん2012/10/18(木) 15:44:16.47
ローカルでやるだけじゃん
0091デフォルトの名無しさん2012/10/18(木) 15:59:35.29
>>90
一人ならそれでいいけど、二人以上だとローカルじゃ済まない
0092デフォルトの名無しさん2012/10/18(木) 16:10:02.22
GitでもMercurialでも、共有フォルダでできるよ。
0093デフォルトの名無しさん2012/10/18(木) 16:10:40.43
>>92
そうなんだ、ありがとう
gitってサーバ立てなくてもいいのか
0094デフォルトの名無しさん2012/10/18(木) 16:31:55.96
共有フォルダだってローカルのうちだろ
0095デフォルトの名無しさん2012/10/18(木) 18:23:37.91
>>94
じゃあダメなの？
普通のファイルサーバを使ってバージョン管理したいんだけど
0096デフォルトの名無しさん2012/10/18(木) 18:27:07.11
サーバ不要でローカルで管理してるだけだろう。
そのローカルのファイルの置き場所がファイルサーバにあるだけだろ？
0097デフォルトの名無しさん2012/10/18(木) 18:36:28.26
svnはローカルでもロックファイル作るけど、gitはどうだっけな
0098デフォルトの名無しさん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が成功したように見えて実は失敗してたとか、面倒なことになる可能性がある

まで読んだ（超斜め読み）
0099デフォルトの名無しさん2012/10/19(金) 00:22:03.28
共有フォルダに作ってfile:でアクセスしていたリポジトリを
file:でアクセスできるようにしたまま、後からサーバ立ててgit:とかssh+svn:とかで配信することできる？
0100デフォルトの名無しさん2012/10/19(金) 12:00:52.54
svn でならやってる。
デスクトップでは file: で Checkout して、ノートでは svn://192.168... で Checkout してる。
リポジトリにどのプロセスがアクセスするかだけなんだから、できて当然じゃないかと思うけど。
0101デフォルトの名無しさん2012/10/19(金) 14:53:35.53
>>100
いや、チェックアウトとか、アクセスするプロセスとか関係無いし。

リポジトリを作る方法が同じならばできるし、違えばできない（だろう）ということ。
0102デフォルトの名無しさん2012/10/19(金) 21:53:39.87
>>89
Mercurial最高です。
0103デフォルトの名無しさん2012/10/19(金) 23:15:31.90
Bazaar最高！
0104デフォルトの名無しさん2012/11/04(日) 14:20:11.98
ぶっちゃけsfは広告の多さ、見づらさ、使いづらさ、レスポンスの悪さがピカイチすぎて
いまんとこGitHubに勝る点がないんだよな。なんかこう、強みが古いってだけ
0105デフォルトの名無しさん2012/11/16(金) 19:05:23.52
Windowsのドキュメント　フォルダをまるごとバージョン管理したいのですが
日本語ファイル名扱えるのってsvnしかないですよね
ローカルで管理したいのですが
仮想マシンにsvnサーバーたてるとかしかないのでしょうか
0106デフォルトの名無しさん2012/11/16(金) 19:09:02.08
bzrでも大丈夫だよ。
でも、オフィスのファイルなどのバイナリファイルが多いならDropbox辺りを使った方がいいかもしれない。
0107デフォルトの名無しさん2012/11/16(金) 19:26:03.15
同一pcで完結できるぞ
0108デフォルトの名無しさん2012/11/16(金) 19:58:58.07
svn は file:// とかでローカルリポジトリ作れた気がする
0109デフォルトの名無しさん2012/11/16(金) 20:55:28.45
bzrの日本語ファイル名対応は、互換漢字が全部直されてしまうから、異体字が区別できない
まあ気にならんだろうけど
0110デフォルトの名無しさん2012/11/16(金) 21:19:40.79
bzrは開発が止まったって噂があるが？
0111デフォルトの名無しさん2012/11/16(金) 21:32:36.13
うん。もう枯れた技術として忘れ去られる運命にある。
0112デフォルトの名無しさん2012/11/16(金) 23:02:49.38
枯れた技術ってわりとポジティブな使い方をされると思うけど
0113デフォルトの名無しさん2012/11/17(土) 00:10:22.26
TCPスタックなんかは枯れてないと怖くて使えないしね
0114デフォルトの名無しさん2012/11/17(土) 00:29:44.31
中身継ぎ接ぎだらけってのもあるからなぁ。
それまでのノウハウを元に一回作りなおしたほうがいいかとも思うものもある。
0115デフォルトの名無しさん2012/11/17(土) 01:45:59.22
今の msysgit (Git for Windows) はUTF-8公式サポートしてるから日本語ファイル名もOK
0116デフォルトの名無しさん2012/11/17(土) 07:30:15.37
>>115
でも結局バイナリ多そうなドキュメントまるごとバージョン管理には向いてないこと無い？
0117デフォルトの名無しさん2012/11/17(土) 11:18:57.90
gitは頻繁にマージすることを前提にしたシステムだから、バイナリを上手く管理するには向いてなさそう
0118デフォルトの名無しさん2012/11/17(土) 11:44:32.64
SVNはいまいちっていうか、日本だけダントツで使用率高いあたりガラパゴスしてきてる
世界に取り残されてる感ある

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

Git使ってみたけど、ブランチが全部インデックスだから早くて快適だったよ
マスターにプッシュしなけりゃいいわけだからローカルで複数作業を平行してしやすいのがステキ
0119デフォルトの名無しさん2012/11/17(土) 12:08:42.29
>>116-117
バイナリのサイズと比率が大きいならPerforceやAlienbrainの検討を、てなっちゃうかねぇ

>>118
BSD界隈になるとまだCVS使ってるところもざらだよ…
分散型はやっぱ「手元にレポジトリ持てる」＝「じっくりかつ気軽にcommit, amend, rebaseできる」のが大きいよね
0120デフォルトの名無しさん2012/11/17(土) 12:22:11.26
>>119
cvsだとCVSROOT切り替えや周辺ツールで手元にリポジトリミラーしたりして
意外と運用で回避できるし公式にgitミラーあったりするし
0121デフォルトの名無しさん2012/11/17(土) 12:50:58.96
やっぱり、日付フォルダが最強だろ
0122デフォルトの名無しさん2012/11/17(土) 13:04:40.47
>>121
君ぐらいの能力だとそうだろうね。
0123デフォルトの名無しさん2012/11/17(土) 13:23:19.70
>>122
お前の母ちゃんよりはマシだけどな
0124デフォルトの名無しさん2012/11/17(土) 13:25:33.21
小学生かよ…
0125デフォルトの名無しさん2012/11/17(土) 19:44:49.29
SVN環境でGitとかみたいな分散管理するいい方法ってないかな
最近運用都合(リリース作業とか)でコミット禁止になることが多くて、細かいコミットしたりがしづらくて適わん
ブランチは使い方わからないとかいってまったく使おうとしないし、いろいろアレすぎて…

やるとしたら、ローカルにSVNのリポジトリのミラー作って普段はそっち使って、
変更結果をマスターの作業フォルダーに手動でマージしてコミット、とかしかないかな…？
0126デフォルトの名無しさん2012/11/17(土) 20:08:51.48
よくしらんけど、git-svn とかを使えばいいんでないの？
0127デフォルトの名無しさん2012/11/17(土) 20:11:27.06
ローカルで git, merurial, bazzar を使い、subversionとの連携機構を使う。
全員でsubversionを止めてgit,mercurial,bazzar,perforceやbitkeeperにする。
更新が止まったsvkを使って何とかする。
svkを自分で引き継ぐ。
subversionの開発に加わって、分散バージョン管理機能の開発を手伝う。
0128デフォルトの名無しさん2012/11/17(土) 20:29:37.41
>>105
>Windowsのドキュメント　フォルダをまるごとバージョン管理
フリーなものならbzrってことでいいのかな？
0129デフォルトの名無しさん2012/11/17(土) 21:39:59.62
>>128
MSのTeamFoundationServerExpressでええやん。無料やし。
無料やし。
0130デフォルトの名無しさん2012/11/17(土) 22:17:52.03
分散が不要ならsvn一択だろ
Windowsへの対応も、バイナリファイルの扱いが一番上手いのもsvnだよ

いや一番かはわからんけど
0131デフォルトの名無しさん2012/11/18(日) 03:10:07.46
ブランチが使われてないなら、勝手に使って適当にマージすりゃいいんじゃね？
0132デフォルトの名無しさん2012/11/18(日) 03:27:10.29
ブランチって何ですか？
0133デフォルトの名無しさん2012/11/18(日) 04:00:47.98
>>130
バイナリ扱うならperforceが優秀svnはギガ単位の大きなファイル扱うにはちょっと重い
Alienbrainは興味あるんだが使ったこと無いので比較できない。
だれか両方使ったことある人がいたら簡単なレビューしてもらえると助かる
0134デフォルトの名無しさん2012/11/18(日) 04:51:46.23
Windowsって言ってるんだから、まともなのはTFSしか選択肢はないのでは？
0135デフォルトの名無しさん2012/11/18(日) 07:09:53.10
MS の製品が全てまともだと思ってるのか…

幸福な人生を歩んできたんだな。
01361252012/11/18(日) 11:07:23.41
勝手にインスコしていいとか、自分で使うためのブランチを切ってよければそれでよかったんだけど
SVNしかない状態でどうにかできないかなーと
やっぱ手はなさそうだし、手動マージする方向で考えてみるわ…
0137デフォルトの名無しさん2012/11/18(日) 11:43:29.52
>>127 がかわいそうだ…
0138デフォルトの名無しさん2012/11/18(日) 12:48:50.20
>>127は1行目は126とほぼ同じで2行目からはただのネタじゃ
>>125はSVN以外がインストール禁止のお堅い糞職場なんだろ

一番いい解決策は転職じゃねーのｗ
0139デフォルトの名無しさん2012/11/18(日) 13:45:29.93
今ならBazaarを自分の好きなように改造できるぞー
0140デフォルトの名無しさん2012/11/18(日) 14:28:48.08
>135 の頭の幸せさにﾜﾛｽｗ
0141デフォルトの名無しさん2012/11/18(日) 14:43:20.96
使ったこともないTeamFoundationServerを頭ごなしに馬鹿にするやつは、ほぼ底辺IT企業に勤めている。
0142デフォルトの名無しさん2012/11/18(日) 14:47:48.94
>>141
Windowsを使っているところが底辺IT企業では？
0143デフォルトの名無しさん2012/11/18(日) 15:21:46.47
Windows、Microsoftつー単語で思考停止する >142 みたいなのを雇ってるのが底辺IT企業ｗ

MSはOS「以外」には優秀なプロダクトが多い。VSとかExcelとか。
でもまあTFS使うかといわれるとちょっと微妙だけど。
多機能＆大きすぎて小回りが利かない。
0144デフォルトの名無しさん2012/11/18(日) 16:51:34.99
>>136
git-svnなどを自分のPCに入れるのをなんとか許可取れるよう説得してみたら？
サーバーに入れるわけじゃないし他人に迷惑かけないという辺りを説明して
0145デフォルトの名無しさん2012/11/18(日) 19:09:54.22
VSSは糞だろうが
0146デフォルトの名無しさん2012/11/18(日) 19:23:04.09
git-svnは糞
0147デフォルトの名無しさん2012/11/18(日) 22:57:39.73
>>145
いきなりどうしたの？VSSで時代が止まっちゃってる人？
0148デフォルトの名無しさん2012/11/18(日) 23:29:08.69
VSとVSSを勘違いしたんじゃないかと思う
まぁスレタイ的にVSとかはスレチだし仕方がない気はするｗ
0149デフォルトの名無しさん2012/11/18(日) 23:30:17.02
>MSはOS「以外」には優秀なプロダクトが多い。

に対するVSSは糞って意味だったんだが
0150デフォルトの名無しさん2012/11/18(日) 23:42:43.85
>>143
硬直した異様な操作性でExcelなんて最悪な部類だと思う。
Ctrl-Cを押した時のセルのまわりのちらちら四角形なんて殺意すら覚える。
スレチすまん。
0151デフォルトの名無しさん2012/11/18(日) 23:58:57.88
Excelを越える同系アプリが何一つ存在しない事実。
しかもExcelはバージョン管理にも大いに使えるしなー。

誰もが名前を知ってる大手カード会社のバージョン管理がExcelだった悪夢。
0152デフォルトの名無しさん2012/11/19(月) 00:05:03.29
>>136
だからよー。そのSVNでブランチ切れよ。
0153デフォルトの名無しさん2012/11/19(月) 22:51:56.19
勝手にブランチ切るのを許してないんだろ。
0154デフォルトの名無しさん2012/11/20(火) 01:43:13.39
どうしようもない状況なら転職が最良の解決策ってのは間違いではない
既存を常に正と信じきってしまってるところはどう頑張っても改善しようとしないからな
0155デフォルトの名無しさん2012/11/20(火) 07:40:23.22
2chのことか
0156デフォルトの名無しさん2012/11/24(土) 11:55:48.87
>>152-154
Mercurialのいいところは、他人を説得しなくてもいいことなので
よほどでかいソースじゃなかったら自分だけはさっさとMercurial化しちゃうのが吉。
これで仕事のストレスはかなり軽減された。
未だにCVSとかSVNとかやってられんが、Mercurial化を個人でやるには誰も困らない。
0157デフォルトの名無しさん2012/11/24(土) 12:12:23.98
別に SVN だって個人でやる分には誰も困らんと思うが…

まさかサーバー必須とか思ってないよね？
0158デフォルトの名無しさん2012/11/24(土) 18:57:03.47
旧式なCVSやSVNを使いたくないから、個人でなんとかできるか？って話だろ
頭沸いてるのか
0159デフォルトの名無しさん2012/11/24(土) 19:28:19.50
svn 嫌なら、git なりでローカルリポジトリ作ればいいだけだろ。

応用力もないのか？
0160デフォルトの名無しさん2012/11/24(土) 21:12:14.92
社内ネットワークがインターネットから遮断されてたり、
そうでなくとも自PCに何か入れようと思ったら管理者に申請＆許可が必要な職場もあるんだが
0161デフォルトの名無しさん2012/11/24(土) 21:21:46.40
うん、そういう職場は珍しくない、うちも許可が必要だし。

でも、そういう職場だと >>156 もだめだよね。
0162デフォルトの名無しさん2012/11/25(日) 01:01:06.89
ＳＶＮでも使いたくないとかそんなに便利なのかよ。

プロジェクトの規模がでかくてＳＶＮ遅くてたまんねぇってのはあるが。
0163デフォルトの名無しさん2012/11/25(日) 01:58:02.06
>>161 うん、>>156,159に向けて言ったんだ
>>162 分散型は実際、便利だよ。ローカルで気軽にコミットできるのとできないのとでは大違い
0164デフォルトの名無しさん2012/11/25(日) 19:23:22.96
日本は頭固い企業多いからな
しかも技術者の不勉強度も高い
SVNがいつまでも使われ続ける環境が多いのは、新しい技術に手を出す層がいないからだと思う
0165デフォルトの名無しさん2012/11/25(日) 22:21:44.26
>>161
そこだけは根性出すしか無い。
これは開発に必要なツールです（キリッ
0166デフォルトの名無しさん2012/11/25(日) 22:25:43.76
あんたが変えることを諦めたらその会社では30年後もsvnのままだぞ
0167デフォルトの名無しさん2012/11/25(日) 23:36:46.08
まて、お前がSVNを分散型に改造すれば良いんじゃないのか？
0168デフォルトの名無しさん2012/11/25(日) 23:38:45.15
svkを引き継いでくれたら嬉しいんだけど、svnがローカルコミットに対応するほうが早いんだろうなあ
0169デフォルトの名無しさん2012/11/26(月) 01:33:34.09
SVNを利用してるのはTortoiseSVNが神なうえに、バイナリにも強いからでしょ。
プログラマ以外がｴｸｾﾙとかコミットするのにもお手軽。

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

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

１度使ってみるか。
0170デフォルトの名無しさん2012/11/26(月) 06:40:31.57
Subversion で、チームのリポジトリと別に、ローカルにもリポジトリを作って作業してる。
それぞれに作業コピーを作って、ローカルのリポジトリの作業コピーで作業してる。
それぞれの作業コピー同士を WinMerge でマージして、それぞれに Update/Commit。
実験的ブランチをホイホイ切れるので気が楽。
0171デフォルトの名無しさん2012/11/26(月) 07:43:57.64
作業ミスしてお釈迦にする悪寒。
0172デフォルトの名無しさん2012/11/26(月) 08:35:08.16
VCS使ってるのはプログラマだけじゃないからなぁ

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

プログラマは当然git使いたがるけど、プログラマ以外の人達に
採用を納得させるだけのアドバンテージがsvnとgitの間には無いんだよな。
0173デフォルトの名無しさん2012/11/26(月) 10:33:20.39
公式用と俺様用で別のVCS使うと間違える可能性がかなり減らせていいぞ
0174デフォルトの名無しさん2012/11/26(月) 11:44:12.29
そういう意味ならgitの方が良くね？
0175デフォルトの名無しさん2012/11/26(月) 12:01:50.45
は？
gitはVCSじゃないとでも？
0176デフォルトの名無しさん2012/11/26(月) 12:04:23.78
svnよりgitの方がってことだろ。JK
そんなこと、>170以外はみんな判っていることだけどな。
0177デフォルトの名無しさん2012/11/26(月) 12:10:07.43
gitってバックアップにも使える？
ネットワークドライブ上のフォルダをレポジトリ？っていうの？
ローカルのディスクをワークスペース？ っぽくして
バージョン管理兼バックアップしたい
0178デフォルトの名無しさん2012/11/26(月) 12:33:10.84
ok
0179デフォルトの名無しさん2012/11/26(月) 12:39:28.91
ゲームのセーブデータのバックアップに最適

Gitの作業フォルダにゲームをインスコして、コミットしまくると完璧
0180デフォルトの名無しさん2012/11/26(月) 13:16:15.19
gitはバックアップとして使えないよ。
push -fすれば全部パー。
0181デフォルトの名無しさん2012/11/26(月) 13:21:10.94
そらそうよ
0182デフォルトの名無しさん2012/11/26(月) 13:56:44.23
SCMはSCMであってバックアップツールでもアセット管理ツールでもないからなぁ
0183デフォルトの名無しさん2012/11/26(月) 14:00:52.24
いや、「push -fすれば全部パー」だし、「rm -rfすれば全部パー」だよ
「SCMはバックアップツールにはならないけどちゃんとしたバックアップツールは別にあるので買いなさい」
は違うんじゃないかと
0184デフォルトの名無しさん2012/11/26(月) 14:02:01.96
resetしたら負け
0185デフォルトの名無しさん2012/11/26(月) 14:28:51.43
SCMとは別にバックアップしてたって、そのバックアップ先でrm -fしたら全部パーだろ
消去不能な外部メディアを使えってことなのか？

俺の場合gitのリポジトリは複数の場所に複製が勝手に作られるんで、
手元でpush -fしても全部パーにはならない
0186デフォルトの名無しさん2012/11/26(月) 14:30:00.64
>>185
> 俺の場合gitのリポジトリは複数の場所に複製が勝手に作られるんで、
> 手元でpush -fしても全部パーにはならない

？？？？？？？？？
0187デフォルトの名無しさん2012/11/26(月) 14:39:57.19
>186
馬鹿ですね
わかります

>185
ネットワークドライブ側のバックアップを世代管理しとけば良いだけの話じゃね？
0188デフォルトの名無しさん2012/11/26(月) 14:45:53.35
>>187
まあ、世代管理みたいなもんだよ
ただバックアップツールとか使わず、gitだけでやってるってだけで
0189デフォルトの名無しさん2012/11/26(月) 14:49:59.76
>>187
force updateをご存知ないようで
0190デフォルトの名無しさん2012/11/28(水) 18:22:11.64
結局、>>177みたいなことは出来るってこと？
0191デフォルトの名無しさん2012/11/28(水) 18:26:35.01
>>190
git gc(prune)でリビジョンが破棄されるということを知らない馬鹿が出来る信じていた。
0192デフォルトの名無しさん2012/11/28(水) 20:06:46.21
破棄されるのはrebaseとかしてどこからも参照できなくなったリビジョンだろ
根っこが勝手にpruneされたらそっちの方が問題だわ
0193デフォルトの名無しさん2012/11/28(水) 20:25:57.27
>>192
push -fしたら元のブランチのリビジョンが破棄される。
>>185 が具体的に何をしているかわかないが、fetchしているとしても、
そこでも元のブランチのリビジョン破棄される。
0194デフォルトの名無しさん2012/11/28(水) 21:07:33.23
特定の人のみがpushする、かつpush -fは使わないって運用前提なら問題無いのでは？
0195デフォルトの名無しさん2012/11/28(水) 21:15:14.15
じゃあ>>177みたいなのはできないってことか・・・
横着せずちゃんとした同期ソフト買うか
0196デフォルトの名無しさん2012/11/28(水) 21:59:53.10
馬鹿と鋏は使いよう
0197デフォルトの名無しさん2012/11/28(水) 22:03:37.12
いいこと聞いた
コミット権限持ってるあのレポジトリとかこのレポジトリとか全部push -fでぶっ壊してやろうかねぇｗ
0198デフォルトの名無しさん2012/11/28(水) 22:19:28.22
ブランチが消えても実際にコミットがgcで消えちゃうまではかなり時間があるから戻すのは簡単だし、
どこにもcloneされてない孤立して放置されたレポジトリでもない限り、
とくにダメージは無い。
0199デフォルトの名無しさん2012/11/28(水) 22:31:09.32
>>197
別にいいんじゃね
あんたに権限渡したプロジェクトが悪いんだから
0200デフォルトの名無しさん2012/11/29(木) 18:20:39.33
hgならpush -fしても何も消えることはないから安心
0201デフォルトの名無しさん2012/11/29(木) 18:45:20.94
gitのpushは次のリリースで仕様が変わるんじゃなかったっけ？
gitは使ってないからよく知らないけど
0202デフォルトの名無しさん2012/11/29(木) 18:52:12.85
git はpushの仕様が怖くて、試しで使ったプロジェクト限りで封印してる……
まだSubversionから離れられない……Mercurialのマルチバイト対応はまだか……
0203デフォルトの名無しさん2012/11/30(金) 12:29:12.65
Bazaar でいいじゃん。
0204デフォルトの名無しさん2012/11/30(金) 13:59:27.53
>>193
gitはpushされるほうがreceive.denyNonFastforwards = trueなら、push -f は拒否られるんじゃ無いの？
この指定も無視する方法あんの？
0205デフォルトの名無しさん2012/11/30(金) 14:16:38.19
>>204
つgithub
0206デフォルトの名無しさん2012/11/30(金) 14:31:42.33
>>205
自分で用意したリポジトリなら設定できるだろ？

あと、master以外はブランチごと削除して置き換えるとかできるから、
receive.denyDeletes = trueも設定しとけばいいのか
0207デフォルトの名無しさん2012/11/30(金) 18:56:50.16
gitとmercurialって、どっちが強いの？教えてエロい人
0208デフォルトの名無しさん2012/11/30(金) 19:07:37.70
イデオン
0209デフォルトの名無しさん2012/11/30(金) 19:28:19.12
最初の敷居の低さではhgだろ
gitは自由度が高すぎるというかVCSでは避けたいことも簡単に道を踏み外せるし
熟練者にとってはそれが魅力なんだろうが
0210デフォルトの名無しさん2012/11/30(金) 19:32:27.03
>>207
Bazaar
0211デフォルトの名無しさん2012/11/30(金) 21:19:32.52
gitは無茶やってもリカバリーできないことはほとんど無いし
ちゃんとリカバリーできたかどうかもわりとはっきり確認できるし
その辺まで仕組みが理解できればわりと快適
0212デフォルトの名無しさん2012/11/30(金) 21:25:42.03
>>211
ドカタにそれが理解できるのが何％いるのだろうか？
0213デフォルトの名無しさん2012/11/30(金) 22:01:15.78
チームにはアホもいるからmercurialと言いたいが
以前真性アホがいてsvnよりvssのほうが良かったとか言い出しやがったからな
0214デフォルトの名無しさん2012/12/01(土) 12:02:06.49
gitの敷居はVCSの中でも低い方だと思うの
0215デフォルトの名無しさん2012/12/01(土) 13:33:21.34
導入は楽だわな
アクセス制御もユーザーアカウントもないんだから
ただ、運用となると
アホがひとり混じる→誰かが直してあげる
と言うコストが発生してしまう
0216デフォルトの名無しさん2012/12/01(土) 13:40:51.55
アホには無理
0217デフォルトの名無しさん2012/12/01(土) 16:40:33.61
この業界アホが増えてきたからちょっとしたスキルが必要なものも採用に躊躇される、って会社は少なくない気はする
スキル重視な会社少なすぎじゃね…
0218デフォルトの名無しさん2012/12/01(土) 16:45:46.27
うちの会社でも検討したが、gitはややこしすぎて無理。
mercurialでもかなりギリギリって感じ。
0219デフォルトの名無しさん2012/12/02(日) 22:14:35.26
プログラマのチームだったら、そんな理解力でまともな製品作れるのかと思うことしきりだが、
まぁ俺マじゃないからどうでもいいや
0220デフォルトの名無しさん2012/12/02(日) 22:20:46.69
そして>>218の会社では大量の日付つきzipファイルが
0221デフォルトの名無しさん2012/12/03(月) 04:52:47.72
zipなら未だいいよ。
某所の開発用端末には日付けフォルダが多層化しちまってる。
カレントにある日付けフォルダごと別の日付けフォルダにコピーする馬鹿って何考えているんだろうね。
0222デフォルトの名無しさん2012/12/03(月) 05:24:26.25
自分の部屋も整頓できないタイプだな
0223デフォルトの名無しさん2012/12/03(月) 07:17:31.09
だから Windows 8 のスタートはあんな風になってしまったの
0224デフォルトの名無しさん2012/12/03(月) 13:46:59.08
subversion導入だけでも半年以上掛かったからなぁ。
mercurialは1年以上は掛かるな。
0225デフォルトの名無しさん2012/12/03(月) 13:48:37.53
年月がかかっても導入される事例はあるんだな
希望は捨てずにいようと思う
0226デフォルトの名無しさん2012/12/03(月) 18:11:47.18
何かBazzarが最近オチ担当みたいになってて笑える
>>218
プログラマだってツールへの習熟度は大事だって。
理解すれば大丈夫なことでも理解間違いがあってレポジトリが壊れると怖い。
壊れなくても復旧に時間が掛かる状況はなるべく避けたいし。
0227デフォルトの名無しさん2012/12/03(月) 19:58:50.06
Bazzar は変態用だからな
0228デフォルトの名無しさん2012/12/03(月) 20:21:14.95
っていうか技術に興味もたない職業マが増えすぎて、スキルレベルがわりと酷い
とくに中途半端な大手やそのグループ企業のマの質は劣悪
0229デフォルトの名無しさん2012/12/03(月) 21:13:25.05
いつと比べて増えたって言ってるんだ。昔から底辺は広かった。
0230デフォルトの名無しさん2012/12/03(月) 21:36:59.71
昔は、ある程度のスキルが有る連中しかバージョン管理システム使ってなかっただけだよね。
そんなのあるの知らない人が多かったという。
0231デフォルトの名無しさん2012/12/04(火) 09:08:20.99
VSSが馬鹿を増やした
0232デフォルトの名無しさん2012/12/04(火) 15:11:16.32
しかし、VSSでも神と呼ばれた時代があった。
問題は「VSSは良い物だ」と言う考えを変えられなかった人達にある。
数年前にMS自身がVSSを放棄したことで、このスレに来たって人も居るんじゃないかな？




俺だ
0233デフォルトの名無しさん2012/12/04(火) 19:35:16.00
VSSでもなんでも、バージョン管理してるだけで
してない連中の200倍は偉いだろ
0234デフォルトの名無しさん2012/12/04(火) 20:24:42.11
俺にとっては「21世紀のRCS」でしかないが、まあ使ってない奴らよりは少しだけマシ＞VSS
0235デフォルトの名無しさん2012/12/05(水) 01:19:55.57
GitがSVNを駆逐できないのってなんで？マイグレーションパスも用意してるのに。

日本語対応に問題があるのはわかるけど、英語圏でもまだまだSVNが使われてるよね。なんでだろう。
0236デフォルトの名無しさん2012/12/05(水) 03:59:01.72
移行コストに見合うメリットがないからじゃない
SVNで十分とも言える
0237デフォルトの名無しさん2012/12/05(水) 06:28:42.66
オフラインで作業する人がいない
0238デフォルトの名無しさん2012/12/05(水) 07:47:01.05
>>235
gitに移行することよるデメリットの方が大きいから
0239デフォルトの名無しさん2012/12/05(水) 07:50:17.18
デメリットｋｗｓｋ
0240デフォルトの名無しさん2012/12/05(水) 08:01:24.63
>>239
・ファイルのコピー・リネーム
・空っぽのディレクトリ
・ブランチの違い
0241デフォルトの名無しさん2012/12/05(水) 08:47:55.72
それが「大きいデメリット」なんだ、へー
0242デフォルトの名無しさん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.
0243デフォルトの名無しさん2012/12/05(水) 10:14:15.24
空っぽのディレクトリは確かに大きなデメリットだ
0244デフォルトの名無しさん2012/12/05(水) 11:29:08.07
ディレクトリに何かファイルを置くというバッドノウハウはあるけどな
0245デフォルトの名無しさん2012/12/05(水) 12:23:21.71
このディレクトリは削除しないでください.txt
0246デフォルトの名無しさん2012/12/05(水) 12:53:47.83
管理させてるソースがGPL汚染されそうで怖いとか？
0247デフォルトの名無しさん2012/12/05(水) 14:13:29.09
IDE組み込みの存在じゃない？
最新のやつを使えない事情があると、svnはあってもgit無かったりするし。
0248デフォルトの名無しさん2012/12/05(水) 14:21:15.47
なんだかんだ言って、Windowsで気軽にgitを使える環境が事実上存在しないのが問題。
0249デフォルトの名無しさん2012/12/05(水) 14:29:56.15
ちょっとググったんだが、WindowsではいまだにmsysGitしか無いのか？
0250デフォルトの名無しさん2012/12/05(水) 15:19:52.26
プログラマーにとってGitは便利だけどデフォルト状態で出来ることが多すぎて、スキルレベルがまばらな多人数チームでの運用は難しい。
プログラマー以外が多い職場ではGUIがまともなSubversionか、分散型ならデフォルトで出来ることが制限されているMercurialを使ってるとこが多いと思う。
個人的にはGitを使ってるけど「Gitだけあれば万能！」って事は今のところ無いと思う。
0251デフォルトの名無しさん2012/12/05(水) 15:27:49.81
>>240
追加
・ユーザーアカウント
・アクセス権制御(フォルダ単位ファイル単位)
・ファイルロック
0252デフォルトの名無しさん2012/12/05(水) 22:50:10.68
単に学習意欲がないからだろ
SVNもコミットとログ閲覧くらいしか理解してない奴ばかりだし
0253デフォルトの名無しさん2012/12/05(水) 23:02:49.19
日常的なワークフローが、コミットとログ閲覧で充分ならSVNから他へ乗り換える理由もないからな。
0254デフォルトの名無しさん2012/12/05(水) 23:21:37.39
それだけをうまくやれるフロントエンドあってもよさそうなもんだけどな
素のインターフェースを使ってもらうとステージングやマージではまってよく呼ばれる
0255デフォルトの名無しさん2012/12/06(木) 01:11:50.49
git submodule では svn:external の代替にならんので移行できずにいる。
0256デフォルトの名無しさん2012/12/06(木) 03:10:49.50
>>250
結局まともなGUIが無いことが大きいんだよな
デザイナにGUIが無いけど機能的にはいい物なんだなんて説得は通用しない

それに対してAlienbrainへの食いつきは凄かった。
まぁMayaやフォトショップ上で過去バージョンが確認出来るとか、
デザイナにとっては有効なものが多いから当然かもしれないけど。
0257デフォルトの名無しさん2012/12/06(木) 13:34:40.60
デザイナが作ればいいじゃん。
作らないでないないとか知らんわ。
プログラマは現状で問題ないし。
0258デフォルトの名無しさん2012/12/06(木) 15:28:41.51
世の中には想像を絶するアホがいるものだなぁ・・・・
0259デフォルトの名無しさん2012/12/06(木) 17:56:33.12
あるコミュニティにとって使いやすいものが別のあるコミュニティにとって使いやすいとは限らないだけのことだろ
M$ならcvsとsvnは恐ろしく使いやすいからな
俺はgitが必要になるようなことやらねえし

3年ほど前だがgitは導入が糞まんどかったが改善されたのか?
0260デフォルトの名無しさん2012/12/06(木) 18:35:02.03
>>259
3年ほど前: apt-get install git-core
今: apt-get install git
大幅な改善！
0261デフォルトの名無しさん2012/12/06(木) 18:54:15.37
>>259
> あるコミュニティにとって使いやすいものが別のあるコミュニティにとって使いやすいとは限らないだけのことだろ
> M$ならcvsとsvnは恐ろしく使いやすいからな
Bazaarは？
0262デフォルトの名無しさん2012/12/06(木) 20:49:13.11
コマンドラインだとなにもできないレベルのにわかコード屋も増えてきてるからなぁ
つってもGitでGUI欲しいならとーたすでいいんじゃないのって気がするけど
0263デフォルトの名無しさん2012/12/06(木) 20:55:24.79
コマンドラインで自慢とかw
0264デフォルトの名無しさん2012/12/06(木) 21:03:39.98
CLI使えない奴には自慢に聞こえてしまうわけですね
0265デフォルトの名無しさん2012/12/06(木) 21:05:12.11
CLI使えない奴には自慢に聞こえてしまうわけですねw
0266デフォルトの名無しさん2012/12/06(木) 21:10:13.53
大事なことなので
0267デフォルトの名無しさん2012/12/06(木) 21:18:17.47
CLI使えない奴には自慢に聞こえてしまうわけですねw
0268デフォルトの名無しさん2012/12/06(木) 21:22:03.32
顔真っ赤ですけど、そんなに悔しかったの？
0269デフォルトの名無しさん2012/12/06(木) 22:06:21.63
mercurialで日本語が使えないという誤解
Winで統一されてるならTortoiseHgが鉄板
0270デフォルトの名無しさん2012/12/06(木) 22:23:11.82
TortoiseHgはTortoise系の中では一番完成度が高いね
日本語ファイル名がUTF8で通るようになったら、Windows系の案件で使ってみたいところ
0271デフォルトの名無しさん2012/12/06(木) 22:25:27.01
>>270
TortoiseSVNよりも？
0272デフォルトの名無しさん2012/12/06(木) 22:30:54.24
>>271
うん
実はTortoiseHgってTortoiseの名前は付いてるんだけど、かなり拡張されててねｗ
別物と思った方がいいｗ
0273デフォルトの名無しさん2012/12/06(木) 22:48:59.61
>>269
ファイル名に「表」だとか「ロ」(カタカナ)が含まれてるとだめなんじゃない?
0274デフォルトの名無しさん2012/12/06(木) 22:53:18.88
>>273
それが誤解
0275デフォルトの名無しさん2012/12/06(木) 22:56:36.30
>273
ディレクトリ名の最後の文字が「表」「申」「能」だとだめだな
0276デフォルトの名無しさん2012/12/06(木) 23:01:05.50
>>275
それが誤解
0277デフォルトの名無しさん2012/12/06(木) 23:54:22.81
Macの日本語ファイル名も大丈夫なの(´・ω・｀)？
0278デフォルトの名無しさん2012/12/07(金) 00:12:49.71
俺の調査では、Subversionユーザのうち、ちゃんとrenameが出来る人は4割、
mergeが出来る人は1割しか居ない。
0279デフォルトの名無しさん2012/12/07(金) 02:41:38.80
うん。
よく「>>>>>」がついたままのファイルがチェックインされてるわ。
0280デフォルトの名無しさん2012/12/07(金) 19:46:42.54
コマンドライン操作って自慢する事だったのなﾜﾗﾀｗ

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

こんな職場じゃGitとか絶対無理だろうなーって思っちゃう
0281デフォルトの名無しさん2012/12/07(金) 20:22:54.02
＞Alertさせてデバッグ()してる馬鹿
そうやって人を見下す暇があったらだな…(呆
0282デフォルトの名無しさん2012/12/07(金) 20:54:21.87
馬鹿には無理
0283デフォルトの名無しさん2012/12/10(月) 15:12:29.69
printf("ここは通過\n");
0284デフォルトの名無しさん2012/12/10(月) 21:20:16.27
デバッガ繋げる環境でアラートデバッグとかはさすがにないわな。
0285デフォルトの名無しさん2012/12/11(火) 12:41:45.37
>>270
CVS のときも亀が吸収していたし、なんとかしてほしいね。Bazaar は望み薄だし。
0286デフォルトの名無しさん2012/12/11(火) 23:21:01.25
>>277
正規化はもう簡単な解決は諦めて、文字ごとにどれかに寄せて管理することにしないとダメなんじゃないかなぁ……
0287デフォルトの名無しさん2012/12/12(水) 21:21:48.75
>>285
望み薄どころか、Bazaar自体がもう開発終了してる
0288デフォルトの名無しさん2012/12/12(水) 22:57:19.76
ぼくBazaar好きだったんよ(´・ω・｀)しょぼーん
0289デフォルトの名無しさん2012/12/13(木) 15:18:27.07
TortoiseHg の日本語マニュアルだれも更新してないのか？
0290デフォルトの名無しさん2012/12/13(木) 23:15:19.25
簡単すぎていらんだろ
0291デフォルトの名無しさん2012/12/14(金) 16:07:26.26
>>287
Wikipediaより
> 最新版 2.5.1 / 2012年5月30日（6か月前）
> 最新評価版 2.6b2 / 2012年7月24日（4か月前）

終…了？
0292デフォルトの名無しさん2012/12/14(金) 16:48:14.58
それ英語出来ないアホが流したデマ
アンチTDDのロシア人が開発辞めるポストをML
でしただけ
0293デフォルトの名無しさん2012/12/14(金) 17:32:45.35
>>292
http://www.ohloh.net/p/bazaar
0294デフォルトの名無しさん2012/12/14(金) 17:38:41.70
>>292
https://lists.ubuntu.com/archives/bazaar/2012q4/075330.html

Canonicalから大勢人が去って代わりになる人がいない。
フォークする動きも見れないから終了ととらえて良いだろう。
0295デフォルトの名無しさん2012/12/15(土) 09:48:28.83
開発が終了しただけで、使用できなくなるわけでもなければ配布が終わるわけでもない。
0296デフォルトの名無しさん2012/12/15(土) 16:54:10.31
派生元のサブディレクトリと同じに見えるブランチとか
設計がダメすぎるから滅びるのは当然
0297デフォルトの名無しさん2012/12/16(日) 17:19:40.51
かちゅ～しゃ使いから見れば、開発が終了してからこそが本番といえる
0298デフォルトの名無しさん2012/12/16(日) 21:09:52.13
かちゅーしゃ使いだがソース管理はGit派だ
悪いな、俺は先に行くよ…
0299デフォルトの名無しさん2012/12/17(月) 02:50:13.91
Gitなんて7年も前のツールだろ
時代遅れ
0300デフォルトの名無しさん2012/12/17(月) 13:24:45.04
Linuxなんて20年も前のOSだろ
時代遅れ
0301デフォルトの名無しさん2012/12/17(月) 14:39:24.39
やっぱり今はWindows8だね
0302デフォルトの名無しさん2012/12/17(月) 14:52:32.36
■Windows開発新責任者、「Windows 8」UIを語る--「大多数のPCは今後、タッチ技術に対応」
http://japan.cnet.com/news/service/35025790/

やはりこのおばさんが黒幕でしたね
0303デフォルトの名無しさん2012/12/17(月) 17:42:04.70
DOSがウィンドウズの1アプリになったように、デスクトップがウィンドウズの1アプリになった。

しかし、可愛いおばさんだな
0304デフォルトの名無しさん2012/12/17(月) 21:03:51.08
開発責任者が変わるというのは、もうどこのコードのせいか分からなくなって、直せないバグが山ほどできることと同義
0305デフォルトの名無しさん2012/12/17(月) 21:14:30.62
まあ、ドキュメント通りにプログラマがコードを書いているとは限らんしな。
0306デフォルトの名無しさん2012/12/18(火) 15:19:53.90
>>305
それはプログラマを罰するべき話であって
0307デフォルトの名無しさん2012/12/18(火) 16:05:34.97
プロレスラー
0308デフォルトの名無しさん2012/12/20(木) 19:12:28.01
なんでhg qpush失敗してしまうん？
0309デフォルトの名無しさん2012/12/21(金) 11:50:00.15
失敗しないよ
0310デフォルトの名無しさん2012/12/24(月) 22:47:49.64
Git初心者なんだけど、クライアントはsourceTreeでいいんか?
なんか日本語対応されているとか知って使ってみたらもろ機械翻訳なんだけど・・・
0311デフォルトの名無しさん2012/12/24(月) 23:17:35.19
馬鹿には無理
0312デフォルトの名無しさん2012/12/25(火) 00:39:04.30
>>310
bzr-git
http://methane.hatenablog.jp/entry/20111224/1324698755
0313デフォルトの名無しさん2013/01/19(土) 16:36:48.00
Subversion1.8でローカルコミット対応するっていうからｗｋｔｋしてたのに
機能開発が遅延して1.9までおあずけになっちまったようだ・・・。
0314デフォルトの名無しさん2013/01/19(土) 17:22:18.52
だがもううちの職場もGit乗り換えだわ
バイバイSVN
0315デフォルトの名無しさん2013/01/21(月) 14:11:52.54
>>310
ちゃんと翻訳者に投げろと言ってやって下さい。作者が遠慮して機械翻訳で済まそうとするので、
却って手間がかかってたり…^^;
0316デフォルトの名無しさん2013/02/06(水) 21:24:33.93
Android系だとgitとかrepoとか覚えないといけないみたいですね。
とりあえずrepo syncに鬼のように時間がかかっている。
0317デフォルトの名無しさん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
0318デフォルトの名無しさん2013/04/04(木) 21:00:08.42
GitはZFSと合わせて運用しないと危ないZE！ってことだな。
Linusは、OracleのbtrfsをポイしてZFSをくれって言おう！
0319デフォルトの名無しさん2013/05/13(月) 00:07:09.45
VSS6.0はUnicodeファイルを壊す事があるんですか？
0320デフォルトの名無しさん2013/05/13(月) 01:16:00.27
VSSは2005からUnicode対応だったはずだが、それ以前のバージョンでどういう挙動になるかは知らない。
0321デフォルトの名無しさん2013/05/13(月) 07:26:08.00
>>319
バイナリで登録すれば問題ない
テキストで登録すると変な改行が挿入されることがある
0322デフォルトの名無しさん2013/05/13(月) 07:27:16.33
ちなみに変な改行が挿入されるのは
日本語で終了する行のうち
一部の文字で終わる行だけだったはず
0323デフォルトの名無しさん2013/05/13(月) 23:26:54.57
>>321-322
ありがとうございます。助かりました。
0324デフォルトの名無しさん2013/06/22(土) 21:54:33.64
Subversion 1.8.0 age
0325デフォルトの名無しさん2013/07/15(月) NY:AN:NY.AN
バージョン管理のセオリーについて初心者質問いいすか？

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

それとも、いろんなバージョンの同名ソースがあちこちのフォルダに
入り乱れるのは混乱の元なので、trunkの作業コピーを削除して
同じフォルダにbranchのファイルをチェックアウトして作業するべき？
0326デフォルトの名無しさん2013/07/15(月) NY:AN:NY.AN
svn?
svn switchでいいんじゃ?
0327デフォルトの名無しさん2013/07/15(月) NY:AN:NY.AN
作業コピーは作業者の好きにしたらいいんじゃねの？

なんとなく、svn, bzr は前者、
hg は後者、って感じがするが…
03283252013/07/15(月) NY:AN:NY.AN
ありがとうです。使用ソフトはsvnです。
なぜこんなことを聞くかというと、
branchが完成してtrunkにマージする際、
trunkの作業コピーに対してマージが行われると
ヘルプにあったためです。
マージに必要であるということは、trunkの作業コピーは
消してはいけないのでは？と思った次第です。
0329デフォルトの名無しさん2013/07/25(木) NY:AN:NY.AN
亀だが、質問内容が違うやん。
0330デフォルトの名無しさん2013/08/18(日) NY:AN:NY.AN
gitで共有リポジトリの作成とリソースの初期コミットを１回のコマンドでできますか？
やっぱり、初期コミットもローカルリポジトリを作ってからpushするしかないのかな？
0331デフォルトの名無しさん2013/08/20(火) NY:AN:NY.AN
お望みの機能はないけれど(っていうかbareリポジトリは作業ツリー持たないからコミット出来ない)
pushをしない、って目的を達成するだけなら、最初はローカルリポジトリだけで作って、
共有の必要が出た時にcloseして共有するためのbareリポジトリを作るって手もあるよ
0332デフォルトの名無しさん2013/08/21(水) NY:AN:NY.AN
>>331
ありがとう！おかげさまでわかりました！！
私が知りたかったことは、Gitのスマートな共有リポジトリの作り方でした。

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

closeのスペル違いには「そんなコマンドあったんだ」と騙されましたがｗ。
0333デフォルトの名無しさん2013/08/23(金) NY:AN:NY.AN
typoだ許して
0334デフォルトの名無しさん2013/08/23(金) NY:AN:NY.AN
あと今更だけど、リモートに空bare作っておいて、ローカルで新規にリポジトリ作って、
最初のコミットを行った後にリモートへpushしたほうが多分楽だと思うで

pushならローカル→リモートの通信ができればいいが、リモートからcloneする場合リモート→ローカルの通信必要だから
後者のリモートにローカルをcloneするほうが、前者よりも面倒な事が多いと思う
0335デフォルトの名無しさん2013/10/04(金) 03:08:36.44
コンパイルしたバイナリファイルはバージョン管理に含めないのが普通？
0336デフォルトの名無しさん2013/10/04(金) 03:09:36.48
コードの書き換えでバイナリサイズが減ったか知りたいんだけど
これはバージョン管理システムでやることではない感じ？
0337デフォルトの名無しさん2013/10/04(金) 03:19:38.10
ローカルでやるぶんには好きにやれとしか
公開するならコンパイル後のファイルは含めないのが普通。そもそも環境毎に違うしな

git notesとかそういうのにサイズをメモっていくのはどうだろう
0338デフォルトの名無しさん2013/10/04(金) 04:24:26.87
なるほどね
ありが㌧クス
0339デフォルトの名無しさん2013/10/04(金) 05:11:52.48
一番ナウくてイケてるバージョン管理システムって何ですか？git？hg？
0340デフォルトの名無しさん2013/10/04(金) 08:15:39.24
>>337
> そもそも環境毎に違うしな

コンパイル日時を埋め込んだりするから、環境同じでも異なることが多いよ。
0341デフォルトの名無しさん2013/10/04(金) 11:52:28.87
>>335
うちの場合リリース版だけ入れてる。
0342デフォルトの名無しさん2013/10/04(金) 12:06:06.70
俺は客に出す時にソースとビルド出力一式圧縮して別にコミットしてる
0343デフォルトの名無しさん2013/10/04(金) 14:52:32.83
バイナリは入れないのが普通だろJK
ソースがあるんだからビルドすればバイナリ出来るんだし
そんな事をやっているOSSは見たこと無い
0344デフォルトの名無しさん2013/10/04(金) 14:53:48.92
大体そんなものを入れたらマージする度コンフリクトするだろ
0345デフォルトの名無しさん2013/10/04(金) 14:54:57.75
>>343
> ソースがあるんだからビルドすればバイナリ出来るんだし
これで、いつでも誰でも簡単にリリース時のバイナリを復元できると思ってるなら、考えが甘い。

> そんな事をやっているOSSは見たこと無い
OSS以外の事情は考える気もしないのかな。
0346デフォルトの名無しさん2013/10/04(金) 14:59:24.97
バイナリなんかバージョン番号をつけたzipで良いじゃん
0347デフォルトの名無しさん2013/10/04(金) 15:19:45.49
社内で一部にJNI使ったJavaライブラリを開発使用していて、これに関してはCのコードから
生成されるネイティブバイナリもソースツリーの一部としてバージョン管理に入れている。

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

ただこれはこのライブラリに限った特殊事情で基本的にリリース版のビルド出力の保存管理
はArtifactoryで行っているかな。
0348デフォルトの名無しさん2013/10/04(金) 15:30:22.31
画像ファイルや音声ファイルもバージョン管理には含めないもの？
0349デフォルトの名無しさん2013/10/04(金) 15:50:12.29
巨大なファイルならともかく、ウェブアプリ等の開発であればページに貼り付ける
固定画像の類は普通はバージョン管理に含めると思う。

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

画像ファイルの件でいえば単にpngやjpeg画像ではなく、それらのエキスポート元で
あるイラストレーターやフォトショップのファイルもバージョン管理に含めている。
画像の修正には必須なので。
他方でpngやjpegはイラレ等の元ファイルからいつでもエキスポート出来るとはいえ
これらをバージョン管理に含めないということは無い。デザイナーさん以外の多数
はエキスポートされたファイルしか必要としていないからね。
0350デフォルトの名無しさん2013/10/04(金) 16:00:24.48
>>346
だよなぁ。
アーカイブなりインストーラなりを、ファイルサーバに置いとけばOK
0351デフォルトの名無しさん2013/10/04(金) 17:25:59.36
>>349
エキスポートって何だよ！！
エクスポートの方が英語の発音に近いだろ
http://ejje.weblio.jp/content/export
0352デフォルトの名無しさん2013/10/04(金) 19:28:00.13
マッスルポーズ
0353デフォルトの名無しさん2013/10/04(金) 21:01:41.66
> バイナリなんかバージョン番号をつけたzipで良いじゃん
ソースなんかバージョン番号をつけたzipで良いじゃん

これを本気で言い出す人がいて困る。
0354デフォルトの名無しさん2013/10/04(金) 22:11:31.40
diffやマージに意味があるかないかの違いがあるだろ
0355デフォルトの名無しさん2013/10/07(月) 13:26:33.39
>>353
VCS使ってても、数日に1回くらいしかcommitしない奴が言いそう
0356デフォルトの名無しさん2013/10/07(月) 14:43:33.76
書きかけのものでもコミットしたほうがいいの？

foo(a + b + bar(c

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

A. この状態でファイル保存とコミットすべき？
B. この状態でコミットはせずファイル保存だけすべき？
C. 書きかけの行を削除してからファイル保存とコミットすべき？
D. 書きかけの行を削除してからコミットはせずにファイル保存だけすべき？
0357デフォルトの名無しさん2013/10/07(月) 14:44:16.42
コミットとは動く状態のソースコードに対してのみ行うべきなの？
0358デフォルトの名無しさん2013/10/07(月) 15:07:01.56
Subversion でいえば trunk は動く状態のみにすべき。ミスはしゃーないけど。
動かないものは branch を切ってそちらへ。分散 VCS ならローカルは好きに、外部には動くものだけ。
0359デフォルトの名無しさん2013/10/07(月) 15:30:02.02
okわかった
ありがと
0360デフォルトの名無しさん2013/10/07(月) 16:02:20.72
自分しか使わないならどうでもいい
他の人も使うならビルドは出来る状態にする
0361デフォルトの名無しさん2013/10/07(月) 17:10:35.87
コンパイル出来ないバージョンを公開することで、他の開発メンバーを混乱させることができる
0362デフォルトの名無しさん2013/10/07(月) 17:44:14.00
しかも会社から解放されて自由になれる
0363デフォルトの名無しさん2013/10/07(月) 18:58:15.29
書きかけの状態を管理したい時ってまぁないなあ
0364デフォルトの名無しさん2013/10/07(月) 20:30:08.41
書きかけとはちょっと違うけど、終電ギリギリでなんとかコミットしようとして
ビルドは出来るけど、くだらない不具合残したままコミットした事がある
条件判定が逆になってるのと、除算の右辺左辺が逆だった
0365デフォルトの名無しさん2013/10/07(月) 21:03:09.27
比較的最近gitスレでそんな話題を見たな
http://toro.2ch.net/test/read.cgi/tech/1369103196/369-387
0366デフォルトの名無しさん2013/10/07(月) 22:12:26.96
終電がコミットの基準になってるとか変なルールだな
0367デフォルトの名無しさん2013/10/08(火) 07:00:50.30
少なくともbranchは切るよな。
まぁでもコンパイル通らないコードもどんどんcommitするなぁ俺は。
個人的には380に同意だわ。
0368デフォルトの名無しさん2013/10/08(火) 11:47:41.22
なんでわざわざ>380にパス出すかなw
0369デフォルトの名無しさん2013/10/08(火) 12:15:45.85
書きかけ中断はGitならstashかcommitして後で修正
Mercurialならmqでパッチ化かな
0370デフォルトの名無しさん2013/10/08(火) 14:26:54.78
>>368
野暮だけど
どう読んでもgitスレの380だろ
0371デフォルトの名無しさん2013/10/08(火) 14:42:11.82
>>370
んなもん、判るかいw

それはさて、bzrで書き掛けなら棚上げ(shelve)だな。
0372デフォルトの名無しさん2013/10/08(火) 14:42:43.67
360のタイプミスかと思ったがそっちの380だったか
0373デフォルトの名無しさん2013/10/08(火) 14:48:40.94
gitはcommitだけじゃ公開にはならんけどpushしたら今までのcommit全部上げられるから書きかけのcommitはそれはそれでどうなの
0374デフォルトの名無しさん2013/10/08(火) 14:49:25.90
>>373
え？
0375デフォルトの名無しさん2013/10/08(火) 15:08:51.05
>>373
イミフ
0376デフォルトの名無しさん2013/10/08(火) 15:41:21.41
俺はわかるけど
0377デフォルトの名無しさん2013/10/08(火) 15:45:15.06
意味わかってるからこその「何言ってんのコイツ」
0378デフォルトの名無しさん2013/10/08(火) 15:52:47.80
日本語の文章としておかしいのに意味分かるとかエスパーかよ！
0379デフォルトの名無しさん2013/10/08(火) 16:12:38.84
squashしてからpushすればいいよ
0380デフォルトの名無しさん2013/10/08(火) 16:40:48.41
> gitはcommitだけじゃ公開にはならん
> pushしたら今までのcommit全部上げられる
> 書きかけのcommitはそれはそれでどうなの

どこの意味が分からないんだろうか。
0381デフォルトの名無しさん2013/10/08(火) 18:56:49.60
書きかけのcommitを放置したままpushするってそれはそれでどうなの

って言いたいんだが……
0382デフォルトの名無しさん2013/10/08(火) 19:02:23.26
ミスではなく意図的にそんなことやっている事例があるのなら教えてほしい
少なくとも>>365で参照されている範囲では読み取れない
0383デフォルトの名無しさん2013/10/08(火) 19:24:41.34
najeira: Gitの運用ルール、ワークフローを考えてみた 2
ttp://najeira.blogspot.jp/2013/04/git-2.html

>好きなタイミングでコミットしてよい。
>この時、そのコミットがテストされた状態である必要はない。
>ブランチでは、デプロイ可能な状態を常に保つ必要はなく、 あくまで、masterにマージする段階でテストされていればよい。
0384デフォルトの名無しさん2013/10/08(火) 19:33:11.21
> masterにマージする段階でテストされていればよい。
0385デフォルトの名無しさん2013/10/08(火) 19:40:25.22
とどのつまり
0386デフォルトの名無しさん2013/10/08(火) 20:40:05.64
Linuxのワークフローと同じじゃないか
masterにマージするのは権限を持つものだけが行なえる
みんなmasterを改変できる権限を持つから取り決めが必要になる
0387デフォルトの名無しさん2013/10/08(火) 20:50:50.93
一部分だけ変更できる権限とかを各人に与えられるようになるといいのにね
0388デフォルトの名無しさん2013/10/08(火) 20:54:44.90
gitならsubmoduleに分けて、それぞれ権限を分割すればいいんじゃね？
0389デフォルトの名無しさん2013/10/08(火) 22:36:51.63
>>373
全部じゃなくて一部だけpushすればいいだろ
0390デフォルトの名無しさん2013/10/09(水) 03:06:16.04
まあついpushしちゃうこともあるから
ちょっと長めの修正作業になるときなんかは
pushするブランチから別のブランチを切ってそこで適当にコミットしながら作業
公開してもいい状態になったらコミットを整理整頓しながらpushするブランチにマージ
その後pushとかすればいいんでない
0391デフォルトの名無しさん2013/10/09(水) 21:56:42.51
Subversionがさっさとshelveを実装しないから・・・。
1.8で実装されるはずだったのに。
0392デフォルトの名無しさん2013/10/11(金) 15:12:51.99
Java SE 7 パッケージバージョン識別関連 API & 開発者ガイド
http://docs.oracle.com/javase/jp/7/technotes/guides/versioning/index.html
0393デフォルトの名無しさん2013/10/21(月) 19:33:59.42
今まで、ひとりで自己流でWebサービス作って来たんだけど、
１人で開発するときでもGitみたいなバージョン管理システム
って必要あるの？
先祖返りとか上書きの予防なら、Dropboxだけでもいいような。
0394デフォルトの名無しさん2013/10/21(月) 19:38:02.04
コミットメッセージを適当に書く奴には価値がわからない
0395デフォルトの名無しさん2013/10/21(月) 19:49:38.14
>>394
ああ、なるほど。
Gitは、どこを誰がどう直したかを全部記録しておくためのツールなのか。
ソース内のコメントでやろうとすると、ごちゃごちゃになりがちだし。
0396デフォルトの名無しさん2013/10/21(月) 19:55:11.35
今俺何修正したっけ？ってのを簡単にdiffとるために使ってる
0397デフォルトの名無しさん2013/10/21(月) 20:22:37.99
コメントにごちゃごちゃ履歴を書いてるのって絶対に古いバージョンに戻らない。
ときにはコンパイルすら通らない。
0398デフォルトの名無しさん2013/10/21(月) 20:22:48.20
何か問題が起きたときに、以前のバージョンで正常に動いていたなら
正常だったときのコードを取り出して比較できるので
いつから問題が発生したのか、どこをどう直したせいなのか調べるのに役に立つ
0399デフォルトの名無しさん2013/10/22(火) 08:23:51.09
>>393
正直、好きにしたらいいと思う
0400デフォルトの名無しさん2013/10/22(火) 10:38:37.87
>>395
社内プロダクトで、プログラマは実質俺一人な場合があるけど、そういう時でもTicket切って
コミットコメントにはrefs #1234とか書いて、Redmineと統合してる。
0401デフォルトの名無しさん2013/10/22(火) 11:43:27.53
未来の自分のためにツール使っとくのがいいよね……
0402デフォルトの名無しさん2013/10/22(火) 13:23:05.58
つうかよくバージョン管理無しでコード書けるな。
って思うよ。使い方わかると。
バージョン管理無しでコード書くのはセーブなしで RPG やるようなもんだ。
0403デフォルトの名無しさん2013/10/22(火) 13:38:10.91
>>402
うちの会社の別チームは、たまに「先祖返りがー」とかまだ言ってる。
一応ことあるごとにSCMを導入しろと言ってるんだが、聞く耳持たない。
そのチームはリリースミスもたまにやらかすわ。
0404デフォルトの名無しさん2013/10/22(火) 14:07:25.67
>>400
一人自営だが、全く同じ
これは依存症かもしれんが、もうRedmineとSVN無いと不安で仕事できないな

>>403
理解できない人には駄目みたいね
客先に打合せ行った時に「最新のソース下さい」とか言ってるの漏れ聞くと、もうアホかとバカかと

別の会社で協業した時には俺が半ば無理矢理VSSを導入させたんだが、
数年後に訪れて見た別案件では1ヶ月前に全ソースチェックアウトしたままで作業してた
途中何度もリリースしてるのにもう完全放置状態
0405デフォルトの名無しさん2013/10/22(火) 14:26:10.21
SCM（も自動テストも）をやってない人達が言いがちなセリフ：

「前はちゃんと動いてたはずなんだけど・・・」

前に戻ることもできないし、テストもできませんから。
0406デフォルトの名無しさん2013/10/22(火) 14:38:22.74
過去のコードが全部コメントで残ってたりするわけだｗ
0407デフォルトの名無しさん2013/10/22(火) 14:44:47.27
>>406
それを強要してくるクライアントも未だ未だ多いよ。
履歴と過去のコードを全て消したら1/3になったりする。
0408デフォルトの名無しさん2013/10/22(火) 19:32:33.06
>>406
そして、そのコメントアウトした過去のコードが
同じ箇所に色んな日付のコードが混じったり
同じ日の変更が多数のファイルに渡ってて
特定の日付の状態を再現するだけで小一時間掛かって
やっと戻ったと思ったらあれれ動かない、と
戻す作業ミスったかな？と思って原因調べていったら
実は戻しの作業はミスってなくて自社ライブラリのバージョンだったりするんですね
0409デフォルトの名無しさん2013/10/22(火) 20:42:58.41
昔、バージョン管理ソフト導入しているのに
コメントで履歴を残しているプロジェクトに遭遇したことあるけど
誰も不思議に思わなかったのかなぁ
0410デフォルトの名無しさん2013/10/22(火) 22:18:57.89
You can't be serious!
0411デフォルトの名無しさん2013/10/23(水) 15:33:29.49
エクセルで管理してる情報が面倒なんだよなぁ
マージとかができないし……
0412デフォルトの名無しさん2013/10/23(水) 15:47:01.85
>>409
あえて残すことはあるな。
0413デフォルトの名無しさん2013/10/23(水) 22:57:17.81
>>411
csvで済まないの?
0414デフォルトの名無しさん2013/10/24(木) 08:01:34.01
>>412
理由は？

旧来のやり方しか知らないリーダーの説得に疲れはてたとか、そう言うポリシーのお客さんのコードは修正してるとか、辺りしか思いつかない。
0415デフォルトの名無しさん2013/10/24(木) 08:10:33.87
何かしらの理由でバージョン管理システムのデーモンが稼働してるサーバに繋げられない時でも
ロールバックが出来るっていうメリットはある
0416デフォルトの名無しさん2013/10/24(木) 08:12:53.93
投げ捨てろよそんな中央集権システム
0417デフォルトの名無しさん2013/10/24(木) 08:17:35.32
>>413
Excel で管理したがる人って下手すると内容よりフォーマットに凝ってたりするし...
0418デフォルトの名無しさん2013/10/24(木) 08:20:05.00
>>415
コメント頼りにロールバック？
日付フォルダ管理の方がマシじゃね？
0419デフォルトの名無しさん2013/10/24(木) 08:27:00.31
>>415
分散型ならローカルで戻すだけだと思うがな
0420デフォルトの名無しさん2013/10/24(木) 08:52:04.72
>>409
ファイルを選択して履歴を見れば良い

と誰も思わなかったのが不思議
0421デフォルトの名無しさん2013/10/24(木) 12:49:02.88
>>414
クソ仕様のクソコード引き継いだとき残したな。
しかも一から書き直せないとか。
何が合ってるんだか合ってないんだか曖昧みたいな。
ブランチの差分だと、変更点が多くなってくると辛くなってくるじゃない。
普通の仕事だとまずないけど、極端なケースだと無くはないって感じ。
何かいい方法ないかな。
0422デフォルトの名無しさん2013/11/02(土) 16:50:29.20
sjisのtexと
utfのtexを統一してバージョン管理する方法ないですか？
0423デフォルトの名無しさん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
04244232013/11/02(土) 21:15:06.40
すまんgitスレだと勘違いしてたわ
0425デフォルトの名無しさん2013/11/15(金) 04:04:39.35
個人開発でバージョン管理ソフトを使う場合
開発のどの段階からバージョン管理ソフトを導入したらいいの？
まだファイルもない開発の始めから？アルファ版が出来たくらいから？
それともベータ版やリリース版が出来きたくらいから？
それとも実験的な改造したくてブランチ切って作業したくなったとき？
0426デフォルトの名無しさん2013/11/15(金) 07:10:10.28
>>409
プログラムでソースを解析する時に目印が有ると楽じゃん
0427デフォルトの名無しさん2013/11/15(金) 11:15:44.38
>>425
自分は最初から
この実装糞だからやっぱやめるわ、となった時に捗る
0428デフォルトの名無しさん2013/11/15(金) 11:28:47.85
俺も最初からだね
たとえソフトの開発を途中で諦めて完成しなかったとしても
後々別のソフトを開発するときにコードの一部を再利用できるかもしれない
そんなに容量取るもんじゃないし
少しでも書いたものはバックアップも兼ねてリポジトリに放り込んでおく
0429デフォルトの名無しさん2013/11/15(金) 17:33:15.11
同じく。空っぽの関数書いただけでもとりあえずコミットしておく。
0430デフォルトの名無しさん2013/11/15(金) 17:34:52.54
「コミット」の意味が、svnユーザとgitユーザでちょっと違う
0431デフォルトの名無しさん2013/11/15(金) 18:17:38.66
どう違うんだい？
0432デフォルトの名無しさん2013/11/15(金) 18:42:16.33
>>425
途中から使い出す理由が思いつかない
0433デフォルトの名無しさん2013/11/15(金) 19:10:59.96
svnでのコミットは
gitでは公開リポジトリへのpushに相当するのかな
0434デフォルトの名無しさん2013/11/15(金) 19:19:32.22
それはちょっとどころじゃないね
0435デフォルトの名無しさん2013/11/15(金) 21:23:09.71
gitでのコミットはローカルリポジトリへのコミット
gitでのaddはコミット対象の追加

http://www.backlog.jp/git-guide/reference/basic.html
add:
-p オプションを付けると、ファイルの変更箇所の一部のみを登録することができます。

これsvnに入ったらしいね
04364252013/11/16(土) 00:30:20.28
>>427-432
参考になりました
ありがとうございました
0437デフォルトの名無しさん2013/11/16(土) 13:40:35.94
>>432
と言うか、途中まで使わない理由がわからん
0438デフォルトの名無しさん2013/11/16(土) 14:23:39.80
バージョン管理システムの存在を知っていて、いつでも導入可能の状態であるのに、「開発の途中から使う・開発の途中まで使わない」理由が分からない

という意味です
0439デフォルトの名無しさん2013/11/16(土) 14:25:12.51
バージョン管理システムの存在を全く知らなかった人や、システムの導入が困難な状況にあった人が、「開発途中から使い始める・開発途中まで使ってない」理由が分からないわけではないのです
0440デフォルトの名無しさん2013/11/16(土) 14:39:48.92
cvsや昔のsvnだとディレクトリの再構成やりにくいしサーバー設定いるしで
概形はかたまってからバージョン管理始めたいって気持ちも分かる

gitやhgだとなんかするときにまずgit initしときゃいい
0441デフォルトの名無しさん2013/11/16(土) 19:03:38.11
>>440
> 昔のsvnだとディレクトリの再構成やりにくいし

いつの話だよ...

> サーバー設定いるし

レポジトリはローカルファイルシステムにも作れるぞ
0442デフォルトの名無しさん2013/11/16(土) 20:13:57.27
>>433
個人でローカルリポジトリでやるならコミットに差は無いのでは？
0443デフォルトの名無しさん2013/11/16(土) 20:16:59.23
ローカルで1人でも差分管理が楽だからやる価値はある
0444デフォルトの名無しさん2013/11/16(土) 21:19:37.35
>>442
gitのローカルリポジトリへのコミットは
後でコミットを複数に分解したり複数のコミットをひとつにしたり
もしくは内容自体を修正するつもりで作ってもいいからね
svnの場合はローカルリポジトリ用意してもそういう使い方は面倒
0445デフォルトの名無しさん2013/11/16(土) 21:26:30.84
ブランチ切っときゃ何やったってダイジョウブだろん
0446デフォルトの名無しさん2013/11/16(土) 21:36:21.70
一人でやるならsvnよりgitやhgのが手軽だよな
会社の縛りでもない限り、もはやsvnの意味無しだね
0447デフォルトの名無しさん2013/11/16(土) 21:56:10.35
capistrano 3 がsvn対応を外した(後回しにした?)のが個人的には印象深い。
0448デフォルトの名無しさん2013/11/16(土) 22:06:13.67
>>445
svnは最近触ってないけどコミットのrebaseは出来るようになったのん？
0449デフォルトの名無しさん2013/11/17(日) 02:51:42.07
リポジトリをdropboxにおけばいろいろ楽チンだよう、まあお一人様でやっているからだけど
0450デフォルトの名無しさん2013/11/17(日) 03:21:30.14
自動同期とかなんか怖いんだよねdropbox、だから導入できないわ。
0451デフォルトの名無しさん2013/11/17(日) 03:22:36.18
だからオープンソース用のリポジトリサービスでいいかなって
0452デフォルトの名無しさん2013/11/17(日) 03:25:47.10
「dropbox リポジトリ」でググると結構あるね
0453デフォルトの名無しさん2013/11/17(日) 03:32:10.70
dropbox使ったgitリポジトリの話多いけど、ローカルに同じリポジトリを２つ保持するってことになるのか？
0454デフォルトの名無しさん2013/11/17(日) 04:07:43.94
Dropbox+hgならやってる

ローカルに同じリポジトリが2つあるんだけども
Dropbox側はinitはするが、生ファイルが必要無いので.hgだけだな

gitで同じかどうかは知らん

あと、俺はDropbox使用マシンが全て常時接続してるからいいが
同期が切れるマシンが存在するなら
Dropbox同士でコンフリクト起こした場合が面倒そうだなw
0455デフォルトの名無しさん2013/11/17(日) 08:08:33.35
Dropbox+bzr なら checkout/bind 使ってリポジトリ１つで push/pull なしでも運用できる。

通信気になる環境なら unbind で切り離して、何回か comitt した後でまとめて push できる。

割としょっちゅう「これ bind されてるっけ？」って気が気でなくなるので、お勧めできないが…
0456デフォルトの名無しさん2013/11/17(日) 11:09:49.14
その点、bzrなら融通が利くじゃんw
0457デフォルトの名無しさん2013/11/19(火) 04:36:22.15
一人で使う場合、ブランチ作るまでもないから、GitやMercurial使う必要性あまりない
0458デフォルトの名無しさん2013/11/19(火) 04:44:24.63
途中までやってて、「やっぱこれらの変更全部なし」にしたいってとき、ブランチ捨てるだけってのは簡単なんじゃないの
前のリビジョンとかまでに戻すのって結構簡単なん？
0459デフォルトの名無しさん2013/11/19(火) 05:50:25.34
ローカルのみで使う場合とか一人で使う場合はなおさらGitやMercurialを使うデメリットが
思いつかない。
0460デフォルトの名無しさん2013/11/19(火) 06:54:49.37
>前のリビジョンとかまでに戻すのって結構簡単なん？

そんな難しくはないけど、
でもブランチにしておいて「もうやーめた」と放っておく方がなお簡単。
とにかく何かするときにはとりあえずブランチって習慣にしてればだけど。
0461デフォルトの名無しさん2013/11/19(火) 09:38:00.49
>>459
ローカルで1人だとIDEに統合されてるやつがいいね
0462デフォルトの名無しさん2013/11/19(火) 09:52:35.48
>>461
つまり、IDEに組み込めるgitやbzrがいいわけですね?w
0463デフォルトの名無しさん2013/11/19(火) 10:42:21.67
しかしIDEはまだまだタコなとこ多いから、結局専用アプリとコマンドライン併用になりがちなんだよなー
0464デフォルトの名無しさん2013/11/19(火) 11:37:00.53
Dropbox+hgはやってるわ、Dropboxが自動pullとバックアップしてくれてると思うと便利
誰か、Dropboxの代わりにBittorrent Sync使ってる奴は居ないのかな？
0465デフォルトの名無しさん2013/11/19(火) 12:00:43.63
それはsvnに加えてgitやmercurialに習熟してる場合だろ
ブランチを使わない作業フローなら、svnから移行するメリットない
0466デフォルトの名無しさん2013/11/19(火) 14:32:31.56
>>465
そう言われればそうだわな
0467デフォルトの名無しさん2013/11/19(火) 14:53:21.99
>>465
まぁそれもgitやhg以前に既にsvnに習熟していてブランチ切らない縛りがある場合。

これからバージョン管理を使ってみようという人であれば今更あえてsvnを選ぶメリットも無い。
作業フローについてもブランチをガンガン切るやり方から初めても良いよね。
0468デフォルトの名無しさん2013/11/19(火) 14:59:31.78
>>467
svnの中央集中リポジトリ型の方がシンプルで布教しやすいというメリットは依然としてある。
0469デフォルトの名無しさん2013/11/19(火) 15:07:39.18
(え～)
0470デフォルトの名無しさん2013/11/19(火) 15:36:43.38
gitはgit initするだけでどこでもすぐ使えるんだけどsvnもそんな感じなの？
0471デフォルトの名無しさん2013/11/19(火) 16:05:36.61
hgもhg initするだけでディレクトリがバージョン管理下に入るな。

svn・・・svnadmin?
0472デフォルトの名無しさん2013/11/19(火) 16:50:01.65
巨大バイナリを扱うならsvnしか選択肢がないだろ
もちろん分散も含めてハイブリッド環境にするべきだろうけど

つうか、ホントにsvnを知らないアフォが増えてきたな・・・
0473デフォルトの名無しさん2013/11/19(火) 16:58:14.29
gitだけで別に困らないし
0474デフォルトの名無しさん2013/11/19(火) 17:00:05.21
巨大バイナリをバージョン管理するのなんてやめてgitやhg使ったほうがいいよ
0475デフォルトの名無しさん2013/11/19(火) 18:12:00.65
バイナリ扱うならSVNでも無理だ
有料になるけどAlienbrainどうよ
0476デフォルトの名無しさん2013/11/19(火) 19:03:54.49
ファイルサイズが大きくなるようなバイナリフォーマットは
大抵元から圧縮がかかってるんで、
SVNのメリットが出てこないんだよね。

SVNで管理できる程度のバイナリなら、gitでも管理できる。
0477デフォルトの名無しさん2013/11/19(火) 21:02:48.76
入門やとっかかりの話をしていたところが急に特殊ケースを持ち出してがんばる人がでてきたでござる。
0478デフォルトの名無しさん2013/11/19(火) 21:56:08.02
>>476
SVNは巨大ファイルでもメモリーをあまり食わない。他のはたいていファイルサイズ以上の
メモリーを食う。だからと言ってSVNを進んで使おうとは思わないが。
0479デフォルトの名無しさん2013/11/19(火) 22:09:20.74
クライアントの話？
0480デフォルトの名無しさん2013/11/20(水) 00:06:36.76
gitとかの分散型の方がより高機能なのは確か
だが、subversionのような中央集権型の方が分かりやすいというメリットは大きい
0481デフォルトの名無しさん2013/11/20(水) 00:25:40.31
なんかループしてるぞ
0482デフォルトの名無しさん2013/11/20(水) 00:50:50.24
個人でやるなら好きなほうを使えばええ
組織でやるならトップの決めたほうに従えばええ
おまえさんが組織のトップなら・・・
0483デフォルトの名無しさん2013/11/20(水) 04:28:36.93
>>458
Mercurial はどこからでも枝生やせるし、どこにも push してないなら mq で消せる。
最近は push しててもフェーズ変更できるみたいだけど。
まあ自分は失敗もひとつの歴史としてそのままにしとくけど。思いがけず役立つ時があるかもしれないし。
0484デフォルトの名無しさん2013/11/20(水) 04:51:53.49
全然分かってない人に説明するコストは、依然としてSubversionが最も低い。
0485デフォルトの名無しさん2013/11/20(水) 06:33:17.82
初学者が実作業を通じて独習する場合もsvnよりGitやMercurialの方が良い気がしている。
まずローカルで独習する場合はpushやpullが不要なので分散型特有の面倒は無い。

で、一本のブランチにただコミットするだけならさして難しくはない。しかしコミット
だけ出来てもあまり役に立たない。集中型だろうが分散型だろうが一番悩ましくて故に
実体験から学んでおいてほしいのはむしろマージなんだよね。

しかし他の人との共同作業ならともかく一人で一本のブランチにコミットするだけだと
マージをする機会が極端に少ない。

なので出来れば分散型云々とは別としてもまずトピックブランチを切って後でメインに
マージする開発スタイルを試してみることで、マージの回数を一度でも多くこなして
みると良いんじゃ無いかと思う。
となるとブランチの扱いに長けたgitやhgの方が学習効率もよいのではないかと。
0486デフォルトの名無しさん2013/11/20(水) 07:51:20.28
ドキュメントも全て差分取るのが普通だよね？
0487デフォルトの名無しさん2013/11/20(水) 08:31:53.80
ソース等から生成するのは管理対象外
オフィスドキュメントは校閲機能使って管理対象外

全てとか気軽に言っちゃう奴の普通は知らん
0488デフォルトの名無しさん2013/11/20(水) 16:12:28.91
>485
いや、実体験として、Subversionはデザイナとかでもすぐ使えるようになるが、
GitとMercurialはプログラマでも無理な人は無理。教えるのは苦行だよ。

>487
ビルド成果物でも、「3年後に他人が1時間でビルド出来そう」と思えなかったら
入れる。悩ましいところだが。
0489デフォルトの名無しさん2013/11/20(水) 17:00:14.96
>>488
これも実体験として語るけれども、新人やインターンにMercurialを教えることを
結構な回数こなしてきたけれども極端に難しいことは無かったなぁ。
GitやMercurialが無理なプログラマというのもちょっと想像出来ない。

ただ目的はVCSを教えることではなく、VCSはあくまで道具で目的はそれを使った
開発フローの回し方を教えることなんだよね。
チケットもらってブランチ切ってからマージされてクローズするまで、フローの
中の一連の作業で使うhgのコマンドはある程度決まっているから最初のとっかかり
は別に難しくは無い。あとは実作業を通じてMercurialそのものの使い方の理解を
深めていってもらえば良い、みたいな。

マージに関してはsvnだろうがDVCSだろうが悩みどころだと思う。コンフリクトの
解決がいい加減な人は本当に困る。
0490デフォルトの名無しさん2013/11/20(水) 17:09:34.23
>>489
> GitやMercurialが無理なプログラマというのもちょっと想像出来ない。

なんかこういうこと言う人嫌い。
0491デフォルトの名無しさん2013/11/20(水) 17:13:11.71
自分が想像できない世界は存在しない事にするのが一番楽
0492デフォルトの名無しさん2013/11/20(水) 17:36:34.19
普通に勉強すれば大抵は使えるようになるってこと。
0493デフォルトの名無しさん2013/11/20(水) 17:38:45.29
できるようになるまで普通に勉強できない人もいる
0494デフォルトの名無しさん2013/11/20(水) 17:39:23.79
人間には超えられない能力差があるもんです
あなたは真面目に勉強すれば医者にでも法律家にでも官僚にでもなれるんですか？違いますよね
普通に勉強したって出来ることには個人差があります
0495デフォルトの名無しさん2013/11/20(水) 18:24:26.75
スイッチオン
0496デフォルトの名無しさん2013/11/20(水) 18:27:45.35
まあでも、git程度も使えない奴をプロのプログラマとは認めたくないよな
0497デフォルトの名無しさん2013/11/20(水) 18:32:17.98
世の中、金を払ってプロを名乗るような世界もあるんです
能力が無くたってプロを名乗ってもいいじゃないですか
0498デフォルトの名無しさん2013/11/20(水) 22:41:46.51
cvs/svnより、git/hgのが学びやすいと思う
ディレクトリを対象にできるrcs、って感じのお手軽な使い方ができるのが良い
そりゃもちろん、push/pullまで修得してこそ本領発揮なんだろうけどさ
0499デフォルトの名無しさん2013/11/20(水) 22:49:04.92
ソースコード中のコメントで誰々が変更しましたなんてやってる連中にSVNで新しい
プロジェクトを始める方法を教えるなんて嫌だ。
0500デフォルトの名無しさん2013/11/20(水) 22:50:49.91
プログラムで修正担当者がわかるからコメントは必須だろバカ
0501デフォルトの名無しさん2013/11/21(木) 00:04:29.65
バージョン管理が要らない画期的システムだな
0502デフォルトの名無しさん2013/11/21(木) 00:22:31.07
ブランチはフォルダでいいな
0503デフォルトの名無しさん2013/11/21(木) 00:29:16.59
誰かと共同で何かするんじゃなくて、一人自宅で使うつもりで、とりあえず
http://www.backlog.jp/git-guide/
を読みながら Git (Windows)を使い始めてみようと思うんだけど、
1.8 系で始めるのと 1.7系 で始めるのどっちが良い？
上記のサイトでは 1.7系っぽいので合わせたほうが無難なのか
最初から 1.8系 で行ったほうが良いのか。
0504デフォルトの名無しさん2013/11/21(木) 00:33:36.32
つまり、1.7系と1.8系の違いが知りたいと
0505デフォルトの名無しさん2013/11/21(木) 00:46:28.85
そうですね。最終的には 1.8系 ということに落ち着くんでしょうけど、
1.8系の新しい方から始めても大きく戸惑うようなことが無いのか、
ガラッと変わってるから 1.7系 で取っ掛かりを掴んだほうが良いのか
その辺の状況がわかれば。
0506デフォルトの名無しさん2013/11/21(木) 02:05:02.23
大した違いはないから1.8にしとけ
0507デフォルトの名無しさん2013/11/21(木) 04:06:12.13
gitは特定のファイルに対する変更追いづらいな
玄人のお前らはそんなのどーしてんの?
0508デフォルトの名無しさん2013/11/21(木) 04:07:04.55
IDE上でShow history
0509デフォルトの名無しさん2013/11/21(木) 04:31:25.43
GitHub上で更新頻度の多いファイルを開いたのBlameやらHistoryやらでそのファイルの細かい更新見られるし、
おそらくgitコマンドにそういうのあるんじゃないの？もしくはgitのGUIクライアントにそういう機能があったりするんじゃないの
0510デフォルトの名無しさん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
0511デフォルトの名無しさん2013/11/21(木) 04:38:25.18
一応msysgitでもしょぼいがファイル単位の変更履歴見られるけど
0512デフォルトの名無しさん2013/11/21(木) 07:49:37.57
>>506
ありがとう、1.8系ではじめてみる。
0513デフォルトの名無しさん2013/11/21(木) 09:20:54.95
普通に
$ git log README.md
$ git blame README.md
とは違うのか？
0514デフォルトの名無しさん2013/11/21(木) 09:31:41.24
Atlassian SourceTreeええな。
0515デフォルトの名無しさん2013/11/21(木) 21:45:28.10
【ネット】 GitHubに「総当たり」攻撃、安易なパスワードが破られる…セキュリティ対策を強化へ
http://uni.2ch.net/test/read.cgi/newsplus/1385019870/
0516デフォルトの名無しさん2013/11/23(土) 15:46:39.29
>>514
git/Hg両対応のSourceTreeがMac/Win版揃っちゃったせいでもう新規でSVN使う理由無くなっちゃったな
「うちのデザイナーはLinux使ってるんです＞＜」な奴このスレにはおらんだろうし
0517デフォルトの名無しさん2013/11/24(日) 02:14:56.73
若いヤツに辛抱強くGit教えてたんだけど、あまりに理解しないんでこりゃもうダメだなって
諦めてたんだけど（まあ何やらしても基本ダメなヤツだし）
最近になって急に意味が分かってきたみたいで、驚いてる。

たぶん、Subversionを先に覚えちゃうと、分散型は逆に理解しずらいのかもしれない。
デザイナーとかにも少しずつGit使ってもらうようにしてるんだけど、どうしてもsvnで言うとアレ、
みたいにしてやってしまうようで、それが却って障壁になってるんだと思った。
で、彼は長い時間かけてやっとsvn思考の呪縛から開放されて、新しいことを覚える気になったらしい。
0518デフォルトの名無しさん2013/11/24(日) 05:30:29.85
分散型でもGitは特に分かりづらい
0519デフォルトの名無しさん2013/11/24(日) 05:47:18.88
他の分散型は差し置いてGitが急速に普及しつつあるのは何故か
0520デフォルトの名無しさん2013/11/24(日) 08:20:46.12
>>519
ニワトリが先か卵が先かみたいな話になるかもしれないけど、オープンソースの世界で Github を使うことが多くなっている影響もあると思う
採用試験の時に、あなたの Github を見せてくださいっていうこともあるみたいだし
0521デフォルトの名無しさん2013/11/24(日) 12:43:36.51
Linuxで使われてるからだろうな
それとGithubの影響
0522デフォルトの名無しさん2013/11/24(日) 15:43:51.00
>>521
俺もこの2点に尽きると思う
会社で分散型使うなら正直hg押しだわ
0523デフォルトの名無しさん2013/11/24(日) 16:25:52.90
日本だとGitHubがRailsで作られてる影響もあるだろうな
海外だとFacebookもgitからhgに移行してると社員が言っているし
0524デフォルトの名無しさん2013/11/24(日) 17:13:39.85
svnの退潮とgitの流行はSourceForgeの退潮とGitHubの流行とも関連していると思うな。

どっちが卵でどっちがニワトリか判然としないけど。
0525デフォルトの名無しさん2013/11/24(日) 20:17:09.86
GitHubたんもSourceForgeをオススメしてるんだよ

https://help.github.com/articles/distributing-large-binaries
0526デフォルトの名無しさん2013/11/24(日) 21:27:00.17
ストレージコストのかかる用途を体よくSFにオフロードしているようにしか見えんw
0527デフォルトの名無しさん2013/11/24(日) 21:48:57.54
>>427-432
gitとかを使う場合は作業開始からブランチ切ってやるの？それともずっとmasterブランチ？
0528デフォルトの名無しさん2013/11/24(日) 22:15:45.64
作業ブランチは毎回つくる
切りが良いところでmasterにmerge
0529デフォルトの名無しさん2013/11/24(日) 23:21:18.23
gitだと気にせず後からブランチにしてmasterは巻き戻すとかできるから
複数作業が混ざらないようにしてれば適当でもいいよね
0530デフォルトの名無しさん2013/11/25(月) 01:30:13.93
>>528-529
なるほど、参考になったサンクス
0531デフォルトの名無しさん2013/11/25(月) 13:56:03.23
>522
俺も、会社で使うならMercurialの方が向いてると思う。
Subversion脳からの移行も、gitより簡単だし。
0532デフォルトの名無しさん2013/11/25(月) 15:37:54.89
multiple heads でハマるんですね。
0533デフォルトの名無しさん2013/11/25(月) 15:50:50.80
同一ブランチに同時に複数人が変更をコミットした状態の表現としてマルチヘッドは有る意味
自然だと思うのね。
0534デフォルトの名無しさん2013/11/25(月) 16:45:45.51
>>533
> 自然だと思うのね。

俺は全くそうは思わない。
0535デフォルトの名無しさん2013/11/25(月) 16:58:59.30
JapaneseDownload - Mercurial
http://mercurial.selenic.com/wiki/JapaneseDownload

>TortoiseSVN 同様、作業コピーとリポジトリについてはインデックスサービスを止め、ウィルススキャンから除外するよう お勧めします

これってどういう理由からなん？
05365352013/11/25(月) 16:59:35.65
これってgitとか他のバージョン管理ツールでもインデックスサービスとかを止めたほうがいいってこと？
0537デフォルトの名無しさん2013/11/25(月) 17:02:02.87
>>535
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&;dsMessageId=2437253
05385352013/11/25(月) 17:10:41.13
>>537
㌧
つまりTortoise系列の固有の問題でバージョン管理システムの問題というわけではないわけね
0539デフォルトの名無しさん2013/11/25(月) 17:24:55.13
>>538
> つまりTortoise系列の固有の問題でバージョン管理システムの問題というわけではないわけね
そういう結論なのかなぁ
0540デフォルトの名無しさん2013/11/25(月) 17:29:21.42
>>534
そうかな。
Mercurialは子リビジョンを持たないリビジョンをheadと呼んでいるだけであって、
作業ブランチでの他の人の変更をpullした場合、それらをmergeするまでは大抵は
同一ブランチ内でマルチheadな状態だよ。

単に未merge状態の呼称の仕方の問題だと思う。
0541デフォルトの名無しさん2013/11/25(月) 17:36:44.74
アンチウィルスソフトやインデックスサービスと競合起こすってことは
ローカルでリポジトリ作るたびにそれぞれ除外設定してかないといけないのか
Windowsだと面倒なんだね
0542デフォルトの名無しさん2013/11/25(月) 17:44:23.37
TortoiseCVS
TortoiseSVN
TortoiseGit
TortoiseHg
TortoiseBzr
0543デフォルトの名無しさん2013/11/25(月) 17:46:12.13
全部入れたら右クリックメニューが酷いことになりそう
0544デフォルトの名無しさん2013/11/25(月) 17:55:13.58
>>540
「同一ブランチに複数人が変更をコミットした状態」を「マルチヘッドと呼ぶのが自然」というのが同意できない箇所。
じゃぁどう呼ぶのが自然かとかそういうことではなくて。
これがあるからMercurialは分かりづらいんだと思うんだが。
0545デフォルトの名無しさん2013/11/25(月) 18:20:20.56
>>541
> Windowsだと面倒なんだね
C:\reposとかC:\projとかにフォルダを限定して作業すればそうでもないよ。
0546デフォルトの名無しさん2013/11/25(月) 18:21:56.88
個人で趣味のプロジェクトなら何が良いですか？
作業マシンは書斎のWindows7, トイレのWindowsXP, 布団用のSurface Pro 2
サーバはScientific Linuxを使う予定です
ダサい恥ずかしいコードなので外に出したくないです
なのでローカルエリアで完結していると助かります
0547デフォルトの名無しさん2013/11/25(月) 18:26:42.26
>>545
そういう手もあるな
その場合は外からリポジトリ持ってくるときは手動でウィルスチェックかけなきゃならんだろうけど
0548デフォルトの名無しさん2013/11/25(月) 18:27:00.53
「入門Git」でマルチヘッドになったツリーをmergeなりrebaseなりで合成する図を見て
これがGitの醍醐味か、と感動したもんだ
0549デフォルトの名無しさん2013/11/25(月) 18:28:15.47
トイレで作業ができるほど長く籠ることがあるのか、それに驚き
0550デフォルトの名無しさん2013/11/25(月) 19:03:16.27
トイレより精神が平穏に満ちた空間はないよ
まさに文化の極みだね
0551デフォルトの名無しさん2013/11/25(月) 19:18:28.54
multiple heads の意味が理解できないプログラマも居るから注意が必要だ。
適当に解消してソース壊しまくったオッサン。
結局プロジェクト掻き回しただけで逃げ出したけどな。
0552デフォルトの名無しさん2013/11/25(月) 19:42:36.50
分からないことがあって
自分で調べても尚わからない、もしくは至急解決する必要があるとき
分かる人に訊いてもいい雰囲気が大事
0553デフォルトの名無しさん2013/11/25(月) 21:10:44.71
>>546
Mercurial
0554デフォルトの名無しさん2013/11/25(月) 23:36:40.33
>>546
何だか羨ましいと思った。
全部LANで繋がってると楽しそう。
俺はトイレに雑誌置いてて、気が付くと
お尻だしたまま寝てる。
0555デフォルトの名無しさん2013/11/26(火) 00:26:50.64
>>544
分散型ではMercurialが初めてだった自分にはわかりやすく自然に思えるんだが、Gitから入った人にはそうは思えないかもね
Mercurialではブランチはチェンジセットに付けられる名前で、ブランチに関係なくリポジトリ内に存在する全てのチェンジセットが常に見えていて、枝分かれがあって初めてヘッドが増える
Gitではブランチはコミットを指す目印で、コミットから親をさかのぼる形でのみ履歴が見えていて、枝分かれが起こり得る部分はあらかじめ異なるブランチになるようにできている
ブランチの概念が全く別物であることがわかってしまえばどちらも理解できると思う
0556デフォルトの名無しさん2013/11/26(火) 00:41:56.07
マジかよ
ブランチの概念ってそれぞれのシステムごとに違うのかよ
0557デフォルトの名無しさん2013/11/26(火) 05:30:16.21
>>555
わかりやすい対比感謝。
ちなみに自分もMercurialから入ったのでマルチプルヘッドは呼称も概念も自然。
Gitのブランチはパス、Mercurialのブランチはサブツリーやサブグラフってとこかな。
0558デフォルトの名無しさん2013/11/26(火) 10:06:06.53
bzrとの対比を誰か書いてくれないものだろうか。
どうも今一つbzrから乗り換える気にならんのだよ。
0559デフォルトの名無しさん2013/11/26(火) 11:19:19.37
svnだと、HEADと言えばある一点のみを常に指し示すので非常にわかりやすい
0560デフォルトの名無しさん2013/11/26(火) 13:37:19.27
svnはブランチが上の方から別ツリーになるから何か調べようとしたときにわかりやすいよな
0561デフォルトの名無しさん2013/11/27(水) 08:12:00.44
svnは最高だ
0562デフォルトの名無しさん2013/11/27(水) 15:27:54.03
バージョンシステムごとの概念の違いの比較の表とかあればいいのいね
0563デフォルトの名無しさん2013/12/01(日) 01:51:03.22
リポジトリって何？
VisualStudioで出てくるソリューションみたいなもの？
0564デフォルトの名無しさん2013/12/01(日) 06:47:11.58
VSで言うソリューションのディレクトリの、その時その時の現状を
バージョン管理システムへ報告していった、
そのデータを蓄積する場所がリポジトリ、かな
0565デフォルトの名無しさん2013/12/01(日) 11:27:55.82
>>563
履歴を含んだデータの入れ物
0566デフォルトの名無しさん2013/12/01(日) 14:29:32.30
なるほど、わからん
0567デフォルトの名無しさん2013/12/01(日) 15:17:39.02
取り敢えず、入れもんをカッコつけて言ってるだけだよ。
0568デフォルトの名無しさん2013/12/01(日) 15:38:09.27
例えば、VisualStudioのソリューション(の現在の版)をMercurialのリポジトリへコミットする。
そのリポジトリには過去の版からの履歴が入ってる。
…という感じ。何となくニュアンスが分かればOKかと。
0569デフォルトの名無しさん2013/12/01(日) 17:17:34.41
>>564-568
㌧
なんとなくわかった気がしなくもない
0570デフォルトの名無しさん2013/12/01(日) 18:22:44.82
いやVisual SourceSafeのドキュメントににVisualStudioに沿った説明があるのではとおもったが
VSS自体がお亡くなりになっていたのね。知らんかった。
0571デフォルトの名無しさん2013/12/01(日) 20:46:50.13
いかん、この様子だとGitとかMercurialどころかTFSにも乗り換えられずVSSに一生閉じ込められたままだ
なんとしても脱出するんだ！
0572デフォルトの名無しさん2013/12/01(日) 20:49:37.55
GitってPC9801みたいにすぐに主流から消えちゃう？
0573デフォルトの名無しさん2013/12/01(日) 21:04:49.69
すぐに主流から消えちゃう程度のクソソフトだと思う？
Gitを殺すほどのキラーソフト候補って今何かある？
0574デフォルトの名無しさん2013/12/01(日) 21:33:43.01
gitは俺が使い出したから後3、4年で廃れるよ
0575デフォルトの名無しさん2013/12/01(日) 22:05:21.97
hgがgitより良いっていう話をよく聞くから主流はそのうちhgに
0576デフォルトの名無しさん2013/12/01(日) 22:45:54.87
Hard Gay
0577デフォルトの名無しさん2013/12/01(日) 23:29:21.86
最後まで残るのはsvn
0578デフォルトの名無しさん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にあらずという状況さ。
0579デフォルトの名無しさん2013/12/02(月) 00:24:12.06
それを聞いて安心した
バージョン管理システムにどれを導入しようか迷ってたが
Gitに決まり
0580デフォルトの名無しさん2013/12/02(月) 00:40:55.13
うわぁ…
0581デフォルトの名無しさん2013/12/02(月) 00:41:23.21
てか、Linuxの開発用に使われ続けられるから廃れることはない。主流から外れることはあるだろうが。
0582デフォルトの名無しさん2013/12/02(月) 00:44:07.34
非分散型ならこれ使っとけ
ってやつはある？
0583デフォルトの名無しさん2013/12/02(月) 00:44:53.55
非分散型？
集中型以外にもあるのか
0584デフォルトの名無しさん2013/12/02(月) 00:50:55.82
最近出てきたやつだろなんて言ったかわすれたが
0585デフォルトの名無しさん2013/12/02(月) 01:17:56.07
集中型って和名なのか
英語圏だとクライアントサーバー型となってる
0586デフォルトの名無しさん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
0587デフォルトの名無しさん2013/12/02(月) 01:25:18.88
バージョン管理も和名か、というよりバージョンが和製英語的な使い方か
0588デフォルトの名無しさん2013/12/02(月) 06:44:05.39
>>586
gitのメインテナーがリーナスだと思ってたら、濱野 純になってる
0589デフォルトの名無しさん2013/12/02(月) 07:42:24.92
>>578
スタバだとMacのシェアが圧倒的
0590デフォルトの名無しさん2013/12/02(月) 07:48:47.08
最近はsurface pro 2が伸びて来てるね
やはりビジネスマンは圧倒的に窓pcだよ
ガキやアーティスト気取りはMacで満足かもだけどね
0591デフォルトの名無しさん2013/12/02(月) 07:49:17.62
>>588
いつのまにかどころかほとんど濱野さんのはず
Linus君にはLinuxがあるからね
0592デフォルトの名無しさん2013/12/02(月) 08:04:31.96
都内で行われてる IT 系の勉強会だと Mac の率がものすごく高いけど。
0593デフォルトの名無しさん2013/12/02(月) 08:07:25.70
>>578
> WindowsよりMacが良いって話もよく聞くけど

それ、一部の声の大きい人が騒いでるだけだから (w
0594デフォルトの名無しさん2013/12/02(月) 08:13:42.70
両方使ったがシンプルさと美しさは断然Macだね
ハードまで含めてすべてが調和してる
でも開発するならWindowsだな
Macは開発環境がしょぼすぎる
あくまでクライアントのためのマシン
0595デフォルトの名無しさん2013/12/02(月) 08:13:45.19
>>588
これ見ると Git の開発で濱野さんがどれだけ commit してるかわかるよ
パンダのアイコンが濱野さんね
https://github.com/git/git/graphs/contributors
0596デフォルトの名無しさん2013/12/02(月) 08:16:11.26
ぶっちゃげ.net関連を除けば開発環境としてWindowsにメリットは今では殆ど無い。

むしろデプロイするターゲットがLinuxなどのUnix系だと素でUnixであるOSXの方が
開発には便利でWindowsとかかえって面倒。
Cygwinでビミョーにお茶を濁したりLinuxの仮想環境をわざわざ入れるまでして
Windowsにこだわる理由が無い人が増えてきたと言うこと。
0597デフォルトの名無しさん2013/12/02(月) 08:18:39.62
ビジネスでは窓が殆どだからねぇ
Linuxの利点なんて今やタダなだけだし
0598デフォルトの名無しさん2013/12/02(月) 08:19:37.25
Winで無いとダメという人は、具体的にどんな開発環境を使っているの?
0599デフォルトの名無しさん2013/12/02(月) 08:21:38.05
Web 系、サーバー系の開発だったら Unix マシンである Mac の方が良いと思う
0600デフォルトの名無しさん2013/12/02(月) 08:22:38.59
vsだろ
これ以上の開発環境なんかないよ
0601デフォルトの名無しさん2013/12/02(月) 08:24:01.22
マカーはxcodeとか使うのか？
0602デフォルトの名無しさん2013/12/02(月) 08:26:03.35
Eclipse、IntelliJ、Netbeansに必要な言語プラグインを入れて使う。
0603デフォルトの名無しさん2013/12/02(月) 08:37:32.65
EclipseやVim、金出すにしてもIntelliJといったところか。iOS開発も抱えているのであればXcode。
.net以外はWindowsいらないよ。
0604デフォルトの名無しさん2013/12/02(月) 08:46:06.40
エクリプスなんかでよく満足できるな
0605デフォルトの名無しさん2013/12/02(月) 08:56:58.43
むしろEclipse慣れてるとVSなんかでよく満足できるな、になるけどな
0606デフォルトの名無しさん2013/12/02(月) 09:00:26.28
>>598
禿丸
0607デフォルトの名無しさん2013/12/02(月) 09:02:15.37
>>593
これ思い出した
ttp://www.youtube.com/watch?v=HNJ7wI79qRE
ttp://rocketnews24.com/2011/10/07/138206/
0608デフォルトの名無しさん2013/12/02(月) 10:36:51.98
MacでWindowｓは使えるけど、WindowsPCでMacOSは使えない。
只使われているだけのIT土方と違って、まともなエンジニアはMac比率が高くなるのも当然。
0609デフォルトの名無しさん2013/12/02(月) 13:57:47.44
>WindowsPCでMacOSは使えない

あった気がするけど
hackintosh.com だか hackInt0sh.org だか
0610デフォルトの名無しさん2013/12/02(月) 14:27:58.66
OSｘ86の話はスレ違い
0611デフォルトの名無しさん2013/12/02(月) 14:47:59.13
多彩なハードウェアに対応するWindows
限られたハードウェアでしか動かいないMac

つまり、Windowsは優秀だって話だな
0612デフォルトの名無しさん2013/12/02(月) 15:08:35.57
OS依存の少ないWebアプリを作ればいいのよ
0613デフォルトの名無しさん2013/12/02(月) 16:14:31.18
WebアプリはIEでの動作確認という壁が・・・
0614デフォルトの名無しさん2013/12/02(月) 16:44:11.07
おまえらバージョン管理システムについて語れよ！
0615デフォルトの名無しさん2013/12/02(月) 17:44:08.59
ふぉー
0616デフォルトの名無しさん2013/12/02(月) 17:46:56.12
マカーがディレクトリごと固めて公開するとゴミが大量に入るんだよねw
0617デフォルトの名無しさん2013/12/02(月) 17:55:42.05
.DS
0618デフォルトの名無しさん2013/12/02(月) 18:05:28.06
.DS_Store ._.DS_Store に対して言いたいこと
http://anago.2ch.net/test/read.cgi/mac/1384074458/
0619デフォルトの名無しさん2013/12/02(月) 18:09:04.11
マカー自体がゴミなのだから仕方ない
0620デフォルトの名無しさん2013/12/02(月) 19:57:26.84
>>611
> 多彩なハードウェア
NetBSD「ﾌﾟｯ」
0621デフォルトの名無しさん2013/12/02(月) 22:27:44.68
>>613
IE10だかはけっこうHTML5準拠度高くなかったっけ？
0622デフォルトの名無しさん2013/12/02(月) 23:04:21.22
>>621
何れにしてもテストはしなきゃならん。
0623デフォルトの名無しさん2013/12/02(月) 23:14:35.88
どっちでもいいから破滅してひとつに統一してよ
0624デフォルトの名無しさん2013/12/02(月) 23:25:38.81
git か hg か好きな方使うといいよ
0625デフォルトの名無しさん2013/12/03(火) 03:01:11.08
>>616
thumbs.dbのこと？
0626デフォルトの名無しさん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
0627デフォルトの名無しさん2013/12/03(火) 20:40:21.99
bzrのことも忘れないであげてください
0628デフォルトの名無しさん2013/12/03(火) 22:39:34.47
>>627
もう成仏させてやれよ
0629デフォルトの名無しさん2013/12/04(水) 20:10:44.74
多彩なハードウェアっていう言い方だと誤解を招くかもしれないが、周辺機器なんかでWindows用のドライバしかないなんてものはたくさんあるわけで、
そういう機器を使ったものを作りたい限り、Windowsで開発するしかない。
なんか、別にWindowsに限ったことじゃないけど、事情もよくわからず勝手な決め付けで「○○を使ってる奴は時代遅れ」っての、すごく頭悪そう。
0630デフォルトの名無しさん2013/12/04(水) 20:39:23.43
マカーは時代の流れ見えてないよね
これからはlinuxの時代さ
0631デフォルトの名無しさん2013/12/04(水) 20:45:06.92
svnを使ってる奴は時代遅れ
0632デフォルトの名無しさん2013/12/04(水) 21:08:08.97
うるせえばか
髪の毛むしり取るぞ
0633デフォルトの名無しさん2013/12/04(水) 21:51:35.52
hgがハゲを連想させるから移行できない
0634デフォルトの名無しさん2013/12/05(木) 00:09:10.56
>>629
そういうのを作らないのであればWindowsは不要だし、最近より一般化してきたウェブ系やUnix系の作業の
場合はOSXの方が便利でWindowsはかえって不便というだけの話。

時代遅れとか関係ない。純粋に適材適所の問題。
0635デフォルトの名無しさん2013/12/05(木) 00:14:11.73
OSXなんて生産性もコストも最悪だろ
そうでなければもっと売れるし案件も増える
しかし現実は厳しいね
0636デフォルトの名無しさん2013/12/05(木) 00:41:34.11
パソコンソフト作ることしか頭にないんだな>>635は
0637デフォルトの名無しさん2013/12/05(木) 01:05:02.78
議論に熱くなってしまうのは仕方ないことだが
OSの議論ならOSのスレでやってくれ
0638デフォルトの名無しさん2013/12/05(木) 01:08:42.59
>>636
どこの分野でも同じだよ
反論したいなら開発環境としてOSXのシェアがトップの分野を挙げてみろよ
0639デフォルトの名無しさん2013/12/05(木) 02:12:54.16
>>638
iOS
0640デフォルトの名無しさん2013/12/05(木) 10:44:34.04
こいつWindows極めるまで10年かかりましたって顔してるな
そりゃ他のOS触りたくないわけだわ
0641デフォルトの名無しさん2013/12/05(木) 20:50:20.74
この発想の貧困さがマカーだよな()
0642デフォルトの名無しさん2013/12/06(金) 12:07:08.70
常に新しい物には触れてみたいけど時間がなくなってくる感覚はなんなの！
老化だね。
0643デフォルトの名無しさん2013/12/06(金) 15:40:57.16
いいえ、社畜化です。
0644デフォルトの名無しさん2013/12/06(金) 15:49:44.66
社畜なら口開けて待ってりゃ餌出て来るから良い身分だよ
0645デフォルトの名無しさん2013/12/07(土) 11:02:08.19
>>640
そもそもWindowsって、どんどんUIいじくり倒されるから
いくら学んでも次のバージョンで役に立たなくなる知識が多い

…まあ、だからこそWindows一辺倒の人には
「君ならOSXもLinuxもすぐ慣れるよ」と言ってやりたい
あんだけ振り回されて使ってる人なら実際すぐ使えるようになるだろて
0646デフォルトの名無しさん2013/12/07(土) 11:44:52.55
お前らいい加減にしろ。
0647デフォルトの名無しさん2013/12/07(土) 12:08:40.61
Windows のひとに限らないけどさ
開発者ってなんで UI 変えちゃうんだろうな
仕事でアプリ使ったことないのかな
0648デフォルトの名無しさん2013/12/07(土) 12:15:47.83
Mac の人に限らないけどさ
お前らってなんでスレ違いの話題続けちゃうんだろうな
仕事でも間違ったまま進めることが多いのかな
0649デフォルトの名無しさん2013/12/07(土) 12:22:49.34
UI変えたぐらいであたふたするのがマカー技術者なんだよな
基本的な設計がなってないからそうなるんだろうなあ
0650デフォルトの名無しさん2013/12/07(土) 12:45:18.49
>仕事でも間違ったまま進めることが多いのかな

激しく同意させていただきます
0651デフォルトの名無しさん2013/12/07(土) 12:46:23.06
>>649
あいつら機能を意味で覚えないで場所で覚えてる人種だからな
0652デフォルトの名無しさん2013/12/07(土) 12:58:08.64
MacでもWindowsでもスレタイ読めない奴は無能
0653デフォルトの名無しさん2013/12/07(土) 13:16:23.78
>>647
UI買えないと売れない。
一般消費者にとって、UI＝性能。
どんなに内部設計が超絶進化してても、
UIが進化していない＝何もが変わってないから買う必要がない
となる。
0654デフォルトの名無しさん2013/12/07(土) 13:40:36.55
デザイン変えるだけなら理解できるが場所まで変えられたら
間違い探ししてるみたいでイライラするわ
0655デフォルトの名無しさん2013/12/07(土) 19:49:57.66
バージョン管理システムのUIってIDEと統合されていてナンボだと思う。

マージ後にそれぞれのバージョンと比較してコミット前に微調整の編集を加えたりとか。
不具合出たときにあるファイルの過去のバージョンと比較して問題の更新を特定したり。
バージョン管理とはいえ途中でファイルの編集もするし、開発中にサクサク履歴を参照
出来ると非常に便利。

今はIDEとは別にSourceTreeも併用しているけれども、良いアプリながら所詮別アプリ
なのでこの辺りの作業がし難い。
他方でEclipseのプラグインとかも出来や安定性が微妙なんだよね・・・

SourceTreeをIDEに統合して欲しい。ホントに。
0656デフォルトの名無しさん2013/12/07(土) 19:57:23.30
ようするにVS使えですな
0657デフォルトの名無しさん2013/12/07(土) 21:38:54.57
VisualStudioもEclipseに統合できるなら考えても良い。
0658デフォルトの名無しさん2013/12/07(土) 22:08:58.77
>>634
開発にWindows使ってる奴が、ファイル名の大文字小文字考慮しないで作っていて
本番系の環境に持って行ったらビルドできなくてしばらくハマってたな。
気づけば何の事ないことなんだが、普段の環境では大丈夫だからなかなか気づかない。
0659デフォルトの名無しさん2013/12/07(土) 22:17:37.05
Microsoft以外は倒産してプラットフォームを統一するべき
0660デフォルトの名無しさん2013/12/07(土) 22:47:59.71
自分はどんどん Bitbucket や Github に push しちゃって、過去の履歴は Bitbucket や Github の方で見てる。
開発マシン上では Git をコマンドラインのみで使ってる。
0661デフォルトの名無しさん2013/12/07(土) 23:03:32.49
>>658
少し昔にsubversionsでそんなトラブルを経験したことがあったな。
Windowsは短いファイル名の場合大文字小文字を区別しないとうかデフォですべて
大文字扱いしたので、Unix環境とファイル名の不整合がおきて短い名前のファイルが
毎度更新対象になったり変な動作をおこした。
0662デフォルトの名無しさん2013/12/08(日) 03:34:35.93
>>660
正解
0663デフォルトの名無しさん2013/12/08(日) 03:35:58.71
>>661
FATにしてた馬鹿ですね
0664デフォルトの名無しさん2013/12/08(日) 04:55:28.80
NTFSでも起こるよ?
0665デフォルトの名無しさん2013/12/08(日) 05:38:02.29
むしろ大文字小文字区別するのはファイルシステム側の怠慢としか（どうせ簡易なコードで収まるとかそんな理由だろ？）
ユーザ側の使い勝手からすれば同じ名前なのに違うファイルとか混乱のもとでしかない
クラスに同姓同名の生徒がいたら先生も名前だけで呼びづらいだろう

同名ファイルを同一フォルダに入れてるプロジェクトあったら
Windowsマシンではダウンロードできないな
0666デフォルトの名無しさん2013/12/08(日) 06:24:49.32
６６６
http://developers.slashdot.jp/comments.pl?sid=429722&;cid=1468089
0667デフォルトの名無しさん2013/12/08(日) 08:03:25.46
>>665
NTFSだって大文字小文字は区別するよ。
問題は8.3形式のファイル名は特別扱いして区別しない場合もあると言うこと。
理由はMS-DOSとかの古い時代のファイル名にも対応するため。

そんな古い時代のものに関してまで互換性を維持しようとするのは関心するけれども、
それはあくまでMS界隈で閉じた話であるべきだし、色々なOSがアクセスするVCS界隈に
持ち込まれても迷惑だしトラブルだって起こる。
0668デフォルトの名無しさん2013/12/08(日) 08:50:24.19
ren ahoaholongname.txt AhoAhoLongname.txt
これは NTFS でも通らないな
0669デフォルトの名無しさん2013/12/08(日) 09:06:53.17
>>668
おいらのWin7ではできた。CYGWINのmvコマンドではだめだったような気がしたけど
これもできた。
0670デフォルトの名無しさん2013/12/08(日) 09:16:50.66
exoplorerがダメなんだろ
.hogeとかも作れないし
0671デフォルトの名無しさん2013/12/08(日) 10:16:30.27
バカな仕様に今まで疑問も持たずにやってきたのが間違い
Microsoftは来然として間違った慣習は正すからイイよね
0672デフォルトの名無しさん2013/12/08(日) 11:44:18.56
>>665
賢いな
ついでにかたかなも廃止してひらがなに統一しようぜ
0673デフォルトの名無しさん2013/12/08(日) 11:57:17.75
いわゆる全角の「ａ」と「Ａ」も同一視されるのにはびっくりしたもんだ。
あと「:」とか「AUX:」とか変な制限もあるからVCSにWindowsを混ぜるのはやっかいだ。
0674デフォルトの名無しさん2013/12/08(日) 15:27:24.97
Hoge.cppとhoge.cppはWindowsでは共存できないんだよ、Windowsで大文字小文字の区別はファイル名の見た目だけなんだよ
0675デフォルトの名無しさん2013/12/08(日) 18:29:49.17
NTFS上は区別できる。OS上で同一視しているだけ。
0676デフォルトの名無しさん2013/12/08(日) 18:49:17.56
Windows使いは我々のプロジェクトには参加しないでもらいたい
0677デフォルトの名無しさん2013/12/08(日) 19:31:58.11
Hoge.cppとhoge.cppが共存して、かつ敢えて使い分けるプロジェクトに
我々を巻き込まないでもらいたい

大文字小文字よりもUnicode正規化の方が
バージョン管理システムとしては頭痛いところだと思うけど
別に某OSをバッシングする気は無い
0678デフォルトの名無しさん2013/12/08(日) 19:39:43.22
32年前は大文字と小文字を区別しなくて良い画期的なシステムだった

未だにその呪縛から逃げられていないのだけど
0679デフォルトの名無しさん2013/12/08(日) 19:43:06.85
ここで、OSX登場
0680デフォルトの名無しさん2013/12/08(日) 19:45:26.02
拡張子で区別とか、まだ残っているな
0681デフォルトの名無しさん2013/12/08(日) 19:49:51.63
>>677
趣味でOS/2をつついてたころ、わりと有名なオープンソースソフトウェアで大文字と
小文字の違いだけのファイル/ディレクトリがあった覚えが。
うろ覚えだがCONFとconfだったか? どっちかがディレクトリ。
OS/2のファイル名も大文字と小文字を無視するものだった。
0682デフォルトの名無しさん2013/12/08(日) 19:50:58.21
これがWindows三大汚点だ！！！

・ 大文字小文字同一視
・ ファイルパス長制限
・ プロセス引数長制限

すぐに解決するかと思われたが、互換性維持のために永遠に残ることが決定したぞ！
0683デフォルトの名無しさん2013/12/08(日) 19:53:29.09
ファイルパス長の制限って、WindowsのShell系ライブラリの制限か？
0684デフォルトの名無しさん2013/12/08(日) 20:21:08.91
で、肝心のSVNやらGitやらのバージョン管理システムは、そういうファイル名の違いは配慮してくれるの？
0685デフォルトの名無しさん2013/12/08(日) 20:24:35.08
TortoiseSVNは割と丁寧に配慮してくれた

git？何を期待しているんですかｗｗ
0686デフォルトの名無しさん2013/12/08(日) 20:26:39.58
gitってのは正に>>676だからな。
0687デフォルトの名無しさん2013/12/08(日) 20:30:24.79
コンフリクトしますた
0688デフォルトの名無しさん2013/12/08(日) 20:31:11.21
WindowsやOSXはcase-preservingだけどcase-insensitive。
つまりファイル作成時に名前の大文字小文字の違いはちゃんと保存される。
でもファイルを読み込むときに大文字小文字は区別されない。

他のUnix系のシステムはcase-preservingでcase-sensitive。
大文字小文字の違いはちゃんと保存されるし読み込み時も区別される。

VCSも多くはcase-preservingでcase-sensitiveと想定するのが無難じゃないのかな。
例えばファイル名だけでは無く.ignore等のパターンに関しても大文字小文字の違い
は注意した方が良い。
0689デフォルトの名無しさん2013/12/08(日) 20:48:27.57
そもそもどういう需要があって大文字小文字を区別するファイルシステムになったんだろうな
0690デフォルトの名無しさん2013/12/08(日) 20:54:37.70
それは、なんで8+3字のファイル命名法を変えてしまったのか、と言うのに似ている
0691デフォルトの名無しさん2013/12/08(日) 21:06:12.80
Progra~1の暗黒歴史を思い出すな
0692デフォルトの名無しさん2013/12/09(月) 00:48:46.92
>>689
WindowsのNTFSやOSXのHFS+はファイル名を保存する文字コードをUnicodeに決め打ってる。
だから大文字小文字を区別「しない」処理をドライバ内に書ける。

Unix一般ではそういうことはしてないので、ロケールを変えたらファイル名も一緒に化けるのが通例。
そんな状況でドライバ内に文字種を決め打つ処理を入れられるわけがない。

ただしZFSみたいな新しいファイルシステムは例外。
0693デフォルトの名無しさん2013/12/09(月) 00:59:23.81
あとgitの動作はLinuxのファイルシステムに忠実という点では価値がある。Linuxのために作られたんだから。

bzr(や、svnの将来のプラン)は、ファイル名に対してUnicode正規化をかける。
全ファイルシステム中でファイル名の正規化をするのはHFS+とZFSのふたつだけ(と思う)なんだけど
bzrもsvnも、このふたつのファイルシステムとは違う正規化ルールを使う糞っぷり。
誰も幸せにならない。
0694デフォルトの名無しさん2013/12/09(月) 05:03:38.50
unicodeであってもAとaは区別されているから単にポリシーの問題
むしろ別に割り当てられているものを同一視するほうがどうかしてると思うが
0695デフォルトの名無しさん2013/12/09(月) 12:01:59.09
こんな百済ない話題で盛り上がれるおまいらがどうかしてる
0696デフォルトの名無しさん2013/12/10(火) 09:12:46.11
時代はケース・インセンシティブだろ。
0697デフォルトの名無しさん2013/12/10(火) 23:02:44.38
ファイル名は文字列なんだから大文字小文字区別すべき。
0698デフォルトの名無しさん2013/12/10(火) 23:04:35.07
大文字小文字区別するのはコンピュータの仕組み上の都合でしょ
コンピュータを使う人間にとっては大文字小文字の違いで別物だなんて感覚がまずない
0699デフォルトの名無しさん2013/12/10(火) 23:18:02.29
>>697
人間が「か」＋「゛」と「が」を区別できるってんなら同意してやる
0700デフォルトの名無しさん2013/12/10(火) 23:20:59.96
プログラムからアクセスするためのライブラリが充実してるバージョン管理システムと言えば？
0701デフォルトの名無しさん2013/12/10(火) 23:29:54.22
プログラムからアクセスって
普通コマンド叩くだけ（パイプ）じゃないの？
0702デフォルトの名無しさん2013/12/10(火) 23:35:38.53
VSCをアプリのプラグインで埋め込むとかそういう話？
0703デフォルトの名無しさん2013/12/10(火) 23:37:38.16
コンピュータの都合でハイフンとダッシュとマイナスが同一記号で表現されてるし
0704デフォルトの名無しさん2013/12/10(火) 23:45:32.44
>>701
そういう雑な作りではなくちゃんとしたライブラリとしてまとまっているもの
0705デフォルトの名無しさん2013/12/11(水) 00:37:18.44
ソフトウェア開発用途に関してはCamelCaseをファイル名に使う流儀もあるから
一律にcase insensitive
にするのも微妙だなぁ。
0706デフォルトの名無しさん2013/12/11(水) 01:02:07.34
CamelCaseをファイル名に使う流儀において
case insensitiveだと何が微妙なの？
Non-case-preservingな糞システムを使いたいって？
0707デフォルトの名無しさん2013/12/11(水) 01:37:52.61
大文字と小文字を区別したくないってのは人間側の都合なのではないかという見方もあるんじゃゃないか？
日本語だとひらがなとカタカナは区別しないなんていう仕様だったら暴動が起きるわけだしさw
0708デフォルトの名無しさん2013/12/11(水) 01:43:35.70
英語のアルファベットの大文字と小文字は一対一対応だけど
ひらがなとカタカナは一対一対応じゃないから等価には扱えないよ。　ヴ　とかね
0709デフォルトの名無しさん2013/12/11(水) 01:50:36.26
「バージョン管理システム 連携」でググった感じからすると
ライブラリがありそうな雰囲気は感じてくる
0710デフォルトの名無しさん2013/12/11(水) 02:01:06.16
いやつまり何が言いたかったかっていうと、等価に扱いたいかどうかってのは人間側の都合によって大きく変わるだろう、という話。
一対一対応じゃないから等価に扱えないってのは技術的にはそうかもしれないけど、
そもそも一対一対応ではない理由としてひらがなとカタカナは等価であるっていう意識が利用者にないからそういうことになるわけで。
英語だったとして、ある文字列の大文字小文字違いのものがあったとして、等価であるかどうかってケースバイケースだろうから、正解はないんじゃないの？
Case-preservingかつCase-insensitiveなファイルシステムって一貫性なくて気持ち悪い感もあるが、現実的な落とし所だろうなと個人的には思うけど。
0711デフォルトの名無しさん2013/12/11(水) 02:25:05.66
TortoiseSVNやTortoiseHGのフォルダ見るとSVN用のDLLがいっぱいあるけど
0712デフォルトの名無しさん2013/12/11(水) 05:50:37.95
ケースセンシティブかどうかは各プラットフォームの中で閉じる分にはそれぞれ自由に
ポリシー設定して良いけど、色々なプラットフォームが関わるプロジェクトの場合には
厳しい方に合わせないとダメだよ。

例えばLinuxとWindowsが相乗りするプロジェクトの場合はWindows側が配慮して大文字
小文字をゲンミツに扱わないと他方が困る。念のため、これは優越の問題では無くて、
そうしないとプロジェクトが回らないということ。

VCSに複数人がコミットするプロジェクトの場合とかで無くても、例えばデプロイ先が
LinuxのウェブアプリをWindows上で開発する場合も大文字小文字は要注意だよね。
0713デフォルトの名無しさん2013/12/11(水) 05:56:52.16
大文字小文字ならまだいいさー
:が入っててM$じゃ取得すらできなくなるのどこかにあったからな
0714デフォルトの名無しさん2013/12/11(水) 09:04:24.42
>>712
>例えばLinuxとWindowsが相乗りするプロジェクトの場合はWindows側が配慮して大文字
小文字をゲンミツに扱わないと他方が困る。

逆じゃないの？
Linuxで大文字と小文字の違いで別のファイル作られるとWindows側が困る

大文字と小文字を勝手に書き換える糞なアプリケーションもあるけど
それはOSの問題じゃないし
開発ツール関係でそんな酷いのはない
大文字と小文字を区別せずにハードコーディングするのも糞プログラマの問題
0715デフォルトの名無しさん2013/12/11(水) 10:28:08.71
Windowsしか使わないクライアントにいじられないように、
設定ファイルの名前をauxにしたのは懐かしい思い出w
0716デフォルトの名無しさん2013/12/11(水) 11:36:10.99
>>714
C言語でクロスプラットフォームのプロジェクトだったけど、
includeするヘッダファイルについて、Windows上がりは考慮が浅い奴が居るのよ。
#include "XxxYyy.h" って書いてるんだけど、ファイル名は xxxyyy.h とか。
0717デフォルトの名無しさん2013/12/11(水) 12:21:23.66
だからそれはシステムの問題じゃなくてユーザの問題だろ
そういうポカが見過ごせない程度にあるなら
数行のスクリプト書いてテストに入れるだけ
0718デフォルトの名無しさん2013/12/11(水) 12:47:37.30
>>707
半角カナ涙目
0719デフォルトの名無しさん2013/12/11(水) 15:08:00.10
>>717
ユーザの問題だよ。
ファイル名の大文字小文字に無頓着でもWindows上だとビルドも通って正常に動いた
プロジェクトがケースセンシティブな環境に持ち込んだとたんに動かなくなることが
あるので、相乗りプロジェクトの場合はWindowsで参加している人もちゃんと大文字
小文字に配慮する必要があると言うこと。
0720デフォルトの名無しさん2013/12/11(水) 15:32:24.65
Winは未だに内部名とシェル上の表示名をすり替えるとかやってるから
意識して書き分ける方がナンセンス
0721デフォルトの名無しさん2013/12/11(水) 15:48:59.17
MSですらソースでは#include <windows.h>とか全部小文字なのに
実際のファイル名がWindows.hとか嫌な状態だ
0722デフォルトの名無しさん2013/12/11(水) 15:57:05.95
UNIXから持ってきたツールだとcase sensitiveでソートするから意識した方が良い
Windowsに限った話でも、explorer上で大文字と小文字が混合しているのは醜い
0723デフォルトの名無しさん2013/12/11(水) 16:05:15.67
8.3ルールを徹底しているのならそれでもよい
0724デフォルトの名無しさん2013/12/11(水) 16:41:29.69
結論としてはファイル名はユーザーが大文字小文字意識しなさいってことだな。
そろそろスレ違いになりそうだ。
0725デフォルトの名無しさん2013/12/11(水) 17:14:47.17
ケースセンシティブなVCSやプロジェクトをケースセンシティブで無いファイルシステム上で
扱うのであれば最終的にはユーザーにその辺り注意する役割が降ってくるよね。
0726デフォルトの名無しさん2013/12/11(水) 18:19:43.57
リポジトリだって仮想ファイルシステムのようなもんなんだから
どのフォーマットをエミュレートするか指定できる機能があればいいんだけどな
0727デフォルトの名無しさん2013/12/11(水) 21:09:42.76
バージョニングファイルシステム上にリポジトリが構築されて
リポジトリはバージョニングファイルシステムをエミュレート
……あれ？
0728デフォルトの名無しさん2013/12/11(水) 21:27:58.76
おまえら色々苦労してきたんだな
他のOSの奴と共同プロジェクトしたことないから全くついていけん
0729デフォルトの名無しさん2013/12/11(水) 21:53:10.64
俺の感覚では、同じフォルダにWindows.hとwindows.hが有って、それぞれが
別の役割を持つほうが異常に感じる。
ぜひ同一視してほしいし、Windows.hがすでに有るなら、windows.hを新規作成
出来ないようにしてほしい。
これらは同じもののように見える。
0730デフォルトの名無しさん2013/12/11(水) 22:12:21.86
だらしないOSの仕様をVCSが吸収してやればいいのですよ
0731デフォルトの名無しさん2013/12/11(水) 22:48:29.72
>>729
変数 Bar と bar があって別の役割を持つプログラム言語は使うべきじゃないな
CとかC++とかJavaとかC#とか
ぜひ同一視してくれるBASICを使うべきだ
0732デフォルトの名無しさん2013/12/11(水) 22:49:01.35
お前ら本当にIT従事者なんか？
仕事する前にファイル名を制限するコードを先に書けよ
0733デフォルトの名無しさん2013/12/11(水) 22:51:39.16
ファイル名をいい加減に決めるから不幸になる

つまるところファイル名を連番にするというシンプルかつ厳格なルールが
市民を幸福にさせるのですね！
0734デフォルトの名無しさん2013/12/11(水) 22:52:10.22
>>731
俺はプログラミングはBASICから入ったからCを知ったときはマジ驚いたわ、
0735デフォルトの名無しさん2013/12/11(水) 22:53:06.84
連番ファイル名の悲劇

100.txt
1000.txt
1100.txt
2.txt
32.txt
4.txt
0736デフォルトの名無しさん2013/12/11(水) 22:58:52.82
NTFSがCase-sensitiveなのはWindowsをPOSIX準拠にする為に仕方無く従った仕様だしな
0737デフォルトの名無しさん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
0738デフォルトの名無しさん2013/12/11(水) 23:18:04.92
>>733
数字だとネットワークでの分散管理で破綻するのでハッシュ値にすべきだな
0739デフォルトの名無しさん2013/12/11(水) 23:22:49.77
ハッシュ値は完全に一意に作られるわけでは無いので運が悪いと・・・
0740デフォルトの名無しさん2013/12/12(木) 04:07:46.06
>>698
ホんトニソう思うカ？
たトエバ wInDOwS, lINuX ガオなじニミエるのカ？
ヒラガなトかタカなノチがイヲイしキシナいのカ？
0741デフォルトの名無しさん2013/12/12(木) 04:09:32.09
× > たトエバ wInDOwS, lINuX ガオなじニミエるのカ？
○ > たトエバ wInDOwS, lINuX ガ Windows, Linux トオなジにミえルノカ？
0742デフォルトの名無しさん2013/12/12(木) 04:15:29.98
画像認証みたいｗ
0743デフォルトの名無しさん2013/12/12(木) 05:47:15.10
才ナツ゛二Ξ工ﾉﾚ
0744デフォルトの名無しさん2013/12/12(木) 07:22:15.71
>>729
UNIXには、makefileとMakefileがあったらmakefile優先と言うコマンドが
PWB/UNIX(V6,V7)の頃から存在するのだ
0745デフォルトの名無しさん2013/12/12(木) 08:22:15.36
そもそもargv[0]の値見て挙動変えたりするしな
0746デフォルトの名無しさん2013/12/12(木) 18:09:15.46
気持ち悪い仕様だな
やはりWindowsが一番いいね
0747デフォルトの名無しさん2013/12/12(木) 22:00:09.03
NTFSにはWindows.hとwindows.hが同時に存在しうるが、Windows OSからは片方しか見えない
この状態を解消するには、二回 remove するしか無いという糞みたいな仕様は何とかならんのか
0748デフォルトの名無しさん2013/12/12(木) 22:09:11.86
>>747
両方存在してるってどうやって確認するの？
0749デフォルトの名無しさん2013/12/12(木) 22:20:42.24
>>744
それってメリットなの？
0750デフォルトの名無しさん2013/12/12(木) 22:36:15.19
バージョン管理システムが無かった時代にMakefileを使い分けてたとかじゃね
0751デフォルトの名無しさん2013/12/12(木) 22:48:04.47
それだと単に盲腸になってるだけな気が
0752デフォルトの名無しさん2013/12/13(金) 01:58:37.37
ファイルが見えなくなるって怖いな。
DIRコマンドでも片方しか見えないの？
0753デフォルトの名無しさん2013/12/13(金) 02:12:54.70
コマンドプロンプトで
echo hoge > hoge.txt
echo HOGE > HOGE.TXT
をやっても最初のに上書きされるだけだったけど・・・
エクスプローラーでも同一ファイル扱いになるし
>>747の再現ってどうやるのさ
0754デフォルトの名無しさん2013/12/13(金) 02:21:12.14
>>753
NTFSを使えるWindows以外の大文字小文字を区別するシステムで作るのでは？
0755デフォルトの名無しさん2013/12/13(金) 02:23:11.43
SFUとかSUAを使う
あるいはLinux等の別OSからNTFSをmountする
0756デフォルトの名無しさん2013/12/13(金) 02:24:00.13
LinuxのだとNTFS領域は読み込みはOkだけど書き込みは自己責任って感じで怖すぎて試せないお
0757デフォルトの名無しさん2013/12/13(金) 05:25:16.38
>>753
cygwinでもできると思うよ。>715のauxはvygwinなら作れるから。
0758デフォルトの名無しさん2013/12/13(金) 10:28:55.55
>>730
だらしないってどっちのこと言ってる？
処理としてはケースセンシティブの方がだらしないのはわかってるよね？
0759デフォルトの名無しさん2013/12/13(金) 15:32:23.34
処理においても文字列比較等で strict match とか loose matchって言うよね
0760デフォルトの名無しさん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度変わってくると思うんだが。
極論を言ってしまえば、だらしなさの根本は違うコードポイント列を同一視したりしなかったりする人間そのものだろ。
0761デフォルトの名無しさん2013/12/13(金) 15:39:45.56
だらしないといえば、まずUnicodeを決めてる連中もだらしないからなあ
Unicodeを基準にすると、Unicodeのバージョンに縛られることになってHFS+の惨状があちこちで起こることになる
0762デフォルトの名無しさん2013/12/13(金) 16:42:32.58
>>760
> いい加減「だらしない」とか「クソ」とか「腐った」とか言って自分の嫌いなOSの
> 仕様をdisるのはやめないか？なにも生み出さない。

まったくその通り。

アルファベットにしても欧州諸言語におけるアクセント記号とかエスツェットなど
合字の扱いとかあるので難しい。正直使用目的に応じたケースバイケースだと思う。

ただ様々なシステムが相乗りするようなプロジェクトの場合は概ね無難な最大公約数
としてはファイル名はASCII文字だけ、case preservingかつsensitiveただし小文字
等にそろえた場合に同じになるファイル名は避ける、といったあたりだと思う。
0763デフォルトの名無しさん2013/12/13(金) 19:30:10.93
HFS+の惨状は主に林檎独特の方言に起因してるんじゃないのか？
0764デフォルトの名無しさん2013/12/13(金) 19:47:16.60
>>763
方言(互換漢字の扱い)もそうだけど、使われているUnicodeテーブルのバージョン自体も古いので
最新のテーブルを使ってしまうと食い違いが酷い＆新しく追加された文字は正規化されない

Unicodeが「バージョンアップ」する仕様である以上は、ファイルシステムを作った時点で
Unicodeのバージョンも固定しないといけないわけで
するとアプリはバージョン違いのテーブルをいくつも抱え込む必要が出てくるわけで

HFS+だからといってその辺のライブラリを適当に使ってNFD変換するアプリでこの辺の差異に遭遇すると
まだ何の対応もなく素通ししてくれたほうがマシに思えるレベルで軽く絶望できる。
svnのunicode_pathパッチとか、bzrとかな。
0765デフォルトの名無しさん2013/12/13(金) 21:34:46.60
Unicodeの継ぎ接ぎ拡張って、調べれば調べるほど人間がいかに好き勝手に文字という概念を取り扱ってるかという印象しか抱けないな。
アルファベットくらい世界が単純だといいんだろうけれど、漢字は複雑だしローカル拡張が多すぎて(元の字は違うのに見た目は同じ略字とか)
意味も見た目もちゃんと取り扱える文字コードを作るってこと自体幻想なんだろうなと思ってしまう。
つまるところ、人間がよくないw
0766デフォルトの名無しさん2013/12/13(金) 22:43:42.95
誰もこんなことになるとは予想してないから仕方ない。
人工的に作って実用になった文字はハングルしか知らないし。
0767デフォルトの名無しさん2013/12/13(金) 23:20:00.90
チェロキー文字は、まぁちょっと特殊か。
0768デフォルトの名無しさん2013/12/13(金) 23:36:11.11
バージョン管理うんぬんではなく
共同プロジェクトに関する問題だよね
ここまでの不毛な議論の連続は
0769デフォルトの名無しさん2013/12/14(土) 23:09:26.90
様々な環境で運用する事案は、それぞれの環境に配慮した運用をするべきであって
嫌われるのは、自分の環境を前提として、他の環境を考慮しない無知と傲慢。
俺様ルールを主張すること自体は別に構わないが、そのテリトリーから一歩も出て
もらっては困る。迷惑だから。
0770デフォルトの名無しさん2013/12/14(土) 23:44:13.94
そんなことより
バージョン管理システムについて語ろうぜ
0771デフォルトの名無しさん2013/12/15(日) 02:41:50.56
http://toro.2ch.net/test/read.cgi/motenai/1381308314/242-257

この感じからするとITへの就職を考えるならgitよりsvnのほうがいいの？
0772デフォルトの名無しさん2013/12/15(日) 03:08:35.15
gitメインにしつつ両方やっとけ
0773デフォルトの名無しさん2013/12/15(日) 03:19:34.95
>>771
svnはバージョン管理ツール。
gitはバージョン管理もできる開発ツール

svnはバージョン管理するぐらいしか出来ないが、
gitはソースコードの修正とコミット（リリース）を
適切に行うための各種機能が付いている。

具体的にはローカルで大規模な開発しながらも
その開発でできた機能のうち先にリリースできる部分や
小さい修正に分離したり整理することで
大きなものを小さく開発の連続にすることが可能になる。
0774デフォルトの名無しさん2013/12/15(日) 03:41:39.05
おｋ
gitやりつつsvnも覚えることにする
0775デフォルトの名無しさん2013/12/15(日) 03:47:10.39
Gitって、ソース修正できるような、エディタ機能もあるんか
0776デフォルトの名無しさん2013/12/15(日) 07:57:51.96
シェルスクリプトで楽々自動コード修正です。
0777デフォルトの名無しさん2013/12/15(日) 12:44:13.91
エディタ機能があるのと充実しているのでは全く違う
バージョン管理はバージョン管理だけしていれば良いし
エディットは他のシステムの仕事だ
こんな基本もわからない素人がgitだなんだなんて駄作に走る
プロはみんなsvnみたいなシンプルで応用や連携が効くものを選ぶ
0778デフォルトの名無しさん2013/12/15(日) 13:02:37.83
>>775 がgithubのことを言ってるのか、giのコマンドが登録されたエディタを呼ぶ機能のことを言ってるのかわからんが
>>777 はただの無知
0779デフォルトの名無しさん2013/12/15(日) 14:28:57.55
よく考えたら扱うシステムのが複雑なのだが、バージョン管理が複雑に見えて戸惑う
0780デフォルトの名無しさん2013/12/15(日) 16:59:30.29
>>778
ハゲろ
0781デフォルトの名無しさん2013/12/15(日) 20:51:22.69
>>780
ハゲにハゲろっつってもダメージ無いよ
0782デフォルトの名無しさん2013/12/15(日) 21:03:33.91
何て言えばハゲは傷つくの？
0783デフォルトの名無しさん2013/12/15(日) 21:31:12.13
生えろ
0784デフォルトの名無しさん2013/12/16(月) 15:04:02.25
>>775
別にソースコード修正機能＝エディタとは限らんだろ
patchコマンドだってソースコードを修正するツールだし
0785デフォルトの名無しさん2013/12/16(月) 15:12:03.97
gitだとコミットを複数に分割してその中のいくつかを取り除いたりとかできるからな
これはソース修正してるのとかわらんかもしれん
0786デフォルトの名無しさん2013/12/16(月) 22:01:58.23
それはtortoisesvnにもついてるらしいけどな
http://toro.2ch.net/test/read.cgi/tech/1381929347/413
0787デフォルトの名無しさん2013/12/16(月) 22:06:27.16
SVNのコミットに相当するのはGitだとプッシュだって言ったじゃないですかー

SVNのコミット　≠　Ｇｉｔのコミット
SVNのコミット　≒　Gitのプッシュ
0788デフォルトの名無しさん2013/12/17(火) 00:03:58.47
>>787
この文脈ではSubversionでもGitでもコミットと呼ばれる操作についての話だと思うぞ。
SubversionのコミットはGitでいうところのコミット+プッシュだろう。おおまかに言えば。
0789デフォルトの名無しさん2013/12/17(火) 00:29:41.12
>>786
それは今編集中のファイルの一部をコミットする方法かな？
>>785で言ってるのは、過去にコミット済みの修正の特定部分の削除を
gitコマンド操作だけでできるってことね
0790デフォルトの名無しさん2013/12/17(火) 23:25:45.09
SVN次期バージョンでcheckpointやshelfといったローカルコミット機能が実装されるようだから、
そうなるとまた話は変わってくるな。
0791デフォルトの名無しさん2013/12/20(金) 16:43:01.31
git cloneてresume できないんですね。
ダウンロード速度が遅かったのでctrl-cで止めて寝て、今日やり直したら
また最初から全部ダウンロードやり直しとか。
0792デフォルトの名無しさん2013/12/20(金) 16:48:56.04
マジかよ
それは酷いな
0793デフォルトの名無しさん2013/12/21(土) 03:49:57.95
gitはデフォだと遅いけど、まあぐぐって幸せになりやがれ
0794デフォルトの名無しさん2014/02/04(火) 20:31:50.62
Windows用に特化された分散管理システムきぼんぬ
GitやHGはLinux向きだし
0795デフォルトの名無しさん2014/02/04(火) 20:43:59.05
MSが自分で作れなくて、白旗を上げてGitサポート初めた時点で終わった
0796デフォルトの名無しさん2014/02/04(火) 21:15:05.55
gitは改行コードが
0797デフォルトの名無しさん2014/02/04(火) 21:30:45.30
>>794
Veracity
http://www.sourcegear.com
0798デフォルトの名無しさん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

いっぱいあるよ
0799デフォルトの名無しさん2014/02/05(水) 08:09:43.61
>>795
> MSが自分で作れなくて、

TFS も知らんのか？
まあ、売れてないみたいだけど。
0800デフォルトの名無しさん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がほかの分散型バージョン管理システムと比べて勢いがあり、
> また新たな分散型バージョン管理システムを作ることは難しいと思われたことが挙げられている。
0801デフォルトの名無しさん2014/02/05(水) 14:11:13.49
特許を取得できそうなアイデアがすでにオープンソースで使われてしまってたってとこかな
0802デフォルトの名無しさん2014/02/05(水) 16:02:58.49
新しいDVCSを別にイチから作るより既に普及しているGitを使った方が時間と手間の
有効活用になるってことだろうね。
http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx
0803デフォルトの名無しさん2014/02/05(水) 16:08:53.93
他所のオープンソースソフトウェアなんか導入しちゃってどこから利益を得ようって考えなんだろね
0804デフォルトの名無しさん2014/02/05(水) 17:02:06.55
VSからじゃない?
0805デフォルトの名無しさん2014/02/14(金) 00:00:32.95
趣味でプログラミングを始めようと思ってます
VCSにはSVNやらGITやら色々あるようですが
VCSを覚えるならどれがどのVCSがオススメですか？
0806デフォルトの名無しさん2014/02/14(金) 00:02:48.11
svnでおk
0807デフォルトの名無しさん2014/02/14(金) 00:03:11.25
趣味ならGitでいいんじゃない？VisualStudioでもサポートしたらしいし
0808デフォルトの名無しさん2014/02/14(金) 00:11:20.72
Mercurial一択
0809デフォルトの名無しさん2014/02/14(金) 02:00:04.37
Bazaar
0810デフォルトの名無しさん2014/02/14(金) 02:36:36.24
個人ならCVSで十分やろ～
0811デフォルトの名無しさん2014/02/14(金) 11:02:44.88
CVSは最新版が使い物にならなかったりするからな@ms
0812デフォルトの名無しさん2014/02/14(金) 11:37:35.02
新規で CVS はない
git か svn でいいだろ
0813デフォルトの名無しさん2014/02/14(金) 15:56:47.74
Mercurial...
0814デフォルトの名無しさん2014/02/14(金) 16:18:13.36
mercurialかgitで良いと思う。
一人だとsvnは手間。
0815デフォルトの名無しさん2014/02/14(金) 16:28:03.66
svnは今更だと思う。新規に学ぶのであればDVCSからでは。
0816デフォルトの名無しさん2014/02/14(金) 16:32:18.25
両方こなせる Bazaar 択一！
0817デフォルトの名無しさん2014/02/14(金) 17:03:57.54
cvsだけは絶対無い100%無い
0818デフォルトの名無しさん2014/02/14(金) 17:16:37.05
Bazaar は死んだでござる
0819デフォルトの名無しさん2014/02/14(金) 21:51:59.06
ソースコードなどのテキストデータではなく
画像などのバイナリデータについてバージョン管理したいと考えています。

差分とかは気にせず、単純に失敗したら前のバージョンに戻ったりしたいだけです。
以前、ソフト開発していたころに使っていたGitを使っていますが、
ソースコード以外の用途にも耐えうるか心配です。

Gitでも大丈夫でしょうか。他にオススメがありましたら、ご教授願います。
0820デフォルトの名無しさん2014/02/14(金) 22:22:31.63
git使えるならとりあえずgitで
パフォーマンスに不満が出てからもう一度検討すれば？

明らかに駄目そうなら予め使い方書いてもらわないと
0821デフォルトの名無しさん2014/02/14(金) 22:28:09.24
別にgitでも困らないとは思うけど、バイナリを差分で格納して欲しいならsvnかなあ
gitでも手動でアレコレ指定してrepackすればいけるけど
0822デフォルトの名無しさん2014/02/14(金) 22:35:20.44
横レスだが
バイナリの差分保存って保存方法として有用なのか？
ビットマップのような非圧縮の生データで多少の変更ならともかく
圧縮がかかってるデータだとほぼ別ファイルくらいになるんじゃないのか？
0823デフォルトの名無しさん2014/02/14(金) 22:50:29.23
>>822
まあその辺はアルゴリズム次第としか。
0824デフォルトの名無しさん2014/02/14(金) 22:50:31.18
非圧縮のビットマップだって
人間の眼ではほとんど区別できない程度にトーンカーブいじっただけで
全く別のバイト列になる

有用な使い方もあるし逆効果な使い方もある
だからVCSがどちらを優先するかは技術的優劣というよりはポリシーによる
0825デフォルトの名無しさん2014/02/14(金) 23:30:57.99
>>820-821
回答ありがとうございます。
とりあえずGitでやってみます。
0826デフォルトの名無しさん2014/02/14(金) 23:34:03.79
ブランチ使わず画像やバイナリデータを管理するなら
ディレクトリ別に分けて圧縮しとくだけでいいと思う
0827デフォルトの名無しさん2014/02/14(金) 23:51:25.68
差分圧縮と言えばMercurialだろ
0828デフォルトの名無しさん2014/02/15(土) 10:58:39.30
>>819
一人で使うとか個々のファイルがそれ程大きくないならgitでいいと思う
まぁその「大きい」ってのも曖昧なんだけど

gitはリポジトリ全体を使う人全員にコピーするようなものなのね
だから、巨大ファイルを大人数で共有するならsvnの方が有利と言われていたような
0829デフォルトの名無しさん2014/02/15(土) 11:15:40.05
数百MBとかのあまりに巨大なファイルはそもそもバージョン管理すべきじゃない気がする
Mercurialにはlargefileという巨大ファイル管理用の拡張があるが、これを使うのは最終手段的な扱い
0830デフォルトの名無しさん2014/02/15(土) 12:07:37.89
一人で使うならgitやhgはメリットない
面倒臭いsubversionに過ぎなくなる
0831デフォルトの名無しさん2014/02/15(土) 12:22:46.92
gitやhgはファイルを管理するというよりパッチを管理するという方が正確
同時に他人が同じファイル編集しててもパッチを当てられる(たまにパッチ失敗するが)
なので、gitを使うにはpatchコマンドとdiffコマンドの概念を理解出来てる事が前提
画像ファイルのようなバイナリはdiffが取れないのが根本的な問題だけど、他にもgitの実装上の理由で不都合な事がいくつかある
0832デフォルトの名無しさん2014/02/15(土) 12:29:00.77
>>830
一人で使うならsvnの方がめんどいわ
むしろgit/hgの方がお手軽
0833デフォルトの名無しさん2014/02/15(土) 12:37:01.88
2MB程のテキストファイルでもgitでやると恐ろしいペースでリポジトリが肥大化してくもんだ
で、時々repackしてみるとこれまた笑えるぐらい一気に縮む
0834デフォルトの名無しさん2014/02/15(土) 14:25:56.65
デザイナーが使ってsvnよりgitやhgにメリットあるって勧めてるのはプログラマーのステマ
0835デフォルトの名無しさん2014/02/15(土) 15:32:47.57
gitやhgはSourceTreeが使えるからね。あれは良いものだ。
デザイナーも多く使うOSXで使えるSVNのGUIクライアントとしては現在一番まとも。
0836デフォルトの名無しさん2014/02/15(土) 15:33:43.85
> SVNのGUIクライアント

間違えた。VCSのGUIクライアントだ。
0837デフォルトの名無しさん2014/02/15(土) 15:47:57.03
gitやhgはコマンドラインで使うもの
コマンドラインに降りてこなければgitならではの利点は活かせない
0838デフォルトの名無しさん2014/02/15(土) 15:51:40.21
gitk便利だよん
0839デフォルトの名無しさん2014/02/15(土) 16:26:57.30
ロブ・パイクのUNIX環境本でvcsの基本って学べるの？
0840デフォルトの名無しさん2014/02/15(土) 17:53:19.32
Gitの設計的にバイナリデータを含めるのはよろしくないってのはわかってるけど、
GUI的な要素を含むソフトウェア開発では画像とかのリソースも一緒に管理したいから、なんとも難しいところだね。というかどうすればいいんだろう。
0841デフォルトの名無しさん2014/02/15(土) 18:20:52.46
>>814
> 一人だとsvnは手間。

どこが手間なの？
個人ならリポジトリをローカルファイルにも作れるし。
0842デフォルトの名無しさん2014/02/15(土) 18:39:40.48
一人でもブランチの多用やマージやチェリーピックは便利なんで
両方使える環境ならあえてsvn選びはしないな

gitの場合むしろ超巨大プロジェクトの分割管理が鬼門で
Linux方式にしろAndroid方式にしろ面倒そう
0843デフォルトの名無しさん2014/02/15(土) 18:42:14.61
>>842
hgは、Facebookが1つの超巨大リポジトリに全部突っ込む為に、色々改良してるらしいな。
0844デフォルトの名無しさん2014/02/15(土) 18:46:53.13
bazaarは置いてけぼりなの？
GNUプロジェクトこういうの多くてかなしい
0845デフォルトの名無しさん2014/02/15(土) 18:51:02.01
>>844
残念だけど諦めたほうがいいよ。
svnからの移行もしやすく好きだったんだけど…
0846デフォルトの名無しさん2014/02/15(土) 19:09:50.50
最もセキュリティが高い（盗聴してるIP履歴を発見できる）バージョン管理システムを教えてください。
0847デフォルトの名無しさん2014/02/15(土) 19:13:37.97
盗聴されてる時点でセキュリティも糞も無いと思うが
0848デフォルトの名無しさん2014/02/15(土) 19:17:35.64
ニダーさんが覗いています
0849デフォルトの名無しさん2014/02/15(土) 19:22:57.03
>>844
GNU Emacsがbazaarやめてgitにしようとか言ってる時点で
bazaarは終わりでござる
RMSもべつにかまわんとか言ってるし
0850デフォルトの名無しさん2014/02/15(土) 19:47:48.44
Linux版のSubversionを使い始めて
早速最新版をビルドしようとしたが
依存ソフトがいろいろあって難儀している
OSのパッケージシステムに登録されてる版は
古すぎてお話にならず
みんなはこれくらいへっちゃらなのか？
0851デフォルトの名無しさん2014/02/15(土) 20:04:28.20
bazaarは名前がダメだわ。一昔前に流行ったバズワードじゃねぇか。
0852デフォルトの名無しさん2014/02/15(土) 20:10:29.19
>>850
パッケージシステムのはいくつなん？
0853デフォルトの名無しさん2014/02/15(土) 20:44:34.91
gitやhgがsvnに比べて有利なのは複数のプログラマーが同時に開発するプロジェクトでソースコードの管理する場合だね
0854デフォルトの名無しさん2014/02/15(土) 20:53:54.49
ひとりでローカルにブランチいっぱいつくって
とっかえひっかりしたり、マージしたり、いろいろ加工できるのが
gitの利点なのに
0855デフォルトの名無しさん2014/02/15(土) 20:57:24.87
>>852
Ubuntu12.04LTSで1.6.17
Windows用クライアントは既に1.8.4という大差
0856デフォルトの名無しさん2014/02/15(土) 21:16:21.21
精神分裂病のプログラマーでもないかぎり、とっかえひっかえブランチ切り替えてコード書いたりしないと思う
0857デフォルトの名無しさん2014/02/15(土) 21:50:04.82
新しい機能を実装するために新しい機能ブランチ切るだろ。
その機能ブランチに細かくコミット重ねながら機能を実装していく。
途中で実装方法迷ったときとかそこから更に新しいブランチ切る。
いくつかコミット重ねて修正してみて、その実装方法に確信が持てたら元の機能ブランチにマージ。
納得できなかったらとりあえずそのブランチは行き止まりにして元の機能ブランチに戻る。
それを繰り返してると行き止まりにしたブランチに捨ててきたコミットが使えることに気づいて、
そのコミットをチェリーピックで復活とかもしたくなる。
そんなのを多段に繰り返して機能実装完了したら機能ブランチを整理してオリジナルにマージ。
機能ブランチの整理のときも、安全のために機能ブランチとは別のブランチ作ってリベース。
0858デフォルトの名無しさん2014/02/15(土) 22:06:52.93
目標に向かって一直線にプログラム書いていけるようなプロジェクトやってる人も
手法20個試して1個の当たり見つけるようなのやってる人も居るだろ

後者のようなのをsvnでやってるときはifdefやコメントアウトのほうが便利だし
そんなにブランチいらんだろと思ってたが、
gitに慣れてくるとブランチとマージのコストが低いからちょいちょいブランチ切るようになった
0859デフォルトの名無しさん2014/02/15(土) 22:48:41.33
> gitに慣れてくるとブランチとマージのコストが低いから

これに尽きるなぁ。結果として作業中のコミットの頻度も上がるんだよね。良い意味で。
コミットするたびにコンフリクトやマージを気にする必要があり、かといって細かい単位で
トピックブランチを切る文化もないsvnだとどうしてもコミットの間隔が長くなる。
0860デフォルトの名無しさん2014/02/15(土) 22:55:42.18
それぞれ若干用語の意味がズレるからアレだけれども
枝を分けたり、それらをマージすることに対する敷居が
Subversionに比べてGitもMercurialもすんごい低いんよね
0861デフォルトの名無しさん2014/02/16(日) 01:37:45.01
Gitだとブランチ作って作業、Mercurialだと名前もつけずにupdateで古い
チェンジセットに戻してそこに積み上げることもできるし、
頻繁に行き来したり最後にまとめたりする時はmqが便利だよね

SVNは昔使ってたけど、ローカルで使っててもGitやMercurialに比べて動作が遅すぎたよ
0862デフォルトの名無しさん2014/02/16(日) 01:46:26.92
手法20個も試したことないわ
0863デフォルトの名無しさん2014/02/16(日) 03:55:11.27
mqって
08648142014/02/16(日) 11:38:40.28
>>841
リポジトリを作るのが手間
git/hgなら今ローカルにあるフォルダをそのままリポジトリにできるじゃん？
svnはリポジトリ自体の配置設計をしなければならないのがめんどい
0865デフォルトの名無しさん2014/02/16(日) 15:35:35.12
そんな必要ないけどパラレルワールドに生きてるのかな(笑)
0866デフォルトの名無しさん2014/02/16(日) 15:56:10.10
だな
0867デフォルトの名無しさん2014/02/16(日) 16:01:09.30
なんだ？SVNはリポジトリ作らんでもいいようになったのか？
0868デフォルトの名無しさん2014/02/16(日) 16:18:55.42
作業コピーとリポジトリが別の場所なのが嫌だってことなんじゃ
0869デフォルトの名無しさん2014/02/16(日) 16:32:18.81
git/hg/bzrをメインで使っている人にとっては
svnは枯れていることに意義があるので
svnの進歩には興味ないどころか
余計なことしやがってと思っていても不思議ではない
0870デフォルトの名無しさん2014/02/16(日) 17:00:59.91
>>865
kwsk
0871デフォルトの名無しさん2014/02/16(日) 17:40:14.45
自分が管理しているわけでもないSVNリポジトリ触るのって苦痛じゃない？
0872デフォルトの名無しさん2014/02/16(日) 18:24:58.38
ソースコード管理するのにローカルにリポジトリ作れるのは大してメリットないと思うな
UNIXのドットファイルみたいな設定ファイルを管理する場合はローカルに作れるといいかも
0873デフォルトの名無しさん2014/02/16(日) 18:38:07.68
ローカルにリポジトリ作れてありがたがっている人を前にして
その発言に何の意味があるんだ？
0874デフォルトの名無しさん2014/02/16(日) 18:40:44.14
新しいプログラムを作り始めるときに、ローカルリポジトリから始められるのはすごくいい。
0875デフォルトの名無しさん2014/02/16(日) 18:48:56.80
~/repos/projectA/

これだけの話だろ
なんで同じ場所だといいんだ？
ドットファイルもシンボリックリンクでいいじゃん
0876デフォルトの名無しさん2014/02/16(日) 18:53:55.63
VCSはバージョン管理の道具であると同時に共同作業のためにも使われるあたりも議論が
ごっちゃになりがちな原因だと思う。
「一人で開発しているのでVCS不要」とか。
0877デフォルトの名無しさん2014/02/16(日) 19:00:46.06
>>875
そのprojectAって名前を他のリポジトリかぶらないように考えるのすら面倒
0878デフォルトの名無しさん2014/02/16(日) 19:03:13.87
>>864
同意するけど、毎日リポジトリを作る訳じゃないし、そんなに大きな違いか？
0879デフォルトの名無しさん2014/02/16(日) 19:08:00.84
>>878
頻繁にやるわけじゃないからこそさ、
いざリポジトリ作ろうと思ったとき git init だけで作れるのがいいんだよ
0880デフォルトの名無しさん2014/02/16(日) 19:13:49.67
Subversionで管理してた計1GBぐらいの画像ファイルの管理をMercurialに移行したら
レスポンスが速くなったよ
たいした機能は使ってないけどね
0881デフォルトの名無しさん2014/02/16(日) 19:47:06.74
gitとhgってどっちがいいんだろう
0882デフォルトの名無しさん2014/02/16(日) 19:51:20.54
Mercurial良いよと言いたいところをグッとこらえて素知らぬ顔でいやぁ～gitが
グローバルスタンダードですよねとか言ってみる。

水銀たん・・・
0883デフォルトの名無しさん2014/02/16(日) 20:16:04.00
>>877
だな
0884デフォルトの名無しさん2014/02/16(日) 20:20:17.44
>>880
そ、それは、、、
分散型と最も相性の悪い事の一つでは…
0885デフォルトの名無しさん2014/02/16(日) 20:24:11.69
>>884
880だけど、俺以外が更新する事なんか、滅多にないから大丈夫だよ
実際、かち合った時にどうなるのかは体験してないから、よくわからん

>>882
コードの管理で言うと、一般企業にはMercurialが、オープンソースプロジェクトにはgitが向いている
たぶんね
0886デフォルトの名無しさん2014/02/16(日) 20:29:46.21
>>878
俺は手軽だからこそリポジトリ化する頻度が上がったな
会社の方針で共有ソースコードはSVNだけど、個人pc内にあるほとんどの自作物(検討ソースコードやofficeドキュメント類も)をhgで版管理してるよ
0887デフォルトの名無しさん2014/02/16(日) 20:33:15.81
>>884
どうして分散型と相性が悪いの？
0888デフォルトの名無しさん2014/02/16(日) 20:46:25.80
>>884
分散型はリポジトリ全体をコピーするからかな
巨大ファイルを入れてしまうと、そこからのクローン全部に入ってしまう
また画像のようなバイナリファイルは差分を取りにくいので版を重ねるたびに巨大になっちゃうとか

だから>>885さんのように一人で使う分には問題ないよ
その場合「分散型」自体の意味が無いけど、それでも一人でgit/hgを使うメリットはあると思う
08898882014/02/16(日) 20:46:59.62
すまん
>>888は>>887宛ね
0890デフォルトの名無しさん2014/02/16(日) 21:20:47.03
>>888
880だけど、Mercurialにはlargefiles拡張っていう、でかいファイルは最新版しかコピーしない機能があるよ

で、クライアントにTortoiseHG使ってると、ファイル追加する時に
「当然使いますよね」的なダイアログを出してくるので、その機能使ってる
0891デフォルトの名無しさん2014/02/16(日) 23:26:40.46
>>890
それは知っているけど、それはmercurialが分散型の弱点の一つをカバーする為に集中型の特徴を部分的に取り入れただけだよ
原理的に分散型の苦手部分だという事に変わりはないよ
まあ、分散型・集中型できっちり区分けする必要も無くて、ツールとしては良いとこ取りして進化していってくれたらそれで良しだけどね
0892デフォルトの名無しさん2014/02/16(日) 23:28:16.22
gitのHEADが参照してるBLOBだけDLしてくれればな
0893デフォルトの名無しさん2014/02/17(月) 00:01:54.46
SVNも最近のバージョンはマージのコスト下げるために色々やってるね。
あとは前々から予告されているローカルコミットさえ実装されてくれれば・・・。
0894デフォルトの名無しさん2014/02/17(月) 00:13:28.67
SVNや分散型のそれぞれのいいとこ取りしたVCSが出てくればいいのにね
0895デフォルトの名無しさん2014/02/17(月) 02:58:44.41
gitのコマンド体型って誰が考えたんだろう
^^とかさ
0896デフォルトの名無しさん2014/02/17(月) 03:04:49.52
ああいうのは頭のいいバカが考えたものだと相場が決まっておる
0897デフォルトの名無しさん2014/02/17(月) 05:42:00.62
>>893
> あとは前々から予告されているローカルコミットさえ実装されてくれれば・・・。

ほんとそれ
0898デフォルトの名無しさん2014/02/17(月) 06:04:56.80
svnのアップデートを待つよりもうそれMercurialで良いのではないかと思うw
0899デフォルトの名無しさん2014/02/17(月) 08:54:18.94
Mercurialは土方でも使えるよ
0900デフォルトの名無しさん2014/02/17(月) 12:34:20.79
土方歳三
0901デフォルトの名無しさん2014/02/17(月) 13:05:41.22
Mercurial推しの奴が（見た目）大いんだが、そんな流行ってるのか？
0902デフォルトの名無しさん2014/02/17(月) 13:14:12.72
分散型は、gitとhgの2強時代だと言っていいんじゃないの？
公式採用とかは、gitやや優勢かなと思うけど、誤操作での被害を考えると個人的にはhgを推したい気はする。
俺は、unicodeファイル名への対応をどうするかで決めたいと思ってまだ様子見。
0903デフォルトの名無しさん2014/02/17(月) 13:51:25.96
git>>>>>>>>>>>>>>>>>hgでしょ
0904デフォルトの名無しさん2014/02/17(月) 13:52:25.53
SourceForge.JPの作業部屋って言う個人リポジトリだとhg使えるらしいしそこで試してみるは
0905デフォルトの名無しさん2014/02/17(月) 14:06:15.80
gitもhgも試すだけなら自分のPCだけでできるだろ
0906デフォルトの名無しさん2014/02/17(月) 15:00:13.28
mercurialってgithubみたいなのあるの？
0907デフォルトの名無しさん2014/02/17(月) 15:00:33.60
ああいうリポジトリサービスは
どうでもいい個人が登録して使ったらアカンやろ
0908デフォルトの名無しさん2014/02/17(月) 15:01:52.89
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
0909デフォルトの名無しさん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
0910デフォルトの名無しさん2014/02/17(月) 16:15:17.98
全体的にはhgが好きなんだけど、日本語ファイル名の扱いがいつまで経ってもウンコなのと
名前付きブランチをマージした後の扱いが気に入らない。
0911デフォルトの名無しさん2014/02/17(月) 16:29:14.08
gitの方がより複雑で、svnからの移行はhgの方が多少しやすいと思う
あと、gitはwindowsクライアントがろくなのない
0912デフォルトの名無しさん2014/02/17(月) 16:38:10.99
gitが複雑・・・？
0913デフォルトの名無しさん2014/02/17(月) 17:11:59.92
>>906
つbitbucket
0914デフォルトの名無しさん2014/02/17(月) 17:13:56.92
俺もhg押し派なんだけど、ネット上に存在する日本語の資料の量は圧倒的にgitの方が多いよね
0915デフォルトの名無しさん2014/02/17(月) 17:16:24.47
>>907
kwsk
0916デフォルトの名無しさん2014/02/17(月) 19:13:07.50
誰かがhgを分かりやすく解説してくれないとな
文才のある奴じゃないと
0917デフォルトの名無しさん2014/02/17(月) 20:45:52.81
ここではhg押しが多いのにスレが全然進んでない不思議
http://toro.2ch.net/test/read.cgi/tech/1321109748/
0918デフォルトの名無しさん2014/02/17(月) 20:50:31.81
ROMりにいってやるよ
0919デフォルトの名無しさん2014/02/17(月) 21:14:53.07
gitはgithubで名前が知れたからな
けど、俺はhgの方がsvnの次のステップとして適してると思う
ま、svnで十分だったらsvnのままでもいいが
0920デフォルトの名無しさん2014/02/17(月) 21:20:10.52
GitとHg共通の機能や操作に使用感の違いはあります？
0921デフォルトの名無しさん2014/02/17(月) 22:40:57.29
>>920
hgにはステージが無い

よね？
0922デフォルトの名無しさん2014/02/17(月) 23:03:14.20
ブランチの扱いが随分違うな
gitじゃメモ代わりにブランチ作ったり消したりできるぐらいお手軽なものだけど
hgでは名前つきブランチっていうのはある程度計画的に作るべきものなのか
0923デフォルトの名無しさん2014/02/17(月) 23:04:59.43
hgのほうがいろいろ縛りが厳しい
0924デフォルトの名無しさん2014/02/17(月) 23:57:36.51
hgだと作業途中での変更が大変そうだし他のとこ見ても
Gitのほうがスッキリ作業できそうなのでGit使い続けることにします
レスありした
0925デフォルトの名無しさん2014/02/17(月) 23:58:18.81
コミットメッセージ書くの面倒臭すぎて「ちょっと修正」とか「いろいろ変更」にしてしまう
一人で趣味でやってるだけだから周りに迷惑かけてないからこれでいいけど
みんなはこんな面倒なことしてるのかな
0926デフォルトの名無しさん2014/02/18(火) 00:07:15.10
gitならブランチ分けて、途中までは「作業中」でコミット、
最後にmerge --squashするときに、ちゃんと書く…とか
hgならmq使うとか、色々やり方はあるかと
0927デフォルトの名無しさん2014/02/18(火) 00:26:39.07
>>922
そもそも、Subversionのブランチ並のことやらん限りブランチ要らんかと
0928デフォルトの名無しさん2014/02/18(火) 00:29:52.35
>>925
もっと細かい修正でコミットすればよくね？
あとで見返したときに「ちょっと修正」や「いろいろ変更」で中身が思い出せるエスパーなら止めはしないけども。
0929デフォルトの名無しさん2014/02/18(火) 00:32:33.78
複雑な樹形ブランチを管理保存出来るなんてvcs凄いわ。
0930デフォルトの名無しさん2014/02/18(火) 00:59:34.79
>>928
そもそもコミットが面倒臭い
理想は機能一つ、修正一つ毎にコミットなんだろうけどうまく出来ないんだよな
0931デフォルトの名無しさん2014/02/18(火) 01:07:07.35
作業する前に何の作業をするのか言葉にしてから作業を開始しろ
0932デフォルトの名無しさん2014/02/18(火) 01:08:06.33
俺の集中力も分散型
0933デフォルトの名無しさん2014/02/18(火) 01:26:47.81
そもそも機能と修正ごとにブランチ切るべき
0934デフォルトの名無しさん2014/02/18(火) 01:52:46.77
>>930
hgならmqで簡単な名前だけ入れて残して、細かい修正は行ったり来たりしながら作って、
後で整理してきれいなコミットにするんだよ
0935デフォルトの名無しさん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文に直して処理の流れを分かりやすく整形した
0936デフォルトの名無しさん2014/02/18(火) 01:59:29.83
hgはiOS、gitはandroidって感じ
0937デフォルトの名無しさん2014/02/18(火) 02:03:36.37
ググって見たが、hgのmqややっこしいな
gitで普通にコミットしてrebase -iで順番入れ替えるほうが簡単でいいわ
0938デフォルトの名無しさん2014/02/18(火) 02:05:40.52
ブランチ作らずに一本道で見るのは一番最後にコミットしたものだけって使いかたしてるけど
これならsubversionの方がいいんだろうな
0939デフォルトの名無しさん2014/02/18(火) 02:07:59.94
>>938
本当に「見るのは一番最後にコミットしたものだけ」ならバージョン管理いらん
0940デフォルトの名無しさん2014/02/18(火) 02:23:26.20
作業時間を測りたいから
作用開始コミットと終了コミットを打つ
0941デフォルトの名無しさん2014/02/18(火) 02:35:08.34
機能ごとにコミットしてきちんとコミットメッセージ書くのがいいけど、面倒だからな
TortoiseSVNはコミットメッセージか空でもエラーにならないよね
その運用で困らないならそれでいいと思う
0942デフォルトの名無しさん2014/02/18(火) 02:51:52.80
>>904
そんなくだらん目的のためにリソース食うバカは死ぬべき
0943デフォルトの名無しさん2014/02/18(火) 04:11:57.57
>>930
だからgit merge --squashやMercurial Queueじゃあかんの？
0944デフォルトの名無しさん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にしておく。
0945デフォルトの名無しさん2014/02/18(火) 04:17:49.62
安価ミス？
0946デフォルトの名無しさん2014/02/18(火) 04:32:58.80
三日も経てばコマンドを忘れてしまってまた学習し直し
よってフォルダコピーで済ませるようになった
バージョン管理ソフトはメリットに比して学習・運用コストが高すぎる
0947デフォルトの名無しさん2014/02/18(火) 05:05:52.72
使用頻度の低いコマンドも覚えようとしてんじゃねえの
0948デフォルトの名無しさん2014/02/18(火) 05:11:36.67
いやメインのコマンドだよ
三日くらい集中して開発してふう一息って感じで
コミットするスタイルだから
その間に忘れてしまうんだ
0949デフォルトの名無しさん2014/02/18(火) 05:12:58.44
３日に１回は低頻度だろ
0950デフォルトの名無しさん2014/02/18(火) 05:14:59.05
コマンドじゃなくバージョン管理の一連の流れを覚えるのが大事であってだな
0951デフォルトの名無しさん2014/02/18(火) 08:32:41.87
>>946
そんな記憶力でソースなんて書けるんか？
printf ってなんだっけ、とか言ってそう (w
0952デフォルトの名無しさん2014/02/18(火) 09:00:48.28
普段会社ではMercurialなので時々思い出したようにgitやsvnを使う必要があるときは
細かいコマンドをウェブで検索してしまうな。
0953デフォルトの名無しさん2014/02/18(火) 09:53:58.65
そういう人のためのGUIフロントエンドですよ
別にコマンド丸暗記しなくたって、恩恵は受けられる
0954デフォルトの名無しさん2014/02/18(火) 10:37:43.29
IDE組み込みじゃないとなかなか使ってくれない・・・
0955デフォルトの名無しさん2014/02/18(火) 11:37:58.48
そゆのはバッチ書いてやれば楽になるぞ>>946
0956デフォルトの名無しさん2014/02/18(火) 12:32:31.92
>>955
同意するわ。
コマンド覚えられないならg.shのようなスクリプト書いて流れ作業全部をスクリプトに暗記させればいいだろ。
実際おれはコマンド辞典の丸暗記なんかしてないよ。暗記作業はpcに任せて自分は最大限に手を抜くのが正義だと思ってるわ。
沢山のコマンド名を暗記して人間百科事典みたいな事してるやつは、頭はいいとは思うけど、バカだな。と思うわ。
0957デフォルトの名無しさん2014/02/18(火) 12:36:09.70
そしてスクリプトの名前を丸暗記してるのですね
0958デフォルトの名無しさん2014/02/18(火) 12:48:04.67
>>944
hqの無名ブランチがgitのブランチと構造的に同じだとしても
好きな名前付けられないんならメモ代わりにはならないんじゃないの？

mq使う必要無いって、このスレでmq、mq言ってるやつは何なんだよ
0959デフォルトの名無しさん2014/02/18(火) 15:32:27.24
mq は、TortoiseHg Workbench が対応してやっと理解できた。
今はめっちゃ使ってる。
なくても困りはしないけど。
0960デフォルトの名無しさん2014/02/18(火) 15:50:58.13
GUIは色々なリビジョンの変更履歴を確認したりrebaseしたりと、コマンドラインだと
リビジョン番号を手打ちする必要のある作業のときに特に重宝するな。
SourceTree楽だ。
0961デフォルトの名無しさん2014/02/18(火) 17:29:53.07
>>957
シェルの補間機能がうまく働くような名前にしとくといいよ
0962デフォルトの名無しさん2014/02/18(火) 17:36:37.93
昔のおっさんには、人間アセンブラな人、マシンのブートコード丸暗記してる人がいたらしい。
0963デフォルトの名無しさん2014/02/18(火) 17:39:12.64
現代のゆとりにはミリ
0964デフォルトの名無しさん2014/02/18(火) 17:42:55.79
もうゆとり教育終わってるんだけどな
0965デフォルトの名無しさん2014/02/18(火) 17:46:18.09
ゆとり教育終わってから小学校に入った人はまだ高校生
途中で終わった人はどういう扱いなんだろ
0966デフォルトの名無しさん2014/02/18(火) 17:47:14.14
>>958
いや、そのレス先に書いてあるように、bookmark機能を使えば、gitと同じ状態になる。
0967デフォルトの名無しさん2014/02/18(火) 17:57:20.59
gitのブランチと同じってことはそのままリモートにpushできるのか
0968デフォルトの名無しさん2014/02/18(火) 19:17:09.24
>>962
昔のおっさんといっても、その辺のレベルの人現役で結構いるけどな。
ハードに近いところの仕事してると普通に会う。
で未だに現役な人達は50こえてるだろうに知識に貪欲で色々勉強しててびっくりする。
自分があの歳になってもああなれるか自信ないわ・・・
0969デフォルトの名無しさん2014/02/19(水) 01:28:24.23
>>957
スクリプトのショートカットを好きなところに置いておけばクリックするだけなんだよ
ターミナル開く必要もない
スクリプトにヘルプ表示も付ければそのスクリプトのオプション覚える必要もない

ちなみにこれはどれも実際に俺自身が複数一度に処理できるように作って実践している
0970デフォルトの名無しさん2014/02/19(水) 12:01:04.91
外部記憶の活用
0971デフォルトの名無しさん2014/02/19(水) 23:34:27.90
posh gitやposh hgは良くできてる
0972デフォルトの名無しさん2014/02/22(土) 03:39:52.07
バージョン管理もできないweb屋と仕事すると頭痛い
0973デフォルトの名無しさん2014/02/22(土) 12:14:59.46
結構あるからな。
自分だけでもバージョン管理しとくといいよ。
0974デフォルトの名無しさん2014/02/22(土) 13:52:23.18
バージョン管理ソフトは
学習コストがけっこう高いからねえ
万人が使えるとは言えないのが痛いところ
将来はシステムが自動でバージョン管理してくれる
方向に進むと思う
0975デフォルトの名無しさん2014/02/22(土) 14:27:11.73
>>974
vs2010のC#でプログラミング勉強しとります。
この環境でvcs使いたいんですが何が良いあるか？
0976デフォルトの名無しさん2014/02/22(土) 14:29:10.63
gitで良いあるよ
0977デフォルトの名無しさん2014/02/22(土) 14:45:22.37
VS統合ならAnkhSVNがまあまあ良かった
0978デフォルトの名無しさん2014/02/22(土) 14:53:29.42
2010だとGitサポートは無いのか
0979デフォルトの名無しさん2014/02/22(土) 15:40:13.53
2013からどす
0980デフォルトの名無しさん2014/02/22(土) 15:59:35.64
そういえば、MSがGitを取り込むんだったっけ
よく知らんけど、今のバージョンなら使えるの？
0981デフォルトの名無しさん2014/02/22(土) 16:01:38.53
MSは日本のソフトウエア業界を蹂躙したインベーダー。
0982デフォルトの名無しさん2014/02/22(土) 19:05:48.95
>>974
> 将来はシステムが自動でバージョン管理してくれる
> 方向に進むと思う

それはない。

なぜならバージョン管理ソフトというのは
ソフトウェアのバージョン（機能の違い）を
管理するためのものであって、ファイルのバージョンを
管理するものではないから。

ファイルのバージョンとソフトウェアのバージョンは一致しない
ファイルはコンパイルすら通らないような修正中であっても保存できる。
だがこれはソフトウェアのバージョンになるとは限らない。

ソフトウェアにおいてある機能が出来たとされるバージョン（＝コミット）
これを判断するのは人間しかできない。
0983デフォルトの名無しさん2014/02/22(土) 19:11:52.99
gitにおいてはもはやバージョンを管理するものだけではなく
別のバージョンの機能の一部を取り込んだり、
ソフトウェアにおけるバージョンを綺麗に直すことも出来る。
こういうのは人間が判断することでシステムには無理。
0984デフォルトの名無しさん2014/02/22(土) 19:20:09.37
VCSの用途としては共同作業ツールの側面もあるからね。
0985デフォルトの名無しさん2014/02/22(土) 19:53:29.03
>>975
VC拡張でgitのがあるはず
公式なやつは2010でもあったと思う
0986デフォルトの名無しさん2014/02/22(土) 19:54:56.26
ごめん逆、MS公式なやつはもっと先のバージョンだけど、非公式なやつは2010から
0987デフォルトの名無しさん2014/02/22(土) 21:53:04.00
馬鹿がバージョン管理ソフトを使うと
普通考えられない使い方をすることがある
それなら使わない方が効率いい的な
0988デフォルトの名無しさん2014/02/22(土) 21:54:08.37
そんなゴミはプログラマにしない方が効率が良い
0989デフォルトの名無しさん2014/02/22(土) 22:03:15.00
「なんだかよくわからないけど動かなくなりました」
「なんだかよくわからないけど動くようになりました」
この必殺技に対する抑止力として、馬鹿にこそ使わせるべき
0990デフォルトの名無しさん2014/02/23(日) 07:21:31.59
馬鹿に使わせると動かない状態をコミットして、動く状態をコミットしないんだよな。
0991デフォルトの名無しさん2014/02/23(日) 07:22:23.70
VSのアドオンであるけど、普通にTortoiseHgとか組み合わせて使えばいいんじゃない
0992デフォルトの名無しさん2014/02/23(日) 07:28:01.34
ソリューションディレクトリでgit initしてhttps://github.com/github/gitignore/blob/master/VisualStudio.gitignoreを入れておけばいい
0993デフォルトの名無しさん2014/02/23(日) 12:27:56.48
>>991
やっぱり統合されてるのは便利だよ
Tortoise も便利なんだけどね
0994デフォルトの名無しさん2014/02/23(日) 14:29:08.81
VCSがエディタ画面とうまく統合されてるとおそろしく快適だわ
0995デフォルトの名無しさん2014/02/23(日) 17:20:44.78
バージョン管理システムをバージョン管理に使わない例を聞いて頭をかかえたことが
0996デフォルトの名無しさん2014/02/23(日) 17:35:04.48
svnもhgも、IDEに統合された中途半端なやつ使うより、専用のTortoise*使った方が
使いやすいと思うわ。差分見るのも、ExamDiff Pro使って見たいし。
0997デフォルトの名無しさん2014/02/23(日) 17:42:01.90
差分を確認する時とかブランチをどうこうする時は別の使うけど
VisualStudio上からすぐコミット出来るのは便利だった
コミットしてないファイルがどれかもわかるし
0998デフォルトの名無しさん2014/02/23(日) 17:52:17.19
Tortoiseで操作するような部分はコマンドラインでいいや
それよりも、ソース編集するツールがVCSと統合されてdiffやblameを常時チェックできるような状態になってるのが嬉しい
いまIntelliJ IDEA使ってるんだけど、これで行単位のaddとかも編集画面でそのままできたら言うことはないな(できるのかな？)
0999デフォルトの名無しさん2014/02/23(日) 17:56:46.68
>>997
え、差分確認せずにコミットしてるの？

コミットしてないファイルは、適切な無視ファイルパターン入れてれば、
Tortoise*でも自明でしょ？
1000デフォルトの名無しさん2014/02/23(日) 17:59:08.60
つづく！
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。