Добрейшего.
Подкинули ссылку на хорошую статью из серии "10 тут-написать-самое-важное". Не смог пройти мимо, т.к. речь - о контроле версий! Называется The 10 commandments of good source control management, или "10 заповедей хорошего контроля версий".
Надо бы её перевести, но пока - перечень Важных Вещей:
Подкинули ссылку на хорошую статью из серии "10 тут-написать-самое-важное". Не смог пройти мимо, т.к. речь - о контроле версий! Называется The 10 commandments of good source control management, или "10 заповедей хорошего контроля версий".
Надо бы её перевести, но пока - перечень Важных Вещей:
- Если используете VSS - бросьте сейчас же. Прям щас!
- Если что-то не лежит под контролем версий - этого не существует.
- Делайте коммиты раньше, чаще и не откладывая.
- Всегда проверяйте изменения перед коммитом.
- Помните про психопата с топором перед написанием комментариев.
- Делайте коммиты сами, не перекладывая на других.
- Версионности БД избежать не получится.
- Результаты компиляции не кладутся под контроль версий.
- Никому не интересны ваши личные настройки.
- Зависимости надо тоже пристроить.
s/VSS/VCS :-)
ОтветитьУдалитьНет-нет, всё верно - есть (пока, к сожалению) такой зверь VSS - Visual Source Safe. Уродливая штука, за какой-то надобностью поддерживавшаяся Майкрософтом долгие годы. Поскольку автор - адепт МС-технологий, отсюда и первоочередной призыв сделать жизнь лучше :)
ОтветитьУдалитьТогда прошу прощения, принял за опечатку :-)
ОтветитьУдалитьПоследний стабильный релиз VSS датирован 2005 годом. Тем более пора забыть.
[попыткф толстого троллинга]А что, микрософтские поделия ещё кто-то использует!?
ОтветитьУдалитьПо делу. Автор, хоть бы текст перевёл, что ли. Лень матушка и облом батюшка, да? :-)
Мне больше понравилось вот это. Написано коряво и нескладно, но ценных идей больше.
По пунктам. 1 и 6 просто странные (особенно 1 - это личные трудности автора оригинального поста). Пункт 7 я не понял вообще - можно пояснить?
Пункт 5 все знают, но никто не делает :-) У меня тоже встречаются комменты типа "minor" - ну минор он и есть, если я только поменял пару рабочих параметров при прогоне программы, хвастаясь шефу.
Пункт 8 спорен. Кому как: у меня кладутся, ибо важны (под результатом компиляции имеется в виду сохранение текущих значений некоторых переменных в файл). Это может быть важно, но не в случае автора.
И да, бойтесь ставить ссылки на всякие гуглогруппы и списки рассылок - дублируйте со ссылкой нужный текст обсуждения. Кто-нибудь потрёт обсуждение, а вы останетесь с битой ссылкой. Особенно обидно читать про решение нужной проблемы: ткнёшься, а там 404. Не айс.
[троллинг моуд]Серьезные люди тока их и использют!!![/троллинг моуд]
ОтветитьУдалить:)
Насчет перевода - тратить время на перевод стоит только ради "программных" заметок, рассказывающих о правильных с моей точки зрения вещах, которые не устареют через год-два-три. Например,
http://scm-notes.blogspot.com/2010/09/branch-per-task-workflow-explained.html
Заметки же из серии "для чайников" или "10 самых-самых" - того не стОят :) Да и вообще, техническому специалисту стыдно английский не знать, хотя бы на уровне тения таких вот заметок :)
По пунктам.
1 - да, это актуально только для адептов МС :)
6 - ну, это актуально в больших командах, встречал такое сам.
7 - актуальная вещь, на мой взгляд. Однако весьма непроста в реализации, к сожалению.
5 - это вопрос самодисциплины. Проще всё время писать осысленные коммиты, чем каждый раз думать - понадобится кому-то их читать или нет. Не знаешь ведь никогда как что повернется
8 - всё верно написано. Т.н. deliverables как правило выходят в рамках релизов, в т.ч. и конфиги. Релизы обычно кладут вне контроля версий, в т.н. release areas - чтобы зашел со стороны, скачал что надо и нае парился контролем версий. Конечно, могут быть исключения, но общее правило - лучше результаты компиляции не хранить.
Касаемо ссылок - тут тот самый облом-батюшка :) Это ж копировать, форматировать. Но вообще - да, надо :)