LINUX.ORG.RU
ФорумTalks

Посоветуй: GIT или что-либо иное?

 , , ,


1

2

Всем приветик снова и хороших выходных (заранее)

Началось свободное время, хочу его занять. Чем занять - уже нашел :)

Недавно потребовалось решить вопрос с коллективной работой над файлами в формате .odf (Libre|OpenOffice). Коллективный режим работы я изучал, скуриваясь в манах, однако оно нормально не пашет. Поэтому я решил повернуть свой взор в сторону систем управления версиями.

Гугление и Яндексение показало, что Либру/Опену хорошо использовать с Git...вроде все понятно и даже разжевано для дурачков. Но это уже оффтоп.

UPD: Да, я фактически ищу аналог Гугл-документам. К счастью в моем окружении знают, что такое опеноффис и ЛаТеХ.

А есть другие системы, такие как Mercurial, например. Я пока не могу понять, что из них лучше. ТЗ простое: берется сферический сервак, в него вбабахивается система управления версиями. Я и мои коллеги работают с документами/схемами: они - в OpenOffice, я соответственно в LibreOffice. Я делаю кусок в файле foo.odt, кидаю в сервак с пометкой, где что надо доделать и перепилить. Коллеги редактируют у себя, потом перезаливают новую версию. И так далее. Хочу такую, цепочку сделать, чтобы можно было в крайнем случае отбэкапить прошлую версию, в которой могло остаться что-нибудь сверхважное. Однако возник вопрос - какую систему контроля взять, чтобы можно было быстро «развернуть, разобраться и работать»?

Заранее спасибо! :))

P.S. И прошу высказать мнение относительно этих книжек. Нормально ли они написаны?

★★★★★

Последнее исправление: Klymedy (всего исправлений: 3)

В роли системы управления версиями Git - говно. Как средство обмена патчами - наверное, юзабельно.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Даже если так:

Я делаю кусок в файле foo.odt, кидаю в сервак с пометкой, где что надо доделать и перепилить. Коллеги редактируют у себя, потом перезаливают новую версию. И так далее. Хочу такую, цепочку сделать, чтобы можно было в крайнем случае отбэкапить прошлую версию, в которой могло остаться что-нибудь сверхважное.

??

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от bookman900

Даже если так:

А если вы работаете над одним файлом, можно вообще без DVCS.

tailgunner ★★★★★
()

ТЗ простое: берется сферический сервак, в него вбабахивается система управления версиями.

Можно не мучиться с настройкой сервака, а создать приватный репозиторий на битбакете и синхронизировать все изменения, сделанные командой, через него.

P.S. И прошу высказать мнение относительно этих книжек. Нормально ли они написаны?

Книги нормальные. В первой редакции Pro Git стоит прочитать вторую главу и уже можно идти и делать коммиты.

Если из odf можно извлечь текст для сравнения, то вообще проблем нету показывать текстовую разницу между версиями odf-документа таким образом: http://git-scm.com/book/ru/v1/Настройка-Git-Git-атрибуты

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от EXL

Если из odf можно извлечь текст для сравнения, то вообще проблем нету показывать текстовую разницу между версиями odf-документа таким образом: http://git-scm.com/book/ru/v1/Настройка-Git-Git-атрибуты

http://www-verimag.imag.fr/~moy/opendocument/

aidan ★★★★
()
Ответ на: комментарий от rupert

В роли системы управления версиями Git - говно. Как средство обмена патчами - наверное, юзабельно.

пять звёзд и такое сказануть...

А ты однозвездный, но очень умный? Тогда ответь мне на вопрос: Анонсирована система управления репозиториями Kallithea (комментарий)

tailgunner ★★★★★
()

Никакой нормальной коллективной работы не получится ни с одной VCS. odf - бинарный формат. Будет так, что один человек работает, остальные ждут. Потому как если они тоже будут делать изменения, то только один человек сможет закоммитить свои изменения, а остальным прийдется откатывать свои локальные изменения и делать их опять. В общем геморой еще тот. Нужна система, которая позволяет лочить файл на сервере. Тогда, как я уже и сказал, все будут сидеть и тупо ждать пока один человек, который залочил файл, закоммитит свои изменения и разлочит его.

rupert ★★★★★
()
Ответ на: комментарий от rupert

Спасибо :) Я ждал примерно такого ответа.

