я не верю в «участочек работы» в рамках большого проекта, в отрыве от всего проекта.
Это любо два разных проекта, либо один.
У нас в репозитарии 4 экстернела, 2 из них реально отдельные проекты, и они лежать отдельно. И от их иногда «неудачных» обновлений страдают лишь они сами. И поэтому у них отдельные репозитарии.
2 других фактически часть нашего проекта, которую вынесли для разработки «ВНЕ» (участочки работы, блин), и это два нам постоянно все ломают. И если бы разработчики этих двух проектов, работали со всей системой «в целом» такого бы не было.
1) каждый проект — свой репозитарий
так что приходится выкидывать в суб-модули
про теги в суб-модуле, не знаю не юзал
2) никак, т.к. идеология git — работать со всем проектом, а не с файлами/директориями
и проект ведется соответственно этой идеологии, что учит нас разрабатывать не кусочки, а законченные решения.
и тогда SVN будет для Вас как еще один удаленый репозитарий.
Я сам так колебался, потом попробовал Hg, потом Git. Сейчас Git меня вполне устраивает. Хотя основной транк находится в SVN, для меня это просто еще одна ветка в Git.
зависит от того что тебе нужно.
если ты просто привык коммитить уже сделанные вещи, и ты успеваешь сделать итерацию за день то ничем.
я использую иначе:
— каждая фича — свой бранч
— каждое законченное изменение (функция, шаблон, правило) — коммит (в среднем я комичу раз в 10 минут)
— в работе 5-10 фичей одновременно, причем я могу переключится с одной на другую за пару секунд
— в транк попадают только законченые и протестированые фичи (тестирование и транк на др. хостах), тут отлично применяется распределенность
причем GIT сам навязывает такой стиль разработки
можно ли все это также просто и легко сделать в SVN???
а если в проекте 5-10 человек?
ЗЫ
ну и специально для тебя, в TM есть отличный GIT.bundle, благодаря которому можно не вникать в устройство GIT'а, а просто его использовать :)
спасибо, большое за статью.
мне идея samlowry понравилась, но в друго ракурсе. Было бы хорошо если известные подкастеры рассказали о своих микрофонах/усилителях/софте, и тогда мы бы поняли как эти связки работают в действительности.
А ты бы выступал в роли непревзойденного эксперта (комментарии бы отвешивал :)
я рассказывал, и сам же сказал что делать этого не стоит (если ты не делаешь админку под себя или интранет) и объяснил почему.
а вопрос этот обсуждается и сейчас, а толковой информации как небыло так и нет.
а какие из них лишние?
что сделать надо?
а. убрать все span (тривиально)
b. слепить все span stylе в один тег span, где style будет из все спанов.
c. убрать конкретный span
Это любо два разных проекта, либо один.
У нас в репозитарии 4 экстернела, 2 из них реально отдельные проекты, и они лежать отдельно. И от их иногда «неудачных» обновлений страдают лишь они сами. И поэтому у них отдельные репозитарии.
2 других фактически часть нашего проекта, которую вынесли для разработки «ВНЕ» (участочки работы, блин), и это два нам постоянно все ломают. И если бы разработчики этих двух проектов, работали со всей системой «в целом» такого бы не было.
ветки которые мне нужны есть в git c префиксом svn_
и я их полноценно мержу с всеми остальными (в которых работаю)
автоматизации нету (меня это сейчас мало смущает т.к. в один SVN коммит отправляется 2-3 фичи/ветки из GIT, и я понимаю что они делают)
именно для такой автоматизации создан svn-git, сейчас я бы стал его использовать.
Возможно и переду в ближайшее время.
а расход на использование веток, это то что ветки приходся тянуть с сервера каждый раз
1) каждый проект — свой репозитарий
так что приходится выкидывать в суб-модули
про теги в суб-модуле, не знаю не юзал
2) никак, т.к. идеология git — работать со всем проектом, а не с файлами/директориями
и проект ведется соответственно этой идеологии, что учит нас разрабатывать не кусочки, а законченные решения.
сейчас использую одну ветку git как транк SVN куда подливаю все изменения.
когда надо закомитить в svn я просто грепаю лог git'а
и пишу что надо в комментарии к комиту
причем не обязательно отказываться от SVN есть www.kernel.org/pub/software/scm/git/docs/git-svn.html
и тогда SVN будет для Вас как еще один удаленый репозитарий.
Я сам так колебался, потом попробовал Hg, потом Git. Сейчас Git меня вполне устраивает. Хотя основной транк находится в SVN, для меня это просто еще одна ветка в Git.
А как Вы работаете с SVN
— сколько коммитов Вы делаете в день?
— сколько бранчей обычно в репозитарии?
— сколько разработчиков в проекте?
если ответы на все эти вопросы < 5, то SVN вам вроде должно хватать.
а если нет, то готов рассказать что станет в Вашей жизни лучше если Вы перейдете на Git
если ты просто привык коммитить уже сделанные вещи, и ты успеваешь сделать итерацию за день то ничем.
я использую иначе:
— каждая фича — свой бранч
— каждое законченное изменение (функция, шаблон, правило) — коммит (в среднем я комичу раз в 10 минут)
— в работе 5-10 фичей одновременно, причем я могу переключится с одной на другую за пару секунд
— в транк попадают только законченые и протестированые фичи (тестирование и транк на др. хостах), тут отлично применяется распределенность
причем GIT сам навязывает такой стиль разработки
можно ли все это также просто и легко сделать в SVN???
а если в проекте 5-10 человек?
ЗЫ
ну и специально для тебя, в TM есть отличный GIT.bundle, благодаря которому можно не вникать в устройство GIT'а, а просто его использовать :)
git.or.cz/gitwiki/GitSvnComparsion
markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/
как применять правда пока не понятно… может в блогах?
мне идея samlowry понравилась, но в друго ракурсе. Было бы хорошо если известные подкастеры рассказали о своих микрофонах/усилителях/софте, и тогда мы бы поняли как эти связки работают в действительности.
А ты бы выступал в роли непревзойденного эксперта (комментарии бы отвешивал :)
как хоть назывался? и кто читал? а то Кудинова я в докладчиках не нашел. или это было в 2007?
а вопрос этот обсуждается и сейчас, а толковой информации как небыло так и нет.
я прав?
что сделать надо?
а. убрать все span (тривиально)
b. слепить все span stylе в один тег span, где style будет из все спанов.
c. убрать конкретный span