Репозиторий на Github. Будет ли?

[rb2]

У меня такой вопрос возник. Допустим, есть релиз opencart, на основе которого сделан релиз ocstore. Вносятся в релиз ocstore многочисленные правки и изменения. И вот выходит новый релиз opencart. И получается всё по новой? Как отслеживать такие ситуации?

Да, по новой. Все изменения сливать вместе вручную.

Делать это можно либо раз, после выхода релиза, либо отслеживая изменения (по истории коммитов) и синхронизируя изменения сразу в свой репозиторий.

Если бы Опенкарт хостился на гитхабе, а ocStore форкнулся от него там же - всё было бы раз в 10 проще, быстрее и вообще на автопилоте.

И не проще ли в этом случае присоединиться к разработчикам opencart?

Проще в смысле лучше? Да, лучше. Но просто это было бы в случае, если бы авторы опенкарт хотели, чтобы к ним присоединялись.

[JohnnyVega]

Делаеть это можно либо раз, после выхода релиза, либо отслеживая изменения (по истории коммитов) и синхронизируя изменения сразу в свой репозиторий.

Т.е., грубо говоря, после каждого релиза opencart Вы каждый раз вносите туда свои изменения, доработки и т.д. А как в этом случае Вы храните свои наработки? В виде diff'ов?

Если бы Опенкарт хостился на гитхабе, а ocStore форкнулся от него там же - всё было бы раз в 10 проще, быстрее и вообще на автопилоте.

Простите мою безграмотность, но что означает "форкнулся"?

Проще в смысле лучше? Да, лучше. Но просто это было бы в случае, если бы авторы опенкарт хотели, чтобы к ним присоединялись.

Я Вас правильно понял, что Вы имеете ввиду, что авторы opencart не хотят, чтобы к ним присоединялись? Как Вы думаете почему? Пробовал присоединиться кто-либо к ним?

[rb2]

Т.е., грубо говоря, после каждого релиза opencart Вы каждый раз вносите туда свои изменения, доработки и т.д. А как в этом случае Вы храните свои наработки? В виде diff'ов?

Я в общем-то не участвую в развитии ocStore: не хватает времени на свои проекты, поэтому не хочется брать на себя ещё что-то. А в целом да - насколько понимаю, берется ocStore в одной папке, новый релиз Opencart в другой, и вручную все изменения просматриваются и сливаются вместе.

У меня сейчас проекты - это локальные ветки, отпочкованные от основного репозитория Опенкарта. Всё, что приползает туда, я легко получаю к себе. Отдельно храню лишь некоторые доработки, которые надо отдавать другим (в виде diff-файла и папки с измененными файлами). В целом diff-ы не являются универсальным способом долго хранить изменения: если код к тому времени изменится, автомат не сможет справиться с автоматическим применением этого патча и всё придётся разбирать вручную, разрешая конфликты. Имеющийся дифф можно легко и просто применить к определенной версии проекта (когда точно известно, в каком состоянии исходные файлы и конфликтов не будет). А если пройдет какое-то время - эти места и эти файлы могут уже измениться, и patch обломится.

Простите мою безграмотность, но что означает "форкнулся"?

Форк - это отдельная ветка проекта, которая может развиваться параллельно. На каком-то этапе копия ответвляется и в ней ведется работа. Но при этом сохраняется связь с "родителем" и вносимыми изменениями можно обмениваться: в копию интегрировать внесенные в основной ветке изменения (если развитие фичи в отдельной ветке затянулось по времени или же ветка изначально создавалась как параллельная альтернатива) или наоборот, включить обратно все новые изменения из ветки (форка) в основной родительский проект. На гитхабе это очень просто и удобно происходит: в Git работа с ветками, в отличие от SVN - базовая, простая, мощная и очень удобная процедура. И форки может делать кто угодно - для этого необязательно просить разрешения авторов и ждать, когда же они рассмотрят и одобрят твою кандидатуру. Делается форк, в нем ведется работа, отдельные ветки своего проекта можно "вернуть" пулл-реквестом, предложив включить в основной проект. То есть нет никакой проблемы активно подключиться к процессу разработки. Не понравится авторам - форк будет развиваться сам по себе, параллельно, понравится - изменения будут включаться в основной проект, понравится настолько, что новому разработчику станут доверять - его просто подключат в список тех, кому разрешены коммиты в основной проект, и он может там работать. То есть на всех этапах есть связь с "родительскими" проектами и обмениваться изменениями очень просто.Без всякой ручной работы в виде диффов и патчей и никак не связанными проектами, которые сложно синхронизировать.

