Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Mercurial, публичный и персональный репозитории.
Форум на CrossPlatform.RU > Разработка > Инструменты разработчика
Sokoloff
Всем привет.

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

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


Litkevich Yuriy
Цитата(Sokoloff @ 26.1.2011, 21:27) *
публикую код в публичном репозитории без истории изменений которые были на приватном сервере.
держать клона публичного хранилища дома.
Как в личном хранилище нарисуется нормальный вариант, просто копировать файлы в рабочий каталог клона, фиксировать в нём изменения и отправлять на сервер.
Sokoloff
Цитата(Litkevich Yuriy @ 26.1.2011, 19:53) *
Цитата(Sokoloff @ 26.1.2011, 21:27) *
публикую код в публичном репозитории без истории изменений которые были на приватном сервере.
держать клона публичного хранилища дома.
Как в личном хранилище нарисуется нормальный вариант, просто копировать файлы в рабочий каталог клона, фиксировать в нём изменения и отправлять на сервер.

Это сработает с измененными файлами, для новые надо добавить под контроль, еще надо удалять удаленные (ух, как коряво звучит). Можно использовать rsync, и скрипт, но это как-то монструозно.
DVCS позволяют отправить изменения патчем, можно через это сделать, накатывать патч скриптом на копию публичного хранилища а потом отправлять. Но это все велосипедно. А более стандартных методов нет?
Iron Bug
"более стандартный" - это механизм ветвления. отделил ветку, поработал в ней, закоммитил в главную версию. стандартно именно для этой цели и придумано. но будет ли это работать с удалёнными хранилищами - я хз. и как удалённые репозитории сводят конфликты при объединении разных веток - я тоже не особо знаю. читай документацию по меркуриалу на эту тему.
Litkevich Yuriy
Цитата(Iron Bug @ 26.1.2011, 23:47) *
отделил ветку, поработал в ней, закоммитил в главную версию
меркуриал, как и гит, всю историю помнят, т.е. в публичном хранилище не будет в виде одной правки. Будут все промежуточные.

Sokoloff, яб не стал над этим мучатся. Есть правки и есть.
Iron Bug
Цитата(Litkevich Yuriy @ 27.1.2011, 23:01) *
меркуриал, как и гит, всю историю помнят, т.е. в публичном хранилище не будет в виде одной правки. Будут все промежуточные.

да и пускай себе будут. они же будут в отдельной ветке, а не в главном направлении, насколько я понимаю.
Sokoloff
Цитата(Iron Bug @ 28.1.2011, 8:05) *
Цитата(Litkevich Yuriy @ 27.1.2011, 23:01) *
меркуриал, как и гит, всю историю помнят, т.е. в публичном хранилище не будет в виде одной правки. Будут все промежуточные.

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


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

Что-то я не пойму, в чем тогда преимущества распределенных систем. Все что предлагалось можно сделать и на SVN-е. Я думал, что распределенная система позволяет сделать распределенный процесс разработки. Ведь мою задачу можно и по другому представить. Есть несколько групп разработчиков, каждая занимается отдельным модулем проекта, возможно в разных городах или странах. У каждой группы свой рабочий репозиторий. Есть "выпускающие редакторы", которые переносят готовые доработки из рабочих реп в основной репозиторий. Схема уже не выглядит надуманной. Я думал что такое можно получить в DVCS "из коробки".
Litkevich Yuriy
Цитата(Iron Bug @ 28.1.2011, 10:05) *
а не в главном направлении, насколько я понимаю.
ну если ветку потом слить с основной (master/trunk), то они и там появятся

Цитата(Sokoloff @ 28.1.2011, 21:37) *
Я думал, что распределенная система позволяет сделать распределенный процесс разработки.
она именно это тебе и даёт, в SVN-не ты никаких правок в отсутствии доступа к единственному хранилищу не зафиксируешь.

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

