問題タブ [trunk]

スクリプトを保存する場所や、このフィールドにリンクする方法がわかりません。このスクリプトは別の Web サイトで見つけましたが、必要な作業には問題なく機能すると思います。トラックが停止したときに電子メールで通知するだけです。

たとえば、JVM の 2 つの異なるインスタンスを使用するなどして、Eclipse で 2 つのプロジェクトを同時に実行できるかどうか疑問に思っていました (それが理にかなっている場合)。

ちょっとした背景: 比較的長い実験(6 ～ 8 時間) を実行するプロジェクトがあります。私は最近、コードを改善/プロジェクトに追加するためのさまざまな戦略を開発するために分岐できる開発のポイントに到達することができました。ただし、同時にいくつかの実験を行う必要があり、実験が完了するまでに長い時間がかかるため、長い待ち時間を利用して分岐コードに取り組みたいと考えています。

要するに、私の理想的なシナリオは、Eclipse のトランクで実験を開始し、ブランチに切り替えてコードを開発し、機能をテストする必要があるときにブランチで短い実験を実行することです。これは可能ですか、それとも別の戦略を考え出す必要がありますか?

前もって感謝します！

編集：「テスト」という言葉の選択は、誤解される可能性があるため、誤解を招く可能性があることに気付きました。JUnitなどでテストするのではなく、実行するはずのプログラムを実行することを意味します。ご迷惑をおかけし申し訳ございません。

私の問題に対する最善の解決策を見つけようとしている月であり、これが最善の解決策です. あなたがそれに同意するかどうか知りたいです。

相互接続された一連の Web アプリケーションを開発しています。各アプリケーションを、他のアプリケーションとは独立した単一のソリューションとして扱います。各アプリケーションは異なるプロジェクトによって形成されますが、これはあまり重要ではありません。

トランクの新しい機能を開発するために使用します。何かをライブで公開するときはいつでも、バージョン名でトランク バージョンにタグを付けます。たとえば、最初のトランク バージョンが 1.0.0 とタグ付けされているとします。さらに実装を開発すると (つまり、1.1.0 に取り組んでいます)、製品版から一連のバグが出てきます。私たちが考えているのは、タグ 1.0.0 をチェックアウトし、バージョン 1.0.1 に向けてバグを修正することです。

ここで達成したいことは、各リビジョン バージョンにタグを付けることです。つまり、1.0.0、1.0.1、1.0.2 ... の完全な作業コピーを作成できるようにしたいと考えています。

これが私の解決策です。同意するかどうかを知りたいです。

1. タグ付きバージョン 1.0.0 をローカルの /tags フォルダーにチェックアウトします
2. このバージョンを /branches/1.0.1 リポジトリ フォルダーに分岐します
3. 新しいブランチをローカルの /branches フォルダーにチェックアウトします
4. ブランチ 1.0.1 のバグを修正します
5. x がコミットした後、すべて問題がなければ、この新しいバージョンを /tags/1.0.1 にタグ付けします

など、新しいバグや新しいリリースごとに。試してみましたが、/tags フォルダーをチェックアウトすると、すべてのバージョンが表示され、完全に機能しています。

1.1.0 の準備ができたら、「リビジョンの範囲をマージする」オプションを使用して、トランクの最後のタグ (またはブランチ、すべてが正しい場合は最後に同じである必要があります) をマージする必要があります。すべてがマージされると、過去に修正されたリビジョンを含む完全に機能する 1.1.0 バージョンが得られるはずです。コンパイルし、テストしてから公開し、明らかに、サーバーの /tags/1.1.0 フォルダーにタグ付けします。

どう思いますか？ありがとう、マルコ

私は最近トランクに取り組んでいましたが、私が行った変更は他の人がそれらを必要とするかもしれないと思ったので、コミットする直前にパッチを作成しました.

現在、ブランチ (数週間前にトランクから来た) で作業していた仲間の開発者は、新しいサーバーに移動するためにこれらの変更を必要としています。

Tortoise SVN でパッチを適用しようとしていますが、作業コピーの不一致がうまくいきません。私は持っている ：

• 私のトランク: D:\SVN\Trunk
• ブランチ: D:\SVN\Branches\TheBranchINeedToPatch

私は何か不可能なことをしようとしていますか? 私が欠けているものはありますか？

ブランチの作業コピーにトランク パッチを適用できますか?

助けてくれてありがとう！

トランク/ブランチとタグに関しては混乱してしまいます。以下は私の質問です：

単一のプロジェクトに取り組んでいる開発者のチームがあります。多くの場合、開発者はグループに分けられ、同じプロジェクトのさまざまなモジュールで作業します。

