Я раньше использовал такой подход:
в uses проекта подключается минимум модулей, в директории проекта подключаю папки, где лежат исходники этого проекта.

Часто вижу проекты организованные подругому: в uses проекта подключены все его модули с путями относительно проекта, 
соответственно в директориях проекта - подключается только third-party библиотеки

Вопрос: Какой подход правильней, их плюсы и минусы.

Сам пока думаю так
1 способ:
+ Легко реструктурирую проект через Explore/Windows Commander и через SVN, в проекте достаточно подредактировать пути.
- Криво работают анализаторы кода, рефакторинг не хотят кушать модули неподключенные к проекту, 
в общем тупит куча разных автоматических инструментов (кот пользуюсь не часто, но дискомфорт от этого есть)

2 способ
+ могу изменить структуру проекта в дереве прямо в delphi (не знаю как отразится на svn)
+ наверное Compile работает надежнее (меньше вероятности, что он забудет перекомпилить изменившийся модуль)

Кто как делает и почему?

И вопрос по организации в связке с SVN:
каждый члена команды в настройках проекта забивают свой Run-Parameters. Естественно постоянно по случайности коммитят проект и у всех остальных
их настройка слетает. как от этого избавиться?

  Каждый пусть создаст новый проект в формате <имя проекта>.<имя пользователя> и закомитит его в SVN. И пусть каждый юзает только свой проект. Конечно же возникнут проблемы с тем, чтобы каждый добавлял новые файлы в свой проект. Но тут уж ничего не сделаешь. VC++ поступает хитрее. Она для каждого пользователя создает файл персональных настроек, при том, что файл проекта общий. 

Alexeis, это не выход. Сейчас просто слетают параметры проекта, это относительно фигня, а так время от времени у соседа вообще проект после обновления будет отказываться компилиться.

Правильно - комбинация этих двух.

Указать модуль без пути + вписать его папку в поиск - это делается для библиотек (FastMM, JCL, etc). Потому что на разных машинах библиотеки стоят в разных путях. Часто относительный путь к ним записать нельзя. Кроме того, перенося проект на другую машину, библиотеки не переносятся вместе с проектом. Если надо - их ставят отдельно.

Все прочие файлы - относятся конкретно к этому проекту. Они хранятся в его папке или подпапках. Иногда - в родительской папке (если проект входит в группу проектов и мы подключаем общие файлы). Тут логично указать относительный путь, ибо вписывать папки в настройки - явный overkill. Да и это создаёт сложности с переносом проекта на другую машину.

CodeMonkey,  я в пути проекта всегда впиваю относительные пути, вопрос именно в том,
нужно ли подключать все модули проекта в список uses самого проекта. Для компиляции они там не нужны. Тогда для чего это делают?

А не так тогда понял. 

В uses головного проекта вписываются с путём те файлы, которые считаются частью проекта. Даже если они не нужны там для компиляции. Если файл оттуда убрать (указав его только во вложенном модуле) - файл не будет считаться принадлежащим проекту. Это будет как бы часть библиотеки.

Понятно, тогда что стоит за тем. что "файл считается принадлежащим проекту" и что оно дает мне.
Например, как я уже писал получается гемор  с тем, чтобы перетащить файл из папки в папку:
 сейчас я делаю команду svn move и всё, а так мне придется подправлять файл проекта.
Какие плюсы этого подхода?

Допустим есть Ф-ция TestFunc, которая принимает один параметр следующего содержания "Тестова ф-ция" и была дана команда, поменять ее содержимое на "Тестовая ф-ция 2", мы в Делфях жмем Crtl+F и появляется окно поиска. Так вот если мы туда введем название ф-ции, то она найдет ф-цию в тех модулях, которые считаются "принадлежащим проекту". А потом будем думать почему программа передает в ф-цию то "Тестова ф-ция" то "Тестова ф-ция 2" .

Или второй пример. Есть переменная/ф-ция/форма и т.д. Хотелось изучить ее поведение, то беж где она вызывается или кем используется, чтобы потом ее переделать или правильно использовать. Но так как поиск нашел все это в файлах "принадлежащих проекту", то мы можем упустить главное, допустим в том модуле, которую поисковик Делфи не нашел, переменная может сбрасываться в другое значение, что мы не ожидали

Добавлено через 2 минуты и 50 секунд

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

модуль обяъвлен в dpr, значит "модуль принадлежит проекту", "модуль принадлежит проекту" - значит модуль объявлен в dpr... Великолепный пример рекурсии  



У меня весь проект хранится в одном каталоге с вложенными папками, поэтому я нажимаю Ctrl+Shift+F (который настроен на поиск в корневом каталоге проекта) и я ищу во ВСЕХ модулях моего проекта.

У вас да У других возможно нет. Допустим есть два проекта, которые используют общие модули, а их не положишь в папку одного проекта или второго (дублирование не выход)  



Та ладно Вы уже сами создали рекурсию   

Много всего по мелочи. Лениво перечислять. Менеджер проектов давно открывали?

Открывал, есть возможность перетаскивать и переименовывать файлы, при этом, как я понимаю с svn косяк будет. 
Связка TortoiseSVN + JEDI VCS Integration дает мне тоже самое, только в связке с svn к тому же.