Może udokumentować katalog główny serwera na komputerze klienckim

Oto mój problem.

W naszej firmie mamy taką konfigurację. Jest serwer z apache, php i wszystkim. Wszystkie komputery klienckie (deweloperskie) mają jeden dysk (M :) zamapowany na folder domowy na serwerze tego użytkownika. Skonfigurowaliśmy także dynamiczny katalog główny dokumentu. Na przykład jimy.www.domain.com pobierz katalog główny jako / home / jimitm / www /. Teraz zaczęliśmy używać GIT kilka dni temu. Jednym z problemów, przed którym stoimy, jest git status(lub inne podobne polecenie) zbyt długo, ponieważ musi on sprawdzić każdy plik pod kątem zmiany na dysku sieciowym.
Myślałem, że w ogóle możliwe, że katalog główny będzie na komputerze klienta (dewelopera) D: Dysk (lub jakiś lokalny dysk stanowy). Więc dla jimy.www.domain.com Katalog główny będzie D:/wwwna komputerze klienckim?

Czy jest jakieś inne obejście?

linux apache-http-server git

— jimy
źródło

Dlaczego nie masz lokalnej roboczej kopii repozytorium (jak mówisz na D :) i nie wypychasz repozytorium (jak już masz na M :) na serwerze?

— Dan D.

@DanD. Byłby to jeszcze jeden krok synchronizacji plików i D: i M:

— jimy

Tak więc, chociaż git może być używany w udziałach sieciowych, jest daleki od optymalnego - musi załadować zarówno pliki .git, jak i wszystkie pliki z udziału sieciowego, aby zobaczyć, co się zmieniło.

Korzystanie z zasobów sieci, to może zamontować foldery od strony serwera, jednak realizacja tego żądania na serwerze będzie znacznie gorzej, co zwiększa kod test ocenić cykle od 5-10 sekund do ~ 10-30 sekund każda . Jest to kara wydajnościowa (i psychologiczna), której deweloperzy nie będą tolerować ani na którą nie mogą sobie pozwolić.

Są na to sposoby:

Korzystając z podobnej konfiguracji, nasze rozwiązanie miało również dostęp powłoki do serwera i używanie git tylko z powłoki; pozwala to na pół-natychmiastowe sprawdzanie / zatwierdzanie git, a także na pomocnicze skrypty po stronie serwera, szczególnie do wdrażania, wycofywania i testowania jednostkowego.
Innym popularnym wyborem jest zachęcenie wszystkich do pracy nad w pełni lokalnymi kopiami (poprzez skonfigurowanie repliki środowiska na żywo w virtualbox), a następnie zatwierdzenie ich zmian w centralnym repozytorium

Mam nadzieję, że to pomoże, skomentuj jeśli potrzebujesz wyjaśnień.

— Srebrny Smok
źródło

Najprawdopodobniej wybieramy drugą sugestię. Nawiasem mówiąc, dzięki za obejście pierwszej sugestii.

— jimy