日常の進捗履歴記録ツールWitBucket(仮称)検討中 (229レス)
日常の進捗履歴記録ツールWitBucket(仮称)検討中 http://mevius.5ch.net/test/read.cgi/tech/1668901194/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
必死チェッカー(本家)
(べ)
自ID
レス栞
あぼーん
1: デフォルトの名無しさん [sage] 2022/11/20(日) 08:39:54.55 ID:zgGXmL2v 日常の進捗/履歴記録/バックアップツールWitBucket(仮称)の製作を検討中です。 欲しい機能/実装等について意見あればどうぞ。 (長さ制限によりスレタイは一部略) (カッコ内はGit19スレ内の参考レス番) 詳細: Git19: https://mevius.5ch.net/test/read.cgi/tech/1667720427/101-102 経緯: Git19: https://mevius.5ch.net/test/read.cgi/tech/1667720427/59- 全レス: Git18: https://mevius.5ch.net/test/read.cgi/tech/1650651945/633- 【コンセプト】 ・ゴミ箱の様に簡単に操作出来、何も知らなくても使える『全自動完全履歴保持バケツ』(101) http://mevius.5ch.net/test/read.cgi/tech/1668901194/1
2: デフォルトの名無しさん [sage] 2022/11/20(日) 08:41:36.31 ID:zgGXmL2v 【目標仕様】 ・Gitを全く知らない人でも使える。 ・Gitのビュワーとしても多分使える。ライタとしても使えるはずだが勧めない。 ・中身の改変/消去を簡単に出来るようにする。(142) ・Gitツールではないので、Gitのフル機能へのアクセスは提供しない。 ・diffは取れるが「ファイル内の」mergeは直感的GUIがないので実装しない。(101,127) ・branchは現ブランチをパスと共に保存するのみ。(103,112) ・デスクトップ等に転がしてるファイルも明示的に指定すれば保存される。(109) 【実装】 ・Gitをゴミ箱/バケツ化するラッパ(フロントエンドのみ。バックエンドはGitで、Gitは別インストール必須)(101) ・electronで作ってwindowsストアに配置(広告付き無料アプリ)(101) ・プロプライエタリ。コードは俺が書く。使い勝手のフィードバックを希望。(101) 【開発意図】 ・後で確認出来ればいい程度の人にはGitは学習コストが高すぎるので、無学習で使えるアーカイバを用意する。 ・保存先はGit。これにより、gitや外部ツールを使うことも可能になる。(211) ・Gitで間違った物をcommitして結局全部作り直した、みたいな話が散見されるし、 実際俺も困ったことがあったので、簡単に改変したり消したり出来るようにする。 ・この機能でGitのリポジトリも改変出来るが、 俺自身がGitの仕様に詳しくない為、非互換の部分が発生するかもしれないので、勧めない。 (この意味ではバグだし、確認出来ればgitになるべく合わせるようにはするが) ・ビュワーとして使うだけなら安全。gitをゴミ箱GUIで閲覧出来るようにする。 【日程】 ・作る場合は、2023年3月末リリース目標。(101) ・広告収入目的の商用アプリであり、売れそうにないと判断した場合はそもそも作らない。(202) ・electron/Windowsストア/広告アプリ/他全Windows版Git/Saplingについての調査が必要。(102,299) http://mevius.5ch.net/test/read.cgi/tech/1668901194/2
3: デフォルトの名無しさん [sage] 2022/11/20(日) 08:42:08.54 ID:zgGXmL2v 【第二弾(完全に未定)】 ・Gitに欠けている機能を補完する。 ・commit/rebase履歴が無いので、付加する。(111,274) ・Viewでrebaseする。(多分saplingもこれを目指している)(331) 【名称について】 ・GitBucketがよかったが既にあるのでボツ。(126) ・Gitと冠するのはGitツールだと誤解を招くようなので、外すべきか?(191) ・しかしやはりGitの方が分かりやすいか?ならばGitPailが確かに良い(244) ・Linusと同様に3音3文字でunixコマンドと被らず、 馬鹿向けgit(馬鹿)で馬鹿の最上級を探したが、無いので、一周回して WitBucket(天才バケツ)。中身がGit感もある。 GitツールではないのでGitと付けないくらいが丁度よいと判断した。 Gitxxxxとするなら、GitPail。検索的に有利なこちらにするかも? http://mevius.5ch.net/test/read.cgi/tech/1668901194/3
7: デフォルトの名無しさん [sage] 2022/11/20(日) 10:54:30.03 ID:zgGXmL2v >>4 実はそれも考えた。 俺が欲しい物ってなんだろう?と思ったときに、一番分かりやすい表現がそれだったから。 ブッ込んでおきさえすれば、あとは手で探れば取り出せる、的な。 ただそれって、 現物(WitBucket)→四次元ポケット、にはなるけど、 四次元ポケット→現物(WitBucket)、にはならないんだな。 「四次元ポケット」と聞いてきた連中が想像するのはもっと違った何かで、Gitのフロントエンドではない。 というわけでボツ。 あとちなみに、Gitxxxxで考えたのは、 GitChest:大道具箱 GitCasket:小物入れ、宝石箱、 GitCan:can(出来る)とのダブルミーニング GitBin:binもこの界隈では違う意味になってしまうが、can/bin共に蓋付きなので雑に放り込んでおけるイメージがないのでボツ GitBox:大切にしまうイメージでボツ GitTrunk:同上 GitBasket:ザルは漏れそうなのでボツ Pailは俺自身知らなかった。そういえばペンキ缶のことをペールって呼ぶけど、あれ、正式名称だったんか!ってな具合。 ただ、雑に放り込めるイメージはあるから、(その単語を知ってる人には)Gitxxxxでは一番合ってると思う。 それから、名前ぐらいあとで決めろ、とか思う連中は、先人の知恵に学ぶべきだよ。(賢者は歴史に学び、愚者は経験に学ぶ) https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E5%90%8D%E5%89%8D%E9%87%8D%E8%A6%81/ 最初読んだとき、俺も、Matzよ、もうちょっとましなことは書けなかったのか?と思ったけど、今はこれは凄く納得してる。 少なくとも、自分が気に入らない名前は付けるべきではない。長期的に愛せなくなるから。 http://mevius.5ch.net/test/read.cgi/tech/1668901194/7
8: デフォルトの名無しさん [sage] 2022/11/20(日) 10:58:18.24 ID:zgGXmL2v >>5 その発想はなかった。が、GNUもそうだし、考えてみるべきだな。 ・馬鹿でも使える ・ブッ込んでおくだけ ・中身はGitであると薄々見える と名前を聞いただけでイメージ出来る案があれば募集。 http://mevius.5ch.net/test/read.cgi/tech/1668901194/8
9: デフォルトの名無しさん [sage] 2022/11/20(日) 11:06:58.01 ID:zgGXmL2v >>6 それはその通り。 なので「広告」付けて金銭で俺自身を釣る。 多分自分でもそこそこ使うが、Gitに慣れたら問題なくなってしまうのだと思うんだよ。 それがGitスレの連中なわけで、多分俺もそうなる。 俺自身が欲しいのは第二弾の方で、 こちらはGitには無いが俺には必要な機能を実装するから、俺自身が使い続けることは確定してる。 (ただし第二弾自体が未確定、それ以前に第一弾も未確定、 そもそもSaplingが実装済みな可能性大なのでこちらもよく確認して、になる) http://mevius.5ch.net/test/read.cgi/tech/1668901194/9
12: デフォルトの名無しさん [sage] 2022/11/20(日) 16:31:49.48 ID:zgGXmL2v >>10 それ言うならGNUばりに GIT Is TrashBox なんだろうけど、これだと通称も略称もGitなのが駄目だな。 あと、「ゴミ箱」ではどうしても「捨てる」感を払拭出来ないのが問題だ。 片づけるのが面倒だからとりあえず入れておく「ガラクタ入れ」(=最初から捨てる気はない)が使用感として正しいので。 >>11 と(上記のように)思ったけど、先に言われてしまった。 まあ略したら実はGitってのは良いが、この長さだと通称もGitになりそうなのが不味い。 多分対等な言葉を並べてるのが悪い。 Great Ineligible's Trail (偉大なる馬鹿の軌跡) とかだと通称「トレイル」で、「トレイル付けたか?」とか使われるからまだ行ける。 しかしこれもGit公式 > "Goddamn idiotic truckload of sh*t" > https://git.wiki.kernel.org/index.php/Git_FAQ#Why_the_.27Git.27_name.3F と似たようなものではあるが。 http://mevius.5ch.net/test/read.cgi/tech/1668901194/12
17: デフォルトの名無しさん [sage] 2022/11/20(日) 18:35:02.83 ID:zgGXmL2v >>15 全く知らんが、見る限りただの豪華版ファイル共有システムのような。 これで任意の履歴を探索出来るのなら、十分ではあるが。 というか、WitBucketはこの辺の「履歴探索出来ればOK」程度の連中を相手にしてる。 同一ファイル内のmergeなんて、ほぼ必要ない連中向けだ。 ちな、お前ら本当に「任意のファイルを任意のタイミングで任意に編集出来る」開発スタイルで、 mergeも日常的にやってるのか? それはチームの腕前が『上側に』揃ってる必要があって、 上手く回ってるのなら素晴らしいが、下手すると余計悲惨なことになるので、 一般の会社(新人からベテランまでの混成部隊)ではかなり無理だが。 ただサイボウズ(だったと思う)のインタビュー読んだとき、 ああこいつらは(俺の想定している)一般とは違うフローなのだな、とは思ったので、 連中は上手く出来てるのかもしれんが。 http://mevius.5ch.net/test/read.cgi/tech/1668901194/17
19: デフォルトの名無しさん [sage] 2022/11/20(日) 21:18:59.77 ID:zgGXmL2v >>18 そこから辿れる7ページ全部読んだ。 確かにこれで良い。履歴の部分が欲しいだけ。 > ヒント: チームで共同編集機能を使用する場合は、 > ライブラリ内で他のユーザーが共同編集しているものと同じ名前のドキュメントを誰かが誤ってアップロードしてしまった場合に備えて、 > 少なくともライブラリでメジャー バージョン管理を有効にすることをお勧めします。 > そうすることで、変更内容が失われた場合でも、ドキュメントの前のバージョンに復元することが可能になります。 > https://support.microsoft.com/ja-jp/office/%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%86%85%E3%81%AE%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%A2%E3%82%A6%E3%83%88-%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%82%A4%E3%83%B3-%E3%81%BE%E3%81%9F%E3%81%AF%E5%A4%89%E6%9B%B4sharepoint%E3%81%99%E3%82%8B-7e2c12a9-a874-4393-9511-1378a700f6de > 定期的に、ドキュメントを編集および保存Officeします。 > すべての編集と保存で新しいバージョンが作成される場合があります。 > たとえば、頻繁に編集を保存する場合、各新しいバージョンでは、個々の編集ではなく、ポイントインタイムがキャプチャされます。 > これは、自動保存 が有効になっている場合に一 般的です。 > https://support.microsoft.com/ja-jp/office/%E3%83%AA%E3%82%B9%E3%83%88%E3%81%A8%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%A7%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%81%AE%E3%81%97%E3%81%8F%E3%81%BF-0f6cd105-974f-44a4-aadb-43ac5bdfd247 ただ5000しか保存出来ないのは問題だから、縮退して欲しい。 自動保存等の割とどうでもいい奴はコミットメッセージ(SharePointではチェックインコメント)が入ってないから、 それらは直近100件越えたら自動的に縮退でいい。いやなら何かしら入れとけ、で十分だ。 マニュアルでバージョン番号を上げた場合は全保持(縮退無し)で。 http://mevius.5ch.net/test/read.cgi/tech/1668901194/19
20: デフォルトの名無しさん [sage] 2022/11/20(日) 21:19:42.57 ID:zgGXmL2v > Microsoftは9月24日(米国時間)、同社のWindowsデバイスに関する最新のデータを公開するページを更新し、現在世界で稼働するWindows 10デバイスの数が9億(900million)を突破したことを報告した。 > 例えばStatCounterの2019年8月時点でのデータを見ると、ほぼ正比例に近い形でシェアが上昇している。現在はWindows 10が約60%、Windows 7が31%の水準だが、 > https://www.itmedia.co.jp/pcuser/articles/1909/30/news054.html > マイクロソフトは、SharePointには20万の組織に1.9億人のユーザーがいると述べている[8]。 > https://ja.wikipedia.org/wiki/Microsoft_SharePoint シェア60%で9億台だから、Windows全部は13.5億台程度か? それで1.9億なら、1/7の使用率になる。 見る限り共有ファイルシステムで必要な機能を全部入れてて、ついでに履歴も取れるようになってる。 共有ファイルでやる部署には必要なソフトで、また、これで十分だろう。 ただ思ったより使用率が低いのは、何か他に原因がある気はするが。 (有料だって事か?まあこれも十分な理由にはなるが) > https://support.microsoft.com/ja-jp/office/sharepoint-%E3%81%A7%E4%BB%A5%E5%89%8D%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE%E9%A0%85%E7%9B%AE%E3%81%BE%E3%81%9F%E3%81%AF%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E5%BE%A9%E5%85%83%E3%81%99%E3%82%8B-f66dbda0-81f4-4d1e-b08c-793265c58934 これも復元するときはGitと同じく「ツール上で上書き」なのが気持ち悪い。 普通につまんで取りだして、確認したあとに「手動で上書き」したい。 大体は古いバージョンなんて見るだけで十分なので、一々「上書き」しないと確認すら出来ないのがとにかく気持ち悪い。 (つかこれどこから来た文化?バージョンが古いのに差し替わっただけかはファイルのhash取れば分かるのだからそうしろよと) http://mevius.5ch.net/test/read.cgi/tech/1668901194/20
21: デフォルトの名無しさん [sage] 2022/11/20(日) 21:20:16.00 ID:zgGXmL2v 個人的にはもうファイルシステムも上書きする必要なく、SSDのウェアレベリングと同様、常に新規でいいと思ってる。 ハードリンクがそうだが、あれは使いやすいとは言えないので、 各ファイル/ディレクトリに履歴が付いてて、必要なら引っ張り出せるようにして欲しいし、それだけで十分だ。 既に指摘されたように(Git19の73)、現Windowsもファイル単位ではこの機能を持ってはいるが、 勝手なときに記録され、勝手に間引かれ、勝手に停止されるのでは使えない。 保存時全部の履歴が保持されてる必要があって、 ただしどうでもいい(=メッセージが無く、かつ、バージョンも更新されてない)のは間引かれるべき、というわけ。 だからNTFSにこの機能が標準的に付けられたら、WitBucketの出番は無いね。 (Windowsがこの機能をハードリンクで実現して、勝手に管理してくれるのが一番いい。 要は上書きされてしまった昔のファイルを引っ張り出せれば良いだけだから。 どれなのかを探すのはユーザ責任でいい。日付で探しきれる自信がなければメッセージそれなりに残せ、で十分) http://mevius.5ch.net/test/read.cgi/tech/1668901194/21
23: デフォルトの名無しさん [sage] 2022/11/20(日) 23:32:27.69 ID:zgGXmL2v >>22 > Basic:650円/人月 家庭用には無しか。 地味に家庭用に履歴機能だけ付けておいて慣らして、 ファイル共有機能(家庭では不要)をBusinessで、として欲しいが。 > バイナリの管理が上手にできた方がいい。 それがどこまで出来れば「上手い」と言えるのか知らないが、多分、 ・diffを表示出来るか ・圧縮出来るか だと思ってる。 そしてSVNにはExcelファイルの差分を見るプラグイン?があるらしいと聞いてググったら、以下なのだが > Officeドキュメントの内容比較はTortoiseSVN/TortoiseGitで瞬殺 > ところでTortoiseSVN/TortoiseGitでOffice文書の差分を見ようとするとどう表示されるか、お気付きでしょうか。 > バイナリ差分が表示されたりしません。 > Officeがセットアップされている環境ではOfficeを使って差分表示してくれます。 > しかも、Excelブックについても自力で差分表示を生成までして! > https://qiita.com/yuba/items/771e59b6bf1b0908e500 これだとtortoiseの機能であってGitでも出来るらしい。 そもそもOffice側にプラグインがあれば出来る、ということのようだが。 http://mevius.5ch.net/test/read.cgi/tech/1668901194/23
24: デフォルトの名無しさん [sage] 2022/11/20(日) 23:32:57.69 ID:zgGXmL2v ソフトウェアの構成としては、差分表示は各ソフトに任せるべきであって、 履歴ツールの領分は各ファイルを用意するところまでだ。 tortoiseはExcelに足りなかったから補ったようで、これは確かに凄いが、個人レベルでの開発でこれは無理。 バイナリ圧縮もほぼ無理。そもそもフォーマットが公開されてないし、 単に圧縮したいだけなら圧縮DISKにセーブしろ、で終わる。 バイナリも履歴方向に対してならかなり圧縮出来るのだろうけど、それは別開発だよ。 上手く出来たら、「バイナリ用高圧縮履歴保持バケツ」として差別化は出来るのだろうけど、 diffのアルゴリズムは地味に難しいので、俺ではなくて数学屋がやるべき課題だ。 まあどちらも(diffも圧縮も)出来ないのであればrsnapshot(Git19の222=rsync+ハードリンク)と変わらんといえばそうだが。 ググるとSVNではxdeltaを使ってると出て、1997製らしいので、 > https://yanor.net/wiki/?Subversion/%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E5%B7%AE%E5%88%86%E4%BF%9D%E5%AD%98%E6%A9%9F%E8%83%BD > https://ja.wikipedia.org/wiki/Xdelta むしろこれをGitに組み込めよ、ということだと思うが。(既にそうなってる?) xdeltaはAPL2らしいので、Gitには無理なのか?よく分からん。 とりあえずWitBucketはxdelta呼べるようにしろ、というのなら多分出来るが。 てかWindows用バイナリが無いんだがこれ。exeのリンクは全部GitHubに飛ばされてしまう。 > http://xdelta.org/ http://mevius.5ch.net/test/read.cgi/tech/1668901194/24
メモ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.924s*