version-control - 継続的なバージョン管理

Question

私は継続的なバージョン管理システムを見たことがありません - 正式なチェックインを待つのではなく、開発したコードの変更を保存するものです。変更はもちろん「未チェックイン」として保存されますが、バックアップのために保存され、実際に正式なチェックインを行う前に他の人が見ることができます.

私はこれを見たことがないので、それまたはそれに似たものが存在するかどうか、そしてそれが良い考えであるかもしれないし、そうでないかもしれない理由について疑問に思っています.

現在、プログラマーはソースコード管理をコードのパケットの統合と考えていますが、これらのパケットを小さくして継続的に統合しないのはなぜでしょうか?

-アダム

score 13 · Accepted Answer

現在、プログラマーはソースコード管理をコードのパケットの統合と考えていますが、これらのパケットを小さくして継続的に統合しないのはなぜでしょうか?

DVCS はすでに基本的にこれを行っていると言えます。分散化されているからではなく、コミットが非常に高速だからです.. git を使用すると、SVN よりもはるかに頻繁にコミットできます.. また、「チャンク」または特定のコミットが簡単になりますコードの (git add -iまたはを使用してgit gui) であり、一般に、完全なファイルではなく、コード行の追跡にはるかに重点を置いています (Subversion のような「従来の」VCS として)。

また、あなたが言ったように、gitが本質的に機能する方法は、「変更はもちろん「チェックインされていない」として保存される」ことを意味します..コミットすると、変更はローカルであり、別の方法でリモートマシンにプッシュしますコマンド..保存するたびにコミットし、必要に応じてそれらを単一のコミットにリベースできます。

「継続的なバージョン管理」を行うツールについては、次のようなシェルスクリプトを使用して非常に簡単に行うことができます..

while [ 1 ]; do
   git add -a && git commit -m "Autocommit at $(date)";
   sleep 10;
done

同様のことを行うスクリプトCACM ( github ) があります。

[CACM] は特定のディレクトリを監視し、すべての変更をスタンドアロンの Git リポジトリにコミットします。

使用するには、次のようにします。

cacm --repo dir_of_git_repo --watch dir_to_watch

なぜそうする必要があるのかわかりません.. VCSの使用について最も役立つことの1つは、（最後のコミット以降に）変更したものの差分です。一定の/自動化されたコミットを持つことは単なるノイズになるようです..

また、「e」テキストエディターには興味深い機能があります。分岐を使用して元に戻す履歴を視覚化します。スクリーンショット付きのブログ投稿があります。

score 11 · Accepted Answer

定期的な自動保存の仕事は、バージョンシステムの仕事ではなく、編集者の仕事です。バージョンシステムに新しいバージョンが表示された場合、それは他のバージョンからの意味のある変更を表す必要があります。

score 6 · Accepted Answer

Eclipse には、まさにそれを行う「ローカル履歴」と呼ばれる機能があります。保存間でソースファイルのコピーが保持されます。削除されたフォルダも追跡します。それは私のお尻を何度も救いました。ローカルヒストリーは、ローカルマシンでのみ発生する低レベルのバージョン管理として表示できます。もちろん、これの欠点は、別のマシンで作業する場合、ローカル履歴が異なることです。

score 5 · Accepted Answer

bazaar、git、Mercurialなどの配布バージョン管理システムを使用できます。その後、ローカルでコミットできます。

score 4 · Accepted Answer

さまざまな DVCS 用の inotify ベースのプラグインをいくつか見てきましたが、それらは非常にスマートなだけです。本当に理想的なのは、リポジトリをコピーオンライトファイルシステムに保存することです。これにより、これらの頻繁に実行される細分化された (そして不変の) バージョンのファイルが DVCS の外部に保持されます。

他の人が言ったように、私は多くの小さな約束をすることを好みます. DVCS を使用すると、トランクやマスターブランチの破損を心配する必要はありません。プッシュは作業が終わってから行うだけで済みます。ファイルを編集する際に有害なリビジョンが作成される心配はありません。

Linux では、ext3cowを使用して HG/Git リポジトリを保存しています。これにより、あなたが説明したような機能が得られます。悲しいことに、Linux を超えて移植可能なものを私は知りません。クレイジーなチームが Python で何かを思いつくかもしれません。

この質問は以前に何度か出てきたので (それぞれ異なるコンテキストで)、ext3cow のような (しかしポータブルな) ものが必要であることは明らかです。それでも、特に巨大なツリーでは、DVCS 自体が肥大化することは望ましくありません。

DVCS ではなく、ファイルシステムからこれを要求する必要があると思います。

score 3 · Accepted Answer

Subversion autoversioningのようなものですか?

免責事項: 私は自動バージョン化が開発にとって良いアイデアだと言っているわけではありませんし、私が個人的にやろうとしているわけでもありませんが、技術は存在します。

