Как Вы структурируете свой репозиторий SVN? [закрытый]
Ваша логика предполагает, что длина a всегда является правильным количеством для условной итерации. Игровая площадка, которой @FatchulAmin поделился в комментарии к ответу @EdChan, выявила проблему, когда a больше, чем b или наоборот, вы получите ошибку «index out of range», потому что меньший срез больше не будет иметь индексов чтобы соответствовать большему. a[i].TransactionDate == b[i].TransactionDate
Для здравомыслия, в этом случае вы должны выполнить проверку, чтобы найти наименьшее число для повторения, однако это не позволит вам полностью проверить все самые большие срезы.
Я предлагаю объединить срезы, а затем найти самый большой и наименьший диапазон, чтобы зациклить, чтобы удалить то, что вы хотите от слияния. ПРИМЕЧАНИЕ: @EdChan правильно использовать одну структуру, так как они все одинаковы.
type FooBar struct {
TransactionDate string
TotalAmount string
TotalTransaction string
}
type FooBarSlice []FooBar // this is used as a receiver on func Remove
func compareReplace(a []FooBar, b []FooBar) []FooBar {
var c FooBarSlice
c = append(a, b...)
var largerSlice []FooBar
var smallerSlice []FooBar
if len(a) <= len(b) {
largerSlice = b
smallerSlice = a
} else {
largerSlice = a
smallerSlice = b
}
for _, v := range smallerSlice {
for j := 0; j < len(largerSlice); j++ {
if largerSlice[j].TransactionDate == v.TransactionDate && largerSlice[j].TotalTransaction == "0" {
c.Remove(j)
}
}
}
return c
}
Полный рабочий пример: https://play.golang.org/p/iyUYtXlDG54
5 ответов
администрация Репозитория глава книга SVN включает раздел по Планирование Вашей Организации Репозитория обрисовывающие в общих чертах различные стратегии и их импликация, особенно последствия расположения репозитория на ветвлении и слиянии .
Мы используем A, потому что другой не имел смысла нам. Обратите внимание, что "проект" относительно SVN является не обязательно единственным проектом, но может быть несколькими проектами, которые принадлежат вместе (т.е. что Вы поместили бы в Решение в Visual Studio). Таким образом, у Вас есть что-либо группировавшееся связанное. Все ответвления, теги и соединительная линия определенного проекта. Имеет смысл мне.
Группировка ответвлением/тегом вместо этого не имеет смысла мне, потому что ответвления различных проектов не имеют ничего общего, за исключением того, что они - все ответвления.
, Но в конце, люди используют оба пути. Сделайте то, что Вы любите, но когда Вы решили, попытайтесь остаться с ним :)
Как дополнение: у Нас есть отдельные репозитории на клиента, т.е. все проекты для клиента находятся в том же репозитории. Таким образом, Вы можете, например, делать резервные копии единственного клиента сразу или давать исходный код чего-либо, чем клиент владеет ему, не борясь с SVN.
Я предложил бы опцию C:
server:1080/projectA/trunk/...
branches/branch1
branches/branch2
branches/branch3
tags/tag1/...
tags/tag2/...
server:1080/projectB/trunk/...
branches/branch1
branches/branch2
branches/branch3
tags/tag1/...
tags/tag2/...
я предпочитаю разделять проекты в отдельных репозиториях. Используя svn:externals помогает управлять проектами библиотеки кода, которые являются общими для два или больше проекта приложения.
Мы используем установку B. Beause это легче к выезду/, отмечают несколько проектов сразу. В svn 1.5 это возможно через редкий контроль, но не операцию с одним щелчком. Вы хотите использовать установку B, если некоторые проекты скрыли промежуток зависимостей.
Мы используем
/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags
, О котором я начинаю сожалеть. Это должно быть более плоско. Это было бы лучше.
/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags
, Почему? Продукты (компоненты, законченное программное обеспечение) длятся навсегда. Проекты приходят и уходят. В прошлом году существует всего одна проектная группа, создающая продукт QUUX. В следующем году та команда рассеивается, и один или два человека поддерживают QUUX. В следующем году будет два больших проекта расширения QUUX.
, Учитывая, что временная шкала, QUUX должен появиться в трех репозиториях проекта? Нет, QUUX независим от какого-то конкретного проекта. Это верно, что проекты действительно имеют продукты работы (документы, отставания, и т.д.), которые являются частью получения сделанной работы, но не являются фактической целью работы. Следовательно "projectX" репозитории для того материала - материал, о котором никто не будет заботиться после проекта, сделаны.
я работал над одним продуктом, который имел три команды. Большая проблема с координацией работы, потому что каждый проект справился, это - репозиторий независимо. Были выпуски межкоманды и координация межкоманды. В затем конце дня это предполагалось к одной части программного обеспечения. Однако как можно предположить, это были три части программного обеспечения со странными перекрытиями и дублированием.