Kennt sich hier jemand mit WinCVS aus?

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