Kontrola wersji do współpracy (z różnicami na poziomie słów)?

Większość prac jest teraz pisanych wspólnie, a współpracownicy często znajdują się w różnych miejscach. Zawsze używałem systemów kontroli wersji dla moich dokumentów i kodu, a także uważałem kontrolę wersji za kluczową dla wspólnych projektów oprogramowania, ale wydaje się, że wielu badaczy teoretycznie unika ich użycia do pisania wspólnych dokumentów. Aby przekonać moich współpracowników, że kontrola wersji (kontrola wersji) jest dobrym pomysłem do współpracy, wydaje się, że istnieją pewne warunki wstępne. Nie można zmusić wszystkich do martwienia się o określony zestaw konwencji dotyczących podziałów wierszy i akapitów ani do uniknięcia konwersji tabulatorów / spacji.

Czy ktoś oferuje darmowy hosting małych współdzielonych repozytoriów dokumentów z kontrolą wersji przyjazną dla dokumentów tekstowych, która może obsługiwać różnice na poziomie słów ( nie liniowe)?

Jeśli nie, to chętnie przyjmę inne sugestie oparte na doświadczeniu (unikajmy spekulacji, proszę).

Myślałem o Git, Subversion, Mercurial, darcs lub Bazaar, skonfigurowanych do obsługi różnic poziomów słów za pomocą wdiff, wraz z prostym sposobem konfigurowania dostępu zabezpieczonym kluczami publicznymi (na przykład przez ssh). Jednak żaden z dostawców kontroli wersji, na który patrzyłem, nie oferuje czegoś takiego. W przypadku współpracy naukowej cechy „korporacyjne” podkreślane przez wiele z tych firm nie są bardzo ważne (wiele oddziałów, integracja ze trac, audyt przez strony trzecie, hierarchiczne zespoły projektowe). Ale różnice na poziomie słów wydają się krytyczne, ale nie są obsługiwane. Z mojego doświadczenia wynika, że ​​z różnicami na poziomie linii dla plików tekstowych każdy musi unikać formatowania akapitów i edytorów, które zmieniają tabulacje na spacje lub odwrotnie, powodują problemy; wydaje się również, że istnieje wiele fałszywych konfliktów edycji.

Zobacz powiązane pytanie w MO na temat narzędzi do współpracy i powiązane pytania na TeX.SE, dotyczące kontroli wersji dokumentów LaTeX i pakietów LaTeX do kontroli wersji . Zobacz także tabelę porównawczą hostingu SVN, która zawiera dużą listę dostawców hostingu dla jednego z głównych systemów kontroli wersji.

Edycja: Odpowiedź Jukki Suomeli na pytanie TeX.SE „ Najlepsze narzędzia różnicujące i scalające rozpoznające LaTeX-a do subwersji ” wydaje się być jak dotąd najlepszą sugestią, obejmującą sposób interpretowania delt na poziomie słów. Ponadto Jukka wyjaśnił, w jaki sposób różnice między kolejnymi wersjami na końcu repozytorium są oddzielone od różnic na poziomie użytkownika wykorzystywanych do wykrywania konfliktów i łączenia zmian. Odpowiedź Jukki na TeX.SE wyraźnie wyklucza jednoczesne edycje i scalanie, polegając zamiast tego na tradycyjnym atomowym tokenie edycji, aby uniknąć konfliktów edycji. Wyjaśniając (i modyfikując) moje oryginalne pytanie, czy istnieje sposób, aby zapewnić, że konflikty edycji można rozwiązać na podstawie różnicy słów, a nie na podstawie różnicy między wierszami? Innymi słowy, możewdiffczy podobne narzędzia mogą być zintegrowane z częścią kontroli wersji narzędzia do wykrywania konfliktów , podobnie jak sposób ignorowania różnic na końcu linii i różnic w białych znakach?

Użyłem git do współpracy przy niektórych dokumentach napisanych w lateksie. Będziesz musiał przestrzegać kilku zasad:

• Rozpocznij każde zdanie od nowej linii, lateks ignoruje te nowe linie, o ile nie ma pustej linii
• Użyj tej samej konfiguracji do formatowania (tabulator / spacje / maksymalna szerokość tekstu)
• Aby uzyskać najlepsze wyniki, utwórz plik .gitattributes w repozytorium i dodaj wiersz *.tex diff=tex. To sprawia, że ​​diff zdaje sobie sprawę ze składni tex i prowadzi do bardziej znaczących wyników.

