Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
hallo, ich beginne gerade, mich in cvs einzuarbeiten. allerdings sind da ein paar fragen aufgetreten.
1. wenn ich einen tagfür meine daten setze, comitte und andre sich diese daten holen, welchen tag haben die dann?
2. die tags sind ja dafür da, um verschiedene versionen einer datei zu habe, oder? also es kann 2 gleiche dateien geben, aber jeweils anders getagt, korrekt?
3. warum kann ich aus dem branch updaten und aus einem tag? ist es so, dass man nur aus dem tag updatet, wenn man eine bestimmte version haben will?
Zuerst einmal ist das setzten des Tags nicht vom Commit abhängig...und zum anderen wäre die Frage, wie du den Tag machst?
"cvs tag" ? oder "cvs rtag" ?
Das hängt davon ab, ob der/die jenige ein "cvs update"(vorhandene Sandbox), ein "cvs update -r TAGNAME" macht?
Unterschiedliche Tags können einer einzigen Datei zugeordnet sein...
frager hat gesagt.:
2. die tags sind ja dafür da, um verschiedene versionen einer datei zu habe, oder?
Das mit dem "updaten" würde nur dann stimmen, wenn man auf einem Tag weiter entwicklen würde (in CVS geht das nicht). Um das zu machen würde man einen Branch verwenden (Bug-Fixing etc.).
Es hat einfach damit zu tun das SVN nicht für jede Umgebung zu empfehlen ist.
Ich weiß nicht wie es bei Netbeans oder IntelliJ aussieht, aber wenn mit Eclipse arbeitet kann ich nur von SVN abraten weil es nur Probleme macht.
Es vergeht kaum ein Tag an dem ich die Entscheidung für SVN bei meinem letzten Projekt nicht bereut habe.
Bei jedem commit das große Zittern 'was geht jetzt wieder schief'. Nein Danke.
Die Probleme ziehen sich über alle getestete Versionen der beiden Plugins, alle getesten Betriebssysteme und alle involvierten Rechner. :toll:
Komisch. Ich selbst arbeite mit Subversion in Eclipse jetzt seit mehr als 2 Jahren (ok vorher waren das PlugIn mist..). In Projekten mit 20-40 Entwicklern und das Klappt. Die Infos die ich von Kollegen habe, die mit IntelliJ arbeiten hören sich sehr gut an...Zu Netbeans kann ich leider nichts sagen, da ich da keine Kollegen habe, die mit Netbeans arbeiten. Im Zend-Studio klappt das auch und im Enterprise Architecten ebenfalls.
Und zur not gibt es noch die Kommandozeile...oder Tortoise? oder was auch immer für ein Client.
Also ich möchte nur sagen, ein Refactoring in CVS ? Nie mehr bitte...in SVN klappt das jetzt....Ich selbst habe ca. 15 Jahre mit CVS gearbeitet und auch administriert und installiert...und seit ca. 5 Jahren arbeite ich mit Subversion (zum Teil mit SVK) und ich muss sagen, ich möchte nicht wirklich zurück zu CVS....
Wildcard hat gesagt.:
Es vergeht kaum ein Tag an dem ich die Entscheidung für SVN bei meinem letzten Projekt nicht bereut habe.
Bei jedem commit das große Zittern 'was geht jetzt wieder schief'. Nein Danke.
Die Probleme ziehen sich über alle getestete Versionen der beiden Plugins, alle getesten Betriebssysteme und alle involvierten Rechner. :toll:
Das Teil kommt ständig out of sync.
Der absolute Tot für die Plugins ist es beispielsweise eine etwas an der Groß/Kleinschreibung zu ändern.
Das führt selbst dann zu Problemen wenn die Resource noch gar nicht eingecheckt war.
Unter Linux kam dann mit Subversive das Problem hinzu das er aus unbekannten Gründen nicht mehr commiten konnte (regelmäßig).
Versucht man dann über den (gut funktionierenden) Linux Konsolen-Client die Resourcen einzuchecken fliegt Subversive wegen Inkompatibilitäten auf die Nase.
Der Wechsel des von Subversive verwendeten SVN-Clients von Java SVN (das oft Probleme bei bei mir gemacht hat) auf SVN-Kit führt zum Repository Supergau.
Er verliert häufig die Projekt-Zuordnung als Shared Project und ist dann der Meinung das es sich um ein lokales Projekt handelt.
Wenn dann uncommited changes in diesem Projekt vorhanden sind bekommst du es praktisch nicht mehr mit dem Repository gemerged.
CVS benutze ich auf der Arbeit täglich und hatte noch kein einziges Problem in all den Jahren.
Subversion verwende ich für private Projekte und es hat noch niemals reibungslos funktioniert.
Änderungen am Dateisystem ohne "resync" gibt tatsächlich Ärger aber nicht nur mit dem Subversion PlugIn....sondern auch sonst.
Wildcard hat gesagt.:
Der absolute Tot für die Plugins ist es beispielsweise eine etwas an der Groß/Kleinschreibung zu ändern.
Das führt selbst dann zu Problemen wenn die Resource noch gar nicht eingecheckt war.
Unter Linux kam dann mit Subversive das Problem hinzu das er aus unbekannten Gründen nicht mehr commiten konnte (regelmäßig).
Versucht man dann über den (gut funktionierenden) Linux Konsolen-Client die Resourcen einzuchecken fliegt Subversive wegen Inkompatibilitäten auf die Nase.
Der Wechsel des von Subversive verwendeten SVN-Clients von Java SVN (das oft Probleme bei bei mir gemacht hat) auf SVN-Kit führt zum Repository Supergau.
Er verliert häufig die Projekt-Zuordnung als Shared Project und ist dann der Meinung das es sich um ein lokales Projekt handelt.
Wenn dann uncommited changes in diesem Projekt vorhanden sind bekommst du es praktisch nicht mehr mit dem Repository gemerged.
Das riecht nach alte/neue Subversion Release. Alter SVN Client dann mit neuere Release angepackt und dann wars das....Da muss man in der Tat aufpassen. Bin ich auch schon mal drauf reingefallen. ;-(
Apropos mit welchen Releases von Subclipse und Subversive hast Du gearbeitet?
Mit CVS gibts dann andere Probleme, mindestens ein Tag pro Commit, damit auch wirklich die richtigen Dateien für einen Build zusammen bekommt etc. Verzeichnisse (Refactoring in Java)..usw.
Das meine ich nicht. Mir ist bekannt das der Workspace nur Eclipse intern verändert werden sollte. :wink:
Mir scheint einfach das der ResourceChange Listener von Subversive noch einige Probleme aufweißt und nicht immer up-to-date ist. Das führt natürlich zu Problemen.
Das war damals auf Windows, richtig.
Ist natürlich klar das Windows hier keine Unterscheidung macht, aber da es sich um eine uncommited Resource handelte dürfte sich der Client nicht derart aus dem Tritt bringen lassen das man das Projekt löschen muss.
Das ist meiner Meinung nach ein Bug.
Das riecht nach alte/neue Subversion Release. Alter SVN Client dann mit neuere Release angepackt und dann wars das....Da muss man in der Tat aufpassen. Bin ich auch schon mal drauf reingefallen. ;-(
Ja, genau. Der aktuelle Konsolen Client in Feisty Fawn ist neuer als das von Subversive verwendete Kit.
War eben der Versuch die Changes zu retten weil Subversive mal wieder versagt hat. Hat natürlich zu noch mehr Problemen geführt :cry:
Apropos mit welchen Releases von Subclipse und Subversive hast Du gearbeitet?
Subclipse weiß ich leider nicht mehr, das hat mir gar nicht zugesagt und war dementsprechend kurz im Einsatz.
Bei Subversive habe ich den SVN Team Provider 1.1.2.
Mit CVS gibts dann andere Probleme, mindestens ein Tag pro Commit, damit auch wirklich die richtigen Dateien für einen Build zusammen bekommt etc. Verzeichnisse (Refactoring in Java)..usw.
Natürlich hat CVS auch seine Schwachstellen. Refactoring zB ist echt übel, aber das ist mir allemal lieber als ein verbuggter Client bei dem ich immer Angst um meine Projekte haben muss.
Ausserdem habe ich mich an die Schwächen von CVS bereits gewöhnt
hallo, nochmal eine frage zum tagging. also sagen wir mal, ich hole mir mittels update daten von einem branch. wie kann ich erkennen, wie diese daten getaggt wurden? und muss ich meine daten, wenn sie einmal getaggt sind, jedesmal wieder taggen, bevor ich comitte?
Nachdem man eine Klasse gelöscht hat einfach ein Commit und das Umbenennen danach. Fertig.
Gast hat gesagt.:
Hatte es sehr oft das ich das Projekt löschen musst1e weil er nicht mehr auf die letzte version reversen wollte und musste es dann ganz neu auschecken.
Der Tag hat nichts mit dem Commit zu tun.
Das hört sich aber danach an, als ob Du eine Weiterentwicklung auf einem Tag machen würdest dazu würde man allerdings einen Branch verwenden und nicht den Tag.
Typisch ist hier, dass man von einer Release eines Produktes (z.B. 1.0.0) einen Branch macht (BUG_FIX) und am Ende des Bug-Fixes einen Tag zieht, um zu kennzeichnen, dass die geänderte Release (vom Branch) wieder an den Kunden geliefert wurde.
also was ich noch nicht kapiert habe, ist wozu man überhaupt taggt. ich hab den trunk, davon gehen die branches ab. sagen wir mal, ich mach ein update aus einem branch...jetzt ändere ich daten und will wieder comitten...auf genau diesen branch. jetzt die fragen:
1. wieso sollte ich jetzt taggen?
2. wer sieht das getaggte
3. man kann sich jetzt für diesen branch verschiedene getaggte versionen einer datei holen und smit verschiedenen versionen einer datei auf einem branch haben, richtig?
Taggen, um beispielsweise bestimmte Versionsstände (Rollout) explizit zu markieren. Oder willst du noch irgendwo ne Liste führen, aus der hervorgeht, dass Version 1.4.3 Revisionsstand 1165 entspricht?
aha, also hab ich eine datei mit 3 tags, kann ich von dieser datei 3 verschiedenen stände aus dem cvs holen, korrekt? das kann dann aber jeder und nicht nur der, der comitted, also die taginfos stehen auch im cvs?
Um einen bestimmten Stand zu markieren z.B. für einen Release, die an den Kunden gegangen ist oder die in den Test gegangen ist usw.
Damit man auch später nochmal genau nachvollziehen kann wer, was genau bekommen hat.
z.B. Wenn der Kunde anruft und sagt: Hier ist ein Bug? Dann kann man eben genau diese Version auschecken und dort den Fehler auch suchen.
frager hat gesagt.:
ich hab den trunk, davon gehen die branches ab. sagen wir mal, ich mach ein update aus einem branch...jetzt ändere ich daten und will wieder comitten...auf genau diesen branch. jetzt die fragen:
1. wieso sollte ich jetzt taggen?
Die Situation, die Du hier schilderst ist genau die Kunden Situation von oben...Kunde hat in Release 1.0 einen Fehler endeckt. Jetzt erzeugst Du einen Branch vom Release 1.0, um den gemeldeten Fehler wieder zu beheben.
Dann ist alles Ok und Du lieferst die neue (gefixte) Version wieder aus. Um diese Info auch später nochmal nachvollziehen zu können, wird jetzt das Ende des Branches getaggt mit z.B. "Release 1.0.1"
Das muss aus der Sandbox gemacht werden (Working Copy).
In Subversion kann man per Access File auf Verzeichnisebene festlegen, wer die Tags bzw. Branches sieht.
Bitte von der CVS Vorstellung lösen, dass ein Branch/Tag nur eine Zusatzinformation in der Datei sind....
frager hat gesagt.:
3. man kann sich jetzt für diesen branch verschiedene getaggte versionen einer datei holen und smit verschiedenen versionen einer datei auf einem branch haben, richtig?
Du denkst hier in CVS. Wenn ich in CVS einen Branch haben möchte, muss ich folgendes machen:
Code:
cvs update -r BRANCH_NAME
Damit werden alle Dateien des Projektes in meine Sandbox übernommen, die diese Info besitzen.
Wichtig dabei ist, in CVS wird alles Dateibasiert gemacht in Subversion nicht!
In Subversion ist ein Branch/Tag im Repository ein Verzeichnis:
.
