開発者以外でも使いやすいバージョン管理システムは？ 96
ストーリー by headless
手間 部門より
手間 部門より
今週、「外資系投資銀行のエクセル仕事術」という記事が/.Jの日記で話題になっていた。記事の第5回では上書き保存をせず、その都度別名保存するというテクニックが紹介されているが、本家/.では別名保存の結果生じるバージョン管理の問題が先週話題になっていた。
本家/.「Ask Slashdot: Version Control For Non-Developers?」より
本家/.「Ask Slashdot: Version Control For Non-Developers?」より
私の配偶者は多数の文書(Word、スプレッドシート、スキャンした文書など)を扱う会社で働いており、バージョン管理の問題で毎週数時間を無駄にしている。文書はいわゆる階層構造を用いて共有サーバーに保存されるが、諸悪の根源はそこにある。たとえば、皆が文書の上書きを恐れ、変更結果を「念のために」少し異なる名前で保存するため同じ文書の複数のバージョンができてしまい、どれが最新バージョンなのか、どれがクライアントに送られたバージョンなのかといったことが誰にもわからない状態だ。
こういった状況はバージョン管理システムを導入すれば大幅に改善されるはずだ。最初はSVNやTortoiseSVNを考えたが、開発者でなくても使いやすい、もっとシンプルなものはないだろうか。スラッシュドットの皆さんの体験談やアイディアがあれば教えてほしい。ドキュメントツリーで簡単にテキスト検索ができるものなら理想的だ。
コメントではMicrosoft SharePointを勧める意見が複数みられるが、その他のドキュメントバージョン管理システムやバージョン管理機能を備えたクラウドストレージサービス、Wikiなどを利用するといったもののほか、命名規則を検討する、仕事のやり方を見直すといったローテクな提案もある。皆さんはどのように文書ファイルのバージョン管理を行っているだろうか。
目的によるよね。 (スコア:2, 参考になる)
日付が超重要な法律関連のファイル管理システムを担当したことがあるけど、
・進行中のファイルについては、基本的にサーバで同期する。
・それだと、出先での同期に時間が掛かるので、チーム内で都度都度P2P同期し合う。
・個別ファイルはWordとかExcelなんだけど、単純なバイナリ比較ではなく、同期するときに個人が中身そのもので判断する。
・終了したファイルについては、絶対に変更することが許されない形（アーカイブ）として保存する。
当然、こんな要求に応えられる製品なんて存在しないので、内製してました。
Re:目的によるよね。 (スコア:2)
Gitでなんとかなりそう。
Re:目的によるよね。 (スコア:1)
うちはローカルにGitHubクローンのGitBucketを置いて、バージョンはそこで管理してる。
gitはクライアントソフトが結構充実してきてるから、細かい事は判らない事務員でも
普通に使えている。
修正確認などの承認ワークフロー管理はredmine側で行ってる。
修正の流れというかタスクが分かりにくかったのであとからredmine立ててリポジトリを連携させる様に
したけど、あまり複雑な事はしないで運用を絞ってしまえば難しいことは特になかった。
Re:無理 (スコア:1)
300MBのバイナリ使うと動かないgitがなんだって?
「法律関連のファイル」で「WordとかExcel」で、300MBのバイナリって、具体的には何?
六法全書か何かをWordの一ファイルでで書いてみたとか?
まあ、そういうのにはgitは使えないね。
でも、WordやExcelは使えるのかな?
それで?
ワークフロー管理？ (スコア:2)
これだけ聞くと、必要なのは「ワークフローシステム」(耳慣れないひとはぐぐって)に見える。
変更結果が良く分からないなら、修正履歴を書けよ。
バージョン管理システムを使うには学習コストがかかるし、
そのバージョンでどんな修正をしたのか、記入するのは人間だからな。
本当は、バージョン管理システムとかいらなくて、文書に作業履歴をつけることを徹底して、
作業中フォルダ、承認済みフォルダ、クライアント提供済みフォルダなど、
ワークフローに応じてファイルを移動させるぐらいで済むのではないかな？
Re:ワークフロー管理？ (スコア:1)
その「ワークフローシステム+変更履歴強制」よりバージョン管理システムの方が総コストが高くなる、という理屈がわからん。
どっちも似たようなもんじゃないかな?
それに、変更履歴って、「書け」ってルールを決めても、書かれないことが少なくないと思う。
変更履歴が書かれることを期待できるような環境なら、フォルダベースのワークフローでも上手くいくかもしれないね。
Re:ワークフロー管理？ (スコア:2)
> たぶんな。
その通りです。というより、穴だらけの主張に予想以上に的確な解釈をして頂いて申し訳ない。
私自身、別に「手段」に拘っていなくて、やりたかったことの本質を問いたかっただけです。
「ルールを決めても守られない」ということの本質は、
(概念的な)バージョン管理の範疇ではなく、(概念的な)ワークフロー管理の範疇
ではないかという事を問いたかったのです。
乱暴に言うと、こんな感じかな？
- バージョン管理 ... 版数と資産の関係を管理するもの。
- ワークフロー管理 ... 作業プロセスというか資産の流れを管理するもの。
確かに、バージョン管理システムの機能の一部でワークフロー管理の真似事が
実現できるかもしれませんが、目的が、「ワークフロー管理」なら、それに最適な
プロダクトやローカルルールを仲間内で話し合ってみれば、
負担のない運用が思いつくのではと、一例としてフォルダの運用を出しました。
＊ ＊ ＊
個人的には、手段が、Gitだろうと、VCSだろうと、SharePointだろうと、
馴染むものを使えばよいと考えています。
Ryo.Fさんは、バージョン管理システムに対して、理解が深いようですので、
「バージョン管理」のストーリーに素直に最適な手段を提示して
頂いているなとは思っていました。ただ、手段の方の議論が好きそうで、
ぶつかり合うだけで楽しい議論にならなさそうだったので、
モデレーションに身を任せようとした次第です。
※元のコメントはマイナスモデされても仕方ないかなと思っていました。
IDの初期プラスモデ恐ろしすぎる。+1とか+2相当の重みのあるコメントを
強要されているような気がする。
Re:ワークフロー管理？ (スコア:1)
その根底にあるのは「コントロールされていない状態」が問題なんだよ。
そうだね。
ただ、コントロールについて、どの程度の厳密さが必要か、ってことだね。
もちろん、厳密さが必要な場合もあるだろうし、そういう場合は、ワークフローが適しているかもしれない。
そうでない場合もあるだろうし、その場合は、VCSが向いているかもしれない。
コミット時に厳密さを求めなくても、後で履歴を追えば良い場合とかだね。
厳密さが必要な場合も、中央レポジトリへのコミットを適切に制限すれば、それでもokかもしれない。
Re: (スコア:0)
> 本当は、バージョン管理システムとかいらなくて、文書に作業履歴をつけることを徹底して、
徹底させられないからどうしようかっていう話をしてるの。
徹底しろって言うだけでみんなが徹底してくれるんならそもそもこんなトピックが立ち上がってない。
Re: (スコア:0)
コミットログに何も書かずにコミットできるので、バージョン管理システムを使っても何も変わらないのでは？
それとも、差分比較したいといっている？
やったことがあれば分かるけど、修正が多い場合の差分比較は修正履歴書くよりずっと手間のかかる作業ですよ。
> バージョン管理システムを使うには学習コストがかかるし、
> そのバージョンでどんな修正をしたのか、記入するのは人間だからな。
MS以外から見たらただのバイナリ (スコア:1)
Office文書を主に扱うならSharePointでいいんじゃない？
SVNやgitはテキストファイルじゃないとあんまし嬉しくないし。
Re:MS以外から見たらただのバイナリ (スコア:2, 参考になる)
xdocdiffというのがありまして....
http://freemind.s57.xrea.com/xdocdiff/ [xrea.com]
最近のWinMergeならOffice文書用の展開プラグインも入ってるので，DiffプログラムをWinMergeに設定してやればほかのVCSでも良いかも
少なくとも，タグを付けたり最新版を管理したりしたいというのであれば，素直にVCS使うべきだと思います
それがたとえバイナリであったとしても
変更履歴の記録 (スコア:1)
WordやExcelだったら標準機能の「変更履歴の記録」を使えばいいんじゃないかなぁ。
タレコミにあるような「ちょっとした変更」くらいならファイルを新しく作るより、こっちの方が改変者が誰かも残るし使えると思う。
Re:変更履歴の記録 (スコア:2)
お客さんへ送信する前に編集履歴を消す必要があるので、別ファイルへのブランチは避けられないのでは。
文書全部wikiで管理すりゃええのに (スコア:1)
これもプロプラを使うことの隠れたコスト
Re: (スコア:0)
これもプロプラを使うことの隠れたコスト
Excelワープロは、一部の表形式を除いて都度新作する事を前提とした物で、結果的に文書ファイルのバージョン管理不要。
使い回される一部の表形式は、「テンプレート」とファイル名に明記すれば良い。
テンプレートを上書きする馬鹿には付ける薬はないし、そんな馬鹿にドキュメントバージョン管理システムが使えるわけはない。
要するに (スコア:1)
＃残念ながら開発者でも難しいというのが現実なんだけどね
命名規則を指定すればいい (スコア:1)
わたしが勤めている会社では、「ドキュメント名_日付_編集者.拡張子」という命名規則で運用しています。
お客様に送ったなどの節目はさらにメールで周知します。
みんながITに明るいわけではないので、下手にバージョン管理システムを導入すると混乱を引き起こしかねません。
Re:命名規則を指定すればいい (スコア:1)
タレこみにあるような「都度別名保存する」というのが最新版保存で使われているのはあまり好きでない。
まあ、元コメントのように末尾のタイムスタンプやバージョン番号やが随時上がっていくならある程度理解できる。
問題点はタレこみ元では無法状態で「少し異なる名前」にしていることだろうね。
ちなみに私が良くやるのは最新は常に1個でファイル名も極力変えないという原則で、古い方の名前変更とバクアップフォルダーへ移動する方法。
これで少なくとも最新がどれかという問題は起きない。名前が固定なら利用もしやすい。
外部送付ならそれ専用のフォルダーを作ってそこへ入れ変更禁止にする。
#そういう面倒対応のお世話をしてくれるのがSVNみたいなツールなんだけどね。
たれこみ> 仕事のやり方を見直すといったローテクな提案もある。
あと、それをローテクっていうか?
命名規約を作ったり、ツールを使うようにする話の根本は全部仕事の見直しだよ。
それを放棄したら何も解決しない。
Re: (スコア:0)
外資系コンサルの方が勧めている方法 [diamond.jp]に近いものがありますね。
素晴らしいと思います。
Mediawiki (スコア:1)
実情 (スコア:1)
一時期社内開発担当してたんでストーリー中、「配偶者の会社」の惨状が少しはわかる。まとまってないが自分の業界に当てはめてこの会社がこの先どうなるかを予測。
ストーリーのような状況では当然ツールを導入orシステムを開発しようとなるが、こういうとこでは話題になってるツールを現状のニーズだけ考え気まぐれで使うので同じ目的の複数のツールが同時並行で使われることになる。また体制変わる毎に新しいツール使いたがるので時間が経つとデータがバラバラな場所にバラバラに散乱して手に負えなくなる。
全社あるいは複数の部署で統一しようと話が出てくるが部署毎に処理方法、考え方、慣習の違いがあり、更に関係者全員に論理思考は期待できないのでまとめるのに苦労、担当は素人相手に話聞いて調整して説得してというのががメインの仕事になる（優秀な人は自分が素人だと自覚してるが自覚がなく中途半端に知識のある連中が一番扱いづらい、プライドだけ高い子供のお守りみたいなもん）。合意ができればとりあえずはこちらの勝ち、統一できるかどうかはこちらの調整能力による。
うちらは貧乏なのでコンサルを雇った場合の事情は知らない、派遣されたコンサルの力量次第で天国になったり地獄になったりで運次第だろうなと想像。
技術的な知識が話を簡単にしてくれることはあるが知識よりは人の問題。
Re:実情 (スコア:3, おもしろおかしい)
配偶者（元文読むと女性っぽい？）は共感をもとめているだけで、
解決方法なんぞこれっぽっちも望んでいなかったりして。
diff, patchの統一プロトコルがあれば (スコア:1)
履歴管理ツールと、フォーマット毎のdiff, patchコマンドの仕様は独立していればいいと思う。
新しいフォーマットを作った人は、それに合った、プロトコルに適合したdiff, patchコマンドを作る。
履歴管理ツールは、ファイルフォーマット毎に適切なdiffとpatchを呼び出す。
これがあるべき姿だと思うんだけどな。
これどうなんだろ？ (スコア:1)
http://jp.techcrunch.com/2014/07/28/jp20140728universions/ [techcrunch.com]
エンジニア的にはGitHubでいいじゃんと思うけど...。
勝手に… (スコア:0)
状況がよく分からないのですが。
雛形を使って上書きが怖いならMS-Officeであればテンプレートありましたよね？
テンプレートで保存するときに任意のファイル名付けられるんでMessageIDぽくしたら？
これで人と時系列は何とかなるので基のファイル名をどうするかですが、これは一義的
に決まると思うので。
ユーザー名や日時が面倒ならVBAで補助して行けるのでは？
Re: (スコア:0)
皆が文書の上書きを恐れ、変更結果を「念のために」少し異なる名前で保存するため同じ文書の複数のバージョンができてしまい、どれが最新バージョンなのか、どれがクライアントに送られたバージョンなのかといったことが誰にもわからない状態だ。
元がテンプレートではなく、設計書などを改版→提出する流れでそれを特定のメンバーがやらない（初版作成者ではなく手の空いた人間に作業をあてがうなど）うえ、レビューで「（不適切な修正などが原因で）元に戻せ」という指摘を受けることが多いとか、そんな感じじゃないかなーと。
主業務として文書管理をする人を置かないとツールだけでは回らないのではないでしょうか。
管理者もレビューに参加してもらってOKになったらその版をブランチしてもらう、みたいに。
Re: (スコア:0)
分岐するのならその時点で分かるように連番や命名規約を決めればよいと思います。
バージョン管理システムを利用していますがソフトに全部任せるのは難しい場合も過去ありました。
文書管理者の準備は予算等で難しいでしょうし、たとえ人がいても結局解決しない場合もありました。
開発チームのソースやインフラチームの設定ファイル、自動化シェル等はCVSやVSS等で管理していますが設計書、パラメータシートなどのドキュメント類は結局ファイル名、ディレクトリの命名規約で回すことも検討したほうがよいかも。
Re:勝手に… (スコア:2)
とりあえず、どこそこのフォルダに書け！とだけ教えた。
見た目大事。
Re:勝手に… (スコア:1)
分岐するのならその時点で分かるように連番や命名規約を決めればよいと思います。
まさに正論。
しかし、正論で上手く行くケースばかりなら、こういうストーリーは立たないわけで。
たとえば、命名規約を守らないやつがいるとか、新規に加入したメンバーへの教育をしなければならないとか、意図的でないミスを防ぐ仕組みがないとか。
正論以前の問題として、首から上が飾りにしかならない人々の存在も無視できない。
たとえば、こう言ったファイル名に基づくバージョン管理では、十分な長さのバージョン識別子が必要になる。
よく見るのは、「 ○○-20150228.xlsx」とか。
これが十分と言えるのは、更新頻度が1回/日を上回らないと言い切れるときのみ。
こんなことは、十秒も考えれば判ることなのに、日に数回更新されるファイルに適用して破綻しているケースをよく見る。
こんなのは、可読性も考慮して、「 ○○-2015-02-28-00.xlsx」くらいにしとけば、日に十回以上更新されても問題ない。
しかし、彼らの思考がそういう方向に向くことはなく、同じ破綻を何度も繰り返している。
そういう人々を無視できないから、こういうストーリーが立つ、ってわけだ。
共有しないなら (スコア:0)
ファイル履歴使えよ...
Re: (スコア:0)
「皆が文書の上書きを恐れ」と書いてあるんだから共有共同作業が前提の話だろ。
履歴管理アルよね、、 (スコア:0)
dropboxではだめなのか？
Re:履歴管理アルよね、、 (スコア:1)
dropboxではだめなのか？
第3者のサーバーにファイルをアップロードしてもいい用途ならdrop boxやGoogle Driveもいいんじゃないかな。でも「ファイル名を変える」なんて方法を使うレベルだと、Google driveだと設定ミスって世界に公開して盛大に後悔、とかなりそう。dropboxは知らんが。
他に、あっちのミスでファイルが消えたとか、数日サーバーが使えない場合に賠償請求できないかと。こう考えると個人で機密度の低い用途が限度では。Gooleは「すぐにサービスを止めてしまう」という懸念もあるけど。
Google ドライブ (スコア:1)
古い版を今後も保持するよう設定していない場合、改訂日から 30 日経過するか改訂版数が 100 版を超えると、ファイルの古い版が自動的に削除されます。 [google.com]とあるから、これに注意が必要だけど 「Google 以外の形式で作成されたファイルでも、Google ドライブでそのファイルの古い版を確認することができます。また、古い版の削除やダウンロード、新しい版のアップロードも行えます。」とあるので、マル秘や極秘でなければ、今回の用途には使えるのでは。使いやすいかどうかは存じておりませんが。(逆に、設定しないと30日改定しないファイルはぜんぶ消えるってわけ? 怖過ぎ)
ていうかRCSで機能が不足って事は無いと思うのだけれど。そんな人ならSVNその他を使うだろうし。
RCSとかBATとか (スコア:0)
TZは JST-9にしておいてRCS [purdue.edu]の Windows で動くバイナリ使って ci -l -zLT %1 とか、それも無理ならバッチ1行で copy %1 %どこぞ%\%date:~-10,4%-%date:~-5,2%-%date:~-2,2%T%time:~0,2%%time:~3,2%-%1 とかじゃダメなの?
テキスト検索ならDesktopHE [xrea.com]。
Re:RCSとかBATとか (スコア:1)
今時RCS?
Re:RCSとかBATとか (スコア:1)
私の配偶者は～な人は「最初はSVNやTortoiseSVNを考えたが、開発者でなくても使いやすい、もっとシンプルなもの」とのことですから、SVNよりもシンプルなバージョン管理ツールとあれば、レポジトリが不要(というより扱えない)でコマンドのパスさえ通っている所に ci.exe 等を置けばバージョン管理が可能となるRCSで十分だろう、と思いました。今時、というなら、CVSは選択肢から外れますが、複数のユーザーが同時に一つのWordやスプレッドシートを編集して結果をマージ、とかはどのみちできないでしょうから、「編集中だからロックをかけるよ！」で競合を防げば済むかなと思いまして。ロックかけっぱなしで放置、とされると rcs -U 使う事になりますが。「異なる名前で保存する」なんてやりかたをしているぐらいだから、逆に、RCSで間に合うのになぜ新しい高度なツールを使うのかな、と。
Re:RCSとかBATとか (スコア:2)
まったく同意。
今、モデレート権があれば「すば洞」を挙げたい。
Re:RCSとかBATとか (スコア:1)
なら、RCSでも十分でしょうけど、Gitでも良いんじゃない?
どちらにせよ0からの学習なら、いまさらRCSじゃなかろう。
100MBのファイルを扱えないGitなど論外 (スコア:1)
なら、RCSでも十分でしょうけど、Gitでも良いんじゃない?
Gitは 100MBのファイルをpushできません。これは仕様なので。if you add a new file or update an existing file larger than 50MB, and will be blocked from pushing files larger than 100MB [github.com] と GitHub Help にありますよ。例えば誰かが写真の多いWordをpushしようとしたら弾かれて、管理者を呼んだところで解決できませんね。「Gitを捨て、別のツールを検討しよう」と提案する以外に無くなります。
うっかり100MB超えのファイルをリポジトリに追加してしまったら、面倒な手順を踏んで削除しなければいけません。GitHubは、プログラム開発ならいいでしょうが、Wordやスキャンした文書などを扱うのなら「論外」としか言いようがありませんので非技術系の人たちが学習する価値はありません。とはいえGit以外のバージョン管理システムも扱えるファイルの最大サイズに限度がある可能性があり、調べないといけませんが。
RCS は単純だしそんなにヤワじゃないだろうと思いましたが、扱えるファイルの最大サイズはパッと調べた範囲では分かりませんでしたが、とりあえず手元で 1GB のファイルを ci -l できる事を確認しています。
Re:100MBのファイルを扱えないGitなど論外 (スコア:1)
それ、GitでなくてGitHubの仕様じゃないの？
GitとGitHubの区別がついてないのがGit厨って思ってたけど、非Git厨でもそうなのか。
Re:100MBのファイルを扱えないGitなど論外 (スコア:1)
Gitは 100MBのファイルをpushできません。
ローカルだけでよければ、pushする必要は無いよね。
今手元で試した限りでは、1GBのファイルをcommitすることはできるようだよ。
GitHubは、プログラム開発ならいいでしょうが、
GitHubを使うって話は、あなた以外誰もしていないようですが。
Re:RCSとかBATとか (スコア:1)
SharePointは使ったこと無いけど、話を聞く限り、現実解として最有力だろう、ってことは認める。
けど、中央レポジトリ的なものが不要、って条件を満たさないのでは?
一時流行った奴 (スコア:0)
WebDAV
Windowsならネットワークドライブに割り当てられたはず。
(実装が腐ってるって話があったけど)
フィットするかはわからんが (スコア:0)
企業向けSNSとかが、求められてる要件にあってるのでは？
部署・部門毎にツリー構造でファイル共有、ファイルの更新履歴やコメント付けで管理したいって言うのであればですが。
大抵は全文検索もサポートしてますし。
チームコラボレーションシステムを主軸にする (スコア:0)
リビジョンコントロールシステムを使わない、使えない、使いたくない、使う度胸もない奴らに使わせなければいけない場合、
本題のようにストレージのディレクトリベースでやると破綻するので、
チームコラボレーションシステムとチケットシステムを主軸にして
起草・編集・修正・確認・権限者承認・外部提出の運用を回すようにしたほうがよいとおもう。
Atlassian の Confluence と JIRA あたりをつかうとかね。
Re:バージョニングファイルシステム (スコア:2)
OpenVMSで使われていたファイルシステムでしたっけ？
噂には聞いていますが触ったことがないので。
ストレージ容量があれば、ファイルシステムレベルで履歴を持つというのもありですよね。ZFSにみたいにブロックレベルでの重複排除もあるとストレージもさほど使わないで済みそうですし。
Re:Timemachine (スコア:2, すばらしい洞察)
Cmd+Sで保存した全てのバージョンを保存してくれるならまだしも、OSレベルのユーザーが制御できないタイミングのバックアップなんて、
あんまり当てには出来ませんよね。「このバージョンで完成！」ってユーザーが思うタイミングでの保存にこそ意味があるわけで。
# あと、その程度の機能は、他のOSでも概ね実装されていますよ :)
Re:コミュニケーション不足 (スコア:1)
ほぼ同意。もう、自分が知ってるツール自慢で滑稽だよな。
以前はどこの会社にも書類管理するライブラリアンという職業はあったんだけどな。
PCが普及して、文書をサーバーに突っ込めばライブラリアンが要らないというのが誤解だな。
ソフトウェア開発だって規模が大きいところはコミッターなりメンテナという立場の人が居る。
この相談の元の会社がどんな業態なのか知らんけど、一般的な引き合い、提案、受注、請求というサイクルで仕事が回っているなら個々の案件の作成物はテンプレートから派生させればいいだけで履歴を管理する必要はあまりないな。
たとえば、営業が見積りつくって、お客さんと会話して出精値引き入った見積りだし直した、といった場合最終的な見積りがどれなのかを会社として知っていることは重要だけど。
なんか、自分が知ってる範囲のことしか考えないやつばかりだな。
＃そういう企業活動を円滑に進めるためにあるのがSharePointなんだけどな。
＃Office使うのがメインの業務形態ならコンサル頼んでSharePoint入れるのが確実
＃＃金がないからと言って業務知らない人間に何か聞いても使いづらいヘンテコはツール押し付けられるだけ。ここ見てれば明らか。