www.mikrocontroller.net

Forum: PC-Programmierung Tortoise SVN


Autor: mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Verwende seit gestern Tortoise SVN und habe eine Frage dazu.

Habe mit commit schon einige Änderungen eingestellt und habe mir jetzt 
mal das log angesehen. Dort sehe ich meine bisherigen Versionen und in 
der Spalte action ein rotes Ausrufezeichen und ein blaues plus Zeichen.

Kann mir jemand erklären was diese beiden bedeuten und wie ich das rote 
Ausrufezeichen weg bekomme. anscheinend stimmt etwas nicht.
was habe ich falsch gemacht?

vielen dank für euere antworten!

mike

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du das Logmeldungen-Fenster siehst, gibt es unten rechts den Button
'Hilfe'... wenn du den drückst, dann kommt (nach etwas runterscrollen)
folgendes:
> 5.9.2. Aktionen im Revisionslog
> Der obere Bereich enthält eine Aktionen Spalte, in der Symbole die
> Änderungen einer Revision zusammenfassen. Es gibt vier verschiedene
> Symbole, die jeweils in einer eigenen Spalte angezeigt werden.
>
>
> (!) <--das rote Ausrufezeichen
> in der ersten Spalte zeigt an, dass in einer Revision eine Datei
> oder ein Ordner geändert wurde.
Die Bedeutung der anderen drei Symbole musst du jetzt aber selbst
ermitteln. ;-)

Autor: mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, das reicht mir schon...

vielen dank!

