Gitを置き換えるバージョン管理システム「Jujutsu」 | ソフトアンテナ
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
bun.lockbのVersion管理をGitでどうやる？問題
はじめに bun installで生成されるBunのロックファイルはbun.lockbというバイナリファイルである。 公式を読むと性能向上のためにバイナリ化していることがわかる。 Why is it binary? In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles. 困ること まさにこのツイートの問題で、Git管理したいのにバイナリが出力されるのは不便で、どうしよう? と実際の本番利用では困るだろう。 解決方法 案1. git diffで差分確認する 公式のページを読むと、どうやら設定追加でgit diffができるらしい。 bun install request g
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
Metaの大規模ソースコード管理システム「Sapling」がオープンソース化
Metaが10年間にわたり開発・使用してきたソースコード管理システム「Sapling」がオープンソース化されました。Git互換で基本的なコマンドは類似しており、すべてのコマンドがシンプルで使いやすいように設計されているとのこと。Saplingは2022年11月15日から一般向けに公開されています。 Sapling: Source control that’s user-friendly and scalable https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ MetaはSaplingについて「ユーザビリティとスケーラビリティを重視した、Metaで使用されているソース管理システム」と紹介。GitやMercurialのユーザーにとって基本的な概念の多くがなじみのあるものであり、
Railsで監査ログやバージョン管理機能を追加するPaperTrailの使い方をまとめてみた - Qiita
github : https://github.com/airblade/paper_trail Railsアプリケーションで監査、またはバージョン管理のためにモデルの変更を追跡するツールです。モデルの生成から破棄まで監視していて、任意のバージョンへ戻したり、削除したものを復元したりできるようになります。 基本的にはgithubのREADMEを見ればだいたいわかるようになっていますが、少しつまづいたところもあったのでまとめました。 PaperTrailのバージョン 2015/11/25 バージョン4が最新安定版、ruby1.8.7以上、activerecord3.0以上6未満 バージョン5はunreleasedとなっています。 作成されるテーブルとその中身 PaperTrailは以下のようなversionsテーブルを作りログを残します。 item_typeがモデル名、 whodunnitは
PaperTrailはどうやってActiveRecordのバージョン管理をしているか - Qiita
この記事はRails Advent Calendar 2014の21日目の記事です。 Qiitaでは投稿の履歴管理にpaper_trailというgemを使っています。本稿ではPaperTrailがどんな感じでイベント情報をDBに保存しているかを紹介しつつ、PaperTrailが作り出すversionオブジェクトの渡り歩き方を簡単に解説したいと思います。 PaperTrailを使ってみよう 前提 PaperTrailで管理している Item modelがあり、そのインスタンスを2回編集してから削除したとします。 コードで表現するならこんな感じです。 class Item < ActiveRecord::Base has_paper_trail end item = Item.create(body: 'foo') item.update_attributes(body: 'bar') ite
分散VCSのモデル、あるいはPijulについて | κeenのHappy Hacκing Blog
先日、Pijulという分散VCSについて知って、それについて調べてみたら少し面白かったのでメモ。 DVCSで一番有名なのは間違いなくGitだろう。あれは分散グラフ理論木モデルに基いているらしい。ベースになったモデルがあることに驚いたが、調べても出てこなかった。 Gitは高速で信頼性が高い一方、コミット同士をチェーンのように繋げてしまうので柔軟性を欠き、例えばCherry Pickなんかがやりづらい。 あるいはリモートのmasterを取り込まずにローカルのmasterにコミットすると互いに独立した変更であっても一旦remote masterをマージしないとプッシュ出来ず、コミットグラフが汚れてしまう。 また、CUIが直感的でなく、理解しづらいという声もある。それはこういう皮肉にも現れている まあ、言われてみれば私もこのスライドを見てようやく理解した。 他のVCSにも色々特色はあって、歴史は神
第2回 ハックガールズが教える、Gitの基礎知識 | gihyo.jp
皆さん、こんにちは！ エンジニアアイドル「ハックガールズ」の堤沙也と濱ヶ崎美季です。 前回は私達の自己紹介をさせて頂きましたが、連載第2回の今回からいよいよ本題。「Git」について一緒に学んでいきましょう！ Gitとは？ Gitとは、分散型バージョン管理システムの1つです。 では、バージョン管理とは一体何でしょうか。 プログラムというものは、多くの場合、一度開発して終了ということはありません。まず作ってみて、改善したり、機能追加したりと、どんどん更新されていくものです。 しかし、プログラムを更新すると、人はうっかりリバグも生んでしまうことがよくあります。昨日まで正常に動いていたプログラムが、今回の更新によって動かなくなってしまった！という苦い経験は誰しもあるでしょう。 バグが発生してしまったプログラムに対し、「ひとまず正常に動いていた状態に戻そう！」と思い立ったとき、役に立つのがバージ
Semantic Versioning 2.0.0
Semantic Versioning 2.0.0 Summary Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Introductio
本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
Bazaar-NG: 7 years of hacking on a distributed version control system Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。 Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。 この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。 黎明期 < ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。 2004年、筆者は、 SambaのコントリビューターであるMartin Pool
bzrは死につつある。Emacsは移行しなければならない
bzr is dying; Emacs needs to move Emacsのソースコードは、Bazaarでバージョン管理されてきた。しかし、Bazaarは分散バージョン管理システムとしては、Gitに敗北したし、もはや死につつある。Eric S. Raymondは、Emacsは他のバージョン管理システムに移行しなければならないと書いている。 私がこの投稿をしている理由は、バージョン管理システムとその周辺ツールのエキスパートとしての責務であって、この議論に参加したいがためではない。 bzrバージョン管理システムは死につつある。ほとんどの点で、もはや死んでいる。dev listは死んでいるし、Canonicalのほとんどの内部プロジェクトはbzrを捨ててgitを使っているし、古参開発者の一人が、なぜbzrが失敗したかについて書いている: http://www.stationary-trave
git さんと darcs さん - ろじかるんるんものがたり
HIMA' に参加してきました。今回のお題は「gitとdarcsの使い方」。 darcs のパッチ理論の話とか聞けるかなーと思っていたのですが、聞けなかったのでちょっと残念でした。そもそもパッチ理論の話出来る人っているのかなっていう… とりあえず恐らく利用者が多いであろう git ユーザー向けに darcs の特徴とか。 バージョン管理というよりパッチ管理。 歴史（コミットが形成する DAG）は存在しない。あるのは積み重なったパッチだけ。 パッチ間の依存関係を考慮したシステム。依存関係さえ問題なく解決されていれば、昔のパッチを削除しようが何しようが関係なし…ヒエー ブランチはない。ブランチが欲しければリポジトリを作る。 インデックスはない。 author と committer の区別はない。あるのはパッチの作成者だけ。 パッチに名前がある。基本的にパッチは名前で指定。 こんなもんですかね
etckeeperで設定ファイルのバージョン管理を始めよう
斎藤です。こんにちは。 今日は、etckeeperを用いて、設定ファイルをバージョン管理する方法を説明します。設定ファイルの書き換えで辛い目に遭う前に、どうぞお試しください。 ※CentOS 6.4, Ubuntu 12.04 LTS, etckeepr 1.7を基準に説明します etckeeperとは etckeeperは主に/etc配下をVCS(Version Control Systems)を用いてバージョン管理します。実態は、gitやmercurialのwrapperとなっています。 設定ファイルの書き換えの際に、ファイル名に日付をつけてバックアップしたりする手間を省いたり、誤って書き換えてしまったときのための 保険 として利用する事ができます。 インストール方法 はじめに 先程も述べました通り、etckeeperはVCSのwrapperとして動きます。そのため、インストール時には
On Chromium Tree (to kzys) - WiT
Google の巨大レポジトリとブランチ無し運用 に書いててあることを肴に雑談する試み。基本的には kzys さん向けに書いてるので他の人には 文脈不足で誤解されそうだけどめんどくさいので特に補足しないで書きます。 Chromium も Bundler みたいのを使っている。 Chromium は言うほど単一ツリーに閉じておらず、結構サードパーティのライブラリに依存している。 ビルド支援の glicent スクリプトは Bundler のしょぼいやつみたいな機能をもっていて DEPS というファイルが Gemfile(.lock) 相当。 この外部レポジトリのこのリビジョンをこの場所にチェックアウトしろと指示している。 Bundler というと大げさすぎで実際は git submodule くらいです。 代表的なところだと Blink, V8, Skia, WebP あたりはこうやって引っ
Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi
GTAC 2013 Opening Keynote の Evolution from Quality Assurance to Test Engineering (スライド) を見た。 スライドの7ページ目 によると、Google では 15,000 あまりの開発者が、40 あまりの拠点に分散している。そして、彼らはひとつの巨大なレポジトリで、ブランチなしに開発しているらしい。 Single monolithic code tree with mixed langauge code Over 100 million lines of code. 50% of code changes monthly. Development on one branch - submissions at head 講演ではこの理由について One of the benefit is that we don’
Get Started - Flyway by Redgate • Database Migrations Made Easy.
For non-JVM users and environments without build tools > flyway migrate -url=... -user=... -password=... Get Started with the Command-line Tool Migrate directly from within your application Flyway flyway = Flyway.configure().dataSource(url, user, password).load(); flyway.migrate(); Get Started with the Java API
Flywayで簡単DBマイグレーション | DevelopersIO
Flywayとは FlywayとはDBマイグレーションフレームワークです。 複数人でのアプリケーション開発時のDBマイグレーション作業を素早く手軽に行うことができます。 MavenやAnt、APIやコマンドラインツール形式で提供されており、柔軟に対応することができます。 環境構築方法 今回使用した動作環境は以下のとおりです。 OS : MacOS X 10.7.4 MySQL : 5.5.15 flywayを使ってみよう 環境設定 flywayはMavenやAPIからも使用できますが、今回はCommand-line Toolを使ってみましょう。 ここからCommand-line Toolをダウンロードして解凍しておきましょう。 次にテストで使用するデータベースを用意します。今回はMySQLを使用しました。 mysqlを起動し、コンソールからデータベースを作成しておきましょう。 mysql>
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DBスキーマもバージョン管理したい！
GitHub - kwatch/migr8: DB schema version management tool
GitHub - tacitknowledge/autopatch: An automated database patching framework for Java.