Versjonskontrol alternativer

[The Jackal]

Du må ikke sette opp Sharepoint så vidt jeg vet. Altså, må muligens være installert, men det er jo uansett bare en del av Windows Server, altså gratis. Om du vil bruke sharepoint integrasjonen, så må du naturligvis også konfigurere Sharepoint, men dette er kun om du vil ha et webgrensesnitt f.eks til kildekode, og det er vel muligens der også litt forskjellige burndown charts osv presenteres om du bruker workitems osv. Anyways, går fint an å la være å konfigurere sharepoint så vidt jeg husker (får ta det med en liten klype salt, men om man må det, tar det ca 10-15min maks om du kan det).

 

Ellers er jo GUIet for innsjekking av filer i TFS nettopp Team Explorer. Om du installerer Team Explorer på en maskin uten Visual Studio, så vil du se at det er nettopp Visual Studio den er basert på Jeg vet ikke om noe annen klient enn det egentlig, men det går fint å legge til filer utenfor en solution via denne klienten. Du har ellers command line utility om det er noe hjelp: http://msdn.microsoft.com/en-us/library/z51z7zy0.aspx. I tillegg har du namespace Microsoft.TeamFoundation om du vil programmere noe selv

[HDSoftware]

Linken din førte ingen steds...

 

Du har uansett vekket min interresse for TFS igjen. Team Explorer er noe jeg ikek har hørt om så den skal jeg sjekke ut..

[The Jackal]

Team Explorer er den klienten du er vant til...altså integrasjonen i Visual Studio. Jeg påpekte bare at du må strengt tatt ikke installere visual studio med C# osv for å få en integrasjon mot TFS. Installerer du Team Explorer så får du en light versjon av visual studio. Ble et punktum for mye når du klikker på den linken: http://msdn.microsoft.com/en-us/library/z51z7zy0.aspx

[HDSoftware]

Ok!!! Jeg er solgt!! CommandLine integrasjonen sammen med .NET APi'et gjør jo dette utrolig enkelt å implementere over allt :-D Takker for infoen!!

[zotbar1234]

SVN har jeg borti noe av problemene du beskriver, men det har i det store og det hele fungert greit.

 

Det er en funksjon av arbeidsflyten.

 

Hvis man har fortalt seg selv at branching er noe man egentlig ikke trenger, at lokale commits er noe man ikke trenger, at å være avhengig av en sentral repo ikke er en ulempe, at integritet av commits er noe man ikke bryr seg om, at det er helt greit å vente et par minutter på en svn blame, så kan man bruke svn. Tross alt bedre enn ingenting (med nød). I et flerutviklermiljø tar det svært kort tid før svn sine begrensninger setter dype spor.

[HDSoftware]

Men så lenge GIT ikke støtter file locking så er det ubrukelig for oss. Mange av våre prosjekter inneholder Clarion apps og disse er ikke basert på tekst, men er lagret som binær filer. Det er avgjørende at disse kan file lockes pr. utvikler. En Offline repository mekanisme forhindrer derfor dette.

[zotbar1234]

Mange av våre prosjekter inneholder Clarion apps og disse er ikke basert på tekst, men er lagret som binær filer. Det er avgjørende at disse kan file lockes pr. utvikler.

 

Kunne du forklare litt nærmere hvorfor det skulle være nødvendig å låse en fil til en utvikler? Folk kan ikke redigere den samme filen samtidig i en distribuert modell, hvis det var det som var motivasjonen for låsing (dette er mer et spørsmål til arbeidsflyt enn hvilket versjonskontrollsystem man skulle velge).

[HDSoftware]

Vel, som sagt så bruker Clarion for Windows APP filer. Disse filene er ikke lagret som noe kjent filformat, men er en slags database over hvordan en applikasjon er bygget opp. I tillegg er filen kryptert slik at den ikke er lesbar i noe som helst av editor.

 

Så er det slik at når utvikler A åpner denne filen så vil med en gang man lukker appen filen annses som endret. Det betyr at neste gang han oppdaterer så vil denne filen bli forsøkt merget og dermed feile.

 

I SubVersion, eller Tortoise (usikker på hva som er hva) så kan han låse filen slik at ingen andre kan få annet en lese tilgang til den og dermed vil den aldri bli sjekket inn ved en feiltagelse

[asicman]

Det betyr at neste gang han oppdaterer så vil denne filen bli forsøkt merget og dermed feile.

 

Hva mener du med feile? Du kan velge om du vil ha enten din eller den andre versjonen av bin. filen: git checkout --ours eller git checkout --theirs

 

Men heldigvis slipper jeg bin filer i de repo jeg jobber med.

[HDSoftware]

