Versjonskontrol alternativer

[HDSoftware]

Det stemmer. Clarion har ingen åpning for at to eller flere kan jobbe med den samme APP filen. Normalt ikke noe problem og som jeg har nevnt tidligere så bruker vi altså ikek SubVersion til kildekode håndtering i Clarion, men kunn som et utlånssystem med muligheten til å si "Jeg tar appen fordi jeg skal endre noe i den"

 

Anyway, jeg har fått svar på det jeg lurte på så jeg melder meg ut av tråden..

[David Brown]

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

 

Når jeg leser hvordan Clarion fungere, med "touch" på filer som er uendret bare fordi man har åpnet dem for å lese dem, har jeg mye mer forståelse for hvorfor du ønsker låsing. Da er den "read-only" checkout du får fra låsing veldig hjelpsom.

 

Men det er likevel ikke nok i seg selv. Hvis du ta en checkout eller update på en prosjekt og låse det, kommer Clarion til å endre filene dine selv om de egentlige er det samme. Dermed ved neste commit blir disse filene sendt til serveren som en ny versjon, som er høyst uønsket.

 

Jeg vet ikke hva som er det beste løsningen her (annet enn å klage på de som lagte Clarion). Kanskje du må bli vant til å ta en "svn revert" på Clarion mappene før en commit, når du vet at du ikke har endret noe? Det ville selvfølgelig fungere med andre VCS også.

[Terrasque]

Fant et StackOverflow spørsmål om dette : Locking binary files using git version control system

 

Svarene der er vel generelt sett det samme som har kommet frem i denne tråden. Det er gitt noen workarounds der, men tror ikke de passer til HDSoftware's bruk.

[HDSoftware]

Den beste løsningen her er å bruke Get Lock. Dette forteller SVN at filen er locket av en bestemt bruker og ingen andre får noe annet en en ReadOnly versjon av denne filen når de kjører en Update. Dette fungerer svert bra og har aldri skapt noe problem i det hele tatt, noe jeg har prøvd å si veldig lenge. Vi har altså ingen problemer med Clarion prosjektene i det hele tatt. Dette fungerer 100% knirkefritt, nettop fordi vi kan locke en app. Hvis vi derimot hadde gått over til GIT, som ikke kan locke hadde vi vært nødt til å bruke en himla masse tid på reversering og alt det andre man må forholde seg til. Ser ikke hvorfor denne tråden eskalerer rundt Clarion i det hele tatt da dette faktisk aldri har vært noe issue for oss. Jeg nevnte kunn tidligere i tråden at GIT ikke kan brukes nettop av denne årsaken. Går det ikke an å bare akseptere det da?