Если вы работаете с одним рабочим пространством, вы получите три проекта, каждый из которых зеркально отображен в CVS: один - это dll, другие - это проекты, использующие dll (настроенная как зависимость проекта этих проектов от проекта dll) .
С тремя проектами я бы не стремился к рабочим наборам - они хороши для управления многими проектами в одном рабочем пространстве, для трех проектов я бы счел их излишними. Я обычно стремлюсь к нескольким рабочим областям вместо рабочих наборов.
Относительно следующего человека, работающего с этими проектами: Вам необходимо иметь некоторую документацию о том, как настроить ваши проекты. Вы можете сказать, что ваши файлы проекта затмения делают именно это (поскольку они определяют зависимость проекта от другого проекта), но это для машины - людям, как правило, нравятся другие средства связи.
Если вас беспокоит, что изменения в dll несовместимы с одним проектом (потому что лицо, применяющее эти изменения, не заботится о другом проекте), стремитесь к серверу сборки . Это будет создавать все проекты и зависимые проекты всякий раз, когда что-то под управлением версий изменяется, запускать все тесты, предоставлять номер сборки и упаковывать все это готовым к использованию. Таким образом, вы можете быть уверены, что - все, что есть в вашем результате - может быть воспроизведено, потому что сервер сборки не может вносить локальные (незафиксированные) изменения в код. Кроме того, сервер сборки будет сигнализировать о сбое (либо сломанном API, либо неудачных тестах) в момент последнего коммита (ну, спустя несколько минут) и возлагает бремя исправления повреждения на тот, который вызвал повреждение.