Med andre ord - for mye styr. I Tortoise IDE kan man velge LOCK i stedet for CheckOut og dermed låses filene og ingen trenger å bekymre seg for noe som helst. Videre kan man ghjøre en Comit med Keep lock for oppdatering av repo.

 

Ligger litt i kortene at Team Foundation Server plutselig dukker opp igjen, men det vil tiden vise. I hvertfall holder vi oss til SubVersin en liten stund til

Endret 27. januar 2012 av HDSoftware

[dahuff]

Vel, som sagt så bruker Clarion for Windows APP filer. Disse filene er ikke lagret som noe kjent filformat, men er en slags database over hvordan en applikasjon er bygget opp. I tillegg er filen kryptert slik at den ikke er lesbar i noe som helst av editor.

 

Så er det slik at når utvikler A åpner denne filen så vil med en gang man lukker appen filen annses som endret. Det betyr at neste gang han oppdaterer så vil denne filen bli forsøkt merget og dermed feile.

 

I SubVersion, eller Tortoise (usikker på hva som er hva) så kan han låse filen slik at ingen andre kan få annet en lese tilgang til den og dermed vil den aldri bli sjekket inn ved en feiltagelse

Har aldri hørt noen si locking er en fordel, det er jo en historisk artefakt.

 

Slike problemstillinger unngår man vanligvis ved å ikke sjekke inn prosjekt og kjørefiler til å begynne med. Filer som ikke skal sjekkes inn merkes for ignorering.

[HDSoftware]

Om locking er en fordel eller ikke spiller ingen rolle fordi Clarion prosjektene lagres som BIN filer. Siden vi er tre som jobber med dise prosjektene så kan dette gjøres på en av to måter. Vi kan ha en felles mappe med prosjektene og så ha en manuell ordninger der man markerer prosjektet som AKTIVT og stole på at alle som skal gjobbe med Clarion går veien om denne listen. Alternativt kan vi bruke SubVersion eller lignende og velge File Lock. Ser ikke hvorfor dette er noe ulempe i dette tilfellet - snarere tvert imot, siden Clarion prosjekter ikke lar seg kildekode kontrollere. Om det er en historisk artefakt eller ikke er jo meningsløst. Faktum er jo at Slik er det og man løser ikke problemet ved å velge "utelat" i en eller annen variant. Da kan man jo like gjerne droppe hele SubVersion og gå tilbake til den manuelle måten, som i hvertfall er å annse som en historisk artefakt

[GeirGrusom]

Hvis ikke filene blir kryptert, så mener jeg at Subversion skal være istand til å versjonskontrollere binærfiler. Mulig jeg tar feil dog.

[David Brown]

Om locking er en fordel eller ikke spiller ingen rolle fordi Clarion prosjektene lagres som BIN filer. Siden vi er tre som jobber med dise prosjektene så kan dette gjøres på en av to måter. Vi kan ha en felles mappe med prosjektene og så ha en manuell ordninger der man markerer prosjektet som AKTIVT og stole på at alle som skal gjobbe med Clarion går veien om denne listen. Alternativt kan vi bruke SubVersion eller lignende og velge File Lock. Ser ikke hvorfor dette er noe ulempe i dette tilfellet - snarere tvert imot, siden Clarion prosjekter ikke lar seg kildekode kontrollere. Om det er en historisk artefakt eller ikke er jo meningsløst. Faktum er jo at Slik er det og man løser ikke problemet ved å velge "utelat" i en eller annen variant. Da kan man jo like gjerne droppe hele SubVersion og gå tilbake til den manuelle måten, som i hvertfall er å annse som en historisk artefakt

Jeg skjønner ikke hvorfor du føler du trenger låsing til dette.

 

Tenk deg hva som skjer hvis man ikke låser når du har begynt å jobbe med et prosjekt. Samtidig begynner en annen å jobbe med samme filene. (Skjer dette ofte, har du en svikt i prosjektstyring, som ikke har noe med tekniske løsningene å gjøre.) Første man commit'er koden sin - alt går greit. Neste man prøver å commit'er - han får en "konflikt" og commit går ikke igjennom. Respository er uendret, ingenting er merged (svn prøver ikke å merge binære filer), og utvikleren må rydde opp og manuelt merge. Ingenting blir mistet eller korruptert.

 

Og dersom du låser filene før du begynne å jobbe, mens en annen jobber med filene som han allerede har. Da få han omtrent samme effekt - bare at han får en annen feilmelding da han prøver commit.

 

