Subversion e la gestione del ciclo di sviluppo di un progetto

Utilizzare e strutturare il repository di subversion è un requisito fondamentale per supportare correttamente il ciclo di sviluppo di un progetto software. Qui di seguito alcuni appunti che sintetizzano l'uso del repository.

Struttura del repository

Il repository è suddiviso nelle seguenti cartelle:

• Progetto 1
  • trunk
  • branches
  • tags
• Progetto 2
  • trunk
  • branches
  • tags

La cartella trunk è la cartella di lavoro principale, contiene i sorgenti nella versione attualmente in lavorazione (next release). La cartella branches contiene delle sottocartelle dei vari branches anche loro in fase di sviluppo: il nome delle cartelle è significativo (ad esempio, per lo sviluppo alla risoluzione di un bug, viene creata una cartella BUG-xxx). La cartella tags contiene invece le versioni alpha, beta, RC o final del progetto; qui i nomi sono nella forma [VER].[REL]-[alpha, beta, RCx].

Branching e merging

Il branching viene effettuato per creare una copia di lavoro per la risoluzione di un BUG o per l'implementazione di una nuova feature in prova senza intaccare il trunk principale: utilizzando i front end grafici di svn oppure il comando svn copy, è sufficiente creare una copia dal trunk nella cartella branches e nominarla in modo appropriato; occorre quindi (utilizzando svn switch) passare alla copia di lavoro il nuovo repository ed effettuare le modifiche. Al termine del ciclo di vita del branch, occorre fare un merge con il trunk principale (utilizzando svn merge) ed eventualmente cancellare il branch.

Rilascio di una versione (alpha, beta, RC, final)

Per rilasciare una versione, occorre effettuare una copia di trunk (si suppone ovviamente che la versione venga fatta sul trunk principale e non su un branch) con il comando svn copy o tramite il frontend grafico. A questo punto, per fare il building della versione occorre fare un checkout (svn co) dalla cartella tags di riferimento (ad es. svn co svn://server_svn/Progetto/tags/1.5-RC2)

Primi passi con Glade e gtkmm

Oggi ho cominciato a fare qualche piccolo esperimento con Anjuta, Glade e GTKmm.
Dopo aver creato una form con due pulsanti, ho creato un gestore di eventi minimale:

struct Gestore
{

   Gestore(Glib::RefPtr<Gnome::Glade::Xml> &the_xml)
   {
      dynamic_cast<Gtk::Button*>(the_xml->get_widget("button_due"))->signal_clicked().connect( sigc::mem_fun(*this, &Gestore::on_click_due) );

      dynamic_cast<Gtk::Button*>(the_xml->get_widget("button_uno"))->signal_clicked().connect( sigc::mem_fun(*this, &Gestore::on_click_uno) );
   }

   void on_click_due()
   {
      cout << "Click sul bottone DUE!!!" << endl;
   }

   void on_click_uno()
   {
      cout << "Click sul bottone UNO!!!" << endl;
   }
};

A questo punto, ecco il main (generato da Anjuta) con l'aggiunta del mio gestore:

int main (int argc, char *argv[])
{

   Gtk::Main kit(argc, argv);
   Gestore *gestore;

   //Load the Glade file and instiate its widgets:
   Glib::RefPtr<Gnome::Glade::Xml> refXml;
   try

   {
      refXml = Gnome::Glade::Xml::create(GLADE_FILE);

      gestore = new Gestore(refXml);
   }
   catch(const Gnome::Glade::XmlError& ex)
   {

      std::cerr << ex.what() << std::endl;
      return 1;
   }

   Gtk::Window* main_win = 0;
   refXml->get_widget("main_window", main_win);

   if (main_win)
   {
      kit.run(*main_win);
   }
   delete gestore;

   return 0;
}

C++ to HTML

http://www.bedaux.net/cpp2html/

Molto utile, complimenti Jasper!