Число пересмотра подверсии через несколько проектов

Ummm ... внутренний класс IS является вложенным классом ... вы имеете в виду анонимный класс и внутренний класс?

Edit: Если вы на самом деле имели в виду внутреннее или анонимное ... внутренний класс - это просто класс, определенный в классе, например:

public class A {
    public class B {
    }
}

. В то время как анонимный класс является расширением класса, определенного анонимно, поэтому никакого фактического «класса» не определено, как в:

public class A {
}

A anon = new A() { /* you could change behavior of A here */ };

Дальнейшее редактирование:

Википедия утверждает, что в Java существует разница , но я работаю с Java в течение 8 лет, и это первое, что я услышал такое различие ... не говоря уже о том, что нет ссылок на резервную заявку ... нижняя строка, внутренний класс - это класс, определенный внутри класса (статический или нет), а вложенный - это еще один термин, означающий одно и то же.

Существует тонкая разница между статическим и нестатическим вложенными классами ... в основном нестатические внутренние классы имеют неявный доступ к полям экземпляра и методам охватывающего класса (таким образом, они не могут быть построены в статическом контекст, это будет comp iler). Статические вложенные классы, с другой стороны, не имеют неявного доступа к полям и методам экземпляра, а CAN могут быть сконструированы в статическом контексте.

24
задан Community 23 May 2017 в 12:09
поделиться

15 ответов

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

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

Это некоторые преимущества подхода единого репозитория.

  1. Упрощенное администрирование. Один набор рычагов для развертывания. Один репозиторий для резервного копирования. и т.д.
  2. гибкость Ответвления/тега. С кодом все в одном репозитории это облегчает создавать ответвление или тег, включающий несколько проектов.
  3. код Перемещения легко. Возможно, Вы хотите взять раздел кода из одного проекта и использовать его в другом или превратить его в библиотеку для нескольких проектов. Легко переместить код в том же репозитории и сохранить историю кода в процессе.

Вот некоторые недостатки к подходу единого репозитория, преимущества для нескольких подход репозитория.

  1. Размер. Могло бы быть легче иметь дело со многими репозиториями меньшего размера, чем один большой. Например, при уходе в отставку проекта, можно просто заархивировать репозиторий к медиа и удалить его из диска и свободный устройство хранения данных. Возможно, необходимо вывести/загрузить репозиторий по некоторым причинам, например, для использования в своих интересах новой функции Subversion. Это легче сделать и с меньшим количеством влияния, если это - репозиторий меньшего размера. Даже если Вы в конечном счете захотите сделать это во все Ваши репозитории, это окажет меньше влияния, чтобы сделать их по одному, предполагая, что нет срочной необходимости сделать их внезапно.
  2. Глобальное число пересмотра. Даже при том, что это не должно быть проблемой, некоторые люди чувствуют, что он один, и не любят видеть, что число пересмотра совершенствуется на репозитории и для неактивных проектов иметь большие разрывы в их истории пересмотра.
  3. Управление доступом. В то время как authz механизм Подрывной деятельности позволяет Вам ограничивать доступ по мере необходимости к частям репозитория, еще легче сделать это на уровне репозитория. Если у Вас есть проект, что только выбор, к которому должны получить доступ немного людей, это легче сделать с единым репозиторием для того проекта.
  4. Административная гибкость. Если у Вас есть несколько репозиториев, то легче реализовать различные сценарии рычага на основе потребностей репозитория/проектов. Если Вы хотите универсальные сценарии рычага, то единый репозиторий мог бы быть лучше, но если каждый проект хочет свой собственный почтовый стиль фиксации тогда, легче иметь те проекты в отдельных репозиториях

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

9
ответ дан James McMahon 28 November 2019 в 23:35
поделиться

Имел ту же проблему в моей предыдущей компании, Они используют для имения как 50 проектов, работающих в одном репозитории, и это был кошмар для работы над теми же проектами из-за того, когда выполнение svn обновляет других, проклял бы.... lol...

Одна вещь я узнал, что всегда удается лучше всего, Один проект Один Repo...., Вы никогда не будете сожалеть о нем.

0
ответ дан Ronald Conco 28 November 2019 в 23:35
поделиться

Числа пересмотра не имеют никакого семантического использования. Единственная вещь, что они находятся в последовательном порядке. Если Вы выводите свой проект и импортируете его в другом репозитории, Ваши версии могут получить новые числа пересмотра. Так НИКОГДА не используют числа пересмотра для маркировки выпусков или подобного материала. Сделайте теги для выпусков (копии соответствующего пересмотра).

0
ответ дан Mnementh 28 November 2019 в 23:35
поделиться

Я не уверен, что документы SVN на самом деле рекомендуют один проект на репозиторий. Главным образом они говорят о позитивных аспектах и оборотных сторонах каждого пути. Я, оказывается, использую три различных репозитория, один для 7 или 8 проектов, которые все связаны, делая очень хорошим быть в состоянии отослать совместимые копии всех проектов только путем создания из одного пересмотра (или проверяя, что они совместимы путем рассмотрения чисел пересмотра на каждом). Второй репозиторий имеет другую группу связанных проектов и документов, в то время как третьим является намного меньший. Это позволяет нам использовать в своих интересах то, что связанными проектами может управлять единственное число пересмотра, но что несвязанные проекты не влияют на свой репозиторий.

0
ответ дан 28 November 2019 в 23:35
поделиться

@Daniel Fone: документы SVN рекомендуют один проект на репозиторий, так, чтобы был определенно путь, которым создатели предназначили его для движения. Поскольку у Вас может быть один сервер (апач, или svnserve) поддерживают несколько репозиториев, я никогда не сталкивался с проблемой слишком много служебного. С Сервер VisualSVN , устанавливая апачский сервер и настраивая несколько репозиториев является защелкой.

