Które pliki Eclipse podlegają kontroli wersji?

Które pliki Eclipse należy poddać kontroli źródła, oczywiście poza źródłami?

Szczególnie w moim projekcie zastanawiam się nad:

.metadata / *
project-dir / .project
project-dir / .classpath
project-dir / .settings / *

Jeśli są jakieś, od których to zależy, wyjaśnij swoje wytyczne.

Metadanymi nie należy zarządzać w kontroli źródła. Zawierają one głównie dane dotyczące twojego obszaru roboczego.

Jedynym wyjątkiem są .launchpliki XML (definicja programu uruchamiającego).

Znajdują się w

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

I powinny zostać skopiowane do katalogu projektu: Gdy projekt zostanie odświeżony, te konfiguracje zostaną wyświetlone w oknie dialogowym „Uruchom konfigurację”.

W ten sposób tymi plikami parametrów uruchamiania można również zarządzać w SCM.

(Uwaga: Do odznacz opcję „Usuń konfiguracje gdy związany zasób jest usunięte” w Run / Launching / Uruchom Konfiguracja panelu preferencji: powszechne jest miękki skasować projekt w celu zaimportowania go z powrotem - do wymuszenia reinicjowanie z następujących metadane eclipse. Ale ta opcja, jeśli zaznaczona, usunie szczegółowe parametry uruchamiania!)

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

powinny być w SCM (w szczególności .projecti .classpathzgodnie z dokumentacją Eclipse ).

Celem jest, aby każdy mógł pobrać / zaktualizować swój obszar roboczy SCM i zaimportować projekt Eclipse do obszaru roboczego Eclipse.

W tym celu chcesz używać tylko ścieżek względnych w ścieżce .clas, używając połączonych zasobów .

Uwaga: lepiej jest project-dirodwoływać się do „zewnętrznego” katalogu projektu, a nie katalogu utworzonego w obszarze roboczym zaćmienia. W ten sposób dwa pojęcia (obszar roboczy zaćmienia vs. obszar roboczy SCM) są wyraźnie rozdzielone.

Jak wspomina ipsquiggle w komentarzu i jak wspomniałem w starej odpowiedzi , możesz faktycznie zapisać konfigurację uruchamiania jako plik udostępniony bezpośrednio w katalogu projektu. Całą konfigurację uruchamiania można następnie wersjonować tak jak inne pliki projektu.

(Z posta na blogu Wskazówka: tworzenie i udostępnianie konfiguracji uruchamiania z KD)

Obecnie pracuję nad projektem, w którym mamy pliki .project i .cproject pod kontrolą źródła. Pomysł polegał na tym, że ustawienia związane ze ścieżkami bibliotek i dyrektywami linków byłyby rozpowszechniane w całym zespole.

W praktyce nie działało to zbyt dobrze, fuzje prawie zawsze wracają w stanie konfliktu, który musi zostać zdekonflikowany poza zaćmieniem, a następnie projekt został zamknięty i ponownie otwarty, aby zmiany zostały wprowadzone.

Nie zalecałbym utrzymywania ich pod kontrolą źródła.

Nic nie warte jest tego, że pliki konfiguracyjne CDT nie są przyjazne dla kontroli źródła. Zgłoszony został błąd dotyczący bardzo częstej zmiany plików .cproject i powodowania konfliktów, zobacz Udostępnianie plików projektów cdt w repozytorium zawsze powoduje konflikty .

Niektóre projekty, takie jak te wykorzystujące Maven, lubią generować pliki .project na podstawie POM.

To powiedziawszy, poza tym - metadane NIE powinny mieć kontroli źródła. Twój projekt będzie musiał ustalić, czy robi to projectdir / .settings, na podstawie tego, jak planujesz zarządzać standardami i tym podobne. Jeśli możesz szczerze zaufać programistom, że skonfigurują swoje środowisko w oparciu o standard i nie musisz dostosowywać niczego specjalnego do żadnego projektu, to nie musisz ich włączać. Ja, zalecam skonfigurowanie każdego projektu specjalnie . Umożliwia to programistom pracę nad materiałami z wielu projektów w tym samym obszarze roboczym bez konieczności zmiany domyślnych ustawień tam iz powrotem, i sprawia, że ​​ustawienia są bardzo wyraźne, zastępując ich ustawienia domyślne zgodne ze standardami projektu.

