Versjonskontrol alternativer

[HDSoftware]

Hei alle...

 

Vi har nå brukt SubVersion et halvt års tid. I Visual Studio bruker vi AnkhSVN og til det meste uten om VS så bruker vi Tortoise. Vi opplever at det til stadighet dukker opp problemer som gjør at jeg må slette en solution for så å hente den inn på nytt. Videre synes jeg auto merge er for dårlig. Eksempelvis så har nå to personer jobbet på samme solution og ingen har gjort direkte endringer på selve SLN filen, men siden begge har lagt til nye filer i prosjekter så får jeg nå konflik i SLN filen. Dette er jo håpløst. Jeg hadde ingen planer om å sette meg inn i hvordan SLN filen virker og sånn jeg ser det så er eneste vei utenom å hente inn solutionen på nytt, gjøre de endringene jeg gjorde i går og sjekke inn på nytt, rett og slett for å få inn den andre personens endringer først og så legge til mine egne på nytt. Det kan da ikke være meningen at det skal være slik!!

 

Jeg leste dokumentasjonen til SubVersion en gang for lenge siden, kansje er ting endret på i dag, men det jeg leste var at SubVersion egentlig er et dopkument versjonskontroll system og ikke kildekode versjonskontroll system, men at det alikevel egner seg godt til kildekode versjonskontroll. Kan hende det egner seg godt, men de ovennevnte problemer gjør at jeg lurer...

 

Finnes andre og bedre alternativer ?

[rozon]

Klart det finnes alternativer

 

Hva som er bedre er en annen sak. Jeg bruker TFS til vanlig, men det er vel litt overkill om du kun skal ha versjonskontroll. Microsoft har sikkert en trial versjon hvis dere vil prøve... Skal ikke påstå denne er bedre enn noe annet!

[Kiff]

Jeg vet ikke hvordan dette funker med Visual Studio og windows, men min erfaring fra Java er at man ikke sjekker inn IDE spesifikke filer i versjonskontrollsystemet.

[HDSoftware]

Vi brukte Microsoft Versjon Control 2005 tidligere. Fungerer aldeles utmærket helt til du trenger utviklere som befinner seg på andre steder av kloden.

 

Så testet jeg TFS, men det ble bare rot. For store krav og implementasjoner av diverse andre server programvarer. Håpløst, men takk for tipset

[HDSoftware]

Jeg vet ikke hvordan dette funker med Visual Studio og windows, men min erfaring fra Java er at man ikke sjekker inn IDE spesifikke filer i versjonskontrollsystemet.

Forsåvidt et godt poeng, men det er liksom SLN filen som holder sammen alle prosjektene. Hmmm. Må sjekke om jeg rett og slett har vært litt kjapp her. Kansje bør alle utviklere ha en egen solution file, men at selve prosjektene ligger i SVN. Det må jeg sjekke ut...

[Dinosauromann]

Git, mercurial, bazaar?

Vet ikke hvor godt de integrerer med VS, men de er nå alle en forbedring ifra subversion.

[HDSoftware]

Jeg vet ikke hvordan dette funker med Visual Studio og windows, men min erfaring fra Java er at man ikke sjekker inn IDE spesifikke filer i versjonskontrollsystemet.

En annen ting. Hvis du ikke har med hele solution i SVN, hvordan klarer du da større refactoring oppgaver ?

 

Git, mercurial, bazaar?

Vet ikke hvor godt de integrerer med VS, men de er nå alle en forbedring ifra subversion.

GIT har jeg så vidt hørt om, de andre er ukjennte for meg. Kjenner du til hvilke fordeler GIT har over SVN ?

[danerik]

Git fungerer iallefall fint. I motsetning til TFS og Subversion, så er det ikke sentralisert. Dette gir enkelte fordeler i forhold til å arbeide lokalt, siden VCS ikke må kontakte en sentralisert VCS-server for å gjøre "repo"-relaterte oppgaver som commit, branch, tag og checkout.

 

Jeg vet ikke noe om integrasjonen med Visual Studio, men har brukt git og Subversion i C#-prosjekt. Og der har min erfaring vært lik som i alle andre prosjekt der git og Subversion har blitt testet ut: Det er få grunner til å bruke Subversion fremfor git. Den eneste grunnen (og i mine brukstilfeller) må være at det er enkelt å inkludere eksterne repositories i Subversion (svn:externals). TFS har jeg ikke så mye erfaring med, men dersom Microsoft har gjort jobben sin så burde det være velegnet.

 

