Kennt sich hier jemand mit WinCVS aus?

[daniel775]

Hallo,


gibt es hier im Forum jemanden der mit WINCVS arbeitet? Ich habe gestern ein paar Stunden mit dem Programm herumexperimentiert. Erstmal nur mit Ordnern und Textdateien.

Zu meiner Frage:

Ich kann aus einen branch Ordner ein Release erzeugen. Muss ich die Release-Sourcen manuell aus dem branch Ordner rauskopieren? Wenn ich auf dem branch-Ordner rechtsklick->Release auswähle kommt ein prompt was nach Yes/No fragt. Wenn ich auf "Yes" klicke, dann kommt ein Dialog und ich kann kein Pfad angeben wo das Release gespeichert werden soll.

[Bernhard Geyer]

Versuchst du dich jetzt in ein einzuführendes Quellcodeverwaltungssystem einzuarbeiten?

Schmeiß (Win)CVS weg und beschäftige dich mit git oder mercurial.

[jaenicke]

Die Frage, die dort kommt, ist ja, wenn ich das richtig sehe, ob du fortfahren willst, obwohl nicht alles eingecheckt ist. Da sind noch veränderte Dateien vorhanden. Wenn du die erst committest, sollte die Meldung nicht mehr kommen.

Zitat:

Zitat von daniel775 (Beitrag 1383026)

gibt es hier im Forum jemanden der mit WINCVS arbeitet? Ich habe gestern ein paar Stunden mit dem Programm herumexperimentiert. Erstmal nur mit Ordnern und Textdateien.

Fängst du gerade an damit zu arbeiten als Versionskontrollsystem? Wenn ja: Das Ding ist hoffnungslos veraltet. Es gibt heute viele deutlich modernere, einfachere und bessere Möglichkeiten.

Wir haben es früher auch benutzt, sind aber schon vor Jahren zu SVN und mittlerweile zu Git gewechselt. Im Vergleich ist das wie Steinzeit zu Industriezeitalter. ;-)

Hier habe ich einmal etwas zum Einrichten von Git geschrieben:
https://www.entwickler-ecke.de/topic..._115462,0.html

[daniel775]

Zitat:

Fängst du gerade an damit zu arbeiten als Versionskontrollsystem?

Ja, da ich das ständige zwischenspeichern vom kompletten Entwicklungsordner leid bin. Auch experimentelle Nebenentwicklungen sind so schwer zu handeln. Wie ich gelesen und ausprobiert habe, sind solche CVS Systeme in der Lage branches und Tags zu mergen. Die Units der unterschiedlichen Entwicklungsstände per Hand zu mergen ist doch extrem lästig geworden!

Zitat:

Wir haben es früher auch benutzt, sind aber schon vor Jahren zu SVN und mittlerweile zu Git gewechselt. Im Vergleich ist das wie Steinzeit zu Industriezeitalter.

Das ist schön. Aber ich habe eher nach einen einfachen Freeware Offline System gesucht. Hab ich nicht erwähnt, das ich korrekt!
Sehe ich das richtig, dass bei Git oder SVN die Sourcen auf einen öffentlichen Server geladen werden müssen? Bzw. die Profile zur Verwaltung öffentlich sind?

[sakura]

Zitat:

Zitat von daniel775 (Beitrag 1383049)

Das ist schön. Aber ich habe eher nach einen einfachen Freeware Offline System gesucht. Hab ich nicht erwähnt, das ich korrekt!
Sehe ich das richtig, dass bei Git oder SVN die Sourcen auf einen öffentlichen Server geladen werden müssen? Bzw. die Profile zur Verwaltung öffentlich sind?

Wenn Du allein bist, dann brauchst Du noch nicht mal einen Server, du kannst alles über einen Git-Client, oder gar die Kommandozeile mit git.exe erledigen.

Als Client entweder den offiziellen GitHub Desktop, oder SourceTree von Atlassian.

...:cat:...

[jaenicke]

Zitat:

