Начало / Половинка / Разни картинки / Разни връзки / За мен / About me / RSS емисия
 

 

Записки Разни

 

Studley tool chest 

 

списък https://www.flickr.com/photos/georgelazenby/5454202560/in/photostream/

(кой знае защо отбелязано като съдържание за възрастни) 

 
/2.6.2017, 14:10/ 

мислех, че веселото знаме с дъгата завинаги е отвлечено от гей движението, но се оказа, че не е съвсем така; гей знамето е незначително различно от нормалната дъга, но все пак е различно.

обикновената дъга се рисува със 7 цвята, а гейската - с 6 цвята.

 
преименуване на git commits 

да не забравя:

първи начин

За да преименувам последния гит камит и да се редактира текста му ползвам това:

git commit --amend -c HEAD #предлага за редакция последния камит с текста му

или за да редактирам най-горния камит текст и да се вземе текст от точно определен друг камит:

git commit --amend -c 9e8e019d9ab041d5b35bcdd0987ed63b783d73d0

Важно! при промяната на текста се променя самия камит, тоест се променя неговия хеш.

втори начин - за разбиране на нещата, с използване на git command line

За промяна на предишни текстове на камити процеса става сложен и трябва да се мине през rebase:

git rebase -i HEAD~4 #редактирай последните 4 камита с интерактивен рибейз (-i)

При тази команда гита изкарва редактора (default: vi) и пита какво трябва да ги прави тези камити. Там където трябва да се редактира текста сменяме думата "pick" с думата "reword". след това се записват така заявените команди с ":wq" (за vi)

При :wq vi завършва изпълнението си и предава управлението обратно към гита. Гит вижда, че искаме да reword-нем някои камити. За всеки един от тях гит отново пуска текстовия редактор и вече можем да зададем новите им текстове. (тоест ако сменим всички pick с reword ще видим още 4 пъти редактора, за всеки един камит поотделнo)

Всички тези операции променят хешовете и става еднаа.. Става една такава, че дървото с камилите вече е коренно различно от предното. Ако предното дърво е пушнато към римоута трябва да се форс-пушне отново, като така се затърква предното:

git push --force <бранч_с_преименувания>

Ако римоута вече е бил изтеглян от други хора, които са си правили камити върху него става много гадно. губи се чужда работа и т.н., така че ако е правен пуш... просто не се прави форс-пуш. Не си заслужава усилието.

(любопитна особеност е, че не може да се промени името на първия камит в дървото, защото преди него няма друг, върху който той да се рибейзне.)

по темата

трети начин - практичен и удобен, с помощта на SourceTree

  • сташваме или комитваме, не трябва да има uncommited промени по working tree.
  • проверяваме на кой бранч сме - трябва да сме на същия, на който ще поправяме текста.
  • цъка се с дясното копче на мишката на предшественика на камита, който трябва да се редактира и се избира "rebase children of <hash> interactively...".
    • появява се нов екран, в чиято горна част са изброени камитите, деца на цъкнатия с мишката (внимание, това работи само с камити на текущия бранч).
  • цъка се на желания камит, на който трябва да сменим текста.
  • цъкаме на копчето "Edit Message" и въвеждаме новия текст
  • повтаряме за всички камити, които искаме да редактираме.
  • цъкаме ОК в джама.
  • тадаа... гита свършва същото онова, което е описано в начин 2 по-горе и променя текстове и хешове.
 
/25.5.2017, 14:27/ 

"бащицата" путин може да е безскрупулен агресор, но чак такъв глупак не е. Че кирилицата била дошла от македонската земя - това е добре премерено изказване - той не казва, че идва от Македония, а от македонската земя, която тогава е била в територията на България. Така хем е фактологично прав, хем няма да спомене името "България", защото всяко признаване, че ни дължат нещо ще им развали кулата от карти. И в същото време се заиграва с македонците, които с удоволствие ще клъвнат всяка стръв, която е свързана с легализиране на измислената им история.

 
Sql Server Deadlock Example 

declare @i int = 1

while @i<500

begin

   begin tran 
      --SET TRANSACTION ISOLATION LEVEL  repeatable read <--whatever!!!
/*1*/       update accounts set [AccountBalance]=AccountBalance + 0.01 
/*2*/       update invoices set amountdue = amountdue + 0.01
   commit

   set @i = @i + 1

end

 

declare @i int = 1

while @i<500

begin

   begin tran 
      --SET TRANSACTION ISOLATION LEVEL  repeatable read <--whatever!!!
/*2*/   update invoices set amountdue = amountdue + 0.01 
/*1*/   update accounts set [AccountBalance]=AccountBalance + 0.01    

   commit

   set @i = @i + 1

end

 

 these two scripts ran by two different connections cause sql deadlock error like this:

Transaction (Process ID 55) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

the one transaction is executed ok, the other transaction is rolled back and needs to be rerun.

this error is inevitable and in my tests cannot be remedied by chosing the "right" isolation level although the docs clearly says that this error is result from using shared locks. i thought that using isolation level with no shared locks would prevent it. but it still occurs. why?

2017-05-25: somebody else also needed sql server deadlock demonstration, here it is on stackoverflow.

2017-05-26: the best solution is to be reordered the operations and in this manner this classic deadlock would never happen. Still if some other software out of our control works with the tables in the wrong order it would cause deadlock after all. This is why in such case the handling of this deadlock exception is mandatory.