Цитата(Sokoloff @ 28.1.2011, 21:37) *
Есть "выпускающие редакторы", которые переносят готовые доработки из рабочих реп в основной репозиторий.
ну и пусть себе переносят, посмотри как троли работают. Все (!) их правки в конце концов появляются в открытом хранилище.
Sokoloff
Цитата(Litkevich Yuriy @ 28.1.2011, 21:24) *
Цитата(Iron Bug @ 28.1.2011, 10:05) *
а не в главном направлении, насколько я понимаю.
ну если ветку потом слить с основной (master/trunk), то они и там появятся

Цитата(Sokoloff @ 28.1.2011, 21:37) *
Я думал, что распределенная система позволяет сделать распределенный процесс разработки.
она именно это тебе и даёт, в SVN-не ты никаких правок в отсутствии доступа к единственному хранилищу не зафиксируешь.

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

Я читал что это в базаре так, но может и здесь то-же. Я еще с hg не работал.
Цитата(Litkevich Yuriy @ 28.1.2011, 21:24) *
Цитата(Sokoloff @ 28.1.2011, 21:37) *
Есть "выпускающие редакторы", которые переносят готовые доработки из рабочих реп в основной репозиторий.
ну и пусть себе переносят, посмотри как троли работают. Все (!) их правки в конце концов появляются в открытом хранилище.

Т.е. проблема только в сокрытии промежуточных правок? Остальное можно сделать без проблем?
Iron Bug
Цитата(Litkevich Yuriy @ 28.1.2011, 23:24) *
она именно это тебе и даёт, в SVN-не ты никаких правок в отсутствии доступа к единственному хранилищу не зафиксируешь.

зафиксируешь. надо просто "перевести стрелки" с одного хранилища на другое. это делается одной командой relocate. переводишь с удалённого на локальное и правишь сколько влезет. потом - обратно переводишь и коммитишь. я это проделывала со своим переносным хранилищем: я не каждый раз с собой винт переносной на работу таскаю, я промежуточные копии иногда сохраняю локально. к тому же, есть экспорт-импорт и можно переносить отдельные части, выносить их в отдельные хранилища и много чего ещё.
Sokoloff
Цитата(Iron Bug @ 29.1.2011, 0:19) *
Цитата(Litkevich Yuriy @ 28.1.2011, 23:24) *
она именно это тебе и даёт, в SVN-не ты никаких правок в отсутствии доступа к единственному хранилищу не зафиксируешь.

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

Опа, а это интересно. Я думал switch --relocate используется когда меняется адрес сервера. А такое использование мне и в голову не приходило. Можно поподробнее.
А как будут идти ревизии? Вот скажем в главном хранилище была ревизия №10. Перевели на локальное, какая ревизия в нем появится 10-я? Или у локального идет своя нумерация.

Дальше в локальном я зафиксировал 5 комитов, переключаю на удаленное, комичу туда, там добавится одна ревизия или 5?
Если 5, то как разруливать ситуацию если кто-то уже делал комиты в удаленное хранилище? Ведь может так получиться 1-го числа я сделал комит в локальное, 2-го кто-то в удаленное, а 3-го я комичу в удаленное. что покажет история на 2-е число?

P.S.
После этого треда меня терзают смутные сомнения, нужно мне изучать меркуриал, или использовать старый добрый SVN.
Litkevich Yuriy
Цитата(Sokoloff @ 30.1.2011, 4:35) *
Опа, а это интересно.
мне тоже. Два хранилища - два разных идентификатора хранилища, переключение не возможно.

вообще переключение (switch) в свине предназначен для переключения веток в рабочей копии. Либо перебазированиии адреса хранилища (когда хранилище просто взяли и переместили с места на место).

Если же сделать копию хранилища и просто поработать с ней, сделать несколько правок. то в исходное хранилище потом ничего не залить из рабочей копии. Т.к. версия рабочей копии будет иметь имя (номер) превышающий версию хранилища.

П.С.
гит, базар и ртуть придумали из-за невозможности в свине работать распределённо.

Цитата(Sokoloff @ 30.1.2011, 4:35) *
После этого треда меня терзают смутные сомнения, нужно мне изучать меркуриал
бери гит, уже много всяких проектов на нём живёт.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.