Как призвать более частые фиксации к SVN

Используете ли вы какое-либо программное обеспечение для отслеживания ошибок / функций?
Вы можете попросить их указать номер версии при отметке выполненная работа.

Если вы раньше использовали VSS, то, скорее всего, вы работаете в Visual Studio. В AnkhSVN есть окно ожидающих изменений, подобное тому, что есть в TFS и VSS. Это окно автоматически показывает, какие файлы локально изменены в вашем решении.

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

[См. этот снимок экрана более старой версии AnkhSVN]

Я думаю, что Проблема, которая у вас есть, на самом деле заключается в отсутствии непрерывной системы сборки, сочетающейся с отслеживанием ошибок / функций / изменений. С системой отслеживания ошибок и непрерывной сборкой разработчик может заявить о «завершенности» только после того, как его изменения внесены в автоматизированную сборку, и выпуск, содержащий изменения, собран, пройдет тесты проверки сборки и будет помещен в место сброса выпуска. Поскольку единственный способ внести изменения в сборку - это проверить (возможна обратная интеграция функциональной ветки в основную ветку / ствол), разработчикам придется проверять, иначе они никогда ничего не закончат. .

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

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

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

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

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

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

Массивы на Java ковариантны. Это означает, что TSub [] является подтипом TSuper [] , если TSub является подтипом TSuper .

Имеется int [] [] , который является массивом int [] . Теперь, как отмечали другие, любой массив в Java является подтипом Object , поэтому int [] является подтипом Object . Так, благодаря ковариации массива, int [] [] является подтипом Object [] (подстановка TSub = int [] и TSuper = Object в приведенном выше определении ковариации).

Edit - Чтобы понять, почему ковариация важна здесь, учтите, что сделать то же самое с List < T > не получится:

List<Object> ref2 = new List<int[]>()

/// Calculates the SHA1 for a given string
let calcSHA1 (text:string) =
    text 
      |> System.Text.Encoding.ASCII.GetBytes
      |> (new System.Security.Cryptography.SHA1CryptoServiceProvider()).ComputeHash
      |> Array.fold (fun acc e -> 
           let t = System.Convert.ToString(e, 16)
           if t.Length = 1 then acc + "0" + t else acc + t) 
           ""
/// Calculates the SHA1 like git
let calcGitSHA1 (text:string) =
    let s = text.Replace("\r\n","\n")
    sprintf "blob %d%c%s" (s.Length) (char 0) s
      |> calcSHA1

Это решение в F #.

Автоматизируйте сборки и развертывания и сделайте их частью процесса, чтобы ничего не было "сделано" до тех пор, пока они не будут протестированы на тестовом сервере

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

Как разработчик может закончить что-то и забыть проверить это? Является ли процесс доставки таким, что пользователь запускает сборку с собственной машины разработчика?

Хороший трекер ошибок / функций позволит вам добавить номер ошибки при фиксации изменений. Например, если я запускаю Redmine, я могу выполнить фиксацию с помощью «Fixes # 323» где-нибудь в моем сообщении о фиксации Subversion, и он автоматически закроет ошибку / задачу 323. Его установка очень проста; вам просто нужно указать Redmine, где находится репозиторий, который в любом случае запрашивается.

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

Trac также делает это, как и многие другие.