Что не должно являться объектом управления исходным кодом?
Попытка включает вход в систему
Insted попытки пользователей разъединения, которых Вы не должны позволять им соединять.
существует и пример такого триггера.
CREATE OR REPLACE TRIGGER rds_logon_trigger
AFTER LOGON ON DATABASE
BEGIN
IF SYS_CONTEXT('USERENV','IP_ADDRESS') not in ('192.168.2.121','192.168.2.123','192.168.2.233') THEN
RAISE_APPLICATION_ERROR(-20003,'You are not allowed to connect to the database');
END IF;
IF (to_number(to_char(sysdate,'HH24'))< 6) and (to_number(to_char(sysdate,'HH24')) >18) THEN
RAISE_APPLICATION_ERROR(-20005,'Logon only allowed during business hours');
END IF;
END;
22 ответа
Все, что сгенерировано. Двоичный, байт-код, код / документы, сгенерированные из XML.
Из моих комментаторов, исключить:
- Все, что сгенерировано сборкой, включая документацию кода (doxygen, javadoc, pydoc и т. Д.)
Но включают:
- ] Сторонние библиотеки, у которых нет исходного кода для ИЛИ , не собираются.
FWIW, во время моей работы над очень большим проектом у нас есть следующее в ClearCase:
- Все исходный код
- Исходный код Qt И встроенные спецификации отладки / выпуска
- (Ужасно устаревшие)
У нас нет встроенных модулей для нашего программного обеспечения. Полный двоичный файл с последними обновлениями распространяется каждые пару недель.
Если у вас есть среда выполнения для вашего кода (например, библиотеки зависимостей, определенные версии компилятора и т. Д.), Не помещайте пакеты в систему управления версиями. Мой подход жестокий, но эффективный. Я фиксирую make-файл, роль которого заключается в загрузке (через wget) материала, его распаковке и создании моей среды выполнения.
Независимо от языка:
- файлы кэша
- как правило, импортированные файлы также не должны (например, изображения, загруженные пользователями в веб-приложение)
- временные файлы; даже те, которые сгенерированы вашей ОС (например, thumbs.db в Windows) или файлы конфигурации IDE
- с паролями? Зависит от того, у кого есть доступ к хранилищу
И для тех, кто не знает об этом: svn: ignore отлично!
У меня есть конкретный файл .c, который не входит в систему управления версиями.
В системе управления версиями, генерируемой в процессе сборки, нет правила.
Единственное известное исключение это если инструмент требует для сборки более старую версию (проблема начальной загрузки). В этом случае вам понадобится заведомо исправная копия начальной загрузки в системе управления версиями, чтобы вы могли строить с нуля.
Вещи, которые не входят в систему управления версиями, делятся на 3 класса
- Вещи, совершенно не связанные с проектом (очевидно)
- Вещи, которые можно найти на установочных носителях, и никогда изменено (например: сторонние API-интерфейсы).
- Вещи, которые могут быть механически сгенерированы в процессе сборки из вещей, которые являются в системе управления версиями (или из вещей в классе 2).
Временные файлы, конфигурация для всего, кроме глобальной разработки и конфиденциальной информации
Фактические файлы конфигурации, такие как web.config в asp.net, потому что у людей могут быть разные настройки. Обычно я справляюсь с этим, используя web.config.template, который находится в SVN. Люди получают его, вносят необходимые изменения и переименовывают его в web.config.
Помимо этого и того, что вы сказали, будьте осторожны с конфиденциальными файлами, содержащими пароли (например).
Избегайте всех надоедливых файлов, созданных с помощью Windows (большой палец) или Mac OS (.ds_store)
Файлы конфигурации, содержащие пароли или любую другую конфиденциальную информацию.
desktop.ini - еще один файл Windows, в который я видел, как крадутся.
Исключение:
4 или 5 разных ответов сказали, что сгенерированные файлы не должны попадать под контроль версий. Это не совсем так.
Файлы, созданные специальными инструментами, могут принадлежать системе контроля версий, особенно если требуются определенные версии этих инструментов.
Примеры:
- парсеры, генерируемые bison / yacc / antlr,
- autotools файлы, такие как configure или Makefile.in, созданные autoconf, automake, libtool и т. д.,
- файлы перевода или локализации,
- файлы могут быть созданы дорогими инструментами, и было бы дешевле установить их только на нескольких машинах .
По сути, если вы не можете разумно ожидать, что разработчик будет иметь точную версию того инструмента , который им нужен, то можно поместить сгенерированные файлы в систему контроля версий.
Я бы подошел к проблеме иначе; какие вещи должны быть включены в систему управления версиями? Вы должны контролировать исходный код только те файлы, которые:
- (требуется история изменений ИЛИ созданы вне вашей сборки, но являются частью сборки, установки или носителя) И
- не могут быть сгенерированы процессом сборки, который вы контролируете И
- являются общими для всех пользователей, которые создают продукт (без пользовательской конфигурации).
В список входят такие вещи, как:
- исходные файлы
- файлы make, проекта и решения
- другие файлы конфигурации инструмента сборки (не связанные с пользователем)
- Сторонние библиотеки
- предварительно созданные файлы, которые хранятся на носителе, например PDF-файлы и документы
- документация
- изображения, видео, звуки
- файлы описания, такие как WSDL, XSL
Иногда результат сборки может быть входом сборки. Например, файл переименования обфускации может быть выходом и входом для сохранения той же схемы переименования. В этом случае используйте зарегистрированный файл в качестве входных данных для сборки и поместите выходные данные в другой файл. После сборки проверьте входной файл, скопируйте в него выходной файл и зарегистрируйте его.
Проблема с использованием списка исключений состоит в том, что вы никогда не узнаете все правильные исключения и можете в конечном итоге получить контроль источника над тем, что не должно не контролируется источником.
Все, что может быть создано IDE, процессом сборки или двоичным исполняемым процессом.
Как Кори D сказал все, что сгенерировано, особенно все, что сгенерировано сборкой процесс и среда разработки - хорошие кандидаты. Например:
- Двоичные файлы и установщики
- Байт-код и архивы
- Документы, созданные из XML и кода
- Код, созданный шаблонами и генераторами кода
- Файлы настроек IDE
- Файлы резервных копий, созданные вашей IDE или редактор
Некоторые исключения из вышеперечисленного могут быть:
- Изображения и видео
- Сторонние библиотеки
- Специальные файлы настроек IDE для команды
Возьмите сторонние библиотеки, если вам нужно поставлять или ваша сборка зависит от сторонней библиотеки, было бы разумно поставить он находится под контролем источника, особенно если у вас нет источника. Также учтите, что некоторые системы управления версиями не очень эффективны при хранении двоичных двоичных объектов, и вы, вероятно, не сможете воспользоваться инструментами сравнения систем для этих файлов.
Пол также дает отличный комментарий о сгенерированных файлах и вы должны проверить его ответ :
В принципе, если вы не можете разумно ожидайте от разработчика точного версия именно того инструмента, который им нужен, есть случай поставить сгенерированные файлы в системе контроля версий.
С учетом всего вышесказанного, в конечном итоге вам нужно будет учитывать, что вы помещаете в систему контроля версий, в каждом конкретном случае. Составление жесткого списка того, что и чего не следует указывать, сработает только для некоторых и, вероятно, надолго. И, конечно же, чем больше файлов вы добавите в систему управления версиями, тем больше времени потребуется на обновление вашей рабочей копии.
Некоторые другие типичные файлы / папки Visual Studio:
*.cachefile
*.backup
_UpgradeReport_Files
Мой шаблон глобального игнорирования черепахи, например, выглядит так
bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
Файлы ОС, созданные их файловыми браузерами, такими как
Thumbs.db и .DS_Store
Я нашел лучший способ подумать об этом так:
Представьте, что у вас совершенно новый, купленный в магазине компьютер. Вы устанавливаете ОС и обновления; вы устанавливаете все свои инструменты разработки, включая клиент системы контроля версий; вы создаете пустой каталог, который будет корнем ваших локальных источников; вы делаете «получить последнюю версию» или как это называет ваша система управления версиями, чтобы получить чистые копии выпуска, который вы хотите построить; затем вы запускаете сборку (полученную из системы контроля версий), и все строится.
Этот мыслительный процесс объясняет вам, почему определенные файлы должны находиться в системе контроля версий: все те, которые необходимы для сборки, чтобы работать в чистой системе. Сюда входят файлы .designer.cs, выходные данные шаблонов T4 и любые другие артефакты, которые сборка не создает.
Здесь я рискую, но я считаю, что если вы используете списки задач в Visual Studio, они хранятся в файле .suo. Возможно, это не повод держать их в системе контроля версий, но это повод хранить где-нибудь резервную копию, на всякий случай ...
Мнение: все может быть в системе управления версиями, если вам нужно, если только это не приводит к значительным накладным расходам репозитория, таким как частое изменение или большие двоичные объекты.
Сторонние двоичные файлы, трудно сгенерировать (с точки зрения времени) сгенерированные файлы для ускорения процесса развертывания, все в порядке.
Основная цель управления версиями - согласовать одно связное состояние системы с номером версии. Если бы это было возможно, я бы заморозил всю вселенную с помощью инструментов сборки кода и целевой операционной системы.