RepoBugGuideAndBehaviour

Работа с хранилището

Откъде да започнем?

Първата работа е да си инсталираме subversion (пакетът в Debian е точно с това име). След това създаваме работно копие на хранилището:

svn co http://fsa-bg.org/repos/gtp

Това може да стане в която и да е директория, например /home/user или /home/user/projects. След като вече имаме работно копие на дадена машина, правим само svn up (или svn update) в директорията gtp. Първата команда на subversion, която трябва да научим, е svn help. Това ще извади списък със всички налични команди. Тези, които ни интересуват най-много, са:

svn update (up) - осъвременяване на работното копие спрямо хранилището

svn status - състояние на работното копие

svn commit (ci) - бухане на промените в хранилището (т.нар. "комитване")

Добавяне на преводи

В момента хранилището е почти празно, затова ако трябва да се коргирира някой превод, правим следното:

Изтегляме си файла, който ще осъвременяваме, например ggv. След това го копираме в директорията gtp/desktop на работното копие на хранилището. Какво забелязваме:

yavor@keel:~/projects/fsa/gtp$ svn status
?      desktop/ggv.HEAD.bg.po

Една въпросителна пред файла. Трябва да го добавим по следния начин:

yavor@keel:~/projects/fsa/gtp$ svn add desktop/ggv.HEAD.bg.po 
A         desktop/ggv.HEAD.bg.po

Сега вече има едно "A", т.е. "add" пред файла; съответно "D" е изтрит, "M" е променен. Превеждаме си програмката и идва време за комитване

yavor@keel:~/projects/fsa/gtp$ svn status
M      desktop/ggv.HEAD.bg.po
yavor@keel:~/projects/fsa/gtp$ svn ci

След което ще се зареди редактора по подразбиране, за да въведете коментарите. В системите под Debian може да видите кой е настроения редактор с:

$ /usr/sbin/update-alternatives --display editor

А може да го настроите, ако не ви харесва:

# update-alternatives --config editor

Може и временно да настроите променливата $EDITOR така:

$ export EDITOR=emacs (може и gedit :-))

В редактора въвеждаме коментари. Това е много важно, тъй като е необходимо колегите да знаят за какво става въпрос, кратко обобщение на извършените промени, например:

(ggv/desktop) Леки промени и стандартизация

  * Променена информацията за преводачите (затваря: #46)
  * "Разпечатка" е променено на "Печат", благодарим на Сульо Пулев (затваря: #38)
  * Премахнати някои мазни форми
  * Подобрена ползваемостта на превода
  * Коригирани n фъзенца
  * Бла-бла-бла, и така нататък

Хубаво е да се пише името на програмата, за да е лесно за ориентиране. Също е добре да се упоменават грешки, които се оправят. След успешния commit се появява съобщение от сорта "Commited revision 14")

Ако пък файла, който ще превеждаме, вече го има в хранилището, заменяме го с новия файл и превеждаме него. Няма смисъл да се променят имената, тъй като има контрол на версиите. Ако превеждаме някой файл от друг клон, то той ще бъде с друго име, например ggv.gnome-2-10.bg.po; след една година спокойно можем да ги изтрием всички файлове от клона 2.10.

Билети

След подаването на превод, който коригира докладвани грешки, отиваме на съответните билети и ги затваряме, например със следния коментар:

Благодарим за доклада, грешката е коригирана съгласно Вашето предложение в ревизия [14]. Имайте търпение, докато обновения превод се появи в дистрибуцията на GNU или *BSD, която ползвате.

Или нещо подобно, но трябва да бъде учтиво и да дава възможност на потребителя да надникне как точно е била оправена грешката, особено ако е било нещо спорно. Идеята е да направим така, че потребителите да се чувстват участници. Това е същия този гъдел, който ни прави щастливи като превеждаме, кара ни да се чувстваме като част от нещо голямо, като малки зъбни колеленца, задвижващи неумолимо машината на свободата. Ако това чувство го изпитат и потребителите, то ще ги подтикне да докладват още повече грешки и да се чувстват полезни. А и на нас ще ни е още по-хубавко.

-- YavorDoganov - 18 Jun 2005