Programmieren mit Harald R. Haberstroh

Erstellen Sie ein Projekt java-klassen mit zwei Klassen:

1. Person
2. PersonManager

Die Methoden der Klasse Person sollen folgende Funktionalität bereitstellen:

1. Der Konstruktor Person(String vn, String fn, int gj, char g) soll einfach die passenden Attribute setzen.
2. print() soll Vorname, Nachname, Alter und Geschlecht auf der Konsole ausgeben.
3. getName() liefert den Vornamen und Nachnamen mit einem Leerzeichen getrennt.
4. getAlter(int jahr) soll das Alter in Jahren bezogen auf das im Parameter angegebene Jahr zurückliefern.
5. toString() liefert einen String, der alle Informationen lesbar enthält.
6. main() ist optional und enthält einfach Tests der Klasse.

Die Methoden der Klasse PersonManager sollen folgende Funktionalität bereitstellen:

1. print() soll einfach alle Personen ausgeben (print() von Person verwenden).
2. add(Person person) nimmt eine neue Person in die interne Liste/Array auf.
3. main() soll mindestens zwei verschiedene Personen anlegen, die dann in einen Manager aufgenommen werden. Alle Personen sollen ausgegeben werden.

Beispielaufruf auf Konsole:

hp@if205-2l $ java PersonManager
Max Meier, geboren 1998 (16 Jahre alt), männlich
Katrin Huber, geboren 1996 (18 Jahre alt), weiblich

Importieren Sie das Projekt ins CVS. Die Abgabe erfolgt durch Taggen der abzugebenden Version (siehe CVS: Wissenswertes (POS1: 2BHIF)).

Labels: Aufgabe, CVS, Java, POS1-2

# Eingestellt von Harald R. Haberstroh @ 12:20 0 Kommentare

Tags

Ein Tag (nicht das Gegenstück zur Nacht, sondern das englische Wort zu Marke) ist ein symbolischer Name für den Zustand des Projekts im Repository zu einem bestimmten Zeitpunkt. Ein Tag muss mit einem Buchstaben beginnen und kann dann Buchstaben, Ziffern, Unterstriche und Bindestriche enthalten. Punkte sind nicht erlaubt, damit ein Tag nicht mit einer Versionsnummer verwechselt werden kann.

Beispiele REL_1_0, rev-99, TRY_HP_20060919

Reguläre Tags

Jede Datei im Repository hat ihre eigene Versionsnummer (beginnend mit 1.1, wird bei jedem commit erhöht: 1.2, 1.3 usw.).

Besteht ein Modul (Projekt) aus den Dateien

Main.java      1.4
Gui.java       1.9
Net.java       1.6

will man auf diesen Zustand (diese Versionen) später wieder zugreifen können, weil dies z.B. eine auszuliefernde Version ist, so wählt man ein Tag, z.B. REL_1_0.

Ein Tag erzeugt intern eine Liste von Versionsnummern, die den Stand jeder Datei wiedergeben.

Es können beliebig viele Tags vergeben werden, jedoch müssen sie eindeutig sein.

~/work/project > cvs commit -m ""
cvs commit: Examing .
~/work/project > cvs rtag REL_1_0 project
cvs rtag: Tagging project

Mit dem CVS-Befehl rtag wird das Tag REL_1_0 erzeugt. Später kann man das Projekt mit der Option -r REL_1_0 (-r für release)

~/work > cvs checkout -r REL_1_0 project
~/work > cd project
~/work/project >

auschecken. Die Dateien im Verzeichnis project haben dann wieder obige Versionsnummern. Möchte man das Projekt in ein anderes Verzeichnis auschecken, dann muss man die Option -d name verwenden. Z.B.: es soll REL_1_0 in das Verzeichnis rel1.0 ausgecheckt werden:

~/work > cvs checkout -r REL_1_0 -d rel1.0 project
~/work > cd rel1.0
~/work/rel1.0 >

Verwenden eines Tags für die Abgabe

Für die Abgabe verwenden Sie das Tag ABGABE_1_0. Wollen Sie Korrekturen abgeben, dann verwenden Sie bitte ABGABE_1_1, ABGABE_1_2 usw.

Gibt es für ein Beispiel mehrere (Teil-)Abgaben, so verwenden Sie für die erste Abgabe obiges Schema, für die zweite Abgabe ABGABE_2_0 bis ABGABE_2_n (n n. Abgabeversion) usw.

alte Versionen auschecken

Will man auf eine alte Version zugreifen, so kann man beim Auschecken angeben, welchen Zustand man haben will, in dem man die Option -D datum angibt. datum kann entweder in der englischen Schreibweise angegeben werden (MM/TT/JJJJ), im ISO-Format (JJJJ-MM-TT) oder auch relativ als Text unter Hochkomma (z.B. 3 weeks ago, 1 day ago 27 minutes ago oder 3 days ago o.ä.).

Das Projekt python im Zustand vor einer Woche auschecken:

~/work > cvs co -D "1 week ago" python
cvs checkout: Updating python
U python/dreieck.py
U python/prim.py
~/work >

Das Projekt python im Zustand vom 22.9.2006 auschecken:

~/work > cvs co -D 09/22/2006 python
cvs checkout: Updating python
U python/calc.py
U python/craten.py
U python/dreieck.py
U python/ggt.py
U python/mittelwert.py
U python/muster.py
U python/prim.py
U python/pyintro.pdf
U python/raten.py
U python/summe.py
~/work >

Ältere Versionen sollten in eigene Verzeichnisse ausgecheckt werden. Sobald eine bestimmte Version ausgecheckt wurde, ist sie sticky (klebrig). Das bedeutet, dass sich alle Arbeiten in diesem ausgecheckten Verzeichnisbaum auf diese Version beziehen.

Daher ist das Weiterarbeiten an einer solchen Version nur sinnvoll bei Zweigen.

binäre Dateien

Unter binären Dateien verstehen wir hier Dateien, die nicht aus Textzeilen bestehen. Das sind z.B. Word- und Excel-Dateien, Bilder usw. CVS speichert normalerweise Textdateien und deren Zeilenänderungen. Dies ist bei Binärdateien nicht möglich. Wird z.B. eine Word-Datei nicht als Binärdatei markiert, so wird sie vom CVS zerstört (Subversion, der Nachfolger von CVS, kann gut mit Binärdateien umgehen, CVS ist aber immer noch weit verbreitet...).

Damit nicht bei jedem cvs add, cvs import" usw. die Option %-W *.gif -k 'b' (für jede Dateiendung von Binärdateien einmal!) angegeben werden muss, schreibt man diese Dateien in die Konfigurationsdatei CVSROOT/cvswrappers.

Die Konfiguration eines Repositories befindet sich im Projekt CVSROOT, welches man auscheckt, bearbeitet und dann wieder eincheckt (commit).

~/work > cvs checkout CVSROOT
...
~/work > cd CVSROOT
~/work/CVSROOT > vim cvswrappers

Die Datei sollte z.B. so aussehen (Zeilen mit # sind Kommentare, die schon enthalten sind):

# This file affects handling of files based on their names.
#
# The -m option specifies whether CVS attempts to merge files.
#
# The -k option specifies keyword expansion (e.g. -kb for binary).
#
# Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers)
#
#  wildcard [option value][option value]...
#
#  where option is one of
#  -f    from cvs filter      value: path to filter
#  -t    to cvs filter     value: path to filter
#  -m    update methodology   value: MERGE or COPY
#  -k    expansion mode    value: b, o, kkv, &c
#
#  and value is a single-quote delimited value.
# For example:
*.img -k 'b'
*.cramfs -k 'b'
*.jar -k 'b'
*.m2v -k 'b'
*.mvi -k 'b'
*.ppc -k 'b'
*.jffs* -k 'b'
*.nfi -k 'b'

# Microsoft
*.doc -k 'b'
*.xls -k 'b'
*.ppt -k 'b'

# Openoffice 1.*
*.stc -k 'b'
*.std -k 'b'
*.sti -k 'b'
*.stw -k 'b'
*.sxc -k 'b'
*.sxd -k 'b'
*.sxq -k 'b'
*.sxi -k 'b'
*.sxm -k 'b'
*.sxp -k 'b'
*.sxw -k 'b'

# dia
*.dia -k 'b'

# Bilder
*.xcf -k 'b'
*.jpg -k 'b'
*.bmp -k 'b'
*.gif -k 'b'
*.png -k 'b'

Für jeden Dateityp mit Binärformat gibt es eine Zeile der Form *.endung -k 'b'.

Diese Einträge speichern, den Editor beenden und das Projekt wieder commiten:

~/work/CVSROOT > cvs commit -m "Binärdateien bekanntgegeben"
...

Das Verzeichnis ~/work/CVSROOT können Sie löschen, da Sie es ja jederzeit wieder auschekcen können, wenn Sie eine Dateiendung vergessen haben.

Ignorieren von Dateien/Verzeichnissen

Bestimmte Dateien im Projektverzeichnis will man nicht in die Versionsverwaltung aufnehmen, z.B. Testdateien à la xxx oder die Sicherungsdateien vom vim (*~ - diese werden standardmäßig ignoriert), Klassendateien (*.class) usw.

Dafür gibt es auch Kommandozeilenargumente für cvs (z.B. -I '*.class'), aber besser ist es, diese Dateien ein für alle mal zu ignorieren. Die Konfigurationsdatei heißt CVSROOT/cvsignore. Leider existiert diese Datei in der Standardkonfiguration nicht und muss daher mit cvs add aufgenommen werden.

Hat man CVSROOT bereits ausgecheckt, so muss man die Datei mit einem Editor erzeugen:

~/work/CVSROOT > vim cvsignore

Bei mir hat die Datei folgenden Inhalt:

*.nfi
*.img
*.pyc
*.class
*.log
*.tmp
xxx
*.ppc
*.jffs*
*.cramfs

Dann muss man die Datei dem Repository hinzufügen und einchecken (commit):

~/work/CVSROOT > cvs add cvsignore
~/work/CVSROOT > cvs commit -m "zu ignorierende Dateien"
...

Labels: CVS, POS1-2

# Eingestellt von Harald R. Haberstroh @ 12:07 0 Kommentare

Anmeldung am Server

erfolgt über ssh. Man muss zunächst den Server und das CVS-Verzeichnis wählen. Die Anmeldung erfolgt bei jedem CVS-Befehl über ssh.

~ > export CVSROOT=:ext:USER@cvs.htlwrn.ac.at:/srv/cvsroot/USER
~ > export CVS_RSH=ssh

USER ist der Username (Projektuser, Evidenznummer).

Repository einrichten

~ > cvs init
Password:

damit wird ein Repository eingerichtet (dieser Schritt wird für Schüler vom Administrator beim Anlegen der User durchgeführt). Die Zeile mit Password: deutet das Anmelden am Server an. Hier ist das Passwort einzugeben. Die Meldungen vom CVS werden in diesem Text nicht angegeben.

Importieren eines Projektes

Soll ein Projekt ins CVS aufgenommen werden, so muss man zunächst ein Verzeichnis mit allen Unterverzeichnissen und Dateien anlegen (natürlich können später weitere Dateien hinzugefügt werden).
Dann importiert man das Projekt mit

~ > cd neues_projekt
~/neues_projekt > cvs import -m "eine Beschreibung des Projekts" projektname name start

projektname ist der Name des Projekts im CVS.
name ist das sog. Vendor Tag, eine Bezeichnung des Verkäufers (Entwicklers).
start ist das Release Tag, welches den Start des Projekts anzeigt (beide Tags sind eigentlich unnötig, aber vom CVS zwingen einzugeben...).

Nach dem Import kann (soll) das Verzeichnis neues_projekt gelöscht werden, denn wenn man an diesem Projekt nun weiterarbeiten will, muss es ausgecheckt werden.

Checkout

In einem Arbeitsverzeichnis (workspace) wird das Projekt ausgecheckt (dieser Vorgang ist normalerweise pro Arbeitsplatz und User nur einmal zu machen):

~ > cd workspace
~/workspace > cvs checkout projektname
Password:

Im Verzeichnis workspace wird nun ein Verzeichnis projektname angelegt. In diesem Verzeichnis kann man nun editieren, compilieren, debuggen usw. projektname kann auch ein Modulname sein (vgl. Einführung in CVS).

Update

Ein Update ist nötig, um Änderungen, die von anderen Personen oder von einem anderen Arbeistplatz aus eingecheckt wurden, in den eigenen workspace zu übernehmen. Hier kann es natürlich zu Konflikten kommen, d.h. dieselben Dateien haben sich im Repository und im eigenen Workspace geändert.

~/workspace > cvs update
Password:

Falls es Konflikte gibt, müssen diese gelöst werden.

commit - Änderungen ins Repository übernehmen (check in)

Änderungen im eigenen workspace sollten regelmäßig ins CVS übernommen werden. Dadurch werden von den geänderten Dateien neue Versionen angelegt. Arbeitet man im Team, so dürfen nur Sourcen eingecheckt (commit) werden, die sich zumindest übersetzen lassen. Noch besser ist es, wenn die nötigen Tests bestanden werden.

~/workspace > cvs commit -m "der Text, der beschreibt, was sich geändert hat"
Password:

add - neue Dateien aufnehmen

Werden neue Dateien angelegt, so müssen sie der Versionsverwaltung zunächst bekannt gegeben werden. Die Dateien werden aber erst wirklich aufgenommen, wenn ein commit gemacht wird.

 ~/workspace > cvs add neue_dateien...
Password:

Nun müssen die Dateien auch eingecheckt werden (commit):

~/workspace > cvs commit -m "der Text, der beschreibt, was sich geändert hat (welche Dateien neu sind)"
Password:

Genauere Informationen sind mit man cvs bzw. cvs –help zu finden.

Labels: CVS, POS1-2

# Eingestellt von Harald R. Haberstroh @ 11:47 0 Kommentare

     Main.java      1.4
     Gui.java       1.9
     Net.java       1.6    

     Main.java      1.4
     Gui.java       1.10
     Net.java       1.7    

Links
Ximbiot
Einführung in das Concurrent Versions System (CVS)
Wikipedia:CVS
ganz kurze Einführung in CVS (pdf)

Bücher
Versionsverwaltung mit CVS

Kurzreferenz
2-seitige Kurzreferenz

Labels: CVS, POS1-2

# Eingestellt von Harald R. Haberstroh @ 11:13 0 Kommentare

<projectdescription>
  <name>start-demo</name>
  <comment></comment>
  <projects>
  </projects>
  <buildspec>
  </buildspec>
  <natures>
  </natures>
</projectdescription>

<projectdescription>
  <name>start-demo</name>
  <comment></comment>
  <projects>
  </projects>
  <buildspec>
    <buildcommand>
      <name>org.eclipse.jdt.core.javabuilder</name>
      <arguments>
      </arguments>
    </buildcommand>
  </buildspec>
  <natures>
    <nature>org.eclipse.jdt.core.javanature</nature>
  </natures>
</projectdescription>

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry kind="output" path="bin"/>
</classpath>

Labels: CVS, eclipse, Fehler

# Eingestellt von Harald R. Haberstroh @ 15:00 0 Kommentare

     Main.java      1.4
     Gui.java       1.9
     Net.java       1.6    

     Main.java      1.4
     Gui.java       1.10
     Net.java       1.7    

Links
Ximbiot
Einführung in das Concurrent Versions System (CVS)
Wikipedia:CVS
ganz kurze Einführung in CVS (pdf)

Bücher
Versionsverwaltung mit CVS

Kurzreferenz
2-seitige Kurzreferenz

Labels: CVS, PR2

# Eingestellt von Harald R. Haberstroh @ 11:07 0 Kommentare

Anmeldung am Server

erfolgt über ssh. Man muss zunächst den Server und das CVS-Verzeichnis wählen. Die Anmeldung erfolgt bei jedem CVS-Befehl über ssh.

 ~ > export CVSROOT=:ext:USER@cvs.htlwrn.ac.at:/cvs/USER
~ > export CVS_RSH=ssh

USER ist der Username (Projektuser, Evidenznummer).

Repository einrichten

 ~ > cvs init
Password:

damit wird ein Repository eingerichtet (dieser Schritt wird für Schüler vom Administrator beim Anlegen der User durchgeführt). Die Zeile mit Password: deutet das Anmelden am Server an. Hier ist das Passwort einzugeben. Die Meldungen vom CVS werden in diesem Text nicht angegeben.

Importieren eines Projektes

Soll ein Projekt ins CVS aufgenommen werden, so muss man zunächst ein Verzeichnis mit allen Unterverzeichnissen und Dateien anlegen (natürlich können später weitere Dateien hinzugefügt werden).
Dann importiert man das Projekt mit

 ~ > cd neues_projekt
~/neues_projekt > cvs import -m "eine Beschreibung des Projekts" projektname name start

projektname ist der Name des Projekts im CVS.
name ist das sog. Vendor Tag, eine Bezeichnung des Verkäufers (Entwicklers).
start ist das Release Tag, welches den Start des Projekts anzeigt (beide Tags sind eigentlich unnötig, aber vom CVS zwingen einzugeben...).

Nach dem Import kann (soll) das Verzeichnis neues_projekt gelöscht werden, denn wenn man an diesem Projekt nun weiterarbeiten will, muss es ausgecheckt werden.

Checkout

In einem Arbeitsverzeichnis (workspace) wird das Projekt ausgecheckt (dieser Vorgang ist normalerweise pro Arbeitsplatz und User nur einmal zu machen):

 ~ > cd workspace
~/workspace > cvs checkout projektname
Password:

Im Verzeichnis workspace wird nun ein Verzeichnis projektname angelegt. In diesem Verzeichnis kann man nun editieren, compilieren, debuggen usw. projektname kann auch ein Modulname sein (vgl. Einführung in CVS).

Update

Ein Update ist nötig, um Änderungen, die von anderen Personen oder von einem anderen Arbeistplatz aus eingecheckt wurden, in den eigenen workspace zu übernehmen. Hier kann es natürlich zu Konflikten kommen, d.h. dieselben Dateien haben sich im Repository und im eigenen Workspace geändert.

 ~/workspace > cvs update
Password:

Falls es Konflikte gibt, müssen diese gelöst werden.

commit - Änderungen ins Repository übernehmen (check in)

Änderungen im eigenen workspace sollten regelmäßig ins CVS übernommen werden. Dadurch werden von den geänderten Dateien neue Versionen angelegt. Arbeitet man im Team, so dürfen nur Sourcen eingecheckt (commit) werden, die sich zumindest überetzen lassen. Noch besser ist es, wenn die nötigen Tests bestanden werden.

 ~/workspace > cvs commit -m "der Text, der beschreibt, was sich geändert hat"
Password:

add - neue Dateien aufnehmen

Werden neue Dateien angelegt, so müssen sie der Versionsverwaltung zunächst bekannt gegeben werden. Die Dateien werden aber erst wirklich aufgenommen, wenn ein commit gemacht wird.

 ~/workspace > cvs add neue_dateien...
Password:

Nun müssen die Dateien auch eingecheckt werden (commit):

 ~/workspace > cvs commit -m "der Text, der beschreibt, was sich geändert hat (welche Dateien neu sind)"
Password:

Genauere Informationen sind bei Links und Literatur zu CVS sowie mit man cvs bzw. cvs –help zu finden.

Labels: CVS, PR2

# Eingestellt von Harald R. Haberstroh @ 11:00 0 Kommentare

binäre Dateien

Unter binären Dateien verstehen wir hier Dateien, die nicht aus Textzeilen bestehen. Das sind z.B. Word- und Excel-Dateien, Bilder usw. CVS speichert normalerweise Textdateien und deren Zeilenänderungen. Dies ist bei Binärdateien nicht möglich. Wird z.B. eine Word-Datei nicht als Binärdatei markiert, so wird sie vom CVS zerstört (Subversion, der Nachfolger von CVS, kann gut mit Binärdateien umgehen, CVS ist aber immer noch weit verbreitet...).

Damit nicht bei jedem cvs add, cvs import" usw. die Option %-W *.gif -k 'b' (für jede Dateiendung von Binärdateien einmal!) angegeben werden muss, schreibt man diese Dateien in die Konfigurationsdatei CVSROOT/cvswrappers.

Die Konfiguration eines Repositories befindet sich im Projekt CVSROOT, welches man auscheckt, bearbeitet und dann wieder eincheckt (commit).

~/work > cvs checkout CVSROOT
...
~/work > cd CVSROOT
~/work/CVSROOT > vim cvswrappers

Die Datei sollte z.B. so aussehen (Zeilen mit # sind Kommentare, die schon enthalten sind):

# This file affects handling of files based on their names.
#
# The -m option specifies whether CVS attempts to merge files.
#
# The -k option specifies keyword expansion (e.g. -kb for binary).
#
# Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers)
#
#  wildcard [option value][option value]...
#
#  where option is one of
#  -f    from cvs filter      value: path to filter
#  -t    to cvs filter     value: path to filter
#  -m    update methodology   value: MERGE or COPY
#  -k    expansion mode    value: b, o, kkv, &c
#
#  and value is a single-quote delimited value.
# For example:
*.img -k 'b'
*.cramfs -k 'b'
*.jar -k 'b'
*.m2v -k 'b'
*.mvi -k 'b'
*.ppc -k 'b'
*.jffs* -k 'b'
*.nfi -k 'b'

# Microsoft
*.doc -k 'b'
*.xls -k 'b'
*.ppt -k 'b'

# Openoffice 1.*
*.stc -k 'b'
*.std -k 'b'
*.sti -k 'b'
*.stw -k 'b'
*.sxc -k 'b'
*.sxd -k 'b'
*.sxq -k 'b'
*.sxi -k 'b'
*.sxm -k 'b'
*.sxp -k 'b'
*.sxw -k 'b'

# dia
*.dia -k 'b'

# Bilder
*.xcf -k 'b'
*.jpg -k 'b'
*.bmp -k 'b'
*.gif -k 'b'
*.png -k 'b'

Für jeden Dateityp mit Binärformat gibt es eine Zeile der Form *.endung -k 'b'.

Diese Einträge speichern, den Editor beenden und das Projekt wieder commiten:

~/work/CVSROOT > cvs commit -m "Binärdateien bekanntgegeben"
...

Das Verzeichnis ~/work/CVSROOT können Sie löschen, da Sie es ja jederzeit wieder auschekcen können, wenn Sie eine Dateiendung vergessen haben.

Ignorieren von Dateien/Verzeichnissen

Bestimmte Dateien im Projektverzeichnis will man nicht in die Versionsverwaltung aufnehmen, z.B. Testdateien à la xxx oder die Sicherungsdateien vom vim (*~ - diese werden standardmäßig ignoriert), Klassendateien (*.class) usw.

Dafür gibt es auch Kommandozeilenargumente für cvs (z.B. -I '*.class'), aber besser ist es, diese Dateien ein für alle mal zu ignorieren. Die Konfigurationsdatei heißt CVSROOT/cvsignore. Leider existiert diese Datei in der Standardkonfiguration nicht und muss daher mit cvs add aufgenommen werden.

Hat man CVSROOT bereits ausgecheckt, so muss man die Datei mit einem Editor erzeugen:

~/work/CVSROOT > vim cvsignore

Bei mir hat die Datei folgenden Inhalt:

*.nfi
*.img
*.pyc
*.class
*.log
*.tmp
xxx
*.ppc
*.jffs*
*.cramfs

Dann muss man die Datei dem Repository hinzufügen und einchecken (commit):

~/work/CVSROOT > cvs add cvsignore
~/work/CVSROOT > cvs commit -m "zu ignorierende Dateien"
...

Labels: CVS, PR2

# Eingestellt von Harald R. Haberstroh @ 10:55 0 Kommentare

Will man auf eine alte Version zugreifen, so kann man beim Auschecken angeben, welchen Zustand man haben will, in dem man die Option -D datum angibt. datum kann entweder in der englischen Schreibweise angegeben werden (MM/TT/JJJJ), im ISO-Format (JJJJ-MM-TT) oder auch relativ als Text unter Hochkomma (z.B. 3 weeks ago, 1 day ago 27 minutes ago oder 3 days ago o.ä.).

Das Projekt python im Zustand vor einer Woche auschecken:

~/work > cvs co -D "1 week ago" python
cvs checkout: Updating python
U python/dreieck.py
U python/prim.py
~/work >

Das Projekt python im Zustand vom 22.9.2006 auschecken:

~/work > cvs co -D 09/22/2006 python
cvs checkout: Updating python
U python/calc.py
U python/craten.py
U python/dreieck.py
U python/ggt.py
U python/mittelwert.py
U python/muster.py
U python/prim.py
U python/pyintro.pdf
U python/raten.py
U python/summe.py
~/work >

Ältere Versionen sollten in eigene Verzeichnisse ausgecheckt werden. Sobald eine bestimmte Version ausgecheckt wurde, ist sie sticky (klebrig). Das bedeutet, dass sich alle Arbeiten in diesem ausgecheckten Verzeichnisbaum auf diese Version beziehen.

Daher ist das Weiterarbeiten an einer solchen Version nur sinnvoll bei Zweigen.

Labels: CVS, PR2

# Eingestellt von Harald R. Haberstroh @ 10:50 0 Kommentare

• 5ad-name-java-helloworld
• 5ad-name-c-helloworld
• 5ad-name-cpp-helloworld
• 5ad-name-ruby-helloworld
• 5ad-name-groovy-helloworld
• 5ad-name-python-helloworld

Labels: Aufgabe, C, C++, CVS, eclipse, groovy, Java, netbeans, PR5, Programmiersprachen, Python, ruby

# Eingestellt von Harald R. Haberstroh @ 19:53 0 Kommentare

Labels: allgemeines, CVS, Fehler, System

# Eingestellt von Harald R. Haberstroh @ 15:47 0 Kommentare

Labels: allgemeines, CVS, Fehler, System

# Eingestellt von Harald R. Haberstroh @ 13:18 1 Kommentare

1. Alle einzelnen Dateien des Projekts händisch commiten.
2. Das Projekt in einem neuen Verzeichnis auschecken.
3. Prüfen, ob alles da ist.
4. Das alte/originale Projekt löschen.
5. Das neue verwenden.

• Replacing CVS files
• Concurrent Versions System – Wikipedia

Labels: CVS, eclipse, Fehler, netbeans

# Eingestellt von Harald R. Haberstroh @ 14:36 0 Kommentare