Miért fogok előbb meghalni?

Mert rákényszerültem a Microsoft Visual Studio-ra, ahol autobackup, manuális mentegetések mit sem érnek, egy nap munka után elszállt a görény, és vitt mindent. A backup mappák, a projekt mappák, temp mappák, stb. mind-mind üresek. Mintha mindig is üresek lettek volna. Egy napi munka odalett.
Birka leszek, beee-beee, újra begépelem, mert nincs más megoldás (recovery, undelete se segített).

Csendesen kérdezem: ha mindez nem Windows alatt történik, mekkora flémelés lenne belőle?

( asch v | 2015. 02. 24., k – 17:40 )

Másodszorra minden egy kicsit jobb lesz, mint elsőre volt. Én hiszek a WDWA módszer mindenhatóságában (Write, Delete, Write Again!).

Elrontom a
mindent,
minden egész
eltörött.
Halott-linket
nem hívhatok
újra-életre.

nyolcvankilenc óta: Hello World!

„Hát, eddig egyszer sem sikerült…”

Azóta is újraírom, hát. Mindig a nyakába vettetem a tarisznyát.

hüphup

Önöknek pedig semmi keresnivalójuk nincs itt.
exeunt

( log69 | 2015. 02. 24., k – 17:59 )

Részvétem. Azért van valami sejtésed hogy tényleges mi okozhatta ezt?

Hat, a backup-rol nekem nem az jut eloszor eszembe hogy ugyanabba a projektkonyvtarba tolok egy zippelt archivumot a forrasfa egy reszerol, ahol a projekt tobbi resze is talalhato. Igy nyilvan megy a levesbe az egesz, backupostol, ha a projektfa eleje se'ru"l. Max snapshotting-nak lehetne hivni ezt a featura't, de a backup azert minden, csak nem ez.

Lehetni lehet - csak vagy nem illik, vagy nem hatekony, vagy nem segit.

Vegyuk sorra:

- Elosztott verziokezelok eseten ugye nem segit az, ha lokalisan becommitolod a kodot, hiszen az meg mindig csak lokalisan lesz meg, ugyanugy ki van teve torlesnek/lemezhibanak a lokalis gepedben.
- Erre az a megoldas, hogy pusholjuk fel a szerverre, nem elosztott SCM-eknel ugye ez a sima commit. Ekkor ket dolog miatt nem lehet ez jo: a) raugrik a CI teljes mertekben feleslegesen es b) ha vmiert nincs sajat branched/repod/whatever, akkor ezzel mas munkajat szennyezed egy olyan koddal, ami jo esellyel error-prone. Igen, az az ajanlas, hogy legyen, de ezzel barmely $RANDOM ceges policy szabadon szembemehet, fuggetlenul attol, hogy ez mekkora ostobasag. Kerlek, hogy ezt az agat (miert nincs) ne boncolgassuk.

Egyebkent szerintem a felkesz kod mast jelent neked mint nekem. En a kodot es a feature-t kulon kezelem, vagyis a felkesz kod nalam azt jelenti, hogy SyntaxError-t/NoMethodError-t dobalhat, mert meg egyszer sem vagy legfeljebb egyszer futott le a kod. Az, hogy feature szempontjabol a kod kesz van-e vagy nincs, az szamomra irrelevans a commitolasnal, a fontos az, hogy ne fordulhasson elo olyan eset, hogy felcommitolok egy olyan allapotu kodot, ami miatt az app keptelen peldaul felbootolni, mert szintaxishiba vagy valami korai inicializalasi hiba van benne, ezzel hasznalhatatlanna teve az egesz alkalmazast, webalkalmazas eseteben pedig az epp commitolas alatt levo statikoknak nem szabad eltorni az egesz oldal designjat.
--
Blog | @hron84
Üzemeltető macik

"b) ha vmiert nincs sajat branched/repod/whatever, akkor ezzel mas munkajat szennyezed egy olyan koddal"

Akkor rossz a folyamat. Tapasztalataim szerint, ha nem feature branchba fejlesztesz aminek a vege egy mergeles, abbol csak az van, hogy elobb-utobb valai elbasz valamit akaratlanul is. Es mindegy, hogy SVN vagy GIT.

