Γράφω στο Team Edition forum αν και δεν θέλω να μιλήσω μόνο για το Team System αλλά γενικότερα.

Όταν δουλεύει κανείς ομαδικά μέσω source control (προσωπικά χρησιμοποιώ subversion) υπάρχει το εξής θέμα. Κάποια στιγμή θέλεις να δοκιμάσεις ή να διορθώσεις κάτι στον κώδικα. Ας το ονομάσουμε αυτό task A. Στο μεταξύ προκύπτει κάτι πιο επείγον ή για κάποιο λόγο θέλεις να παγώσεις την δουλειά που έκανες και να πιάσεις κάτι άλλο (task B). Ok, καλό είναι να τελειώνεις κάτι που ξεκινάς, αλλά... συμβαίνει καμιά φορά. Τι κάνεις; Αν απλά αφήσεις un-commited τις αλλαγές του task A και προκύψουν αλλαγές στα ίδια αρχεία για το task B, τότε μπερδεύται η δουλειά. Συνήθως κοινές αλλαγές προκύπτουν στα csproj/vbproj αρχεία. Όταν θα θέλεις να κάνεις commit στο Β θα πρέπει να κάνεις και στο Α το οποίο δεν έχει τελειώσει.

Μια λύση στο subversion είναι να κάνεις ένα patch. Είναι ένα αρχείο που περιλαμβάνει όλες τις αλλαγές στο task A. Μετά κάνεις revert, οπότε χάνεις τις αλλαγές του Α και αρχίζεις να δουλεύεις στο Β. Όταν τελειώνεις κάνεις 'Apply Path' και επαναφέρεις τις αλλαγές του Α.

Να προσθέσω και άλλη μια παράμετρο. Όλα τα παραπάνω γίνονται για να μην μπερδεύεται ο ένας developer με τον άλλο. Όταν μπαίνουν στη μέση και άτομα που ασχολούνται με το building-testing τότε ένα commit είναι πιο σοβαρό. Ακόμα και αν οι developers συμφωνήσουν μεταξύ τους ότι δεν πειράζει να κάνουν commit και κάτι που δεν έχει τελειώσει, ο tester (ο οποίος δεν θεωρείται μέλος της ομάδας) ίσως μπερδευτεί.

Μήπως δεν υπάρχει πρόβλημα με όλα αυτά και είναι απλά ιδέα μου;

Το ερώτημα αποτελεί αφορμή για συζήτηση και ιδέες. Άλλωστε δεν ψάχνω κάποια συγκεκριμένη και άμεση λύση. Απλά θέλω να ακούσω και άλλες απόψεις.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Do you know shelving???

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Δεν ήξερα ότι λέγεται έτσι. Ουσιαστικά αυτό είναι που κάνω και τώρα με τα patches. Τώρα όμως που το είπες το έψαξα λίγο και είδα και μια άλλη ιδέα χρησιμοποιώντας private branches: http://mikemason.ca/2005/03/30/

Έχει δουλέψει κανείς κάτι τέτοιο;

edited: Το video δεν κατάφερα να το παίξω! Μου λείπουν codecs!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Λοιπόν δοκίμασα το κόλπο που λέει το παραπάνω link για να κάνεις shelving στο subversion. Δεν είναι άσχημο. Ουσιαστικά ένα branch κάνεις. Βέβαια αυτό που δεν μου αρέσει είναι το εξής (έχει να κάνει με τον τρόπο που χρησιμοποιούμε το subversion στη δουλειά): Έχουμε ενεργοποιήσει την αποστολή e-mail για κάθε commit. Οπότε ακόμα κι όταν κάνει κανείς commit σε ένα shelve παίρνουν ειδοποιήσεις όλοι. Θα ήθελα να μην παίρνουν ειδοποιήσεις συγκεκριμένα άτομα (π.χ. μόνο οι developers ή ακόμα και κανένας). Μάλλον πρέπει να δω αν γίνεται αυτό.

edited: Για να το πω διαφορετικά, πληρώνεις το κόστος του γεγονότος ότι δεν πρόκειται για πραγματικό προσωπικό shelve set αλλά για ένα workaround!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Στην τελευταία έκδοση του SNV (1.5) η διαδικασία branching/merging έχει βελτιωθεί αρκετά. Επίσης το TortoiseSVN έχει πλέον έναν όμορφο wizard που απλοποιεί τη διαδικασία.

