Poster taggade med ‘Subversion’

Git > Subversion

De flesta programmerare som jag känner började sin versionshanteringskarriär med antingen CVS eller M$ SourceSafe. Efter några år gick de över till Subversion eftersom det fungerar på ungefär samma sätt, fast bättre. De är nöjda med Subversion och har inga åsikter om hur systemet skulle kunna förbättras. Dessutom så finns det bra GUI frontar för Subversion som tex. Tortoise. Jag hävdar att det är dags att lämna Subversion, det finns bättre alternativ!

Sedan några år tillbaka så finns det en ny typ av versionshanteringssystem som till skillnad från de gamla är decentraliserade. Exempel på de här nya systemen är Git, Mercurial och Bazaar. I ett decentraliserat versionshanterinssystem (DVCS) så har varje användare en lokal kopia av hela projektets versionshistorik. Det betyder INTE att man inte kan ha ett centralt repository som alla i projektet arbetar mot, och det leder heller inte till anarki. Med ett DVCS kan man göra allt som man kan med Subversion, och dessutom en massa andra saker.

För mig är de viktigaste fördelarna med DVCS lokala commits och lokala branchar. En vanlig pattern i Subversion-land är att man på stora projekt inte vågar checka in kod eftersom det kan sabba bygget för resten av laget. Det leder till att man sitter och kodar på sin nya feature under en längre tid och väntar med att checka in tills det är testat och klart – vilket ibland kan ta lång tid. Under tiden man arbetar på sin feature så kan man hämta hem ny kod från sina medarbetare via svn update, men man har ingen versionshistorik på sin nya feature. Ett DVCS råder bot på det här problemet genom att tillåta lokala commits. När man är klar pushar man upp sina ändringar till den centrala servern, antingen som en enda commit eller med hela lokala versionshistoriken för featuren.

Under tiden som man arbetar på sin nya oincheckade feature så är det väldigt vanligt att man inte kan köra resten av systemet på sin lokala maskin eftersom det är en enda stor byggarbetsplats. Med ett DVCS som Git så är det busenkelt att skapa lokala branchar. Vana Git-användare gör det flera gånger om dagen! För varje ny feature som man börjar arbeta på så skapar man en lokal branch. När man är nöjd med featuren så mergar man tillbaka det till sin lokala trunk innan man pushar upp den till det centrala repot. Man kan även brancha i Subversion, men det är krångligare så det brukar man bara göra vid större releaser.

Förutom lokala commits och branchar så finns det en massa andra anledningar till att gå över till ett DVCS. Det känns helt enkelt mer kraftfullt och modernt. Dessutom så vågar jag hävda att det gör ditt liv som utvecklare roligare, för det ger dig en ny frihetsgrad.

Jag vet inte om Git eller någon av de andra DVCSerna kommer slå igenom på bred front, men inom open source så har de redan gjort det. Jquery, Linux, Rails, Drupal och andra stora projekt kör eller är på väg till Git. Det som talar emot Git är att det är lite svårare att lära sig än Subversion. Git används av de flesta via kommandotolken, och det är tveksamt om man kan få med sig .NET och Java-utvecklarna tills att det finns bra integration med deras utvecklingsmiljöer. På sistone har det kommit GUI-frontar både till Windows och OSX.

Jag har använt Git sen ett tag tillbaka och jag är fast! Jag känner inte till någon som har lärt sig Git och som har valt att gå tillbaka till Subversion. Som tur är så kan jag köra Git även om alla andra i mitt projekt vill fortsätta använda Subversion. Det finns nämligen en git-svn brygga som är väldigt enkel att använda. Med den så kör jag Git lokalt fast den centrala Subversion servern ser mig som en vanlig subversion klient.

Fortfarande inte övertygad om att Git är bättre än Subversion? Läs det här!: Why Git is better than X och Git Svn Comparison.

Här är några länkar jag rekommenderar er att utforska om ni vill lära er mer om Git:
Git Community Book
Pro Git Book
Effectively using Git with Subversion
A Successful Git Branching Model

Axure RP Pro 5.0 – uppdaterat prototypverktyg

I slutet av april släpptes version 5 av Axure RP Pro. Den innehåller en mängd nya funktioner och förbättringar som gör att vi interaktionsdesigners kan jobba effektivare och bättre illustrera mer funktionalitet i våra prototyper.

Den kanske viktigaste nyheten är det Axure kallar för Shared Projects. Denna funktion för att kunna dela och jobba parallellt med projekt är baserad på versionshanteringssystemet Subversion. Resultatet är ett relativt smidigt system som låter flera interaktionsdesigners jobba samtidigt på samma projekt utan risk för att hamna ur synk.

Att Shared Projects baseras på ett versions­hanterings­system gör att det sköter versionshantering bra mycket bättre än vad jag normalt mäktar med på egen hand. Därför har jag valt att använda Shared Projects även när jag jobbar själv på ett projekt.

Skärmdump av Axure

En annan ny funktionalitet som tillkommit i version 5 är möjligheten att dynamiskt flytta sidelement i prototypen. Det har gjort det lättare för oss att prototypa rika gränssnitt som till exempel innehåller drag’n’drop. Än så länge går det bara att flytta sidelementen mellan förutbestämda platser men det ger ändå större möjligheter att visa och prova de tänkta egenskaperna.

Till sist har det också blivit möjligt att dynamiskt aktivera/avaktivera widgets och scrolla inom en sida – äntligen!