http://ru.wikipedia.org/wiki/Форк

http://en.wikipedia....are_development)

http://help.github.com/fork-a-repo/

Как это работает в идеале, можно посмотреть на примере CodeIgniter: github EllisLab/CodeIgniter - contributing.md

Почитайте там секцию "Branching" и "How-to Guide", надеюсь, станет понятнее.

Я Вас правильно понял, что Вы имеете ввиду, что авторы opencart не хотят, чтобы к ним присоединялись? Как Вы думаете почему? Пробовал присоединиться кто-либо к ним?

Они без проблем принимают какие-то правки в виде патчей, но по большей части мелочь какую-нибудь. С больее обширными изменениями возникают проблемы. Во-первых, Даниэль считает себя крутым разработчиком, и часто на разумные советы более опытных программеров такую бочку катит и обзывается, что люди натурально в шоке от такого поведения и перестают вообще общаться с ним. Потом он, правда, иногда извиняется, но в общем все об этом в курсе. Понять его в какой-то мере можно, он болеет за своё детище. В силу технической ограниченности им сложно взять какое-то большое изменение (типа того же SeoPro), ответвить, протестить с ним, убедиться что всё ок и включить в основную ветку. Они просто не умеют - Qphoria (автор vQmod и второй человек, кто имеет право коммитить в Опенкарт репозиторий), только недавно начал экспериментировать с ветками в SVN. В общем, они технически и психологически не готовы к модели совместной разработки. Там немного голову перестраивать надо, концепции разработки и взаимодействия немного меняются. Они же более по-старинке работают. И поэтому им сложно впускать в свой внутренний круг других разработчиков, поскольку при этой модели (одна ветка и в ней всё меняется) усложняется процесс контроля за изменениями, нет никаких автоматизированных юнит-тестов, и т.д. и т.п. Они не готовы легко приветствовать новых разработчиков и координировать их деятельность. Даниэль активно кодит, считает, что делает это очень хорошо и, разумеется, разбираться с чужими правками -- ему не до этого. Поэтому он злится, когда его критикуют, ревностно относится к изменениям и т.п. Не знаю, насколько это плохо или хорошо - опенкарт живет и развивается силами одного человека и какой-то помощи сообщества, так что пока работает - пусть работает как умеет. Это его путь и его продукт. Многие теоретики и более опытные разработчики и этого не могут. Поэтому даже при всём при том, за что его можно люто ненавидеть, я его усилия уважаю, хотя и приятным общение и попытки участия в развитии трудно назвать.

Для примера можно посмотреть, сколько в приведенном примере (репо CodeIgniter на гитхабе) форков и разработчиков участвуют в развитии и исправлении этого движка. Если Вы читали ругань Даниэля в багтрекере и на форумах - ему до такой открытой совместной разработки ещё очень долго расти. CodeIgniter не так давно открыли и перенесли разаработку на гитхаб - 1-2 года, но результат заметен и после этого решения, принятого EllisLab, его развитие существенно ускорилось.

[JohnnyVega]

rb2, спасибо за столь развёрнутый ответ. Я до этого СВН использовал, причём довольно непродолжительное время. И сейчас каша в голове.

