Управление версиями “лучшая практика”
Нет нет никакого встроенного Строкового метода. Можно преобразовать его в массив символов, отсортировать его с помощью Arrays.sort и преобразовать тот назад в Строку.
String test= "edcba";
char[] ar = test.toCharArray();
Arrays.sort(ar);
String sorted = String.valueOf(ar);
Или, когда Вы хотите иметь дело правильно с определенным для локали материалом как символы верхнего регистра и символы с диакритикой:
import java.text.Collator;
import java.util.Arrays;
import java.util.Comparator;
import java.util.Locale;
public class Test
{
public static void main(String[] args)
{
Collator collator = Collator.getInstance(new Locale("fr", "FR"));
String original = "éDedCBcbAàa";
String[] split = original.split("");
Arrays.sort(split, collator);
String sorted = "";
for (int i = 0; i < split.length; i++)
{
sorted += split[i];
}
System.out.println(sorted); // "aAàbBcCdDeé"
}
}
6 ответов
Я не знаю, почему вы думаете, что ветки временные - они будут существовать до тех пор, пока вы этого хотите.
Ваше приложение звучит так, как будто оно могло бы выиграть от реструктуризации для реализации большей модульной функциональности, но тем временем вы можете разработать основную функциональность как магистраль, при этом каждая клиентская версия станет отдельной ветвью.
Модификации основного кода затем можно объединить в каждую ветку по мере необходимости. Изменения, специфичные для клиента, могут быть сделаны изолированно в этой ветви или объединены обратно в магистраль позже.
Отдельные репозитории для каждого клиента звучит как совершенно неправильный поступок, так как это может привести к дублированию общего кода между репозиториями.
Насколько я знаю, то, что вы делаете, не является тем, что должен делать контроль версий. Он используется только для отслеживания вашего исходного кода, а не вашего распространяемого продукта. На ваш вопрос о ветках, я думаю, может помочь это небольшое объяснение: - ствол - это основная разработка проекта, здесь взаимодействуют все члены команды - ветка - это место для временного развития (да, вы не ослышались). Здесь вы можете экспериментировать или возиться с кодом, не затрагивая других членов команды. - тег - не что иное, как «именованный снимок». В системе управления версиями снимки проекта повсюду, тег - это способ дать им более удобочитаемое имя. Если вы попытаетесь получить все больше и больше веток, не избавляясь от них, ваш проект будет расти и расти вечно. Я все еще удивляюсь, почему вы все равно должны отслеживать все это. Могу я повторить еще раз, контроль версий предназначен только для совместной работы над исходным кодом, а не для распространения среди множества клиентов. Надеюсь на помощь
Во-первых, вам, возможно, будет лучше прикусить пулю и провести рефакторинг вашего кода, чтобы уменьшить влияние всех этих настроек. Есть хорошие шаблоны, которые допускают этот тип сценария (на ум приходят конфигурации, плагины, фабрика программного обеспечения).
Сказав это, если приложение такое, как вы описываете (каждый клиент требует широкомасштабных изменений в ядре ), вы можете захотеть узнать, работает ли использование директив компилятора для изоляции отдельных клиентских изменений лучше, чем ветвление. Проблема с ветвлением (как я уверен, вы уже заметили) заключается в том, что исправление, помещенное в одну ветку, часто необходимо распространять на все другие ветки (поскольку вы никогда не собираетесь объединять ветки в будущем). Кроме того, вам может потребоваться исправить производственную версию, работающую на одном клиенте, пока вы все еще разрабатываете следующую версию для этого клиента ... ветвь ветви.
Ситуация будет только ухудшаться, если вы продолжите эту стратегию ветвления на клиента по мере добавления новых клиентов.
Ветвление функций - это модульная архитектура для бедняков, вместо того, чтобы строить системы с возможностью простой замены функций во время выполнения / развертывания, они соединяются с системой управления версиями, обеспечивая этот механизм посредством ручного слияния .
- Дэн Бодар - через Мартин Фаулер
Контроль версий - очень неподходящий инструмент для этого, поскольку вы хотите использовать его для управления версиями, а не клиентами.
Прежде всего, используйте ветки и узнайте, как правильно использовать свою систему контроля версий.
Я работал над проектом, в котором они пытались управлять версиями, как вы описали, с помощью тегов. Это была чья-то работа - вручную добавлять / объединять изменения для тега, а затем применять новый тег. Это затрудняет синхронизацию всех и почти всегда приводит к сбоям в сборках из-за простых ошибок (забытые файлы, внесение изменений и т. Д.). Вы в основном вручную делаете то, что делают за вас ветви .
Что касается того, как управлять различными настройками клиента. Помимо управления стратегией ветвления для каждой версии клиента, вам следует взглянуть на архитектуру и подумать о том, как вы хотите управлять настройками / различиями.
Можно ли разбивать компоненты и иметь подпроекты? Некоторые из основных областей могут не меняться часто и могут быть добавлены в сборку (вроде сторонних jar-файлов).
Или вы можете выполнить базовую сборку / установку, а затем наслоить на нее настройки. Наложите пользовательские файлы и / или измените базовые файлы.
Я пишу патч для приложения, часть которого включает выполнение sql-скрипта
5000строк для внесения изменений в базу данных. Скрипт написан с использованием синтаксисаMSSQL, однако мне было интересно, есть ли приложение для автоматического преобразования синтаксисаMSSQLв синтаксисOracleи / илиMySQL, чтобы избавить меня от необходимости делать это вручную.
Это вряд ли возможно.
Общее подмножество SQL , которое все эти системы поддерживают, довольно мало.
Поскольку у вас есть ] 5000 строк кода в вашем скрипте, скорее всего, он не входит в это подмножество.
Хуже всего то, что он ' Поскольку тег предназначен для ссылки на «неизменяемый» контент, вам не следует делать в нем никаких изменений. Простого:
cvs tag -r MY_TAG -b MY_BRANCH
будет достаточно для инициализации ветки из тега ветвления.
Эти ветки должны выполняться для каждого цикла UAT (пользовательского приемочного теста), начиная с вашей текущей разработки. Затем вы можете:
- либо попытаться объединить содержимое предыдущей ветки, выполненной для предыдущей демонстрации для клиента, в эту новую ветку
- , либо напрямую повторно реализовать настройки в новой ветке.
- оставить эти ветки как они есть, когда цикл UAT завершен. Они не будут изменены, но могут служить справочными материалами для следующих веток следующего цикла.
Попытаться сохранить ветку с настройкой будет сложнее, чем воссоздать указанные эволюции в новой ветке: