Znalazłem narzędzie Oś czasu z powieści Pixel, ale zastanawiałem się, czy mogę użyć dowolnej aplikacji do zarządzania plikami do zarządzania wersjami. Nie jestem pewien, czy rozumiem jeszcze wszystko o Subversions, i nie znalazłem wielu informacji na temat jego użycia w dziedzinie projektowania.
Odpowiedzi:
Nie jestem pewien, jak dobrze działa z kompresją danych, ale możesz wypróbować załącznik do git : http://git-annex.branchable.com
Jeśli twoje pliki nie są tak duże, najlepszym rozwiązaniem może być zwykły git lub merkurial. Po prostu unikaj SVN za wszelką cenę
Istnieje kilka dobrych sugestii na /programming/29292/version-control-for-graphics
Oto kilka cytatów z pytania na http://StackOverflow.com
„Github niedawno wprowadził„ tryby wyświetlania obrazów ”, spójrz: https://github.com/blog/817-behold-image-view-modes ”
-
„Odniosłem sukces przy użyciu perforce w bardzo dużych projektach (+100 GB), jednak musieliśmy owinąć dostęp do serwera kontroli wersji czymś bardziej przyjaznym dla artystów”.
-
„TortoiseSVN może wyświetlać zmiany obrazu obok siebie, co jest bardzo przydatne. Użyłem go z różnymi zespołami z dużym powodzeniem. Artyści uwielbiali możliwość wycofywania rzeczy (po przyzwyczajeniu się do koncepcji ). Jednak zajmuje dużo miejsca. ”
Oś czasu współpracuje z „dowolnym svn” i jest najwyraźniej również wtyczką do projektowania.
SVN jest prawdopodobnie w większości nie na temat, ale w skrócie, śledzi pojedynczy plik źródłowy, a następnie przechowuje zmiany w tym oryginalnym pliku w miarę upływu czasu lub wymusza nowy „punkt bazowy”.
Jedynym sposobem na niezawodne przywrócenie starszej wersji jest porównanie ich ręcznie i podjęcie decyzji. Repozytoria pierwotnie były przeznaczone głównie do plików tekstowych (kodu źródłowego) i dość łatwo jest spojrzeć na surowe zmiany i zdecydować, które chcesz, ponieważ były one czytelne dla ludzi, ale dla danych binarnych (obrazy, formaty zastrzeżone, formaty kontenerów itp.), zmiany nie są w formie czytelnej dla człowieka. Oś czasu wydaje się być sposobem na poradzenie sobie z tym, biorąc różne zatwierdzenia i wyświetlając je.
Link Scotta do obrazu GIT jest przeznaczony dla określonych formatów i (tak sądzę ) prawdopodobnie nie obsługuje plików PSD, a zwłaszcza plików niestandardowych (tj. Losowych formatów binarnych). Oś czasu wydaje się być wtyczką, która polega jedynie na aplikacji hosta do prezentacji danych binarnych (dobre rozwiązanie, przynajmniej na papierze IMO).
Podstawowym sposobem działania repozytorium svn jest posiadanie procesu serwera, który obsługuje śledzenie i podstawowe przechowywanie wszystkich różnic. Następnie masz proces klienta na działającej maszynie, który działa zawsze i jest podłączony do menu kontekstowych itp. (Lub korzysta z wiersza poleceń). Utworzysz pusty folder lokalny, a następnie oznaczysz go jako folder SVN, „sprawdzając” wersję z repozytorium na serwerze. Od tego momentu możesz edytować je tak, jak chcesz, ale musisz użyć klienta svn, aby przenieść kopię lub usunąćpliki w systemie plików. Jeśli dodasz nowe pliki do lokalnego folderu SVN, musisz oznaczyć je, aby je śledzić. Wszystko to dzieje się lokalnie, a repozytorium jest aktualizowane z wszelkimi poprawkami tylko wtedy, gdy ręcznie „zatwierdzasz” powrót do repozytorium. Twoja lokalna kopia jest pojedynczą wersją i musisz przywrócić serwer SVN, aby przywrócić plik.
Wszystko to jest powolne w porównaniu z brakiem SVN, nawet w przypadku plików tekstowych, zwłaszcza jeśli sprawdzasz duży projekt. Projekty, na których korzystałem z SVN (czas przeszły), były w większości oparte na kodzie źródłowym, z 20-30 tysiącami małych plików i pełne zamówienie wymagało przerwy na kawę. Podejrzewam, że było to bardziej spowodowane narzutem związanym z tak dużą liczbą małych plików i mniej dużych plików binarnych o tym samym rozmiarze byłoby szybsze.
Myślę, że GIT działa nieco inaczej.
Korzystam z git w moich projektach Illustrator i InDesign. Muszę przyznać, że zarządzanie projektami w ten sposób nie jest łatwe. Oto kilka wskazówek, które mogą Ci pomóc:
Uważaj tylko na SVN, nauczę się git. Jest to lepsze przy dużych rozmiarach plików, ale nadal zapewnia kontrolę / zarządzanie subversion. Po prostu lżejszy.
Większość systemów wersjonowania jest zaprojektowana do obsługi niebinarnych formatów plików. Innymi słowy, pliki tekstowe.
Są lekkie, łatwe do rozwidlenia, rozgałęzienia, scalenia i śledzenia zmian przyrostowych.
Systemy takie jak SVN i GIT nie są zaprojektowane do obsługi plików PSD. Są to gigantyczne pliki, których nie można łatwo porównać z jedną wersją do następnej i niemożliwe do „scalenia”, rozwidlenia itp.
Niektóre mogą zezwalać na pliki binarne - wydaje mi się, że SVN to robi, ale z mojego doświadczenia wynika, że nie próbuje ich wersji. Zamiast tego po prostu zamienia najnowszą wersję. Więc tam ograniczone użycie.
Ponadto, jeśli zapoznasz się z działającym modelem kontroli wersji, nauczysz się często meldować. Jest to świetne w przypadku kodu, ale wkrótce spowoduje powiększenie repozytorium do rozmiarów niemożliwych do zarządzania, jeśli sprawdzasz wersje plików PSD 100 MB co 20 minut.
Z powodu braku rozgałęzień itp. Oznacza to, że nadal będziesz prawdopodobnie wykonywać wiele takich czynności ręcznie, mając wiele kopii nieznacznie poprawionych plików. Oznacza to, niestety, jeszcze więcej dużych plików, które muszą być przechowywane, więc kolejne ostrzeżenie przeciwko kontroli wersji.
W związku z tym w przypadku ciężkich plików binarnych warto zachować zewnętrzny system kontroli wersji, taki jak ten, i zapoznać się z narzędziami DAM (Digital Asset Management).
Niestety, nie ma wielu systemów kontroli wersji zaprojektowanych specjalnie dla ciężkich dokumentów. Sharepoint jest jeden, ale jest niezdarny, mało zautomatyzowany i rzadko jest skonfigurowany do obsługi plików wielkości PSD.
Najbardziej prawdopodobną alternatywą jest własna wersja Adobe Cue, która moim zdaniem została przekształcona w produkt „Adobe Drive”: