332 γραμμές
27 KiB
Markdown
332 γραμμές
27 KiB
Markdown
|
+++
|
|||
|
|
title = 'CVS: Concurrent Versions System (\...)'
|
|||
|
|
date = '1999-10-01T00:00:00Z'
|
|||
|
|
description = ''
|
|||
|
|
author = 'Παπαδογιαννάκης Βαγγέλης για το Magaz ( magaz.hellug.gr(http://magaz.hellug.gr) )'
|
|||
|
|
issue = ['Magaz 19']
|
|||
|
|
issue_weight = 3
|
|||
|
|
+++
|
|||
|
|
|
|||
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
*Το CVS (Concurrent Versions System) είναι ένα σύστημα που έχει αναπτυχθεί από προγραμματιστές για προγραμματιστές. Δηλαδή, θα μου πείτε; Ε, λοιπόν, είναι
|
|||
|
|
φτιαγμένο για \`\`προγραμματιστικούς\'\' σκοπούς. Ας δούμε όμως αναλυτικά τι κάνει, πώς λειτουργεί, και πώς μπορεί να μας φανεί χρήσιμο.*
|
|||
|
|
|
|||
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
**1. ΕΙΣΑΓΩΓΗ**
|
|||
|
|
-------------------------------------
|
|||
|
|
|
|||
|
|
- [1.1 ΤΙ ΚΑΝΕΙ ΤΟ CVS](#ss1.1)
|
|||
|
|
- [1.2 ΠΩΣ ΛΕΙΤΟΥΡΓΕΙ ΤΟ CVS.](#ss1.2)
|
|||
|
|
|
|||
|
|
**2. ΣΤΗΣΙΜΟ CVS ΣΤΟΝ ΥΠΟΛΟΓΙΣΤΗ ΣΑΣ**
|
|||
|
|
------------------------------------------------------------
|
|||
|
|
|
|||
|
|
- [2.1 LOGIN ΚΑΙ ΕΡΓΑΣΙΑ ΣΕ ΕΝΑ CVS SERVER](#ss2.1)
|
|||
|
|
- [2.2 ΑΝΑΝΕΩΣΗ ΤΟΥ ΚΩΔΙΚΑ](#ss2.2)
|
|||
|
|
|
|||
|
|
**3. CVS FOR DEVELOPERS**
|
|||
|
|
-----------------------------------------------
|
|||
|
|
|
|||
|
|
- [3.1 Αλλαγές στον κώδικα και πώς να τις ενσωματώσουμε στο Repository του Project.](#ss3.1)
|
|||
|
|
- [3.2 CONFLICTS](#ss3.2)
|
|||
|
|
- [3.3 ΠΑΡΑΚΟΛΟΥΘΗΣΗ ΑΛΛΑΓΩΝ](#ss3.3)
|
|||
|
|
- [3.4 ΠΡΟΣΘΕΣΗ - ΑΦΑΙΡΕΣΗ ΑΡΧΕΙΩΝ](#ss3.4)
|
|||
|
|
|
|||
|
|
**4. ΕΠΙΛΟΓΟΣ**
|
|||
|
|
-------------------------------------
|
|||
|
|
|
|||
|
|
|
|||
|
|
### [1. ΕΙΣΑΓΩΓΗ]{#s1}
|
|||
|
|
|
|||
|
|
### [1.1 ΤΙ ΚΑΝΕΙ ΤΟ CVS]{#ss1.1}
|
|||
|
|
|
|||
|
|
Το cvs θα λέγαμε ότι χρησιμοποιείται για την διατήρηση και ανάπτυξη ενός προγραμματιστικού έργου (module) μεγάλης εμβέλειας, όπου πολλοί προγραμματιστές μπορούν
|
|||
|
|
να εργάζονται ταυτόχρονα - ή σχεδόν ταυτόχρονα όπως θα δούμε και παρακάτω - για την ολοκλήρωση του. Διατηρεί μια δομή με αρχεία, καταλόγους αρχείων και κώδικα
|
|||
|
|
που είναι προσπελάσιμα από κάθε προγραμματιστή που έχει τη διάθεση να συνεισφέρει. Φυσικά, ο καθένας μπορεί να κάνει αλλαγές που πιστεύει ότι είναι σωστές για
|
|||
|
|
την καλύτερη λειτουργία του υπό αν άπτυξη προγράμματος.
|
|||
|
|
|
|||
|
|
### [1.2 ΠΩΣ ΛΕΙΤΟΥΡΓΕΙ ΤΟ CVS.]{#ss1.2}
|
|||
|
|
|
|||
|
|
Η αρχή λειτουργίας του είναι πολύ απλή. Σε κάποιο server κάπου στο παγκόσμιο δίκτυο, είναι συγκεντρωμένος ο κώδικας ενός προγράμματος. Όταν κάποιος από την
|
|||
|
|
ομάδα των προγραμματιστών που έχουν αναλάβει το project θέλει να κάνει μια αλλαγή στον κώδικα, αρκεί να συνδεθεί με τον εν λόγω server και να κατεβάσει το
|
|||
|
|
αρχείο στο οποίο θέλει να κάνει την αλλαγή.
|
|||
|
|
|
|||
|
|
Κάνει την αλλαγή και μετά το ανεβάζει\... Φυσικά, οι λέξεις \"ανεβάσει\" και \"κατεβάσει\" δεν είναι οι καλύτερες για την περιγραφή της εργασίας που γίνεται,
|
|||
|
|
μια και το CVS αναλαμβάνει να \`\`ενημερώσει\'\' όλα τα αρχεία που έχουν αλλάξει. Αυτό σημαίνει, ότι ο χρήστης στον τοπικό του δίσκο έχει όλα τα αρχεία του
|
|||
|
|
project (ακόμα και το README) ακόμα και αν το μόνο που κάνει είναι\... ορθογραφική διόρθωση.
|
|||
|
|
|
|||
|
|
Μόλις γίνει μια ενημέρωση, το CVS \`\`μαρκάρει\'\' την νέα έκδοση με ένα minor αριθμό παραπάνω. Αυτό σημαίνει ότι από 1.3 το κάνει 1.4 (Φυσικά αυτή η αλλαγή
|
|||
|
|
μπορεί να είναι και από 1.5.3.4.2 σε 1.5.3.4.3). Την ίδια στιγμή, ο χρήστης που έκανε την αλλαγή, είναι υποχρεωμένος να γράψει και μια μικρή παρατήρηση. Επίσης
|
|||
|
|
μαρκάρεται η ώρα της αλλαγής και το όνομα αυτού που την έκανε. Κάτι τέτοιο βοηθάει τους άλλους προγραμματιστές να μπορούν με ευκολία να απαντήσουν σε ερωτήματα
|
|||
|
|
του τύπου
|
|||
|
|
|
|||
|
|
- Ποιός έκανε την αλλαγή;
|
|||
|
|
- Πότε έγινε;
|
|||
|
|
- Γιατί έγινε;
|
|||
|
|
- Τι προσφέρει στον κώδικα αυτή η αλλαγή;
|
|||
|
|
|
|||
|
|
Αλλά πριν συνεχίσουμε, ας δούμε πώς μπορούμε να στήσουμε το δικό μας δέντρο CVS με απλές εντολές.
|
|||
|
|
|
|||
|
|
|
|||
|
|
### [2. ΣΤΗΣΙΜΟ CVS ΣΤΟΝ ΥΠΟΛΟΓΙΣΤΗ ΣΑΣ]{#s2}
|
|||
|
|
|
|||
|
|
Πριν να μπορέσουμε να τρέξουμε και να κάνουμε την ενημέρωση, πρέπει να έχουμε δηλώσει μια μεταβλητή συστήματος, την CVSROOT. Αυτή είναι η διαδρομή στον
|
|||
|
|
απομακρυσμένο server που βρίσκονται τα προς λήψη αρχεία.
|
|||
|
|
|
|||
|
|
Αν και λογικά για να διαβάζετε αυτό το άρθρο ξέρετε πως να θέσετε μια μεταβλητή συστήματος, θυμίζω για τους νέους: Ο τρόπος είναι ανάλογος του shell που
|
|||
|
|
χρησιμοποιεί ο καθένας.
|
|||
|
|
|
|||
|
|
Η πλειοψηφία έχει bash (CVSROOT=\':pserver:anonymous\@cvs.enlightenment.org:/cvs/enlightenment\' ; export CVSROOT) και υπάρχουν και λίγοι (αλλά δυνατοί!) με csh
|
|||
|
|
ή κάτι αντίστοιχο (setenv CVSROOT = \':pserver:anonymous\@cvs.enlightenment.org:/cvs/enlightenment\')
|
|||
|
|
|
|||
|
|
### [2.1 LOGIN ΚΑΙ ΕΡΓΑΣΙΑ ΣΕ ΕΝΑ CVS SERVER]{#ss2.1}
|
|||
|
|
|
|||
|
|
Επόμενο βήμα είναι να κάνουμε login σε ένα CVS server, στην παραπάνω περίπτωση θα κάνουμε Login στον CVS server που περιέχει τον enlightenment.
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs login
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Σε αυτό το σημείο θα σας ζητήσει ένα password, πατήστε απλά ENTER. Δεν θα χρειαστεί να ξανακάνουμε αυτό το βήμα, εκτός αν κόψουμε πλέον τη σύνδεση!
|
|||
|
|
|
|||
|
|
Από αυτό το σημείο και πέρα, θα πάρουμε όλη τη δομή καταλόγου του project στο δίσκο μας.
|
|||
|
|
|
|||
|
|
**ΣΗΜΕΙΩΣΗ: Αν και για να μπορέσουμε να κάνουμε τον enlightenment να δουλεύει, πρέπει να κατεβάσουμε πολλά modules, εδώ θα αναφερόμαστε σε ένα για συντομία
|
|||
|
|
χρόνου και χώρου.**
|
|||
|
|
|
|||
|
|
Ο enlightenment αποτελείται από πολλά modules. Αυτά είναι:
|
|||
|
|
|
|||
|
|
- e
|
|||
|
|
- Eterm
|
|||
|
|
- imlib
|
|||
|
|
- fnlib
|
|||
|
|
- esound
|
|||
|
|
- audiofile
|
|||
|
|
|
|||
|
|
Εμείς θα ασχοληθούμε με το module της imlib, μιας βιβλιοθήκης διαχείρισης γραφικών (μπορείτε φυσικά να διαλέξετε ένα άλλο module)
|
|||
|
|
|
|||
|
|
Την κατεβάζουμε λοιπόν τοπικά με την εντολή:
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs -z3 checkout imlib
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Φυσικά, μπορούμε να πάρουμε και πάνω από ένα module με μια εντολή:
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs -z3 checkout imlib fnlib ...
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Σε αυτό το σημείο έχουμε κατεβάσει όλο τον κώδικα του module, και είμαστε έτοιμοι να κάνουμε τις αλλαγές που θα κρίνουμε απαραίτητες ή αν δεν είμαστε στο
|
|||
|
|
development team απλά να κάνουμε compile τον νέο μας κώδικα!
|
|||
|
|
|
|||
|
|
**ΠΡΟΣΟΧΗ: Δεν είναι ανάγκη να κάνουμε καμμία αλλαγή, οι άνθρωποι που γράφουν τον κώδικα ξέρουν τι κάνουν.** Αν και εσείς ξέρετε τι κάνετε, δεν το βρίσκω πρέπoν
|
|||
|
|
να τους αλλάξουμε των κώδικά τους!! (εκτός και αν ανήκετε στο development team).
|
|||
|
|
|
|||
|
|
Ας δούμε το directory structure που δημιουργήθηκε στο δίσκο μας. Έχει δημιουργηθεί ο κατάλογος `imlib/` που περιέχει όλον τον κώδικα, και ένας κατάλογος `CVS/`,
|
|||
|
|
στον οποίο το cvs έχει καταγεγραμμένες πληροφορίες για καθένα από τα αρχεία ώστε να μπορεί να καταλάβει τι αλλαγές κάναμε από τότε που το κατεβάσαμε (Αυτό
|
|||
|
|
χρειάζεται για την περίπτωση που θέλουμε να το ανεβάσουμε με δικές μας αλλαγές, ώστε να ξέρει τι log file να δημιουργήσει).
|
|||
|
|
|
|||
|
|
Έχουμε πλέον την πιο νέα έκδοση του πακέτου αυτού!
|
|||
|
|
|
|||
|
|
Φυσικά, αυτό δεν είναι πάντα καλό, μια και πολλές φορές το πακέτο που μόλις κατεβάσαμε δεν κάνει compile καν! Φυσικό, όπως αντιλαμβάνεστε, μια και μιλάμε για
|
|||
|
|
ΧΟΝΤΡΟ development, όπου συνήθως ενσωματώνονται νέα χαρακτηριστικά. Είναι λοιπόν πιθανότατο ακόμα και αν κάνει compile να μας \`\`κολλάει\'\' συνεχώς (core
|
|||
|
|
dumped κ.λπ.). Σε αυτή την περίπτωση ή προσπαθούμε να το φτιάξουμε μόνοι μας, ή\... περιμένουμε να βγει νεότερη έκδοση. Σε καμία περίπτωση μη στείλετε mail
|
|||
|
|
στους developers να τους πείτε \`\`δεν δουλεύει αυ τό\'\'. Πιστέψτε με, το ξέρουν καλύτερα από εμάς!!
|
|||
|
|
|
|||
|
|
### [2.2 ΑΝΑΝΕΩΣΗ ΤΟΥ ΚΩΔΙΚΑ]{#ss2.2}
|
|||
|
|
|
|||
|
|
Την επόμενη φορά που θα πάμε στο CVS server για ανανέωση, δεν θα κάνουμε checkout, αλλά update. Κάτι τέτοιο σημαίνει ότι θα μας έρθουν μόνο τα πακέτα που έχουν
|
|||
|
|
αλλάξει, και όχι όλα από την αρχή. Αυτό μπορεί να γίνει με την εντολή:
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs -z3 update -Pd imlib
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Φυσικά, κάνουμε την προσευχή μας να κάνει compile. Αν και πιστεύω ότι δεν θα εισακουστεί (μιλάω εκ πείρας), πάντα υπάρχουν οι εξαιρέσεις, και πάντα γίνονται
|
|||
|
|
θαύματα.
|
|||
|
|
|
|||
|
|
Οι απλοί χρήστες που θέλουν να έχουν την πιο νέα έκδοση του λογισμικού στο δίσκο τους, και όχι να γράφουν κώδικα, **μόλις τελείωσαν το διάβασμα αυτού του
|
|||
|
|
άρθρου**. Στη συνέχεια, αυτό που εξηγείται είναι το πως το cvs καταφέρνει να τα βγάζει πέρα με τυχόν conflicts (π.χ.: δύο developers την ίδια στιγμή έκαναν
|
|||
|
|
revisions στο ίδιο αρχείο), το πως μπορούμε να δημιουργήσουμε νέα αρχεία ή και ολόκληρα directories και να τα συμπεριλάβουμε στο repository του module.
|
|||
|
|
|
|||
|
|
Όσοι δεν ασχολείστε με προγραμματισμό, μην συνεχίσετε το διάβασμα, εκτός αν θέλετε να μάθετε εγκυκλοπαιδικά πως δουλεύει το CVS. Δεν είναι τίποτα δυσνόητο, αλλά
|
|||
|
|
κατά πάσα πιθανότητα δε θα σας ενδιαφέρει.
|
|||
|
|
|
|||
|
|
|
|||
|
|
### [3. CVS FOR DEVELOPERS]{#s3}
|
|||
|
|
|
|||
|
|
### [3.1 Αλλαγές στον κώδικα και πώς να τις ενσωματώσουμε στο Repository του Project.]{#ss3.1}
|
|||
|
|
|
|||
|
|
Οι αλλαγές που τυχόν θα γίνουν θα γραφούν τοπικά στο δικό σας δίσκο, και όχι στο server. Αυτό πάει να πει ότι οι άλλοι developers δεν θα δουν τις αλλαγές σας,
|
|||
|
|
μέχρι να σιγουρευτείτε ότι αυτό που κάνατε δουλεύει και μόνο αν του το πείτε θα τα ανεβάσει. Αυτό γίνεται με την εντολή **`/cvs commit`**
|
|||
|
|
|
|||
|
|
Πριν γίνει όμως το γράψιμο στο server, πρέπει πάνω του να υπάρχει η έκδοση των αρχείων που είχατε κατεβάσει ώστε τυχόν αλλαγές που έκαναν άλλοι developers να
|
|||
|
|
μην χαθούν (αυτός είναι ο σκοπός του directory CVS/ που έχει δημιουργηθεί στην ιεραρχία καταλόγων στο δίσκο σας). Κάνουμε λοιπόν ένα
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs update imlib
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Έστω ότι κάναμε αλλαγές στο αρχείο README, αλλά άλλος ένας έχει κάνει αλλαγές τόσο στο ίδιο αρχείο όσο και στο αρχείο Makefile στο μεσοδιάστημα. Μετά την εντολή
|
|||
|
|
update, βλέπουμε την έξοδο:
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs update: Updating .
|
|||
|
|
> U Makefile
|
|||
|
|
> RCS file: /imlib/README
|
|||
|
|
> retrieving revision 1.5
|
|||
|
|
> retrieving revision 1.6
|
|||
|
|
> Merging differences between 1.5 and 1.6 into README
|
|||
|
|
> M README
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Όλα αυτά σημαίνουν:
|
|||
|
|
|
|||
|
|
> U Makefile
|
|||
|
|
|
|||
|
|
Οι αλλαγές που έκανε ο άλλος κατέβηκαν στο δίσκο μας.
|
|||
|
|
|
|||
|
|
> RCS file: /imlib/README
|
|||
|
|
> retrieving revision 1.5
|
|||
|
|
> retrieving revision 1.6
|
|||
|
|
> Merging differences between 1.5 and 1.6 into README
|
|||
|
|
|
|||
|
|
Αυτό μας δείχνει ότι οι δύο revisions 1.5 και 1.6 του αρχείου README συγχωνεύτηκαν σε ένα αρχείο, το README, τοπικά, στο δίσκο μας.
|
|||
|
|
|
|||
|
|
> M README
|
|||
|
|
|
|||
|
|
Το γράμμα Μ, φανερώνει ότι το αρχείο έχει αλλαχθεί από εμάς, και ότι οι αλλάγες δεν ανέβηκαν ακόμα (φυσικό αυτό, ένα update κάναμε.
|
|||
|
|
|
|||
|
|
Ας μην ξεχνάμε ότι τώρα το αρχείο README περιλαμβάνει και τις αλλαγές του άλλου!!! Καλό (απαραίτητο για να είμαι ακριβής) θα είναι να κάνουμε έναν έλεγχο να
|
|||
|
|
δούμε αν δουλεύει ακόμα ο κώδικας. Φυσικά, στην περίπτωσή μας, δεν είναι ανάγκη, γιατί είναι ένα text κείμενο, που δεν επηρεάζει τη λειτουργικότητα του όλου
|
|||
|
|
project (αυτό δεν σημαίνει ότι δεν θα ήταν καλό να ελέγξουμε τί αλλαγές έκανε ο άλλος).
|
|||
|
|
|
|||
|
|
Καλό θα είναι πριν κάνουμε commit, να ξανακάνουμε update, ώστε στο διάστημα που κάναμε τον έλεγχο να μην έγινε καμμία άλλη αλλαγή (πράγμα σπάνιο). Η έξοδος,
|
|||
|
|
καλώς εχόντων των πραγμάτων, θα είναι:
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs update: Updating .
|
|||
|
|
> M README
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
\`Αρα, οι μόνες αλλαγές είναι στο δίσκο μας. Πάμε για commit.
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> $ cvs commit
|
|||
|
|
> README
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Τώρα θα μας ζητηθεί να γράψουμε ένα μικρό κείμενο που θα εξηγεί στους άλλους τι αλλαγές κάναμε και γιατί. Μόλις τελειώσουμε, θα πάρουμε από το CVS:
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> Checking in README;
|
|||
|
|
> /imlib/README,v <-- README
|
|||
|
|
> new revision: 1.7; previous revision: 1.6
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Τώρα, οι αλλαγές μας θα είναι πάνω στο server, και οι άλλοι προγραμματιστές όταν θα κάνουν cvs update θα τις πάρουν στο δίσκο τους.
|
|||
|
|
|
|||
|
|
### [3.2 CONFLICTS]{#ss3.2}
|
|||
|
|
|
|||
|
|
Κάτι τέτοιο είναι εφικτό στην περίπτωση που οι γραμμές που αλλάζουν οι δύο developers δεν είναι ίδιες. Αν όμως τύχει και αλλάζουν και οι δύο την ίδια γραμμή;
|
|||
|
|
|
|||
|
|
Σε αυτή την περίπτωση έχουμε conflict, και το cvs μας αφήνει να βρούμε μόνοι μας τη λύση. Μας αφήνει με ένα αρχείο, στο οποίο φαίνεται η περιοχή που έγινε το
|
|||
|
|
conflict, περιέχει και τις δύο απόψεις (τη δική μας και αυτή που έρχεται σε αντίθεση με τη δική μας, του άλλου προγραμματιστή) και είμαστε αναγκασμένοι να το
|
|||
|
|
ελέγξουμε, να κάνουμε τυχόν αλλαγές και να ξανακάνουμε commit. Αυτό, αν και ακούγεται δύσκολο, είναι πολύ εύκολο (και φυσικά απαραίτητο) γιατί ο τρόπος που μας
|
|||
|
|
έχει φτιάξει το αρχείο βοηθάει στην κ ατανόηση του προβλήματος που έχει δημιουργηθεί. Από εκεί και πέρα, είναι απαραίτητο να έχουμε σωστή κρίση ώστε να αφήσουμε
|
|||
|
|
στον κώδικα την καλύτερη λύση από τις δύο προτεινόμενες (ακόμα και αν αυτή δεν είναι η δική μας!)
|
|||
|
|
|
|||
|
|
### [3.3 ΠΑΡΑΚΟΛΟΥΘΗΣΗ ΑΛΛΑΓΩΝ]{#ss3.3}
|
|||
|
|
|
|||
|
|
Για να μπορέσουμε να δούμε τις αλλαγές που έχουν γίνει σε ένα αρχείο του project, θα χρησιμοποιήσουμε την εντολή **`cvs log`**
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs log README
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Θα μας παρουσιαστεί ένα κατεβατό με μια περιγραφή του αρχείου, τον τρέχοντα αριθμό αναθεώρησης, καθώς και όλες τις αναθεωρήσεις που του έχουν γίνει, καθώς και
|
|||
|
|
το log για κάθε μια από αυτές.
|
|||
|
|
|
|||
|
|
### [3.4 ΠΡΟΣΘΕΣΗ - ΑΦΑΙΡΕΣΗ ΑΡΧΕΙΩΝ]{#ss3.4}
|
|||
|
|
|
|||
|
|
Η πρόσθεση και η αφαίρεση αρχείων γίνεται όπως και με τις αλλαγές σε αρχεία, αφού πρώτα καταγραφούν οι αλλαγές στο cvs directory που έχει δημιουργήσει. Με αυτό
|
|||
|
|
τον τρόπο (και μόνο) μπορεί το cvs να ξεχωρίσει τι αλλαγές έχουν γίνει.
|
|||
|
|
|
|||
|
|
#### ΠΡΟΣΘΕΣΗ
|
|||
|
|
|
|||
|
|
Το να προσθέσουμε απλά ένα αρχείο στο directory structure του δίσκου μας, δεν είναι αρκετό. Σε αυτή την περίπτωση, το cvs θα μας πει με πολύ κομψό τρόπο ότι δεν
|
|||
|
|
έχει ακουστά αυτό το αρχείο ακόμα (CVS doesn\'t know about this file yet) στο επόμενο update.
|
|||
|
|
|
|||
|
|
Για να το προσθέσουμε, πρέπει να κάνουμε cvs add. Έστω ότι δημιουργήσαμε το αρχείο colors.c. Για να ολοκληρωθεί η διαδικασία πρόσθεσης του αρχείου, κάνουμε τα
|
|||
|
|
εξής βήματα (με \$ αρχίζουν οι εντολές που δίνουμε, τα άλλα είναι η έξοδος του cvs).
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> $ cvs add colors.c
|
|||
|
|
> cvs add: scheduling file `colors.c' for addition
|
|||
|
|
> cvs add: use 'cvs commit' to add this file permanently
|
|||
|
|
> $ cvs update
|
|||
|
|
> cvs update: Updating .
|
|||
|
|
> A colors.c --- The file is marked for addition.
|
|||
|
|
> $ cvs commit colors.c
|
|||
|
|
> (...Το cvs θα μας ζητήσει να δώσουμε εδώ ένα κείμενο για το log...)
|
|||
|
|
> RCS file: /imlib/colors.c
|
|||
|
|
> done
|
|||
|
|
> Checking in colors.c;
|
|||
|
|
> /imlib/colors.c,v <-- colors.c
|
|||
|
|
> initial revision: 1.1
|
|||
|
|
> done
|
|||
|
|
> $
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Παρατηρούμε και την αρχική αρίθμηση, που είναι από το 1.1. Από αυτή τη στιγμή το αρχείο που προσθέσαμε βρίσκεται στο repository του project, και οι χρήστες που
|
|||
|
|
θα κάνουν update, θα το πάρουν μαζί με όλα τα άλλα του project.
|
|||
|
|
|
|||
|
|
#### ΑΦΑΙΡΕΣΗ
|
|||
|
|
|
|||
|
|
Αν απλά αφαιρέσουμε ένα αρχείο από το directory structure του σκληρού μας, φυσικά και δεν φεύγει από το server. Μάλιστα, όταν κάνουμε cvs update, το αρχείο θα
|
|||
|
|
επαναδημιουργηθεί. Αυτό βοηθάει πολύ σε περιπτώσεις που έχουμε κάνει πολλές αλλαγές σε ένα αρχείο και αποφασίσουμε ότι κάναμε λάθος και τελικά δεν έπρεπε να
|
|||
|
|
γίνουν αλλαγές. Σε αυτή την περίπτωση απλά σβήνουμε το αρχείο και κάνουμε ένα update.
|
|||
|
|
|
|||
|
|
Είναι κατανοητό ότι η αφαίρεση ενός αρχείου είναι επικίνδυνο παιχνίδι, και γιαυτό το cvs δεν αφήνει πλήρη ελευθερία στον χρήστη. Φυσικά, μπορεί να δημιουργηθεί
|
|||
|
|
μια \`\`αφαίρεση\'\', η οποία όμως θα είναι πλασματική. Δηλαδή: Για να διαγράφεί ένα αρχείο, πρέπει πρώτα να το σβήσουμε από το δίσκο μας, και να γράψουμε την
|
|||
|
|
εντολή
|
|||
|
|
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
>
|
|||
|
|
> cvs rm `filename'
|
|||
|
|
> cvs commit `filename'
|
|||
|
|
>
|
|||
|
|
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
Πάντως, αυτό δεν το καταστρέφει από το server. Απλά φτιάχνει μια νέα \`\`αναθεώρηση\'\' στην οποία χαρακτηρίζεται ως \`\`ανύπαρκτο\'\'. Υπάρχει ακόμα όμως, και
|
|||
|
|
μπορεί να ανακληθεί π.χ. με την εντολή cvs log.
|
|||
|
|
|
|||
|
|
|
|||
|
|
### [4. ΕΠΙΛΟΓΟΣ]{#s4}
|
|||
|
|
|