Возрикла просто проблема: зарубежные коллеги, опасаясь, что у нас в стране с ай-ти творится хаос, решили пееключиться с коллективной работы ч гугл-документах на простое присылание доков в .odt. В связи с этим я задумался об использовании таких систем.

На самый крайняк я уже подумываю о кодинге через ЛаТеХ, и теоетически тогда cvs уже тут уместны. Просто иногда у нас и полуяается, что я вот сделал часть текста, отсылаю в «общак», грубо говоря заваливаюсь спать, в это время коллеги там либо совместно, либо по очееди работают дальше.

Такая же штука и с .odg

bookman900 ★★★★★
() автор топика
Последнее исправление: bookman900 (всего исправлений: 1)
Ответ на: комментарий от EXL

А ведь мог бы и CVS посоветовать... :)

Но я с ним дела не имел, про его преимущества не знаю

Harald ★★★★★
()
Ответ на: комментарий от EXL

И тебе спасибо :)

С битбакетом имел дело один раз. Радует, что клиенты под 3 платформы есть.

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Ты что думаешь, что я буду возиться с твоей проблемой? Git тут скорее всего не причем. Возможные причины:

1. ты не умеешь нормально использовать git
2. тот кто сделал эти изменения, тоже не умеют использовать git эффективно, и (например) сначала удалили файлы, а потом закоммитили их с новыми именами.
3. и еще куча причин, которые зависят от конкретной истории изменений. Подними историю, если ты думаешь, что ты не профан в Git-е, и посмотри, что конктретно там произошло.

PS:
Я тут с одиним чуваком обсуждал Git. Он говорит, типа, Git - говно, SVN - нашевсе, нафига мне эти бранчи, я и в SVN могу все забранчить и замёрджить. А потом я посмотрел, как он это делает: отдельные файлы копирует ручками из одного бранча в другой (а их всего два: dev и trunk). В результате половина изменений не прошла (он их просто забыл скопировать), trunk поломан, не говоря уже о том, что история изменений и мёрджей при таком ручном копировании теряется (я посмотрю, как он будет резолвить конфликты в следующий раз - вероятно с матюгами).

А мораль какова? В 99% случаев люди просто не знают как пользоваться инструментом, а кричат, что все дерьмо.

rupert ★★★★★
()
Ответ на: комментарий от bookman900

Я имел в виду .odt (текст), и .odg (векторная графика).

Да пофигу. И то, и другое - xml в zip'е. И то, и другое без костылей в СКВ нормально храниться не будет (бинарями), с костылями (xml'ем) будет ок.

Stil ★★★★★
()
Ответ на: комментарий от rupert

Ты что думаешь, что я буду возиться с твоей проблемой?

Я думаю, что ты не ответишь на вопрос.

ты не умеешь нормально использовать git

Но как нормально пользовать его, ты не покажешь. Какой сюрприз.

Подними историю, если ты думаешь, что ты не профан в Git-е, и посмотри, что конктретно там произошло.

Я это сделал и точно знаю, что произошло. Теоретически Git должен это обрабатывать, а на практике не обрабатывает. Это одна из причин, по которой он говно.

Я тут с одиним чуваком обсуждал Git

Всем пофиг на твое мнение.

tailgunner ★★★★★
()
Ответ на: комментарий от n_play

что-то ещё из заявленного там неработает?

Из заявленного где? По сравнению с Mercurial, отсутствует revsetsfilesets, хотя это менее важно), evolve, а CLI сделан инопланетянами для своих добровольных рабов.

Git не моя основная рабочая система, так что я не знаю всех его косяков - только очевидные.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

до этого, был явный конкретный пример, что в git заявлено «автоматическое распознание чего-то там», но оно несработало.

имеется что-то ещё из оффициально заявленного, что там неработает?

n_play
()
Ответ на: комментарий от n_play

имеется что-то ещё из оффициально заявленного, что там неработает?

Из того, чем пользуюсь я - только log. И, как я сказал, это только одна из причин.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

ясно. Были предположения, что что-то ещё подобное нашлось там. спасибо

n_play
()