Låsing hjelper ikke mot dårlig struktur i prosjekt eller mappene, og det hjelper ikke mot dårlig planlegging og organisering av arbeid og oppgaver. Det også åpner for nye problemer, med folk som tar en lås og glemme å frigjøre den (svn har dermed mulighet til å bryte en lås). Låsing passer til enkelte filer eller mapper som mange må endre ofte med raske update/change/commit sykluser - det hjelper da for å unngå conflicts. Men det er aldri nødvendig, og gir ingen realt ekstra sikkerhet (fordi låsene kan brytes) - det er mer kosmetisk, som en ekstra måte å kommunisere mellom utviklerne. Bruker du låsing i vanlig prosjektarbeid, jobber du feil.

 

Og det har ingenting med binære filer å gjøre. Jeg mener det er kritiske at en versjonskontroll program skal kunne håndtere binære filer (vi har mange type ikke-tekst filer i svn repository, som f.eks. odt filer), men man trenger ikke låser for det.

[HDSoftware]

Der tar du nok feil ;-)

Hvordan kan det være mulig? Tenk deg hva som skjer - To personer gjør endringer i prosjektet og dette lagres binært. Når subversion (eller et hvilket som helst annet system) så presenterer for brukeren en konflikt - hvordan skal da den brukeren kunne avgjøre hvilke kryptiske tegn som vises som en konflikt, skal gjelde?

 

En annen ting - Om filen er kryptert eller ikke spiller ingen rolle. Dataene som presenteres er like kryptiske uansett da det ikek er noen forskjell for det menneskelige øyet mellom krypterte data og ikke

 

Husk at side dette lagres binært så er det ikke noe lesbart i disse prosjektfilene..

 

Filen inneholder kunn instillinger i forhold til en template og dette lagres som verdiene. Noe kildekode finnes det der, men det er svert lite. Resten oppfattes av øynene som skrot.

[David Brown]

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...

 

Dette var veldig interessant å lese om. Jeg har ikke satt meg inn i git ennå, men er stor bruker av subversion. Men på enkelte prosjekter hadde det vært nyttig med lokale billige brancher eller små committer - bruk av git lokalt kombinært med svn på serveren er kanskje det beste løsningen der. (Jeg mener å ha lest at mercurial kan også fungere sammen med svn på den måten, men skal jeg først lære og bli vant til en DVCS, er det kanskje mer nyttig å lære git.)

[HDSoftware]

David Brown:

 

Jeg klarer ikke se hvorfor du prøver å løse et håpløst problem med argumenter som ikke har noen betydning for problemstillingen.

 

Som nevnt så kan ikke Clarion sine APP's versjonkontrolleres. Eller for å si det på en anne måte, de er ikek spesiellt versjonkontroll vennlige. Appene inneholder en masse mekanikker som har avhengigheter andre steder i APP filen. App filen er å annse som en relasjonsdatabase. Det blir jo helt håpløst for en utvikler å måtte analysere innholdet i APP filen for å ta et standpunkt på hva som ska være med eller ikke. Jeg sier ikek at det er umulig, men svert upraktisk. Nå er solutionen vår fordelt på ca 20 forskjellige Clarion APP filer. Hver av dem har sine egne egenskaper og funksjonalitet.

 

Jeg skjønner ikke hvorfor du føler du trenger låsing til dette.

Vel. Dette har med det at en app som hentes ut av SubVersion normalt lagres på arb. stasjon uten ReadOnly flagget. Dette forteller Clarion at filen kan endres på. Når appen så åpnes i Clarion og lukkes igjen så har allerede Clarion touchet filen og annses som endret i SubVersion. Når utvikler da sjekker inn igjen så vil SubVersion automatisk mase om versjons konflikt, noe som er helt unødvendig. Ved å locke filen vil den få ReadOnly attribut på utviklers maskin og dermed vil ikke Clarion gjøre noe endringer på APP filen. Du må huske på at i Clarion sammenheng blir SubVersion kunn brukt som et "utlånssystem" for appene. Noe annet kan ikek dette brukes til side man ikke kan kildekode kontrollere noe som helst i Clarion uansett versjonskontroll system.

 

Man kan selvsagt si - Hvorfor bruker man SubVersion i det hele tatt da? Dette har jo med at vi også bruker Visual Studio til andre parter av vår program portefølje og av organisatoriske hensyn så er det fint å ha alt som har med utvikling å gjøre på ett og samme sted. Jeg kunne helt sikkert enkelt laget et BAT fil system som automatisk satte ReadOnly flagget og slikt, men hvorfor? SubVersion gjør jo dette veldig elegant.

 

Så derfor er det uaktuellt å gå over til GIT for det betyr at Visual Studio prosjektene må lagres i GIT og Clarion prosjektene må lagres i noe annet. Den veien gidder jeg ikek engang å ta. Jeg vil ha alt under samme paraply og derfor kan det se ut til at TFS er veien å gå, hvis vi i det hele tatt gidder å bruke mere tid på det. SubVersion gjør jo en god jobb tross alt. Inledningsvis var jo mitt spørsmål om det finnes andre og bedre alternativer og det har jeg fått svar på. Git var ett av dem, men siden Clarion er litt sært så er dette uaktuellt. TFS vil være veien å gå hvis vi tar en beslutning på å bytte...

