Структура управления исходным кодом сервера основы команды
Операции takeWhile и dropWhile добавлены в JDK 9. Ваш примерный код
IntStream
.iterate(1, n -> n + 1)
.takeWhile(n -> n < 10)
.forEach(System.out::println);
будет вести себя точно так, как вы ожидаете, когда он скомпилирован и запущен под JDK 9.
Выпущен JDK 9. Его можно скачать здесь: http://jdk.java.net/9/
5 ответов
Мне нравится Ваша идея поместить файлы Замка из песка как одноранговому узлу к Источнику и Тестам, я добавил бы папку документации, которая будет тогда содержать файлы замка из песка, и дополнительно фактическую документацию.
существуют определенно различия мнений, и я уверен, что буду downvoted для этого (так как я был прежде). Я поместил бы сгенерированную документацию в TFS по нескольким причинам:
- Ваша попытка хотеть Вашу документацию с каждым выпуском и использованием TFS является легким подходом, чтобы гарантировать, что Ваша документация остается в корректном месте.
- Используя TFS для хранения это означает, что все будут знать, куда пойти, получают документацию.
Одна вещь я не вижу, с которым я всегда борюсь, то, где к сторонним зависимостям, могло бы случиться так, что они относятся вниз к источнику, таким образом, они с каждым проектом, хотя, если Вы хотели совместно использовать их через проекты, Вы могли бы добавить новый высокоуровневый узел.
Редактирование
Для моих двоичных файлов я обычно заканчиваю с
$/ThirdParty/Company/Product/Version/Src (дополнительно)
Так, например, я имею
$/thirdparty/Microsoft / EntLib/3.1 4.0 ComponentArt/WebUI/2008.1/Src
, мне нравится добавлять источник, я должен был исправить источник CA, который я очень не хочу сделать, но когда третье лицо не исправляет ошибку, необходимо обратиться к этому.
Большое расположение и объяснение. Я боролся с теми же самыми проблемами. Я волновал с очень похожей структурой. Мой варьируется немного.
Development/
Trunk/
Binaries/ -- Shared libraries
Source/
Test/
Docs/ -- Documentation
TeamBuildTypes/ -- Build definitions
- Добавление двоичной папки позволяет Вам иметь одно расположение в ответвлении, где все Ваши проекты могут сослаться на совместно использованные библиотеки
- , Мы помещаем документацию здесь, таким образом, это может переместиться наряду с, он - определенное ответвление.
- Наши определения сборки на уровне разработки, так как мы можем изобразить их в одном месте для всех ответвлений, но это могло определенно быть на уровне ответвления, который может иметь больше смысла.
Должен двоичные файлы (средства управления, библиотеки, и т.д.) быть сохраненным в управлении исходным кодом? Если так, это должен быть свой собственный Проект Команды?
я думаю, что они должны определенно быть источником, которым управляют, но я не вижу оснований для помещения их в их собственный проект команды. Одной проблемой, чтобы быть осторожной с является TFS, по некоторым причинам рассматривает немного отличающиеся двоичные файлы. У меня были проблемы, где я обновил двоичные файлы в управлении исходным кодом, но "Получение Последнего" на других машинах не вызывает обновление файлов. Иногда необходимо сделать, "Получают Определенную Версию" и проверяют опцию "Overwrite Unchanged Files" на тот конкретный файл.
Необходимо подвергнуть папку TeamBuilds соединительной линии. Это было невозможно в TFS2005, но Microsoft зафиксировала его на 2008...
причина этого состоит в том, что Ваша сборка может измениться с более новой версией (например: новые упаковочные схемы, различное тестирование и т.д.), который может сделать его несовместимым с более старыми корректировочными версиями. Вот почему необходимо связать сборку команды с версией кода.
Таким образом, позволяет, говорят, что Вы выпускаете 1,0 версии и подвергаете ее папке Releases. Вы будете в состоянии создать его и патчи проблемы при работе над v2.0 в соединительной линии Разработки (который может потребовать изменения сборки)
Одна вещь, которую я рекомендовал бы, не состоит в том, чтобы использовать местоположение по умолчанию для сборок команды и включать его в 'branchable' уровень, потому что, поскольку Вы переходите по различным причинам (говорят продвижения кода) Вы захотите, чтобы Ваши сценарии сборки переходились и синхронизировались с ним.
Также новое и больше сценария определенное руководство было просто опубликовано также в http://www.codeplex.com/TFSBranchingGuideII
Для Ваших двоичных файлов - очевидно, единственные двоичные файлы, которые должны являться объектом управления версиями, являются "сторонними" блоками, которые Вы не "создаете" как часть никакой автоматизированной сборки. Если у Вас есть свои собственные библиотеки, что у Вас есть их источник при управлении версиями и т.д. - необходимо посмотреть на различные стратегии создания и синхронизации и т.д.
, я тогда организую их как Josh - и затем использую ветвление, чтобы "скопировать" двоичные файлы в _ExternalReferences папку, которая является одноранговым узлом к папкам Project.NET в дереве решения. Это - очень эффективный путь сторона сервера, поскольку Управление версиями TFS только хранит "Дельты" - поэтому по существу, каждое "дублирование" тех двоичных файлов через многие проекты по существу похоже на "указатель".