問題タブ [commit]

-編集-気にしないでください、私は私の選択ステートメントを間違えました。アップデートは正しく機能していました。

理由はわかりませんが、sqliteDBが更新されていません。このクエリは、影響を受けるテーブルに対して1を返すことがわかりますが、アプリを閉じるか、特定のselectステートメントを実行すると、この更新が行われなかったかのようになります。2ノート。1）挿入は正常に機能します。2）コードにトランザクションはありません。

現在、git svn dcommitgit を実行すると、前回の SVN との同期以降に行ったすべてのローカル コミットに対して、SVN に個別のコミットが作成されます。dcommit代わりに、最近のすべてのローカル コミットを SVN の 1 つのコミットに結合する方法はありますか?

夜間に SVN リポジトリにいくつかのファイルをバックアップするスクリプトを作成する必要があります。ファイルは安全であるため、ユーザー名 (それは可能ですか?) またはパスワードを入力せずにコミットできます。

私が思いついた可能な解決策: -パスワードなしまたは既知のパスワードを使用してダミーユーザーを作成しますが、これはセキュリティ上の問題を引き起こします (誰かがそれを読んで、好きなものをコミットするために使用できます) -パスワードを隠して渡すスクリプトを作成しますsvn コマンドに。

ありがとうございました

ファイル間で情報を移動するときに、VCS がひどいマージを行っているため、作業中のプロジェクトに大混乱が生じています。

したがって、シナリオは次のとおりです。

たとえば、辞書の用語に関する情報を含むファイルがたくさんあるので、アルファベットの各文字のファイルがあります。

用語を入力するユーザーはやみくもに辞書の順序に従います。そのため、たまたま辞書にリストされていた場合は、B の下に「バケツを蹴る」などのエントリを配置します (または、B のバケツと K のキックの両方にリストされていた可能性があります)。 .

後で、他のユーザーが用語を正しいファイルに移動します。辞書用語に関しては、常に多くの作業が行われています。

たとえば、ユーザー A は B ファイルを取得し、「バケツを蹴る」エントリについて詳しく説明した可能性があります。ユーザー B は B ファイルと K ファイルを取得し、「kick the bucket」エントリを K ファイルに移動しました。最終的にどの順序でコミットされても、VCS はおそらくエントリを失い、エントリが移動されたことを「認識」しません。

