Autor Wątek: Git i VS, synchronizacja tabów, bookmarków itp  (Przeczytany 2152 razy)

Offline ShadowDancer

  • Redaktor

# Marzec 25, 2015, 00:03:30
Jw, jak załatwić synchronizację tabów, bookmarków, (ew. breakpointów) itd. itp. pomiędzy branchami (w kontekście Visual Studio).


Sprawa jest dość oczywista - pracuję nad jakimś featurem, z jakiegoś powodu chcę się przełączyć na inny branch. Muszę wszystko wywalić (z oczywistych powodów) i otworzyć inne pliki, interesują mnie inne bookmarki itp. itd. Jest jakiś lepszy sposób niż trzymanie kilku kopii repo, każda z innym branchem? Z pewnych powodów (iis) to też nie jest dobre rozwiązanie.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 25, 2015, 00:44:58
Cytuj
Sprawa jest dość oczywista - pracuję nad jakimś featurem, z jakiegoś powodu chcę się przełączyć na inny branch. Muszę wszystko wywalić (z oczywistych powodów)
Powody są kompletnie nieoczywiste. Jeśli chcesz przełączyć się na inny branch, to wycheckoutuj go w inne miejsce niż to, w którym aktualnie pracujesz.

Cytuj
Jest jakiś lepszy sposób niż trzymanie kilku kopii repo, każda z innym branchem? Z pewnych powodów (iis) to też nie jest dobre rozwiązanie.
Jeśli kopie są odpowiednio powiązane (możesz pushować do wspólnego repo z każdej kopii), to w czym jest problem?

Offline ShadowDancer

  • Redaktor

# Marzec 25, 2015, 08:22:58
Jeśli chcesz przełączyć się na inny branch, to wycheckoutuj go w inne miejsce niż to, w którym aktualnie pracujesz.
Chodziło mi o zamykanie tabów - jeżeli mam otwarte ponad 20 tabów, to nie jest tak pięknie jak kiedy mam ich 5. Podobnie z bookmarkami, szybciej się przegląda jak mam ich tylko kilka dot. aktualnego featura, niż kilkadziesiąt i muszę z 20x skrót zanim przejdę do właściwego.

Jeśli kopie są odpowiednio powiązane (możesz pushować do wspólnego repo z każdej kopii), to w czym jest problem?
W różnym wymaganym oprogramowaniu, które może działać tylko w jednej instancji (np. iis, ale nie tylko) i generalnie nie pozwala mi debuggować kodu z 2 miejsc bez pieprzenia się z configami. No i nie współgra dobrze z featurami typu otwórz ostatnio edytowane dokumenty - czasami tracę trochę czasu, bo edytuję plik nie w tym katalogu (w senie w ścieżce do katalogu kilka folderów wyżej mam np. repo2 zamiast repo3 itp.)
« Ostatnia zmiana: Marzec 25, 2015, 09:16:40 wysłana przez ShadowDancer »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 25, 2015, 11:27:41
Cytuj
Chodziło mi o zamykanie tabów - jeżeli mam otwarte ponad 20 tabów, to nie jest tak pięknie jak kiedy mam ich 5. Podobnie z bookmarkami, szybciej się przegląda jak mam ich tylko kilka dot. aktualnego featura, niż kilkadziesiąt i muszę z 20x skrót zanim przejdę do właściwego.
No właśnie. Jak "aktualny feature" będziesz developował w zupełnie innym katalogu, niż "właściwy feaure", to jedne bookmarki nie będą przeszkadzały drugim. Ba, możesz nawet sobie otworzyć równolegle dwa Visuale i się między nimi przełączać.

Cytuj
W różnym wymaganym oprogramowaniu, które może działać tylko w jednej instancji (np. iis, ale nie tylko)
Ale pozwala się chyba łatwo przełączać między projektami które są w różnych folderach?

Offline Xender

  • Użytkownik

# Marzec 25, 2015, 15:00:41
Rozwiązanie jest oczywiste - NIE trzymać plików projektu IDE w Gicie.

Jak na standardy repa, które nadaje się do publikacji bez wstydu, one i tak nie powinny się tam w ogóle znaleźć.

Przepisać całą historię używając filter-branch lub BFG Repo Cleaner, wywalając z commitów wszystkie pliki IDE.
Dodać nazwy tych plików do .git/info/exclude. To takie .gitignore, tylko, że lokalne dla repo.

Efekt - pliki te nie będą wersjonowane przez Gita, więc wszelkie zmiany branchy nie będą nic w nich mieszać.


Osobny workdir też może być dobrym rozwiązaniem.

Tylko, że zamiast robić lokalnego klona i pushować jak głupi w tę i wewtę, można uzyskać automatyczną synchronizację obiektów i refek na poziomie filesystemu:
https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir

O ile uda Ci się doprowadzić ln -s do działania na Windowssie. Da się.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 25, 2015, 15:46:07
Cytuj
Jak na standardy repa, które nadaje się do publikacji bez wstydu, one i tak nie powinny się tam w ogóle znaleźć.
Akurat osobiście o rząd wielkości wyżej cenię repa z plikami projektów, niż bez. Nie dać sln+vcxproj pod Windowsem to tak jakby pod Linuxem zapomnieć dodać do repo Makefile. Oczywiście mówię o plikach projektu, a nie plikach tymczasowych IDE z zakładkami, itp.

Offline Xender

  • Użytkownik

# Marzec 25, 2015, 16:19:24
Akurat osobiście o rząd wielkości wyżej cenię repa z plikami projektów, niż bez. Nie dać sln+vcxproj pod Windowsem to tak jakby pod Linuxem zapomnieć dodać do repo Makefile.
No ok, jeden Windows, jedno IDE, jedna Rzesza.
Niech tam będzie.

Oczywiście mówię o plikach projektu, a nie plikach tymczasowych IDE z zakładkami, itp.
Jeśli VS trzyma te dane w osobnych plikach, no to rozwiązanie rzeczywiście wygląda na tak trywialne, jak wywalenie tych plików z każdego brancha (i zatrzymanie w working copy, chociażby przez skopiowanie wcześniej w bezpieczne miejsce i przywrócenie). Przepisywanie historii opcjonalne.

Offline Kos

  • Użytkownik
    • kos.gd

# Marzec 25, 2015, 16:26:12
Akurat osobiście o rząd wielkości wyżej cenię repa z plikami projektów, niż bez. Nie dać sln+vcxproj pod Windowsem to tak jakby pod Linuxem zapomnieć dodać do repo Makefile. Oczywiście mówię o plikach projektu, a nie plikach tymczasowych IDE z zakładkami, itp.

No, krótko mówiąc commitujemy wszystko co się tyczy builda, a nie commitujemy rzeczy mających sens tylko dla jednego usera.
Szczegóły trochę zależą od projektu: jeśli np. biblioteka C++ jest otwarta, to lepiej zacommitować CMakeLists, a .sln zostawić poza repo. Natomiast jeśli to wewnętrzny projekt zespołu pracującego w całości na Visual Studio, to .sln jest bardziej na miejscu.



Oszczędnym sposobem na drugą kopię roboczą repozytorium Gitowego jest shallow clone (--depth 1). Nie zapominamy, że można klonować z tego które już jest na dysku, a nie z origina.

Są też jeszcze lepsze rozwiązania: http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git

Offline Dab

  • Redaktor
    • blog

# Marzec 25, 2015, 16:29:20
Cytuj
Akurat osobiście o rząd wielkości wyżej cenię repa z plikami projektów, niż bez. Nie dać sln+vcxproj pod Windowsem to tak jakby pod Linuxem zapomnieć dodać do repo Makefile

Lekki OT: są pliki projektów i pliki projektów. :)

Np. XCode 3 miał koszmarny format pliku projektu. Każdy plik z kodem miał generowany unikalny identyfikator i pliki projektów sypały się przy KAŻDYM merge/rebase.

Generalnie taki plik projektu jakiego używa VS czy XCode to też jest plik tymczasowy. Dodanie jakiekolwiek nowego pliku źródłowego wymaga potem mergowania, co drugi merge posypie się kolejność plików i trzeba poprawiać. Plus, podawanie opcji kompilacji jest upierdliwe, bo np. przy dopisywaniu nowego #define trzeba pamiętać o dopisaniu go w Debug, Release i potencjalnie innych miejscach.

Co jest od tego lepsze?

Lepsze jest użycie języka/środowiska które ma sensowny sposób budowania projektów. :) Np. nie ma problemów z projektami Ruby czy Java bo tam nie podajesz w opcjach projektu konkretnych źródeł, tylko projekt budowany jest zaczynając od określonego katalogu/katalogów. Na palcach jednej ręki drwala mogę policzyć sytuacje w których chciałem budować projekt inaczej niż podając N katalogów w których leżą źródła.

A co w C++? Osobiście polecam premake. Specyfikację projektu podaje się w Lua (więc można po prostu dodać kawałek kodu zamiast czarować z magiczną składnią CMake), można potem z takiej specyfikacji generować projekty na różne środowiska i platformy.

Offline ShadowDancer

  • Redaktor

# Marzec 25, 2015, 19:01:07
Jeśli VS trzyma te dane w osobnych plikach, no to rozwiązanie rzeczywiście wygląda na tak trywialne, jak wywalenie tych plików z każdego brancha (i zatrzymanie w working copy, chociażby przez skopiowanie wcześniej w bezpieczne miejsce i przywrócenie).
Tylko ja właśnie chcę mieć swoją kopię tych danych per ja per branch (oczywiście nie w repo). Idealnie by było, gdyby plugin do gita w VS jakiego mam brancha i wczytywał layout i taby, tylko czegoś takiego (AFAIK) nie ma?


