Wspólne narzędzia dla manekinów / profesorów

Załóżmy, że współautorzy z dwóch lub więcej różnych instytucji piszą papier w lateksie i chcieliby zrobić coś lepszego niż wielokrotne przesyłanie szkiców w tę iz powrotem.

Zdają sobie sprawę, że mogą bezpłatnie otworzyć konto Dropbox, udostępnić hasło i zsynchronizować wersję papierową na swoim komputerze z wersją na Dropbox. Jeśli dwie osoby jednocześnie edytują tę samą sekcję, będą się wzajemnie nadpisywać.

Słyszeli także, że systemy kontroli wersji, takie jak SVN i Git, mają narzędzia do scalania jednoczesnych zmian, które działają dość dobrze. Dokumentacja tych produktów jest jednak trudna do odczytania i bardziej skupia się na tym, jak cofać zmiany i jak zarządzać różnymi „oddziałami”, niż na podstawowych potrzebach współautorów piszących artykuł.

Czy istnieje prosta prezentacja krok po kroku na temat korzystania z systemu kontroli wersji w tej konfiguracji:

• Centralne repozytorium
• kopie lokalne
• „inteligentne” scalenie
• bez oddziałów

?

Który ze standardowych systemów kontroli wersji jest najłatwiejszy w użyciu? (Mówimy tutaj o teoretycznych profesorach informatyki).

Czy są jeszcze prostsze narzędzia, które synchronizują się tylko z inteligentnym scalaniem, bez kontroli wersji?

Z drugiej strony, czy ludzie, którzy używają systemów kontroli wersji, aby nawet napisać artykuł jednego autora, naprawdę uważają, że funkcja nieograniczonego cofania jest warta dodatkowej złożoności?

Po pierwsze: jeśli jesteś zainteresowany edycją grupową w czasie rzeczywistym, spróbuj czegoś takiego jak gobby . Pozwala dosłownie edytować dokument w tym samym czasie.

Jeśli chodzi o systemy wersji, znam tylko SVN. Oto, co robisz po zainstalowaniu subversion, oczywiście:

1. Poproś kogoś o utworzenie repozytorium i podanie adresu URL, nazwy użytkownika i hasła
2. Przejdź do miejsca, w którym chcesz mieć kopię lokalną
3. W powłoce (wiersz poleceń?) Wpisz: svn co url://to.your/repository(wymeldowanie). Teraz pojawia się nowy folder z zawartością repozytorium.

To wszystko. Teraz najbardziej podstawowe polecenia:

• Za każdym razem, gdy dodajesz nowy plik foo, wprowadź:svn add foo
• Ilekroć chcesz usunąć plik, wprowadź: svn rm foo
• Po wprowadzeniu zmian wprowadź: svn ci(zameldowanie)
• Ilekroć chcesz otrzymywać najnowsze rzeczy, wpisz: svn up(aktualizacja)

Istnieją również polecenia do przenoszenia, kopiowania, rozgałęziania, rozwiązywania konfliktów, ... ale dopóki nie wypróbujesz śmiesznych rzeczy, nie masz nic przeciwko powyższym. Jeśli coś się psuje lub wydaje się, że coś się zepsuło, zrób kopię zapasową swoich edycji, usuń cały folder i odtwórz wszystko od nowa. To jest dla svn jak restart systemu Windows.

Dodatek: Widzę, że martwisz się „inteligentnymi połączeniami”. Zakładam, że masz na myśli scalone różne wersje pliku, przy założeniu, że dwie osoby dodawały różne elementy w rozłącznych częściach dokumentu. O ile mi wiadomo, svn potraktowałoby to jako konflikt i prawdopodobnie słusznie. Nie sądzę, że istnieje ogólna procedura, która zapewnia, że ​​dostaniesz to, czego chcesz, po tym, jak dwie osoby zmanipulowały to samo źródło. Istnieją graficzni klienci svn, którzy wizualizują takie konflikty i pomagają je rozwiązać; są w zasadzie różnymi przeglądarkami, w których możesz wybrać, którą wersję zachować dla każdej sprzecznej linii). Będzie to jednak wymagać pracy.

Zauważam, że nikt nie daje „małego” samouczka dla GIT , więc postaram się to opisać. GIT jest szybszy i lepszy od SVN, ale może łatwiej jest założyć konto SVN na serwerze na twojej uczelni, ponieważ SVN jest dobrze ugruntowany. Również twój współpracownik wiedziałby, jak z niego korzystać.

Nawet jeśli współpracujesz przy użyciu SVN, możesz chcieć użyć GIT do własnej lokalnej wersji (ja tak!).

Pierwsze ostrzeżenie : GIT jest bardzo potężny, a do podstawowego użycia jest tylko nieco trudniejszy w użyciu niż SVN (np. Jedna opcja do dodania w wierszu poleceń; dwa kroki zatwierdzenia dla centralnego repozytorium).