現在、誰もが同じローカルサーバーで作業し、ファイルをコミットする単純なSVNシステム（トランク/ブランチまたはタグなし）があります。しかし、問題は、数人の開発者が将来のモジュール（すぐに稼働することは想定されていない）に取り組んでいるときに始まります。この状況では、データをコミットできません。コミットすると、開発コードがライブサーバーにアップロードされ、すべてが台無しになってしまうためです。

それで、今私は、これらの開発者が別々に、しかし同じコードで作業できる、ある種の解決策を探しています。このようなもの：

開発者Aは新しいモジュールAに取り組んでいます開発者Bは新しいモジュールBに取り組んでいます開発者CはモジュールCのバグ修正に取り組んでいます（これはすでに稼働していますが、修正する必要のあるバグはほとんどありません）

したがって、開発者Aはこのマシンに独自のコピーを持ち、開発者Aのリポジトリにコミットします。（またはブランチ）

同じロジックが開発者Bにも当てはまりますが、開発者Cはタグのどこかにある共通の安定したコピーで作業し、作業が完了すると、タグが付けられてトランクにプッシュされ、ライブサーバーにアップロードされます。

開発者Aが作業を終えたら、ライブアップロードのためにすべてのファイルをトランクにプッシュします。（これにより、トランク内のいくつかの一般的なファイルもマージされます）。同じロジックが開発者Bにも適用されます。

SVNがこれに対する正しい解決策になるかどうかはわかりません。自分が欲しいものを実装するもっと簡単な方法があるかどうかさえわかりません。

どんな提案でも大歓迎です。

ありがとうTTR

git-svn ツールを使用して、トランク ブランチを svn リポジトリ内の別のブランチに置き換える方法は?

これが私のSVN構造です:

Mavenリリースプラグインにタグ付け/trunk/dev/したい/releases/<release-version>

こちらが私の親ですpom.xml

問題は、実行するmvn release:prepare-with-pomと、Maven が にタグ付け/trunkされること/releases/<release-version>です。

誰かが/trunk/dev代わりにタグを付ける方法を知っていますか? ありがとう ！

現在、SVNからTFSに移行しています。

今日、私たちの開発を追跡および整理するためのトランク、ブランチ、およびタグがあります。しかし、私たちは棚セットを持っている間にトランクの必要性に疑問を投げかけています。保留中のアクティビティを棚上げし、必要に応じてそれらをメインブランチにアンシェルフしてマージすることができます。

それは良い計画ですか？これを行うことで悪い結果はありますか、誰かが以前に試したことはありますか？

前もって感謝します！

私が取り組んでいる SVN プロジェクトは完全に乱雑で、リソースの名前は恐ろしく、プロジェクト ファイルは誤った情報とリンクでいっぱいで、検索して破棄することはほとんど不可能です。その上、ファイル アーカイブは、意味を理解できるように真剣に再編成する必要があります。このようにコミットしたのは、同じ名前の新しいプロジェクトで問題を修正し、「良い」コードとリソースをすべて素敵なフォルダーとディレクトリに転送することだけを意図していたからです。

だから私の問題は、私がプロジェクト「FOOBAR」を持っていることです。私のデスクトップには、リビジョン管理下にない「FOOBAR_FIXED」がありますが、「FOOBAR」SVNで今必要なものです。

「FOOBAR」をすべて「FOOBAR_FIXED」に置き換えるにはどうすればよいですか? すべてのオブジェクトを手動で削除してコミットし、次に手動ですべてのオブジェクトを再度追加して再コミットする必要はありませんか?

バージョン 1.0 をリリースし、trunk で 2.0 の開発を続けています。リリースされたバージョンに関連するバグ修正のために、branchs/1.0 を作成しました。

計画は:

• 2.0 開発はトランク/で継続
• トランク/ には、branches/1.0 にマージされない新機能が含まれているため、トランクはこれまでブランチ/1.0 にマージされていません。
• リリースされたアプリケーションにバグが見つかった場合は、branchs/1.0 に修正が加えられます。修正セットが本番環境にリリースされると、branchs/1.0 が tags/1.0.x にコピーされ、branches/1.0 が trunk/ にマージされます。
• 1.0.4 の修正をトランクにマージすると、1.0.3 の修正が自動的にスキップされるように、subversion マージ追跡で変更を追跡する必要があるという考えです。

このアプローチに問題はありますか? Subversion マージ追跡は変更を追跡しますか? 私はまだこれを実際に試していませんが、ほとんどの例ではこれを別の方法で行っています (ほとんどの 2.0 開発は 1.0 修正では必要ないため、トランクからブランチへのマージは望ましくありません)。マージと再統合は何とかこれに収まりますか?