Ещё пару вопросов.

1) Насколько я знаю, Вы в основном используете оригинальный opencart. Почему? При использовании оригинального opencart Вы вручную исправляете его косяки с отображением русских букв, Сео и т.д? Может быть тогда проще (лучше?) в Git репозиторий заливать копию оригинального opencart, чем ocstore?

2) Вы можете написать типовые команды для начинающих работать с Git, этакий HowTo или FAQ с привязкой к https://github.com/rb2/ocstoreru? Т.е., как получить себе копию репозитория, как сделать в нём отдельную ветку со своими изменениями, как потом опубликовать эти изменения. Т.е, те вопросы, которые будут возникать у новичков.

3) Нужен какой-то список, в котором указывается какие изменения нужно сделать при выходе очередной версии ocstore. Например, добавил в Git репозиторий кто-то мод по водяным знакам. К примеру, из админки можно выбирать водяной знак и его расположение. Всё хорошо, это используется. Затем вышла новая версия ocstore, и чтобы не забыть все эти изменения, открываем список, смотрим какие нужны изменения и накатываем их снова на новую версию ostore. Суть такая. Возможно, можно делать это по-другому. Если кто-то знает, пож-та, напишите.

[mva]

Товарищи! Лень перепосчивать пост полностью, но: https://opencartforum.com/topic/9112-перенос-разработки-на-github/page__pid__59584

(отвечать можно сюда)

P.S.:

https://github.com/msva/ocStore (основная (на данный момент) ветка разработки, которую я пилю и использую на своих магазинах)

https://github.com/ocStore/ (организация на гитхабе, куда я, собственно, и приглашаю разработчиков свн-версии). Babushka'е и rb2 уже выслал инвайты, т.к. они уже есть на гитхабе. Если они отпишут о согласии — перенесу репозиторий с моего аккаунта в организацию.

[mva]

2) Вы можете написать типовые команды для начинающих работать с Git, этакий HowTo или FAQ с привязкой к https://github.com/rb2/ocstoreru? Т.е., как получить себе копию репозитория, как сделать в нём отдельную ветку со своими изменениями, как потом опубликовать эти изменения. Т.е, те вопросы, которые будут возникать у новичков.

git clone https://github.com/rb2/ocstoreru #(но лучше мой форк, который будет на https://github.com/ocStore/ocStore/ )

Всё. Всё скачано, можно ставить и использовать

обновлять —

git pull
# (хотя лучше git stash && git pull && git shash apply && git stash clear
# для того, чтобы исключить пересечение изменений в файлах).

3) Нужен какой-то список, в котором указывается какие изменения нужно сделать при выходе очередной версии ocstore. Например, добавил в Git репозиторий кто-то мод по водяным знакам. К примеру, из админки можно выбирать водяной знак и его расположение. Всё хорошо, это используется. Затем вышла новая версия ocstore, и чтобы не забыть все эти изменения, открываем список, смотрим какие нужны изменения и накатываем их снова на новую версию ostore. Суть такая. Возможно, можно делать это по-другому. Если кто-то знает, пож-та, напишите.

1) по возможности делать через vqmod, тогда вряд ли придётся что-либо накладывать.

2) я стараюсь всякие вкусные модули добавлять и синкать все изменения с текущей SVN-копией. Если удастся переманить разработчиков на гитхаб — буду синкать с опенкартом

3) опять же в первой части ответа я дал объяснение как не потерять свои изменения после апдейта (перечисляю команды для Linux/FreeBSD, которые обычно стоят на хостинг-серверах):

