Определение & ldquo; downstream & rdquo; и & ldquo; upstream & rdquo;
похоже, что вам, возможно, придется сделать что-то вроде этого
PackageInfo info = getPackageManager().getPackageInfo(PACKAGE_NAME, 0);
int currentVersion = info.versionCode;
this.versionName = info.versionName;
SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(this);
int lastVersion = prefs.getInt("version_code", 0);
if (currentVersion > lastVersion) {
prefs.edit().putInt("version_code", currentVersion).commit();
// do the activity that u would like to do once here.
}
Вы можете делать это каждый раз, чтобы проверить, обновлено ли приложение, поэтому он запускается только один раз для обновления приложения
3 ответа
С точки зрения контроля исходных текстов, вы "вниз по течению", когда копируете (клонируете, проверяете и т.д.) из хранилища. Информация течет "вниз по течению" к вам.
Когда вы вносите изменения, вы обычно хотите отправить их обратно "вверх по течению", чтобы они попали в репозиторий, чтобы все, кто берет из того же источника, работали со всеми теми же изменениями. Это в основном социальный вопрос о том, как каждый может координировать свою работу, а не техническое требование контроля исходных текстов. Вы хотите, чтобы ваши изменения попадали в основной проект, чтобы вы не отслеживали расходящиеся линии развития.
Иногда вы можете прочитать о менеджерах пакетов или релизов (людях, а не инструментах), которые говорят о передаче изменений "вверх по течению". Обычно это означает, что им пришлось корректировать исходные тексты, чтобы они могли создать пакет для своей системы. Они не хотят продолжать вносить эти изменения, поэтому если они отправят их "вверх по течению" к исходному источнику, им не придется сталкиваться с той же проблемой в следующем выпуске.
Это немного неофициальной терминологии.
Что касается Git, все остальные репозитории - просто удаленные.
В общем, апстрим - это то место, откуда вы клонировали (источник). Downstream - это любой проект, который объединяет вашу работу с другими работами.
Условия не ограничиваются репозиториями Git.
Например, Ubuntu является производным от Debian, поэтому Debian является апстримом для Ubuntu.
Когда вы читаете в git tag man-страницу :
Один из важных аспектов git - это то, что он распределяется, а распространение в значительной степени означает отсутствие присущих ему «восходящего» или «нисходящего» в системе.
, что просто означает, что нет абсолютного восходящего репо или нисходящего репо.
Эти понятия всегда относительны между двумя репозиториями и зависят от способа передачи данных:
Если yourRepo объявил otherRepo как удаленный, то :
- you извлекают из восходящего потока «otherRepo» («otherRepo» - это «восходящий поток от вас», а вы - «нижестоящий для otherRepo»).
- вы отправляете в восходящий поток («otherRepo» по-прежнему «восходящий поток», куда теперь возвращается информация).
Обратите внимание на «от» и «для»: вы не просто «ниже по течению», вы «ниже по течению от / для », отсюда относительный аспект.
Изюминка DVCS (распределенной системы контроля версий) заключается в следующем: вы не знаете, что на самом деле представляет собой нисходящий поток, помимо вашего собственного репо относительно удаленных репозиториев, которые вы объявили.
- вы знаете, что такое восходящий поток (репозитории, из которых вы извлекаете или отправляете)
- вы не знаете, из чего состоит нисходящий поток (другие репозитории, извлекающие или отправляющие ваше репо ) .
В основном:
В терминах « поток данных », ваше репо находится внизу («ниже по течению») потока, исходящего из вышестоящих репозиториев («извлечение из») и возвращающегося назад. в (те же или другие) вышестоящие репозитории ("push to").
Вы можете увидеть иллюстрацию на git-rebase странице руководства с параграфом «ВОССТАНОВЛЕНИЕ ИЗ UPSTREAM REBASE»:
Это означает, что вы извлекаете из «восходящего потока» репо, в котором произошла перебазировка , и вы (репо «ниже по течению») застряли с последствиями (множество повторяющихся коммитов, потому что ветка, перебазированная вверх по течению, воссоздала коммиты той же ветки, что и у вас локально).
Это плохо, потому что для одного «восходящего» репо может быть много нисходящих репозиториев (т. Е. Репо, извлекаемых из восходящего репо с перебазированной ветвью), и все они потенциально могут иметь дело с повторяющиеся коммиты.
Опять же, по аналогии с «потоком данных» в DVCS одна неверная команда «восходящий поток» может иметь « эффект пульсации » в нисходящем направлении.
Примечание: это не ограничивается данными.
Это также относится к параметрам , поскольку команды git (например, «фарфоровые») часто вызывают внутри себя другие команды git («сантехнические»). См. rev-parse страницу руководства :
Многие команды git porcelainish принимают смесь флагов (т.е. параметров, начинающихся с тире '
-') и параметров, предназначенных для основная командаgit rev-list, которую они используют внутри, и флаги и параметры для других команд, которые они используют ниже по течению отgit rev-list. Эта команда используется, чтобы различать их.