Visual Studio og flere udviklere, versionskontrol giver problemer, andre muligheder
Hej. Vi er en flok universitetsstuderende der er i gang med at programmere i visual studio 2008. Vi vil gerne være i stand til at kode på samme projekt, men her støder vi i problemer.
I forbindelse med rapportskrivning og generel projektarbejde anvender vi svn til versionsstyring og vi har forsøgt os med dette i visual studio også. Både med totoris direkte på projektmappen og ved hjælp af et plugin VisualSVN til visual studio.
Vores problem er hver gang konflikter med projektfilen som gør at det hele ryger i ged.
Nogle der har erfaring med at arbejde flere udviklere på samme projekt der kan give råd til hvordan i bruger versionsstyring effektivt?
Evt kan vi se at microsoft har nogle team værtøjer (som vi har adgang til), men de virker meget omfattende og det eneste vi har brug for er at kunne dele et forbandet projekt (eller soulution) og det er alt.
Er der en fornuftig måde at gøre dette på? lige nu anvender vi vs 2008 pro, men vi har adgang til team systems også hvis det skulle være.
Vi har bare ikke 2 måneder til at sætte os ind i et omfattende projektstyringsværktøj.
Håber nogle kan give os ideer til hvordan vi kan dele et projekt nemt og effektivt.
Det nemmeste er at bruge TFS, som det lyder til at I har adgang til. Den virker med VS og hvis I får sat et projekt op til jer, så er det ganske enkelt at bruge, til deling af projekter/solutions.
Det kan naturligvis en masse, men I behøver ikke kunne det hele. bare check ud/ind + evt. shelving og branching.
Det er meget vigtigt at huske at i altid (jeg siger det lige igen - ALTID) kører en update inden i laver en commit. Ellers kan der gå ekstra muggen ged i projektet.
Update og Commit ofte. Der er intet tool i verden der har det godt med 10 udviklere der render ud af hver deres tangent i en uge, og så får besked på at redde trådene ud. Update og Commit ofte.
Selve csproj filen kan godt være lidt drilsk..... Det er en xml-fil, og hver gang i tilføjer/fjerner/flytter filer eller referencer i projektet vil den blive genereret igen.
Der er desværre ikke nogen garanti for, at de enkelte entries i den kommer i samme rækkefølge hver gang, så SubVersion har somme tider noget svært ved at fatte hvad der er lavet om, og vil derfor markere filen som værende conflicted.
Da filen er en (relativt) letforståelig xml-fil burde i være i stand til at merge de conflictede filer, og markere det som løst.
Jeg bruger også SVN sammen med skildpaden og visual SVN. Jeg må sige jeg fotryder ikke vi skiftede til SVN.
Vi er en hel udviklings afdeling der benytter det, samt vores eksterne afdeling som kommer på ude fra. Køre godt og smidigt over nettet.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