# переходим в директорию с мазагином.
mkdir ../backup && cp  -r . ../backup #копируем старую копию магазина на всякий случай. Мало ли что.
git stash # кладём всё, что у нас изменено локально (конфиги, кеш, картинки) в "сундук".
git pull #обновляемся
git shash apply #вытаскиваем из сундука всё на место
#тут, если надо вносим правки, в то, что вытащили из сундука.
# Потому что после апдейта некоторые "самопальные" вещи могут ломаться)
git stash clear #после успешных (!!!!!!!) правок и проверки (!!!!!!!) на магазине
# убедившись, что всё прекрасно работает — удаляем из сундука копию того, что мы туда клали.
# Иногда, кстати, обновления не проходят "бесследно" (при сильном апгрейде опенкарта) и
# даже апгрейд через инсталл-скрипт может не спасти, тогда придётся переустанавливать магазин.
# (хотя мы попробуем решить этот вопрос. Я, вот, думаю про создание интерфейса для
# автонакладывания обновлений в SQL-базу)
# Если всё успешно обновилось и работает как часы (и ТОЛЬКО в этом случае) — удаляем бекап:
rm -rf ../backup

[JohnnyVega]

Склонировал репозиторий https://github.com/rb2/ocstoreru к себе на комп. Сделал небольшое изменение. При попытке залить изменения на https://github.com/rb2/ocstoreru выдаёт ошибку. Нет прав доступа. Как заливать свои изменения на https://github.com/rb2/ocstoreru (или в другой репозиторий)?

[mva]

Склонировал репозиторий https://github.com/rb2/ocstoreru к себе на комп. Сделал небольшое изменение. При попытке залить изменения на https://github.com/rb2/ocstoreru выдаёт ошибку. Нет прав доступа. Как заливать свои изменения на https://github.com/rb2/ocstoreru (или в другой репозиторий)?

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

Тогда репозиторий склонируется в Вашу локальную копию, вот её уже и сливать на комп, вносить изменения, коммитить, отправлять на гитхаб.

А когда всё что нужно будет закоммичено и отправлено на гитхаб — на страничке репозитория (своего) нажать кнопочку Pull request. И в открывшейся формочке описать суть изменений.

Вариант без регистрации: вносим изменения, делаем git commit а вместо push — делаем

git format-patch -1 # ну или вместо единицы пишем сколько коммитов было сделано

Потоп получившийся файлик (или файлики, если коммитов несколько) отправляем либо по e-mail либо аттачим на форуме (и пишем в личку ссылку на тему с файликами) :)

[JohnnyVega]

mva, спасибо за ответы.

По поводу списка изменений. VQmod не все используют и не всем он нравится, и не всегда его возможно сделать + это дополнительное время на создание xml. Вопрос остаётся открытым.

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

Сделал так. Пул реквест отослал... Получается непосредственно в репозиторий rb2 коммитить нельзя? Только Пул реквест? Или rb2 должен добавить человека, чтобы он мог коммитить в репозиторий rb2?

Ещё вопрос по форку. Форк автоматом обновляется с первоисточника? Или дополнительные действия нужны для обновления?

[mva]

mva, спасибо за ответы.

По поводу списка изменений. VQmod не все используют и не всем он нравится, и не всегда его возможно сделать + это дополнительное время на создание xml. Вопрос остаётся открытым.

Ну, мне кажется, когда он уже из коробки стоит — его можно хотя бы не замечать, если не нравится. :)

Сделал так. Пул реквест отослал... Получается непосредственно в репозиторий rb2 коммитить нельзя? Только Пул реквест? Или rb2 должен добавить человека, чтобы он мог коммитить в репозиторий rb2?

Да, именно так. Если он даст доступ на коммит в его репозиторий — можно будет делать git push туда. Если нет — fork & pull request.

Ещё вопрос по форку. Форк автоматом обновляется с первоисточника? Или дополнительные действия нужны для обновления?

Нет, он не синхронизируется автоматом, ибо при активной разработке это бы вызвало множественные коллизии при изменениях в одних и тех же файлах.

Поэтому если хочется обновиться из репозитория —

git pull https://github.com/rb2/ocstoreru

а потом разрешаем конфликты, если таковые выявились.