[zotbar1234]

(...) Ser ikke hvorfor dette er noe ulempe i dette tilfellet - snarere tvert imot, siden Clarion prosjekter ikke lar seg kildekode kontrollere.

 

Hvis Clarion-prosjektfiler ikke lar seg administrere av et versjonskontrollsystem, hvorfor ikke bare fortelle til versjonskontrollsystemet å ignorere disse filene? Dette er noe som alle versjonskontrollsystemer kan, distribuert eller ej.

 

Sagt på en annen måte -- hvorfor har dere disse binærblobbene i historikken overhodet? Eller er det slik at dette er den eneste måten å få lagret prosjektdata på (dvs binærblobbene ikke er avledet av noe annet som _er_ under versjonskontrollsystemets kontroll)?

[HDSoftware]

(...) Ser ikke hvorfor dette er noe ulempe i dette tilfellet - snarere tvert imot, siden Clarion prosjekter ikke lar seg kildekode kontrollere.

 

Hvis Clarion-prosjektfiler ikke lar seg administrere av et versjonskontrollsystem, hvorfor ikke bare fortelle til versjonskontrollsystemet å ignorere disse filene? Dette er noe som alle versjonskontrollsystemer kan, distribuert eller ej.

 

Sagt på en annen måte -- hvorfor har dere disse binærblobbene i historikken overhodet? Eller er det slik at dette er den eneste måten å få lagret prosjektdata på (dvs binærblobbene ikke er avledet av noe annet som _er_ under versjonskontrollsystemets kontroll)?

Dette har jeg allerede svart på. Men kan si det igjen i en kortere variant:

På Clarion siden bruker vi SubVersion som et "utlånssystem" kunn for å holde orden på hvem som har "skriverett" på hva til en hver tid. Ingen annen grunn. Det er derfor meningsløst å dra denne diskusjonen videre

 

På Visual Studio fronten bruker vi system som et fullverdig versjonskontroll system

[David Brown]

Der tar du nok feil ;-)

Hvordan kan det være mulig? Tenk deg hva som skjer - To personer gjør endringer i prosjektet og dette lagres binært. Når subversion (eller et hvilket som helst annet system) så presenterer for brukeren en konflikt - hvordan skal da den brukeren kunne avgjøre hvilke kryptiske tegn som vises som en konflikt, skal gjelde?

 

Det er svært enkelt - de ser fort hvilke filer er i konflikt. Når det er binære filer, kan ikke svn (eller tortoise, dersom du bruker den som front end) hjelper deg med å sammenligne filene. Noen programvare har støtte til slike sammenligningene (f.eks. OpenOffice/LibreOffice kan hjelpe dersom det er tekstbehandler filer). Men som regel må man åpne både den nye versjonen av filen, og din egen endret versjonen (og eventuelt også den tidligere felles baseversjonen), og manuelt kopi og lim endringer over.

 

Husk at dette skal være en unntakssituasjon - har dere en konflikt, har dere dummet dere ut ved å jobbe uavhengige på samme fil.

 

Låsing er bare en måte å se at man kommer til å gjøre noe dumt før man kommer så langt. Men det er fult mulig å gjøre det dumme likevel (man kan jobbe med filen uten å kjøre update - da vet man ikke at det er låst).

 

En annen ting - Om filen er kryptert eller ikke spiller ingen rolle. Dataene som presenteres er like kryptiske uansett da det ikek er noen forskjell for det menneskelige øyet mellom krypterte data og ikke

 

Husk at side dette lagres binært så er det ikke noe lesbart i disse prosjektfilene..

 

Som sagt gjør dette ingenting for svn (eller annen VCS) - alt den vet er at filen har endret seg.

 

Og jeg regner med at brukeren kan lese filen, med de rette programvarene. Ellers er det galskap å bruke dette utviklingsverktøyet.

 

Filen inneholder kunn instillinger i forhold til en template og dette lagres som verdiene. Noe kildekode finnes det der, men det er svert lite. Resten oppfattes av øynene som skrot.

 

Enten er filen en del av prosjektet ellers så er det ikke. (Med "prosjekt" mener jeg en program skrevet med dette verktøyet.) Hvis det er en del av et prosjekt, skal det stå sammen med de andre prosjektfilene i prosjektmappen. Den som jobber med det prosjektet tar en checkout eller update, jobber med filene, og så commit'er. Hvis du ønsker at mange skal jobbe samtidig på samme prosjekt, så må du velge utviklingsverktøy som støtter denne modellen - det høres ut som det blir vanskelig med Clarion.