0
ответ дан flipdoubt 28 November 2019 в 23:35
поделиться

Один репозиторий на проект.

комментарий Steven Murawski о CC.NET является интересным. Мне было бы интересно слышать, как это работает, если необходимо определить несколько репозиториев управления исходным кодом.

0
ответ дан flipdoubt 28 November 2019 в 23:35
поделиться

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

я только начинаю добавлять сервер сборки CI (CruiseControl.NET), таким образом, я должен буду видеть, как это все удается, но если мои сценарии сборки являются правильными, что это не должна быть проблема.

Кроме появления, хотя, это - действительно вопрос предпочтения (по-моему).

1
ответ дан Community 28 November 2019 в 23:35
поделиться

На моем рабочем месте у нас есть два репозитория. Один с общедоступным доступом для чтения, и один для всего остального. Я использовал бы всего один для всего, но нам нужны различные права доступа для общедоступных/частных проектов.

Однако я лично не вижу проблемы с постепенным увеличением чисел пересмотра на каждом обновлении. Числа пересмотра могли пропустить простые и четные числа и все еще сделать что его воображаемое сделать. Облегчите добираться до определенного пересмотра.

3
ответ дан Grant 28 November 2019 в 23:35
поделиться

Гм, где я работаю, у нас есть все наши проекты в том же репозитории. Я действительно не вижу преимущества разделения их, который только создает большую дополнительную работу - создание новых репозиториев, предоставление доступа людям, и т.д.? Я предполагаю, что отдельные репозитории имеют смысл, если проекты абсолютно не связаны, и у Вас есть, скажем, внешние клиенты, который должен иметь доступ к repo.

3
ответ дан Erlend Halvorsen 28 November 2019 в 23:35
поделиться

Рекомендуемый использовать отдельный репозиторий на проект. В моем Apache conf.d каталог у меня есть subversion.conf, который содержит:

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

Тогда каждый раз, когда я запускаю новый проект, я просто работаю:

svnadmin create /var/www/svn/myproject
3
ответ дан grom 28 November 2019 в 23:35
поделиться

У нас просто есть один репозиторий со всем в нем, в значительной степени точно как Ваш пример.

я не вижу ничто плохого с этим - единственное требование для числа пересмотра - то, что это

  • Уникально
  • Атомарный
  • Больше, чем это было при последней регистрации

, не имеет значения, если это увеличивается на 1 или 50 с каждой фиксацией, насколько я заинтересован.

@grom:

Тогда каждый раз, когда я запускаю новый проект, я просто работаю:

svnadmin create /var/www/svn/myproject

я вижу, что это хорошо работает, если Вы только получили 1 или 2 devs, но что происходит, если у людей, которые создают новые проекты, нет доступа оболочки на сервере SVN, чтобы быть в состоянии создать каталоги под/var/www?

4
ответ дан Orion Edwards 28 November 2019 в 23:35
поделиться

Число пересмотра должно действительно только быть идентификатором для конкретной версии. Последовательно ли это для проекта или не не должно иметь значения. Однако я могу понять, что это - меньше, чем идеал.

Большинство проектов, с которыми я встретился, было установкой в едином репозитории, и идентификаторы пересмотра ведут себя таким образом. Я не знаю параметра конфигурации SVN изменить это поведение, и по моему скромному мнению, поддержание нескольких репозиториев походит на ненужные издержки.

4
ответ дан Daniel Fone 28 November 2019 в 23:35
поделиться

Я думаю, что это настоятельно рекомендовано это, Вы создаете отдельные репозитории для каждого проекта. Если ни для чего иного, чем избежать сценария Вы говорите о.

С управлением версиями, особенно Подрывной деятельностью, можно легко проверить части репозитория в другую рабочую копию и затем фиксировать их назад их соответствующим репозиториям. Это позволяет, Вы для хранения их ясно отделяетесь и отличный при предоставлении Вам большой гибкости. Как только Вы входите в SVN немного больше (я предполагаю, что Вы являетесь новыми.) можно начать использовать рычаги, и я мог бы видеть, где это могло стать трудным с Вами установка. Если разрешение важно для Вас, единый репозиторий мог бы оказаться более трудным, чем необходимый.

кроме того, если Вы обеспокоены, что потребуется много времени для установки каждого репозитория, изучают переменную SVNParentPath для конфигурационного файла Apache. (Снова, я предполагаю, что Вы используете Apache.)

6
ответ дан Barrett Conrad 28 November 2019 в 23:35
поделиться

Это происходит из-за того, как подрывная деятельность работает. Каждый пересмотр является действительно снимком репозитория, определенного тем числом пересмотра. Если все Ваши проекты совместно используют репозиторий тогда, это неизбежно. Как правило, по моему опыту, однако Вы установили бы отдельные репозитории для абсолютно несвязанных проектов. Таким образом, короткий ответ не, Вы ничего не делаете неправильно, что это - общий вопрос окружающая подрывная деятельность, но это имеет смысл, когда Вы думаете о том, как это хранит информацию о хранилище.

4
ответ дан John Downey 28 November 2019 в 23:35
поделиться

Если наличие изменения чисел пересмотра на основе других проектов беспокоит Вас, затем поместило проекты в отдельные репозитории. Это - единственный способ сделать числа пересмотра независимыми.

мне, большая причина использовать различные репозитории состоит в том, чтобы предоставить отдельное управление доступом пользователям и/или использование различных сценариев рычага.

2
ответ дан crashmstr 28 November 2019 в 23:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: