Передача унаследованного кода базируется от cvs до распределенного репозитория (например, мерзавец или подвижный). Предложения необходимы для начального [закрытого] дизайна репозитория
Поскольку кварталы представляют собой локализованную (западную) концепцию, вместо локали по умолчанию укажите локаль:
Calendar cal = Calendar.getInstance(Locale.US);
/* Consider whether you need to set the calendar's timezone. */
cal.setTime(date);
int month = cal.get(Calendar.MONTH); /* 0 through 11 */
int quarter = (month / 3) + 1;
Это позволит избежать получения тринадцатого месяца (Calendar.UNDECIMBER) в незападных календарях, и любой перекос, вызванный их более короткими месяцами.
2 ответа
Просто небольшой комментарий, чтобы напомнить вам, что:
- эти миграции часто предлагают возможность реорганизовать источники не по модулям (каждый с одним репозиторием), а по разделению функционального домена (несколько модулей для одного и того же заданного функционала). домен помещается в тот же репозиторий).
[...] CVS, т.е. он действительно в значительной степени ориентирован на "один файл за один раз ».
Что приятно тем, что у вас может быть миллион файлов, а затем проверять только некоторые из них - вы даже никогда не увидите влияние другого 999 995 файлов.
Git принципиально никогда не смотрит на меньше, чем на все репо. Даже если ты немного ограничить вещи (например, проверить только часть или оставить историю немного назад), git по-прежнему всегда заботится обо всем,
Итак, git очень плохо масштабируется, если вы заставляете его смотреть на все как на единое целое. огромный репозиторий. Я не думаю, что это действительно поправимо, хотя мы возможно, можно улучшить его.
И да, еще есть проблемы с "большим файлом". Я действительно не знаю что делать с огромными файлами. Я знаю, что мы их обижаем.
Эти два вышеупомянутых пункта выступают за более компонентно-ориентированный подход для большой системы (и большого унаследованного репозитория).
С помощью подмодуля Git вы можете проверить их в своем проекте (даже если это двухэтапный процесс). Однако у вас есть инструменты, которые могут упростить управление подмодулем (например, git.rake ).
Когда я думаю об исправлении ошибки в модуле, который используется несколькими проектами, я просто исправляю ошибка и фиксация, и все просто делают свои обновления
Это то, что я описываю в сообщении Vendor Branch как «системный подход»: все работают над последней (HEAD) версией всего, и это эффективен для небольшого количества проектов.
Однако для большого количества модулей понятие «модуль» по-прежнему очень полезно, но управление им отличается от DVCS:
для тесно связанных модулей (также называемых «в одном функциональном домене», например «все модули» связанных с PNL - прибылью и убытками - или «анализом рисков» в финансовой сфере), вам действительно нужно работать с последней версией (HEAD) всех задействованных компонентов.
Этого можно достичь с помощью стратегии поддерева , но не для того, чтобы вы публиковали (проталкивали) исправления в эти другие подмодули, а для отслеживания работ, выполненных другими командами.
Git позволяет это с дополнительным бонусом, заключающимся в том, что это «отслеживание» не обязательно должно происходить между вашим репозиторием и одним «центральным» репозиторием, но также может происходить между вами и локальным репозиторием другой команды, что позволяет очень быстро обратная интеграция и тестирование между проектами схожего характера.однако для модулей, которые не находятся непосредственно в вашей функциональной области, подмодули являются лучшим вариантом, поскольку они относятся к исправленной версии модуля (фиксации) :
когда низкоуровневый фреймворк изменяется, вы не хотите, чтобы он распространялся мгновенно , так как это повлияет на все другие команды, которым затем придется отказаться от своих действий, чтобы адаптировать свой код к этому новому версия (вы хотите, чтобы все другие команды знали об этой новой версии, чтобы они не забыли обновить этот низкоуровневый компонент или «модуль»).
Это позволяет вам работать только с официальными стабильными идентифицированными версиями других модулей, а не с потенциально нестабильными или не полностью протестированными HEAD.
Что касается Mercurial, то рекомендуется также реорганизовать большие устаревшие репозитории CVS / SVN на более мелкие компоненты. Общий код должен быть помещен в его собственные библиотеки, и тогда код приложения будет зависеть от этих библиотек аналогично тому, как он зависит от других библиотек.
Mercurial имеет расширение леса , которое позволяет вам: управлять «лесом» из «исходных деревьев». При таком подходе вы объединяете несколько меньших репозиториев в более крупный. С CVS вы делаете наоборот: вы проверяете меньшую часть большого репозитория.
Я лично не использовал расширение леса, и на его странице говорится, что следует использовать обновленную версию по сравнению с той, которая поставляется с Mercurial. Тем не мение, он используется крупной организацией, такой как Sun, в ее проекте OpenJDK .
В настоящее время также ведется работа по добавлению отчета суб-репозитория непосредственно в ядро Mercurial, согласно дизайн на странице вложенных репозиториев в вики Mercurial.