WCF и Система. Пространство имен конфигурации
Можно ли объединить любую ветвь (скажем, Release), но не удалить?
Слияние и удаление - совершенно независимые действия. Несмотря на то, что есть некоторая защита, чтобы избежать ее непреднамеренного использования, несжатые ветви могут быть удалены. И объединенные ветви не удаляются автоматически в
git.Github имеет возможность автоматически закрывать ветви, которые были объединены, но это происходит «над» уровнем git в бизнес-логике github.
В конце концов, ветвь Develop закончится множеством веток Release, объединенных, но не удаленных ... В любой момент, если в репозитории нет разработчика, тогда у Git должна быть ветка Master. и только несколько веток Release.
Похоже, вы хотите, чтобы существование ветвей отражало что-то значимое. Это решение остается за вами и вашими коллегами. Но учтите следующее: пока существует ветвь, можно увидеть ее связь с другими ветвями (наиболее непосредственно по
git diffи по тому, какие ветви являются главой и / или позади каких других ветвей). Как только ветвь исчезнет, такое сравнение не может быть сделано. Поэтому вам решать, является ли удаление веток вашим любимым способом выразить работу в процессе.Я для одного чемпиона непрерывной интеграции с несколькими долгоживущими ветвями (например, разработка -> мастер), отмечая точки в мастере, если вы решите сокращать релизы, и удаляя недолговечные ветки объектов после того, как они были слились в разработке, когда это удобно. Но я бы никогда не предположил, что их существование или, если уж на то пошло, отсутствие, что-то значат.
gitможет сказать мне точно, в чем различия. Я бы придерживался этого. Удаление ветвей функций - это задача обслуживания, которая не создает быстрого интереса при отложении на неопределенный срок.
3 ответа
Я смог решить вопрос конфигурации путем удаления существующего кода из моего предыдущего ответа и замены его следующей реализацией ConfigurationManager:
string MySetting = ConfigurationManager.AppSettings.Get("MyAppSetting");
Если работы для приложений ASP.NET, приложений WinForms и WCF Services. Я просто сверхспроектировал начальное внедрение своей библиотеки классов 3 года назад....
Это зависит от того, что Вы пытаетесь выполнить. На ASP.NET Вы были бы обычно не использовать ConfigurationManager для материала как это, но WebConfigurationManager вместо этого. Тем не менее нет никакого точного эквивалента, с тех пор, в действительности, материал пользователя/роуминга/и т.д., который позволяет OpenExeConfiguration, не имеет смысла на веб-приложении.
Для чего Вы нуждаетесь в нем?
.NET, на которую ссылаются, 2.0 блока являются частью библиотеки классов, которую я разработал, чтобы наша библиотека предприятия обработала общие задачи. Это было предназначено, чтобы использоваться в приложениях WinForm и ASP.NET.
Вот исходный код, который я раньше определял который тип конфигурационного файла открыться:
//Open app.config or web.config file
if (HttpContext.Current != null)
this.m_ConfigFile = WebConfigurationManager.OpenWebConfiguration("~");
else
this.m_ConfigFile = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);