Mangel på integrasjon med Visual Studio burde ikke være et så stort problem. Å lage "riktig" liste med filer eller filmønstre som skal ignoreres, er noe som bør gjøres på prosjektbasis uansett. Og det er såpass lite interaksjon man har med et VCS, at det ikke spiller noen rolle at filer ikke blir lagt under versjonskontroll med en gang de legges til i Visual Studio.

 

Men hovedproblemet ditt ser jo ut til å være relatert til fletteverktøyet som følger med TortoiseSVN. Dette har ikke noe begrep om strukturen til en Visual Studio solution-fil, og kan i grunn ikke bidra så veldig mye dersom flere utviklere har forandret på linjer som havner i konflikt. Men dersom dette er et problem, så lurer jeg nesten på hvor mange prosjekt dere har i hver solution. Det er klart at det oppstår problemer dersom alle sitter å reorganiserer solution-filer gjennom å samtidig legge til og flytte rundt på prosjekt. Men strukturen til en sln-fil burde ikke være mer komplisert enn at det er overkommelig å fikse det bare ut ifra konfliktmarkørene som settes inn ved en eventuell versjonskonflikt.

[zotbar1234]

GIT har jeg så vidt hørt om, de andre er ukjennte for meg. Kjenner du til hvilke fordeler GIT har over SVN ?

 

Vel, man kan begynne med å si at svn er uegnet som verktøy. Den har såpass mange defekter (eksistensen av svnmerge.py alene er nok for å aldri betrakte svn som verdig) og er basert på en såpass ødelagt mental modell, at den rett og slett ikke kan brukes til utvikling annet enn en demonstrasjon av hvordan ting IKKE skal gjøres. svn er ubrukelig ytelsesmessig (iallfall mot en master repo som er over nettverket), ubrukelig plassmessig, komplett ubrukelig til branching og merging (fordi, vel, det er operasjoner som er vanskelige i svn) og totalt uegnet til distribuert arbeidsflyt (prøv å committe kode uten å ha kontakt med master repo). Det eneste som er mer ubrukelig enn svn er manuell patching og cvs.

 

Linus

.

 

Av aktuelle alternativer har man git og mercurial. Personlig synes jeg at mercurial (ofte referert til som hg) har en lavere terskel, men jeg har også et subjektivt inntrykk at git har en større brukermasse bak seg (og følgelig større utvalg av verktøy, tips, osv).

Endret 24. januar 2012 av zotbar1234

[GeirGrusom]

Etter det jeg kan finne, så kommer problemet av at en glemmer å lagre solution før en committer. En enkel løsning vil da å alltid bygge før en committer, som uansett er god skikk ettersom det er ganske kjipt å ha en versjon i repository som ikke lar seg bygge.

 

http://stackoverflow.com/questions/1329482/visual-studio-svn-and-merging-csproj-and-sln-files

Endret 24. januar 2012 av GeirGrusom

[HDSoftware]

Vel... Problemet dukker ikke opp når man laster opp endringer, men når man henter siste endringer fra systemet og dette har så vidt jeg vet ingenting med om ting kompillerer før update å gjøre..

 

Var forresten en nyttig artikkel du hadde funnet...

 

Takker..

Endret 26. januar 2012 av HDSoftware

[GeirGrusom]

Vel... Problemet dukker ikke opp når man laster opp endringer, men når man henter siste endringer fra systemet og dette har så vidt jeg vet ingenting med om ting kompillerer før update å gjøre..

Hvis forrige person ikke hadde lagret solution før commit så vil det ligge en gammel solution i repository?

[HDSoftware]

Du har et poeng, men jeg tror ikke det var problemet her altså. Det handler mer om at to personer endrer på de samme tingene og at versjonskontroll systemet dermed er usikker på hva som skal gjøres og fremtvinger en "Velg hva som er rett" situasjon. Men samme det. Vi kommer i neste uke til å gå over til GIT og forhåpentligvis forsvinner noe av problemene våre med dette

[Terrasque]

