問題タブ [organization]

これらのプロジェクトはすべて相互に依存しているため、これらのプロジェクトをどのように編成すればよいかわかりません。

現在、すべてが次の構造になっており、管理が難しくなっています

これには多くの問題があります: -1 svn 構造が少し混乱しています。たとえば、1 つのアプリケーションだけの bracnh を作成する実際の方法がありません。アプリによって。たとえば、python プログラムは、python 拡張 dll がどこにあるのか、および各共通 dll がどこにあるのかを知る必要があります。これらのパスは、svn では、リリースの場合とは非常に異なります (すべて共通のディレクトリにある可能性が高い)。

さて、私たちは皆、の標準的なSVNセットアップを知っています

また、タグには「特別な」コミットを含めることをお勧めします。ただし、tagsディレクトリを実際に使用したことはなく、なぜ使用するのかわかりません。

私の理解では、tags\には"Version1Release \、Version2Release \、ThatTimeWeUpgradedEverthing \"などが含まれます。しかし、ここに入ると、Version1Releaseに変更を加える必要がある場合は、ブランチである必要があります。タグは決して変更されないはずですが、とにかくソース管理でコピーを作成する意味は何ですか？リビジョン712がバージョン1リリースであったことに注意してください。

私の混乱は、タグが決して変更されることのないバージョンのように見えることだと思います。ただし、ソース管理とは、ファイルの変更履歴を保持することです。これは小さな組織的な議論であることは知っていますが、人々がどう思うか興味があります。

私は多くのバグ修正と、いくつかの異なる顧客向けの新機能の実装を行っています。これらの顧客はすべて、バグ、変更要求、新機能要求をTrac システムに報告します。これらの要求により、SQL 変更スクリプトを作成することになる場合もあれば、テストデータを含む Excel ドキュメントや Access データベース、顧客からの Word ドキュメントなどがある場合もあります。1 つのチケットを修正するために使用され、チケットがクローズされたときに削除できる大量のファイル。

私は通常、ファイルシステムに /customerXX/TicketNNNNN のようなフォルダーを作成し、そこにすべてをダンプすることでこれを行います。

作業ファイルをどのように整理していますか? これを行うための素晴らしいツールを見つけましたか?

ディスク上の Visual Studio プロジェクトの物理レイアウトを管理する最良の方法は何ですか? いくつかのフォルダーができるようになりましたが、今のように分類し続けることはできません。たとえば、いくつかのカスタム コントロールがありますが、それらのコントロールがアプリケーションの設定に関係している場合があります。その場合、それらのコントロールは Controls フォルダーまたは Application Settings フォルダーに移動しますか? メインのソース フォルダに本格的なフォームが多数あるため、適切なソース ファイルを探すのが少し難しくなっています。

中規模のプロジェクトをフォルダー階層に整理して、プロジェクト内で何かを見つけようとして気が狂わないようにする方法について、誰かが提供できるヒントはありますか?

何百ものプロジェクトがある場合、どのようにプロジェクトを整理しますか? プロジェクト内のレイアウトではなく、プロジェクトのルート ディレクトリのレイアウト。

私は、複数のシステムのディスク全体に散らばっている 10 年以上の個人プロジェクトとサンプル プロジェクトを統合しており、12 ほどのアクティブなプロジェクトを常に表示し、アーカイブされたプロジェクトを見つけられるようにするための整理方法を探しています。

ほとんどのプロジェクトは学習実験であり、さまざまな言語やフレームワークを横断しています。プロジェクトの中には、アイデアやコードを再利用するために手を差し伸べる本格的な実用的なアプリケーションもあります。

私は個人的なもののためにリモート git リポジトリでフラットな名前空間を使用していますが、それは私の開発システムで物事を整理する理想的な方法とは言えません。~/active/ や ~/archive/ よりも優れたものがあるはずです。

この状況で何がうまくいきますか？

私の会社でまったく同じテーブルを結合するために同じクエリを作成するのに何時間かかったかについても考えたくありません。

私が最初に仕事を始めたとき、これは非効率であると認識し、開発者の便宜のためだけに別のスキーマでビューを書き始めました。
上司はこれをあまり気に入らなかったので、本番SQLとは別のフォルダーにあるソース管理に一般的なクエリをコミットし始めることをお勧めしました。一部のスクリプトにはパラメーターが必要であり、すべてが読み取り専用であるとは限らないため、これは理にかなっています。

一般的なクエリとは何ですか？

• 特定の問題を診断するために使用されるスクリプト
• 複数のテーブル間の関係を表示するスクリプト（複数の結合を実行）
• その日の問題を診断するために調整されることが多いため、ストアドプロシージャに不要なスクリプト

対処したい問題

• 発見可能性、誰も見つけられない場合、クエリは書き直されます
• IDE統合、IDEでクエリを簡単に表示できるようにする必要があります。私はSQLServerソリューションを試しましたが、そのファイルのセットでのみ作業するようにロックされているため、本当にひどいです。

そこにいるすべてのプロが共通のSQLクエリをどのように共有しているのか疑問に思いました。

ありがとう

Java プロジェクトの標準的なディレクトリ レイアウトはありますか? どのレイアウトが一番好きですか?

プロジェクトのディレクトリ内の 'src' と 'bin' よりも複雑なレイアウトについて質問しています (つまり、テスト クラスやビルド構成などをどこに配置しますか?)。

前もって感謝します。