Статья очень круто написана, спасибо! Но для понимания того, как работает библиотека, хотелось бы увидеть график взаимодействия ее основных компонентов.
Конечно, это можно понять из кода в примере, но вот времени на это нет(
В случае Android пользователю выдается предупреждение о том, что приложение может находиться поверх других. Да, мало кто их читает, но это все же защита. Более того, это средство OS, а не баг, как в этом случае.
В svn:externals есть возможность указать конкретную ревизию. Да и ссылаться в svn:externals нужно на соответвующий релиз-тег библиотеки, а не на транк.
Я не знаю как, но я обошел это стороной… А ведь было введено еще в версии 1.5!
И про tags я тут не написал очень зря…
Какие правила вы тут имеете в виду?
Правила именования папок проекта. trunk — для основной ветви разработки, tags — для состоявшихся релизов и branch для новых фич, которые не нужны пока что в основной ветви.
… то это видно при выполнении svn log --stop-on-copy в бранче. Если бранч создавался как svn cp ^/trunk ^/branches/branchName, то ответвление произошло от ^/trunk@[branch revision — 1], где branch revision — последняя запись в выводе svn log --stop-on-copy (хотя ревизия [branch revision — 1] могла быть совершена не в транке, но ^/trunk@[branch revision — 1] указывает на вполне конкретное состояние транка).
С этим я согласен, но пункт был не про branch, а про обычную разработку. То есть вы обновились и начали что-то делать. При этом у вас ревизия была 2, а когда вы захотели закоммититься, то получилось так, что этот коммит оказался под номером 11. И все выглядит так, что при коммите вы основывались на версии 10, а не на 2ой. И это уже никак восстановить нельзя.
Либо вы берете одну из неиспользуемых рабочих копий (которые образовываются в результате «заново выкачивать все сорци с последней ревизии») и делает svn switch / svn up в ней.
Если я правильно понимаю, то вы тут говорите о ситуации, когда программист находится в branch и переключается обратно в trunk. Однако, я имел в виду то, что он и так уже находится в trunk и просто работает, когда к нему приходят. Хотя, возможно, я не верно понял…
Спасибо большое за замечания. Некоторые вещи не знал и рад, что вы о них сказали =)
Вы же сами говорите, что в целом децентрализованные системы контроля версий выигрывают у svn (централизованной системы) при условии, что над проектом работает не менее двух человек, либо этот проект быстро развивается или включен в другой проект. И статья была именно об этом. Не понимаю при чем тут сравнение git и hg.
Я согласен, что не очевидных моментов у Git больше, но, как я и писал в статье, в компании часть сотрудников уже пользовалась Git (малая, но все же). И просто не решились вводить в интеграцию с существующими сервисами еще одну систему контроля версий.
Конечно, это можно понять из кода в примере, но вот времени на это нет(
Подскажите, минимальное расстояние до спутника 10км или 10тыс км?
Я не знаю как, но я обошел это стороной… А ведь было введено еще в версии 1.5!
И про tags я тут не написал очень зря…
Правила именования папок проекта. trunk — для основной ветви разработки, tags — для состоявшихся релизов и branch для новых фич, которые не нужны пока что в основной ветви.
С этим я согласен, но пункт был не про branch, а про обычную разработку. То есть вы обновились и начали что-то делать. При этом у вас ревизия была 2, а когда вы захотели закоммититься, то получилось так, что этот коммит оказался под номером 11. И все выглядит так, что при коммите вы основывались на версии 10, а не на 2ой. И это уже никак восстановить нельзя.
Если я правильно понимаю, то вы тут говорите о ситуации, когда программист находится в branch и переключается обратно в trunk. Однако, я имел в виду то, что он и так уже находится в trunk и просто работает, когда к нему приходят. Хотя, возможно, я не верно понял…
Спасибо большое за замечания. Некоторые вещи не знал и рад, что вы о них сказали =)