Verständnisfrage bei der Einrichtung von subversion

Hobbes

Aktives Mitglied
Hallo zusammen,

ich versuche gerade, für meine Projekte subversion einzurichten. Dabei habe ich eine Verständnisfrage.

In meinem Eclipse-Workspace habe ich 3 Java-Projekte. Diese sind unabhängig voneinander.

Was sind die äquivalenten Teile im subversion?

Workspace <=> Repository
oder
Java-Projekt <=> Repository?

Oder anders gefragt: Pro Workspace ein Repository? Oder pro Java-Projekt ein Repository? Oder ist das vollkommen beliebig?

Bei einem alles umfassenden Repository würde ich mir folgende Verzeichnisstruktur vorstellen:

repository/projekt1
repository/projekt1/trunk
repository/projekt1/tag
repository/projekt1/branch

repository/projekt2
repository/projekt2/trunk
repository/projekt2/tag
repository/projekt2/branch

usw.
 

Hobbes

Aktives Mitglied
Danke für die Antwort. Inzwischen konnte ich ein bißchen rumspielen und beide Varianten ausprobieren.

So spontan gefällt mir ein gemeinsames Repository für alle Projekte besser. Dann muss ich mir nur eine Repository-Adresse merken und kann dann besser navigieren.

Allerdings habe ich noch keine Möglichkeit gefunden, innerhalb des Repositorys ein komplettes Projekt zu löschen, also bei

Code:
myRepository/projekt2
myRepository/projekt2/trunk
myRepository/projekt2/trunk/src
[...]
myRepository/projekt2/tag
myRepository/projekt2/branch

den Ordner projekt2 inklusive aller Unterordner. Oder geht das nicht wegen der gemeinsamen Revisionsnummer?

Installiert habe ich Collabnet subversion edge und Eclipse mit subversive.
 
T

TimUK

Gast
Jupp, wenn du keine riesigen Projekte hast und noch am Anfang deiner SVN-Erfahrungen stehst, ist "ein Repository pro Projekt" eher Overkill. Ich würde zum Lernen eher vorschlagen:

- ein Produktiv-Repo, in dem du nach und nach deine Projekte eincheckst
- ein Test-Repo, in dem du nach Lust und Laune rumspielen kannst

Zu deiner Frage: Im Prinzip brauchst du bloß im Repository das entsprechende Projekt-Verzeichnis zu löschen. Siehe svn delete
 

mvitz

Top Contributor
Naja, bei mehreren gehts ja eigentlich auch, wenn du die alle im selben Ordner hast, dann musst du ja praktisch nur an den Ordner den Projektnamen anhängen.

z.B.
Code:
C:\SVN\
+- projekt1
+- projekt2
\- projekt3
 

Hobbes

Aktives Mitglied
Danke euch beiden. Das Löschen funktioniert jetzt auch.

Ich habe jetzt erst mal alles notwendige, um ein bißchen rumzuspielen :)
 

reibi

Top Contributor
Geht beides und ist Geschmackssache. Ich persönlich mag 1 Repository pro Projekt.

Hi

Ich persönlich hab überhaupt nur ein Repository in meinem eigenen Netzwerk.
Bei einer Firma (Firmennetzwerk) gibts auch meistens nur ein SVN-Repository (natürlich abhängig von der Grösse der Firma - dicke Dinger wie Oracle oder IBM haben bestimmt 2 SVN-Repos ;-) )

Alle meine Projekte hab ich in MEINEM EINZIGEN SVN-Repo gehostet.
Für meine eigenen Projekte würde es z.B. überhaupt keinen Sinn machen 2 REPOs zu haben.

Wenn ich mir aber zB ein Projekt von SourceForge runterladen will um es zu verändern, dann hab ich natürlich ein 2tes SVN-REPO. Nämlich das REPO zu welchem das Projekt gehört.

Bei einem alles umfassenden Repository würde ich mir folgende Verzeichnisstruktur vorstellen:

repository/projekt1
repository/projekt1/trunk
repository/projekt1/tag
repository/projekt1/branch

repository/projekt2
repository/projekt2/trunk
repository/projekt2/tag
repository/projekt2/branch

Genau so ;-)

Gruss
 

mvitz

Top Contributor
Hi

Ich persönlich hab überhaupt nur ein Repository in meinem eigenen Netzwerk.
Bei einer Firma (Firmennetzwerk) gibts auch meistens nur ein SVN-Repository (natürlich abhängig von der Grösse der Firma - dicke Dinger wie Oracle oder IBM haben bestimmt 2 SVN-Repos ;-) )

Alle meine Projekte hab ich in MEINEM EINZIGEN SVN-Repo gehostet.
Für meine eigenen Projekte würde es z.B. überhaupt keinen Sinn machen 2 REPOs zu haben.

Wenn ich mir aber zB ein Projekt von SourceForge runterladen will um es zu verändern, dann hab ich natürlich ein 2tes SVN-REPO. Nämlich das REPO zu welchem das Projekt gehört.



Genau so ;-)

Gruss