Amugy meg mit csinalsz, ha mondjuk felkesz kodot at kell adni egy masik kolleganak, mert mondjuk ido hianyaban o viszi tovabb?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Van, hogy két gép között ingázok, attól függően, hogy hol vagyok. Pl. laposon írok valami kódot, van neki egy branch. Pusholom, majd hazaérve a desktopon pull és folytatom tovább. A titka az egésznek, hogy branchbe dolgozok, így a kutyát nem érdekli, mit dobálok bele.

Amig nincs egy komplett folyamatrendszer kotve a branchedre, nagyjabol azt csinalsz vele amit akarsz. De en nem szeretem, ha a CI feleslegesen raugrik egy olyan valtozasra, amibol szinte biztos, hogy SyntaxError-ral vagy valami hasonloan trivialis hibaval fog kilepni. Foleg azert, mert egy nagyobb projekt inicializalasa (tehat amig egyaltalan eljut a tesztelesig a szerencsetlen) nem tiz masodperc. A sajat kodjaim persze masok, ott vagy kezivezerelt CI van (meghuzom a kart es elindul a teszteles), vagy eleve csak a master/development brancheket figyelgetem.

De lattam mar az enyemnel nagyobb rendszereket, ahol mindenkinek az epp aktualis branchere volt CI/CD kotve, a sajat playgroundjaba instant ment a deployment is, ha a teszteles sikeres volt. Viszont ha egy hianyzo parameter miatt ez az egesz gepezet beindul, majd nekiall kiabalni, hogy hiba tortent, az csak felesleges pocsekolasa az eroforrasoknak.

Tudom, talan rosszul latom, talan nem kellene emiatt aggodnom. De en nem kommitolok fel olyan fajlt, ami legalabb alapveto ellenorzeseken (szintaxis pl.) nem megy at, mert ugy gondolom, hogy ez fontos.
--
Blog | @hron84
Üzemeltető macik

De egyáltalán miért akarna valaki szándékosan olyan rendszert, hogy _minden_ commit _minden_ branch-en triggerel egy komplett deploymentet/tesztet/akármit? :)

Ha ilyen mégis van a valóságban, az tervezési hiba, nem az SCM tehet róla, és nem is a fejlesztők, akik használják.

> De en nem kommitolok fel olyan fajlt, ami legalabb alapveto ellenorzeseken (szintaxis pl.) nem megy at

Ez oké, de a kérdés továbbra is áll: hol tárolod a félkész kódot? Hogy próbálsz ki dolgokat? (lásd a már leírt esetet: nem tudod, hogy egy adott megoldás fog-e működni) Hogy rollbackelsz? Adott esetben hogy dolgozol össze másokkal (review, igen, félkész kódon is lehet olyat)? Stb.

A felkesz koddal kapcsolatban nem akarom ismetelni magam, lsd ezt a kommentemet: http://hup.hu/node/138981#comment-1841379

Nyilvan a kiprobalaskor felrakom branchbe, rollbackelni meg a git feature-ivel szoktam. Itt tenyleg inkabb definicios problemat erzek - szamomra mast jelent a felkesz kod, mint neked. Nekem nem verzik a szivem felkommitolni egy felkesz feature-t, de igenis vigyazok arra, hogy legalabb szintaktikailag helyes legyen a kod, amit felkommitolok (pontosabban egy git hook vigyaz erre helyettem). Az, hogy a kod altal megvalositott algoritmus, metodus, megoldas, mukodik-e vagy sem, az szamomra nem kepezi a "felkesz kod" definiciojanak reszet, szamomra az tisztan a "felkesz feature" definiciojanak resze - es itt nem errol van szo. A kod maga szamomra utasitasok halmaza, az altala tanusitott viselkedes pedig a feature resze - de talan rosszul fogom fel a definiciokat.

Ami extra, az az, hogy webappoknal figyelek arra, hogy ha lehet, ne essen szet az oldal azert, mert felkommitoltam egy css-t/js-t, amit nem kellett volna.

--
Blog | @hron84
Üzemeltető macik

Az már viszont gáz, ha az én branchemből bárki bármit is élesbe merge-öl. Egy fejlesztői branchből se manuálisan, se folyamatrendszerből nem húzunk ki semmit, amíg nincs rányomva tag, vagy bármi jelzés, hogy itt a remekmű. Ezen kívül egy fejlesztői branchből első körben teszt ágba tolunk át bármit is és kizárólag azután mehet masterbe (nem beszélve arról, hogy fejlesztői branchez a fejlesztőnek és annak felettesének van hozzáférése). Ha ez nincs szétválasztva és szabadon húzható ki belőle bármi élesbe, akkor megette a fene az egész folyamatrendszert, mert szarul építette fel az, akinek a dolga volt.

Oke, let me reprhase it.

Ugye itt most arrol beszelgetunk, hogy az IDE megbolondult, es eltavolitotta a teljes projektkonyvtarat. De vegyunk egy egyszerubb peldat, mondjuk meghal a diszk alattad. Elosztott verziokezelo eseteben, ha nem pusholod fel a felkesz kodot, csak becommittolod, akkor megis mennyivel vagy elorebb? Mennyivel jobb neked az, hogy ott van gitben a felkesz kod, amikor a lokalis git repodhoz hozza nem fersz, a remote oldalon meg nincs semmi?
--
Blog | @hron84
Üzemeltető macik

Elobb mondtad, hogy repoba ne keruljon felkesz kod, akkor lokalis repoba miert kerulhetne?

Masik oldalrol: repoba miert is ne kerulhetne felkesz kod? Mi van, ha a felkesz kodra alapozva ki akarsz probalni valami mast, ami lehet, hogy nem fog bevallni es vissza kell majd terni - akar napokkal es commitokkal kesobb - arra a felkesz allapotra?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( rigidus | 2015. 02. 24., k – 19:17 )

En a helyedben betennek a Windows feladatutemezojebe egy szkriptet ami orankenti snapshotokat csinal egy kulon konyvtarba, esetleg egy masik gepre is.

Elottem szolo tanacsat is fontolora venem: SCM. Hozzadasz egy Git plugin-t a VS-hez es mar nyomhatod is. A VS2013-tol (vagy VS2010-tol?) mar integralva van.

Amugy en eleg gyakran dolgozom C#-ban MSVS-szel es nalam szerencsere meg egyszer se omlott igy ossze az elmult ~10 ev alatt. Legalabbis adatvesztes soha nem volt. Mondjuk en is szivesebben dolgozok pl MD 4-gyel Linuxon de az meg sajna annyira bugos meg hogy sokszor a kedvem is elmegy tole. Bar legalabb patchelni tudok rajta amikor van ra idom bibelodni vele.

Nekem azért naponta egyszer megadja magát a VS2010 aktívabb használat során valamelyik elcseszett plugin miatt (Pluginhalom nélkül ill, VS2013-mal nem volt gond). Viszont olyat, hogy vigye a gyári VS a teljes projekt könyvtárat, olyat még nem láttam.

Amúgy nem kell feladatütemező, ott a Volume Shadow Services, szvsz az is alkalmas ilyenre.

--

LOL @ MD. Néha használtam, mikor Unity3D-vel játszadoztam debugolásra, ill OSX alatt, hát... kössz nem. Bár az újabbak már nem annyira vészesek. (Viszont már az UnityVS-t felvásárolta az MS és ingyenessé tette, szóval már csak ezért se kellett legutóbb.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"SCM. Hozzadasz egy Git plugin-t a VS-hez es mar nyomhatod is."

Mar masodszorra olvasom, es masodszorra tunik baromsagnak. Valaki magyarazza mar el, mire gondolt a kolto. A verziokezelo rendszereknek es a backupnak semmi kozuk nincs egymashoz, egy napi munkat mindenfele verziokezelovel el lehet veszteni, mert joerzesu ember (foleg olyan helyen, ahol continuous integration van) nem kommittol be felkesz kodot sehova. Ha meg csak lokalis Git kommitot csinal, akkor meg ugyanott tart, ahol a part szakad.

Szoval nem latom, a jelenlegi probleman egy SCM hol segitene. Ha leirtanank a VS-t, na az peldaul segitene, de egy SCM...
--
Blog | @hron84
Üzemeltető macik

( deje | 2015. 02. 24., k – 21:08 )

Minden szoftver bugos, a VS nem különben. Mellesleg nem bugosabb, mint pl. egy sok pluginsos Eclipse, de mindegy. Sőt, néha az IDEA is nagyon felidegesít.

Először is: VERZIÓKEZELŐ. Ha nem használsz, rá fogsz faragni. Ja bocs, már megtörtént.
Másodszor: VERZIÓKEZELŐ.

Visual Studio-t szépen meg lehet etetni mindenféle SCM pluginekkel, én Git-et és Subversion-t használok, korábban TFS is volt (na annak voltak gondjai rendesen).

Harmadszor: nézz körbe a VS pluginek között (nuget), van ott bizony olyan, ami külön könyvtárba mentegeti neked a változásokat automatikusan, így tudsz undo-zni szemérmetlenül, szegény ember SCM-je.

Utoljára: szerintem nem a VS volt a hibás, ugyanis hogy minden temp mappát, projekt mappát, stb. letöröljön, na az számomra kissé furcsa. Mentettél egyáltalán akár egyszer is? Ha igen, akkor máshol van a baj, nem a Visual Studio-val.

Mondjuk megjegyzem, ha valami olyat fog ki, ami tényleg gyalul mindent (beleértve a .git-et is, akkor sokra nem megy addig, ameddig nem pushol szerverre.)

"ugyanis hogy minden temp mappát, projekt mappát, stb. letöröljön, na az számomra kissé furcsa."

Detto. Főleg, hogy egy méretesebb projektnél már csak a fájlok száma miatt se fél pillanat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Frantique v | 2015. 02. 24., k – 21:40 )