Σημείωση: Το shelve στο subversion λέγεται "Feature Branch". Πρόκειται βέβαια για μια απλή τυπική ονομασία καθώς από κάτω οι έννοιες branch, tag, feature branch και trunk είναι εντελώς εικονικές. Πρόκεται για ακριβώς το ίδιο πράγμα.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Dimitris Papadimitriou:

Δεν ήξερα ότι λέγεται έτσι. Ουσιαστικά αυτό είναι που κάνω και τώρα με τα patches. Τώρα όμως που το είπες το έψαξα λίγο και είδα και μια άλλη ιδέα χρησιμοποιώντας private branches: http://mikemason.ca/2005/03/30/

Έχει δουλέψει κανείς κάτι τέτοιο;

Δουλεύαμε private branches πριν 4 χρόνια με subversion/tortoise σε ένα project με developers που δεν ήταν στον ίδιο χώρο και συχνά δεν βλέπαν (ή δεν έστελναν σχετικά) mail.  To integration κατέληξε τραγωδία.

Πάντως έχεις δίκιο, υπάρχει θέμα στο συγκεκριμένο πρόβλημα. Ίσως όχι σε όλες τις ομάδες ανάπτυξης, αλλά τουλάχιστον στην τωρινή που είμαι όπου οι προτεραιότητες του καθενός αλλάζουν μερικές φορές ακόμα και μέσα στην μέρα και δεν έχουμε την άνεση να ζούμε σε ένα release-driven περιβάλλον (αλλά πρέπει κάθε μέρα να έχουμε stable nightlies) γίνεται της κακομοίρας μερικές φορές.

Τα patches είναι πολύ καλή φάση πάντως.

---

The people of the straight land have really got it made, a warm friendly sleep from the craddle to the grave

Δεν μπορώ να επιβεβαιώσω κι εγώ ότι το merging είναι τραγωδία, αλλά σίγουρα δεν είναι αυτό που θα περίμενα. Φυσικά είναι τραγωδία αν κάνεις ο καθένας το δικό του branch και το κρατήσει για πολύ καιρό, ειδικά σε αρχικά στάδια ενός project όπου υπάρχουν πολλές αλλαγές. Τότε μπορεί η λέξη "τραγωδία" να μην είναι αρκετή, αλλά είναι φυσικό.
Σημείωση: Η τελευταία έκδοση του svn και tortoise svn έχει βελτιωμένη υποστήριξη για branch/merge.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Linus Torvalds μιλάει για το git και για ποιό λόγο ξήλωσε το SVN. Ουσιαστικά για το braching/merging.
http://www.youtube.com/watch?v=4XpnKHJAok8

Μάλον το θέμα branching/merging είναι πολύ σοβαρό.
Μπορεί κάποιος να εξηγήσει πρακτικά (ή να παραπέμψει σε παράδειγμα) για το τι συμβαίνει στο κομμάτι του κώδικα που έχει αλλάξει για να καλύψει μια μεγάλη αλλαγή
και ξαφνικά εμφανίζεται η ανάγκη να γίνει μια γρήγορη διόρθωση κάπου αλλού για να βγεί κάποια bug-fix έκδοση?
Τι εξασφαλίζει ότι το branch με τη μεγάλη αλλαγή θα παίξει μετά την bugfix διόρθωση?

Svn?  Git? Source Safe? Team foundation? πολλά ακούνται...
Tι έχετε να προτείνεται για source management για μια μικρή ομάδα τεσσάρων προγραμματιστών, οι οποίοι δεν βρίσκονται σε τοπικό δίκτυο? Θα παίζουν via internet.
Η ομάδα θα δουλέψει με το VS 2008.

---

Εγώ προτείνω SVN. TortoiseSVN

---

Manos

Για να είμαι όμως και δίκαιος να αναφέρω το μεγαλύτερο πρόβλημα του SVN είναι το copy- paste- rename φακέλων μέσα στο PRoject. Αυτό απαγορεύεται δια ροπάλου διότι μετά είναι πολύ δύσκολο να το συγχρονίσεις με το repository. Αντιγράφω από τη WikiPedia (http://en.wikipedia.org/wiki/Subversion_(software))  Με απλά αρχεία δεν έχεις πρόβλημα.

---

Manos