abills.net.ua

Собсна, что мне светит при этом, и какие камни я могу встретитьи что нужно будет обязательно добавлять в базу

ченжлог 0.3 + ченжлог 0.4 наверно проще с 0 поставить

А зверей где брать, не сильно охото со зверми возится

lasik писал(а):А зверей где брать, не сильно охото со зверми возится

ну я ж сказал наверно проще... если тебе проще через ченжлог - счастливого пути

я уж и не знаю, может оставить все как есть ?

Не так страшен *** как его рисуют (с)
Делается копия биллинга на тестовой тачке (как минимум - настраивается вебка), после чего из ченджлога формируется ручками пакет скл-запросов update.sql (ессно, старые в начале, новые в конце)... + откинуть запросы, работающие с таблицами неюзаемых модулей либо в 0.34 создать в базе таблицы для всех модулей - они есть не просят, весят считанные кб, и проще решение - не нуно каждый запрос сверять с базой на предмет наличия таблиц...
после - mysql -u abills -p -D abills <update.sql
после - обновление из cvs
Если все успешно вышло - то же самое проводится на штатном сервере, либо заливается база с тестового... Ессно - предварительно забэкапив все

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

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

А кто подскажет самую эффективную стратегию апгрейда Abills при условии, что локальное дерево тоже менялось? Т.е. хочу внести изменения Abills, но и не потерять своих. Просто cvs up портит некоторые измененные локально исходники, вставляя в них то тут то там '>>>>>>>>' или '<<<<<<<'. Уже вчера пробовал - пришлось возвращаться обратно из бякапов Можно конечно проапгрейдить чистое дерево, и затем попытаться пропатчить свои изменения, это ли единственно верный путь?

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

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

Потом уже обновляю MySQL, и выставляю заново права для папок, проверяю, работает, если все работает нормально, тогда переношу на основной биллинг все кроме MySQL базы, и обновляю базу, и все.

Проведено было всего 1 раз, но действино, ничего не рухнуло, и не были потеряны мои изменения

lasik писал(а):ну это понятно, я просто хочу узнать что мне придется дописывать в таблици, и какие досоздовать

смотреть changelog там все указано

chtito2 писал(а):А кто подскажет самую эффективную стратегию апгрейда Abills при условии, что локальное дерево тоже менялось?

man patch
P.S. патчи лучше делать на каждый измененный файл поотдельности, а не на всю директорию

NiTr0 писал(а):

chtito2 писал(а):А кто подскажет самую эффективную стратегию апгрейда Abills при условии, что локальное дерево тоже менялось?

man patch
P.S. патчи лучше делать на каждый измененный файл поотдельности, а не на всю директорию

Очевидно, что diff/patch не очень хорошо стыкуются при двусторонних изменениях: я думал об этом не было необходимости упоминать. Например, если текстуально патч подойдет, то чисто логически изменения могли быть такими, что теперь произойдет нечто совершенно неожиданное и непредусмотренное.

Отвечу сам себе: скорее всего придется обновлять сырую ветку и затем вручную мерджить все свои изменения

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

а как ты думаешь, почему так во всём мире делается?

chtito2 писал(а):Например, если текстуально патч подойдет, то чисто логически изменения могли быть такими, что теперь произойдет нечто совершенно неожиданное и непредусмотренное.

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