Svnrev Svnrev is een klein programma dat het huidige revisienummer van het project schrijft in een C / C ++ Header-bestand, een Java-pakketbestand of een C # -klasse-bestand. Dit revisienummer wordt opgeslagen in constanten (macro's in t
Download nu

Svnrev Rangschikking & Samenvatting

Svnrev Tags

Stempel CVS CVS-bron Subversion-integratie VB6-subversie subversie Subversion Client Subversion-configuratie Subversion logs spectrum voor CVS subversie-monitor Subversion-bibliotheek Beheer de Subversion-server Subversion-toediening CVS-client CVS-controle cvs modules werk cvs CVS-functie Subversion-server CVS-opties Subversie-interface Subversion-editor Toegang tot CVS Subversion Management Python-subversie CVS-bestand stempel aanvraag postzegelcomponent C ++ header Rcs Subversion Deployer ondermijning van mercurial CVS-opvolger CVS-import

Svnrev Beschrijving

Stempel uw toepassingen of componenten met revisienummers Svnrev is een klein programma dat het huidige revisienummer van het project schrijft in een C / C ++ Header-bestand, een Java-pakketbestand of een C # -klasse-bestand. Dit revisienummer wordt opgeslagen in constanten (macro's in het geval van C / C ++), zowel als een cijfer als als een tekenreeks. Het krijgt het revisienummer van de "RCS-zoekwoorden" die in de bronbestanden moeten zijn. Svnrev is speciaal ontworpen voor het Subversion Version Control-systeem, maar het kan ook worden gebruikt met CVS en RCS. Svnrev is een zelfstandig hulpprogramma dat niet op een bepaalde IDE vertrouwt. Svnrev is een draagbaar hulpprogramma en moet op elke omgeving lopen waarop een conforme C-compiler beschikbaar is. Ons doel was om het te gebruiken van een "makefile" en om te bevestigen aan een versiescontrolesysteem, en specifiek naar het subversie-systeem. Waarom svnrev gebruiken? Computerprogramma's hebben versies. Elk component (DLL, ActiveX-object, OLE-server, ingebedde firmware, enz.) Kan zijn eigen versie hebben. Als de wereld perfect was, mogen er geen twee verschillende componenten bestaan met hetzelfde versienummer. In de praktijk gebeuren "stealth" -upgrades, vooral tijdens de bèta-periode. Er zijn talloze verschillende releases van MSVCRT20.dll die allemaal hetzelfde versienummer 2.11.000 hebben. Op een vergelijkbare manier zijn incompatibele releases van CTL3D.DLL-versie 1.0 en COMDLG32.dll versie 4.004.004.00 uur ". Wat nodig is om de verschillende componenten van elkaar te onderscheiden, is om een "revisienummer" aan de versie van de component te bevestigen. Wanneer een dergelijke regeling is ingesteld (en het revisienummer maakt deel uit van het versienummer), ontgrendelen ontwikkelaars niet langer per ongeluk een bijgewerkte component met exact dezelfde versie-stempel als de vorige release. Wanneer het versienummer aanwezig is in het vak "Over" en / of in de Version Resource, kan de gebruiker snel verifiëren welke versie hij of zij heeft, en wanneer dit aan de ontwikkelaars wordt gecommuniceerd, kunnen beestjes nogal wat gemakkelijker zijn reproduceren. In meer populaire termen: als u ooit een klant of een collega hebt gevraagd "van welke datum dat component is?", Moet u overwegen Svnrev te gebruiken. Bestandsdatum / tijdstempels hebben een (welverdiende) reputatie van onbetrouwbaar. Er zijn verschillende hulpprogramma's om een automatisch toenemend buildnummer voor elke compileren te handhaven. Dit heeft echter het nadeel dat er geen directe link is tussen de bouwzegel en de versiebeheer. Om een dergelijke link te krijgen, moet u inchecken in het bestand dat het huidige build-nummer in de versie Control houdt. In multi-ontwikkelaarsgroepen wordt dit machine-gegenereerde, vaak veranderende bestand, een overlast voor het versiesregelsysteem. Eigenlijk zet u typisch geen machine-gegenereerde bestanden in versiebeheer. Svnrev gebruikt een andere aanpak: het vraagt het buildnummer bij de trefwoorden die een versiebesturingssysteem in een bronbestand onderhoudt. Meer specifiek gebruikt Svnrev het trefwoord "$ ID: $" (en optioneel twee anderen). Subversion heeft de handige eigenschap die het alleen één revisienummer voor een volledig project gebruikt, in plaats van een afzonderlijk revisienummer per bestand. Dit is niet het geval met CVS en RCS; Zie het gedeelte "Svnrev met CVS en RCS" gebruiken voor meer informatie over het gebruik van Svnrev met CVS / RCS. Svnrev veronderstelt dat u uw wijzigingen aan de versiebeheer begaan voordat u een product / update naar iemand verzendt. Als Svnrev een verschil detecteert, voegt het een "gewijzigde vlag" toe aan twee van de macro's / constanten die het genereert. De redenering hierachter is dat als uw lokale kopie van de broncode wijzigingen bevat die nog niet in versiebeheer staan, het revisienummer van de toepassing / -component die u hebt verzonden, is gekoppeld aan het verkeerde revisienummer in subversie. Het nummer is waarschijnlijk anders dan een eerdere aanvraag / component die uit de deur is gegaan (tenzij u de versie-besturing slecht gebruikt, of de updates ver te snel verzenden), maar het vinden van de juiste revisie-achterkant kan moeilijk of zelfs onmogelijk zijn. Daarom: Bouw eerst uw wijzigingen en bouw vervolgens de definitieve release die u zult implementeren.

Svnrev Gerelateerde software