Autor: jos (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
morgen zusammen!

hänge mich mal hier mit dazu...

habe folgende frage:

ich habe insgesamt 22 revisions und bin nun mittels "revert to this 
revision" auf revision 20 "gewechselt".
hat alles wunderbar funktioniert.

nun möchte ich aber wieder auf revision 22 wechseln. kann mir einer 
erklären, wie ich das realisiere?

Vielen dank schon mal!

josef

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
einfach update ausführen, dann haste die neuste

Autor: Dave Anadyr (wilhem)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jungs,
ich schließe mich an diese Diskussion an, weil ich mit TortoiseSVN seit 
gestern beschäftige.
Ich versuche gerade das Programm zu benutzen, dennoch ist es mir eine 
Sache aufgefallen, die ich nicht so ganz verstanden habe.
Vorwort: ich habe schon die Tutorials hinter mir. Was mir fehlt ist ein 
echter live Workflow.

Ok.
Also...ich habe mein Projektverzeichnis in einem Netzwerk abgelegt. Zwei 
Rechner - A und B- können/dürfen auf das Verzeichnis zugreifen und den 
Code herunterziehen.
Nun passiert folgendes:
A checkt den Code aus. Ändert einige Dateien und lädt - durch ein Commit 
- die Änderungen hoch (Commit #1).
B aktualisiert sein Arbeitverzeichnis (lokal), so hat er die Änderungen 
von A in seinem Code. B ändert den Code und lädt wiederum alles hoch 
(Commit #2).

Nun...A hat mittlerweile noch seine alte Kopie in seinem Verzeichnis 
(lokal), in dem er neue Funktionen implementiert hat. Er spricht mit B 
nicht, daher hat er weiter gemacht, ohne B zu fragen, ob er seine 
programme mittlerweile eingecheckt hat oder nicht.

Ok. A versucht seinen Code einzuchecken. Nun kriegt er eine Meldung, 
dass sein Code nicht der aktuellste ist. Ok...So aktualiesiert seine 
lokale Arbeitskopie und...findet seine neusten Änderungen neben den 
Änderungen von B!!!!

Warum bin ich verwirrt? Weil ich erwartet hätte, dass A, wenn er 
aufgefordert wird, sein lokales Arbeitsverzeichnis zu aktualisieren, die 
Unterschiede zwischen der eingecheckten Version von B (Commit #2) und 
seinen letzten noch nicht eingechekten Änderungen automatisch gezeigt 
werden. Als ob SVN ihm mitteilen würde: "Du hast die Funktion X und Y 
implementiert. Allerdings diese sind nicht in dem letzten Commit von B 
enthalten. Was willst Du damit machen?"

Also..habe ich eine falsche Vorstellung davon, wie SVN funktionert?
Wie kann ich vermeiden, dass ich immer sehen kann, wo der andere Kollege 
seinen Code geändert hat? Durch log ist es unzureichend. Ich will sehen, 
welche Funktionen bzw. Änderungen in den Dateien er letztlich 
implementiert hat.

Danke Euch für Eure Hilfe.
Gruß

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du unter Windows bist, z.B. WinMerge installieren und in svn 
einstellen das WinMerge das standard diff-tool ist. Unter Linux benutze 
ich Kdiff3.

Dann kannst du auch sehen was wo geändert wurde und das ganze mergen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave A. schrieb:

> Also..habe ich eine falsche Vorstellung davon, wie SVN funktionert?
> Wie kann ich vermeiden, dass ich immer sehen kann, wo der andere Kollege
> seinen Code geändert hat? Durch log ist es unzureichend.

wieso ist das unzureichend?
Im log Eintrag dieses Commits von B ist eine Liste aller geänderten 
Dateien. Ein Doppelklick drauf zeigt dir exakt, was von B in der 
Zwischenzeit alles geändert wurde.

: Bearbeitet durch Moderator
Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave A. schrieb:

> Ok. A versucht seinen Code einzuchecken. Nun kriegt er eine Meldung,
> dass sein Code nicht der aktuellste ist. Ok...So aktualiesiert seine
> lokale Arbeitskopie und...findet seine neusten Änderungen neben den
> Änderungen von B!!!!
>
> Warum bin ich verwirrt? Weil ich erwartet hätte, dass A, wenn er
> aufgefordert wird, sein lokales Arbeitsverzeichnis zu aktualisieren, die
> Unterschiede zwischen der eingecheckten Version von B (Commit #2) und
> seinen letzten noch nicht eingechekten Änderungen automatisch gezeigt
> werden. Als ob SVN ihm mitteilen würde: "Du hast die Funktion X und Y
> implementiert. Allerdings diese sind nicht in dem letzten Commit von B
> enthalten. Was willst Du damit machen?"

Was interessiert dich das?
Solange es keine Konflikte gibt, ihr beide also an derselben Source Code 
Stelle gearbeitet habt, ist das ziemlich uninteressant. Das du deinen 
Code nach dem UPdate noch mal neu durchtesten musst, dürfte klar sein. 
Denn es könnte sein, dass B's letzte Änderung deine neuen Ergänzungen 
beeinflussen. Die Auswirkungen auf den restlichen Code wurden ja schon 
von B behandelt und die kriegst du beim Update ja auch in deinen Code 
gemerged.

Wir waren 12 Entwickler in einem Projekt. Wenn ich da jeden Tag die mehr 
als 100 oder 150 Files durchgesehen hätte, die seit meinem letzten 
Commit geändert wurden, wär ich zu nichts anderem mehr gekommen.

Und wenn es beim Update Konflikte gibt, dann krieg ich im Update Dialog 
sowieso eine Anzeige in welchen Files es Konflikte gibt, die ich erst 
mal resolven muss. Auch hier wieder: Doppelklick drauf und es öffnet 
sich ein Merge Tool, welches mir erlaubt zu bestimmen, welche Codezeilen 
die gültigen sein sollen. Sind alle erledigt, den Konflikt als resolved 
markieren und weiter gehts.

A spricht nicht mit B. Das geht, wenn beide in verschiedenen 
Programmbereichen arbeiten. Sitzen sie aber an derselben Funktionalität, 
ist es unumgänglich, dass sie miteinander sprechen oder zumindest einen 
kurzen Nachrichtenaustausch pflegen.

: Bearbeitet durch Moderator
Autor: Dave Anadyr (wilhem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok,
erstmal vielen Dank für Eure Antwort. Insbesondere Kaj hat mir einen 
guten Tipp gegeben. WinMerge kannte ich nicht.

Dennoch möchte ich nochmal nachhacken, weil ich mir sicher bin, dass ich 
vielleicht nicht so ganz klar habe, wie SVN funktioniert. Ich will das 
Programm lernen und nicht bloß Funktionen einfach abrufen, ohne zu 
verstehen, was hinter den Kulissen läuft.

Angenommen, A unb B arbeiten beide an dem selben Projekt.
Eines Tages implementiert A neue Funktionalitäten in mehreren Dateien 
und will diese einchecken. Doch stellt er nun fest, er habe nicht die 
letzte aktualisierte Version, die B mittleweile schon eingecheckt hatte. 
So wenn A jetzt seine lokale Arbeitskopie aktualisiert, findet er die 
von B entwickelten Programmen. Nun: wie kann A überprüfen, ob er die von 
B eingecheckten Änderungen in seinem Code übernehmen soll oder nicht?
Aktualisiert er seine lokale Arbeitskopie und hofft dass die Änderungen 
von B kein Problem hervorrufen?

Danke

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave A. schrieb:

> von B entwickelten Programmen. Nun: wie kann A überprüfen, ob er die von
> B eingecheckten Änderungen in seinem Code übernehmen soll oder nicht?

Er hat gar keine andere Wahl.
Die Frage ist nicht "soll ich sie übernehmen oder nicht".
Die einzige Frage lautet: "Inwiefern betrifft mich das"

Man kann sich natürlich vor dem Upate erst mal im SVN-Log ansehen, was B 
denn da eigentlich alles gemacht hat, wenn man dem misstraut. Aber 
grundsätzlich gibt es immer nur einen aktuellen Stand, der das Projekt 
repräsentiert.
(Über so Dinge wie Branches reden wir erst mal nicht)

> Aktualisiert er seine lokale Arbeitskopie und hofft dass die Änderungen
> von B kein Problem hervorrufen?

erst mal ja.
Vor dem Einchecken wird der Teil an dem A gearbeitet hat nochmal 
durchgetestet, wenn abzusehen ist, dass es da mögliche Beeinflussungen 
gibt. Im Zweifel wird auf jeden Fall getestet.

Keine Projektverwaltung kann dir diese Arbeit abnehmen. Das ist nun mal 
so, wenn mehrer Leute an einem Projekt arbeiten. Da wird es immer wieder 
mal den Fall geben, dass sich die Arbeitsbereich überschneiden.

: Bearbeitet durch Moderator
Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave A. schrieb:

> Aktualisiert er seine lokale Arbeitskopie und hofft dass die Änderungen
> von B kein Problem hervorrufen?

Und dann gilt natürlich noch die Politik der Selbstdisziplin, nach der 
jeder Entwickler nicht einfach nach Lust und Laune einchecken darf, 
sonder das eingecheckte muss getestet und für gut befunden worden sein. 
Halbe Sachen einchecken gilt nicht. Und halbfertige Sachen schon gar 
nicht. Der Zustand im SVN muss jederzeit auf einer neuen Maschine 
auscheckbar sein und das entstehende Produkt muss lauffähig sein. 
Zumindest im Prinzip.

In vielen Teams gilt dann auch das Prinzip, dass man seine Änderungen 
vor dem Einchecken von einem Kollegen 'absegnen' lassen muss.
Und dann gibt es natürlich ja auch noch den Projektverantwortlichen, der 
die Arbeiten zuteilt. D.h. B kann nicht einfach nach Lust und Laune 
irgendwas ändern.
In einer Softwarebude geht es zu wie in jeder anderen Firma auch. 
Inklusive Orignaisationsstrukturen. Die Mär, nach der 2 langhaarige 
Kiffer irgendwann am frühen Nachmittag kommen, dann 12 Stunden in die 
Tastatur hämmern, ist schon lange nicht mehr korrekt. Wenn sie denn je 
korrekt war. Software entwickeln ist Teamarbeit und schon schwer genug. 
Eigenbrödlerische Diven haben dabei nichts verloren.

: Bearbeitet durch Moderator
Autor: Dave Anadyr (wilhem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Karl,
mir ist nun alles klarer geworden.
Also: A hat keine Wahl. So aktualisiert er seine Arbeitskopie. ABER 
bevor er seinen Code eincheckt, wird er überprüfen, inwieweit die 
Änderungen von B seinen Code beeinflussen. Er guckt welche Datei B 
modifiziert hat und was er geändert hat. Und zwar genauso so wie du hier 
beschrieben hast:

> Im log Eintrag dieses Commits von B ist eine Liste aller geänderten
> Dateien. Ein Doppelklick drauf zeigt dir exakt, was von B in der
> Zwischenzeit alles geändert wurde.

Richtig?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke eines deiner Kernprobleme liegt auch hier drinn:
Ein der Aufgaben einer Verwaltung wie SVN ist es auch dafür zu sorgen, 
dass ALLE im Team immer einen IDENTISCHEN Softwarestand haben. Der kann 
kurzzeitig mal von dem der anderen abweichen, weil eine Funktionalität 
gerade in der Entwicklung ist, aber auf lange Sicht sorgt SVN dafür, 
dass die Source-Code Stände aller Entwickler immer auf gleich gehalten 
werden. Deine Änderungen werden in die Source Code Stände der anderen 
eingepflegt und umgekehrt.
D.h. dein Thema "Soll ich oder soll ich nicht" ist eine Fragestellung, 
die du gar nicht haben willst. Denn nichts ist tödlicher, als wenn die 
Source Codes mehrerer Entwickler auseinanderlaufen. Irgendwann will man 
ja dann auch ein verkaufsfähiges Produkt haben. Aber wer hat das denn 
dann? A oder B? Die Antwort lautet: jeder - weil jeder auf seiner 
lokalen Entwicklungsmaschine denselben Code hat wie alle anderen auch. 
Man könnte auch sagen: SVN hat ihn und was du lokal noch an Änderungen 
bei dir rumlungern hast, interessiert niemanden. Aber da du ja keine 
nicht eingecheckten Source Codes hast, ist das ein akademisches Thema.

: Bearbeitet durch Moderator
Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave A. schrieb:
> Danke Karl,
> mir ist nun alles klarer geworden.
> Also: A hat keine Wahl. So aktualisiert er seine Arbeitskopie. ABER
> bevor er seinen Code eincheckt, wird er überprüfen, inwieweit die
> Änderungen von B seinen Code beeinflussen. Er guckt welche Datei B
> modifiziert hat und was er geändert hat. Und zwar genauso so wie du hier
> beschrieben hast:
>
>> Im log Eintrag dieses Commits von B ist eine Liste aller geänderten
>> Dateien. Ein Doppelklick drauf zeigt dir exakt, was von B in der
>> Zwischenzeit alles geändert wurde.
>
> Richtig?

Richtig.
Normalerweise reicht ein Blick in die Kurzbeschreibung um zu sehen, ob 
es eventuell Beeinflussungen gibt. Ist man sich nicht sicher, dann sieht 
man sich die File-Liste an. Ist da nichts dabei, was verdächtig klingt, 
dann wars das schon. Verdächtige Files wird man sich genauer ansehen, 
wobei da wieder die Infrastruktur eines Merge Tools zu Einsatz kommt - 
diesmal aber um die Änderungen zu zeigen.

Erweitert kommt hinzu, dass man tunlichst nicht zu lange wartet, bis man 
seine Änderungen eincheckt. Habe ich einen Bug zu fixen, dann wird der 
Bug gesucht, gefixt und die betroffenen Files sofort wieder eingecheckt. 
Je länger man damit zuwartet, desto größer wird die Chance, dass man 
Code Kollisionen hat. Und die will man nicht haben. Hier ist also 
Disziplin gefragt - schon im eigenen Interesse.

: Bearbeitet durch Moderator
Autor: Dennis S. (eltio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitat aus dem Vorwort (!) vom SVN Book:
[...] die Arbeit in einem Entwicklerteam ist von Natur aus eine soziale Tätigkeit bei der Änderungen am Quelltext ständig besprochen, durchgeführt, geprüft und manchmal sogar rückgängig gemacht werden. Versionskontroll-Werkzeuge ermöglichen diese Art der Zusammenarbeit.

Soll heißen: das Einsetzen eines SCM-Tools bedeutet nicht, dass ein Team 
nicht mehr zusammenarbeiten muss...

Gruß
Dennis

Autor: Tom K. (ez81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl H. schrieb:
> schon im eigenen Interesse.

Wer zuerst eincheckt, hat den Ärger mit dem Mergen nicht ;)

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl H. schrieb:
> (Über so Dinge wie Branches reden wir erst mal nicht)

Schade. Ich benutze TortoiseSVN jetzt ein Weilchen für Projekte allein 
und im Team und suche schon seit längerem nach einer guten Beschreibung 
zu einem Brange&Merge-Workflow.

Autor: Dave Anadyr (wilhem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter T. schrieb:
> Karl H. schrieb:
>> (Über so Dinge wie Branches reden wir erst mal nicht)
>
> suche schon seit längerem nach einer guten Beschreibung
> zu einem Brange&Merge-Workflow.

Genau das ist meiner Meinung nach das größte Problem. Es gibt tausende 
Tutorials und Anleitung aber kein wirklicher Workflow. Entweder hat man 
Glück und lernt das Tool in einem Team (so ist man in dem Workflow 
mittdrin) oder fragt man einfach nach - wie ich eben gerade -.

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave A. schrieb:
> Es gibt tausende
> Tutorials und Anleitung aber kein wirklicher Workflow.

Oh, für den Einstieg in normalen Projekten reicht das erste Drittel des 
Tortoise-SVN-Books völlig aus. Die Workflows nach dem Prinzip 
Blockieren/Modifizieren oder der "optimistische" Workflow sind schon gut 
beschrieben. Die beiden zu kennen reicht für die ersten 10 Jahre auch 
aus :-).

Und ich sehe gerade: Im Kapitel "Branch&Merge" hat sich viel getan. Also 
ziehe ich meine Frage erst einmal wieder zurück und lese mir den Teil 
erst einmal durch - ich hatte diesen Teil weitaus weniger umfangreich in 
Erinnerung.

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr mal überlegt, GIT zu verwenden?
Es ist zwar anfangs etwas komplizierter als SVN, aber durch das 
Branch-Modell hat man (gefühlt) weniger Probleme beim Mergen.
-> Ich kann (sofern ich in meinem eigenen Branch bin) meine Änderungen 
so wie sie sind ins Repository commiten und kann mich danach ums Mergen 
kümmern.

Als GUI verwende ich SourceTree 1.5 von Atlassian und die Kommandozeile.
Früher habe ich auch TortoiseSVN verendet.

(In der Nachfolgeversion 1.6 haben sie das UI "überoptimiert" 
https://jira.atlassian.com/browse/SRCTREEWIN-2271 )

Gruß
Roland

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zu meinem obigen Post: hier ist die aktuelle Version des Buchs:

http://svnbook.red-bean.com/de/1.8/svn-book.pdf

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Da hätt ich auch gleich eine Frage zum Workflow, vorzugsweise mit Git.

Ausgangspunkt wäre eine Library zu der es laufend Aktualisierungen gibt. 
(Releases zum Download)
An dieser habe ich jede Menge Änderungen gemacht.
Ich würde gerne Up-to-date sein, aber auch meine Änderungen eingepflegt 
haben.
Zurzeit führe ich ein Git-Repository mit der unveränderten Library im 
master branch. In einem anderen branch habe ich die angepasste Version 
der Library.
Zum Updaten wechsle ich auf den master branch und committe die aktuelle 
Version. Dann wechlse ich auf den anderen branch und gebe "git merge 
master" ein. Das funktioniert aber nicht immer gut, vor allem wenn 
Dateien umbenannt oder gelöscht wurden.
Kennt Ihr eine bessere Möglichkeit?

Gruß
Stefan

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave A. schrieb:
> Also...ich habe mein Projektverzeichnis in einem Netzwerk abgelegt. Zwei
> Rechner - A und B- können/dürfen auf das Verzeichnis zugreifen und den
> Code herunterziehen.

Das hat zwar nichts mit dem Workflow zu tun, ist aber eigentlich falsch.
Erstens raten die SVN-Entwickler dringend davon ab, das so zu machen, da 
es bei gleichzeitigem Zugriff auf das Repository oder beim Zugriff vom 
verschiedenen SVN-Versionen zu Problemen kommen kann. Zweitens sollte es 
nie einem Benutzer möglich sein, direkt auf das Repository zuzugreifen 
und es dadurch versehentlich zu beschädigen.

Autor: Dave Anadyr (wilhem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Dave A. schrieb:
>> Also...ich habe mein Projektverzeichnis in einem Netzwerk abgelegt. Zwei
>> Rechner - A und B- können/dürfen auf das Verzeichnis zugreifen und den
>> Code herunterziehen.
>
> Das hat zwar nichts mit dem Workflow zu tun, ist aber eigentlich falsch.
> Erstens raten die SVN-Entwickler dringend davon ab, das so zu machen, da
> es bei gleichzeitigem Zugriff auf das Repository oder beim Zugriff vom
> verschiedenen SVN-Versionen zu Problemen kommen kann. Zweitens sollte es
> nie einem Benutzer möglich sein, direkt auf das Repository zuzugreifen
> und es dadurch versehentlich zu beschädigen.

Richtig...und ich weiß es.
Aber manche Entscheidungen werden nicht von mir getroffen.

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Hi!
>
> Da hätt ich auch gleich eine Frage zum Workflow, vorzugsweise mit Git.

Ich mach es so: Die Änderungen werden in einzelnen Branch(es) gemacht
(Wir hatten früher je Entwickler einen Branch, gehen jetzt aber dazu 
über, je Feature einen eigenen Branch zu machen)

Wenn dann eine neue Version ansteht, wechsle ich in den Master Branch 
und merge vom Dev-Branch. (wenn es nur einen Branch gibt, geht dies als 
Fast-Forward Merge und ohne Konflikte)
Wenn es mehrere Branches von mehreren Entwicklern gibt, dann ist 
durchaus mal Arbeit angesagt, das stimmt :(, hier gehe ich aber den Weg, 
erst mal alles in einen "beta"-Branch zu mergen und wenn Tests etc 
durchlaufen, kommt das in den Master.

Die Feature-Branches sollten nun eigentlich gelöscht werden, bzw. wieder 
mit dem Master gemerged werden.

Zum Umbenennen/Verschieben noch ein Tipp:
- Möglichst weit oben eine zentrale .gitignore platzieren
- Löscht man komplette Verzeichnisse oder benennt diese um, ist es eine 
gute Idee, diese in die GitIgnore einzutragen, da Kollegen sonst nach 
einem Merge oft veraltete Files commiten. Dies ist insbesondere dann der 
Fall, wenn in dem Verzeichnis eine .gitignore enthalten war.

Beim Umbenennen/Verschieben sollte man darauf achten, dass Git die 
Änderungen trackt. Also entweder mit "git mv" verschieben oder vor dem 
Ändern der Dateien einen Commit machen (Git kennt verschobene Dateien 
automatisch, sofern sich noch nicht zu viel Inhalt geändert hat)

Gruß
Roland

: Bearbeitet durch User
Autor: Marc (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Roland P. schrieb:
> Habt ihr mal überlegt, GIT zu verwenden?

Wo kommen eigentlich immer all die Leute her, die Git in Großbuchstaben 
schreiben?

> Es ist zwar anfangs etwas komplizierter als SVN, aber durch das
> Branch-Modell hat man (gefühlt) weniger Probleme beim Mergen.
> -> Ich kann (sofern ich in meinem eigenen Branch bin) meine Änderungen
> so wie sie sind ins Repository commiten und kann mich danach ums Mergen
> kümmern.

Also völlig genauso wie in Subversion. Oder gar in CVS, Gott hab es 
selig.

Autor: Dave Anadyr (wilhem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo super Freunde,
ich habe eine kurze Frage, die mich gerade beschäftigt.
Ich habe ein Projektsverzeichnis mit den drei Ordner "tags", "branch" 
und "trunk" erzeugt.
Nun ist es soweit, dass ich mein Projekt, das ich unter "trunk" 
entwinkelt habe, als Release unter "tags" kopieren will.

Was soll ich eigentlich machen?
Ich will ich es ordernlich machen, da die erarbeiteten Dateien und 
Programme nicht verloren werden müssen.

Vielen vielen Dank.

: Bearbeitet durch User
Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt Fragen, für die Google wirklich alle Antworten kennt. WIRKLICH 
ALLE. Ohne Ausnahme.

In diesem Fall sogar auf Deutsch (auch wenn die übersetzten Begriffe 
schon fast körperlich wehtun):

http://tortoisesvn.net/docs/release/TortoiseSVN_de...

Oliver

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.