Następnie możesz użyć git diff --color-wordsi, gitk --color-wordsaby zobaczyć różnice między słowami (zobacz także ten artykuł Różnice między słowami w Git, w jaki sposób skonfigurować git, aby zawsze korzystał z algorytmu różnicy słów do wyświetlania dziennika git diff / git).

Aby zmniejszyć ręczne scalanie, mogę zalecić stosowanie osobnych plików dla sekcji i podsekcji (w zależności od rozmiaru dokumentu).

Proponuję spojrzeć na:

LaTeX / Collaborative Writing of LaTeX Documents ,

i powiązany dokument:

Narzędzia do wspólnego pisania naukowych dokumentów LaTeX .

Naprawdę chcę powtórzyć innym i zasugerować, abyś usiadł i opracował niezłą strategię SVN. Używam SVN do hostowania całej mojej struktury „badawczej”:

• Zarządzanie referencjami JabRef
• Pobrane pliki PDF
• Artykuły

Jest świetny, ponieważ zawiera wszystko i oczywiście zapewnia historię. Zastrzeżenie polega na tym, że potrzebujesz własnego serwera. Ale jeśli masz już istniejącą maszynę z systemem Windows (lub cokolwiek, z czym czujesz się komfortowo), możesz ją zainstalować po prostu za pomocą VisualSVN Server . Następnie tworzysz odpowiednie konta dla współpracowników i dajesz im dostęp do odpowiedniego obszaru (tj. Być może dostęp do odczytu do pliku bibtex JabRef i odczyt / zapis do udostępnionego obszaru artykułów w toku).

TortiseSVN może być używany jako klient Windows do interakcji z SVN. Musisz być ostrożny przy przenoszeniu / usuwaniu plików i kopiowaniu folderów (SVN będzie przechowywać metadane w ukrytych folderach w każdym z twoich folderów, więc musisz wykonać polecenie usuwania z SVN, aby się go pozbyć, zajmuje to trochę czasu, zanim się przyzwyczaisz , ale jest warta inwestycji).

Następnie, pracując ze współpracownikiem, muszą oczywiście używać SVN. Ale znowu inwestycja w naukę nie jest bezwartościowa. I przez pewne przemyślenia, możesz je również mieć, abyś miał dostęp tylko do odczytu do ich pliku jabref (być może za pośrednictwem narzędzia „zewnętrznego” w svn).

W ten sposób, przy odrobinie przemyślenia i wysiłku, możesz znaleźć się w sytuacji, w której edytujesz dokumenty jak zwykle, zatwierdzasz zmiany w nocy, aktualizujesz rano i łatwo rozwiązujesz wszystkie konflikty.

Naprawdę polecam. Im więcej osób utworzy własne SVN, tym lepiej, ponieważ poprawi to jedynie opcje współpracy w przyszłości (choć oczywiście byłoby korzystne, gdyby istniał „standardowy” sposób utworzenia naukowego repozytorium).

- Edycja: Faktycznie, napisałem tutaj taką propozycję: Strategia współpracy naukowej z LaTeX i SVN . Proponuje wykorzystanie funkcji zewnętrznych svn, aby umożliwić łatwą współpracę między osobami o podobnej konfiguracji. Daj mi znać, jeśli wymaga zmiany lub jest po prostu nieodpowiedni.

Czytając świetny post i sam szukając rozwiązania, natknąłem się na opcję pokolorowania zmian na poziomie słów w gitk . Parametr gitk wydaje się być nową i / lub nieudokumentowaną funkcją, ponieważ automatyczne uzupełnianie go nie oferuje, a strona man gitk nie wyświetla go.
Oto opcje, które znalazłem:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

Możesz znaleźć kilka dyskusji na ten temat, szukając gitk „diff --color-words” .

Edycja:
Tak to wygląda ...

Bardzo dobrze rozumiem problem. Zacząłem używać Kalejdoskopu do diffów z git. Jest to tylko Mac, ale jego porównania działają lepiej niż wdiff, a także ma interfejs i aktualizacje na żywo.