SVN fork repository

[Vlad T. (vlad_tepesch)]

hi,

wi stellt man es mit SVN am besten an, wenn man ein Fork zu einem 
Projekt anlegen will?

Ich habe ein readonly repository
und hätte gern einen branch oder Fork in einem eigenen Repo, auf dem ich 
einchecken kann.

Wär natürlich toll, wenn man checkins im Original im Auge behalten und 
gegebenenfalls einfach mergen könnte


Gruß
Vlad

[Läubi .. (laeubi)]

Vlad Tepesch schrieb:
> wi stellt man es mit SVN am besten an, wenn man ein Fork zu einem
> Projekt anlegen will?

Schon gelesen?
http://blog.assembla.com/assemblablog/tabid/12618/bid/11844/Subversion-Fork-and-Merge-the-technical-details.aspx
Erstes Ergebnis wenn man bei Google 'svn fork' eingibt...

Eventuell mit Git kombinieren:
http://flavio.castelli.name/howto_use_git_with_svn

[Vlad T. (vlad_tepesch)]

Läubi .. schrieb:
> Schon gelesen?
> http://blog.assembla.com/assemblablog/tabid/12618/...
> Erstes Ergebnis wenn man bei Google 'svn fork' eingibt...

das hab ich gesehen, sah mir aber nicht nach dem aus, was ich gesucht 
habe.
 - keine svn kommandos
 - scheinbar ist der Kontext das Produkt, was die Webseite anbietet 
(scheinbar ein Repository hoster)
 - die beschriebenen Kommandos gibts im svn nicht, dass sind Eigenheiten 
ihres Tools

ich kann daraus für meinen Anwendungsfall nix ableiten

alles andere was man mit google so findet hat irgendwas mit Git zu tun.
Ich würde schon ganz gerne bei svn bleiben.

[Guido (Gast)]

Ich würde es mit

scn cp trunk Server-URL/branches/vlad

probieren.

Kennst du das SVN-Book?

[Guido (Gast)]

svn ... latürnich

[Vlad T. (vlad_tepesch)]

Guido schrieb:
> scn cp trunk Server-URL/branches/vlad

ich will ja aus einem fremnden repository copieren.

das gibt dann nur folgnde MEldung:
svn: Quelle und Ziel scheinen sich nicht im selben Projektarchiv zu 
befinden

edit:
klar könnte ich dort einfach einen export machen und bei mir ein add.
Ich dachte nur, es gibt vielleicht etwas eleganteres, was weiterführende 
Synchronisation erleichtert

[Läubi .. (laeubi)]

Vlad Tepesch schrieb:
> Ich dachte nur, es gibt vielleicht etwas eleganteres, was weiterführende
> Synchronisation erleichtert

mach doch folgendes:

1) export des trunks in /meinVerzeichnis/trunk
2) export des trunks in /meinVerzeichnis/branches/remote
3) Du arbeitest ganz normal auf dem trunk
4) Von Zeit zu Zeit Schritt 2 wiederholen und einchecken
4a) Änderungen von branches/remote in /trunk mergen

[Guido (Gast)]

Es geht auch vom Server-Verzeichnis /trunk (oder wie auch immer)
ins Serververzeichnis branches/vlad. Dazu zweimal URL angeben.
Voraussetzung ist aber, dass du die Rechte hast das Verzeichnis
anzulegen.

svn Server-URL/trunk Server-URL/branches/vlad

[Vlad T. (vlad_tepesch)]

da gehen halt die remote revisionsinformationen verloren

man bräuchte irgend wie einen Link auf eine spezifische Revision des 
Originals.
von diesem Link brancht man dann, so dass man einchecken kann.

irgendwan updated man das lokale repo, so dass es wieder auf den head 
zeigt und legt einen neuen branch an, in den die änderungen gewerget 
werden (idealierweise automatisch)

andere eigene Projekte, die diese angepasste lib benutzen müssten dann 
jeweils einen der eigenen branches einbinden.
unklar ist mir aber, ob sich das bewerkstelligen lässt.
hab in diesem zusammenhang grad was mit svn:externals gefunden. mal 
schauen, ob sich das damit umsetzen lässt

[Vlad T. (vlad_tepesch)]

Guido schrieb:
> svn Server-URL/trunk Server-URL/branches/vlad

das geht ebend nicht von unterschiedlichen repos

[Guido (Gast)]

Du bestehst also darauf, dass wir das SVN-Book für dich lesen ;-)

$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Privaten Zweig von /calc/trunk angelegt."
Revision 341 übertragen.

Das muss man nicht komplett durcharbeiten.

[Vlad T. (vlad_tepesch)]

ich bin auch grad am lesen.
Das was ich meine ist unter Vendow-Branches behandelt.

basiert auch auf export/import - scheint also keinen schöneren 
Mechanismus zu geben.

Sieht für mich aber auch eher nach Workaround mit sehr viel Handarbeit 
aus.
Insbesondere Das Mergen der Änderungen der neuen lib in die akuell von 
mir benutzte.
Auch ist mir nicht so richtig klar, wozu man das 
vendors/current-Verzeichnis braucht und warum man nicht direkt die neue 
Lib-Version unter separaten Tag/Branch importiert.

der darauffolgende merge zwischen neuer/alter und moduifizierter 
trunk-Version ist der gleiche.


das mit den externals geht leider nicht.
Man kann ihn nicht davon überzeugen einen Branch zu den verlinkten 
dateien anzulegen. Es wird nur das externals-property übertragen.

edit:
einizger Vorteil des current verzeichnisses scheint zu sein, dass es 
Platzsparender ist, da nur Änderungen geschrieben werden.