$\Delta$

Podstawowe polecenia zakładające, że masz już repozytorium

• Sklonuj repozytorium: git clone <url>
• Zaktualizuj lokalne repozytorium: git pull <repo>lub po prostu git pullsklonowane jak powyżej.
• Polecenie pull naprawdę działa zarówno, jak git fetchi git merge. Pierwsze „pobieranie” rzeczy z serwera centralnego, a drugie zastosowanie scalania plików i serwera.

Scalanie odbywa się automatycznie, o ile nie ma jednoczesnych edycji w tych samych częściach niektórych plików. Jeśli scalenie się nie powiedzie, katalog roboczy pozostaje w „stanie scalenia”, co oznacza, że ​​musisz naprawić konflikty, a następnie musisz zatwierdzić scaloną kopię. Jeśli nadal masz niezarządzane konflikty w swoich plikach, zatwierdzenie ponownie się nie powiedzie, nie zostanie popełnione śmieci.

• Dodaj nowy plik zostać popełnione: git add <file name>.
• Zatwierdź zmiany w lokalnym repozytorium: git commit -am "<textmessages>"lub git commit -ajeśli chcesz edytować komunikaty zatwierdzania.
• Przekaż zmiany z lokalnego repozytorium do centralnego repozytorium.

Zauważ, że aby wypchnąć zmiany do centralnego repozytorium, musisz najpierw zatwierdzić swoje repozytorium lokalne i musisz wypchnąć wszystkie zatwierdzenia (nawet więcej niż jedno) do centralnego repozytorium.

Utwórz lokalne repozytorium użytkownika

• Utworzenie repozytorium git initw dowolnym folderze, który lubisz.
• Gotowy!

Utwórz publicznie udostępnione repozytorium (również prywatne, jeśli płacisz gotówką) z ładnym GUI.

• Użyj GitHub

Utwórz skrzynkę z tylu prywatnych / publicznych repozytoriów z różnymi grupami użytkowników, ale bez GUI.

• Poproś o konto SSH bez hasła na dostępnym komputerze.
• Nie martw się, ponieważ uwierzytelnianie odbywa się za pomocą kluczy SSH.
• Zainstaluj Gitosis zgodnie z tym samouczkiem .
• Teraz możesz administrować własnym serwerem git, edytując pojedynczy plik i zatwierdzając go w repozytorium!

Git nie potrzebuje centralnego serwera : dowolny folder na twoim komputerze może być używany jako repozytorium, więc możesz grać z git i przełączać testy offline. Możesz zainicjować jedno repozytorium i symulować trzech współpracowników w trzech innych folderach bez wysyłania jednego bitu do sieci. Wynika to z faktu, że każda sklonowana kopia repozytorium jest repozytorium w pełni funkcjonalnym, do którego można się zatwierdzić. Jest to dobre, jeśli chcesz pracować w locie między USA, Chinami lub Europą.

Dokumenty Google ( https://docs.google.com ) zapewniają doskonałe narzędzia do wspólnego tworzenia dokumentów (w tym edycji w czasie rzeczywistym). Przechowuje wszystko online dla Ciebie i dobrze integruje się z Twoim kontem Gmail. Domyślnie Dokumenty Google nie są zgodne z LaTeX, ale możesz je włączyć, przechodząc tutaj:

http://docs.latexlab.org/

Nie jestem pewien, jak dobrze to działa w przypadku przywracania, ale jestem pewien, że jest w tym funkcja. Słyszałem o niektórych ludziach korzystających z wtyczki Google Wave LaTeX do opracowywania wstępnych szkiców do dokumentów.

Sprawiam, że moi współautorzy uczą się Mercurial, i zwykłem ich zmuszać do nauki Subversion. Jeśli jesteś fanem Subversion, po prostu przeczytaj to , to wszystko prawda.

Bez względu na to, jakiego systemu używasz, zdecydowanie najtrudniejszą rzeczą jest skłonienie drugiej osoby do zainstalowania oprogramowania i rozpoczęcia korzystania z niego. Skype jest idealnym rozwiązaniem. Najnowsze wersje Skype'a umożliwiają „udostępnianie pulpitu”, co naprawdę pomaga, gdy chcesz poprowadzić swojego współautora przez procedurę instalacji. I użyłem prostego udostępniania pulpitu w połączeniu ze Skype, aby napisać artykuł z moim współautorem. Działa całkiem dobrze.

Naprawdę potrzebny jest „Github dla naukowców”. Coś, co daje repozytorium, ma kontrolę wersji, wspólną edycję itp. Zgadnij, co to jest http://www.scribtex.com/ .

oto nowy internetowy edytor lateksowy o nazwie WriteLatex, który wygląda obiecująco, jako niemal kompleksowa baza do wielu potrzeb / wymagań w zakresie pisania artykułów naukowych.

• działa na urządzeniach mobilnych
• ma podgląd w czasie rzeczywistym
• łatwe / prywatne udostępnianie
• znajduje błędy lateksowe
• pozwala dodawać biblioteki / style lateksowe
• magazyn w chmurze

współautorem John Hammersley zamieścił ogłoszenie w TCS se meta tutaj a on reaguje na opinie (5 więcej głosów na reklamy i pojawi się na stronie głównej). wygląda na to, że z czasem może ewoluować w cenne narzędzie dla społeczności tcs i być może autorzy będą mogli wdrożyć niektóre popularne funkcje specjalnie na żądanie.

Co z prostymi systemami, rozwiązaniami:

• Dokumenty Google, pisarz Zoho ... i inne narzędzia do współpracy.
• Dropbox obsługuje sytuacje, w których dwie osoby próbują zatwierdzić zmiany w tym samym pliku. Druga osoba zobowiązująca się otrzymuje nazwę swojego pliku (X.txt -> X.txt_blabla ...) i oryginalny plik (X.txt) na najnowszą wersję. Więcej informacji: Pomoc Dropbox: „Co się stanie, jeśli dwie osoby zmienią ten sam plik?”

To nie wchodzi w rachubę, ale czasami zdarzają się sytuacje, w których część grupy jest zdolna do prostych rozwiązań, takich jak SVN, podczas gdy inna część grupy jest w stanie rozproszonej kontroli wersji, takiej jak GIT. W takich sytuacjach możliwa jest współpraca:

• git-svn - Operacja dwukierunkowa między repozytorium Subversion a git
• Git - SVN Crash Course
• Skutecznie używając Git z Subversion

Niedawno odkryłem sharelatex.com i użyłem go z moim współpracownikiem do współautorstwa artykułu. Tak bardzo mi się podobało, że moim obecnym planem jest wykorzystanie go do wszystkich moich projektów. Niektóre godne uwagi funkcje:

• TeXing w przeglądarce w czasie rzeczywistym (jak Dokumenty Google, ale stworzony dla TeXa, podświetlania składni i wszystkich innych).

• Kompilacja w przeglądarce i przeglądanie plików PDF

• Obsługuje projekty z wieloma plikami

• Posiada funkcję historii

• Synchronizuje się z Dropbox (wkrótce zostanie wydany publicznie, od obecnego stanu beta). W ten sposób możesz przenieść zapisywanie kopii zapasowych itp. Na Dropbox. W zależności od tego, jak to jest zrobione, powinno to również umożliwić korzystanie z sharelatex, nawet jeśli twoi współautorzy nie chcą, pod warunkiem, że chętnie korzystają z Dropbox do udostępniania plików.

• Możesz pobrać / załadować swój projekt w dowolnym momencie, więc nie utkniesz przy użyciu sharelatex, jeśli coś pójdzie nie tak, zmienisz zdanie lub cokolwiek innego.

Jedyny minus (ale myślę, że warto): chociaż korzystanie z sharelatex jest bezpłatne, niektóre jego funkcje nie są. W szczególności, aby korzystać z synchronizacji Dropbox (kiedy ją wypuszczają) lub jeśli chcesz, aby więcej niż 6 współautorów pracowało nad tym samym projektem sharelatex, musisz zapłacić 8 USD / mc. lub 80 USD rocznie [od kwietnia 2013 r.]. Jednak po wydaniu synchronizacji Dropbox wydaje mi się to bardzo uczciwą ceną.

[Oświadczenie: Nie mam żadnego związku z sharelatex lub jego pracownikami poza tym, że używam ich produktu.]

SVN jest narzędziem opracowanym w tym celu. Włożyłbym wysiłek, aby się tego nauczyć. Nie jest to bardziej skomplikowane niż nauka używania, powiedzmy, pakietu algorytm2e Latex lub jednego z pakietów Latex twórcy slajdów pdf.

Powiedziawszy to, używam CVS zamiast SVN. W naszej instytucji administratorzy CS mają lepszą obsługę (serwer SVN jest bardziej zarządzany przez użytkowników). Co więcej, doceniam to, że leżące u podstaw pliki wersji są nadal dostępne i można je edytować, jeśli coś pójdzie bardzo, bardzo źle.

Istnieją 2 wady w porównaniu do SVN. Nazwy plików nie są tak ładne, ale mogę z tym żyć (wybierz dobre imię za pierwszym razem). Drugi problem polega na tym, że do uzyskania dostępu do repozytorium potrzebne jest lokalne konto CS. Dlatego dostęp z innej instytucji jest możliwy tylko wtedy, gdy najpierw zostanie utworzone konto. Oczywiście nie oczekuję, że nigdzie będzie to prawdziwy problem; członek lokalnego oddziału prawdopodobnie może sponsorować to konto.

Lokalne ograniczenie dostępu wynika z faktu, że administratorzy nie chcą obsługiwać serwera. (Trudniejsze do zabezpieczenia itp.)