Personlig har jeg gått fra SVN til mercurial til git. Grunnen til mercurial -> git var at branching / merging delen føltes både enklere og mer solid. Vil også si at git føltes som den vanskeligste å komme inn i, blant annet grunnet litt andre kommandoer og måter å arbeide på (bare repositories, remotes, ingen shorthand av kommandoer osv).

 

mercurial er meget likt SVN i bruk, og føles litt som "distribuert svn" i bruk. git er mer bygd fra bunnen av rundt DRCS prinsippet, som gir en litt større overgang, men fungrer (imho) bedre i praksis når man først har tatt overgangen. Bazaar har jeg ingen erfaring med.

 

Min personlige erfaring er at mercurial har en større tendens enn git til å krølle ting til, spesielt på merges (git er etter min mening fantastisk solid på det punktet).

 

Bruker git med en flow inspirert av http://nvie.com/posts/a-successful-git-branching-model/ - vanligvis litt tilpasset etter prosjektet.

[Wattengård]

Enda en SO-post som kanskje hjelper?

http://stackoverflow.com/questions/1033809/should-a-sln-be-committed-to-source-control

[asicman]

Etter et par år med git forstår jeg ikke hvordan jeg holdt ut med svn... Det eneste jeg ser til svn i dag er «git svn rebase» og «git svn dcommit»

[GeirGrusom]

Bruker SVN på jobben. Har ikke egentlig hatt noen problemer med det, men det er jo ikke akkurat ideelt heller. På private prosjekter har jeg som regel brukt Mercurial.

 

Tror jeg skal undersøke på jobben om det er mulig å flytte til Git istedet for SVN.

[The Jackal]

Vi brukte Microsoft Versjon Control 2005 tidligere. Fungerer aldeles utmærket helt til du trenger utviklere som befinner seg på andre steder av kloden.

 

Så testet jeg TFS, men det ble bare rot. For store krav og implementasjoner av diverse andre server programvarer. Håpløst, men takk for tipset

 

For utvikling i Visual Studio vil jeg si det er ingenting i nærheten av TFS. Er vel ikke så mye ekstra programvare du må ha når du installerer TFS? Spesielt ikke hvis du bare skal bruke det som versjonskontroll. Eneste jeg kan komme på er egentlig SQL Server.

 

Anyways...har brukt git og svn i tillegg til TFS de siste par årene litt avhengig av prosjekt jeg har vært i. SVN har jeg borti noe av problemene du beskriver, men det har i det store og det hele fungert greit. Git er pokker meg det mest tungvindte systemet jeg noengang har vært borti. Microsoft SourceSafe virker jo bedre Helt ærlig...skjønner ikke helt alt fuzzet rundt git. Klart, du har noen features som local commits som du ikke har i andre systemer, men gud bedre å tungvindt det er å bruke. Spesielt integrasjonen i visual studio er helt horribel imho.

[HDSoftware]

Når jeg installerte TFS så krevde den jo ikke bare SQL server. Den krevde også SharePoint.

 

Men den største bøygen var at vi også bruker en annet Win32 dev GUI med app filer lagret som BIN filer (ikke source code). Jeg fant ingen god implementering av TFS i OS'et slik at det ble utrolig tungvint å sjekke inn filer utenfor Visual Studio. Selve implementasjonen av TFS i Visual Studio var helt utrolig bra og faktisk veldig lik Visual Source Safe. Hadde det ikek vært for denne drawbacken så hadde jeg fortsatt med TFS...

 

Hvis jeg tar feil angpende OS implementering så si ifra for veien til TFS er ikek lang for oss...

[asicman]

Tror jeg skal undersøke på jobben om det er mulig å flytte til Git istedet for SVN.

 

Du kan bruke git som front-end til svn som gir deg mange av fordelene til git.

 

git svn clone svn://svn-uri

 

deretter jobbe i git, lage brancher, klone disse videre for testing andre steder, la andre clone ditt git repo for testing, git bisect, slå sammen mange små git commits med git rebase -i og til slutt

 

git svn rebase
git svn dcommit

 

for å sjekke tilbake inn i svn. Den første svn clone tar en del tid (hvis repo er stort), men etter det er det mye mer effektivt å buke git som front-end. Jeg jobber fortsatt i mot svn repo'er, men har ikke brukt svn på flere år. Bruker magit i emacs slik at man aldri ser git kommandoene heller...