By

Ubuntu 16.04 – wymuszenie wersji 1.8 dla SVN

Ściągamy odp pakiety .deb stąd:

https://launchpad.net/ubuntu/xenial/amd64/subversion/1.8.13-1ubuntu3
https://launchpad.net/ubuntu/wily/amd64/libsvn1/1.8.13-1ubuntu3

Ewentualnie mirrory z naszego bloga: pakiety

Następnie wywołujemy komendy:

 

Share This:

By

lista statusów SVN (subversion) ENG

U: Working file was updated

G: Changes on the repo were automatically merged into the working copy

M: Working copy is modified

C: This file conflicts with the version in the repo

?: This file is not under version control

!: This file is under version control but is missing or incomplete

A: This file will be added to version control (after commit)

A+: This file will be moved (after commit)

D: This file will be deleted (after commit)

S: This signifies that the file or directory has been switched from the path of the rest of the working copy (using svn switch) to a branch

I: Ignored

X: External definition

~: Type changed

R: Item has been replaced in your working copy. This means the file was scheduled for deletion, and then a new file with the same name was scheduled for addition in its place.

L : Item is locked

E: Item existed, as it would have been created, by an svn update.

Share This:

By

Eclipse – zapewnienie wsparcia dla nowszych wersji (+1.8) Subversion – SVN

Na początku upewniamy się, że wszystkie pluginy związane z SVN w Eclipse są usunięte.

Help -> Install New Software -> What is already installed

Następnie kolejno usuwamy wszyskie wtyczki Subversive, Subversive Connectors itp.

eclipse-subversion-18

Specyfika Eclipse każe nam usuwać je pojedynczo za każdym razem restartując aplikację celem wprowadzenia zmian. Czynność zatem powtarzamy aż lista będzie pusta z tych wtyczek.

Następnie wchodzimy ponownie w:

Help -> Install New Software

Klikamy przycisk:

Add

Podajemy dowolną etykietę w polu Name np. SVN, w polu Location wklejamy link:

http://download.eclipse.org/technology/subversive/4.0/update-site/

Następnie czekamy na zaczytanie adresu i instalujemy standardowo oprogramowanie. W razie problemów z zaczytaniem powyższego adresu restartujemy Eclipse.

eclipse-subversion-18-2

Po zainstalowaniu wtyczki wchodzimy w:

Window -> Preferences -> Team -> SVN -> zakładka SVN Connector -> Get Connectors

i instalujemy wybrany Connector np. najnowszy SVN Kit.

Po restarcie Eclipse’a – najnowszy SVN powinien być obsługiwany.

Share This:

By

svn – ignorowanie wszystkich plików graficznych w danym katalogu i wszystkich jego podkatalogach

Co by nie powiedzieć, to system ingorowania plików w SVN (subversion) jest dość toporny.. Przynajmiej w porównaniu z innymi systemami kontroli wersji gdzie jest to nieco przyjaźniejsze. W każdym razie też ma duże możliwości przy odrobinie trudu.

Po niżej trochę teorii.

Jeżeli chcemy zignorować wszystkie pliki z rozszerzeniem JPG w danym folderze wywołujemy w nim:

Jeżeli chcemy aby obejmował on także podfoldery wywołujemy:

Następnie taką zmianę w folderze commitujemy.

Jednak sprawa się komplikuje jeżeli chcemy dodać do ignorowanych także pliki z rozszerzeniem JPEG. Nie możemy zadeklarować w komendzie więcej jak jednego rozszerzenia. Próby posiłkowania z REGEX też mogą spełznąć na niczym.

Możemy też spróbować 1) dodać rozszerzenie JPG 2) zacommitować 3) dodać rozszerzenie JPEG wg powyższych komend 4) ponownie zacommitować.

Jednak ku naszemu zaskoczeniu po takiej operacji będziemy mieć coprawda zignowowane pliki z rozszerzeniem *.jpeg ale … tryb ignore zostanie zdjęty z plików *.jpg.

Czyli w tej sytuacji możemy ignorować tylko 1 rozrzerzenie w danym folderze..

Jednak z pomocą przychodzi możliwość określania plików do zignorowania poprzez zewnętrzny plik tekstowy.

Tworzymy plik tekstowy:

Dopisujemy do niego listę plików do zignorowania:

Jak widzimy dodaliśmy tam zarówno różne warianty plików JPEG jak i rozszerzenia pisane CAPSem.

