logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Atmel Studio i SVN - jak przenieść projekt na serwer?

Kudzu 04 Kwi 2017 23:00 1359 17
  • #1 16392760
    Kudzu
    Poziom 14  
    Postanowiłem przyglądnąć się systemowi kontroli wersji. Zainstalowałem zatem dodatek AnkhSVN w Atmel Studio 7 oraz uruchomiłem serwer SVN na Debianie (Apache Subversion).
    Niby wszystko działa, bo repozytorium jest widoczne w Atmel Studio, ale pojawia się pytanie:

    jak przenieść istniejący projekt z katalogu lokalnego do repozytorium?

    Gdzieś trafiłem na informację, że wystarczy skopiować projekt. W innym miejscu przeczytałem, że nie należy ręcznie modyfikować plików w repozytorium, bo można coś namieszać. Zresztą, mimo, że repozytorium jest puste (nie ma projektu), to są już tam jakieś katalogi.

    Proszę o pomoc.
  • #2 16392814
    grko
    Poziom 33  
    W svn działa to tak, że musisz sobie pobrać nowo utworzone repozytorium (svn checkout). Następnie trzeba dodać do repozytorium pliki, które chcesz umieścić na serwerze (svn add). Ostatnim krokiem będzie commit na repozytorium (svn commit). W ramach sprawdzenia możesz sobie ponownie wykonać svn checkout do innego katalogu. Na windowsa jest narzędzie, które pozwala dość łatwo wykonywać te operacje: TortoiseSVN.

    Na dzień dzisiejszy powinieneś się jednak zainteresować rozproszonym systemem kontroli wersji. Do wyboru masz Git oraz mercurial. Obsługuje się je w zasadzie tak samo z tym, że ten pierwszy jest bardziej popularny. Oba są dużo lepsze od svn.
  • #3 16394436
    tmf
    VIP Zasłużony dla elektroda
    @grko Tylko, że chyba nie ma wtyczki obsługującej git w Atmel Studio (Visual Studio). A z ciekawości - jaką przewagę ma git jeśli mam pojedynczego użytkownika i tylko używam systemu kontroli wersji do śledzenia zmian w kodzie?
  • #4 16394540
    grko
    Poziom 33  
    Podejrzewam, że nie trudno o wtyczkę do git do Visual Studio. Według mnie Git ma co najmniej kilkadziesiąt zalet w stosunku do SVN. Kilka z nich:
    1. Jest szybszy bo mam na dysku całe repozytorium.
    2. Mogę pracować offline (klon całego repozytorium jest u Ciebie na dysku).
    3. Mogę mieć repozytoria w wielu miejscach jednocześnie (github, sf, bitbucket /home/gko/repo itd) i nie jest to upierdliwe w obsłudze.
    4. Niesamowity command line interface. W zasadzie nie trzeba żadnych pluginów/gui do obsługi.
    5. Z repozytorium możesz zrobić w zasazie wszystko (rebase, squash, cherry-pick itd...). Przydaje się to choćby w poprawieniu literówki w commit message.
    6. Łatwiejsze mergowanie. Obsługuje 2 strategie mergowania (merge lub rebase). Łatwiej utrzymać czystą historię repozytorium.
    7. git bisect: przydaje się przy szukaniu błędów. Niby pierdoła ale w svn to trzeba robić ręcznie.
    8. Po co się uczyć SVN, który już w zasadzie nie jest już szeroko używany?

    Możesz się oczywiści upierać, że SVN wystarczy gdy się samemu pisze projekt. Może i masz rację. Jednak gita warto się nauczyć choćby dlatego aby zobaczyć jaki to wspaniały kawałek oprogramowania. Praca z nim to czysta przyjemność :)
  • #5 16394628
    tmf
    VIP Zasłużony dla elektroda
    @grko Nie upieram się, że coś jest lepsze, po prostu pytam. Jak dla mnie dobry system wersjonowania to taki, który jest transparentny i nie muszę się go uczyć. Z punktów, które wymieniłeś 1 i 2 w SVN mam, 4 - po to mam integrację z IDE, 5 i 7 naciągane, 6 w jednoosobowym zespole rzadko używane. BTW, widzę, że jednak wtyczka git do Atmel Studio jest. Wiele hostingów udostępnia zmianę interfejsu svn/git w locie, więc nie ma problemu. Ale z tego co piszesz widzę, że decyzja svn/git w jednoosobowym zespole to głównie kwestia wyznawanej religii :)
  • #6 16394673
    grko
    Poziom 33  
    Cytat:

    Z punktów, które wymieniłeś 1 i 2 w SVN mam


    Czyli masz serwer u siebie na dysku. Daj znać co z twoimi projektami jak dysk padnie.

    Cytat:

    4 - po to mam integrację z IDE

    Też mam. Tylko moj command line do tego fajniejszy.


    Cytat:

    5 i 7 naciągane


    Widzisz, ja lubię mieć czystą historie repo (bez literówek i zbędnych rzeczy). Po prostu pomaga mi to w pracy. Co do samej opcji bisect to przez 6 lat pracy z SVN spędziłem dziesiątki godzin (jak nie setki) właśnie na checkoutowaniu kolejnych rewizji oprogramowania (przy szukaniu błędów). Musiałem to robić ręczne i zapisywać sobie rewizje gdzieś na boku. W gicie masz to za darmo wbudowane.


    Cytat:
    Ale z tego co piszesz widzę, że decyzja svn/git w jednoosobowym zespole to głównie kwestia wyznawanej religii :)


    To samo mógłbym powiedzieć odnośnie Twoich postów dotyczących AVR vs ARM, Atmel Studio vs Eclipse;) Najwidoczniej uznajesz tylko jeden zestaw narzędzi za słuszny. Ja przynajmniej podałem alternatywę w postaci mercuriala, który według mnie jest gorszy od gita to i tak jest dużo lepszy od svn.
  • #7 16394741
    Kudzu
    Poziom 14  
    Wtrącę się z pytaniem:
    repozytoria którego systemu archiwizuje się łatwiej?
    Bo wygla na to, że gita też mogę postawić na swoim serwerze i będzie mi obojętne z którego z nich skorzystam. Będę musiał jednak co jakiś czas robić backupy.
  • #8 16395434
    tmf
    VIP Zasłużony dla elektroda
    @grko Myślę, że nie rozumiesz problemu. Zacznijmy od tego, że narzędzie zmieniam wtedy, gdy nowe narzędzie jest dla mnie istotnie lepsze niż dotychczas używane. Czyli dodaje mi funkcjonalności lub możliwości, które umożliwiają mi zrobienie rzeczy, które do tej pory były niemożliwe do zrobienia, lub ich robienie było nadmiernie uciążliwe. Nie zmieniam narzędzi bo nowe ma lepszy kolor, abo bajery, z których nie korzystam. Dlatego zadałem ci pytanie o przewagi git, żeby dowiedzieć się, czy nie oferuje czegoś co potencjalnie może mi ułatwić życie. Ponieważ wśród argumentów jakie wymieniłeś nie znalazłem argumentów istotnych dla mnie, więc nie jestem przekonany do konieczności zmian. Więc nie przechodź na dyskusję religijną. Z drugiej strony zamiana svn na git to jeden checkbox w konfigu repo i zmiana w Atmel Studio jednego pluginu na drugi, więc można to zrobić w każdej chwili.
    Zawsze pracuje się na lokalnej kopii repozytorium, więc w tym sensie jest ono dostępne w offline. Więc nie wiem o co ci chodzi z punktem nr 2. Co do punktu 1 - nie wiem na jakich projektach pracujesz, ale commit w SVN zajmuje ułamki sekundy do sekund, w zależności od połączenia z serwerem. Nie ma dla mnie znaczenia czy to będą 3 sekundy, czy 0,3 sekundy. Nie podnieca mnie też to, że twój command line jest ładniejszy niż mój :) To czego oczekuję to w miarę transparentnej integracji systemu wersjonowania z IDE. Powiem więcej, do tego stopnia mnie to wszystko nie podnieca, że najchętniej niechciałbym wiedzieć, czy za tym stoi git, svn, cvs, czy cokolwiek innego.
    @Kudzu Nie wiem jak git, ale w svn po prostu wydajesz polecenie zrobienia backupu i tyle. W git zapewne jest podobnie. Z drugiej strony jeśli robisz normalny backup servera to też ci się zbackupuje repozytorium.
  • #9 16395704
    grko
    Poziom 33  
    tmf napisał:
    Zawsze pracuje się na lokalnej kopii repozytorium, więc w tym sensie jest ono dostępne w offline. Więc nie wiem o co ci chodzi z punktem nr 2.


    Chodzi o to, że możesz commitować, tworzyć branche i przeglądać historię itd__offline__. Jest to możliwe dzięki temu, że posiadasz pełną kopię repozytorium u siebie na dysku. Jeżeli wydaje Ci się, że masz to samo w svn (skoro piszesz, że pracujesz na kopii) to jesteś w błędzie.

    Cytat:
    Co do punktu 1 - nie wiem na jakich projektach pracujesz, ale commit w SVN zajmuje ułamki sekundy do sekund, w zależności od połączenia z serwerem.


    Seriously? Korzystałeś kiedykolwiek z gita masz jakieś porównanie? Może jak się robi 1 commita na tydzień to nie ma to specjalnego znaczenia.

    Cytat:
    To czego oczekuję to w miarę transparentnej integracji systemu wersjonowania z IDE.


    No to przecież masz integrację. Podejrzewam, że pluginów do gita jest 10 razy więcie i mają 5x tyle funkcji co wtyczki do svnj. No ale to również jest niepotrzebne.

    Zresztą nie wiem o co tak naprawdę chodzi. Napisałem tylko, że warto użwyać gita zamiast svn. Jest powszechny trend zmiany svn na gita w większości firm i naprawdę nie wiem czy jest sens pracować z narzędziem, który za kilka lat nie będzie używane. Więc, czy tego chcesz czy nie i tak kiedyś będziesz musiał się nauczyć Gita:)
  • #10 16395926
    tmf
    VIP Zasłużony dla elektroda
    Tak jak pisałem, skoro w svn commit zajmuje mi max kilka sekund, to fakt, że inny program zrobi to w 0,1s nie ma dla mnie znaczenia. Nie pytałem o zalety dla dużej firmy zajmującej się tworzeniem oprogramowania, bo takowej nie posiadam i nie pracuję w takiej. Mnie interesują zalety dla mnie, hobbysty. Biorąc pod uwagę wolne zmiany zachodzące w informatyce, mogę śmiało jeszcze przez wiele lat na tym svn działać, czekając na coś przełomowego. Nie żebym uważał, że git jest lepszy lub gorszy, po prostu zmiana jak widzę nic mi nie da. Gdybym w tej chwili pierwszy raz wchodził w systemy wersjonowania to zapewne użyłbym gita. Natomiast przechodzenie na niego niekoniecznie jest mi potrzebne, tak jak w wielu miejscach ciągle jest używany Windows XP :)
  • #11 16396373
    grko
    Poziom 33  
    Cytat:
    Tak jak pisałem, skoro w svn commit zajmuje mi max kilka sekund, to fakt, że inny program zrobi to w 0,1s nie ma dla mnie znaczenia.


    A przeglądanie historii i ogólnie praca z repozytorium offline? Bo cały czas odnosisz się do tej szybkości commitowania, która na svn nigdy nie będzie szybsza bo __wymaga__ połączenia z serwerem.

    Cytat:

    Mnie interesują zalety dla mnie, hobbysty. Biorąc pod uwagę wolne zmiany zachodzące w informatyce, mogę śmiało jeszcze przez wiele lat na tym svn działać, czekając na coś przełomowego.


    To na takim githubie nie ma hobbystów? Jak git nie był przełomem w SCM to naprawdę nie wiem co będzie. Ogólnie zabawne są opinie ludzi, którzy nie używali gita.

    Cytat:

    Natomiast przechodzenie na niego niekoniecznie jest mi potrzebne, tak jak w wielu miejscach ciągle jest używany Windows XP :)


    W wielu miejscach just używany windows 3.11 albo dos. No i co z tego? Może też powiesz, że pozostaniesz przy windows 3.11 bo przesiadka na win 10 nie jest Ci potrzebna. Twoja sprawa. Cała dyskusja jest kuriozalna. Równie dobrze mogłeś powiedzieć, że:

    "Hobbyście to wystarcza zipowanie katalogu z projektem i nadawanie mu daty. Nie trzeba się uczyć żadnego gita ani svn. Odpadają też problemy z serwerem. Wszystko przecież można trzymać lokalnie albo na dyskietkach. Czy naprawdę potrzebny jest SVN osobie, która pracuje w jednoosobowym projekcie? Oczywiście nawet nie spróbowałem używać SVNa. Wolę poczekać na coś przełomowego"

    Bez obrazy:) Pozdrawiam.
  • #12 16396846
    Kudzu
    Poziom 14  
    Odpowiem na swoje pytanie.
    W oknie "Solution Explorer" musiałem wybrać opcję "Add Solution to Subversion", wprowadzić adres serwera i repozytorium itd.

    Teraz odniosę się do Waszej dyskusji.
    Informację o svn znalazłem w jednej z książek kolegi tmf. Nie szukałem innego rozwiązania. Gita znam jako miłośnik GNU/Linux, ale nie przypuszczałem, że można korzystać z tego systemu również do prywatnych celów. Na swoim domowym serwerze uruchomiłem już SVN i na razie nie mam czasu na walkę z innym rozwiązaniem, choć doczytałem, że serwer git dostępny jest w debianowych repozytoriach i nie powinno być z tym problemów; dodatkowo, jak zauważył tmf, dla Atmel Studio dostępny jest dodatek wspierający git.

    Dla mnie w tym sporze istotna jest jedna kwestia - backup. Który system jest łatwiejszy w robieniu kopii zapasowych? Przeglądałem katalogi svn na swoim serwerze i, szczerze mówiąc, trudno mi się w tym połapać. Nie potrafię nawet zlokalizować plików swojego projektu, gdybym miał go gdzieś skopiować. Owszem, jeśli łączę się z serwerem svn przez http, to wszystko jest uporządkowane, ale nie ma to odzwierciedlenia w strukturze katalogów.
    Jak to wygląda w git?
  • #14 16396922
    Kudzu
    Poziom 14  
    grko napisał:
    @Kudzu Jeżeli Ci nie szkoda kilka $ to kup sobie Premium na githubie:
    https://github.com/pricing
    i tam rób push swoich repozytoriów.

    Dla skąpych jest opcja z bitbucket gdzie masz za friko dowolną ilość prywatnych repozytoriów:
    https://bitbucket.org/product/pricing?tab=host-in-the-cloud

    Nie ma potrzeby, bo w Debianie instaluję pakiet git-core na swoim prywatnym serwerze i mam gita za darmo;) Zresztą podobnie, jak chmurę czy serwer www.

    grko napisał:
    W jednym i drugim przypadku backup robisz jedną komendą. Spróbuj tak w SVN.

    A to już jest bardzo cenna wiadomość.
  • #15 16397592
    tmf
    VIP Zasłużony dla elektroda
    Z całym szacunkiem, ale widzę, że jednak postanowiłeś zostać apostołem gita i szerzyć nową ewangelizację. W sumie mieć misję to ważna rzecz :)

    grko napisał:
    Cytat:
    Tak jak pisałem, skoro w svn commit zajmuje mi max kilka sekund, to fakt, że inny program zrobi to w 0,1s nie ma dla mnie znaczenia.


    A przeglądanie historii i ogólnie praca z repozytorium offline? Bo cały czas odnosisz się do tej szybkości commitowania, która na svn nigdy nie będzie szybsza bo __wymaga__ połączenia z serwerem.


    Zauważ, że nigdzie nie pisałem, że jedno z rozwiązań jest szybsze niż drugie. Nawet, z braku wiedzy na ten temat jestem skłonny przyznać, że git jest szybszy, żeby cię zadowolić niech będzie 100 razy szyszy, albo lepiej - tysiąc razy :) Tylko co z tego, jeśli commit mi zajmuje max kilka sekund. Zysk kilku sekund dla sporadycznie wykonywanej czynności nie jest żadnym zyskiem. Historii repo też namiętnie nie przeglądam i chyba praktycznie nikt tego nie robi. Natomiast cała historia commitów z opisami jest dostępna w svn od ręki i też nie zauważyłem, żeby jej budowanie zajęło więcej niż ułamki sekundy. Piszesz o wadzie jaką jest konieczność połączenia z serwerem. Ok, git może pracować w offline. Super. Ale czy to nie ty wcześniej pisałeś o ryzyku trzymania lokalnego repo? Jednym z celów używania tego typu systemów jest wzrost bezpieczeństwa danych. A to można osiągnąć synchronizując lokalne repo z kopiami na innych serwerach. Czyli w obu przypadkach musimy mieć połączenie z serwerem. Powiedzmy, że git z jakiś powodów realizuje to wszystko szybciej. Tylko co z tego? Użytkownik tego nie powinien zauważyć. Ja używam lokalnego serwera svn, który synchronizuje się z innym. Kiedy to robi, ile to trwa itd. - nawet nie wiem. I co więcej, nie rusza mnie to :)

    grko napisał:
    Cytat:

    Mnie interesują zalety dla mnie, hobbysty. Biorąc pod uwagę wolne zmiany zachodzące w informatyce, mogę śmiało jeszcze przez wiele lat na tym svn działać, czekając na coś przełomowego.


    To na takim githubie nie ma hobbystów? Jak git nie był przełomem w SCM to naprawdę nie wiem co będzie. Ogólnie zabawne są opinie ludzi, którzy nie używali gita.


    Mnie z kolei bardziej bawi poczucie misji niektórych osób. Zadałem konkretne pytanie - w czym przejście na gita mi ułatwi życie? Wymieniłeś kilka punktów, które akurat dla mnie z powodów jak wyżej są bez znaczenia. Więc jeśli kolejnym argumentem ma być, że inni hobbyści korzystają to przykro mi - musisz zmienić narrację. Niewykluczone, że skuteczną metodą persfazji byłaby krucjata.

    grko napisał:
    Cytat:

    Natomiast przechodzenie na niego niekoniecznie jest mi potrzebne, tak jak w wielu miejscach ciągle jest używany Windows XP :)


    W wielu miejscach just używany windows 3.11 albo dos. No i co z tego? Może też powiesz, że pozostaniesz przy windows 3.11 bo przesiadka na win 10 nie jest Ci potrzebna. Twoja sprawa. Cała dyskusja jest kuriozalna. Równie dobrze mogłeś powiedzieć, że:

    "Hobbyście to wystarcza zipowanie katalogu z projektem i nadawanie mu daty. Nie trzeba się uczyć żadnego gita ani svn. Odpadają też problemy z serwerem. Wszystko przecież można trzymać lokalnie albo na dyskietkach. Czy naprawdę potrzebny jest SVN osobie, która pracuje w jednoosobowym projekcie? Oczywiście nawet nie spróbowałem używać SVNa. Wolę poczekać na coś przełomowego"

    Bez obrazy:) Pozdrawiam.


    Powiem ci, że w pracy co prawda nie używamy W3.11, ale DOS 5.0 ciągle żyje. Dlaczego? Ano z tego powodu, że nie ma potrzeby tego zmieniać i wymogi urządzeń zewnętrznych powodują, że nie ma sensu testować kompatybilności rozwiązań z nowszymi systemami ryzykując, że całość się posypie. Na W10 też póki co się nie przesiadłem bo nie oferuje mi nic co diametralnie polepszyłoby moje życie, a przesiadka jest związana ze nieakceptowalnymi stratami - czasem poświęconym na jej wykonanie i ryzykiem niekompatybilności z posiadanym oprogramowaniem.
    Wydaje mi się, że nie rozumiesz, albo nie chcesz zrozumieć w czym leży problem. Inna jest sytuacja osoby, która startuje i stoi przed wyborem pierwszego używanego przez siebie systemu wersjonowania. Zapewne w takim przypadku można użyć to co aktualnie jest najnowsze. Koszt postawienia svn czy git będzie podobny, ryzyko niepowodzenia podobne, więc ma sens brać to co nowsze. Zupełnie inaczej wygląda sytuacja osoby, która już jakiegoś systemu używa. Decyzja o zmianie musi wiązać się z konkretnymi korzyściami. Bo straty z pewnością będą - chociażby czas poświęcony na migrację plus ryzyko, że coś się sknoci i przede wszyskim - konieczność nauki nowego softu. Ponieważ startuję z tej drugiej pozycji, muszę mieć silne argumenty przemiawiające za sensem jej przeprowadzenia. Nawiązując do twojej analogii. Różnica pomiędzy nieużywaniem żadnego systemu wersjonowania, a używaniem jakiegoś to różnica jakościowa, przepaść. Dlatego też dla wielu użytkowników ma sens decyzja o rozpoczęciu używania systemu wersjonowania. Aczkolwiek zapewne jest spore grono użytkowników dla których opisany przez ciebie mechanizm zipowania może być kuszącą propozycją :) Natomiast decyzja typu cvs, svn, czy git to co najwyżej zmiana ilościowa. Czyli pozytywy muszą z nawiązką kompensować negatywy podjętej decyzji.
  • #16 16397729
    grko
    Poziom 33  
    Tak, to ja zostałem apostołem gita podając jednocześnie mercuriala jako alternatywę. Jednocześnie nie jesteś skłonny do użycia ani gita ani mercuriala.

    Cytat:

    Różnica pomiędzy nieużywaniem żadnego systemu wersjonowania, a używaniem jakiegoś to różnica jakościowa, przepaść.


    A ja dalej uważam, że zipowanie mi wystarczy i w jednoosbowym projekcie nie trzeba nic więcej. Nie uważam aby svn był czymś przełomowym. Nie zamierzam nawet spróbować go używać. Nie brzmi to czasem podobnie do tego co Ty mówisz?

    Cytat:

    Natomiast decyzja typu cvs, svn, czy git to co najwyżej zmiana ilościowa.


    No i znowu wypowiadasz się z perspektywy osoby, która używa tylko svn. Ilościowa zmiana to była zmiana cvs na svn. Bo te systemy są do siebie w jakichś sposób podobne. Przejście na gita/mercuriala to rewolucja i wymaga zmiany sposobu myślenia o wersjonowaniu. Ale Ty jako ekspert od systemów kontroli wersji to zapewne wiesz....
  • #17 16397865
    tmf
    VIP Zasłużony dla elektroda
    @grko To od końca - jeśli zmiana svn na git jest przełomowa to mi te przełomowe możliwości wskaź. Właśnie tego dotyczyło moje pytanie. Po prostu chcę wiedzieć co zyskam, poświęcając czas na migrację i naukę nowego programu. Te punkty, które wskazałeś do tej pory na żaden przełom nie wskazują. Przynajmniej dla mnie.
    Kolejna sprawa - system wersjonowania to dla mnie tylko narzędzie. Wolałbym, żeby narzędzia nie zaprzątały moich myśli - wolę skupić się na celu, czyli realizowanym projekcie. Najlepsze narzedzie to takie, którego się nie zauważa.
    Co do zipowania - zakładam, że jest jakaś klasa zastosowań, w których zipowanie użytkownikowi wystarczy. Mnie w niczym nie przeszkadza, że ktoś używa rozwiązań z mojego punktu widzenia nieoptymalnych. Zresztą być może z punktu widzenia takiej osoby, zipowanie będzie optymalne, a używanie systemu wersjonowania przesadną komplikacją? Tu między nami jest fundamentalna różnica - ty uważasz, że można wskazać obiektywnie najlepsze rozwiązanie, ja uważam, że oceny danego rozwiązania można dokonać tylko w kontekście zastosowań i potrzeb użytkownika.
    Dawno temu, gdy projekty pisane przeze mnie były banalne i całość zamykała się w kilku dniach stosowałem właśnie zipowanie. Potem okazało się, że kontrola wersji projektu, proces tworzenia archiwum, kopiowanie i zabezpieczanie, a na końcu dostęp do wersji archiwalnych zajmuje co raz więcej czasu i jest to rozwiązanie nieefektywne. Ale to dopiero wyszło, gdy skala tworzonych projektów się zwiększyła. Dlatego postanowiłem dokonać zmiany. Lata temu był cvs i svn. Zapewne wtedy użytkownicy obu systemów toczyli podobne dyskusje. Jako, że TortoiseSVN spełniało moje kryteria, nie wdając się w akademickie dywagacje nad przewagą któregoś z systemów użyłem SVN. Powiedzmy, że git jest lepszy, co więcej, jestem przekonany, że jest. Co porzebuję, żeby na niego przejść? Jednej prostej rzeczy - powinien mi ułatwić życie, lub dać jakąś nową przewagę. Ponieważ sprawiasz wrażenie eksperta od git, postanowiłem wykorzystać okazję i zapytać co przejście na git mi da i ocenić czy polepszy moją programistyczną jakość życia w sposób istotny dla mnie. I do tego cała ta dyskusja się sprowadza.
    Warto rozważyć jeszcze jedną kwestię - ponieważ oryginalne pytanie autora tematu dotyczyło Atmel Studio, to o wiele większe znaczenie niż dywagacje nad przewagą któregoś z systemów będzie miała banalna sprawa - jakość wtyczki do AS. I od tego należałoby rozpocząć analizę.
  • #18 16397874
    Kudzu
    Poziom 14  
    Ja swój problem rozwiązałem, chociaż wątpię, żeby ewentualny zainteresowany znalazł je w tym dynamicznie rozwijającym się OT.
    Zamykam.
REKLAMA