Для этого открываем файлы ан которые жалуется гит, ищем там ">>>>>>>>>>>>>>>>>>>>>", и приводим в соответствие с нашими желаниями:

Схема примерно такая:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
строки
из
нашего
варианта
===================================
строки
из
скачанного
варианта
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
номер коммита

Это если я правильно помню :). Нужно оставить только строки, которые нам нужны и сделать git merge.

Хотя, вообще, такое больше применимо при разработке в пределах одного репозитория. Если, например rb2 не будет принимать пулл-реквесты, а Вам не захочется терять свои изменения, то лучше будет всё же вместо форка использовать его репозиторий и просто перед обновлениями прибегать к сундуку :)

[rb2]

Ну, мне кажется, когда он уже из коробки стоит — его можно хотя бы не замечать, если не нравится. :)

Здоровенную, шипастую и с заусенцами, занозу в заднице, обмазанную ядом, трудно не замечать.

Нет там никакой долгосрочной гарантии и панацеи. Все vQmod изменения зависят от точности исходного кода, на который надо наложиться, и если он изменён - каюк. Ждите обновлений. А то и хуже. В одном XML много патчей, а магазин допиливается и меняется? Будьте готовы, что часть патчей наложится, а часть нет. Таких XML-ек штук 50? Причем скорей всего вносящие кучу изменений в одни и те же места - страницы категорий и товаров? Та же фигня. Можете начинать феерично ругаться. Работает на Opencart? Не факт, что будет работать на OcStore (см. выше про изменения в исходном коде, про котрое авторам vqmod-овских xml ничего не известно). Работает на Default теме? Не факт, что будет работать на вашей. Работает сегодня? Не факт, что будет работать завтра, после очередного изменения или добавленного мода.

vQmod - тот же patch (и имеют одни и те же проблемы), только постоянно запущенный и работающий при каждом хите (каждом запросе страницы). Толстый слой-прослойка, который непонятно зачем нужен. Точнее, понятно, зачем (кому) изначально, но на живом сайте, да программистами применяемый - это из раздела "сидеть на пороховой бочке" и себе же проблемы выдумывать, не видя код перед глазами, а гадая, как он соберется на лету и в каком порядке vqmod-ины обрабатываются. Насмотрелся я проблем, источником которых почти всегда был vQmod, применяемый направо и налево и с большим аппетитом. И с логами ошибок по сотне мегабайт.

[mva]

окей, уговорил, впилю изменения из xml'ок "на живую" и выкину его нахрен :)

Ты лучше скажи, согласен ли объединить усилия в gh://ocStore/ocStore (и видел ли инвайт, который прилетел) ? :)

P.S. кстати, я там кучу поправок в твой перевод внёс, но всё влом сделать пулл-реквест :Р

[JohnnyVega]

rb2, тоже не совсем прав, говоря про vqmod. Скажем так, можно и файл со всеми изменениями vqmod посмотреть. И при правильном и аккуратном подходе косяков он особых не вызывает. У меня 20-25 xml стоит - косяков нет. Кто-то на этом форуме отписывался о порядке 70 xml. Тоже проблем нет. Другой вопрос, что новичкам бездумное использование vqmod может много проблем подкинуть. Это да. vqmod - это просто ещё один инструмент, а кто и как им воспользуется это уже другой вопрос. Как электричество. При неаккуратном обращении может убить, но в большинстве случаев приносит пользу.

[JohnnyVega]

согласен ли объединить усилия в gh://ocStore/ocStore?

А в чём преимущество именно в этом варианте по сравнению с тем, что есть сейчас (Ваш репозиторий или rb2)?

[mva]

А в чём преимущество именно в этом варианте по сравнению с тем, что есть сейчас (Ваш репозиторий или rb2)?

ну, если вкратце, то я стягиваю самое вкусное со всех источников и в добавок допиливаю то, чего нет ни в svn, ни в rb2'шной репе.

