Comments 56
Спасибо, давно хотел попробовать svn вместо vss и tfs, сравнить, что удобнее лично для меня.
0
попробуйте git или mercurial
+9
Где взять скомпилированный GIT для Windows?
0
code.google.com/p/msysgit/
p.s. под win мне меркуриал чуть больше понравился, и черепаха(http://tortoisehg.sourceforge.net/) под него есть
p.s. под win мне меркуриал чуть больше понравился, и черепаха(http://tortoisehg.sourceforge.net/) под него есть
+3
Как по мне, с svn работать намного проще чем с git, скачивание отдельно выбранных ревизий, написание патчей, удобный клиент — TortoiseSVN. Но git предоставляет больше возможностей по управлению проекта в целом. Скорее всего на меня сказывается привычка работы с svn. Большой проблемой при попытки перехода на git было отсутствие нормального(с точки зрения svn'шика) нумерации изменений.
0
а мне git куда проще, точнее вначале было конечно тяжеловато врубиться и начать использовать его не в svn-стиле, но потом разобрался, если хотите разобраться, то вот book.git-scm.com
0
а мне кажется, что в tfs намного удобнее, мне так кажется :)
0
UFO just landed and posted this here
«Правильный цикл работы с версиями в SVN» или «Правильный цикл работы с версиями в системе контроля версий».
Не кажется что тавтология какая-то. Я вот глазами пробежал и нифига не понял о чем пост. Я уж было подумал что тут методика описана как когда и почему делать или не делать ветви. Разные подходы там. Поместили бы подробное описание проблемы вначале хотя бы… примеры какие-нибудь…
Не кажется что тавтология какая-то. Я вот глазами пробежал и нифига не понял о чем пост. Я уж было подумал что тут методика описана как когда и почему делать или не делать ветви. Разные подходы там. Поместили бы подробное описание проблемы вначале хотя бы… примеры какие-нибудь…
+12
Спасибо за статью. Думаю пригодиться в ближайшем будущем.
0
Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются невключительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
0
Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются невключительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
0
У меня Reintegrate a branch зарабоатело после обновления свн сервера до 1.5 и последующего апгрейда репозитария с помощью команды svnadmin upgrade <имя репозитория>
+1
Мдя. Посмотришь на такое и сразу хочется волевым решением перевести все проекты на git.
0
С большими проектами git пока хуже справляется, чем svn. К тому же, merge tracking в svn уже есть.
0
А какже Linux с его 100 млн. строк кода? :)
Проблемы git больше со стилем работы — они в git и svn совместимы также, как стиль работы в svn и cvs. Я для себя определился: svn для централизованной разработки в конторе, в том числе, в стиле «кинул файл и забыл», а git — для сетевых FOSS-проектов, когда каждый модуль (репозитарий) — корректный законченный компонент с Makefile и прочими прелестями.
Проблемы git больше со стилем работы — они в git и svn совместимы также, как стиль работы в svn и cvs. Я для себя определился: svn для централизованной разработки в конторе, в том числе, в стиле «кинул файл и забыл», а git — для сетевых FOSS-проектов, когда каждый модуль (репозитарий) — корректный законченный компонент с Makefile и прочими прелестями.
0
100 млн. строк кода в ядре?? Тут более точная оценка: linux.slashdot.org/article.pl?sid=08/10/22/1713241
А вообще да, я имел в виду монолитные большие проекты внутри одной конторы.
А вообще да, я имел в виду монолитные большие проекты внутри одной конторы.
0
Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются не включительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
+1
Странная претензия на правильностью Что тут правильного? Вы уверены в том что организация репозитария как у вас единственный правильный подход?
+3
ну да. Лучше весь код хранить в trunk и мешать друг другу при разработке.
А по сути вашего вопроса — да, я уверен что существует не один подход к организации репозитария. Любой вопрос в сфере IT можно решить далеко не одним способом, а потом препираться и устраивать холивары на эту тему.
Я предложил, скажем так, один из распространённых методов организации, который описывается не в одном мануале. Просто я решил немного уделить внимания подводным камням, с которыми столкнулся я, с которыми столкнулись знакомые программисты. И видимо столкнутся и остальные, кто ещё о данной технике даже не задумался
А по сути вашего вопроса — да, я уверен что существует не один подход к организации репозитария. Любой вопрос в сфере IT можно решить далеко не одним способом, а потом препираться и устраивать холивары на эту тему.
Я предложил, скажем так, один из распространённых методов организации, который описывается не в одном мануале. Просто я решил немного уделить внимания подводным камням, с которыми столкнулся я, с которыми столкнулись знакомые программисты. И видимо столкнутся и остальные, кто ещё о данной технике даже не задумался
0
Имхо, цикл неполон. Более подробное изложение, если угодно.
+3
Не совсем правильный цикл вообще-то. Не описана связь между branches и tags
0
Я бы не назвал описанный подход «правильным», я бы его назвал «простой пример». Если кто-то начнёт длительный или серьёзный проект подобным образом, он неизбежно наступит на грабли с бранчами и мержингом. Мы столкнулись и довольно болезненно разгребали.
Ещё я бы добавил аналогичные команды для оригинальной команды svn (для полноты картины), а также ссылку на Subversion book и на её перевод на русский.
Ещё я бы добавил аналогичные команды для оригинальной команды svn (для полноты картины), а также ссылку на Subversion book и на её перевод на русский.
+1
Стиль автора напоминет стиль промта.
+5
>В новом диалоговом окне [b]нужно нужно[/b] указать путь
Очень нужно!
Очень нужно!
0
Спасибо!
Некоторое время назад перешел с CVS на SVN — стало заметно удобней.
Но Branch'ами не пользовался, спасибо за подсказку!
Некоторое время назад перешел с CVS на SVN — стало заметно удобней.
Но Branch'ами не пользовался, спасибо за подсказку!
+1
Тема не раскрыта.
+2
мне кажется, вся наработанная программерами куча должна лежать в trunk, а ветки, отходящие от него должны быть как раз стабильными версиями.
сделал у себя локально -> там же протестил -> выложил в транк -> там его проверили тестеры -> если все ок, то выкладываются в ветку со стабильной версией.
вроде как удобнее. нет?
а так вообще статья — много буков и картинок, да не по делу все, в основном.
сделал у себя локально -> там же протестил -> выложил в транк -> там его проверили тестеры -> если все ок, то выкладываются в ветку со стабильной версией.
вроде как удобнее. нет?
а так вообще статья — много буков и картинок, да не по делу все, в основном.
-1
Для стабильных версий обычно делают tags. А бранчи нужны для работы в рамках определенной задачи с последующим слиянием кода в trunk. Бранчи удобны в ситуации, когда нужно переключиться с разработки фичи А на разработку фичи Б: вы просто делаете switch с бранча А на бранч Б, а по окончанию работы с таском Б, вы можете вернуться к работе над А.
Если в очередной релиз будет решено отложить фичу А — вы просто не мержите код бранча А в trunk — и получаете релиз без фичи А. Т. е. trunk всегда содержит «стабильный» код, который, в идеале, в любой момент можно забрать из SVN, сбилдить и получить рабочую версию проекта.
Если в очередной релиз будет решено отложить фичу А — вы просто не мержите код бранча А в trunk — и получаете релиз без фичи А. Т. е. trunk всегда содержит «стабильный» код, который, в идеале, в любой момент можно забрать из SVN, сбилдить и получить рабочую версию проекта.
+3
Есть разные подходы. Первый: «trunk — это куча, но стабильная, готовая, что бы в любой момент от неё можно было отфоркать релиз», второй — «куча-полуфабрикат для черри-пикинга в релизные ветки». В обоих подходах все нетривиальные фичи разрабатываются в фича-брэнчах.
0
давно пользуюсь SVN — отличнейшая весчь.
+1
благодаря вашему посту таки решился и выделил время на подробное прочтение раздела официальной документации свн о бранчах :-)
0
Признаться, ожидал увидеть статью с объяснением основных понятий и описанием базовых принципов работы с ветками. А уже затем должны идти пошаговые инструкции с картинками. Это бы сильно повысило ценность материала.
0
Прочитав статью заметил один факт, который никак не укладывается у меня в мозгу, как у разработчика, почему надо работать с бранчами, а потом, прости Господи, мержится. Для многих — это, так сказать, ТРУ путь, но мержинг это штука очень противная и неприятная. С теми свн, с которыми я работал — дело происходило следующим образом, все работают исключительно с транком, в таком случае мерджинг происходит очень редко. Смоделирую ситуацию. Ты пишешь обширный модуль (30+ классов) который работает с низкоуровневыми модулями системы (которые постоянно обновляются, правятся и т. п). Естественно, что до завершения тестирования ты свое творение в транк не зальешь, а при заливке приходится мержить только общие (см. выше) файлы. А если вести разработку в своей ветви то придется мержить все. Итого что мы имеем:
1 — работа с бранчем = Мерж всех общих файлов и мерж своих (все 30+ файлов)
2 — работа с транком = Мерж только общих файлов (~ 5-7 файлов)
По времени 2 способ куда более безболезненный (это плюс). Но есть и минусы, первый и очевидный минус при работе только с транком — все твои изменения хранятся только локально, что есть не совсем гуд, если нет уверенности в железе. Для большинства это огромный минус. Но мне, наверное, очень повезло. Я работаю с макосью и любимая машина времени (Time Machine) постоянно (раз в 3 часа) бекапит _ВСЕ_ измененные файлы.
Выводы: Если есть система локального _тихого_ бекапа можно с чистой совестью работать с транком, если ее нет — добро пожаловать в бренчинг/мерджинг.
1 — работа с бранчем = Мерж всех общих файлов и мерж своих (все 30+ файлов)
2 — работа с транком = Мерж только общих файлов (~ 5-7 файлов)
По времени 2 способ куда более безболезненный (это плюс). Но есть и минусы, первый и очевидный минус при работе только с транком — все твои изменения хранятся только локально, что есть не совсем гуд, если нет уверенности в железе. Для большинства это огромный минус. Но мне, наверное, очень повезло. Я работаю с макосью и любимая машина времени (Time Machine) постоянно (раз в 3 часа) бекапит _ВСЕ_ измененные файлы.
Выводы: Если есть система локального _тихого_ бекапа можно с чистой совестью работать с транком, если ее нет — добро пожаловать в бренчинг/мерджинг.
0
хотя, если посмотреть как можно обще — моя система это, вообщем, тот же бренчинг, но без ужасного мерджинга :)
0
Особенно наверное весело когда в создании «творения» принимают участие несколько разработчиков. В git с этим на порядок лучше
0
Не совсем понял. Вы даже если работает с транком, не коммитите в него что ли?
0
У пользователя DevMan здесь на хабре было 3 статьи. На мой взгляд в них очень доходчиво и правильно было расписано как юзать бранчи причем безотносительно системы контроля версий. Серия называлась «Контроль версий при работе с несколькими командами». К сожалению автор почему-то переместил их в черновики. Найти можно через web.archive.org/. Правда будет без картинок =(
Вот прямые ссылки на 3 части:
habrahabr.ru/blogs/development_tools/87128/
habrahabr.ru/blogs/development_tools/87482/
habrahabr.ru/blogs/development_tools/87817/
Вот прямые ссылки на 3 части:
habrahabr.ru/blogs/development_tools/87128/
habrahabr.ru/blogs/development_tools/87482/
habrahabr.ru/blogs/development_tools/87817/
0
Вот блин. как меня в такую старую тему занесло… Только сейчас заметил.
0
Sign up to leave a comment.
Правильный цикл работы с версиями SVN