SVN Checkout a single directory

Вот моя дилемма:

Я хочу получить один каталог (назовем его A) из SVN, но иметь возможность сделать и svn up A из родительского каталога на компьютере извлечен на.

i.g. Я нахожусь в ~/coolstuff я хочу сделать проверку A и поместить его в ~/coolstuff, и когда я нахожусь в ~/coolstuff я хочу выпустить svn и обновить его A.

Вот хитрость, чтобы сделать это в базовом сценарии: В родительском каталоге SVN A - Z. Я выполняю проверку SVN Z в ~/coolstuff. Затем mv ~/coolstuff/Z/.svn в ~/coolstuff. Walla я могу сделать svn вверх, и это работает, и он вытянет вниз A внутри ~/coolstuff.

Мой сценарий: Я делаю то же самое выше, за исключением того, что проблема заключается в том, что Z не только имеет ребенка A, но и имеет ребенка B. Так svn вверх в ~/coolstuff будет вниз A и B. Но я не хочу, чтобы B был вниз.

Вот решение: Я редактирую ~/coolstuff/.svn/entries и удалил ссылку на B. Теперь svn не видит B, только A.

Решение выше все еще тянет вниз A, когда я делаю первый заказ, я не хочу делать это. Это также кажется очень хак-иш. Есть ли лучший/более чистый способ сделать это, и, надеюсь, не придется опускать «B» вообще?

-121--1254878-

Если программирование без (в основном без условий) [закрыто] У меня был коллега, который сказал мне, что когда-то работал в компании, у которой была политика никогда не иметь условий (операторы «if» и «switch») в коде и что они допускают все решения в...

У меня был коллега, который сказал мне, что он когда-то работал в компании, у которой в качестве политики никогда не было условий («если» и «переключить») в коде, и что они позволяют принимать все решения в коде, используя полиморфизм и (я предполагаю) некоторые другие принципы ОО.

Я типа понимаю рассуждения, лежащие в основе этого, о том, что код более СУХОЙ и проще в обновлении, но я ищу более глубокое объяснение этой концепции. Или, возможно, это часть более общего подхода к дизайну.

Если кто-то имеет какие-либо ресурсы для этого или будет готов объяснить или даже иметь некоторые другие термины, связанные с этим, я могу использовать, чтобы найти больше ответов, я был бы очень обязан.

Я нашел один вопрос на SO , который был своего рода связан, но я не знаком с C++, поэтому я не понимаю слишком много ответов там.

(Я не гуру OO btw, но я могу управлять)

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

Обновление: Я попрошу своего коллегу предоставить дополнительную информацию о том, что именно он имел в виду.

Обновление 2015: После нескольких лет опыта программирования я вижу, что цель этой политики, вероятно, была в том, чтобы помешать программистам добавлять функциональность в случайном порядке, просто добавляя условия (если заявления) в определенных местах. Лучший способ расширения программного обеспечения - использовать «Принцип открытия/закрытия» , где программное обеспечение расширяется с использованием наследования и полиморфизма. Я сильно сомневаюсь, была ли политика сверхстрогой на всех условиях, так как это довольно трудно пройти полностью без них.

65
задан Community 23 May 2017 в 11:54
поделиться