Вы управление версиями invidual приложения или целый проект или оба?
Клиент всегда пытается подключиться. Вам не нужно беспокоиться об этом. Есть переподключенное событие, которое вы можете прослушать, если хотите что-то сделать, когда соединение успешно восстановлено.
РЕДАКТИРОВАТЬ: это изменилось, клиент пытается восстановить соединение только в течение определенного периода времени. После этого вам нужно перехватить событие отключения и перезапустить вручную.
5 ответов
Это действительно зависит от того, будут ли повторно использоваться эти повторно используемые приложения вне проекта или нет?
Единственная причина, по которой он может вам понадобиться в другом репо, - это то, что он может понадобиться другим проектам с отдельными репозиториями. Но вы всегда можете разделить его позже. Создание репозитория git обходится недорого, поэтому это одна из тех вещей, которые вы можете сделать позже, если в этом возникнет необходимость. Если усложнять вещи заранее, это просто расстроит вас позже, поэтому не стесняйтесь ждать, пока вы не узнаете, что это необходимо
YAGNI, это больше, чем просто код.
Я не эксперт по git, но не верю, что подходящая стратегия будет отличаться от стратегии для hg или даже, в данном случае, svn, поэтому я собираюсь в любом случае отдайте мои 2 цента; -).
Репо для каждого приложения имеет смысл только в том случае, если значительное количество людей могут быть заинтересованы в извлечении (или наблюдении за изменениями) отдельных приложений; Теоретически это могло быть так, но я никогда не наблюдал этого в реальной жизни - в основном люди, заинтересованные в проекте, заинтересованы в нем в целом. Поэтому я бы избежал осложнений и превратил весь проект в одно репо.
Практически всегда проще иметь один репозиторий на каждую команду разработчиков, независимо от того, сколько у вас продуктов. В конце концов, вы захотите разделить код между проектами (даже несколькими отдельными веб-сайтами DJango!), И это намного проще сделать с помощью только одного репозитория.
Обязательно настройте красивую структуру папок ВНУТРИ этого репозитория. Однако одна проверка из git (возможно, из подпапки) должна предоставить вам все файлы, необходимые для вашего тестового веб-сайта (python, templates, css, jpegs ...), а затем вы просто скопируете httpd.conf и так далее в завершите установку.
Используют ли эти отдельные приложения общий код и библиотеки? Если это так, они действительно принадлежат одному репозиторию ... что позволяет вам видеть влияние новых изменений при запуске одного набора тестов.
Если они полностью разделены и независимы, это действительно не имеет значения. Из соображений здравомыслия, простоты сборки и простоты упаковки я предпочитаю хранить весь проект в объединенном репозитории. Однако обычно мы работаем в очень маленьких командах. Так что, если не используется общий код, на самом деле вопрос лишь в том, какой метод наиболее удобен и эффективен для всех заинтересованных сторон.
Мне нравятся ответы Тома или Алекса , за исключением того, что они не имеют реального обоснования
(«проще иметь по одному репозиторию на команду разработчиков»?
«значительное количество людей могут быть заинтересованы в извлечении (или просмотре изменений) отдельных приложений»
почему?)
Прежде всего, один или несколько репозиториев - это решение администрирования на стороне сервера (с точки зрения ресурсов сервера).
SVN легко настраивает несколько репозиториев за одним сервером, тогда как ClearCase будет иметь свой собственный процесс « vob_server » для каждого VOB, что означает: вам не нужно больше сотни VOB на (Unix) сервер (или более 20-30 на сервере Windows).
Git особенный: установка репозитория обходится дешево, доступ к может быть простым (через простой общий путь) или может включать процесс (демон git). Последнее решение означает: «не так много репозиториев имеют доступ напрямую извне». (к ним можно получить доступ косвенно через подмодули, на которые ссылается суперпроект)
Затем есть администрирование на стороне клиента : насколько сложной будет конфигурация рабочего пространства, когда задействованы один или несколько репозиториев . Как клиент может ссылаться на правильную конфигурацию ? (список ярлыков, необходимых для ссылки на правильные файлы).
SVN будет использовать внешние модули, git «подмодули», и в обоих случаях это добавляет сложности.
Вот почему ответ Тома может быть правильным.
Наконец, есть аспект управления конфигурацией (упоминается в ответ Алекса ). Можно ли пометить часть репо из not?
Если вы можете (например, в SVN, где вы фактически делаете svn-копию части репо), это означает, что у вас может быть компонентный подход , где несколько групп файлов имеют свой собственный жизненный цикл, а их собственные теги (устанавливаются в индивидуальном темпе).
Но в Git это невозможно: тег ссылается на фиксацию, которая всегда касается репозитория all .
Это означает «системный» подход , при котором вам в любом случае нужен только весь проект (в отличие от фрагмента «просмотр отдельных приложений - я никогда не наблюдал этого в реальной жизни» из Alex's ответ ). Если это так (если вы все равно хотите использовать всю систему), это не важно.
Но для тех из нас, кто думает о «независимых группах файлов», это означает, что репозиторий git на самом деле представляет собой отдельную группу файлов (со своим собственным ритмом в терминах эволюции и тегов) с потенциально супер- проект, ссылающийся на эти репозитории как на подмодули.
Это не ваша повседневная установка, поэтому для независимых проектов я бы порекомендовал всего несколько репозиториев Git или один.
Но для более сложного взаимозависимого набора проектов ... вам необходимо понять, что, судя по самому способу создания Git, «репозиторий» представляет собой согласованный набор файлов, который должен развиваться с той же скоростью, что и все. И не всегда «все» могут поместиться в один набор файлов (если «все» достаточно сложное). Следовательно, в этом случае потребуется несколько репозиториев.
И сложный набор взаимозависимых проектов действительно случается и в реальной жизни;)