Лучшие практики для единственного большого проекта SVN
Из того, что я понимаю, вы не смотрите на нечеткое совпадение. (Потому что вы не проголосовали против других ответов). Если вы просто пытаетесь оценить то, что вы указали в своем запросе, вот код. Я поставил некоторые дополнительные условия, где я напечатал соответствующее сообщение. Не стесняйтесь удалять их.
def wordmatch(baseword, wordtoMatch, lengthOfMatch):
lis_of_baseword = list(baseword.lower())
lis_of_wordtoMatch = list(wordtoMatch.lower())
sum = 0
for index_i, i in enumerate(lis_of_wordtoMatch):
for index_j, j in enumerate(lis_of_baseword):
if i in lis_of_baseword:
if i == j and index_i <= index_j:
sum = sum + 1
break
else:
pass
else:
print("word to match has characters which are not in baseword")
return 0
if sum >= lengthOfMatch and len(wordtoMatch) <= len(baseword):
return 1
elif sum >= lengthOfMatch and len(wordtoMatch) > len(baseword):
print("word to match has no of characters more than that of baseword")
return 0
else:
return 0
base = "Nick"
tomatch = ["Nick", "ick", "nik", "nic", "nck", "nickey","njick","nickk","nickn"]
wordlength_match = 3 # this says how many words to match in the base word. In your case, its 3
for t_word in tomatch:
print(wordmatch(base,t_word,wordlength_match))
результат выглядит следующим образом
1
1
1
1
1
word to match has characters which are not in baseword
0
word to match has characters which are not in baseword
0
word to match has no of characters more than that of baseword
0
word to match has no of characters more than that of baseword
0
Дайте мне знать, послужило ли это вашей цели.
6 ответов
Во-первых, обновите до SVN 1.6 как на клиенте, так и на сервере. В примечаниях к последнего выпуска упоминается ускорение работы с большими файлами (r36389).
Во-вторых, это может быть не слишком уместно для вас, если у вас есть весь проект в вашей рабочей копии, но используйте разреженные каталоги . Мы делаем это для нашего большого репо, первое, что делает клиент, это извлекает только каталог верхнего уровня, затем, чтобы получить больше данных, использует браузер репо, чтобы перейти к нужному каталогу и «обновить его до этой ревизии». Это прекрасно работает на TortoiseSVN. 1.6 также имеет опцию «уменьшить глубину» для удаления каталогов, с которыми вам больше не нужно работать.
Если это не для вас, вы все равно можете обновить некоторые части рабочей копии. Обновление, как правило, происходит медленнее, чем больше у вас файлов (то есть в Windows NTFS кажется особенно плохой со стратегией блокировки, используемой для обновления. Берт Хуйбен заметил это и предложил исправление - TBA с выпуском 1.7 , но вы можете перестроить свой текущий код с помощью его «быстрого исправления».
Альтернативой может быть изменение вашей файловой системы, если вы можете переформатировать, вы можете попробовать драйвер ext2 IFS , но я уверен, что вы будете осторожны с этим!
Последний вариант - отключите антивирусный сканер для .svn-файлов, а также для репозитория на сервере. Если вы используете Apache на сервере, удостоверьтесь, что у вас есть живые сообщения в течение короткого времени (чтобы предотвратить повторную аутентификацию). Также отключите индексирование в каталогах вашей рабочей копии и теневой копии тоже. (последнее не очень помогает, но вы можете увидеть лучшее улучшение, которое я сделал, отключив AV на сервере, хотя мой ответ SVN увеличился в 10 раз).
Чтобы справиться с громоздким размером, я бы подумал разбить двоичные данные на другую ветвь (или даже полностью удалить ее) храниться в другом месте), отдельно от кода. Это должно, по крайней мере, ускорить процесс, особенно если данные меняются не часто.
Я понимаю, что людям нужно иметь централизованное расположение для своих инструментов, данных и библиотек, но это просто не очень хорошо, когда они есть. свалка.
I'll keep it brief:
- Upgrade to the latest version (1.6.x). 1.5.x had speed optimizations as well.
- Make sure everyone is using the same version of TortoiseSVN which is built against the exact version of the server. We had many problems with guys updating on whim and then getting weird problems.
- Externals work between servers, repositories and folders on the same repo. So you can move the binaries to another repo/server altogether and just link to them with externals.
- Restructure the folders so that you can sparse checkout the project and still be able to work productively. Basically everyone checks out tops folder + children only then selectively "update to revision" the folders they need to checkout fully.
- Create scripts that export, build then commit (or prompt to commit). I have such scripts for my use. Before committing, I run the script and it exports my wc and then builds. NOTE: This will copy the full wc! So this is useful with sparse checkouts where the data size is small(er).
- Consider moving the binaries off of the repo (I don't recommend this, but it might be the sanest solution to get productivity up again).
- Remember, exporting doesn't create a wc, which means you save 50% disk space compared to checkouts. So if you restructure such that binaries and infrequently updated items may be exported instead of checkout, it would encourage more people to "get the full thing" and not try to skim some of it.
У нас есть два репозитория, один для нашего кода (часто изменяется) и другой для наших двоичных данных (очень большие, изменения не часто). Иногда это больно, но стоит больше скорости при работе с кодом.
У нас также есть сценарий Ruby, который мы называем «ежедневное обновление», проверенный в нашем хранилище, который мы запускаем на всех наших компьютерах разработки через Windows Запланированное задание, рано каждое утро. Он обновляет обе проверки до последней версии, а затем строит все локально, поэтому мы готовы к работе, как только мы приедем утром.
Есть некоторые ошибки, которые мы еще не сгладили - например, когда запускаются наши автоматические тесты, в настоящее время существует задержка между проверкой кода и проверкой данных, поэтому, когда мы фиксируем изменения в обоих репозиториях, Сервер CI иногда получает старый код и новые данные, что приводит к ошибкам тестирования.
Когда мы фиксируем изменения в хранилище данных, мы обычно просто говорим всем остальным, что им нужно обновить (мы все сидим в одной комнате). В противном случае мы обычно не обновляем данные вручную; мы просто позволяем скрипту ежедневного обновления сохранять его свежим.
Можно ли разбить проект на более мелкие проекты, которые можно подключить через какую-то систему плагинов?
Я был менеджером СКМ в аналогичной ситуации. У нас был проект с более чем 200K файлами (в основном код), у которого были некоторые из тех же проблем. Нашим решением было разделить репозиторий на две версии. Одна версия является версией для разработки, а другая - производственной версией. Мы залили версию для разработки последней и самой известной рабочей копией всего кода. Разработчики начали с этого и внесли изменения, зарегистрировались и вышли и т. Д. Как только они почувствовали, что все стало стабильно, администратор (в нашем случае менеджер сборки) объединил код и выполнил тестовую сборку, чтобы убедиться, что все работает правильно. Если все прошло, это было хорошо. Если этого не произойдет, администратор сборки выследит разработчика и сурово накажет его. У нас были одни и те же проблемы в начале, где "