# CVS ---> einige Fragen



## frager (12. Mai 2007)

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?

so, das wars schon...danke für evtl. antworten .

grüße


----------



## kama (12. Mai 2007)

Hallo,



			
				frager hat gesagt.:
			
		

> hallo, ich beginne gerade, mich in cvs einzuarbeiten.


Nur so eine Frage interesse halber..warum noch CVS? Und nicht direkt Subversion?



			
				frager hat gesagt.:
			
		

> 1. wenn ich einen tagfür meine daten setze, comitte und andre sich diese daten holen, welchen tag haben die dann?


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?


Ein Tag ist dazu da einen bestimmten Punkt in der Entwicklungs zu markieren (Vorbereitung Release, Release selbst etc.).



			
				frager hat gesagt.:
			
		

> also es kann 2 gleiche dateien geben, aber jeweils anders getagt, korrekt?


Ich glaube das muss man etwas umformulieren. 
Eine Datei kann unterschiedliche Tags haben.....



			
				frager hat gesagt.:
			
		

> 3. warum kann ich aus dem branch updaten und aus einem tag?


Meinst Du so sachen wie "cvs update -j BRANCH" oder so sachen wie "cvs update -r TAGNAME" ?



			
				frager hat gesagt.:
			
		

> ist es so, dass man nur aus dem tag updatet, wenn man eine bestimmte version haben will?


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.).

MfG
Karl Heinz Marbaise


----------



## Wildcard (12. Mai 2007)

kama hat gesagt.:
			
		

> Nur so eine Frage interesse halber..warum noch CVS? Und nicht direkt Subversion?


Zum Beispiel weil die beiden bekanntesten SVN Plugins für Eclipse der größte Mist sind.


----------



## kama (12. Mai 2007)

Hallo,



			
				Wildcard hat gesagt.:
			
		

> Zum Beispiel weil die beiden bekanntesten SVN Plugins für Eclipse der größte Mist sind.


Sehr qualifizierte Aussage...Sorry. 

Aber abgesehen davon, was hat das damit zu tun, ob nun CVS oder Subversion...

MfG
Karl Heinz Marbaise


----------



## Wildcard (12. Mai 2007)

kama hat gesagt.:
			
		

> Aber abgesehen davon, was hat das damit zu tun, ob nun CVS oder Subversion...


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:


----------



## kama (12. Mai 2007)

Hallo,



			
				Wildcard hat gesagt.:
			
		

> Es hat einfach damit zu tun das SVN nicht für jede Umgebung zu empfehlen ist.


Meinst Du jetzt wie unten genannt die IDE oder etwas anderes?



			
				Wildcard hat gesagt.:
			
		

> Ich weiß nicht wiees bei Netbeans oder IntelliJ aussieht, aber wenn mit Eclipse arbeitet kann ich nur von SVN abraten weil es nur Probleme macht.


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:


Was waren denn die Probleme , die immer schief gegangen sind?

MfG
Karl Heinz Marbaise


----------



## Wildcard (12. Mai 2007)

kama hat gesagt.:
			
		

> Was waren denn die Probleme , die immer schief gegangen sind?


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.


----------



## kama (13. Mai 2007)

Hallo,


			
				Wildcard hat gesagt.:
			
		

> Das Teil kommt ständig out of sync.


Ä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.


Ich vermute auf Windows?



			
				Wildcard hat gesagt.:
			
		

> 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.

MfG
Karl Heinz Marbaise


----------



## Wildcard (13. Mai 2007)

> Änderungen am Dateisystem ohne "resync" gibt tatsächlich Ärger aber nicht nur mit dem Subversion PlugIn....sondern auch sonst.


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.


> Ich vermute auf Windows?


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


----------



## Gast (14. Mai 2007)

hab auch noch vor ca. nen jahr mit eclipse und subclipse gearbeitet und hatte auch jede menge probleme

Eine Klasse löschen und dann eine andere so nennen wie die gelöschte hatte da schon probleme gemacht. Also grundsätzlich refactorn war echt nervig.

Hatte es sehr oft das ich das Projekt löschen musste weil er nicht mehr auf die letzte version reversen wollte und musste es dann ganz neu auschecken.


----------



## frager (16. Mai 2007)

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?

danke


----------



## kama (16. Mai 2007)

Hallo,



			
				Gast hat gesagt.:
			
		

> hab auch noch vor ca. nen jahr mit eclipse und subclipse gearbeitet und hatte auch jede menge probleme


Also ist das auch jetzt noch so? oder wie? 



			
				Gast hat gesagt.:
			
		

> Eine Klasse löschen und dann eine andere so nennen wie die gelöschte hatte da schon probleme gemacht. Also grundsätzlich refactorn war echt nervig.


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.


Warum nicht? Fehlermeldung? Du meinst aber sicherlich "revert" oder?

BTW: Solche Fehlerinfos wären dann sicherlich auf der Subclipse Fehlerliste bzw. im Bug-Tracker von Subclipse sehr gut aufgehoben gewesen...

MfG
Karl Heinz Marbaise


----------



## kama (16. Mai 2007)

Hallo,



			
				frager hat gesagt.:
			
		

> hallo, nochmal eine frage zum tagging. also sagen wir mal, ich hole mir mittels update daten von einem branch.


Es wird per "switch" auf einen Branch umgeschaltet oder aber eine vollständig neue WC direkt vom Branch ausgecheckt.

Per Update werden keine Änderungen von einem Branch geholt.  Um einen Merge durchzuführen wird "svn merge" verwendet".



			
				frager hat gesagt.:
			
		

> wie kann ich erkennen, wie diese daten getaggt wurden?


Meinst Du hier die Daten auf dem Branch ?



			
				frager hat gesagt.:
			
		

> ..und muss ich meine daten, wenn sie einmal getaggt sind, jedesmal wieder taggen, bevor ich comitte?


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.

MfG
Karl Heinz Marbaise


----------



## frager (16. Mai 2007)

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?

danke!!  ???:L


----------



## AlArenal (16. Mai 2007)

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?


----------



## frager (16. Mai 2007)

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? 

danke!!!


----------



## kama (16. Mai 2007)

Hallo,



			
				frager hat gesagt.:
			
		

> also was ich noch nicht kapiert habe, ist wozu man überhaupt taggt.


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).

```
cvs update -r RELEASE-1-0
cvs tag -b BUG_FIX -r RELEASE-1-0
cvs update -r BUG_FIX
..
cvs commit ...
cvs tag RELEASE-1-0-1
```




			
				frager hat gesagt.:
			
		

> 2. wer sieht das getaggte


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:


```
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:


```
svn checkout URL/branches/BUGFIX
```
bzw.

```
svn switch URL/branches/BUGFIX
```
Schaltet meine Working Copy auf den Branch.


MfG
Karl Heinz Marbaise


----------

