Продолжаю развлекаться с RoR.
Поскольку использовать sqlite неинтересно,
решил заправить какую-нибудь другую СУБД,
например MySQL.


После непродолжительного, но яркого секса сделал следующие выводы:
1. Устанавливать всякие gem лучше через rvm (Ruby Version Manager).
В этом случае вероятность ошибок, выдаваемых gem, падает в разы.
С gem для установки mysql я вообще совладать не смог.
Он ругался и на отсутствие native libraries, потом сказал, мол не могу получить доступ к памяти,
пару раз ложился с суровым некрологом "Segmentation fault". Так что rvm, однозначно.
Да, поставить rvm с помощью gem мне тоже не удалось, пришлось тащить из git-репозитория.
Соответственно, для rvm, понадобится ещё и git.
2. При генерации базы данных возможны неочевидные ошибки.
Так мне выдалось сообщение, цитирую:
  $ sudo rake --trace db:create
  ...
  ** Invoke db:create (first_time)
  ** Invoke db:load_config (first_time)
  ** Invoke rails_env (first_time)
  ** Execute rails_env
  ** Execute db:load_config
  ** Execute db:create
  rake aborted!
  can't convert Fixnum into String
  ...

Ошибка обнаружилась в config/database.yml:
...
username: root
password: 123
...
Чего же такого плохого в этом файле? А вот чего -- пароль доступа к базе воспринят как число, вместо строки, лечится заключением в двойные кавычки. При этом, будь это строка, кавычек не потребовалось бы. Так что be careful, внимательно читайте маны и stackoverflow.com :-)

Теперь о хорошем. Процесс разработки пока что оставляет положительные впечатления и не кажется трудным.
Отдыхаю после си и жаб и жду появления граблей. :-)

В процессе участвуют:
 * локальный репозитарий на компьютере разработчика (ЛРР)
 * удалённый git-репозитарий (УР)
 * локальный репозитарий на тестовом сервере (ЛРТС)
В основном поток изменений направлен в одну сторону ЛРР --> УР --> ЛРТС.
Но иногда приходится делать правки на тестовом сервере и сохранять в локальной копии репозитария.
Соответственно, при очередном pull origin ... происходит merge и ветка постепенно засоряется merge-коммитами.
В борьбе за чистоту локальной версии репозитария тестового сервера теперь делаю так:
  1. Получаю изменения из удалённого репозитария.
    git fetch
  2. Перехожу в нужную ветку.
    git checkout <branch>
  3. Обновляю ветку до состояния в удалённом репозитарии.
    git reset --hard origin/<branch>

Чего не знал — того не знал:
'Существует замечательная команда: git stash. Дословно, stash— припрятывать, тайник. Команда позволяет сохранять локальные незакоммиченные изменения, сбрасывая при этом состояние рабочей копии до HEAD’а. То есть, сказав git stash мы “припрятываем” все локальные изменения, получая чистую рабочую копию, в которую можно смело делать git pull не опасаясь возникновения ненужных merge’й.

После получения из репозитория-origin’а всех новых изменений мы можем смело “достать” “припрятанные” изменения и наложить их на текущую рабочую копию командой git stash apply.

Убедившись в успешном наложении изменений, можно сделать долгожданный git add -u, git commit и git push, после чего (или сразу после git stash apply) можно со спокойной совестью грохать сохранённые изменения командой git stash drop.'

Ссылка на оригинал

 Озадачили меня недавно удалением из нашего git-рапозитария неиспользуемых веток.
Делается это, как известно, не просто, а очень просто: git push origin :<название удалённой ветки>
Всё было хорошо до того момента, как на очередной git push git ответил песней:
  "error: unable to push to unqualified destination: <название ветки>
  The destination refspec neither matches an existing ref on the remote nor
  begins with refs/, and we are unable to guess a prefix based on the source ref.
  fatal: The remote end hung up unexpectedly"
И ещё на один, и ещё...
Вызов git branch -r показывал, что ссылки на эти ветки в удалённом репозитарии существуют.
Оказалось, что эти ветки уже удалены, а ссылки на них остались, лечится так: git remote prune origin.
При этом удаляются все ссылки на несуществующие ветки. Подсказку я нашёл на stay-calm.blogspot.com/