Hallo Cheatah,
Wir arbeiten glücklich[tm] mit SVN. Nun haben wir dort ein Projekt (nennen wir es "Projekt F") abgelegt, welches von anderen Projekten benutzt werden soll. An Projekt F wird kontinuierlich weiter gearbeitet, während andere die Projekte X, Y und Z beackern, in welchen F benutzt wird. (Die Dateien von F liegen mitten in denen des jeweiligen anderen Projektes, teilweise auch in Unterverzeichnissen.)
Bei X, Y und Z handelt es sich aber nicht um eine Art Branches von Z?
Wenn das der Fall ist, könnte eine Lösung sein, einfach im selben Repository Branches anzulegen.
Nun kann es natürlich sein, dass es von der Struktur her Branches sind, von der organisatorischen Seite her allerdings unabhängige Projekte und daher ein gemeinsames Repository problematisch oder unmöglich ist.
In dem Fall seid ihr an die Grenzen von SVN gelangt. Ihr bräuchtet private Branches (also Branches eines Repositories A in einem Repository B). So etwas geht mit verteilten Versionsverwaltungssystemen (Mercurial, GIT, ...). Oft können diese auch zumindest Revisionen aus SVN holen oder sogar Änderungen zurückspielen (was euch aber ja nicht interessiert).
Es wäre also vielleicht möglich, X, Y und Z mit einem verteilten VCS zu verwalten. (Man kann natürlich auch gleich wechseln, aber das ist natürlich ungleich aufwändiger und evtl. gibt es da wieder unüberwindbare organisatorische Hürden).
Handelt es sich hingegen nicht um Branches, würde ich sagen, ihr habt eine kaputte Architektur.
Die Sourcen verschiedener Projekte sollten sauber getrennt sein. Selbst wenn es aus irgend welchen technischen Gründen notwendig ist, diese zusammen zu führen, sollte das besser durch einen (automatisierten) Buildprozess passieren aber nicht schon im Repository.
Grüße
Daniel