このコマンドを実行するのに十分なクオータがありません
クオータ不足
PowerShell & WPFで頻発する。
WPFのコントロールはDisposeが不要との情報があるが、リファレンスカウント制御があるので、変数破棄or $null化が必要？
参考
http://www.powertheshell.com/wpfquota/
https://social.msdn.microsoft.com/Forums/ja-JP/5a0f5abe-aebc-4d4d-a681-b53c26e44547?forum=wpfja
Dispatcher memory leak
http://grabacr.net/archives/1851
https://msdn.microsoft.com/ja-jp/library/system.gc(v=vs.110).aspx
http://www.makcraft.com/blog/meditation/2012/07/06/it-is-a-command-of-wpf-and-is-a-memory-leak/
Dispatcherを使ってみた
http://d.hatena.ne.jp/hilapon/touch/20130225/1361779314
Dispatcher メモリリーク
http://grabacr.net/archives/1687
CPU、メモリ監視
git管理の注意点
git管理
gitを導入する理由には色々なものがあるが、導入時に決める事を整理する。
- ブランチモデル
- コミットコメント
- ブランチ間のマージルール
- git連携、自動テストなど
- その他ルール
ブランチモデル
master一本から、vincentモデルなど目的に合わせたモデル選択。既にgit運用しているのであれば、既存モデルと本プロジェクトの適合確認など。
コミットコメント
redmine連携や、決まり文句など環境と目的に合わせて書式を設定する。
マージルール
マージ派かリベース派か。事前申請か権限制か。
連携
jenkinsの自動試験やredmine連携など。
その他
文字コードや改行コード
ファイルやディレクトリ名 コンテントの文字コード 改行コード
取り消し、打ち消し
revertやresetの使い方。
.gitignoreなど
.gitignoreの使い方
困った時のpush -f 可否
やってはいけない事など。
参考
Vincentモデル
http://nvie.com/posts/a-successful-git-branching-model/
blog
https://techracho.bpsinc.jp/morimorihoge/2014_04_25/16856
git checkout
https://git-scm.com/docs/git-checkout
特定のファイルだけ取り出し
git-flow
gitのブランチ管理
何処かで聞いた4ブランチ管理
- master メインのリリースツリー
- hotfix リリース物件の修正パッチ用
- dev 開発用ブランチ
- release リリース試験用
もう一つあった様な
本題 git-flow
快適な平行開発を実現するためのブランチ活用案。
平行開発対象の種別
- hotfix
- release
- feature
各種別毎に複数ブランチ存在可。それぞれの開発が終われば、メインのmaster/developにマージし消滅するブランチ。
平行開発ブランチのマージ先
- hotfix -> 製品master
- release -> 製品master
- feature -> 開発develop
そして、実が熟して来たら、
develop -> release
整理すると5種類のブランチを使用する形態
master/developが永続ブランチ
hotfix/release/featureが事象駆動型の期間限定ブランチ。
- develop 開発用メインブランチ
- feature 機能開発用。 developから分岐し、developに戻り削除。
- release リリースに向けた作業。developから分岐し、master/developの二つのブランチにマージし削除。
- master 製品用メインブランチ releaseをマージし、tagを付ける。
- Hotfix masterから分岐し、masterにマージし消滅。
master、developが永続的ブランチ。
feature/release/hotfixが事象駆動型の期間限定ブランチ
git-flowの概念と課題
- gitの目指すもの
- gitの課題
- git-flowの方法 Vincent Driesseが提唱するブランチモデル
gitの目指すもの
快適な平行開発？
何が快適？
さて
もっと簡単にならないの？と思う場合、
- 案1. master一本
- hotfixが大変
- 案2. master+develop
- hotfix用はmasterを直接修正？ 製品リリース版とはtagで区別する？
- 開発破棄がrevertの嵐？
案2のmaster+developをベースに必要な時に必要なブランチを作成するのが良いのかも。
そもそもブランチは破棄される前提でモデルを検討すると良いかも。
始まり
リリース後に下記の分岐
- master -> dev
- master -> hotfix
あるいは、
master -> release, developに分岐 releaseで整理 -> master/devマージ
参考
Vincent model
http://nvie.com/posts/a-successful-git-branching-model/
http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html
ブランチモデル実績
https://havelog.ayumusato.com/develop/git/e513-git_branch_model.html
git revert
git revert
gitのコミット破棄機能
revert対象として考えられるのは、
- HEADコミット
- 中間コミット
HEADコミット
git revert HEAD
中間コミット
git revert コミット
さて
あってる？
参考
confirm させない方法 by powershell
confirm
システムに変更を加えるコマンド、例えばIPアドレス削除では、デフォルトでconfirm メッセージがでる。
これを止める方法は、
-confirm:$false
参考
https://blogs.msdn.microsoft.com/powershell/2006/12/14/confirmpreference/