(これらのエントリは、後で自動的に SQL データベースに変換されます。しかし、それらは、多くのコメントや例などとともに、"人間に優しい" 形式で作業できるように保持されます。したがって、「ユーザーに直接 SQL を入力させる」ということは受け入れられません。 ".)

VCS を信頼できないため、これらの種類のファイルをほとんど手動でマージするようになったのは非常に残念です。:(

それで、解決策は何ですか？これに対処できる VCS があることを知りたいです。またはより良いマージアルゴリズム? または、誰かがこの問題を回避するためのより良いワークフローまたはファイル配置を提案できますか?

以前のコミットを誤って修正しました。特定のファイルに加えた変更の履歴を保持するために、コミットは分離されている必要があります。

その最後のコミットを元に戻す方法はありますか？のようなことをgit reset --hard HEAD^すると、最初のコミットも取り消されます。

（私はまだリモートディレクトリにプッシュしていません）

次のような git リポジトリがあります。

ブランチのヘッドが A を指すようにします。つまり、B、C、D、および HEAD を消し、ヘッドを A と同義にしたいのです。

リベースを試みるか (その間に変更をプッシュしたため、適用されません)、元に戻すことができるようです。しかし、複数のコミットを元に戻すにはどうすればよいでしょうか? 一度に 1 つずつ元に戻しますか? 順番は重要ですか？

私は、VMWareFusion仮想マシンの一部としてMacBookとUbuntuServerを搭載しています。ローカルディスク（Mac）でGITを使用すると、すべてが完全に機能しますが、ボリュームでgitを使用しようとすると、問題が発生します。

たとえば、/ Volumes / vm1/webfolderは私のローカルの.gitリポジトリです。私が次のようなクローンを作成する場合

次に、次のような変更を確認します

すべてのファイルが異なり、更新が必要です。何が問題ですか？参考までに...Windowsで共有VMWareフォルダを使用した場合と同じ効果があります。権限の問題やユーザー所有者の問題はありますか？

それを修正しますか？どうも！

ここ StackOverflow には別のスレッドがあり、ソース管理への変更をコミットする頻度を扱っています。これを、git や mercurial などの DVCS を使用するコンテキストに入れたいと思います。

1. どのくらいの頻度で、いつコミットしますか?

2. 正しくビルドされた場合にのみ変更をコミットしますか?

3. 変更をプッシュする (またはプル リクエストなどを提出する) 頻度と時期は?

4. 複雑な機能を開発したり、多くの場所に手を加える必要がある複雑なリファクタリングを行ったりするには、どのようにアプローチしますか? ビルドしない「プライベートコミット」は大丈夫ですか? 完了したら、それらをマスター リポジトリにもプッシュしますか、それとも、プッシュする前にすべての変更を 1 つの変更セットにバンドルしますか?

現在、一連のレコードを挿入するために使用しているプロセスは次のようなものです。

(「一連のレコード」とは、個人のレコードと住所、電話番号、またはその他の結合されたテーブルのようなものを意味することに注意してください)。

1. 取引を開始します。
2. 関連する一連のレコードを挿入します。
3. すべてが成功した場合はコミットし、そうでない場合はロールバックします。
4. 次の一連のレコードについては、手順 1 に戻ります。

このようなことをもっとすべきでしょうか？

1. スクリプトの先頭でトランザクションを開始します
2. レコードのセットごとにセーブ ポイントを開始します。
3. 関連レコードのセットを挿入します。
4. エラーが発生した場合はセーブポイントにロールバックし、すべてが成功した場合は続行します。
5. スクリプトの先頭でトランザクションをコミットします。

ORA-01555 でいくつかの問題が発生し、Ask Tom の記事 (この記事など) をいくつか読んだ後、2 番目のプロセスを試してみることを考えています。もちろん、Tom が指摘するように、新しいトランザクションの開始は、ビジネス ニーズによって定義されるべきものです。2 番目のプロセスは試してみる価値がありますか、それとも悪い考えですか?

Active Directory情報を照会し、メモリに保持されているデータテーブルに約15個のプロパティを格納するアプリケーションを開発しました。

取っておいた「コミット」メモリの量を減らす必要があります。

アプリケーションはシステムトレイでアクティブなままであり、ユーザーの写真とともに情報をすばやく検索できます。

私は、メモリ使用量をかなり低く抑えることができるクラスを持っています。10秒ごとにタイマーで実行され、以下にリストされています。

アプリケーションがロードされると、タスクマネージャーは次のように表示されます。

ワーキングセット（メモリ）-30,000K
メモリ（プライベートワーキングセット）-13,000K
コミットサイズ-25,000K

数秒後、メモリ管理クラスはメモリ使用量を次のように減らします。

ワーキングセット（メモリ） -700K
メモリ（プライベートワーキングセット）
-600Kコミットサイズ-25,000K

私が気づいたことの1つは、コミットサイズが決して下がらず、実際には数日にわたって（非常にゆっくりと）成長し続けるということです。2日後、コミットサイズで最大36,000Kになりました。

これで、disposeメソッドを許可するすべてのオブジェクトを破棄し、他のオブジェクトを=nothingに設定することにかなり前向きになりました。

タスクマネージャーを見ると、他のアプリケーションにはコミットサイズのフットプリントがそれほど大きくありません。

アプリケーションが取っておいたコミットサイズをさらに調整する方法について何かアイデアはありますか？

編集：

以下の提案に従って、CLRプロファイラーからの情報の一部を以下に含めました。

CSIDir.exeの概要
割り当てられたバイト：15,097,943再配置された
バイト：3,680,460
最終ヒープバイト： 1,612,611最終化され
たオブジェクト：16,194最終化
された重要なオブジェクト：148
Gen 0コレクション：19
Gen 1コレクション：17
Gen 2コレクション：16
誘導コレクション： 16Gen0
ヒープバイト：769,019
Gen 1ヒープバイト：156,141
Gen 2ヒープバイト：947,492
ラージオブジェクトヒープバイト：40,706
作成されたハンドル：4,664
破壊されたハンドル：4,386
存続しているハンドル：278
ヒープダンプ：1
コメント：0