Ну и в те моменты когда не забиваю из-за большого к-ва работы — намного быстрее фикшу найденные проблемы.

Так же, кстати, в моей репе готовый драйвер PostgreSQL, правда, его хватает только на установку и на вывод стартовой страницы мазагина. Остальное упирается в кучу моделей, заточенных на MySQL напрямую, вместо использования драйвера.

Но я собираюсь как-нибудь на досуге начать и это дело исправлять.

Плюс к этому, как я уже отметил выше — куча фиксов переводов, которые упущены и у rb2 и в svn.

Ну и так, по мелочам.

[JohnnyVega]

Вопрос к знатокам Git. Как обновлять fork? Насколько я понял нужно обновить локальный репозиторий с источника форка, а затем из локального репозитория обновить свой форк. Правильная последовательность действий?

[mva]

Вопрос к знатокам Git. Как обновлять fork? Насколько я понял нужно обновить локальный репозиторий с источника форка, а затем из локального репозитория обновить свой форк. Правильная последовательность действий?

да.

git pull <адрес источника>
# если надо — merge, resolve и прочее. Это уже отдельная тема
git add .
git commit -am "pulled from upstream"
git push

[rb2]

1) Насколько я знаю, Вы в основном используете оригинальный opencart. Почему?

Сначала - потому что не нашёл ocStore. Нашёл (в июне-июле год назад) Опенкарт (он уже был 1.5), нашёл myopencart.ru - но там был только 1.4. Форум увидел, но т.к. было написано, что это форум поддержки, то ничего сверх того, что есть на сайте, не ожидал. Да и насколько понял тогда из описаний, ничего необычного там не ожидалось - ну русификация готовая, ну модули доставлены и упаковано в готовом к употреблению виде - в общем всё то, что и самому вроде несложно сделать (добавить модулей). Я не очень люблю готовые сборки, поскольку там обычно вкусы не совпадают, плюс у меня древняя фобия русифицированных продуктов - там всегда оказывается гораздо больше ошибок и обновляются они гораздо менее оперативно своих англоязычных источников.

Русского перевода для 1.5 вдобавок тоже не обнаружил, поэтому нашёл кое-какую, но всё же базу, чтобы не всё делать, и перевёл магазинную часть - к тому времени уже понял, что Опенкарт мне нравится и с удовольствием пересяду на него с Престашопа.

Ну а потом уже оказалось, что форум - не поддержки того продукта, а вообще своя параллельная реальность. И что сейчас это сайт - придаток к форуму, а не наоборот. Но мигрировать на ocstore к тому времени уже не хотелось - я обрастал своими изменениями, а в списках фич ocstore не находил ничего такого, что заставило бы взять и потратить время на миграцию. Потом полгода мониторил ветку обсуждения 1.0.1 и не мог воспроизвести у себя массу упоминавшихся проблем. Что тоже не добавляло энтузиазма в миграции именно на ocStore.

При использовании оригинального opencart Вы вручную исправляете его косяки с отображением русских букв, Сео и т.д?

Какие косяки? Когда были (в 1.5.1) - да, исправлял. Сео меня и встроенное вполне устраивает, там rel=canonical есть. SeoPro - можно было бы, но острой необходимости до сих пор не вижу, а его надо искать и выковыривать, в виде отдельного модуля его уже нет.

Может быть тогда проще (лучше?) в Git репозиторий заливать копию оригинального opencart, чем ocstore?

Конечно лучше. Но лучше это будет, если из него ветку или форк сделать, в неё поместить ocStore и дальше там продолжать работать. Тогда, при наличии связи с родительским проектом, оттуда можно будет автоматически втягивать изменения из OC в OCS. Нет такокй связи и общих коммитов (как например в SVN репо ocstore или у @mva) - до свидания. Обречены на ручную работу по синхронизации. Это на застежку-молнию похоже: если две ветки сцеплены, то смержить их -- просто, как потянуть за застежку. Если они живут отдельно и никак не связаны - пробовали когда-нибудь старую молнию руками "связывать"? Можно, но неудобно. И часто местами возникают несовпадения, когда терпение собирать эту змейку вручную равномерно лопается.