Hi,

also ich kenne eben genau das Gegenteil, wir haben in der Firma für jedes Projekt/Produkt ein SVN Repository. Ähnlich sieht es auch für jedes Opensource Projekt aus (es gibt nicht ein Apache SVN Repository, sondern für jedes Apache Projekt ein eigenes).
Wenn du dir ein Projekt von SourceForge runterlädst, hast du kein Repository, sondern eine Working Copy des Repositories (das ist ein Unterschied!).

Ob man nun ein Repository oder mehrere hat, macht beides gleich viel Sinn, es heißt ja nicht, dass du mehr als einen Server laufen lassen musst, selbst svnserve kann mehrere Repositories gleichzeitig verwalten.

Edit: Ein Vorteil von 1:1 Repository:projekt ist übrigens, dass man jedes Repository einzeln backupen und auch wieder einspielen kann. Wohingegen, ein einspielen eines Backups bei mehreren Projekten in einem Repository direkt alle Projekte betrifft.
 
M

maki

Gast
(es gibt nicht ein Apache SVN Repository, sondern für jedes Apache Projekt ein eigenes).
Wirklich? Seit wann?
Habe mich früher selber darüber gewundert dass die alles in ein einziges Repo klatschen, mittlerweile mache ich das auch so.

Edit: Ein Vorteil von 1:1 Repository:projekt ist übrigens, dass man jedes Repository einzeln backupen und auch wieder einspielen kann. Wohingegen, ein einspielen eines Backups bei mehreren Projekten in einem Repository direkt alle Projekte betrifft.
Die Nachteile sind aber auch klar: Der Administrationsaufwand steigt mit jedem Repo an, das war der Grund warum ich nur noch ein einziges Repo nutze, man stelle sich vor, beim Update der Repos (zB. von 1.4 auf 1.5 oder 1.6) muss man das für jedes Repo einzeln machen.
Abgesehen davon kann man recht gut steuern welche Teile eines Backups wiedereingespielt werden sollen bei SVN, daher ist das imho kein Problem.

Naja, man kann beides machen, ime hat ein einziges Repo aber mehr Vorteile.
 

mvitz

Top Contributor
Ah, danke ich war in der Tat immer davon ausgegangen, dass jedes Apache Projekt sein eigenes Repo hat.

Dann entschuldigt mein Unwissen (das ich auch noch verteidigt hab, peinlich)!
 

TheDarkRose

Gesperrter Benutzer
Also ich bin auch eher der Anhänger von je ein Repo (SVN, Git, egal welches), pro Projekt/Produkt. Erstens sind da die Revions strikt getrennt, zweitens kann man jedes Projekt schön und individuell an die jeweiligen Bedürfnisse anpassen und drittens muss nicht jeder sich gleich ne mega Working Copy/Repo Clone von zig Projekten runterladen, wenn er nur eines braucht (ja ich weiß, man kann den jeweiligen Pfad oder so angeben, aber dies geht an einigen Entwicklern immer vorbei ^^). Und vor allwiderkehrende Aufgaben wie Erstellung, etc. wird halt einfach mal ein kleines Bash Skript geschrieben, und schon ist ein Repo fertig eingerichtet, Berechtigungen konfiguriert und im Apache oder was weiß ich freigegeben :)
 

mvitz

Top Contributor
Ja, bei GIT bleibt einem ja auch eigentlich nichts übrig, da man ja immer "das ganze" Repository clont. Bei Subversion funktioniert so ein "partieller" Checkout ja sehr gut. Hat wohl beides vor und Nachteile. Bei einem Repository z.B. hat eine Änderung (z.B. SVN Version) natürlich dann acuh immer globale Auswirkungen auf alle Projekte.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
C Eclipse Verständnisfrage Eclipse+Maven+Resources IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 7
C Eclipse Verständnisfrage Eclipse+Maven+Dependencies IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 8
FINF_AW_Alex (SVN) Subversion Referenz lösen IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 1
M Subversion SSO unter Linux? IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 4
H Upgrade von subversion 1.6 auf 1.7 IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 7
B netbeans subversion lokal einrichten IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 3
H Projekt-Einstellungen von Eclipse mit subversion verwalten IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 9
K Subversion - Fehleranzeige fehlt IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 6
M IDEA IntelliJ Subversion connection problem IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 3
T Subversion-Kuddelmuddel in Eclipse IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 7
P External JARs bei Subversion IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 3
S Subversion: Probleme mit Subversion. IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 3
N Netbeans nud Subversion IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 6
X Eclipse Subversion Plugin Subversive <=> Subclipse IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 5
T Subversion ohne Repository (Server) IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 2
K eclipse 3.4 und subversion IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 6
G Subversion bzw. Subclipse IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 7
B CVS (Subversion) - Gratis Server? IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 6
vogella Javadoc - automatische Version mit subversion IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 3
T CVS: Revisionsnummer wie bei Subversion IDEs - Eclipse, IntelliJ IDEA, BlueJ & mehr 8

Ähnliche Java Themen

Neue Themen


Oben