Poll
Vraag:
Welk soort versiecontrole gebruiken jullie voor jullie software
Optie 1: neen, waar is dat goed voor ik schrijf geen bugs
stemmen: 1
Optie 2: Word en "track changes"
stemmen: 0
Optie 3: af en toe eens een "save as" die "latest version" noemt
stemmen: 0
Optie 4: genummerde files en commentaar
stemmen: 5
Optie 5: second source
stemmen: 1
Optie 6: subversion
stemmen: 3
Optie 7: git
stemmen: 1
Optie 8: een aparte buildserver, testserver, productieomgeving in high availability setup
stemmen: 1
Optie 9: kan je dat ook krijgen in gelijkstroom?
stemmen: 2
Ik moet stilaan aan mijn eigen software beginnen. En omdat ik hier soms lees van mensen die van alles proberen en veranderen in de hoop een oplossing te vinden vraag ik me af of jullie hier soms een versiecontrole systeem gebruiken. Zo ja, welke?
Ook de bedoeling om wat meer discussie los te krijgen hierrond, alternatieven, bedenkingen etc.
Ik geef toe dat ik er slordig in ben.
Ik zou mijn sourcecode - ook voor mezelf - veel beter moeten documenteren :-[
Nu ja, soms zijn de programmatjes zooo klein, dan is het versie-gedoe natuurlijk overkill
Citaat van: Havoc op 30 oktober 2013, 21:03:01 PM
Ik moet stilaan aan mijn eigen software beginnen. En omdat ik hier soms lees van mensen die van alles proberen en veranderen in de hoop een oplossing te vinden vraag ik me af of jullie hier soms een versiecontrole systeem gebruiken. Zo ja, welke?
Ook de bedoeling om wat meer discussie los te krijgen hierrond, alternatieven, bedenkingen etc.
Ik houd een "bugboek" bij. Elke vastgestelde fout wordt zo omstandig mogelijk beschreven en genummerd. Ik denk na over een oplossing en pas ze toe in mijn code met een nota in de kop van het programma en een volgend versienummer bvb van 3.07.22 naar 3.07.23. Dat laatste nummer komt dan weer in het bugboek. Ik houd de vorige versies bij tot de bug opgelost is.
Wat precies wil je programmeren ?
Welke software ga je gebruiken ?
Erik
als ik "major" aanpassingen doe in zelf ontwikkelde software dan ben ik geneigd dit op verschillende manieren bij te houden
- door een andere naam (bvb softwareDemo-1) en de oude versie te bewaren
- door commentaar in de dources op te nemen
- door een aparte source directory aan te leggen
Al mijn projecten zitten in subversion. Je kan dan gemakkelijk bugs fixen , features toevoegen, terug keren naar een vorige versie, files vergelijken ed.... Maar dat weten de meeste wel denk ik :)
http://tortoisesvn.net (http://tortoisesvn.net)
In een vorig leven als shell-script progammeur gebruikte ik (verplicht door de werkgever) het in Unix gebruikelijke SCCS (Source Code Control system) dit is nu ook verkrijgbaar voor Windows
http://freecode.com/projects/sccs
Meer info op:
http://sccs.berlios.de/
Ik moet zeggen het heeft mij meerdere malen een heleboel werk bespaard.
Een stukje uit de documentatie
What are the disadvantages of SCCS?
• SCCS v4 uses local time and no timezone in s. history files and p. files (fixed for s. files with SCCS v6)
What are the advantages of SCCS?
• SCCS is the first version control system, originally written in 1972 by Marc J. Rochkind at Bell Labs
• Fast operation compared to other Source Control systems
• No known "SCCS caused" data loss since at least 30 years
• One Source file results in one SCCS history file, so a file loss does not affect the whole project
• Easy to understand format of the history files that allows manual intervention
• Checksums and interleaved deltas (weave file format) grant file integrity and immediate detection of corruption
• Interleaved deltas (weave file format) allow fast extract by using a single linear read on the history file at a cost of O(n)
• Interleaved deltas allow to create annotated files (with revision, date and contributor) on a line by line base at no cost.
• Support for binary files using uuencoded SCCS history (set up via admin -b)
• SCCS is much faster than competing syststems (e.g. RCS, CVS and others) - currently 6x faster than RCS
grt Piet.
Ik gebruik geen software. Mis ik nog een beetje als optie.
Ik zet heel veel commentaar bij de broncode en in de header
vb header:
;*********************************************
;* PROGRAMMA OM 8 SERVO'S AAN TE STUREN
;*
;* Geschreven door Geert Giebens voor PIC 16F887 microcontroller
;*
;* Datum: 16 september 2011 Versie PIC16F887_SERVO_V2.5
;*
;* Filenaam: servosturingV2p5.asm
;*
;* Aanpassingen versie 2.4:
;*
;* -Uitgangen pulsen naar poort B
;* -Schakelcontacten links- rechts gebundeld per twee
;* -Schakelaars gebundeld per 8 op poort A en E
;* -Na reset even pulsen op de servo's (laatste toestand EEPROM)
;*
;* Aanpassing versie 2.5:
;*
;* -programma geschikt gemaakt voor servo's met pulstijd van
;* 0,5ms tot 2,5ms
;* *
Ik gebruik ook een GMAIL account. Daar stuur ik bijna dagelijks via mail de laaste versie door. Deze GMAIL kan ik ook op elke PC openen, zodat ik niet met geheugenstiks moet rondlopen.
Geert
Citaat van: Geert op 31 oktober 2013, 12:03:43 PM
Ik gebruik ook een GMAIL account. Daar stuur ik bijna dagelijks via mail de laaste versie door. Deze GMAIL kan ik ook op elke PC openen, zodat ik niet met geheugenstiks moet rondlopen.
Geert
Slim !
Erik
gebruik voor veel een dropbox--> veel handiger!
Citaat van: Geert op 31 oktober 2013, 12:03:43 PM
Ik zet heel veel commentaar bij de broncode en in de header
Dat heet nice and tidy documenting Geert!
Daar kunnen nog heel veel programmeurs een voorbeeld aan nemen.
grt Piet.
Zelf volg ik een aantal regeltjes:
- natuurlijk commentaar in de code (zowel in de header als instream)
- hoofd- en sub-versies (mee opgenomen in de bestandsnamen
- edit-change volgletter, zodanig dat ik kan terugkeren naar een vorige werk-versie, als ik wat mispeuterd heb
(dus bv V1.2-a, 1.2-b, ... ). Bij een nieuwe hoofd- of sub-versie herbegin ik met "-a".
- een logboek, waarin in zowel mijn ideeën voor toekomstige ontwikkeling, als effectieve wijzigingen/bugfixes noteer.
Dus een tussendoor flits geraakt niet vergeten.
SCCS doet me denken aan een systeem dat we vroeger gebruikten (CMS op DigitalVMS).
Erg nuttig, soms wat omslachtig.
SCCS bekijk ik zeker
Dat idee van Gmail klinkt erg nuttig, als je veel van computer wisselt.
Zélf plaats ik alles op een externe drive, waarvan ik regelmatig een backup neem (die ik op een andere fysische locatie hou).
Dus bij diefstal of verlies, ben ik niet te veel kwijt.
CiteerWat precies wil je programmeren ?
Welke software ga je gebruiken ?
Er zijn verschillende zaken te programeren. Eerst is er de pc software. Dat wordt gewoon C, heel waarschijnlijk met CodeBlocks en GCC. Geen grafisch gedoe nodig. Dan de firmware van de modules. Dat is een Atmel Xmega en ik zou ook gewoon C gebruiken. Vooral omdat ik me nog wat C herinner van vroeger maar het zal een behoorlijke afstofbeurt vragen.
Omdat ik mezelf ken en nogal slordig met die zaken omspring dacht ik dat het leuk zou zijn om eens te horen hoe anderen dat hier aanpakken. Bij mijn vorige werkgever werd daar redelijk strak mee omgegaan (perforce, ben ik vergeten als optie) maar dat was dan ook essentieel. Voor hobbyprojectjes lijkt het me misschien overkill maar is dat zo?
In eerste instantie dacht ik aan Subversion. Maar die SCCS ga ik toch eens bekijken, al was het maar omdat die binaire files ondersteunt en daar zie ik nog toepassingen voor.
CiteerIk gebruik geen software. Mis ik nog een beetje als optie.
Tja, het is echt wel meer voor de programeurs onder de modelspoorders bedoeld.
Het versiegedoe gaat bij mij vrij losjes. Eenmaal het programma geschreven krijgt het een versienummer in zijn bestandsnaam (_v0001a). Elk wijziging wordt in de code met commentaar verduidelijkt (initalen, datum en korte beschrijving). Het programma wordt dan met een nieuwe versienummer gesaved. Om de zoveel tijd maak ik een backup op een externe schijf (en stockeer die verkeerdelijk in hetzelfde vertrek). Meer heeft het niet om het lijf, bij mij.
Citaat van: Steam.N op 31 oktober 2013, 13:43:41 PM
SCCS doet me denken aan een systeem dat we vroeger gebruikten (CMS op DigitalVMS).
Erg nuttig, soms wat omslachtig.
SCCS bekijk ik zeker
Inderdaad daar lijkt het erg op, volgens de fabrikant is het zelfs sneller.
Wat betreft de omslachtigheid, dat valt wel mee hoor.
Als je het vanaf het begin goed opzet, heb je maar één source en alle aanvullingen of veranderingen zitten afzonderlijk in de database.
Je kunt vrij eenvoudig terug naar een tussenversie, maar ook bij het perongeluk weggooien van de complete werk copie deze weer met SCCS reconstrueren.
Citaat van: Steam.N op 31 oktober 2013, 13:43:41 PM
Dus bij diefstal of verlies, ben ik niet te veel kwijt.
Zie hierboven.
Een voorbeeld uit de praktijk:
De afdeling waar ik werkte was ook verantwoordelijk voor de DNS database met zo'n 1500 zonemaps van het bedrijf.
Op een dag wiste een stagiar de complete directory met zonemaps, paniek alom.
Maar met een paar commando's was het gehele directory met de inhoud van de bestanden weer te reconstrueren.
Daarna waren er op de afdeling geen SCCS haters meer. :)
Voor nog meer info http://casper.cii.saxion.nl:8083/~akkersdi/unix/alles/sccs-java.html
Ik zou er zeker wat aandacht aan geven Jean.
grt Piet.
Zelf gebruik ik Subversion voor m'n persoonlijke projectjes. Deze draait op m'n NAS/mediacenter.
Op het werk gebruiken we IBM Rational (Rational Team Concert), doet wel wat meer dan enkel source controle...
Citaat van: bossie op 31 oktober 2013, 16:17:53 PM
... Ik zou er zeker wat aandacht aan geven Jean...
Ga ik zeker doen.
Is de interface op DOS niveau, of heeft het een Windows interface ?