-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Работа с джуниором и проектрование ТЗ.
- Автор темы LONGMAN
- Дата начала
A1x
Новичок
svn является централизованной системой клиент-сервер, а mercurial - это децентрализованная система контроля версий (DVCS) - например, для нее нее не нужен центральный сервер
почитать можно начиная с http://ru.wikipedia.org/wiki/Mercurial и дальше по ссылкам
MildMildMint
Новичок
https://bitbucket.org/account/signin/?next=/plans
AmdY
Потому ты ими и не пользуешься, что они вносят дискомфорт. В меркуриале и гите, где ветви само собой разумеющиеся вещи и где их создание и поддержка очень дешевы - им сразу же находится применение. Подтверждено миллиардами перешедших с свна
Просто попробуй 
Глупость какая. То что она распределенная, не значит, что для нее не нужен центральный сервер. Не, ну технически можно и диффы почтой слать между разрабочиками, но на практике - это пустые слова: они все централизованы. Другое дело, что у них (DCVS) не обязательно коммитить все свои модификации сразу, имея возможность вести бранч, и слить его достаточно безболезненно с другими бранчами в мастер-бранч _независимо_ от порядка сливания бранчей.
я то понимаю что она значит в данном контексте. Меня просто всегда удивляет, когда доморощенные сторонники Гита/меркуриала/базаара это приводят основным (а часто и единственным) преимуществом то, что не существует на самом деле.
Хотя думаю, это проблема неправильного перевода - ведь они не децентрализованные, а распределенные (distributed) системы контроля версий. И как раз такое наименование снимает всякие непонимания.
Что не умаляет заслуг и качеств DVCS, на самом деле
-~{}~ 28.10.10 07:39:
Как написал какой-то из крутых Git-чуваков: «У нас все репозитории равноправны. Просто один репозиторий демократично выбирается равноправней других»
Farsh
~ on ~ high ~ wave ~
Добрый день)
Требуется небольшая помощь по работе в команде ( тема похожая, новую решил не создавать ).
И так, имеется:
a) рабочая машина
b) сервер
c) новый прогер
До сего момента я работал над внутренним проектом в одиночку:
SVN использовал только в качестве хранилища истории ( тупо в транке ) и синхронизации кода на свои разные рабочие машины;
часто тестировал приложения прямо на серваке ( то есть написал код -> через rsync вгрузил -> проверил; раньше делал дампы на локальную БД, но сейчас они по размерам стали огромные, что постепенно практически заставило отказаться от "локального lamp" )
Соответственно прошу советов, как это должно делаться "правильно" ?
Вот сейчас появился второй прогер, которому также нужны реальные данные с сервака.
Что делать ? Как вообще организовать работу ? Открыть внешний доступ к БД ( ну или через ссх туннель ) ?
Или может поставить вторую БД на тот же сервак и использовать ее как тестовую, на которую будет идти синхронизация с основной БД ?
Вообще, какие есть best practice's ?
Спасибо.
Требуется небольшая помощь по работе в команде ( тема похожая, новую решил не создавать ).
И так, имеется:
a) рабочая машина
b) сервер
c) новый прогер
До сего момента я работал над внутренним проектом в одиночку:
SVN использовал только в качестве хранилища истории ( тупо в транке ) и синхронизации кода на свои разные рабочие машины;
часто тестировал приложения прямо на серваке ( то есть написал код -> через rsync вгрузил -> проверил; раньше делал дампы на локальную БД, но сейчас они по размерам стали огромные, что постепенно практически заставило отказаться от "локального lamp" )
Соответственно прошу советов, как это должно делаться "правильно" ?
Вот сейчас появился второй прогер, которому также нужны реальные данные с сервака.
Что делать ? Как вообще организовать работу ? Открыть внешний доступ к БД ( ну или через ссх туннель ) ?
Или может поставить вторую БД на тот же сервак и использовать ее как тестовую, на которую будет идти синхронизация с основной БД ?
Вообще, какие есть best practice's ?
Спасибо.
Farsh
~ on ~ high ~ wave ~
>> не вижу тут особых проблем
Я просто хотел узнать, как это вообще делают люди, работающие в команде, ибо у меня в этом абсолютно нулевый опыт
>> сделай ему свой бренч, пусть туда коммитит, елс что в транк переносите потом
А зачем ? После какого момента нужно делать перенос в транк ?
А почему нельзя тупо всем использовать только транк ? Раз, нашел багу, сразу пофиксил. Я сделал апдейт из svn и деплой на сервер.
>> доступ к БД лучше сделать 1 пользователя(унифицированно), чтобы все работали с БД с одного юзера
То есть БД должна быть всего одна ( та, что на сервере ) и она же будет использоваться как тестовая всеми прогерами ?
А в чем преимущество сделать 1 пользователя ( root? ) ?
Я просто хотел узнать, как это вообще делают люди, работающие в команде, ибо у меня в этом абсолютно нулевый опыт
>> сделай ему свой бренч, пусть туда коммитит, елс что в транк переносите потом
А зачем ? После какого момента нужно делать перенос в транк ?
А почему нельзя тупо всем использовать только транк ? Раз, нашел багу, сразу пофиксил. Я сделал апдейт из svn и деплой на сервер.
>> доступ к БД лучше сделать 1 пользователя(унифицированно), чтобы все работали с БД с одного юзера
То есть БД должна быть всего одна ( та, что на сервере ) и она же будет использоваться как тестовая всеми прогерами ?
А в чем преимущество сделать 1 пользователя ( root? ) ?
Ragazzo
TDD interested
Farsh
Насчет транка: Транк это стабильная безбажная версия(теоритически), если каждый сразу же будет в него коммитить будет неразбириха, что-то доказывать если ты не понимаешь зачем надо так, не вижу смысла, комитьте в транк, когда наткнешься на грабли - поймешь..10 программистов коммитящих сразу же в транк, создадут нехилую головную боль...В транк надо переносить ту часть, которая в бренче стабильно работает и без багов...
Насчет БД: преимущество в том что не будет проблем с привелегиями и прочей фигней, в разработке все должно быть четко и по стандартам, конечно если не доверяешь программисту второму можешь его посадить только за SELECT...
Насчет транка: Транк это стабильная безбажная версия(теоритически), если каждый сразу же будет в него коммитить будет неразбириха, что-то доказывать если ты не понимаешь зачем надо так, не вижу смысла, комитьте в транк, когда наткнешься на грабли - поймешь..10 программистов коммитящих сразу же в транк, создадут нехилую головную боль...В транк надо переносить ту часть, которая в бренче стабильно работает и без багов...
Насчет БД: преимущество в том что не будет проблем с привелегиями и прочей фигней, в разработке все должно быть четко и по стандартам, конечно если не доверяешь программисту второму можешь его посадить только за SELECT...