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


20

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?


3
Nie do końca rozumiem pytanie. Na przykład w SVN różnice wyświetlane dla użytkownika są generowane przez klienta i zależy od klienta SVN (i jego konfiguracji), czy otrzymujesz różnice oparte na słowach, czy różnice liniowe. Firma, która hostuje twoje repozytorium SVN, w ogóle na to nie wpływa.
Jukka Suomela,

2
@suresh Jeśli edytujesz (zapisujesz) dokumenty tekstowe, często trudno jest zeskanować całą linię w pliku różnic, aby zobaczyć, że ktoś zmienił jeden przecinek. Prawidłowe zachowanie zwykle polega na pokazaniu minimalnej jednostki zmiany. Lub rozważ zachowanie, jeśli ktoś nie używa podziałów linii. Następnie zmiana jednego słowa spowoduje wyświetlenie całego akapitu w pliku różnicowym, aby znaleźć drobną zmianę.
Mark Reitblatt,

2
Nie używam twardego podziału linii do zawijania linii. W moim kodzie źródłowym lateksu fizyczny wiersz tekstu jest zwykle pełnym akapitem tekstu. Edytor może zawijać słowa w celu wyświetlenia, w zależności od bieżącej szerokości okna. To bardzo upraszcza rzeczy; nigdy nie trzeba się martwić takimi rzeczami, jak to, że powinienem ponownie zawinąć tekst w akapit lub uzgodnić „właściwą” szerokość linii ze swoimi współautorami. Będziesz jednak potrzebować narzędzia porównywania na poziomie słów, aby szybko zobaczyć zmiany.
Jukka Suomela,

2
@Andras Chodziło mi o to, że system VC musi być w stanie odtworzyć tylko dwie wersje po stronie klienta, i nic dziwnego, że wszystkie systemy VC mogą to zrobić. To, czego potrzebujesz, to narzędzie do scalania na trzy słowa na poziomie słowa, ale nie znam żadnego. (Na przykład, TortoiseMerge i kdiff3 są oparte na linii.) Gdy będziesz mieć takie narzędzie, wystarczy dowolny system VC, który pozwala określić zewnętrzne narzędzie do łączenia. (Obejmuje svn, bzr, git, hg ...)
Maverick Woo

3
Jednym ze źródeł nieporozumień jest to, że istnieje wbudowany algorytm binarnego mechanizmu różnicowego (działający na poziomie pojedynczych bajtów), który jest używany przez SVN w komunikacji między serwerem a klientem, a także wewnętrznie przez serwer do przechowywania repozytorium kompaktowy. To tylko optymalizacja; nie jest widoczny dla użytkownika, a ten sam algorytm różnicowania binarnego można zastosować do dowolnego rodzaju pliku. Wszystkie rzeczy widoczne dla użytkownika (różnice czytelne dla człowieka, scalanie, rozwiązywanie konfliktów ...) zdarzają się po stronie klienta.
Jukka Suomela

Odpowiedzi:


11

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).


Rozważę zrobienie tego dla moich własnych dokumentów, wydaje się to łatwym sposobem na osiągnięcie większości moich celów. Ale nie wszyscy chcą pracować w ten sposób ...
András Salamon

2
Dla ludzi, którzy wahają się pracować w ten sposób, możesz użyć TortoiseGit, jeśli nie podoba im się wiersz poleceń git. Jeśli chodzi o każde zdanie w nowej części wiersza, o ile nie jest wymuszona maksymalna szerokość tekstu, nie jest to tak ważne. (Pracowałem nad niektórymi projektami bez tej zasady)
Davy Landman

Ogólnie rzecz biorąc, zgadzam się, że git to dobry wybór. Ale dlaczego oddzielne pliki dla (pod) sekcji zmniejszają liczbę ręcznych połączeń? Zastanawiam się także, jak pomaga rozpoczęcie każdego zdania w nowej linii (czasami zdania mieszają się w trakcie edycji).
dd1,

odnośnie rozdzielania plików: w tym czasie nie rozumiałem dokładnych szczegółów łączenia git, więc jest to właściwie niepotrzebne, ale nadal wskazane z innych powodów. Zdanie na nowej linii jest bardzo ważne, ponieważ większość narzędzi wokół git zawsze pokazuje zmiany linii, jeśli użyjesz innej strategii, powiedzmy, że pozwól redaktorowi na łamanie linii, za każdym razem, gdy ktoś zmieni 1 słowo w akapicie, będziesz musiał polować na tak się dzieje, aw przypadku automatycznego łączenia: nie ma mowy.
Davy Landman


4

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.


4

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 ...

Różnice zabarwione na poziomie słowa za pomocą gitk


1

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.


2
Wydaje mi się, że Kalejdoskop jest po prostu narzędziem różnicowym opartym na linii, które dodatkowo uwypukla zmiany wewnątrz każdej linii. Nie zastępuje wdiff i przyjaciół. Kalejdoskop powoduje powstanie nieczytelnych różnic, jeśli np. Weźmiesz akapit tekstu i zmienisz niektóre linie podziału. Narzędzia oparte na Wdiff po prostu ignorują zmiany podziałów linii.
Jukka Suomela,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.