Сейчас я выложил на гитхаб опенкартовский SVN репозиторий. Он обновляется регулярно, и всё, что появляется на гуглокоде в репозитории Опенкарт - транслируется на гитхаб. Авторский гитхаб репозиторий не обновлялся 9 месяцев, так что взять его за основу для форка не получится, к сожалению. Так что если взять сейчас и выстроить цепочку OC -> OCS, можно было бы продолжать там, получив возможность вливать в OCS свежие правки OC по мере их появления. Полностью схему я не выстраивал и не проверял, потому что первичное слияние OCS в эту ветку не обойдетя без уймы конфликтов, которые сперва надо будет разрешить.

Змінено 9 травня 2012 користувачем rb2

[rb2]

Ты лучше скажи, согласен ли объединить усилия в gh://ocStore/ocStore (и видел ли инвайт, который прилетел) ? :)

Во-первых, какие усилия? Я же написал, что практически никак сейчас не участвую, свободного времени нет.

Во-вторых, твой подход никак не решает основную проблему обновлений ocStore. Устанет очередной babushka, Yesvik, mva или кто-то ещё заниматься синхронизацией - и опаньки. Ждём очередного супер-героя. То есть твой подход приведет к тому же, что сейчас и так есть, только из других рук. А нелюбовь к лишним пробелам и CRLF-ным концам строк сделает гарантированным 100% конфликтов при попытке слияния с оригиналом OC ;)

[JohnnyVega]

Давайте всё-таки подумаем, как мы можем организовать совместную разработку.

Основная проблема в том, что мы не можем влиять на разработку оригинального opencart. Т.е., если представить, что мы сделали много-много улучшений и доработок в ориг. opencart, то возникает проблема их дальнейшей поддержки. Т.е., когда выходит новая версия opencart, нужно адаптировать под неё свои доработки. И чем больше таких доработок, тем дольше и труднее адаптация.

Из этого следует, что все изменения и дополнения должны как можно меньше затрагивать ядро opencart. Можно ли это реализовать технически? Если в доработках присутствую JAVA-скрипты и CSS-стили их можно подкидывать в header.tpl. Если в дополнении значительно меняется код движка, то можно эти изменения выносить в отдельные функции, либо в отдельные файлы, либо вызовы частей системы (например, оформление заказа) заменять целиком своими файлами. Смысл в том, чтобы минимизировать изменения в движке... Либо вообще сосредоточить усилия на написании необходимых дополнительных модулей (например, сделать нормальные фильтры и т.д.)

Кто что думает по этому поводу?

[Sammy95]

А нелюбовь к лишним пробелам и CRLF-ным концам строк сделает гарантированным 100% конфликтов при попытке слияния с оригиналом OC ;)

У команд diff и patch есть специальные ключи для игнорирования таких нюансов.

[mva]

У команд diff и patch есть специальные ключи для игнорирования таких нюансов.

Кстати, да, я уже сливал с новым опенкартом (после его мерджа в SVN) и особых проблем не возникло :)

[rb2]

У команд diff и patch есть специальные ключи для игнорирования таких нюансов.

Я нашёл только два, и они не спасали. Надо либо все файлы держать у себя с определенными концами строк (и транслировать их между сервером и рабочей копией), либо держать такими же, как у оригинала.

[Sammy95]

Попробуй

diff -uw file.php.orig file.php

Если у тебя не линукс, то задача сводится к поиску утилиты, которая поддерживает аналогичный функционал.

[JohnnyVega]

Свершилось!

https://github.com/opencart/opencart

Закидаем Даниэля пуллреквестами? :-)