Есть ли аналог Checklist'а в Subversion?

  • Автор темы user1251
  • Дата начала
U

user1251

#1
В системе контроля версий Perforce, есть такое понятие как Changelist. Если пользователю необходимо отредактировать какие-нибудь файлы, он должен создать changelist (или воспользоваться уже созданным) и с помощью клиента (например, P4), поместить в этот changelist файлы для редактирования. Changelist’ы удобны тем, что позволяют логически группировать информацию и закладывать ее на сервер по этим группам.

Начав работать с Subversion, такой возможности я не нашел. То есть, я делаю изменения в файлах, а потом закладываю все сразу, или частично (постоянно проставляю нужные мне галочки напротив файлов).
Хотелось бы узнать, существует ли аналог changelist’а в subversion? Возможно, существуют какие-то клиенты, которые позволяют это делать. Сейчас я использую SmartSVN.
 
E
#2
А в чем прелесть его? если просто какойто аморфный список файлов, так по моему это только доп. телодвижения, или я не прав?

ваще я не в курсе есть ли чтото какое в Subversion ...
 
U

user1251

#3
А в чем прелесть его? если просто какойто аморфный список файлов, так по моему это только доп. телодвижения, или я не прав?

ваще я не в курсе есть ли чтото какое в Subversion ...
Прелесть в том, что если я в течение дня делал изменения в разных местах проекта, то при закладывании измененных файлов на сервер, я буду закладывать их не “скопом”, а в логически сгруппированных changelist’ах.
Мне не кажется правильным когда, например, человек изменил подсистему доступа к данным, графическую подсистему и добавил в вордовский файл пару фраз, при commit’e всего это добра, пишет долгий и нудный текст, где и чего он изменил. Более правильным было бы группирование измененных файлов по changelist’ам, при commit’e каждого из которых было бы написано, какие изменения были внесены.
 
E
#4
А ... понятно, не мы не пишем описалово при комите, наверное неправильно, но както не сложилось. Да и както незнаю нафик оно надо, может поясните?
а то если для документации, то это мне кажется не то место, а для чего еще?
 
U

user1251

#5
А ... понятно, не мы не пишем описалово при комите, наверное неправильно, но както не сложилось. Да и както незнаю нафик оно надо, может поясните?
а то если для документации, то это мне кажется не то место, а для чего еще?
Это необходимо, когда обнаруживается какая-нибудь ошибка, которая раньше не появлялась. При сравнении ревизий файлов разных классов, просматриваются примечания, которые были написаны человеком заложившим файл. Чтобы можно было быстро понять, для чего человек внес такие изменения.
А с помощью тех же changelist’ов, можно понять, какие изменения логически связаны с другими измененными файлами. А без них, в худшем случае, придется «прочесывать» все изменные при commit’е файлы с исходным кодом.
 
E
#6
Ага, ну вроде смысл и я вижу, сенкью, как найдете такую возможность и мне скажите, попробую. :)
 

Kmet

Java Team
25.05.2006
1 036
8
#7
нету, похожий функционал реализуется через бранчи.

Мне не кажется правильным когда, например, человек изменил подсистему доступа к данным, графическую подсистему и добавил в вордовский файл пару фраз, при commit’e всего это добра, пишет долгий и нудный текст, где и чего он изменил. Более правильным было бы группирование измененных файлов по changelist’ам, при commit’e каждого из которых было бы написано, какие изменения были внесены.
а не надо так делать. есть большой рекваймент, сделали для него отдельный бранч. в рамках этого рекваймент изменил подсистему доступа к данным (коммит), графическую подсистему(коммит) и тд. В конце смержили все с транком.
 
U

user1251

#8
нету, похожий функционал реализуется через бранчи.


а не надо так делать. есть большой рекваймент, сделали для него отдельный бранч. в рамках этого рекваймент изменил подсистему доступа к данным (коммит), графическую подсистему(коммит) и тд. В конце смержили все с транком.
Спасибо! Видимо придется мучиться с проставлением нужных галочек при commit’e.
Я обычно делаю бранчи, когда хочу делать серьезные изменения. А когда нужно поправить одну функцию или еще какую-нибудь мелочь, думаю, создавать бранч не стоит.
 

Kmet

Java Team
25.05.2006
1 036
8
#9
А когда нужно поправить одну функцию или еще какую-нибудь мелочь, думаю, создавать бранч не стоит.
поправили - закомитили, еще что поправили закомитили... :) нужно обособить несколько изменений сделали бранч, бранчи в свн дешевые.
можно еще посмотреть на mercurial или git.