Sprawdzanie w projekcie Eclipse do SVN

Question

Chcę sprawdzić dynamiczny projekt internetowy, który stworzyłem w czasie zaćmienia w svn. Czy ktoś może mi powiedzieć, które pliki muszę sprawdzić, a które nie? Chodzi o to, aby móc sprawdzić projekt za pomocą Kreatora nowego projektu, aby móc ponownie utworzyć dynamiczny projekt internetowy. Dokładniej tutaj są pliki/katalogi mam w projekcie -

• src
• WebContent
• build
• dist
• build.xml
• .project
• .classpath
• .ustawienia/

Katalog instalacyjny nie powinien oczywiście być sprawdzany. A co z pozostałymi? Zgaduję wszystkie. pliki nie powinny być również zaznaczone. Czy ktoś może to zweryfikować? Co to jest katalog dist i katalog .settings?

Również tam, gdzie Eclipse przechowuje informacje o serwerze (tomcat)? Nie chcę tego również sprawdzać.

EDIT:

początkowo sprawdzane we wszystkich wyżej z wyjątkiem katalogu build oczywiście. Kiedy wyewidencjonowałem projekt z wnętrza Eclipse, nie zachęciło mnie to do stworzenia nowego projektu, ponieważ projekt .project istnieje, ale Eclipse tworzył projekt JavaEE lub coś innego niż Dynamic Web Project. Czy ktoś inny wpadł na to zachowanie?

** EDYTUJ 2 **

Znaleziono! Okazuje się, że nie powinien sprawdzić w następujący -

• .project
• .settings/
• .classpath

Po tych 3 są usuwane kreatora nowego projektu działa zgodnie z oczekiwaniami i wszystko jest w porządku.

Answer 1

Jeśli zaznaczysz .classpath/.project/.settings, zrobisz swój projekt w stylu Eclipse. A co z programistami, którzy pracują z Netbeans lub IntelliJ? IMO jest czystsze w utrzymaniu niezależności od projektu IDE i łatwości konfiguracji.

Zazwyczaj wybieram kompilację Mavena. pom.xml określa wszystkie wymagane zależności, a mvn eclipse:eclipse generuje dla Ciebie pliki .classpath/.project.

Katalog .settings zawiera ustawienia lokalne (np. Wersję Java, której chcesz użyć). IMO nie jest przydatne, aby to sprawdzić. Możesz wymusić zgodność wersji Java za pomocą Maven2 pom.

Wreszcie, dla twojego następnego projektu, mój protip to svn-ignore pliki lub katalogi których nie chcesz w SVN przed twoje pierwsze zatwierdzenie. W konfiguracji Maven2 będzie to .settings.classpath.projecttarget (domyślny katalog wyjściowy Maven2) i wszelkie inne wygenerowane rzeczy (pliki dziennika, katalogi gfembed, itp.). W twoim przypadku zignorujesz build i dist zamiast target.

Możesz svn-ignore plików lub katalogów z RIGHT_MOUSE->Team->'Add to svn:ignore' (używam wtyczki Subclipse). Instrukcje ignorowania są przechowywane w katalogu nadrzędnym jako svn-properties. Właściwości katalogu można przejrzeć pod numerem RIGHT_MOUSE->Team->Show properties. Możesz także edytować właściwości bezpośrednio tam, klikając pole wartości. Upewnij się, że po każdej nieruchomości jest koniec linii.

Teraz, gdy już popełniłeś, a następnie usunąłeś te pliki, ignorowanie nie będzie już działać w moim doświadczeniu. Jakoś nigdy nie udało mi się zignorować wygenerowanych plików, które kiedykolwiek zostały sprawdzone w repozytorium SVN; są jak zombie, zawsze wracają z martwych. Może poprzez fizyczne usunięcie repozytoriów SVN można to osiągnąć, ale nigdy tego nie zrobiłem.

Answer 2

Pominęłbym .project, .settings /, dist i build.

Ścieżkę .clas można pozostawić, jeśli używasz zmiennych zamiast ścieżek zakodowanych na stałe. Jest to przydatne, więc nie trzeba przebudowywać ścieżki klasowej za każdym razem, gdy sprawdzasz projekt.

Answer 3

W naszym przypadku sprawdziliśmy wszystkie wymienione na liście, z wyjątkiem .settings /.

Po przejściu na .classpath i .project użytkownicy mogą szybko sprawdzić projekt i uruchomić Eclipse na nowym komputerze i rozpocząć pracę nad nim; alternatywą jest ręczne konfigurowanie projektu i staranne dodawanie wszystkich zależności (jeśli używasz anta). Robi to wiele projektów Open Source.

Przeczytaj this, jest kilka naprawdę dobrych punktów do rozważenia.

Answer 4

Dobre pytanie ... Wielu z nas ma dylemat, czy chcemy sprawdzić pliki powiązane z IDE, czy nie. Zwykle chodzę do sprawdzania w .classpath na Eclipse i używam zmiennych Eclipse, aby upewnić się, że zespół musi po prostu zmienić wartość zmiennej i działa. Sprawdzamy również w projekcie .project, aby zespół nie musiał tworzyć nowego projektu w swoim obszarze roboczym.