Chtel bych udelat ve wpf itemscontrol (listbox/listview/je mi to fuk), kterej by pri oznaceni polozky zobrazil jeji detail primo v tom seznamu polozek (viz priloha).
Idealni by byl asi nejak upravenej wrap_panel. Mam se snazit nejak priohnout wrappanel a nebo si mam rovnou udelat nejakej vlastni panel? Nebo uz neco takovyho existuje?

TENCOKACISTROMY: nastin workflow viz email http://article.gmane.org/gmane.comp.version-control.mercurial.general/32583/match= , dole.

NECROMAN: Tak normalne referencuj tu assembly X.
Ta hierarchie je:

soubor
+-> assemblies
   +-> modules
      +-> types

Takze by ti melo stacit nareferencovat patricny soubor *.dll/*.exe a ziskas tim vsechny ty assembly.

JANFROG: No, napriklad moje IDE, kdyz presouvam soubor mezi jednotlivymi projekty (*.dll/*.exe), tak je odmita presunout, ale kopiruje je. Takze v tom mi moje IDE nepomuze (uznavam, ze za to muze IDE).

Delame maly commity, takze se stava velice zridka (cili obcas se to stava), ze by se zmenil zasadne obsah nebo nazev/umisteni souboru.

Kdyz to porovnam se SVN nebo se starickym SourceSafem (kterej, mel nejaky jiny vychytavky), tak mi to prijde porad ziskovy.

Ale prave me zajimal ta workflow, protoze jednou jsem nasazoval version-control ve firme, ktera neprogramovala a jejich soubory byly z 99,99% binarni. Tam napriklad to "rucni" sledovani zmen nazvu souboru dava absolutni smysl.

Tak vyreseno pomoci 'extern alias' syntaxe, kterou jsou vubec poprve pouzil
http://www.davidarno.org/c-howtos/aliases-overcoming-name-conflicts-part-2-extern-alias/

dotaz, kdyz mam windows phone projekt a potrebuji v nem pouzit jednu externi knihovnu X a take Json.NET knihovnu. Problem je, ze X ma uz v sobe namergovanou knihovnu Json.NET. Da se nejak globalne nastavit, aby vsechny reference a Json.NET sli do separatni knihovny a ne do te v X?
Pouzit pouze X nemuzeme, protoze potrebujeme deserializovat Json data i v background agentovi a X obsahuje API, kvuli kteremu nemuze byt pouzita v background agentovi.

TENCOKACISTROMY: Co se tyce prejmenovani tak problemy byly dva na nasi codebase: 1) chvili to trvalo (20 a neco let commitu :-) 2) melo to dost velkou chybovost, proste to nepoznal.
99% vyvoje delame v IDE, takze ide se postara aby udelalo svn/hg rename.

Ne ze by se bez toho nedalo zit, ale kdyz uz investuji cas do implementace neceho noveho, tak at to umi vsechno a rychle. Navic to nebyl jediny problem, jak jsem jiz rikal.

JACHYMKO: Mercuyrialu to bud reknes nebo mu reknes "zkus hadat". Informace o renamu (at jiz explictne dana nebo uhadnuta) je ulozena....

JANFROG: Pokud v jednom commitu nějaký soubor zmizí a současně se na jiné cestě objeví soubor se zcela (či téměř) identickým obsahem, tak je to vcelku jednoduchý „odhad“, že se ten soubor přesunul/přejmenoval… Oproti tomu, jak jsem říkal, svn přejmenovávat neumí, což zase může být pro někoho jiného show-stopper. Každopádně, jak říkám, doporučil bych rozhodovat se primárně podle užívaného workflow.

JANFROG: Ja teda nevidim zasadni rozdil mezi chytrym hadanim a hloupym prejmenovanim od uzivatele (vyvojare). Vysledky budou dost podobny.
Co v procesu vyvoje vam tak zalezi na tom exaktnim trackovani presunu? (nereju, jsem zvedavej)

BUTHRAKAUR: Ne, on to nevi, o to hada, a to je (alespon pro me) dost rozdil. V nasem pripade je to show-stopper. A to neni jediny problem na ktery jsem narazil.

NECROMAN: My pouzivame IM. Nerusime tak ostatni :). Pripadne muzes pouzis datum/cas.

MORMEGIL: Ja to mam stejne. Obcas delam pro nekoho externe. Stahnu si SVN verzi, u sebe verzuju v gitu a pak to commituju do SVN.

JANFROG: se pletes - trackovat renames git rozhodne umi. Akorat mu to explicitne nerikas, ale on to proste pozna sam na zaklade svych heuristik. V historii mu potom jen reknes, jestli ti ma ty renames ukazovat nebo ne viz MORMEGIL, resp. napr "Follow Renames" checkboxem v Tortoise apod GUI.

Jinak mne se jeste osvedcil do VS Git Source Control Provider, kterej umi i integrovat Tortoise, takze na nejaky rychly operace z VS je to celkem idealni. Pouzivam to v kombinaci s obohacenym powershellem z github for windows a aktualne i git-tfs a nic mi nechybi :)

u nas se jede ted obe, ze si v podstate clovek muze vybrat, ja zatim zustavam u svn. do gitu se mi nechce

JANFROG: mas pravdu s tim svn, ale chapu ze nej lidi utikaji, kolik prace uz mi zmizelo spatnym mergem...

NECROMAN: Wut? Subversion to ve skutečnosti neumí, simuluje to pomocí Delete + Add s „falšováním“ historie (což není totéž). A nevím, co to znamená „neumí tracovat“.
git log --follow

Velke zjisteni, Git neumi tracovat zmeny souboru, pokud je prejmenujete nebo presunete. Cekal bych, ze tuto zakladnai ficuru Subversion bude "nejpouzivanejsi" version control zvladat levou zadni.

JACHYMKO: ten githubovy klient ale asi umi pracovat jen s repository na githubu, ne? Jinak ten jsem zkousel a je docela blbuvzdorny.
Ten Git klient od Microsoftu zatim zkouset nebudu, nerad bych si podelal prostredi CTP verzi toho Update 2