Każda nowa deklaracja musi być podana w nowej lini.

Wywołujemy następnie komendę w której wskazujemy na ten plik:

Jak widzimy posiada ona także flagę –recursive odpowiedzialną za objęcie tymi kryteriami także wszystkich podfolderów w danym folderze.

Gotowe! Tak wykonane ustawienie należy zacommitować.

To kolejny artykuł z serii artykułów o SVN.

Share This:

By

Export (tylko) zmienionych plików pomiędzy dwoma rewizjami w SVN

Niestety komenda

Nie zezwala na użycie zakresów jak np. w przypadku

Poniższa komenda powinna być pomocna w osiągnięciu tego celu. Należy w niej określić 3 parametry:

  • rewizję początkową – jej numer (tutaj 2)
  • rewizję końcową (tutaj 5)
  • pełen adres url repozytorium (tutaj svn checkout svn://svn.code.sf.net/p/googlemapsprestashopmodule/svn/ )

Pliki pojawią się w folderze w którym komenda została wywołana.

To kolejny artykuł poświęcony systemowi kontroli wersji SVN (Subversion). Zobacz pełną listę artykułów na ten temat.

Share This:

By

svn i błąd „a peg revision is not allowed here”

Podczas próby dodania (w konsoli) do commitu plików z naszej kopii roboczej pojawia się taki błąd:

Wynika on z dość prozaicznej przyczyny. Zapewne w nazwie pliku jest znak małpki: „@”.

Aby sobie poradzić z tym problemem użyj komendy:

W komendzie jest rozszerzenie pliku PNG. Podmień je na Twoje.

Share This:

By

svn – jak cofnąć zmiany wykonane w kopii roboczej i już zacommitowane?

Jeśli pracujemy w oparciu o system kontroli wersji Subversion (SVN) Czasem zachodzi potrzeba cofnięcia zmian wykonanych przez nas w projekcie. Zazwyczaj w tym celu służy komenda:

Aby uwzglęnić także pliki ukryte (np. w nazwie rozpoczynające się porzez kropkę „.”) użyjmy takiej komendy:

Cofa wszystkie zmiany wykonane w plikach i przywraca ich do wartości domyślnej. Dodatkowo po wywołaniu wówczas:

Aktualizujemy naszą kopię roboczą do najnowszej wersji. Np. jeśli nasi koledzy w zespole w tym czasie nanieśli zmiany w aplikacji.

Co natomiast w przypadku, gdy poczyniliśmy zmiany w kodzie naszej aplikacji i dodatkowo wykonaliśmy commit tych zmian. I to nie jeden. Jednak te modyfikacje okazały się zbędne i jesteśmy zmuszeni je cofnąć. Jak w takim wypadku przywrócić zmiany do wersji sprzed naszej ingerencji? Posłużymy się tutaj funkcją merge.

Na początek musimy mieć pewność, że żadne pliki w naszej kopii nie czekają na commit i nie są zmodyfikowane. Sprawdzamy to za pomocą komendy:

Jeśli komenda pokazuje pliki usunięte (oznaczenie D) lub zmienione (oznaczenie M) cofamy je przez wyżej pokazaną komendę:

OK. Mamy „czystą” kopię roboczą. Teraz upewnijmy się że mamy ją aktualną. Wywołajmy:

I zanotujmy aktualną rewizję naszej kopii roboczej. Czyli numer:

Jeśli nowe pliki się pojawiły przytępujemy do działania. Najpierw poprzez komendę:

Sprawdźmy historię naszych zmian. Klawiszamy page up i page down ustalmy od której rewizji chcemy przywrócenia zmian. Oczywiście oznaczonych przez naszego użytkownika. Zanotujmy ten numer. Powiedzmy jest to:

Następnie wychodzimy z listingu zmian poprzez kombinację klawiszy

Wywołujemy następnie komendę wg wzorca:

Czyli w naszym przypadku:

Następnie pliki są zmieniane wstecz. Tzn wszystkie poczynione zmiany przez nas (i przez innych!) są cofane, a pliki zmieniane. Jeśli w obrębie tego zakresu doszły nowe pliki do repozytorium – są one usuwane.

Możemy to następnie sprawdzimy naszą kopię roboczą poprzez komendę:

Widzimy oznaczenia plików zmienionych (M) i usuniętych (D).

Kolejną rzeczą którą musimy zrobić to sprawdzenie wszystkich plików po kolei. Oczywiście kiedy pracujemy w zespole i inne osoby mogły nanieść zmiany w plikach który nie możemy cofnąć. Niestety. Musimy po prostu uwzględnić te zmany aby one nie przepadły. Jeśli tylko my wykonaliśmy commit albo jesteśmy jedynymi użytkownikami repozytorium – nie musimy tego robić.

Kiedy już jesteśmy pewni, że stan plików odpowiada temu z przed naszych moduyfikacji mozemy zacommitować nasze zmiany:

Gotowe – mamy wersję plików przed naszych zmian. Oczywiście mimo, że jest ona taka sama jak tamta rewizjauzyskuje kolejny nowy numer w repozytorium.

Share This:

By

SVN – problem z commit typu „svn: Plik już istnieje: system plików …” itd.

Podczas pracy z SVN natrafić możemy podczas commitu na dość kuriozalny błąd. Szczególnie jeśli nasze repozytorium posiada z hakiem kilkadziesiąt tysięcy rewizji. Błąd typu:

Może wytrącić z równowagi. Szczególnie dlatego, że uniemożliwia commit i np. pójście do domu..

Pomocne może być następujące działanie.

1. Zmieniamy lokalizację na folder nadrzędny i zmieniamy nazwę folderu z naszą kopią roboczą. Ważnie – nie usuwamy go bo stracimy w końcu naszą pracę.

2. Zgrywamy od nowa naszą kopię roboczą w te samo miejsce.

Najpierw musimy znać pełną ścieżkę. W tym celu używamy komendy:

Ścieżka podana jest po dwukropku:

Zaznaczamy ją i kopiujemy. W terminalu to skrót:

Wykonujemy checkout – zgrywamy od nowa kopię roboczą.

ścieżkę wklejamy w terminalu poprzez komendę:

3. Wracamy do „niedziałającej” kopii roboczej i usuwamy pliki SVN:

(omawialiśmy tą komendę wcześniej na naszym blogu)

4. Przechdzimy do „nowej” kopii roboczej i wgrywamy pliki z „niedziałającej” kopii roboczej do naszej „nowej” kopii roboczej:

Gotowe! Teraz należy skrupulatnie przeglądnąć zmienione przez nas pliki. Jeśli np. pracujemy w zespole – od momentu jak poprzednio zgraliśmy stare pliki – mogły nastąpić dodatkowe zmiany w zmienianych przez nas plikach. To rozwiązanie nie pozwoli uniknąć konfiktów i należy je ręcznie przepatrzyć.

Oczywiście możemy już zacommitować jak wszystko je O.K. i np. iść do domu 😉

Share This:

By

wylistowanie ostatnich zmian w plikach w SVN

Jeśli chcemy przegladnąć ostatnie zmiany w repozytorium SVN używamy komendy:

Spełnia ona swoje zadanie, jednak listuje wszystkie wpisy bez żadnych ograniczeń albo stronicowania.

Stronicowanie możemy dodać poprzez prosty dodatek:

Następnie kolejne strony przełączamy klawiszami:

Od tego widoku uwalniamy się poprzez kombinację:

Dodatkową ciekawą modyfikacją jest dodanie do każdej rewizji listy zmodyfikowanych plików:

Zachęcamy do dalszych eksperymentów z tą bardzo użyteczną komendą

Share This:

By

svn (subversion) – usunięcie wszystkich nowych plików z kopii roboczej

Prezentujemy kolejny post poświęcony systemowi kontroli wersji Subversion (SVN). Poprzednie posty w tej tematyce znajdziesz tutaj: http://linuxporady.pl/tag/svn/

Tym razem pokażemy jak 1 komendą usunąć wszystkie nowe pliki w naszej kopii roboczej. Jak wiemy – jeśli w naszej kopii roboczej pojawi się taki plik jest przy listowaniu zmian przez konsolę:

Oznaczany pytajnikiem. Np:

Jeśli nie chcemy dodawać tych plików do repozytorium ale natychmiast (i nieodwracalnie) się ich pozbyć używamy komendy:

flaga -r na końcu jest podana w razie gdy element do usunięcia byłby folderem.

Oczywiście warto za w czasu zmienić uprawnienia wszystkich plików na adekwatne do usunięcia. Bo np. jak usuwamy pliki szablonów scompilowane przez system Smarty to możemy nie mieć praw do ich się pozybcia. W takim wypadku całość kopii roboczej przypisujemy do nas:

i dopiero wywołujemy powyższą komendę

Share This: