Pull to refresh

Comments 56

Спасибо, давно хотел попробовать svn вместо vss и tfs, сравнить, что удобнее лично для меня.
попробуйте git или mercurial
Где взять скомпилированный GIT для Windows?
code.google.com/p/msysgit/

p.s. под win мне меркуриал чуть больше понравился, и черепаха(http://tortoisehg.sourceforge.net/) под него есть
Как по мне, с svn работать намного проще чем с git, скачивание отдельно выбранных ревизий, написание патчей, удобный клиент — TortoiseSVN. Но git предоставляет больше возможностей по управлению проекта в целом. Скорее всего на меня сказывается привычка работы с svn. Большой проблемой при попытки перехода на git было отсутствие нормального(с точки зрения svn'шика) нумерации изменений.
а мне git куда проще, точнее вначале было конечно тяжеловато врубиться и начать использовать его не в svn-стиле, но потом разобрался, если хотите разобраться, то вот book.git-scm.com
Спасибо, почитаю. Надеюсь узнаю много чего нового и интересного, и вернусь к идеи перехода на git. Просто тогда я не нашел(видимо плохо искал) инфу о гит'е, и пришлось все осваивать практически самому.
а мне кажется, что в tfs намного удобнее, мне так кажется :)
Вот мне и хочется попробовать разные и посравнивать. :)
Как говориться, лучше 1 раз увидеть.
UFO just landed and posted this here
данный момент у меня просто немного наболел. Хотелось поделиться быстрым и кратким решением.
ветвления это вообще отдельная история. Я вот копаюсь в архивах хабра — может уже есть на самом деле такая статья
«Правильный цикл работы с версиями в SVN» или «Правильный цикл работы с версиями в системе контроля версий».

Не кажется что тавтология какая-то. Я вот глазами пробежал и нифига не понял о чем пост. Я уж было подумал что тут методика описана как когда и почему делать или не делать ветви. Разные подходы там. Поместили бы подробное описание проблемы вначале хотя бы… примеры какие-нибудь…
Спасибо за статью. Думаю пригодиться в ближайшем будущем.
Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются невключительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
тьфу. мало того, что не дал предпросмотр сделать, так еще и продублировал. Так еще и криво отформатировал :)
Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются невключительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
У меня Reintegrate a branch зарабоатело после обновления свн сервера до 1.5 и последующего апгрейда репозитария с помощью команды svnadmin upgrade <имя репозитория>
Да использовать «Reintegrate a branch» в TortoiseSVN намного лучше, чем запоминать номера замердженных ревиизий в логе.

Недавно сами перешли на 1.5, стало намного удобней работать светками.
Мдя. Посмотришь на такое и сразу хочется волевым решением перевести все проекты на git.
С большими проектами git пока хуже справляется, чем svn. К тому же, merge tracking в svn уже есть.
А какже Linux с его 100 млн. строк кода? :)

Проблемы git больше со стилем работы — они в git и svn совместимы также, как стиль работы в svn и cvs. Я для себя определился: svn для централизованной разработки в конторе, в том числе, в стиле «кинул файл и забыл», а git — для сетевых FOSS-проектов, когда каждый модуль (репозитарий) — корректный законченный компонент с Makefile и прочими прелестями.
Да, я ошибся на порядок. :)
Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются не включительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
о млин… ссори, я не хотел :(
Странная претензия на правильностью Что тут правильного? Вы уверены в том что организация репозитария как у вас единственный правильный подход?
ну да. Лучше весь код хранить в trunk и мешать друг другу при разработке.
А по сути вашего вопроса — да, я уверен что существует не один подход к организации репозитария. Любой вопрос в сфере IT можно решить далеко не одним способом, а потом препираться и устраивать холивары на эту тему.

Я предложил, скажем так, один из распространённых методов организации, который описывается не в одном мануале. Просто я решил немного уделить внимания подводным камням, с которыми столкнулся я, с которыми столкнулись знакомые программисты. И видимо столкнутся и остальные, кто ещё о данной технике даже не задумался
Судя потому что Вы мне ответели, Вы мало читали документации на subversion, что тем более снижает компетентность Ваших слов.

ЗЫ. trunk'a может и не быть ;)
отличная статья
спасибо
Супер. Стиль изложения напорядок выше чем в статье на хабре.
Не совсем правильный цикл вообще-то. Не описана связь между branches и tags
Я бы не назвал описанный подход «правильным», я бы его назвал «простой пример». Если кто-то начнёт длительный или серьёзный проект подобным образом, он неизбежно наступит на грабли с бранчами и мержингом. Мы столкнулись и довольно болезненно разгребали.

Ещё я бы добавил аналогичные команды для оригинальной команды svn (для полноты картины), а также ссылку на Subversion book и на её перевод на русский.
Стиль автора напоминет стиль промта.
Ага, особенно вот этот кусок:
Создайте обособленно от всех ваших текущих рабочих копию ещё одну копию trunk
>В новом диалоговом окне [b]нужно нужно[/b] указать путь

Очень нужно!
Спасибо!
Некоторое время назад перешел с CVS на SVN — стало заметно удобней.
Но Branch'ами не пользовался, спасибо за подсказку!
кииииборги заполонили всю планету, кииборги, они :)
мне кажется, вся наработанная программерами куча должна лежать в trunk, а ветки, отходящие от него должны быть как раз стабильными версиями.
сделал у себя локально -> там же протестил -> выложил в транк -> там его проверили тестеры -> если все ок, то выкладываются в ветку со стабильной версией.