Zitat von daniel775 (Beitrag 1383049)

Sehe ich das richtig, dass bei Git oder SVN die Sourcen auf einen öffentlichen Server geladen werden müssen? Bzw. die Profile zur Verwaltung öffentlich sind?

Schau dir einfach mal meinen Link an. Da lege ich genau ein lokales Repository an und zeige wie man damit arbeitet.

Auch für dieses lokale Arbeiten ist Git tausendmal besser geeignet als CVS.

[hoika]

Hallo,
für SVN gibt es VisualSVN als lokalen SVN-Server.
Dann noch Tortoise-SVN als Browser-Erweiterung und fertig ist der Lack.

[jaenicke]

Zitat:

Zitat von hoika (Beitrag 1383055)

für SVN gibt es VisualSVN als lokalen SVN-Server.
Dann noch Tortoise-SVN als Browser-Erweiterung und fertig ist der Lack.

Das ist hier denke ich gar nicht nötig und zudem kann SVN weniger als Git. Aber auch diese Konstellation habe ich beschrieben:
https://www.entwickler-ecke.de/topic..._112612,0.html

[stalkingwolf]

Wir haben auch vor 1-2 Jahren GIT benutzt und sind alle begeistert.
Ok die Drittanbieter Clients sind nun nicht die besten, aber mit etwas einarbeit kommt man auch mit der Kommandozeile an alles dran.

[jaenicke]

Zitat:

Zitat von stalkingwolf (Beitrag 1383067)

Ok die Drittanbieter Clients sind nun nicht die besten, aber mit etwas einarbeit kommt man auch mit der Kommandozeile an alles dran.

Ich finde das Mergen auf der Kommandozeile absolut schrecklich. Das dauert ewig im Vergleich mit einem ordentlichen Tool wie BeyondCompare.

Das verwenden wir mit TortoiseGit zusammen und sind auch sehr zufrieden mit beidem.

[daniel775]

Ok, da ich das erste mal mit solchen Tools arbeite ergeben sich ein paar Fragen.
Und da ich am Anfang zu sehr Angst habe unwiederruflich Fehler zu machen bzw. dadurch Stundenlange
Arbeit zu verlieren, werde ich warscheinlich weiterhin ein gewisse Zeit parallel den ganzen Projektordner zwischenspeichern.
Ein zusätzliches Backup vom Projekt ist ja sowieso ratsam.


Versionskontrolle ist ein Thema mit verschiedenen Blickwinkeln.
Ich würde mal gerne eure Meinung zu folgenden Konzepten hören bzw. Vorschläge für Verbesserungen oder besserer Wartbarkeit.

Datei Version.inc

Code:

{$DEFINE SVERSION}
const
  SVERSION = 1001;

Datei Unit1.pas

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

{$I 'Version.inc'}

type

{$IFDEF SVERSION}
  {$IF SVERSION > 1000}
  TObjState = (
    stReady = 0,
    stWriting,
    stReading,
    stErrors,
    stDone
  );
  {$ELSE}
  TObjState = (
    stReady = 0,
    stInProgress,
    stErrors,
    stDone
  );
  {$IFEND}
{$ELSE}
  TObjState = (
    stReady = 0,
    stInProgress,
    stErrors,
    stDone
  );
{$ENDIF}

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    function getStateAsWord(objState: TObjState): Word;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

function TForm1.getStateAsWord(objState: TObjState): Word;
begin
{$IFDEF SVERSION}
  {$IF SVERSION <= 1000}
    case Ord(objState) of
      0: result := Ord(stReady);
      1: result := Ord(stInProgress);
      2: result := Ord(stErrors);
      3: result := Ord(stDone);
    end;
  {$ELSEIF SVERSION > 1000}
    case Ord(objState) of
      0: result := Ord(stReady);
      1: result := Ord(stWriting);
      2: result := Ord(stReading);
      4: result := Ord(stErrors);
      5: result := Ord(stDone);
    end;
  {$IFEND}
{$ELSE}
  case Ord(objState) of
    0: result := Ord(stReady);
    1: result := Ord(stInProgress);
    2: result := Ord(stErrors);
    3: result := Ord(stDone);
  end;
{$ENDIF}
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
begin
  i :=  getStateAsWord(stInProgress);
end;

end.

Bei dem oberen Konzept ist mir klar, das je größer ein Projekt wird desto unübersichtlicher wird der Sourcecode und die Wartbarkeit leidet.
Redundanzen in unterschiedlichen Versionen trägt nicht zur lesbarkeit bei.
Ist aber eine schöne Möglichkeit für Migrationen. Der Compiler hilft beim überprüfen von Abhängigkeiten und beim hinzufügen der richtigen Versionsabhängigen Sourcen.

Ist dieses Konzept durch gute CVS Systeme veraltet?


unit1.pas vom 01.10.2017 um 13:11 Uhr, TAG "Version1000" im GIT

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type

  TObjState = (
    stReady = 0,
    stInProgress,
    stErrors,
    stDone
  );

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    function getStateAsWord(objState: TObjState): Word;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

function TForm1.getStateAsWord(objState: TObjState): Word;
begin
  case Ord(objState) of
    0: result := Ord(stReady);
    1: result := Ord(stInProgress);
    2: result := Ord(stErrors);
    3: result := Ord(stDone);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
begin
  i :=  getStateAsWord(stInProgress);
end;

end.

unit1.pas vom 10.10.2017 um 20:23 Uhr, TAG Version1001 im GIT

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type

  TObjState = (
    stReady = 0,
    stWriting,    // HINZUGEFÜGT
    stReading,    // HINZUGEFÜGT
    stErrors,
    stDone
  );

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    function getStateAsWord(objState: TObjState): Word;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

function TForm1.getStateAsWord(objState: TObjState): Word;
begin
  case Ord(objState) of
    0: result := Ord(stReady);
    1: result := Ord(stWriting);   // HINZUGEFÜGT
    2: result := Ord(stReading);   // HINZUGEFÜGT
    4: result := Ord(stErrors);
    5: result := Ord(stDone);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
begin
  i :=  getStateAsWord(stReading);
end;

end.

Wie sieht eure Versionierung aus?

Wann beginnt sie?
Schon in der Entwicklungsphase oder spät kurz vor Veröffentlichung?

Wo fängt eure Versionshistorie an?
Beispiel:

Major, Minor, Release, Build

0.1.0 Build 0: Projektstatus: alpha: Beginn des Projekts
0.1.0 Build 5: Projektstatus: alpha: Mainform mit der Menüstruktur
0.2.0 Build 26: Projektstatus: alpha: Mainform mit Menüstruktur und ersten funktionen
0.2.1 Build 40: Projektstatus: alpha: Bugfix bei den ersten funktionen
0.3.0 Build 48: Projektstatus: alpha: Mainformfunktionalität erweitert
...
0.6.1 Build 102: Projektstatus: alpha: Bugfix an der Klasse xy
0.6.2 Build 105: Projektstatus: alpha: Bugfix an der Klasse xyz
0.7.0 Build 120: Projektstatus: beta: Datenbankanbindung in den Mainform integriert
...
0.11.0 Build 320: Projektstatus: beta: Neue Datenbankfelder hinzugefügt
0.11.1 Build 355: Projektstatus: beta: Bugfix Querykomponente in Form xy für neue Datenbankfelder angepasst.
0.11.1 Build 357: Projektstatus: beta: Erste Betatests
0.11.2 Build 360: Projektstatus: beta: Diverse Bugfixes
1.0.0 Build 365: Projektstatus: stable: Erste Veröffentlichung
1.0.1 Build 368: Diverse Bugfixes
1.1.0 Build 385: Neue Klasse xy hinzugefügt
1.1.1 Build 390: Diverse Bugfixes an der neuen Klasse
2.0.0 Build 553: Mainform überarbeitet, Toolbarleiste hinzugefügt, Statusleiste hinzugefügt, verhalten beim Resizing angepasst etc.

