Насчет пенсии — думаю, зависит от группы налогообложения. Те, кто ежемесячно/ежеквартально платят фиксированную сумму в ПФ — могут рассчитывать на минималку.
Правила именования папок проекта. trunk — для основной ветви разработки, tags — для состоявшихся релизов и branch для новых фич, которые не нужны пока что в основной ветви.
Это лишь соглашение по именованию. Как вы сами правильно отметили, svn — это всего лишь папки и файлы, так что можно придумать и другую структуру.
С этим я согласен, но пункт был не про branch, а про обычную разработку.
Но бранч — это и есть обычная разработка :)
Впрочем, понятно, вы имели в виду мерджи в пределах одного бранча. Это довольно редкая для меня ситуация, поскольку мы ведем всю разработку в feature branches, и обычно в бранч коммитит только один разработчик.
Если я правильно понимаю, то вы тут говорите о ситуации, когда программист находится в branch и переключается обратно в trunk.
Ну так это не суть важно. Для subversion нет особой разницы между бранчами, тегами и транком — это всего лишь папки (связаные отношением наследования, но все равно лишь папки). Так что где-бы разработчик не работал, он просто переключается в/создает другой тег/бранч/транк и делает то, что у него попросили.
Единственным выходом будет искать ревизию, с которой этот проект работал, и копипастить библиотеки.
В svn:externals есть возможность указать конкретную ревизию. Да и ссылаться в svn:externals нужно на соответвующий релиз-тег библиотеки, а не на транк.
Стоит напомнить то, как ветки реализованы в svn. Это просто папки с полной копией репозитория. Начиная с версии 1.5 появилась история таких файлов, однако все же это просто папки и файлы. Для работы с ними нужно придерживаться специальных правил именования и содержания.
Какие правила вы тут имеете в виду?
Напоследок хочется сказать про историю коммитов. Если в svn она чисто прямолинейная и невозможно сказать, что вы на самом деле основывались на ревизии 2, а не 10 и понятия не имел о том, что происходит с 3 по 10, хотя ваш коммит следует под номером 11…
… то это видно при выполнении 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] указывает на вполне конкретное состояние транка).
к вам прибежали и срочно хотят получить билд (так как я занимаюсь мобильной разработкой, то такое бывает, хотя есть билдсервер). А у вас проект полностью разваленный, так как вы пилите какую-то супер фичу. В svn вам пришлось бы либо заново выкачивать все сорци с последней ревизии, либо пытаться откатить код до более-менее работающего состояния, либо сказать, что вы не можете этого сделать сейчас.
Либо вы берете одну из неиспользуемых рабочих копий (которые образовываются в результате «заново выкачивать все сорци с последней ревизии») и делает svn switch / svn up в ней.
ФЗ «О гражданстве Российской Федерации», глава III, ст.20, пункт «в»:
Выход из гражданства Российской Федерации не допускается, если гражданин Российской Федерации:
[...]
в) не имеет иного гражданства и гарантий его приобретения
Тут есть маленькое «но» — зачастую то, что называется vi, на самом деле является vim'ом с включенным режимом совместимости. Кроме того, еще во времена массового использования оригинального vi уже был emacs, который также снискал некоторую популярность. Так что 100% — сомнительная оценка.
Условия разрыва контракта обычно прописываются в самом контракте. Ну и автопролонгацию тоже никто не отменял.
В версии 1.1, если быть точным: svnbook.red-bean.com/en/1.1/ch07s04.html
Это лишь соглашение по именованию. Как вы сами правильно отметили, svn — это всего лишь папки и файлы, так что можно придумать и другую структуру.
Но бранч — это и есть обычная разработка :)
Впрочем, понятно, вы имели в виду мерджи в пределах одного бранча. Это довольно редкая для меня ситуация, поскольку мы ведем всю разработку в feature branches, и обычно в бранч коммитит только один разработчик.
Ну так это не суть важно. Для subversion нет особой разницы между бранчами, тегами и транком — это всего лишь папки (связаные отношением наследования, но все равно лишь папки). Так что где-бы разработчик не работал, он просто переключается в/создает другой тег/бранч/транк и делает то, что у него попросили.
В svn:externals есть возможность указать конкретную ревизию. Да и ссылаться в svn:externals нужно на соответвующий релиз-тег библиотеки, а не на транк.
Какие правила вы тут имеете в виду?
… то это видно при выполнении 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] указывает на вполне конкретное состояние транка).
Либо вы берете одну из неиспользуемых рабочих копий (которые образовываются в результате «заново выкачивать все сорци с последней ревизии») и делает svn switch / svn up в ней.
А можно поинтересоваться, на чем вы основываете это утверждение?