Как я знаю, было ли ответвление уже объединено в SVN/Mercurial/Git?

Является ли Mercurial или Git более интуитивно понятным, чем SVN?

Да, очень похоже:

sjl at ecgtheow in ~/src/hg-review on webui at tip
[10] $ hg glog
@  changeset: 113:c5debb475273 Steve Losh tip webui
|  summary:   Add file folding.
|
o  changeset: 112:a3ad66636756 Steve Losh  webui
|  summary:   Show skipped-line comments.
|
o  changeset: 111:2e65351af702 Steve Losh  webui
|  summary:   Rough cut of line-level comments.
|
| o  changeset: 110:b599ca22418d Steve Losh  
|/|  summary:   Merge the bug fix.
| |
o |  changeset: 109:e2ddb8631463 Steve Losh  webui
| |  summary:   Fix the event not defined bug.
| |
| o  changeset: 108:001f5ecfd9bc Steve Losh  
|/|  summary:   Merge the webui skipped line counts -- too important to leave in the
| |             branch.
| |
o |  changeset: 107:1cc8e18b1b43 Steve Losh  webui
| |  summary:   Add skipped line counts to diffs.
| |

РЕДАКТИРОВАТЬ: Git имеет git log --graph вариант, который почти такой же, как и у Mercurial, за исключением того, что здесь нет полезного символа «вы здесь» @ .

В git вы можете использовать журнал git , чтобы спросить, включает ли одна ветвь другую:

git log topic ^master # list all commits in branch 'topic', but not in 'master'

Если ничего не возвращается, тема была объединена .

Если у вас есть версия сервера не ниже 1.5, как указано chotchki, и ваш репозиторий был создан с такой версией или обновлен, свойство svn: mergeinfo добавляется к любому каталог, в котором произошло слияние.

Допустим, вы реинтегрировали две ветви в ствол, вы можете проверить (замените на свой URL):

svn propget svn:mergeinfo svn://localhost/Test/trunk

, какие ветви были объединены и какие ревизии они изменили. Пример вывода:

/branches/dev/1:35-36
/branches/dev/2:38-39

С помощью клиента GUI, такого как TortoiseSVN, проверьте график или свойства целевого каталога в браузере репо.

В git вы можете использовать - contains для вывода списка веток, содержащих другие ветки:

git branch -a --contains feature

покажет все ветки (с -a , который включает удаленные ветки), которые объединили данную функцию.

git show-branch покажет множество деталей взаимосвязей между ветвями. Чтобы научиться эффективно читать его, потребуется немного времени, но он очень ценен и многое покажет на небольшом пространстве.

В Git вы можете использовать git branch --merged , в котором перечислены все ветки, которые доступны из данной фиксации ( < commit> по умолчанию HEAD, что означает, что git branch --merged перечислит все ветки, объединенные в текущий коммит).

Или вы можете использовать git show-branch branch1 branch2 или git log --graph --oneline branch1 branch2 , чтобы увидеть историю в графическом виде (или используйте какой-нибудь графический браузер истории, такой как gitk, QGit, Giggle, GitX и т. Д.).

Если у вас есть доступ к TortoiseSVN и репозиторий имеет версию 1.5 или новее, вы можете посмотреть на график репозитория, который он генерирует. Однако SVN в целом затрудняет отслеживание слияний.

Вы можете использовать svnmerge.py для управления ветвями. Он сообщает вам, какие ветки уже были объединены, и объединяет только новые версии.

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

Предположим, эта новая модель называется Feed, следуя шаблону полиморфной ассоциации, вы должны использовать столбцы: feedable_type и feedable_id (в отличие от предложенной вами модели имен столбцов и Associated_id)

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

• Конфиденциальность
• Follow / Subscribe
• Фильтрация
• Слияние

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

Если вы когда-либо создавали приложение для Facebook, довольно поучительно увидеть, как работает их API публикации каналов.

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

Конечно, реализация даже немного сложнее этой. Как и в случае с Facebook, у всех каналов есть одна общая точка (они исходят от людей). Итак, у каждой записи фида есть user_id (так сказать). Поскольку мы знаем, что все фиды содержат эти данные и могут отображать "

Чтобы просто посмотреть, какие ветки сливаются или нет с конкретной веткой, я нашел ответ Якуба наиболее полезным, а также соответствующую команду:

git-ветка --нетка

из git-справки:

С помощью --no-merged будут перечислены только те ветки, которые не были объединены в именованный коммит.