Да нормально всё с гитом для этих задач. На твоём бы месте использовал самописную утилиту которая сканирует проект и делает коммиты - так меньше возможности накодить в гите лажу, с которой трудно или невозможно разобраться. От главначальника проекта потребуется лишь кликнуть по одной из нескольких ссылок а потом набрать «git push». Ну и почитать как заводятся ветки проекта и в чём отличия посылать данные в них. Каждый разработчик заводит в проекте по своей ветке и пишет в неё свои версии файлов (тоже пользуется твоей же утилитой, только отправляет данные не в master а в свою ветку), ты всё это изучаешь, складываешь нужные версии файлов в проекте на локалхосте, кликаешь по ссылкам и отправляешь через «git push» в мастер ветку проекта на сервере. Только тебе придётся координировать работу и договариваться, кто чем будет заниматься.

Napilnik ★★★★★
()
Ответ на: комментарий от rupert

Никакой нормальной коллективной работы не получится ни с одной VCS. odf - бинарный формат. Будет так, что один человек работает, остальные ждут.

Это только если разрабатываемый файл 1. Но задача главврыбы главнюка проекта разбить сабж по главам/файликам чтобы можно было поручить народу по работе над одним файлом. Естественно, с разрешаемым форматированием придётся решать так, чтобы всё можно было копипастить в итоговый проект и оно не засирало файл. Идеальное своё форматирование, для писателей глав, в таком случае - пробелами и маркерами конца строки, но и из неидеального можно подобрать безопасные шняги действующие локально.

Napilnik ★★★★★
()
Ответ на: комментарий от bookman900

Кстати, sharelatex не пробовали использовать?

И если в «ай-ти хаос», то достанется со всех сторон. Тот же гитхаб уже блокировали.

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)

коллективной работой над файлами в формате .odf

если не будет сложного форматирования, то можно попробовать owncloud, там есть групповая правка odt.

ptah_alexs ★★★★★
()
Ответ на: комментарий от tailgunner

Это при том, что драйверы в ядре со времен 2.6.31, но няшка git не видит, что они переименованы.

Просто его попросили вывести лог для «drivers/net/ethernet/xilinx/ll_temac*», он и вывел. До переименования файлов по этому пути вообще не было. Для одного файла он может проследить историю с учётом переименований (--follow). Для нескольких нельзя, потому что Линус добавил этот ключ из жалости к «людям с особыми потребностями». В конце концов, bisect переименования не ломают, а если очень хочется, то можно с show --stat глянуть, где файлы были до b13ad8f.

ilammy ★★★
()
Ответ на: комментарий от rupert

2. тот кто сделал эти изменения, тоже не умеют использовать git эффективно, и (например) сначала удалили файлы, а потом закоммитили их с новыми именами.

Гиту монопенисуально, удалил ты сначала файл и воссоздал или переместил; гит не отслеживает историю файлов. А ты феерически слился.

iVS ★★★★★
()
Ответ на: комментарий от iVS

гит не отслеживает историю файлов

О, как хорошо, что ты это написал.... Еще не начал git изучать :)

У меня как раз в ТЗ есть микро-пункт: чтобы была история файлов, чтобы можно было вернуться, например, с техвыборки_26 на техвыборку_12, в котором убрали кусок инфы, а его (кусок этот) слили зря. Мы с коллегами возвращаемся назад, вытаскиваем, и продолжаем городить проект :)

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от bookman900

Тогда бери Mercurial, там к истории файлов относятся лучше.

P.S. И вообще, новичку Mercurial проще, поддержка на BitBucket есть.

iVS ★★★★★
()
Последнее исправление: iVS (всего исправлений: 1)
Ответ на: комментарий от niemand

Версионную ФС бери

Спасибо. Идея заманчивая, но есть проблема: некоторые коллеги работают под убунтой, некоторые под макомОС, нескоторые по Виндоуз. А так концепция хорошая. Мне понравилась :)

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от bookman900

под убунтой, некоторые под макомОС, нескоторые по Виндоуз.

ООО «Рога и копыта» какое-то. У нормальных людей берется ось со всем необходимым, делается снимок диска, а дальше разворачивается везде, где надо. Унификация!

niemand
()
Ответ на: комментарий от niemand

Коллабораторы из разных стран и разных организаций пишут статьи, скорее всего научные. Всем разлить одну систему?

greenman ★★★★★
()
Ответ на: комментарий от niemand

Сам придумал, или я не внимательный?

Экстраполировал (Возрикла просто проблема: зарубежные коллеги, опасаясь,).