вроде как удобнее. нет?

а так вообще статья — много буков и картинок, да не по делу все, в основном.
Для стабильных версий обычно делают tags. А бранчи нужны для работы в рамках определенной задачи с последующим слиянием кода в trunk. Бранчи удобны в ситуации, когда нужно переключиться с разработки фичи А на разработку фичи Б: вы просто делаете switch с бранча А на бранч Б, а по окончанию работы с таском Б, вы можете вернуться к работе над А.

Если в очередной релиз будет решено отложить фичу А — вы просто не мержите код бранча А в trunk — и получаете релиз без фичи А. Т. е. trunk всегда содержит «стабильный» код, который, в идеале, в любой момент можно забрать из SVN, сбилдить и получить рабочую версию проекта.
спасибо, так действительно удобнее.
документация рассматривает два подхода: «стабильный транк» и «стабильный бранч»
какой использовать — вероятно, политика команды и компании
Есть разные подходы. Первый: «trunk — это куча, но стабильная, готовая, что бы в любой момент от неё можно было отфоркать релиз», второй — «куча-полуфабрикат для черри-пикинга в релизные ветки». В обоих подходах все нетривиальные фичи разрабатываются в фича-брэнчах.
давно пользуюсь SVN — отличнейшая весчь.
благодаря вашему посту таки решился и выделил время на подробное прочтение раздела официальной документации свн о бранчах :-)
Признаться, ожидал увидеть статью с объяснением основных понятий и описанием базовых принципов работы с ветками. А уже затем должны идти пошаговые инструкции с картинками. Это бы сильно повысило ценность материала.
Прочитав статью заметил один факт, который никак не укладывается у меня в мозгу, как у разработчика, почему надо работать с бранчами, а потом, прости Господи, мержится. Для многих — это, так сказать, ТРУ путь, но мержинг это штука очень противная и неприятная. С теми свн, с которыми я работал — дело происходило следующим образом, все работают исключительно с транком, в таком случае мерджинг происходит очень редко. Смоделирую ситуацию. Ты пишешь обширный модуль (30+ классов) который работает с низкоуровневыми модулями системы (которые постоянно обновляются, правятся и т. п). Естественно, что до завершения тестирования ты свое творение в транк не зальешь, а при заливке приходится мержить только общие (см. выше) файлы. А если вести разработку в своей ветви то придется мержить все. Итого что мы имеем:
1 — работа с бранчем = Мерж всех общих файлов и мерж своих (все 30+ файлов)
2 — работа с транком = Мерж только общих файлов (~ 5-7 файлов)

По времени 2 способ куда более безболезненный (это плюс). Но есть и минусы, первый и очевидный минус при работе только с транком — все твои изменения хранятся только локально, что есть не совсем гуд, если нет уверенности в железе. Для большинства это огромный минус. Но мне, наверное, очень повезло. Я работаю с макосью и любимая машина времени (Time Machine) постоянно (раз в 3 часа) бекапит _ВСЕ_ измененные файлы.

Выводы: Если есть система локального _тихого_ бекапа можно с чистой совестью работать с транком, если ее нет — добро пожаловать в бренчинг/мерджинг.
хотя, если посмотреть как можно обще — моя система это, вообщем, тот же бренчинг, но без ужасного мерджинга :)
Особенно наверное весело когда в создании «творения» принимают участие несколько разработчиков. В git с этим на порядок лучше
5+ разработчиков хватит?
Не совсем понял. Вы даже если работает с транком, не коммитите в него что ли?
У пользователя DevMan здесь на хабре было 3 статьи. На мой взгляд в них очень доходчиво и правильно было расписано как юзать бранчи причем безотносительно системы контроля версий. Серия называлась «Контроль версий при работе с несколькими командами». К сожалению автор почему-то переместил их в черновики. Найти можно через web.archive.org/. Правда будет без картинок =(
Вот прямые ссылки на 3 части:

habrahabr.ru/blogs/development_tools/87128/
habrahabr.ru/blogs/development_tools/87482/
habrahabr.ru/blogs/development_tools/87817/
Вот блин. как меня в такую старую тему занесло… Только сейчас заметил.
Sign up to leave a comment.

Articles