Dysku mam na tyle, więc mogę sobie pozwolić na kilka pełnych kopii repo i nie jest to problemem, chodzi tylko o moją wygodę.

Offline deadeye

  • Użytkownik

# Marzec 25, 2015, 22:11:33
Jak chcesz mieć kopie tych ustawień w repo, to po prostu dodaj plik .suo do repo - ten plik zawiera wszystkie dane które ci są potrzebne (bookmarki, otwarte okna itd). Trzymaj osobą wersje tego pliku w każdym branchu i to rozwiązuje twój problem. Tyle że to zły pomysł jeśli pracujesz w teamie, bo z założenia ten plik zawiera dane per-user, ale jeśli pracujesz sam i wiesz co robić to może ci wystarczyć.  Plik jest binarny, więc raczej  go nie zmerge'ujesz, ale wystarczy wybierac którąkolwiek wersje przy merge, i tak jeśli będzie nieaktualna to VS go zregeneruje.

Alternatywna metoda: możesz zdefiniować sobie customowe tokeny komentarzy, np:

//BRANCH1 initialization

//BRANCH2 important code here



a później je przeglądać w Visualu w oknie tasków i skakać do nich, jak do bookmarków. Takie komenty będa się ładnie merge'ować, a filtrując po tokenie w danym momencie możesz oglądać tylko zakładki z jednego brancha.

Tutaj masz opisane https://msdn.microsoft.com/en-us/library/zce12xx2%28v=vs.90%29.aspx?f=255&MSPPError=-2147217396 (na dolne jest jak zrobić własne tokeny).
« Ostatnia zmiana: Marzec 25, 2015, 22:23:46 wysłana przez deadeye »

Offline bies

  • Użytkownik

  • +3
# Marzec 25, 2015, 22:16:08
Eeee, z dokumentacji gita:
post-checkout
This hook is invoked when a git checkout is run after having updated the worktree.(...)This hook can be used to perform repository validity checks, auto-display differences from the previous HEAD if different, or set working dir metadata properties.
Zrób sobie w tym hooku kopiowanie plików z tabami i zakładkami z i do katalogu o nazwie brancha i trzymanego w .gitignore i po kłopocie. Będziesz miał automatykę która będzie zapisywała metadane per branch ale nie trzymała ich w repo.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 25, 2015, 22:45:33
Cytuj
Jeśli VS trzyma te dane w osobnych plikach, no to rozwiązanie rzeczywiście wygląda na tak trywialne
Visual Studio 2013 potrzebuje dokładnie trzech plików: *.sln, *.vcxproj i *.vcxproj.filters. Pierwszy mówi jakie projekty VS ma wczytać, drugi mówi wszystko o danym projekcie, a trzeci o układzie plików w drzewku projektu.

Cytuj
Szczegóły trochę zależą od projektu: jeśli np. biblioteka C++ jest otwarta, to lepiej zacommitować CMakeLists, a .sln zostawić poza repo.
Jeżeli biblioteka jest otwarta i ma kompilować się w Visual Studio, to jak najbardziej dobrze .sln dołożyć. Zwłaszcza na platformie Windows CMake jest produktem niszowym w porównaniu z Visualem. I nie, wymaganie doinstalowania kolejnej rzeczy wyłacznie pod dany projekt nie jest podajściem user-friendly.

Ale najmądrzej robią projekty, które w katalogu "build" w podkatalogach trzymają projekty/makefile dla wszystkich możliwych platform.

Offline karol57

  • Użytkownik

# Marzec 26, 2015, 13:20:45
Jeżeli biblioteka jest otwarta i ma kompilować się w Visual Studio, to jak najbardziej dobrze .sln dołożyć. Zwłaszcza na platformie Windows CMake jest produktem niszowym w porównaniu z Visualem.
W większości przypadków z jakimi się spotkałem projekty Visuala albo nie działały do końca poprawnie, albo były przygotowane do jakiejś przedpotopowej wersji Visuala (a upgrade do nowszej wersji chyba mi jeszcze nie zadziałał poprawnie). A jak już było prawie wszystko cacy, to architekturę x64 zrób sobie sam.

Fakt. Istnieją projekty które poprawnie się kompilują w Visualu, ale szczerze ile ich jest? Boost i Qt się nie liczą ponieważ z VS korzystają tylko i wyłącznie jako kompilatora.

I nie, wymaganie doinstalowania kolejnej rzeczy wyłacznie pod dany projekt nie jest podajściem user-friendly.
Może wymaganie doinstalowania CMake nie jest user-friendly, ale ile userów będzie budować projekt skoro mogą ściągnąć już zbudowany? Równie dobrze można powiedzieć że wymaganie doinstalowania Visuala nie jest user-friendly.
W przypadku programistów prędzej czy późnej użycie CMake'a będzie koniecznością, więc nie jest to "doinstalowania kolejnej rzeczy wyłącznie pod dany projekt".

Dodatkowo CMake pozwala na prostą konfigurację i bez problemów można wybrać architekturę oraz kompilator.