В odf?

Если в каких-то областях науки принимают doc, то почему нельзя допустить, что где-то принимают opendocument?

greenman ★★★★★
()
Ответ на: комментарий от niemand

Сам придумал, или я не внимательный?

Нет, так и есть. Есть друзья-коллеги из Канадского колледжа.

В odf?

Да. Когда я гуглил систему CVS в связке с .doc/.docx, то я выяснил, что формат Некрософт Офиса настолько ****ный, что от идеи использования продукции уг-оффтопа я как организатор и руководительно социолог. проекта отказался. По счастью я узнавал, что LibreOffice они ваще не вкуряют, что это такое. Хотя да, тут я долго ржал - я думал друзья-студенты-коллеги из технически направленного государства просто обязаны знать, что такое LibreOffice, но нет. Про OpenOffice они слышали и даже юзали, что выправляло ситуацию. Отечественных коллег переводить на LibreOffice долго не пришлось - вероятность успеха проекта превысило всякие «фи» относительно насильного перехода в другую офисную систему :))

Схема получается немного костыльная: связка детища OpenDocument Foundation и VCS для того, чтобы можно было править тексты/схемы, когда внезапно гугл забанят в России. Возможно тебе тут покажется, что я анальный параноик и не слущаю диванных экспертов с ЛОРа, но я остаюсь при своем мнении, ибо пример с GitHubом показал всю силу подобного исхода, а с vps мои коллеги наотрез отказываются париться, ибо они не понимают что это такое, а «неудачный контент-анализ» сайтов и СМИ убедил их в том, что это противозаконная технология, из-за чего переубедить в обратном я не могу теперь. Но как социологи они грамотные, оттого мне и пришлось придумывать костыли, чтобы все были довольны [ну и мой ЧСВ в области внедрения opensource в социологийческий продакшен тое вырос. Куда ж без него :)]

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от greenman

Если в каких-то областях науки принимают doc, то почему нельзя допустить, что где-то принимают opendocument?

Вообще да, работа и финальное создание частей исследования ведется строго в word. Но ИМХО и после анализа гугла, получается, что word и коллаборация в лице vcs - это противоположные вещи. Да, есть Word онлайн, но его могут забанить. Есть в Word2013 возможность эффективной коллаборации, однако банально не у всех есть ворд 2013, а именя только 2010 на винде, на кальке и 2011 на маке, которые плохо дружат с этим понятием «коллаборация».

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от greenman

Кстати, sharelatex не пробовали использовать?

Да. Но он висит как аварийный вариант. Просто латехом пользоваться не совсем охота ввиду того, что генерим кучу черновиков....ну некоторые отечественные коллеги просто упорятся «кодить» (они именно так это и называют) свои идеи :)

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от ilammy

Просто его попросили вывести лог для «drivers/net/ethernet/xilinx/ll_temac*», он и вывел.

Его попросили историю с учетом схожести файлов.

Для одного файла он может проследить историю с учётом переименований (--follow).

Спасибо. Хоть кто-то ответил - ЛОР определенно не бесполезен.

Для нескольких нельзя

Хм. То есть< хотя ошибку он не выдает, но результаты неправильные?

Линус добавил этот ключ из жалости к «людям с особыми потребностями»

Вот-вот... git - система, сделанная Линусом для Линуса.

tailgunner ★★★★★
()
Ответ на: комментарий от kernelpanic

Похоже тебе нужно что-то типа Alfresco

Тоже чета посмотрел в сторону их бесплатной шняги. Коллектив - 6 человек, из них 4 актив, 2 иногда подключаются...вроде ничего :)

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от kernelpanic

Попробовал через стек bitnami... какое-то глючное поделие, однако....

Да еще отдельно tomcat требует....и нифига не завелось под калькулятором...попробую тогда VM-образ

bookman900 ★★★★★
() автор топика
Ответ на: комментарий от kernelpanic

Кароче нашел способ нормально запустить.

Да, ты прав. Система хороша....но она ненужна. Ненужна она потому, что перегружена. И от идеи Гугл-Документов она очень далека: Да, есть 1 главный файл, который дробится на несколько более мелких. И с более мелкими уже работаем.

Но все равно спасибо, идея была хорошая...но коллектив крошечный...и нам энтерпрайз вряд ли понадобится :)

bookman900 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.