Mercurial, публичный и персональный репозитории., Как организовать рабочий процесс. Опции

[Sokoloff]

Всем привет.

Я работаю над проектом на двух машинах, на работе и дома. Часто бывает так, начал писать на одной, продолжил на другой. Соответственно надо просто и удобно синхронизировать код. Сейчас я делаю это с помощью приватного SVN сервера, перед уходом закомитил в него, на другой машине забрал.
Но теперь появляется публичный сервер проекта (mercurial), мне не хочется выкладывать там недоделанный код, только более-менее протестированный. Почитал я про DVCS, по идее, они позволяют организовать работу так:
Пишу код на работе, пора идти домой - я комичу данные в персональный репозиторий. Пришел домой, забрал изменения работаю дальше. Закончил определенную доработку, публикую код в публичном репозитории без истории изменений которые были на приватном сервере.

Кто работает с mercurial подскажите как такое сделать?

[Litkevich Yuriy]

публикую код в публичном репозитории без истории изменений которые были на приватном сервере.

держать клона публичного хранилища дома.
Как в личном хранилище нарисуется нормальный вариант, просто копировать файлы в рабочий каталог клона, фиксировать в нём изменения и отправлять на сервер.

[Sokoloff]

публикую код в публичном репозитории без истории изменений которые были на приватном сервере.

держать клона публичного хранилища дома.
Как в личном хранилище нарисуется нормальный вариант, просто копировать файлы в рабочий каталог клона, фиксировать в нём изменения и отправлять на сервер.

Это сработает с измененными файлами, для новые надо добавить под контроль, еще надо удалять удаленные (ух, как коряво звучит). Можно использовать rsync, и скрипт, но это как-то монструозно.
DVCS позволяют отправить изменения патчем, можно через это сделать, накатывать патч скриптом на копию публичного хранилища а потом отправлять. Но это все велосипедно. А более стандартных методов нет?

[Iron Bug]

"более стандартный" - это механизм ветвления. отделил ветку, поработал в ней, закоммитил в главную версию. стандартно именно для этой цели и придумано. но будет ли это работать с удалёнными хранилищами - я хз. и как удалённые репозитории сводят конфликты при объединении разных веток - я тоже не особо знаю. читай документацию по меркуриалу на эту тему.

[Litkevich Yuriy]

отделил ветку, поработал в ней, закоммитил в главную версию

меркуриал, как и гит, всю историю помнят, т.е. в публичном хранилище не будет в виде одной правки. Будут все промежуточные.

Sokoloff, яб не стал над этим мучатся. Есть правки и есть.

[Iron Bug]

меркуриал, как и гит, всю историю помнят, т.е. в публичном хранилище не будет в виде одной правки. Будут все промежуточные.

да и пускай себе будут. они же будут в отдельной ветке, а не в главном направлении, насколько я понимаю.

[Sokoloff]

меркуриал, как и гит, всю историю помнят, т.е. в публичном хранилище не будет в виде одной правки. Будут все промежуточные.

да и пускай себе будут. они же будут в отдельной ветке, а не в главном направлении, насколько я понимаю.

Можно конечно, это не критично, просто не хочется мусор из избы выносить.

Что-то я не пойму, в чем тогда преимущества распределенных систем. Все что предлагалось можно сделать и на SVN-е. Я думал, что распределенная система позволяет сделать распределенный процесс разработки. Ведь мою задачу можно и по другому представить. Есть несколько групп разработчиков, каждая занимается отдельным модулем проекта, возможно в разных городах или странах. У каждой группы свой рабочий репозиторий. Есть "выпускающие редакторы", которые переносят готовые доработки из рабочих реп в основной репозиторий. Схема уже не выглядит надуманной. Я думал что такое можно получить в DVCS "из коробки".

[Litkevich Yuriy]

а не в главном направлении, насколько я понимаю.

ну если ветку потом слить с основной (master/trunk), то они и там появятся

Я думал, что распределенная система позволяет сделать распределенный процесс разработки.

она именно это тебе и даёт, в SVN-не ты никаких правок в отсутствии доступа к единственному хранилищу не зафиксируешь.

П.С.
Если мне память не изменяет, то в "ртути" ветки - это просто новые хранилища, в отличие от гита. Мол концептуальный замысел такой.

Есть "выпускающие редакторы", которые переносят готовые доработки из рабочих реп в основной репозиторий.

ну и пусть себе переносят, посмотри как троли работают. Все (!) их правки в конце концов появляются в открытом хранилище.

[Sokoloff]

а не в главном направлении, насколько я понимаю.

ну если ветку потом слить с основной (master/trunk), то они и там появятся

Я думал, что распределенная система позволяет сделать распределенный процесс разработки.

она именно это тебе и даёт, в SVN-не ты никаких правок в отсутствии доступа к единственному хранилищу не зафиксируешь.

П.С.
Если мне память не изменяет, то в "ртути" ветки - это просто новые хранилища, в отличие от гита. Мол концептуальный замысел такой.

Я читал что это в базаре так, но может и здесь то-же. Я еще с hg не работал.

Есть "выпускающие редакторы", которые переносят готовые доработки из рабочих реп в основной репозиторий.

ну и пусть себе переносят, посмотри как троли работают. Все (!) их правки в конце концов появляются в открытом хранилище.

Т.е. проблема только в сокрытии промежуточных правок? Остальное можно сделать без проблем?

[Iron Bug]

она именно это тебе и даёт, в SVN-не ты никаких правок в отсутствии доступа к единственному хранилищу не зафиксируешь.

зафиксируешь. надо просто "перевести стрелки" с одного хранилища на другое. это делается одной командой relocate. переводишь с удалённого на локальное и правишь сколько влезет. потом - обратно переводишь и коммитишь. я это проделывала со своим переносным хранилищем: я не каждый раз с собой винт переносной на работу таскаю, я промежуточные копии иногда сохраняю локально. к тому же, есть экспорт-импорт и можно переносить отдельные части, выносить их в отдельные хранилища и много чего ещё.

Сообщение отредактировал Iron Bug - 29.1.2011, 0:23