Subversion: Shared files, Trac

Wir möchten in der Firma ein schon längst überfälliges Version Control System einführen, und unsere Wahl ist hier auf Subversion gefallen.

Wir evaluieren gerade und es gefällt uns sehr gut, aber jetzt bin ich auf ein Problem gestoßen, von dem ich nicht weiß wie ich es angehen soll.

Folgendes Szenario:
Wir haben mehrere Projekte, die die selben (eigens verwalteten) Softwaremodule benutzen. Diese werden momentan noch aus dem zentralen Modul-Verzeichnis in ein Unterverzeichnis im Projekt kopiert (NICHT im Subversion, das ist ja noch nicht aktiv), was natürlich nicht gerade optimal ist - wir wollen von diesem Pfusch schon länger weg.

Meine Frage ist nun:
Kann man Subversion irgendwie sagen, dass ein File in einem anderen Verzeichnis zu einem Projekt gehört? Und zwar so, dass Subversion bei einer Änderung am File den Commit bzw. das Check Out richtig macht, und das verlinkte File immer aktuell hält?


Außerdem würden wir gerne noch einen Bugtracker à la Trac einsetzen.
Problematisch bei Trac ist, dass das Repository am gleichen Server wie Trac selbst liegen muss (laut FAQ). Der Repo-Server ist bei uns im lokalen LAN, den Webserver (mit Trac) hätten wir aber gerne in der DMZ.
Kennt jemand eine Alternative zu Trac, mit der das möglich wäre?
Im Notfall sparen wir uns halt den Zugriff aufs Repo - das wichtigste sind immer noch das Bugtracking und das Wiki.

Tia für jegliche Hilfe

Danke, auf die hook-scripts hätt ich sicher vergessen.
Ich hab aber eine schöne Methode gefunden, die - wenn ichs richtig verstehe - genau das macht, was ich will: Abholen des externen Moduls aus dem Verzeichnis beim Check Out, und Update des Moduls im externen Verzeichnis beim Commit. Voraussetzung ist, dass das Ganze im selben Repo stattfindet.

svn:externals heißt die Lösung: http://tortoisesvn.net/docs/release...n-projects.html

Müssen wir mal testen, aber das schaut schon sehr gut aus

Zitat von DJ_Cyberdance

Subversion kann scheinbar keine einzelnen Dateien verwalten, sondern nur Verzeichnisse

Wenn du nur einzelne Dateien versionieren willst, dann reicht CVS sicher aus.
Normalerweise besteht Sourcecode aber aus vielen Files und evtl. auch vielen Directories, und da ist es schon sinnvoll, wenn das VCS diese als zusammengehörig betrachtet. Nur ein Beispiel: CVS kann keine Dateien umbenennen - du kannst nur die alte löschen und die neue einchecken, die History ist damit unterbrochen.

Was bei Subversion noch alles anders oder besser ist als bei CVS, steht hier:
http://subversion.tigris.org/features.html

Zitat von Ringding

Heutzutage mit svn anzufangen ist eh schon eine ziemliche Kasteiung, wo es doch so nette Dinge wie Mercurial gibt, aber heute noch mit CVS zu arbeiten ist wahrlich heroisch! Wobei Mercurial durchaus einige svn-Features nicht unterstützt, die mich aber überhaupt nicht interessieren, z.B. Zugangsbeschränkungen auf Verzeichnisse.

Also ganz ehrlich, ich hab mir die genannten und natürlich SVN jetzt mal angesehen und bis Dato gibt es keinen nennenswerten Grund, nicht mit CVS zu arbeiten. Mir sind die Vorteile modernerer VCS-Software durchaus bewußt, aber die sind allgemein und für gewisse Projekte sicher von Vorteil, aber CVS ist genau auf das Minimum beschränkt, das ich brauche.

Das mit dem mehr Tippen in svn kann ich nur wiederholen, während cvs nur ein simples "cvs up filename" braucht, muß man in svn wohl "svn co file:///path/to/repository ..." tippen - für ein file egal, für längeres arbeiten IMO nervig, insbesondere wenns um mehrere verzeichnisse geht. dafür scheint svn nicht gemacht zu sein...

Danke euch auf jeden Fall für die Infos!

andere frage. wieso möcht ich mir cvs und svn eigentlich ohne tool unterstützung antun?

klar funktionierts, lustig ist aber anders.

Blöd dass ich nicht so viel Zeit hab...

Wenn du im SVN "Module" aus einem anderen Repository(!) brauchst, macht man das über das Spezial-Attribut svn:externals (siehe: http://svnbook.red-bean.com/en/1.5/....externals.html), das kannst du mit dem Befehl propset (siehe auch propget) machen, oder mit dem Client deiner Wahl. Dazu müssten natürlich die Module auch in ein SVN repo, was aber sowieso sinnvoll wäre wenn das einheitlich verwaltet wäre.
Um da dann zB. nur stable revisions zu verwenden kann man auch eine revision im Pfad angeben.

UPDATES macht man in SVN per "svn update", dazu muss man mit der commandline nur im richtigen ordner sein, aber ich kann mir auch kaum vorstellen dass das im CVS anders funktioniert, für einen richtigen checkout braucht man natürlich schon den Repository-Pfad. Einzelne Files werden wahrscheinlich ein Problem mit der lokalen Working-Copy machen - weil wo hin mit den svn-orga-files, einzelne Files exporten geht aber ziemlich sicher (svn export)

SVN alleine unterstützt auch keine verzeichnisspezifischen Rechte, dazu braucht man eine Extension, welche mich schon einige Nächte gekostet hat bis sie endlich funktioniert hat

Mit HG muss ich mich mal spielen, kA wie gut/schlecht das is, aber ich nehm sehr stark an dass es auch dafür eine extension zwecks Rechte auf Verzeichnissen geben wird, andererseits glaub ich eher nicht so richtig dass es da noch wirklich viel zu erfinden gibt auf dem Gebiet, weniger neues, mehr Stabilität wär angesagt. Was wär denn das "tolle neue feature" warum ich auf HG umsteigen würde?

Wegen Commandline:
Unter Windows hab ich extrem gute Erfahrung mit Tortoise SVN gemacht; Für diverse IDEs gibts aber auch sehr praktische Plugins (zB. für Eclipse das ist ziemlich gut, und ignored automatisch files die im svn nichts zu suchen haben, wie zB. test-compiles)
Am mac... Naja, es gibt SCPlugin, welches so ähnlich funktionieren würde wie Tortoise, aber bei weitem nicht an die Usability rankommt.
Linux hab ich bis jetzt nur die Commandline verwendet

um mal den guten Linus Torvalds sinngemäß zu Quoten: merge with cvs / svn is a huge pain in the ass (and the developers of svn are morons ).

die probleme, die du beim mergen via tortoise svn hast, hast mit allem andern auch...