score 3 · Accepted Answer

すべての変更をチェックインする必要はありません。連携できる変更のアトミックセットをチェックインする場合。メソッドにパラメーターを追加して保存し、それをチェックイン (および CI ビルドを実行) した後、メソッドへの呼び出しをまだ更新していないため、ビルドが中断されることは望ましくありません。

score 2 · Accepted Answer

JetBrains が開発した継続的なバージョン管理システムに興味があるかもしれません。まだ公開されていませんが、マルメで開催された JetBrainsDay の基調講演でいくつかの機能を紹介しています: http://new.livestream.com/jetbrains/jetbrainsday1/videos/29348962

score 2 · Accepted Answer

ここに別のアプローチがあります。ほとんど毎日のように、何かが動かなくなってしまい、その理由がわからないという状況に遭遇します。数分巻き戻して、どのファイルにどのような変更が加えられたかを確認します。したがって、継続的なバージョン管理の必要性に同意します。

同時に、毎日何千もの小さな変更をリポジトリにチェックインしたくないのも事実です。

わかりました、これがあなたがすることです。両方を使用しますが、混合しないでください。ソース管理はチーム全体で使用する必要があり、時々チェックインします。同時に、ローカルの個人用ファイルバージョンソフトウェアを実行して、小さな変更をすべて保存し、実際に情報を簡単に使用できるようにします。

それでおしまい。私はHistory Explorerの開発を手伝ったので使用していますが、他にもあります。

score 2 · Accepted Answer

必要に応じて、すべての行または文字を git のような DVCS でコミットできます。一般に、DVCS を使用する場合は、できるだけ頻繁にコミットして、git bisect などのツールで問題を簡単に突き止められるようにすることをお勧めします。説明した効果が必要な場合は、保存するたびにコミットするように選択したエディターをスクリプト化できます...実際には、それは少し多すぎると思います.

score 2 · Accepted Answer

この目的のために開発ブランチをセットアップし、品質保証レベルのブランチにマージする前に、開発者が作業中に変更をコミットするようにする人もいます。主要な開発ブランチに変更をコミットしてマージする前に、自分のブランチで主要な変更作業を行っている開発者を配置することもできます。したがって、分岐はこれに対処できます。

score 2 · Accepted Answer

私はEclipseがそうするか、保存するたびにこのようなことをしていたと思います。バグを特定しようとしているときに、コードがハッキングされてバラバラになってしまったことが何度かありました。

score 1 · Accepted Answer

Rational ClearCaseには、動的ビューの概念があります。Windowsでは、開発ビューはマップされたドライブとして表示されますが、コードの変更は、保存を押すとすぐにサーバー側に保存されます。それはあなたが探しているものですか？

ご想像のとおり、この方法で作業することにはトレードオフがあります。したがって、上記の Siの回答のように、これは推奨事項ではありません...

score 1 · Accepted Answer

Java でのプログラミング経験が数年以上ある私は、Visual Age が開発プロセスにもたらした斬新なアプローチを今でも (懐かしく) 覚えています。Visual Age は、ソースコードに対して非ファイルアプローチを採用していました。コードはリレーショナルデータベースに格納されました。通常、単一のメソッドを示すビューで作業します。また、完全なファイルビューもありましたが、あまり使用しませんでした。

バージョン管理に関しては、保存するたびにバージョンが生成されます。バージョン番号/名前を使用して、メソッド、クラス/インターフェイス、パッケージ、またはプロジェクト全体を明示的にチェックポイントできます。また、メソッドレベルでソースをより細かく制御することもできました。Visual Age から多くの機能を継承し、現在ではコードのすべての「保存」をローカルに保存する履歴機能を備えた Eclipse で作業を開始すると、一歩後退したように感じずにはいられませんでした。

score 1 · Accepted Answer

Dan が述べたように、IBM Visual Age IDE は、保存したソースコードファイルのすべてのバージョンを保持していました。ただし、このアプローチは IDE に限定されません。DEC VMSオペレーティングシステムは、バージョン管理されたファイルシステムで同様のアプローチを採用しました。VMS では、各ファイルの完全な名前にバージョン番号が含まれており、ファイルを保存するたびに、以前の最大番号より 1 大きいバージョン番号で新しいコピーが作成されました。

どちらのアプローチも、分岐 (さらに言えば、同じソースファイルで作業する複数のユーザーを容易にするために特別に設計された機能) がないという点で、今日私たちが知っているバージョン管理とはまったく一致しません。しかし、どちらも人的エラーに対するバックアップの目的を果たします。これは、私にとってバージョン管理の最も有用な側面です。

score 0 · Accepted Answer

0

ベスタはどうですか？

http://www.vestasys.org/

于 2010-01-05T14:07:34.797 に答える

version-control - 継続的なバージョン管理

16 に答える 16

Related

Reference