Jedyną trudną częścią jest upewnienie się, że wszystkie są zsynchronizowane. Ale w większości przypadków można skopiować pliki .settings z projektu do projektu. Jeśli są takie, których nie chcesz w kontroli źródła, wykonaj odpowiednik ustawienia svn: ignore dla nich, jeśli SCM je obsługuje.

Plik .classpath jest zdecydowanie dobrym kandydatem do sprawdzenia w scm, ponieważ ręczne ustawienie go może być bardzo pracochłonne i będzie trudne dla nowych deweloperów wchodzących do projektu. Prawdą jest, że można go wygenerować z innych źródeł, w którym to przypadku można sprawdzić w innym źródle.

Jeśli chodzi o .settings, zależy to od ustawień. Jest to szary obszar, ale niektóre ustawienia są prawie obowiązkowe i wygodnie jest móc sprawdzić projekt, zaimportować go do Eclipse i mieć wszystko skonfigurowane i gotowe.

Dlatego w naszym projekcie przechowujemy kopię folderu .settings o nazwie CVS.settings i mamy zadanie mrówki, aby skopiować ją do .settings. Po otrzymaniu projektu z CVS wywołujesz zadanie ant Eclipsify, aby skopiować ustawienia domyślne do nowego folderu .settings. Podczas konfigurowania ustawień, które są potrzebne wszystkim osobom rozwijającym się w projekcie, scalasz je z powrotem do folderu CVS.settings i zatwierdzasz w CVS. W ten sposób zapisywanie ustawień w SCM staje się świadomym procesem. Wymaga to od deweloperów scalenia tych ustawień z powrotem do ich folderów .settings, gdy sprawdzane są duże zmiany. Ale to prosty system, który działa zaskakująco dobrze.

Nie powiedziałbym żadnego z nich. Najprawdopodobniej zawierają informacje, które dotyczą tylko twojej stacji roboczej (myślę o ścieżkach do bibliotek i wszystkich innych). A co, jeśli ktoś z twojego zespołu nie używa Eclipse?

Rozważać:

.classpath
.project
.launch

Powinny być pod kontrolą wersji, dopóki trzymasz się ścieżek względnych dla projektu. Dzięki temu inni programiści mogą sprawdzić projekt i rozpocząć pracę od razu, bez konieczności przechodzenia przez cały proces konfiguracji, przez który przeszli także inni programiści.

Możesz pokusić się o włączenie .metadanych do kontroli wersji, aby programiści Eclipse mogli sprawdzić cały obszar roboczy i wstępnie go skonfigurować we wszystkich odpowiednich projektach, ale zawiera on wiele informacji specyficznych dla użytkownika, które za każdym razem, gdy ktoś nad nim pracuje, będzie zmienić, więc radziłbym NIE ZAWIERAĆ .metadanych. Łatwo jest zbudować lokalny obszar roboczy, po prostu importując wszystkie istniejące projekty Eclipse.

Spędziłem zbyt wiele godzin konfigurując ustawienia obszaru roboczego zaćmienia dla nowych kolegów (i mnie). Ostatecznie skończyłem z kopiowaniem własnych .metadanych na nową maszynę programistyczną.

Jeśli pracujesz w zespole, uważam, że poniższe osoby są bardzo dobrymi kandydatami do kontroli wersji:

• Zainstalowane środowiska JRE i ich nazwy
• Środowiska wykonawcze serwera
• Szablony edytora Java
• Skróty klawiaturowe kontroli wersji
• Ustawienia wtyczek, które nie zapewniają ustawień specyficznych dla projektu
• Ustawienia Maven
• Wstępnie skonfigurowane perspektywy
• ...