Welches Konzept verfolgt ihr dabei? Um Major, Minor, Release zu inkrementieren?
inc Release: Bugfixes?
inc Minor: Änderung vom Funktionsumfang?
inc Major: Bei Inkompatibilität zu kleinen Versionen bzw. bei grundlegenden Veränderungen am Aussehen oder Features?


Was sind sinnvolle Namen für Tags oder branches CVS Systemen?
RC_1, alpha, beta?

Wann und zu welchen Zeitpunkt sollten diese angelegt werden?


Wie sehen eure Update Konzepte aus? Nutzt ihr vorgefertigte Komponenten?
- FTP-Server und Ordnerstruktur
- Download der nötigen Dateien (HTTP? FTP?)
- Methoden zum Versionsvergleich
- Updatemethoden ( shellexecute(0, 'open', '.\update.exe', nil, nil, SW_NORMAL), self.close ?)

[Bernhard Geyer]

Für die ganzen neuen Fragen solltest du neue Threads erstellen.
Konzentrieren wir uns doch hier auf das Theme Quellcodeverwaltung.

Zitat:

Und da ich am Anfang zu sehr Angst habe unwiederruflich Fehler zu machen bzw. dadurch Stundenlange Arbeit zu verlieren,

Kann mit einer Quellcodeverwaltung eigentlich nicht passieren.
Außer zu "spielst" zu viel mit branches rum und verlierst den Überblick.

Zitat:

werde ich warscheinlich weiterhin ein gewisse Zeit parallel den ganzen Projektordner zwischenspeichern.

Sichere die Datenbank der Quellcodeverwaltung und gut ist.

Zitat:

Ein zusätzliches Backup vom Projekt ist ja sowieso ratsam.

Deine Quellcodeverwaltung ist dein Backup.
Das solltest du gut und regelmäßig sichern. Mindestens 1* pro Tag.
In manchen Firmen werden Backups sogar mehrmals pro Tag durchgeführt.

[TigerLilly]

Das sehe ich anders. Wenn daniel775 neu damit beginnt, ein VCS auszuprobieren, sollte er definitiv NICHT das VCS als Backup nutzen.

Besser:
Ein kleines sinnfreies Testprojekt anlegen + damit alle Funktionen ausprobieren:
- add, commit, update
- remove, move, rename
- branchen, taggen
- mergen
- diff,log

Bei der Anwendung auf ein echtes Projekt, jedenfalls ein Backup unabhängig vom VCS. Und wenn das gut automatisiert ist, kann man das ruhig beibehalten. Quasi Gürtel UND Hosenträger.

[Sherlock]

Sicher, was Du gerne sichern möchtest, mit Zeit und Erfahrung merkst Du, was Du nicht brauchst.

Sherlock

[TigerLilly]

:-)
Wenn du Glück hast, merkst du mit der Zeit und der Erfahrung, was du brauchst.
Wenn du kein Glück hast, merkst du mit der Zeit und der Erfahrung, was du gebraucht hättest.

Zuviel sichern gibt es nicht.
Wenn man an die Sicherung denken muss, ist sie falsch aufgesetzt.
Wenn man überlegen muss, was man sichern soll+was nicht, auch.
Datensicherung ist nicht dasselbe wie Archivierung.

[daniel775]

Zitat:

Zitat von TigerLilly (Beitrag 1383474)

:-)
Wenn du Glück hast, merkst du mit der Zeit und der Erfahrung, was du brauchst.
Wenn du kein Glück hast, merkst du mit der Zeit und der Erfahrung, was du gebraucht hättest.

Zuviel sichern gibt es nicht.
Wenn man an die Sicherung denken muss, ist sie falsch aufgesetzt.
Wenn man überlegen muss, was man sichern soll+was nicht, auch.
Datensicherung ist nicht dasselbe wie Archivierung.

:thumb: