Как скачать копию проекта: Запускайте "Git GUI", "Repository - Clone..." "Source Location" нужно брать из "HTTPS Clone URL" слева на странице проекта. По завершению проект откроется автоматически.
Как загрузить изменения в проект: Снизу есть группа кнопок. "Rescan" - для обновления Unstaged Changes. Те изменения, которые перенесены в Staged Changes, будут добавлены в проект.
Для переноса из Unstaged используйте кнопку "Stage Changed" для всех или выберите нужные и нажмите в верхнем меню "Commit - Stage To Commit"
Кнопка "Commit" подготавливает файлы к загрузке. Перед нажатием на кнопку нужно написать Commit Message, конечно. Ну и "Push" для загрузки. Здесь нужно только выбрать один из "Source Branches" (в нашем случае - master) и нажать на "Push". После появятся окна для ввода логина и пароля.
Обновить локальную копию проекта можно через верхнее меню, "Branch - Checkout...", со стандартными настройками.
LOADING... 57%
Сообщение отредактировал steeldragon - Понедельник, 29.08.2016, 22:26
Эх. Мне кажется, нужно что-то поменять в самом устройстве работы с текстами, хотя даже я это сделать неоднократно пытался. Проблема в том, что меня-то и устраивает вот так вот «переводить на форуме», когда основные посты содержат правки текста, а последующие – правки к ним, и так далее. В итоге эти сорок страниц и набежали. И тут ничего сделать нельзя.
Вот явно же, инструмент должен быть походим, но другим. Вот чисто например: посты (вернее, их абзацы), на которые был дан кем-то ответ – должны выделяться цветом, становиться ссылкой… Чтобы время жизни одного кусочка текста можно было легко проследить, чтобы сразу было видно, что висит, что требует внимания, и что уже рассмотрено. Но я понимаю, что это нереализуемо. Тем более, создавать новый инструмент работы – вообще не вариант ну никак. Точно так же наше Хранилище не показало себя как удобный помощник процесса перевода – да, мы там хранили тексты. Но собирали мы их руками, заливали руками, создавали ТУТ. Идея обсуждений вКонтакте тоже провалилась. Вместо новых идей, мы кажется, получили только новое поле битвы, где за свои варианты фраз бороться надо уже не друг с другом, а с мало что понимающим левым народом, чьё мнение нам как бы формально и важно, но как мне помнится, не устроило.
Ха, ещё можно попробовать перенести что-нибудь в «пад». Уж в этом опыт у меня есть… Но нет, основные наши тексты туда как-то не особо полезно скидывать. Хотя из этого и может что-то получиться. Опять же, это просто инструмент. И им нужно уметь пользоваться по назначению. Есть разница между чатом стиля «двач», комментариями вКонтакте или конференциями в Телеграмме, нашим форумом, системой Issue гугль-кода, форк-бранч-пулл того же Гитхаба, голосовыми чатами Скайпа или Тимспика, и падом. – Каждое из этого создавалось для решения определённых задач, и НИЧЕГО нам нормально не подходит для нашей. Вести переписки на 20 000 символов где-нибудь вКонтакте или паде – ещё менее эффективно, чем здесь (скажем, отсутствием адекватного цитирования), но пад имеет преимущество в виде возможности редактирования общего документа своим цветом, Телеграмм/вКонтакте – доступностью, Гихаб – слиянием, но лишь если «продукт» не требует обсуждений, Тимспик – способностью быстро придти к решению конкретной задачи, прямо за несколько минут, а не днями и неделями при общении на форуме.
Да я и сам не понимаю, что за философию я тут развожу! Я лишь вижу, что что-то не так. Допустим, я заглянул в новенькую соседнюю тему по переводу субтитров к видео. ПИПЕЦ!
Там ж дохрена текста. И если переводить его на форуме – к новому году у нас будет либо овер-10 страниц и никакой надежды на приближающийся конец, либо просто какие-то наработки, которые все уже бросили, но которые в принципе можно релизнуть и будет не то чтобы совсем плохо. Мёртвый путь, даже я не могу представить, ЧТО мне придётся сделать. Нет, ну допустим, я захочу ответить (со мной такой бывает иногда). Для этого я потрачу один-три дня, чтобы последовательно собирать все цитаты, разметить документ, вписать все мои правки и пояснить их. Допустим, я отвечу. Далее, через пару кто-нибудь создаёт ответный пост, с цитатами моих правок (а для прослеживания цепочки придётся уже делать поиск по странице – это ещё если они на одной окажутся), а я должен в следующий раз и на его сообщение ответить, и продолжить ковырять первоначальный текст, полноценный ответ на который явно в предыдущее сообщение поместиться не мог. Ага, а далее появляется какая-нибудь Томас, которая расфигачит за денёк-другой ВСЕ тексты в десяти постах – и как бы всё, я умер. Не потому что не хочу, а потому что не могу. Это как тащить пианино на двенадцатый этаж – сколько бы я его не любил, и как бы мне не стало потом приятно на нём играть – я просто ЗАМАНАЛСЯ.
Конкретно эту тему, в смысле, задумку, с переводами видео – надо тащить в пад. Потому что больше некуда. Если она должна выжить – ей придётся покинуть форум, состоящий из зыбучего песка.
Пример, конечно, дерзкий. И у нас такого хаоса не будет никогда. Но суть ясна – исходный текст представляет себя блокнот белого цвета, а все авторы-переводчики – имеют свои цвета, которыми дописывают к нему всё, что пожелают. Основной принцип перевода для субтитров – одна строка это одна реплика. Переводы записываются напротив неё (длинные строки переносятся, но номер строки остаётся одним). Комментарии – туда же, праве. Ответы на них – туда. И так сколько угодно. Первый же плюс в том, что обсуждения одной строки находятся физически на ней, всё сразу видно. Всякие условности вроде оформления комментарием курсовом, итогового жирным или выбеленным, ошибок подчёркиванием и так далее – второстепенны.
Каждый может делать что угодно (но во-первых, на пад можно поставить пароль против левых людей, и плюс защиту на «зарегистрированный e-mail аккаунт» – против наших, но не своих), например – удалить весь текст. Но как видно, сохраняется таймслайдер – временная шкала, кто, что и когда делал, с возможностью выкопировать оттуда текст. Впрочем, если вся работа сведётся к ковырянию в истории – то это ничем не лучше листания наших форумных страниц.
Пад, когда является единственным инструментом – используется и как форум ( http://ponypad.etherpad.svimik.com/guidelines ), но это костыль. Почти такой же, как форумные вики страницы ( http://mlp.wikia.com/wiki/Forum:Speculation/Animation/Season_three ), чей ужас заключается в том, что новое сообщение – это новое изменение, а это – новая ревизия, требующая и краткое описание, и сохраняющаяся в лог с возможностью отката, не говоря уже о куче правил наподобие «не редактируйте чужие комментарии» (за нарушение которого этой ревизии дают откат, создавая новую с пометкой о нарушении) или «всегда подписывайте свои сообщения» (что часто плодит ревизии, потому что забыть очень легко, а исправить – значит отредактировать ещё раз; и уж тем более это получасовая задача – найти автора какого-нибудь старого поста, который забыл подписаться, чтобы по правилам хорошего тона, восстановить его же подпись – задача, потому что адекватного поиска «в какой ревизии появился этот текст» там нет, остаётся лишь тыкать наугад. Пока не осознаешь, что страница была получена после слияния или разделения другой…)
Как я уже сказал, переходить в пад для перевода основных реплик Spyro – идея не очень. Там в текстах – связи, там обсуждения, там важна последовательность диалога в цитировании, а не просто один комментарий к одной строчке. Насчёт атласа, яиц или ещё чего-нибудь – не знаю.
Но переводы видео обзоров и интервью лучше делать в паде. На форум можно либо копировать завершённые куски, либо обсуждать что-то, не повязанное на каждом конкретном кусочке текста.
Хотя, Piratenpad – не лучший вариант. На самом деле, владелец сервера svimik.com вполне себе не против, что его пады использовались и другими. Я тут даже аккаунтик нам создал: http://spyro3-rus.etherpad.svimik.com/ (вон в тот тестовый пад тоже можете тыкать без ограничений)
Тут просто чуть побольше фишек, чем в Пиратенпаде, но и есть небольшой риск того, что сервер не вечен.
ЦитатаSerlutin
aleksusklim, люди даже вон в гугл таблицах работать не хотят, а они легче, чем любой пад. Зашёл и пиши себе.
Цитата
а они легче, чем любой пад.
Я бы так не сказал.
Цитатаalteya
Что касается организации переводов. Как мне кажется, было бы неплохо если бы это в конечном счете выглядело примерно как мои сборки обсуждений: реплика - все коменты и варианты к реплике строго под этой репликой. Далее следующая реплика и коменты к ней (где каждый автор своего цвета, к примеру). Возможно, это как-кто в табличном виде, где например будут идти отдельной колонкой новые версии (только то что будет в тексте), и параллельно - всевозможные пояснения, ссылки, рассуждения. И возможность автоматически свернуть все промежуточные варианты, получив текущую версию всего текста.
Цитатаalteya
И чтобы все было просто как детская лопатка. Без всяких зубодробительных выстраиваний и вывешиваний тегов и прочей мути (иначе ноги моей там не будет).
Но что касается Spyro 3 - то думаю, поздновато изобретать велосипед, поезд уже ушел. Осталось не так уж много, и проще добить это как есть. Сосредоточившись на самой работе, а не на умозрительных изысканиях способа ее организации.
реплика - все коменты и варианты к реплике строго под этой репликой. Далее следующая реплика и коменты к ней (где каждый автор своего цвета, к примеру).
Вроде как, мой набросок оффлайн-пада подойдёт.
Цитатаalteya
И возможность автоматически свернуть все промежуточные варианты, получив текущую версию всего текста.
Ну некая поддержка этого у меня есть. Это как бы стиль «скрытый текст», сворачивающийся в «▉». Правда глобального раскрытия нет (но можно сделать), есть построчное, то есть визуально раскрывает всё скрытое на строке с курсором. Но если обсуждения построчные – тут нужен блок типа спойлера. Надо подумать.
Цитатаalteya
Без всяких зубодробительных выстраиваний и вывешиваний тегов и прочей мути.
Более того, если я адекватно привяжу экспорт в ВВ-коды, то из пада можно будет в любой момент вставить часть текста на форум без потери форматирования. И обратно тоже, надеюсь.
Цитатаalteya
Но что касается Spyro 3 - то думаю, поздновато изобретать велосипед, поезд уже ушел.
Вот сейчас у нас опять обсуждения паравозом поехали. Уже ваще не понятно, даже тут – на что НИЖЕ были даны ответы, а на что нет. И я именно про фразы. Да, основное обсуждение, разумеется, нужно вести тут. Но сами правки – да блин…
Причём, если будет прямое выкопирование (потенциально опционально прямо в этот визуальный редактор) – то без проблем можно будет вставлять свои правки в пад, а комментировать их (цитируя из пада) – тут. Тогда: – мы не потеряем привычный ход обсуждения фраз (то есть пад не заберёт нисколько от форума) – все реплики и все комментарии к фразам будут собираться в паде (как бы как копии, да…) – по идее, на это не будет уходить ТАК много времени, как например попытка скопировать кусок гугль-таблицы на форум, или внести разноцветные обсуждения на вики-страницу гугль-кода или в сам репозиторий.
Я представляю это так: 1) Синхронизировал свой пад с мастером-репозиторием (гитхаб, всё сведётся к одной кнопке; но сам транспорт на данный момент ещё пока не настроен) 2) Внёс в пад ЛЮБЫЕ изменения, комментарии, выбор финальных вариантов (думаю, условимся так, что тот, кто вносит правку – либо сам же и меняет ИТОГОВЫЙ вариант непосредственно, либо же, если исходная фраза явно чья-то личная – как у нас сейчас, по сути – оставляет правку, и её внесёт уже автор, если согласен). Варианты будут накапливаться не только тем, кто сейчас «держит» все данные об уровне (как steeldragon на гугль-коде, или как alteya сейчас: «внесла» – куда внесла? Понятно, что «себе», но это опять же нудная и неблагодарная работа – копипастить правки других, следить за ними и комментировать успевать. Я бы не смог. Вернее, я и не смог). 3) Синхронизировал пад ещё раз. Он преобразится: будут объединены текущие вносимые изменения, и изменения, сделанные другими за всё это время (которое, разумеется, может быть сколь угодно долгим). 4) Выкопировал куски из пада в свой пост на форуме, чтобы НЕ ТУТ предлагать правку, а просто констатировать факт её внесения. Тогда не придётся собирать вручную, потому что всё уже будет собрано там. 5) Ну и история. Собственная история изменений технически сохраняется подробнее, а глобальная – по непосредственным коммитам-синхронизациям; просмотр истории тоже оффлайновый. Автосохранение также имеет место: думаю, сделаю при потере фокуса у пада, может быть по таймауту (минута или полминуты) тоже можно. (Для справки: в онлайн паде автосохранение происходит каждые 500 миллисекунд!)
То есть ещё раз. При написании очередного поста в Ворде (и я, вообще говоря, не завидую тем, кто делает это не в нём) параллельно должен быть открыть мой оффлайн-пад. По сути это почти такой же Word, на вид. Правки – туда, копии – сюда. Обсуждения – сюда. Итоговые на данный момнет варианты – туда. Время и программы ни к чему не обязывают. Интернет не нужен, быстрый процессор тоже: пад, после превращения его в оффлайн, стал значительно меньше тормозить.
Однако, работать можно будет толкьо под Windows (любой версии), ну или с очень болшой натяжкой – под Linux. На планшетах или андроидах эта вещь не пойдёт (да, в отличие от гугль-доков, которые онлайн).
Так, чего я такой голословный. У меня же есть рабочая версия «онлайн-пада», прямо из которой я делаю оффлайн: http://klimaleksus.narod.ru/Files/D/TDTPad.rar (28 Мб; эта база всё равно понадобится для оффлайн-сборки) – он чуть плоховато настроен, но должен работать. Если я не ошибаюсь, достаточно запустить START.BAT, а потом зайти браузером на http://127.0.0.1:9001/ (или какой там порт в settings.json прописан…) Разумеется, сейчас я призываю оценить не его оффайновость или коллаборейт рантайм эдитинг, а чисто сам интерфейс (дизайн, особенно панель инструментов – параша, это да. Но такой был!..) и юзабилити. Это пока ещё тормозная версия (низкая отзывчивость на быстрое редактирование), и малое количество видов форматирования (скрытие текста «Н» – кстати, есть: нажатие без выделения – раскрытие всего на текущей строке)
Цитатаalteya
Сосредоточившись на самой работе, а не на умозрительных изысканиях способа ее организации.
Может быть… Но я уже впарился, и не остановлюсь. Жаль, что каждый раз, когда я исправляю очередную строчку с мыслью «всё, релиз!» – она опять и опять не работает. Уже несколько дней.
Эй, steeldragon! Короче, Git. У меня есть три файла: checkout.bat %name% commit.bat %name% %file% done.bat %error%
, где параметры %name% – имя папки текущего документа (у меня каждый «документ» = директория), %file% – имя файла для внесения в репозиторий, %error% – код ошибки 0/1/2. Короче, чё надо.
«checkout.bat» запускается первым, и нужно, чтобы Git выкачал свежую версию нужной папки репозитория, и положил её в каталог .\%name%\ рядом с этим батником. По сути, ему нужно просто дописать сюда новые файлы, ибо старые никогда не будут ни обновляться, ни удаляться (ну кроме форс-мажора, когда всё летит в трубу, и нужно фиксить руками). Когда Гит закончит обновлять (успехом или неудачей, не важно; хотя если можно, то насчёт этого тоже чё-нить придумаем, хотя бы окошко пользователю), выполнение .bat файла должно прекратиться (пад лочится и ждёт завершения cmd.exe).
Теперь, если пад желает внести новый файл в репозиторий, он практически сразу запускает «commit.bat» (ну если ему пока нечего коммитить, то выполнится «done.bat» и всё). Однако, он создаёт файлик «failed.tmp», но ложит своё целевое обновление (всегда едиснтвенный файл) в папку .\%name%\%file% (которую только что чекаутил). Гит обязуется попытаться внести этот файл под контроль как ревизию в репозиторий. Причём очень важно, чтобы хоть при малейшей ошибке (скажем, если за каким-то фигом этот файл уже есть в хранилище, хотя мы только что чекаутили) скрипт завершился. Но когда всё прошло успешно, и новый файл ТОЧНО сохранился в мастер-репозитории – скрипт удаляет «failed.tmp» перед завершением. Тогда пад поймёт, что коммит прошёл, и не будет удалять свой %file%, а оставит его и произведёт локальное слияние.
По идее, «done.bat» и не нужен как таковой, но он гарантированно выполняется всегда (если пад, конечно, тупо не грохнется по дороге), и там например, можно сделать «разблокировку» репозитория (если такое вообще возможно), а блокировку ставить в «checkout.bat». Код ошибки – 0 если всё хорошо, 1 – если что-то не сошлось в самом паде (напрмиер при попытке синхронизировать _разные_ документы), и 2 – если «commit.bat» не стёр «failed.tmp».
Ну и всё. Мне нужны параметры Git, которые будут выполнять эти операции автоматически. То есть все передаваемые пароли, настройки, пути – всё это нужно прописывать в батниках, чтобы синхронизация и коммиты были неинтерактивными (но при ошибках лог лишним не будет).
Сейчас я тестил просто на локальной сети – в батниках у меня тупо команда replace (в данной ситуации лучше, чем copy), читающая и копирующая в/из общей сетевой папки. Работает. Теперь надо гит… (все запросы – синхронные, скрипт должен ждать завершения операций, а пад на это время блокируется на редактирование).
Копипащу сюда мысли о моей идее насчёт специальной версии пада, часть из недавней переписки с администратором сервера svimik.com:
И в этой связи у меня вопрос начёт пада, вернее, его ace-редактора и changeset алгоритма слияния.
Можно ли сделать «оффлайн-пад»? Допустим, берём Git. Хочу, чтобы каждый участник мог коммитить изменения.
Но при этом хочу, чтобы они работали в паде, оффлайн. Все изменения, сделанные локально – сохраняются как один такой нефиговый ченджсет. Потом приложение качает текущую общую ревизию, и само же применяет к нему свой чейнджсет, зная при этом во-первых, старую версию, от которой шло редактирование; и новые чейнджсеты, которые другие люди успели запушить в репозиторий, их можно хранить хоть как новые файлы, а старые даже не менять – ещё и от конфликтов избавимся; а наличие всей истории локально у всех (это же система контроля версий, у всех на руках все данные) сделает даже таймслайдер локальным!
Получается, каждый и клиент и сервер одновременно, а Git – транспорт. Я представляю это себе так, что человек пишет-пишет что-то в оффлайн-пад, а потом нажимает «синхронизировать». И тут в документе появляются правки всех остальных, а его собственные – уходят туда, откуда их получат другие.
Итого, если синхронизировать до и после активной работы (учитывая низкую вероятность того, что кто-либо другой вообще этот документ тронет), и при этом условиться не менять построчную структуру документа – то новые правки будут появляться только как добавки к строкам, или их изменения. И по идее, написанный на определённой строке текст – никуда не скакнёт. Равно как и если многие допишут что-то в одну строку – их текст появится там цельным куском.
Как думаете, сильно код пада придётся перекраивать?
Есть ещё вариант, перекроить только сервер, сделав из него локальный, который правит файлы так, как я описал. А клиентская часть как обычно. Просто при синхронизации сервер передаст клиенту сразу много всего.
ЦитатаSviMik
А в чём смысл? Фича пада в групповой работе.
Так нет, это будет уже не пад. Приложение для другой цели.
Ну, я предполагал нечто вроде плагина к браузерам, имеющее доступ к файловой системе.
Всегда можно делать несколько синхронизаций подряд, чтобы что-то поправить, что криво легло. Нужно просто оставлять документ «неиспорченным». Тогда, если кто-то внесёт свои оффлайновые правки в документ, и они лягут чуть-криво – он тут же поправит их. И тогда мердж от другого участника (относительно исходной версии) должен лечь не более криво, чем первый коммит предыдущего участника.
Так вот!
Первый способ – суррогат, конечно, но по идее должен сработать. Ломаем etherpad-lite, найдя в нём значение таймаута для постинга своих изменений на сервер. Там же как работает: клиент пишет в документ, а скрипт через каждые полсекунды (вроде как) – пытается постануть его изменения на сервер. Сервер в ответ пришлёт ему «окей, бро», а всем остальным – новые перевычесленные для каждого чейнждсеты, чтобы те увидели его изменения. Если постинг не удался – скрипт всё ещё пытается какое-то время сделать это.
Я предполагаю, что если сломать таймер, то клиенты будут (потенциально) нормально принимать чужие правки в реальном времени, а постить свои – нет. Кстати, у изменений сохраняется ревизия, от которой сделаны эти правки.
Теперь добавляем кнопку «sync», заставляющую таймер постинга обнулиться, и коммитнуть изменения на сервер. Их сразу все увидят, потому что приём от сервера идёт в реальном времени.
Это не то, что я хочу, но по ощущениям – именно оно.
Вот это всё описывает, как работает чейнджсет. Математика такова, что:
1) если есть документ Д, и изменение И, то мы получим некий новый документ Д1: Д → (И) → Д1.
2) Если есть Д1 и Д2, а нам нужен результирующий документ Р, то алгоритм найдёт нам такие изменения И1 и И2, что: Д1 → (И1) → Р Д2 → (И2) → Р
3) Если есть общий документ Д (сам являющийся набором чейнджсетов от контрольной точки – например, пустого документа), и у двух людей есть свои изменения И1 и И2, приводящие к Д1 и Д2 соответственно, то обменявщись информацией о них, можно получить такие изменения-мерджи М12 и М21, что они приведут обоих людей к результирующему документу Р: Д → (И1) → Д1 → (М12) → Р Д → (И2) → Д2 → (М21) → Р
Так вот. Представим, что пользователь 1 – это репозиторий, а 2 – коммитер. Коммтер изначально скачивает последнюю версию репозитория (всю цепочку) и считает её точкой отсчёта (Д на последней схеме). Теперь он редактирует свой документ как хочет и сколько хочет, локально.
В момент синхронизации, его «браузер» выкачивает новые изменения с репозитория, и сравнивает данные. Если там вообще нет новых ревизий – идеально, просто сохраняем туда свой чейнджсет (суммарный всего того, что мы меняли). Но теперь, некий второй юзер, тоже внёсший свои правки в свою локальную копию репозитория, решил синхронизировать.
Его клиент-браузер (потому что «сервер» с мозгом в этой схеме вообще отсутствует, есть только глупое хранилище) выкачивает репозиторий и сравнивает. Видит, что начиная с какой-то ревизии пошло расхождение. Алгоритм рассчитывает М12 – это как превратить репозиторий в новую версию с его изменениями; и М21 – это как отобразить на собственном экране всё то, что писали другие в репозиторий ранее. Теперь М12 добавляется в хранилище и фиксируется, а М21 нужен просто для локального бесшовного обновления экрана (иначе пришлось бы перезаписать свои изменения тем, что было рассчитано для репозитория, и перезагрузить пад). Но клиент по факту отвергает собственные чейнджесеты чтобы содержимое локального хранилища совпало с репозиторием – получается сначала чекаут в новую папку (или не нужно, если своё состояние запомнить отдельно) и реверт своих, потом чекаут своих, коммит туда слитых чейнджсетов, и пуш в репозиторий.
Также, схема вполне позволяет в гитовском стиле синхронизироваться не с центорм, а между собой. Тогда инициатор синха пушит в репозиторий коллеги мердж своих чейнджсетов, для себя юзает обратный мердж, и обе рабочие копии становятся синхронными. Если кто-то захочет синхронизироваться с мастером – там отсчёт будет идти от номера той ревизии, которая у их общая. То есть эти слитые изменения двух чуваков как собственное единое изменение уходят одной ревизией на сервер.
Ага, вижу проблему. Когда второй из них тоже синхронётся с мастером – будет конфликт, ведь «общая» ревизия-то у них старая, но при этом новые изменения по факту уже давно на сервере. Видимо, тут нужна система хеширования, чтобы брать максимальную из ревизий, хеш контента которой соответствует лучшему хешу на клиенте. В данном случае на сервере будет старая версия, и новая версия со слитыми изменениями двух участников (которые пушнул один из них без ведома второго). А второй (он тоже их имеет, ведь они с первым синхронизировались ранее) при попытке синхронизировать какие-то ещё сверх-новые изменения – должен делать это не от старой ревизии (несмотря на то, что они отлично совпадают), а новой. Но никак, крове сверки хэша содержимого, он этого понять не может. (Ну может можно как-то там сохранить, чтобы было видно, что его авторство указано в ревизиях, но на первый взгляд с хешем проще).
Короче, что это даст. Можно редактировать пад в любой момент, и сохранять изменения на сервере в любой момент. Копаться в истории без сервера. Возможность работать вообще без центра с мастером.
Чат не предполагается. Цвета авторов – может быть, не знаю. Там наворотить уже не такая проблема.
Технически, я вижу каждый документ-пад как ПАПКУ, в которой лежит куча пронумерованных файлов – это чейнджсеты ревизий. Однажды добавленный в «мастер» (любой, в кого мы пушим) файл больше НИКОГДА не изменяется. Все редактирования пада превращаются в новые файлы ревизий. Однако, когда мы пушим в мастер – НАШ репозиторий теряет сколько-то верхних ревизий, и получает их новые варианты с мастера (включая созданным им новый файл), удаляя свои. Тем не менее, алгоритм гарантирует, что по факту его логические изменения текста сохраняются (это типо как уже стало умножение «A*В», но мы из состояния «А» сделали «А*С», а при слиянии для нашего экрана получаем «А*С*В», но в оба репозитория мы положим «А*В*С», по факту откатывая своё «А*С» до «А», а потом обновляя уже сделанное «*С» с сервера как «*В*С»).
Тогда, Git будет норм вариантом, и конфликты решать не потребуется. Допустим, у клиента две копии репозитория – одна для работы, другая для слияния.
Он меняет рабочую. При синхронизации – checkout на вторую. Потом программа («браузер») анализирует эти два своих репозитория, высчитывая объединённые изменния. Коммитит новую ревизию в репозиторий слияния, затем пушит его на сервер. Ревертит свою собственную рабочую копию, и производит чекаут с сервера. И всё снова синхронизировано.
Ну как, норм идея? По алгоритму вроде окей. Непонятно, с какой стороны подходить к реализации: начать вырезать куски из имеющегося пада, или проще собирать по кускам собственный…
*UPD*
С одной стороны, хочется работать с библиотекой Changeset напрямую и сразу правильно, а с другой – сам пад как есть уже ахрененен, и на первый взгляд проще всего – как-нибудь обойти стороной непосредственное изменение его рабочего кода, а сменить интерфейс и протокол общения с сервером…
чем дольше народ будет править одно и то же место без синхронизации - тем хуже потом будет.
Так нет же!
Редактирование = новая ревизия. Каждая ревизия = новый файл. Старые файлы никогда не редактируются. Тот, КУДА пушают – не меняет содержимое имеющихся файлов. Тот, КТО пушает – удаляет у себя часть файлов и заменяет их новыми.
Поскольку, мастер-репозиторий САМ не вносит правки, не пушит никому по своей воле, а лишь принимает изменения других – то на нём конфликты не возникнут никогда. Потому что каждый клиент будет перестраивать свою рабочую копию так, чтобы менялось «задним числом» только у него, а на мастере – всё линейно.
Гипотетический конфликт может возникнуть в сам момент двухэтапной синхронизации, если два клиента физически одновременно попытаются сделать коммит и обратный чекаут, но скорее всего, Гит на этот счёт должен иметь какой-то иной механизм наподобие кратковременной блокировки целевого репозитория, пока один клиент не закончит свой синх (а там ж просто файлы туда-сюда перекопировать).
Однако точности ради, я тут прикинул, и кажется – нельзя будет сливать ревизии разных людей в объединённый файл различий. Их придётся всё равно хранить отдельными файликами (что не проблема, в принципе). Потому что например есть три участника. Изначально у них всех документ условно равен 0. Теперь каждый их них делает свой документ соответственно 01, 02, 03, Первый синхронизируется со вторым. У них становится 021. Второй синхронизируется с третьим: 0321 (потому что идёт «0(21)» с «0(3)», и «21» дописывается третьему в конец). Теперь первый хочет синхронизироваться с третьим. Имеем «021» к уже «0321». Изначальный алгоритм, вычисляющий позицию слияния по номеру ревизии, выдал бы «0(21)» к «0(321)» равно «032121», что неверно. Вместо этого, видя всю цепочку изменений «0321» и свою «021» он должен по хешам каждого файла понять, что единственные изменения, которые нужны – получить эту «3» себе, а на целевом ничего не менять, там всё есть. По идее, алгоритм changeset это позволяет (там можно даже отменить любую ревизию в цепочке изменений, путём правильного пересчёта «будущего» от неё и вперёд). Неочевидно только, как это запрограммировать, чтобы универсально было. Для полноты примера покажу, что будет, если это третий (или второй) хочет синхронизироваться с первым: Имеем «0321» к «021». Мы вычисляем такой чейнджсет «4», чтобы он при добавлении к «021» дал то же, что даёт «0321». Каким образом реализуется вызов этой операции, пока не знаю. Знаю, что есть понятие «инверсный чейнджсет»…
Так, стоп. Ерунду говрю. Соединение «01» и «02» даёт не «021», а «021'» (это «1'» – «один-штрих»). Это не тот же самый чейнджсет. Это я больше подразумевал эффективные _правки_ участников. Да, тут надо ещё подумать над децентрализованным синхом, но он реализуем.
Надо пока отсечь эту головную боль, и хотя бы добиться только централизованных операций с мастер-репозиторием. Там я уж точно всё продумал.
Конец копипасты.
Мои вопросы адресованы не нам, разумеется. Я привёл этот текст только ради того, чтобы все просто оценили саму идею – как на ваш взгляд, это хорошо? Это удобно? Или это нафиг не нужно?
ЦитатаSerlutin
Так, ребят, Алексей натолкнул меня на одну мысль. Переводить сразу все видео в одной теме будет явно сложно. Но с падом мне пока разбираться лень. Поэтому вот одна идея. Гугл Таблицы. Всё просто переходите по ссылке. И переводите. Даже регистрироваться не надо. Единственная проблема, что они слегка тормозят.
ЦитатаТампли
aleksusklim, признаться честно, не совсем до конца поняла тонкости, но уловила общую суть. Как по мне, идея действительно замечательная! Да и позволила бы наконец полноценно организовать все наработки участников форума. Да, я считаю, что это - вполне удобный вариант для переводчиков. Было бы интересно посмотреть, каково оно на практике.
Ну слава богу. Если что, я пару раз прочитал и даже попытался вникнуть.
Цитатаaleksusklim
…в очень глубокой отладке… (Offline pad is actually working!..)
ЦитатаDragonFlight
Не-е-ет!..
Цитатаaleksusklim
Чёртов пад отвлёк даже от неё.
ЦитатаDragonFlight
Не-е-ет!!..
Цитатаaleksusklim
Я привёл этот текст только ради того, чтобы все просто оценили саму идею – как на ваш взгляд, это хорошо? Это удобно? Или это нафиг не нужно?
ЦитатаDragonFlight
Меня удивляет одно: вы ради приличия спросили? Всё равно же сделаете, если захотите. На вашем месте я бы направил энергию в более рациональное русло. Но у вас в голове работает другая система приоритетов, и вы работаете на идею, а не на результат, это давно известно. Дело ваше. Чем вы проаргументируете, что пад удобнее Google таблиц? Создание такой программы именно для нашего перевода вообще обосновано? Потому что я не вижу смысла заставлять всех участников разбираться в длинных инструкциях и тем более с техническими заморочками, если есть вариант быстрее и проще. Поэтому лично я (за других не говорю) не притронусь к вашей программе, если вы не гарантируете, что мне не придётся взрывать над ней мозг как это обычно бывает.
ЦитатаDragonFlight
Чем вы проаргументируете, что пад удобнее Google таблиц?
Он оффлайновый.
Следующий вопрос?
ЦитатаDragonFlight
Создание такой программы именно для нашего перевода вообще обосновано?
Что вы понимаете под «созданием» в данном контексте?
ЦитатаDragonFlight
разбираться в длинных инструкциях
Как я понимаю, выложенный мной основной движок в архиве TDTPad.rar вы даже не попытались запустить.
ЦитатаDragonFlight
если есть вариант быстрее и проще
translate.google.com
ЦитатаDragonFlight
Меня удивляет одно: вы ради приличия спросили?
На тот момент я ещё не был уверен, что сумею реализовать основную часть алгоритма так, чтобы она работала как я описал.
ЦитатаDragonFlight
aleksusklim, воу. Я уловил в вашем посте агрессивные интонации. И если вы в моём – тоже, то прошу прощения: это не нарочно. Я не собираюсь раздувать здесь конфликты (поверьте, меня просто писанина на форум изматывает). А потому постараюсь сейчас объяснить, что имел в виду.
ЦитатаDragonFlight
ЦитатаDragonFlight
Не-е-ет!.. Не-е-ет!!..
В то время я относился к паду как к задумке исключительно для и из-за темы для субтитров, так как вы отписались именно здесь и дали мне основание это предполагать. И я чувствовал в какой-то степени свою вину за то, что отвлёк вас созданием этого обсуждения второстепенной важности, нагрузил и до того переполненный "стек" ваших заданий.
Но, судя по всему, я был не прав, и вы используете пад универсально. В других темах я вообще не вякаю: решите перейти в пад, куда я-то денусь?
Цитатаaleksusklim
Что вы понимаете под «созданием» в данном контексте?
ЦитатаDragonFlight
1) Вложенные время и усилия, которые можно было потратить на давно намеченные цели, 2) новое рабочее пространство, которое может быть даже и не нужно, учитывая объём и глубину текста (это не игра) и количество вовлечённых участников (я не думаю, что их будет слишком много). Всё же понадобится некоторое время, чтобы привыкнуть к паду, в то время как в Гугл таблицах осваиваться не надо (кто ещё со мной не согласен?). Вообще, Альтея сказала как нельзя лучше:
Цитата
Сосредоточившись на самой работе, а не на умозрительных изысканиях способа ее организации.
Цитатаaleksusklim
Как я понимаю, выложенный мной основной движок в архиве TDTPad.rar вы даже не попытались запустить.
ЦитатаDragonFlight
На тот момент – нет. Уже давно в моих планах после ответа в теме Spyro 3 была эта ветвь, и на пару дней я здесь застрял. Не, я пролистал глазами новые ответы в той теме, но ваши посты с описанием своих разработок – это не то, во что можно вникнуть на расслабоне! Даже порой кажется, что высшую математику вкурить легче! Как студент факультета прикладной математики говорю (аж стыдно произносить). Поэтому кусок про пад я пропустил.
Но сейчас – да, попытался. START.BAT там, да? Ну, как бы вот. I'm done. (про "гарантировать", это именно про это было)
Цитатаaleksusklim
Следующий вопрос?
ЦитатаDragonFlight
По сути, чтобы поагитировать за преимущества пада, достаточно было привести свою же цитату:
Цитатаaleksusklim
Причём, если будет прямое выкопирование (потенциально опционально прямо в этот визуальный редактор) – то без проблем можно будет вставлять свои правки в пад, а комментировать их (цитируя из пада) – тут. Тогда: – мы не потеряем привычный ход обсуждения фраз (то есть пад не заберёт нисколько от форума) – все реплики и все комментарии к фразам будут собираться в паде (как бы как копии, да…) – по идее, на это не будет уходить ТАК много времени, как например попытка скопировать кусок гугль-таблицы на форум, или внести разноцветные обсуждения на вики-страницу гугль-кода или в сам репозиторий.
Цитатаaleksusklim
Время и программы ни к чему не обязывают. Интернет не нужен, быстрый процессор тоже: пад, после превращения его в оффлайн, стал значительно меньше тормозить.
Вариант оффлайн-пада я вижу отличным решением проблемы, сочетающим в себя одновремнно и достоинства Ворда (форматирование) и форума (в смысле, лёгкий перенос текста туда-сюда), и системы контроля версий
ЦитатаDragonFlight
Чем-то убедили, но не могу сказать, что совсем. Он-/оффлайн для меня не играет особой роли, но может быть кому-то это будет впрок.
Цитатаaleksusklim
translate.google.com
Способ обсуждения и правки текстов не влияет на качество переводов. Может, если только очень косвенно.
ЦитатаDragonFlight
---- Пожалуйста, не заставляйте меня больше так изгаляться. Давайте лучше работой заниматься.
– продолжение этого обсуждения из четырёх постов выше. Опять же, вопросы не нам. Просто текущий результат:
У-у, я завершил свой оффлайн-алгоритм! Осталось только интерфейс немного поправить, например – сделать выбор текущего репозитория.
О, а ещё я знаете что придумал – не «clear authorship colors», а «toggle»! Пусть будет кнопочка как «Bold», но другая, а её накладываемый CSS будет давать {background:transparent!important;} И там не нужно автоматические покрытие атрибутом нового вводимого текста – тогда экспириенс будет классический: свой текст всегда цветной, а такое «выбеливание» – делает выделенный кусок белым глобально. Но бонус в том, что сделав повторное выбеливание уже белого текста – в нём вернутся исходные авторские цвета! Почему я раньше до этого не додумался… (Кнопку очистки цветов вообще удалить можно, но если опять же рассматривать кастомизитрованного клиента – ну нет, там на этот счёт куча куда больше серьёзных дыр в безопасности. К тому же, для оффлайн пада единственным клиентом будет 127.0.0.1, а ему дозволяется всё.)
Ладно, вот что с оффлайн. Я хотел было собрать это именно как плагин, но там такая инвалидская система хуков (раз уж плагинная архитектура – так ВСЁ должно было реализоваться легко заменяемыми плагинами), и множество констант просто захардкожены, а переменные – сокрыты в замыканиях. Грёбаная инкапсуляция, публичные функции ущербны! Пришлось нагло менять ядро. Хоть я и старался ставить метки на изменённых строках, но по-моему там уже как бы всё, официальные обновления движка будут невозможны. И фиг с ними.
Итак, предполагаем, что в моём Паде одновременно может быть открыто несколько разных падов, но в каждом из них – не более одного клиента. Клиент-серверная часть считается единым целым (вплоть до того, что клиент может послать строку, а сервер сделает её eval). Кстати, как-то можно ли гарантированно закрыть Пад от внешних не локальных подключений? «Bind to localhost» будет достаточно?
Далее, клиент не шлёт на сервер все совершаемые в паде действия (я там флаг блокировки поставил). Также, не совершает дисконнект по свое воле, если ему кажется, что связь с сервером потеряна по таймауту.
Название (=идентификатор) каждого пада – не привязывается к имени документа в репозитории. Один и тот же документ может быть загружен в разные пады, и вот как это устроено (каждый раз под «сервер» я подразумеваю «локальный etherpad-сервер», а не целевой репозиторий; если я где-то говорю о «двух клиентах» – то это имеются в виду два разных клиента репозитория за разными локальными серверами)
На клиенте есть две основные операции, а на сервере – одна. Ну ещё, сервер обладает громадной функцией обработки «новых изменений» от клиента, которую в основном я и менял. Итак, первое что клиент может сделать – послать свои изменения на сервер, как он обычно это делает. Но не каждые полсекунды, а лишь когда окно фрейма редактора потеряем фокус.
Причём исходный алгоритм там шикарен!
Он сливаёт всё – ещё до отправки на сервер. Например, если написать «123», а потом стереть «2», то чейнджсет будет – «13». Тем более, что уж говорить о возможности отмены. Атрибуты тоже. Вообще, любые действия взаимообъединяются в минимальную и адекватную последовательность вставок и удалений. Не важно, насколько дико пользователь работает с текстом до синхронизации – все локальные изменения схлопываются ровно в то, что останется под конец. Удаление и отмена, вставка барахла и очистка его от мусора – всё это ни в истории, ни тем более в репозитории не сохранится.
Теперь, когда клиент посылает изменения на сервер – он блокирует пад на редактирование (но так, чтобы потом суметь разблокировать после получения ответа). Сервер делает всё как обычно (вносит чейнджсет в базу), но при этом сохраняет копию сообщения от клиента в очередной файл в папку, имя которой такое же, как у пада.
То есть ещё раз. Есть, скажем, папка .\PADS\. Там будут паки .\PADS\mypad1\ , .\PADS\test\ – где «mypad1» и «test» – пады, открытые в браузере. В этих папках – файлы с именами «00000000», «00000001»… (десятичные – оказывается, числа в base36 неправильно сортируются Проводником). Каждый файл – сообщение от клиента, отталкивающееся от ревизии с этим номером. То есть начинается всё с пустого пада (именно с пустого, никаких default text!), это – нулевая ревизия, папка пуста. Следующее изменение, приходящее с клиента – сохраняется в файл по номеру количества ревизий. И так далее. То есть, скажем, в файле «00000034» будет «"baseRev":34» – и это чейнджсет, применяемый к 34-ой ревизии, и создавший 35-ю. Таким образом, «лишних» файлов в папке вообще быть не должно, чтобы их общее количество всегда показывало текущую ревизию.
Итак, все приходящие от клиента данные, сервер сливает в эти файлы в папке соответствующей данному паду. Тогда, база данных (только dirtyDB, никакого нафиг MySQL!) пада и эта папка – будут синхронными. Для сброса – придётся либо грохать dirty.db и все папки всех созданных падов, либо – просто создать новый пад с любым ещё неиспользованным именем.
Теперь, вторая операция на клиенте – синхронизация с мастер-репозиторием. Во-первых, она вызывает немедленный постинг всех текущих изменений на сервер (кстати, если посылать нечего – то клиент и не пошлёт ничего), а потом отправляет ему сообщение с именем документа (папки), с которой нужно синхронизировать пад.
Структура тут следующая: у сервера есть ещё одна папка, которая является локальной копией репозитория. Подпапки – «документы», в каждом из них – опять же «00000002», к примеру, – ревизии. Того же типа, что в папке пада, но логически по-другому создающиеся. Теперь задача – считать из нужной папки новые изменения, внести их себе; а свои новые изменения – опубликовать в эту папку следующей ревизией.
Вначале я пытался сообразить что-то из-под запоминания номера ревизии, но к успеху это не привело. Я остановился на варианте с хешем, вернее даже – идентификатором ревизии. Каждый файл, как «00000005», – должен иметь уникальный идентификатор. Я взял строку «автор+время+рандом», чтобы точно гарантировать уникальность. Когда новое сообщение от клиента ещё не имеет его – он создаётся. Так что в папке пада, все файлы ревизий уже с хешами.
Ещё, нужно отдельно сказать, что крутого в библиотеке чейнджетов – операции протаскивания и мерджа, называющиеся follow и compose. Допустим, у нас есть цепочка изменений 1-2-3-4, и вторая – 1-2-5. Операция «follow» применяется от «5» к «3» так, чтобы получить некий «5'», который уже применился бы к «4», и дал бы объединение изменений 3+4+5. Цепочка будет 1-2-3-4-5'. Последняя ревизия как бы протащилась через другие, и встала последней. Именно так пад обрабатывает изменения участников, применяемые к разным ревизиям – протаскивает их до последней, а сами изменения в тексте остаются именно на тех местах, где сделаны.
Вторая операция – объединение – позволяет, скажем, свернуть цепочку 1-2-3-4 в 1-4', где «4'» – это «2-3-4», объединённые в единый чейнджсет. Именно так клиент схлопывает все подряд идущие изменения – поскольку операция применяется к двум соседним – он просто делает «compose» имеющегося чейнджсета с новым.
Ну, для полной картины, можно рассказать про AttributePool. Каждый чейнджсет может не только вставлять текст или удалять его, но и менять атрибуты (например, жирность). Атрибуты нумеруются числами, и каждый – это пара «настройка=значение» (например «bold=true»). В самом чейнджсете физически прописаны только числа, а сами названия атрибутов – прикладываются отдельно. Например, если в одном чейнджсете какой-то текст (условно говоря) выделяется синим, а другой – зелёным, то там будет *0 и *1, а в пуле атрибутов – «0:color=blue,1:color=green». Возникает вопрос, как оперировать над чейнджсетами, если за одним номером могут быть разные атрибуты? Для этого есть функция, преобразующая атрибуты из чейнджсета в новый пул, путём слияния с имеющимися в нём. Причём сам чейнджсет тоже меняется, ведь числа в нём должны обновится. Моя обёртка вокруг функции объединения чейнджсетов именно так и поступает – добавляет атрибуты в общий на двоих пул.
Ещё есть понятие AText – текст с атрибутами. По сути – это один чейнджсет, создающий весь текст с паде. Но внутренне собран он чуть по-другому, хотя и ему также требуется пул (со всеми атрибутами пада). Для применения чейнджсета к а-тексту пада – сначала нужно слить его пул с пулом пада. Это как общий знаменатель: у всего пада он самый большой, потому что там складывается всё подряд.
А вот как ещё можно протаскивать чейнджсеты через цепочку: инверсно. Например, если цепочка одного будет «0-1-2», а второго – «0-1-3», то протащив «2» через «3» получится «0-1-2-3'», а если, с точки зрения второго, протаскивать «3» через «2», то будет «0-1-3-2'». И текст физически не будет одинаков, если в одном из случаев не указать инверсию при follow. Но, как потом я выяснил, эта инверсия не всесильна! И на некоторых цепочках, где были удаления, потом объединённые со вставками – follow не даст идентичные результаты, и будет зависеть от порядка применения, чего быть не должно.
Но пока, вернёмся к тому, что пад решил синхронизироваться. Теперь у нас есть две папки: одна своя, для текущего пада; и чужая, из репозитория. Первое, что сервер делает – смотрит на количество файлов в них. Если обе пустые – ничего не делаем, потому что на клиенте изменений нет, а репозиторий ещё не инициализирован вовсе.
Хорошо, пусть клиент сделает несколько файлов ревизий у себя. Тогда синхронизация с репозиторием должна просто скопировать их туда, а ещё лучше – объединить, чтобы публиковать лишь один чейнджсет в одном файле. Этот файл должен иметь новый хеш (который просто уникальный идентификатор).
Если же наоборот, в репозитории были файлы, а в рабочей копии – нет, то это значит, это производится попытка первый раз получить данные из репозитория. Серверу достаточно честно открыть по порядку каждый файл, и обработать их содержимое так, словно эти изменения идут от локального клиента (все проверки на токен сессии, на авторство и подобное – я отключил). Тогда локальное содержимое базы данных пада, и его папки – станет абсолютно таким же, как в репозитории! Включая и хеши ревизий (поскольку хеш в «приходящих» изменениях уж был, то он и остаётся) и даже историю таймслайдера – серьёзно, сервер обманывает сам себя, словно это клиент только что понасоздавал столько ревизий, и все они запомнились в базе – теперь и откатиться к любой точке можно!
Самый сложный, и основной случай: когда файлы есть в обеих папках – распадается ещё на три вариации, и вот тут уже самую важную роль играют хеши. Для начала предположим, что в рабочую копию не были внесены изменения, а в репозитории – есть обновление от других участников. Тогда новые ревизии нужно «протащить» через локальные, но начиная с правильного места (хотя в данном предположении протаскивать и не понадобиться – кладём в конец). В этом помогут хеши: поскольку синхронизированные версии обладают в точности одинаковыми хешами, достаточно будет идти по целевым ревизиям в обратном порядке, найдя первую (с конца), хеш которой совпадает хоть с каким-нибудь (в предположении – последним) нашим хешем – для этого я ещё отдельно храню ассоциативный массив «хеш=ревизия», привязанный к паду и даже сохраняющийся в его базу данных. Если таковой не найдет – это значит, что документы не могут быть синхронизированы, потому что разные; отсчёт от «нулевой» изначальной ревизии (когда документ пуст) – пришлось логично запретить, чтобы не сливались по ошибке разные документы. То есть первоначально нужно хоть что-то написать в новый пад, и чтобы другие сперва это выкачали себе, а не изменяли пустой документ.
Теперь, есть номер локальной ревизии, и ревизии в репозитории – которые находятся в синхронизации. По предположению, локальная ревизия – последняя (новых изменений нет), значит нужно лишь добавить файлы репозитория сюда, с оригинальными хешами. Но на самом деле не всё так просто, но пока идём дальше…
Второй случай: в репозитории не было обновлений, а у нас – были! Значит, нужно собрать ОДИН чейнджсет, и дописать его как новую ревизию. Но перед тем, нужно опять же вычислить, от какой ревизии отталкиваться. Для этого я формально создаю временный пад, а потом вгружаю в него все файлы репозитория с первого по последний, поступая при этом так, как будто изменения приходят от клиента (но не от конкретно текущего, а просто от некоторого), разве что не сохраняю их ещё в какие-то файлы. Тогда и массив пад-ревизия для нового пада будет заполнен корректно. Обратное действие – беру свои локальные ревизии, и перечитываю их с конца в начало, чтобы найти первый совпавший хеш. Причем по ходу считывания – объединяю их в одну, чтобы публикуемый чейнджсет был единственным. Хеш объединения – это хеш последней локальной ревизии, чтобы в итоге после коммита – хеши последних файлов совпали. Когда ревизия найдена – протаскиваем свои объединённые изменения через неё до конца целевой цепочки.
Как оказалось, объединять изменения перед протаскиванием – единственная возможность протащить больше одно чейнджсета. Потому что нет функции типа «multifollow» – чтобы я передал ей массив чейнджсетов, первый из которых был бы для протаскивания, а прочие – его цепочка. Проблема в том, что каждый конкретный чейнджсет предполагает применения к конкретному тексту. И больше ни к какому другому. Рассмотрим две цепочки: «0-1-2-3» и «0-1-4-5». Начала «0-1» у них одинаковые, а дальше было разветвление. К чейнджсету 2 подходит только 3, к 4 – только 5. А к 1 – одновременно и 2 и 4. Допустим, мы протаскиваем чейнджсет 4 через чейнджсет 2 и 3: «0-1-2-3-4'», где «4'» несёт те же изменения, что и 4, но при этом применим не к 1, а к 3. Возникает вопрос: как протащить «5»? Он подходит только к «4», которого уже в чистом виде нет. Нужно было изменять его как-то параллельно с 4, чтобы он стал неким 5', но готовой функции я не нашёл, а свою писать не знаю как (на самом деле я так и не понял, КАК они так протаскиваются в принципе).
Моё решение – сначала объединить один из хвостов. Пусть станет «0-1-(45)», где 45 – это мердж «4-5». Тогда, поскольку он применяется к 1, его можно успешно протащить: «0-1-2-3-(45)'», где штрих формально берётся от «1-». Если рассмотреть зеркальную цепочку, то будет «0-1-4-5-(23)'». В одной из них нужно протаскивать с инверсным флагом, и как я выяснил – в собственной. Когда локальные изменения вносятся в репозиторий – там follow прямой, он, в реальности, допишет текст того, кто постил позже – СПРАВА от уже имеющегося текста. Пример: первый пишет «0», второй обновляет. Теперь первый пишет «1», у него «01», обновляет. Второй пишет «2», у него – «02», обновляет. У него получится «012» (единичка первого встанет СЛЕВА от его двойки, потому что протаскивание «себе» – инверсное). Первый обновляет – у него тоже «012», но двойка просто появится справа, потому что здесь протаскивание прямое, сделанное вторым.
Ладно, случай третий, самый главный: и в локальном, и в целевом репозитории были созданы новые чейнджсеты. Две операции запускаются по очереди: сначала я ищу с конца целевых ревизий такую, которая бы совпала с каким-нибудь локальным хешем, и объединяю их между собой по дороге. Потом создаю временный пад, прогружаю в него все целевые ревизии по порядку, а затем – иду по своим снова с конца, находя такую, которая совпадёт с хешем из них, тоже объединяя. Казалось бы, теперь достаточно лишь запостить в репозиторий наши изменения, протащив по правильной ревизии, а к нам – его изменения, тоже с верного номера, но уже инверсно. Правда, оба этих новых файла должны иметь одинаковый хеш, причём уникальный, не совпадающий ни с тем и не с другим. К тому же, если коммит одного файла по каким-то причинном не может быть выполнен – себе брать собранные и протащенные изменения тоже ни в коем случае нельзя (это и отличает данный вариант от просто применения двух прошлых по очереди), иначе потом при следующей синхронизации на сервер ушли бы уже имеющиеся там изменения (ошибочно ставшие частью локальной цепочки), либо же – не дошли бы собственные.
Но как я уже сказал, оказалось, что функция протаскивания с инверсией – багнутая. Если первый сделал «0» и синхронизировал, второй тоже синхронизировал; первый дописал слева от нуля «1» и синхронизировал, затем удалил свой «0» и снова синхронизировал; второй дописал «2» слева от нуля, и синхронизировал. Теперь у второго «21», а у первого после синхронизации – будет «12».
…как я долго искал проблему!! При обычных редактированиях, всё нормально. Если делать всё аккуратно и по шагам – ничего не ломается. Но когда я уже был уверен, что всё работает идеально, просто делал беспорядочные правки текста и синхронизации – пад вылетал на попытке применить очередной чейнджсет к тексту, потому что там где-то не сошлись переносы строк (ага, а потом никак «аккуртно» всё повторить и не мог).
На самом деле, операции в чейнджсетах бывают однострочные и многострочные. Причём многострочная операция – это такая, которая затрагивает кусок текста, в котором строго определённое количество переносов строк, причём последний символ (будь то удаление, атрибуты или вставка) – обязан быть переносом строки! Однострочные операции – переносов строк не затрагивают. Поэтому, когда происходила рассинхронизация – клиент вносил такой чейнджсет, который был уже невалиден для второго клиента, если переносы строк оказывались на разных позициях.
Это поставило под угрозу всю задумку, пока я не вернулся к своему изначальному плану, «отвергнуть все локальные изменения» при синхронизации. А ведь даже не обязательно все! Синхронизируяюсь, и рабочая копия, и репозиторий – должны придти к одинаковому состоянию, но разными путями. Поскольку в репозиторий коммит изменений и протаскивание происходит прямым способом, и верен; а вот обратный – глючит, то: что мешает в этот момент полностью почистить текст своего пада, и внести туда ровно то, что должно получиться – текст временного пада, представляющего собой весь репозиторий? Причём это даже не повлияет на таймлайн и историю: какая разница, будет ли чейнджсет таким крутым, что, будучи применённым к имеющемуся тексту каким-то чудом сделает его именно таким, каким пожелает пад репозитория; или же мы просто скажем «удали свой и замени вот этим» – да, возможно тут придётся поплатиться тем, что в таком случае чейнджсет будет размером с весь текущий текст в паде, но какая разница – это всё равно локально, а в репозитории-то всё нормально. Более того, если сбросить свой пад, или создать другой – то при первой синхронизации будет выкачана именно нормальная цепочка с нормальными чейнджсетами. Правда я не стал убирать из алгоритма подготовку к инверсному протаскиванию (чтобы ветвление ещё на случаи не разбивать), просто её результат под конец затирается прямой заменой, вместо этого самого протаскивания.
Замена, кстати, оказалась не такой простой. Там была функция «вставить в новый чейнджсет готовый а-текст», но не было «добавить удаление всего текущего». Вернее было, но лишь в одном клиентском файле, который зависел от каких-то слайсеров, нужных только клиенту и Ace-движку; а у сервера этого не было. Пришлось писать… Функция вышла низкоуровневая: удаляет многострочным изменением весь текст от начала до предпоследнего переноса строки включительно, и потом – однострочным всё на последней строке до самого последнего переноса не включительно (который вообще трогать ни в коем случае нельзя!). И производит вставку а-текста из нового пада; ну там ещё за пулом атрибутов постоянно следить надо.
Теперь, общая функция синхронизации выглядит так: 1) Выкачиваем свежую копию репозитория, и считаем файлы у себя и у цели. Если по нулям – выход. 2) Если у цели пусто – то объединяем все свои файлы, и коммитим результат с хешем последнего. Выход, но если коммит не удался – удаляем внесённый файл. 3) Если пусто у нас– то проходимся по всем файлам цели, и выполняем каждый из них в свой пад, как будто это всё изменения, пришедшие от текущего клиента; файлы у себя появятся автоматически, как обычные изменения настоящего клиента. Выход. 4) Проверяем хеш последнего файла цели: если такой у нас есть – к пункту 7. 5) Объединяем все файлы цели в обратном порядке, до тех пор, пока не найдём хеш, совпавший с одним из наших. Если такого нет – ошибка, это пад другого документа. 6) Собранные изменения запоминаем, а хеш для них будет – из последнего целевого файла. 7) Создаём временный пад, и загружаем в него последовательно все целевые файлы, как изменения, приходящие от фиктивного клиента, но без дополнительного сохранения ещё куда-то, хотя и со слежением за хешами. 8) Проверяем хеш последнего нашего файла: если он есть во временном паде, и при этом пункт 6 не выполнялся – выход, потому что на данный момент, отказывается, ещё ни у кого нет никаких новых изменений. 9) Если хеш есть во временном паде, но пункт 6 выполнялся – то эти самые запомненные изменения просто вносим в свой пад. Выход – мы успешно обновили свой неизменённый пад с репозитория. 10) Объединяем все свои файлы в обратном порядке, до тех пор, пока не найдём хеш, совпавший с одним из целевых во временном паде. Если такого нет – выход с ошибкой, это тоже пад другого документа. 11) Если пункт 6 выполнялся – то создаём новый хеш, который присваиваем и этому объединению, и тому, что мы запомнили тогда. 12) Вносим объединение во временный пад, с протаскиваем через ту ревизию, пред которой совпал хеш в пункте 10; сохранение автоматически в очередной файл в целевой папке. 13) Пытаемся коммитить этот созданный файл, но если не вышло – удаляем его и выходим с ошибкой (по факту, никакие изменения в свой пад ещё не были внесены, раз выполнение дошло до сюда); например, если в целевом репозитории уже появился файл с этим именем последней ревизии – то есть гит-конфликт – то весь алгоритм нужно перезапустить с пункта 1. 14) Если пункт 6 не выполнялся – то выход, ведь наши изменения уже в репозитории, который за это время никто не менял. 15) Берём результат пункта 6 с хешем из пункта 11, и меняем его содержимое на текущий текст из временного пада. Вносим это изменение в свой пад как последнюю очередную ревизию – и синхронизация, наконец, полностью завершена.
Временный пад должен быть удалён сразу, как не нужен. Все файловые операции у меня – вопреки духу джаваскрипта – синхронные. Обращения к репозиторию – тоже. Их, собственно, два: чекаут в самом начале, и коммит на пунктах 2 и 13. Причём успешность или неуспешность коммита критически важна! Клиент блокирует пад на изменения до тех пор, пока эта функция синхронизации не завершится. Каждый чекаут – допись файлов, которых ещё нет; каждый коммит – сохранение одного файла в репозитороии.
Вопрос, что же делать с авторскими цветами? Это именно то, чем я намерен заниматься далее, но идея такая: кроме хеша, я же могу любые метаданные в своих файлах хранить! Буду посылать от клиента целиком его userinfo. Да и вообще, позволю выбирать не только «имя», а сделаю его по факту эквивалентным «id». Тогда, вместе с изменениями серверу будет приходить цвет текущего клиента, и сохранятся в репозитории. Обновляя, разные клиенты смогут и получать цвета друг друга, и менять их.
А что с чатом? Ну так же: приходящие от клиента сообщения чата, буферизуются на сервере. Причём до тех пор, пока не выполнена синхронизация – должна быть возможность удалить любое из них. При первом же постинге в репозиторий – все накопившиеся сообщения чата уходят вместе с изменениями, а новые – вносятся в пад. Ну да, тут и порядок, и даты – будут в рассинхроне: пришедшие с репозитория сообщения чата в любом случае будут добавлены в конец текущего пада, после отправленных собственных; хотя если потом обновить с чистого пада – то сообщения окажутся на самом деле в другом порядке. Хотя всё логично – все новые для данного пользователя – всегда снизу.
Однажды созданный файл ревизии – не удаляется и не изменяется, то есть конфликтов не будет никогда. Если же по каким-то причинам очередной коммит как-то нарушит работу всей системы – то его можно быстро ревертнуть (уже через Git), ведь предшествующая цепочка всегда верна и никуда не делась. Локально можно создавать столько угодно падов, и вгружать в них содержимое репозитория, если по каким-то причинам, текущий локальный пад вышел из строя (например, создан чистый пад в базе, но в папке с его именем уже что-то есть), и не хочет нормально синхронизироваться.
Когда я говорил «хеш» – я имел в виду «идентификатор», просо случайно создающийся, и прямо не связанный с непосредствнным содержимым: два разных файла с одинаковым хешом обозначают, что полная цепочка от начала и до каждого – приводит пад к одному и тому же состоянию (но скорее всего, разными путями).
Возможность синхронизироваться клиентам между собой без центрального репозитория – я пока не рассматривал. Ведь если у одного «0-1-2-3», а у другого – «0-1-4-2'-6» – как это слить, я в своём алгоритме в принципе не представляю («2'» – это чейнджсет 2, протащенный через 4); да, тут постинг не взаимный, но случай рассмотрения различных беспорядочных взаимных синхронизаций сведётся именно к такому.
А в моём случае с мастер-репозиторием – процесс синхронизации сведён к нажатию одной кнопки, и я уже проверял продакшн в локальной сети – шикарно! Изменения сливаются идеально, например если кто-то пишет в строке 4, а я ставлю перед ней два переноса – то после обновления его текст окажется на строке 6 и ничего не нарушится. Если кто-то удалит весь текст в паде, а другой что-то напишет в исходный вариант – то после синхронизации у всех окажется лишь его текст на пустом паде.
Изменения сплетаются между собой неочевидными зависимостями: первый что-то изменил и синхронизировал, второй тоже изменил и синхронизировал, третий изменил (всё ещё исходную версию) и тоже синхронизировал; потом снова первый, опять что-то поменяв, синхронизировал – а ведь перед ним пад уже трогали двое – и НИ У КОГО не будет на экране одно и то же. Но тем не менее, если они перестанут редактировать, а просто несколько раз синхронизируются – то все придёт в норму: изменения каждого достигнут каждого, и пока никаких слияний нет – пады у вех одинаковы, несмотря на то, что в их папках разные файлы, разное количество, разные хеши, и даже разные истории – своя всегда запоминается подробно, а чужие – ревизии встают в те моменты, когда происходило локальное обновление; чтобы получить чистую историю всех настоящих ревизий репозитория – нужно выгрузить в новый пад.
Так во-от… Всё шоколадно.
За одним исключением – теперь пад, он как бы… оффлайн. Да, кэп. Я вот думаю, нельзя ли его обратно – онлайн сделать? Чтобы можно было работать и онлайн, и оффлайн…
Потому что если рассмотреть пользователей мобильных браузеров – так туда ни сервер пада не поставить, ни даже расширение, имитирующее его. Но с другой стороны, есть GitHub. А на нём можно создать проект pages – в нём содержимое репозитория будет отдаваться по http как статичный сайт. Включая все мои файлики ревизий всех документов!
Остаётся лишь кастрировать etherpad до такого состояния, в котором ему вообще не нужен будет «умный» сервер: браузер просто заходит на нужную страничку, и всё ядро и все плагины – скачиваются как обычные .js файлики. И браузер работает сам по себе. Чекаут – просто выкачка новых файлов из нужной папки. Коммит – ну… пусть браузер просто даст скопировать правильный текст, и откроет для клиента страничку Гитхаба, куда нужно будет просто вставить его и подтвердить коммит. Или ещё лучше – пусть сам прокоммитит, может у сайта есть POST-api?
Что же делать с базой-то. DirtyDB… она же хранит простой JSON? Ну видимо, его можно сохранять в localStorage. Ещё даже deflate-ужимать можно, чтобы больше поместилось.
Может у вас есть какие-нибудь идеи насчёт этого? А именно, с чего начать превращение пада с умным локальным сервером – в пад, скачивающийся со статического хостинга, и сохраняющий всю работу в паде локально? Пока у меня идея, перехватить все места отправки оставшихся (я же всякие там «второй юзер зашёл в пад» и тому подобные – вообще не рассматриваю) сообщений, и превратить их в вызовы серверный функций. Движок базы переделать под localStorage.
Ну и функцию синхронизации тоже полностью переписать, заменив файловые операции удалённым скачиванием и опять же localStorage. Хотя, эту функцию всё равно придётся переписывать… http://klimaleksus.narod.ru/Files/4/offline.png – щедро рассредоточить, дать понятные названия и комментарии, и в кой-то веке все вложенные вызовы под anync.series расписать, а не вглубь. (она одной строчкой, потому что я тестировал, отправляя её серверу через консоль браузера как строку)
О, а ещё каждый коммит должен пересоздавать некий общий файл html-экспорта в репозитории. Чтобы всегда можно было легко посмотреть, что там сейчас в паде – даже без включённого javascript.
*UPD* Продолжаем:
ЦитатаSviMik
сама идея править текст в оффлайне для меня выглядит странно.
Из того, что я успел натестировать – пад мерджит ШИКАРНО. То есть, если у нас (а у нас так) будет список строчек такого формата:
Оригинал. Текущий итоговые перевод. Вариант. Обсуждения, Оппонирования, Ещё вариант. Дополнения…
Следующая строка, и так далее.
– тогда, основной текст представляет из себя диалог. Старые строки не правятся, просто добавляются новые. Раздвинуть строки – да пожалуйста, это ничего не сломает. Двое пишут в одну строку? Ну ничего, варианты встанут друг за другом.
Менять будем только финальный вариант, и только с учётом сделанных обсуждений ниже его. Текста (да и вообще, документов) у нас будет МНОГО, и вероятность, что два человека предложат правку к одной строке одновременно (скажем, в течении недели) – низка. Другое же дело, когда кто-то отредактировал, а второй – потом прочитает и напишет ответ. Вот он и примет решение, брать ли предложенные правки (или удалит уже внесённые), и допишет свой ответ.
В этом и оффлайновость! У нас специфика работы другая, и особенно – темп. Что мне не нравится в вашей специфике – необходимость писать обсуждения на той же самой строке. У нас заморочек с нумерацией нет – всегда можно раздвинуть строки и хоть диалог с форума туда добавить.
Оу, а я не говорил, что нам нужны «спойлеры»? Что-то большее, чем скрыть/показать кусок текста на одной строке. Хочу – скрывать несколько строк (хотя, это даже никаким тегом не реализуешь – там в body строго вложен список div, в которых – непересекающиеся span). Чтобы можно было и всё свернуть, и всё развернуть, и поштучно. Да так, чтобы нумерация не сбивалась… Видимо, кастомная функция нумерации, которая не только номера меняет, но и по содержимому смотрит, может даже высоту меняет. Сейчас как есть, даже если как-то сделать многострочный спойлер – он сломает нумерацию строк. Не то чтобы нумерация была мне так нужна… но не отдавать же её без боя? )) А делать многострочный спойлер формально в одну строку (то есть использовать какой-то символ, делающий <;;br>) – ну нет, по моим расчётам для моей задачи – 90% всего пада будет под тем или иным спойлером, и из-за messing with newlines – мердж чейнджсетов сломаться не должен – я как раз про то, что стандартные переносы строк хорошо обрабатываются при слияниях.
Возможно, в сложных ситуациях пад тоже мог бы показывать пользователю диалог с просьбой выбрать вариант решения той или иной ситуации?
Насколько я могу сказать сейчас – изменения затрагивают по факту только тот текст, к которому прикасался редактировавший. А ещё: если после синхронизации произошёл фак-ап – человек может сразу же всё поправить, и синхронизировать ещё раз.
Алгоритм чейнджсетов может протаскивать либо прямо, либо инверсно – всё. Других вариантов «решения проблемы» в нём нет. И я отказался от одного из протаскиваний. В принципе, можно попробовать переключить на инверсное – тогда текст последнего синхронизировавшегося будет, вообще говоря, добавляться СЛЕВА на совместно изменённых строках (больше ни на что не влияет – если он писал на отдельной строке, то в любом случае будет на отдельной), но мне кажется это не совсем ожидаемым, ведь новые изменения логично должны оказаться на конце.
Мне больше импонирует возможность, например, подгружать из хранилища не единым изменением, а частями. Или чтобы всё новое – получало как-то особый атрибут, чтобы сразу было видно, что же было изменено. Это вроде неплохо. И должны быть кнопка, грубо говоря, «прочитал» – очищающая это форматирование. А все приходящие вставки – пусть выделяются. Хотя, с удалениями всё равно ничего не сделаешь – не вставлять же туда какой-то символ?..
Цитатаalteya
aleksusklim, слушьте, а может... это самое... все эти рассуждения перенести в какую-нибудь другую ветку? Есть же у нас темы "общего" назначения. К субтитрам видео они имеют крааайне опосредованное отношение. Ну правда. Вот захочет вдруг кто попереводить видео. Зайдет в тему. И тут же сломает себе мозг! И убежит без оглядки.
Цитатаalteya
Одна из наших форумных проблем. Да что там... Самая ГЛАВНАЯ форумная проблема как раз в том, что среди продуктивных обсуждений самого материала (тексты, правки) есть нефильтрованные ТОННЫ вот таких вот сторонних рассуждений. И потом в этих тоннах откопать крупинки правок весьма затруднительно. Это я вам как копательница со стажем говорю. Сломавшая не один десяток титановых лопат, и стершая себе руки до кровавых мозолей в этих раскопках.
Цитатаalteya
Куда эффективнее было бы сперва установить фильтр на все неотносящееся непосредственно к теме. Например, волшебной кнопкой spoiler.
UPD
Цитатаaleksusklim
Продолжаем:
Цитатаalteya
Тему "Перевод видео "The Making of..." пора переименовать в "The Making of pad". А видео... Какое еще видео? Тут было что-то про видео?
А если серьезно. Это гораздо лучше смотрелось бы в теме "Переезд платформы".
ЦитатаDragonFlight
http://s1.uploadpics.ru/images/Wy-LI7daK-.png
КТО Ж ТАКОЕ В PROGRAM FILES РАСПАКОВЫВАЕТ!!
Только в корень, без пробелов в именах и с КОРОТКИМИ названиями (спорю, что тут проблема лишь в том, что максимальный пусть оказался слишком длинным – в просто не захотите знать максимальную глубину каталогов в архиве…).
Плюс, если при первом запуске вылелит с «заблокирован файл базы данных» (как-то так на английском) – просто перезапустить.
Даже если это очки – зачем притворяться мартышкой?..
ЦитатаDragonFlight
Как студент факультета прикладной математики говорю (аж стыдно произносить).
Земляк, что ли?..
Цитатаalteya
все эти рассуждения перенести в какую-нибудь другую ветку?
(всё, даже сова прилетела и дала подзатыльник…) Да вроде эта ветка пока хорошо подходит – свеженькая, ещё не испорченная…
Цитатаalteya
К субтитрам видео они имеют крааайне опосредованное отношение. Ну правда.
Ну я надеюсь, что всё о субтитрах – уйдёт в пад. Тут останутся лишь итоговые варианты, и какие-нибудь общие обсуждения. Копипасты из пада…
Цитатаalteya
И убежит без оглядки.
Мне хочется убежать просто от громадного числа субтитров, которые тут УЖЕ есть.
Цитатаalteya
И потом в этих тоннах откопать крупинки правок весьма затруднительно.
Ну я же не вечно буду этот пад делать (тьфу-тьфу…), и на следующих страницах – будет только по теме. А для навигации новичкам – нужно шапку нормальную собрать, с хорошими инструкциями. Только прежде нужно чётко понять, ЧТО делать, и какой инструмент для работы выбрать. И решать лучше здесь. Я именно и хочу сделать так, чтобы на форуме больше не приходилось копаться – а его нужно было лишь читать, чтобы понимать, что вообще происходит. Переводить сами субтитры нужно не тут…
Нижеследующее (и часть выше, а то не поместилось…) собрано из различных источников, следуя в логичной хронологии. Вот сохранённая копия последнего состояния изменённой темы: http://klimaleksus.narod.ru/Files/48/12828.zip
ЦитатаSviMik
Представь ситуацию, есть исходный текст: "Lorem ipsum dolor sit amet / Sed do eiusmod tempor incididunt"
– Один пользователь удаляет первый фрагмент, у него остаётся: "Sed do eiusmod tempor incididunt" – Второй пользователь дописывает свой вариант слова: "Lorem ipsum/laborum dolor sit amet / Sed do eiusmod tempor incididunt" – Третий пользователь решает, что ipsum не нужен впринципе, у него в паде остаётся: "Lorem dolor sit amet / Sed do eiusmod tempor incididunt" – Четвёртый решает поменять местами Lorem и ipsum (учитываем также смену регистра L и i): "Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt"
ЦитатаSviMik
Вопросы: 1) Что будет, когда все четверо нажмут на синхронизацию? 2) Будет ли результат отличаться в зависимости от того, в каком порядке они будут синхронизироваться? 3) Останется ли вариант второго пользователя "/laborum", и если да - останется ли он приклеен к слову "Ipsum", или уедет в другое место? 4) Если пользователь 1 окажется последним на синхронизацию, его удаление: а) проигнорируется? б) снесёт первую половину вместе с новыми вариантами? в) снесёт частично, оставив ошмётки текста?
Цитата
"Lorem ipsum dolor sit amet / Sed do eiusmod tempor incididunt"
Первый пишет это, все синхронизировались. Старт есть.
Цитата
Один пользователь удаляет первый фрагмент, у него остаётся: "Sed do eiusmod tempor incididunt"
Допустим, синхронизировался первым.
Цитата
Второй пользователь дописывает свой вариант слова: "Lorem ipsum/laborum dolor sit amet / Sed do eiusmod tempor incididunt"
Пока пусть синхронизироваться в этой же очерёдности. У него: «/laborumSed do eiusmod tempor incididunt»
Цитата
Третий пользователь решает, что ipsum не нужен впринципе, у него в паде остаётся: "Lorem dolor sit amet / Sed do eiusmod tempor incididunt"
Поскольку, ипсума уже там всё равно нет, у него тоже: «/laborumSed do eiusmod tempor incididunt» (кстати, это сгенерировало identity-чейнджсет «Z:15>0$»)
Цитата
Четвёртый решает поменять местами Lorem и ipsum (учитываем также смену регистра L и i): "Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt"
А вот тут зависит от того, КАК он сделал эту правку.
Если вырезать «Lorem », изменить первую букву «ipsum» на «I», и вставить «Lorem » после «Ipsum» и исправить «L» на «l» то: «/laborumIpsum lorem Sed do eiusmod tempor incididunt»
Если вырезать «ipsum », вставить перед «Lorem», исправить «L» на «l» и «i» на «I», то: «/laborumIpsum lSed do eiusmod tempor incididunt»
Тут, видимо, зависит от границ вмешательства. Например, если забить на регистр и тупо менять местами слова через вырезать-вставить, то – Лорем направо: «/laborumLorem Sed do eiusmod tempor incididunt» Ипсум нелево: «/laborumipsum Sed do eiusmod tempor incididunt» – значит, когда прикасаются к удалённым словам по буквам – иногда может остаться только изменённая часть, а иногда и всё слово (потому что трогали и справа и слева от него)
Если же удалить «Lorem ipsum», и написать «Ipsum lorem» вручную, то: «/laborumIpsum loremSed do eiusmod tempor incididunt»
Цитата
1) Что будет, когда все четверо нажмут на синхронизацию?
Допустим, четвёртый всё же написал «Ipsum lorem» вручную, тогда:
Цитата
2) Будет ли результат отличаться в зависимости от того, в каком порядке они будут синхронизироваться?
Ну попробуем ещё раз!
Четвёртый меняет на ипсум лорем: «Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt» Третий удаляет ипсум, которого опять уже нету: «Ipsum lorem dolor sit amet / Sed do eiusmod tempor incididunt» Второй приписывает лаборум: «Ipsum lorem /laborum dolor sit amet / Sed do eiusmod tempor incididunt» Первый удаляет начало, эффективно – долор сит амет: «Ipsum lorem /laborum Sed do eiusmod tempor incididunt»
Пусть тогда сначала третий удалит ипсум, второй допишет лаборум, первый удалит начало, а четвёртый пусть только региcтр поменяет, не трогая сами слова:
У третьего: «Lorem dolor sit amet / Sed do eiusmod tempor incididunt» У второго: «Lorem /laborumdolor sit amet / Sed do eiusmod tempor incididunt» У первого: «/laborumSed do eiusmod tempor incididunt» У четвёртого: «l/laborumISed do eiusmod tempor incididunt» (лаборум встал между «И(псум)» и «л(орем)»)
Цитата
3) Останется ли вариант второго пользователя "/laborum", и если да - останется ли он приклеен к слову "Ipsum", или уедет в другое место?
Как видно, останется в любом случае, потому что его конкретно никто не удалял, но при этом откажется он там, где повезёт…
Цитата
4) Если пользователь 1 окажется последним на синхронизацию, его удаление:
– в) снесёт частично, оставив ошмётки текста. Значит, удаление привязывается к конкретному тексту.
Но как я сказал, в моей задаче – будет так, что:
Первый переносит строку и пишет: «Начало нафиг не нужно, оставим только "Sed do eiusmod tempor incididunt"», сам ничего не трогает. Второй тоже переносит строку, и пишет: «давайте "laborum" вместо "ipsum"», ну да и пусть допишет «/laborum» в строку, нормально. Третий говорит на следующей строке, «"ipsum" убрать нафиг!» и делает это. Четвёртый пишет после переноса, «Ipsum lorem» будет лучше звучать, выделяя эти два слова жирным и не меняя их (потому что, допустим, он не уверен, что так действительно лучше).
Кстати говоря, порядок, в котором появляются новые строки после переноса – такой же, в каком они нажимали на синхронизацию: последний писавший окажется снизу, и после синхронизации – сможет непосредственно увидеть, что написали перед ним.
И что бы там не произошло с текстом в исходной строке – последний всегда сможет разобраться, что каждый пытался отредактировать, соберёт на своё усмотрение верный вариант (даже добавит его копию отдельной строкой далее), и потом ещё и к нам на форум обсуждения фразы прямо из пада и скопирует (кстати, мне нужен экспорт в BB-коды…)
Так что норм!
Цитатаalteya
Цитатазагрязнитель тем
свеженькая, ещё не испорченная…
Вооот. Ага. Непорядок! Как это так - люди обсуждают только переводы, и нет ни одного громадного невтемного сообщения!? Срочно исправить!! Ну серьезно. Вы так стараетесь решить все наши проблемы, попутно создавая другие. Вам доставляет неимоверные физические и моральные муки вид чистой темы?
Так… Мне что ли перетащить всё обсуждение туда, вырезав отсюда, да?
ЦитатаSerlutin
aleksusklim, оффтоп не по теме перевода выделен в отдельную тему
ПРОКЛЯТЬЕ!!
Вы только что уничтожили прямые ссылки на посты, спасибо.
Оффтоп, значит? Ну, посмотрим…
Вообще-то, я и сам мог перенести, _аккуратно_.
Цитата
Вообще-то, я и сам мог перенести, _аккуратно_
Цитатаalteya
Ну дык и надо было. После тоооненьких аки двойной бигмак намеков с моей стороны.
Цитата
Оффтоп, значит? Ну, посмотрим…
Цитатаalteya
Звучит как объявление войны... Ради пресвятых кексиков! Не надо "назло всем" постить ЕЩЕ БОЛЬШИЙ оффтоп или делать другую нехорошую каку.
Насчет пропавших ссылок - честно, сочувствую, если они правда имели большое значение.
Цитатаalteya
Ну и напоследок. Только не подумайте, что все кругом (и я в частности) вражины, которые категорически против pad'а и всего с ним связанного. Нет. Если, это и впрямь окажется крутой штукой - я первая скажу вам СПАСИБО. Но единственное чего я не понимаю, так это зачем все расписывать в теме перевода субтитров или других текстовых темах. В отдельной теме это и выглядит куда красивее.
Цитата
Ну дык и надо было.
Видимо, не я один предпочитаю месть шантажу.
Serlutin, не вышло уговорами – возьмём силой? Way to go.
Перекрёстные. Ссылки.
Это же так просто…
+ адекватная шапка.
Цитата
если есть документ Д, и изменение И, то мы получим некий новый документ Д1: Д → (И) → Д1.
ЦитатаSerlutin
Мне кажется, или кто-то придумал децентрализованную распределённую систему управления версиями? Ну точно, всё сходится. Оффлайн. У каждого своя версия. Синхронизация в начале работы и в конце. Хеш для каждой версии и для каждой правки. Ну точно. Это же Git.
ЦитатаSerlutin
И по описанию, чувство, что просто в Git запихнули обычную таблицу, со строками: Оригинал, Перевод, Обсуждение. Проблема лишь в том, что все системы версий и svn, и Git, и Mercurial, и куча других рассчитаны на программистов, а не на переводчиков. Следовательно, либо учить консольные команды, либо устанавливать дополнительные программы. А переводчик — человек творческий. Он не хочет устанавливать и разбираться, он хочет переводить.
ЦитатаSerlutin
Ну вот просто пример оторванный от реальности. Это если бы, допустим, начать переводить фильм, мультфильм или игру. Но попросить, чтобы актёры не просто записывали свой голос и выкладывали, а еще и конвертировали полученный файл в картинку и выкладывали на хостинг изображений. Да если так сделать, то все актеры сразу бы разбежались. Сложно, неудобно, непонятно, долго и, что главное, отвлекает от озвучивания.
ЦитатаSerlutin
Так дальше, я пытался вникнуть в Ипсум лорем и... ничего не понял. В Git как происходит. Если есть конфликт правок, то при слиянии открывается программка (не помню название, гит давно уже не запускал): бла-бла-бла, какой из вариантов выбрать. Если брать GitHub, то при Pull request просто нужную версию выбирает автор репозитория.
Цитата
Теперь каждый их них делает свой документ соответственно 01, 02, 03, Первый синхронизируется со вторым. У них становится 021. Второй синхронизируется с третьим: 0321 (потому что идёт «0(21)» с «0(3)», и «21» дописывается третьему в конец). Теперь первый хочет синхронизироваться с третьим. Имеем «021» к уже «0321». Изначальный алгоритм, вычисляющий позицию слияния по номеру ревизии, выдал бы «0(21)» к «0(321)» равно «032121», что неверно.
ЦитатаSerlutin
Чёт ересь какая-то. Зачем так? Ну допустим есть файл ПИРИВОД.ТХТ Он хранится на гитхабе. Первый пользователь добавляет первую строку, второй пользователь вторую, третий третью. Потом они нажимают git push (ну или как там называется это в чудо-паде) и в итоге получается ПИРИВОД.ТХТ с тремя строками. Если вдруг четвертый пользователь перевел все три строки, не зная, что их перевели другие, то при пуше он получит конфликт правок. Причем даже при одновременной отправке. Git сравнивает под timestamp, где учитываются даже доли секунды (вроде бы). Так что одновременно в любом случае не получится.
Цитата
У третьего: «Lorem dolor sit amet / Sed do eiusmod tempor incididunt» У второго: «Lorem /laborumdolor sit amet / Sed do eiusmod tempor incididunt» У первого: «/laborumSed do eiusmod tempor incididunt» У четвёртого: «l/laborumISed do eiusmod tempor incididunt» (лаборум встал между «И(псум)» и «л(орем)»)
ЦитатаSerlutin
Эм, то есть вместо того, чтобы сказать: «Чувак, с этой строкой что-то не так, какая-то хрень выходит», получается нечитаемая фигня без пробелов? О да, сверх продуктивно. Но в принципе, я даже в это лезть не хочу. Что-то запускающееся на батниках, которое надо хранить в корне диска? Да ни за что.
ЦитатаSerlutin
ЦитатаDragonFlight
Чем вы проаргументируете, что пад удобнее Google таблиц?
Цитатаaleksusklim
Он оффлайновый.
И? Что дальше? Звучит так, как будто все такие. АААА, ну он же оффлайновый. Это всё меняет. Вроде бы из гугл таблиц тоже можно сделать оффлайновую версию. Есть и googledocs offline. Или можно хранить в виде .xslx и править Excel или Calc.
ЦитатаSerlutin
Нет, Гугл Таблицы, конечно, для перевода подходят довольно плохо. Но они позволяют редактировать, где угодно и с чего угодно. Компьютер, планшет, телефон, холодильник. Проблемы с инетом? Ну скачай на комп, переведи, а потом вручную закинь, ничего страшного.
ЦитатаSerlutin
А вот обсуждения? Тут как раз форум удобнее, как мне кажется. По крайней мере для тех, кто переводит у нас субтитры. В любом случае, даже если есть несколько вариантов, выбирать правильный перевод будет кто-то один. У нас переводчиков можно по пальцам пересчитать. Даже одной руки. Да там хоть по телефону переводи, а результат карандашом на туалетной бумаге пиши, а потом отсылай почтой. Всё равно получится.
Цитата
И? Что дальше? Звучит так, как будто все такие. АААА, ну он же оффлайновый.
Это была инсинуация, ибо его достоинства уже были описаны в другом месте.
Цитата
Что-то запускающееся на батниках, которое надо хранить в корне диска? Да ни за что.
Серьёзно? Вы не запустите и не запускали НИ ОДНУ мою программу?
Цитата
Мне кажется, или кто-то придумал децентрализованную распределённую систему управления версиями?
Гитхаб/изерпад/лайт/мастер.зип
Цитата
Чёт ересь какая-то. Зачем так?
Что, совсем никто не понимает различий между _использованием_ программы, и её внутренним устройством.
Цитата
Хеш для каждой версии и для каждой правки.
А это даже смешно.
Цитата
Чёт ересь какая-то. Зачем так?
Поражаюсь, почему мы до сих пор просто не вставили в игру пофикшенный вариант от Вектора, как DrWho завещал?..
Цитата
Ну точно. Это же Git.
Зачем нужен Windows, если есть Linux? Зачем нужен Delphi, если есть C++? Зачем нужен VK, если есть Facebook? Зачем нужен Telegram, если есть WhatsApp? Зачем нужен Mp3, если есть Ogg? Зачем нужен Ожегов, если есть Даль? Зачем нужен Paint.Net, если есть Photoshop? Зачем нужен SourceForge, если есть GitHub? Зачем нужен KMplayer, если есть VLC? Зачем нужен Game Maker, если есть Construct? Зачем нужен Yandex, если есть Google? Зачем нужен Akelpad, если есть Notepad++? Зачем нужен FarManager, если есть TotalCommander? Зачем нужен TeamSpeak, если есть RaidCall? Зачем нужен Nginx, если есть Apache? Зачем нужен NOD32, если есть Kaspersky? Зачем нужен TheBat, если есть Outlook? Зачем нужен Georgia, если есть Times? Зачем нужен Siemens, если есть Nokia? Зачем нужен aleksusklim, если есть steeldragon?
Цитата
все такие. АААА, ну он
Сорян, IPv6 не юзаю.
Цитата
Ну допустим есть файл ПИРИВОД.ТХТ Он хранится на гитхабе.
Вот есть файл «/levels/original-english/01. Sunrise Spring Home.txt», он хранился на GoogleCode. Что, много диффоф и мерджев, коммитов и пулов было эффективно в него совершено?
Цитата
вместо того, чтобы сказать: «Чувак, с этой строкой что-то не так, какая-то хрень выходит», получается нечитаемая фигня без пробелов?
То есть вы прочитали тот абзац – ПРОТИВ которого я выступал, предложив ниже ровно такой, как вы сейчас сказали – и вы используете это как аргумент против меня же?
Цитата
Так дальше, я пытался вникнуть в Ипсум лорем и... ничего не понял.
А потому что это не для вас и ни для кого здесь. Я опубликовал это для того, чтобы иметь ПРЯМУЮ ССЫЛКУ на данный текст.
Цитата
чтобы актёры не просто записывали свой голос и выкладывали, а еще и конвертировали полученный файл в картинку и выкладывали на хостинг изображений
Редактор
Житель Города