Tele a net ezzel a hibával, csak későn találtam rá. Mentés se segít, az automata mentés bugos. Verziókezelőt nem dogok betenni, mert moat használom először éa uroljára a VS-t. Amint kész a program, dobom is az egész virtuális gépet.
--
Coding for fun. ;)

( ironcat | 2015. 02. 25., sze – 12:44 )

Tipp a címben feltett kérdésre:
Mert előbb, vagy utóbb mindenki meghal, és Te egy nagyon türelmetlen ember vagy.

----- 

(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-

( mrceeka v | 2015. 02. 25., sze – 18:27 )

Javaslom, hogy használd a File History-t.
Nekem nagyon bevált és egyszerű mint a faék.

Üdv,
Marci

Alapértelmezés szerint óránként készít mentéseket.
Amikor a baj bekövetkezik, kinyitja a File Historyt, ott a Restore Personal Files alatt megtalálja az 1 órán belüli érvényes mentést, melyet visszatölt. Kicsit szomorú, mert majd' egy óra munkája elveszett. Viszont nem nagyon szomorú...

Üdv,
Marci

Any time your personal files change, there will be a copy stored on a dedicated, external storage device of your choice. File History continuously protects your personal files stored in libraries, desktop, favorites and contacts folders. It periodically (every hour by default) scans the file system for changes and copies changed files to another location. Over time, File History builds a complete history of the changes made to any personal file.

Bővebben: http://answers.microsoft.com/en-us/windows/forum/windows_8-files/window…

Üdv,
Marci

Nem az.
A File Historyval az általa végzett mentési időpontok bármelyikét kiválaszthatod és visszahozhatod az adott file, könyvtár vagy könyvtárhierarchia akkori állapotát. Ha új gépre állsz át, fel tudod csatlakoztatni a másik gép mentését, visszaállni az utolsó érvényes állapotra és folytatni a mentéseket. Ez a Windows 8-ban jelent meg.
Nálam per pillanat 3141 érvényes mentési pont van, amire visszaállhatok egy vagy sok file-lal.

Hasonlóságot számomra leginkább az Apple Time Machine-nal mutat (bár azt még működés közben nem láttam).

Bár ezeket üzemeltetőként valószínűleg nálam sokkal jobban ismered.

Üdv,
Marci

A Win8 meg csak most kezd elterjedni nalunk, egyelore csak egy-ket kiemelt user kerte a gepere, igy az uj funkcionalitasokat meg nem teszteltuk teljeskoruen.

Azon felul en elsosorban a Linuxos infrastrukturaelemek uzemeltetesevel foglalkozom, nem pedig a Windwosos rendszerekkel, ez utobbiakra nincs olyan szeleskoru ralatasom mint az ezzel foglalkozo kollegaknak. Vannak dolgok, amik szamomra is az ujdonsag erejevel hatnak, mivel en teljesen mas korben mozgok.
--
Blog | @hron84
Üzemeltető macik