Bedre Subversion Practices

Når vi sier Subversion, eller SVN, forstår hver utvikler som bruker den, hva vi skal snakke om. SVN bør være de facto-elementet i enhver utviklingssyklus. Vi kan bruke SVN ikke bare med kodefiler, men med alle typer filer som er involvert i utviklingsprosessen (men det er ikke begrenset til disse filene heller).

I denne artikkelen vil vi vurdere hvordan vi kan bruke SVN effektivt ved å følge noen få praksis. Det vil bidra til å forbedre utviklingsarbeidet og gjøre den endelige kildekoden mer stabil. Når vi sier stabil, betyr det at det vil få færre konflikter enn andre tilnærminger, men å gjøre det 100% konfliktfritt er nesten umulig, fordi alle utviklere har egne måter å få jobb på.

Vi vil gå gjennom nedenstående punkter i denne artikkelen:

1. Repository Patterns
2. Repository Elements
   
3. Grenpolitikk
   
4. Noen få viktige praksiser
   

Repository Pattern

Denne delen omhandler strukturen til ditt arkiv. Det kan være enten et enkelt lager eller flere lagre. Begge mønstrene er mye brukt i bransjen, og begge har sine egne fordeler og ulemper. Så det er helt opp til oss hvilken en vi skal bruke basert på våre krav.

Single Repository Pattern

I dette mønsteret bør vi opprette ett lager i SVN-serveren og fortsette å legge til flere prosjekter i samme lagringsplass. Normalt når vi planlegger å bruke dette mønsteret, bør vi lage et lager uten standard lagringsstruktur, det vil si ingen grener, koder eller trunk katalog. Dette er imidlertid ikke obligatorisk.

Det er forskjellige måter folk følger på dette mønsteret nedenfor er noen av dem:

Root - ProjectA - grener - tagger - trunk - ProjectB - grener - tagger - trunk

Root - ClientA - ProjectA - grener - koder - bagasjerom - ProjectB - grener - koder - bagasjerom - ClientB - ProjectB - grener - koder - kofferter 

Dette mønsteret følges når vi har en liten gruppe mennesker som jobber med noen få prosjekter, og prosjektstørrelsen er liten til middels. Dette kan også implementeres for prosjekter som er relatert til hverandre og deler viss kode. Dette mønsteret har sine egne fordeler og ulemper som er som nevnt nedenfor:

Pros:

• Enkelt sted for all kode, selv for prosjekter som ikke er relatert til deg.
• Enkelt autorisasjon, fordi tillatelse må tildeles for ett lager og resten er bare kataloger under det.
  
• Mindre administrativt arbeid: Et nytt prosjekt kan legges uten hjelp av en SVN admin fordi det ikke er nødvendig å opprette et nytt lager. Fra en backup punktvisning, må administrasjonen ta backup av bare ett lagringssted. Hele prosjektet kan fjernes uten å fjerne lageret.

Ulemper:

• Som flere prosjekter er inkludert, kan dumping og sjekke ut et stort lager bli svært tidkrevende.
• Revisjonsnummeret gjelder hele lageret, så revisjonsnummeret for prosjektet vil fortsette å øke (selv om det ikke er gjort noen forpliktelser på dette prosjektet) i henhold til forpliktelser i andre prosjekter.
  
• Forgrening og merking blir en kompleks prosess når antall inkluderte prosjekter og kataloger vokser.
  

Multiple Repository Pattern

Dette mønsteret passer for store prosjekter som kanskje eller ikke kan forholde seg til hverandre. Som med den forrige metoden har denne metoden sine egne fordeler og ulemper, som er som nevnt nedenfor:

Pros:

• Vi kan definere tilgangstillatelse for alle brukere og prosjekter. Så hver bruker har tilgang til prosjekter som de er involvert i.
• Hvert prosjekt vil ha sin egen revisjonsnummer sekvens.

Ulemper:

• SVN støttes ikke ved sammenslåing av kode fra et annet lagringssted.

Repository Elements

En hvilken som helst type lagringsplass kan inneholde (men ikke er begrenset til) tre elementer, som er grener, koder og stammen. Det er ingen slik veldefinert definisjon på bruken av disse tre elementene. Vi kan sette det på hvilken måte vi vil. Vil du at koder skal være din viktigste utviklingslinje? Ikke noe problem i det hele tatt, bare gå videre og gjør det. Ingen vil arrestere deg.

Men deres små retningslinjer utviklet seg basert på erfaring med å jobbe med SVN, og vi har noen retningslinjer for hver av elementene.

Stamme

Hjulet er brukt til den siste / nåværende utviklingslinjen. 

grener

En gren skal brukes når vi har noen betydelige endringer som kan forstyrre hovedutviklingslinjen (stammen). Så for å jobbe uten å påvirke bagasjen, bør vi lage en gren fra kofferten og gjøre de nødvendige endringene i det. Så senere, når vi er ferdige med endringene, kan vi fusjonere den grenen til bagasjerommet.

Tags

Etiketter anses som et øyeblikksbilde av koden din på et bestemt tidspunkt, f.eks. MileStone1, Milestone2, etc..

Grenpolitikk

Vi kan ha en uendelig debatt om dette emnet, fordi alle har sitt eget perspektiv mens de arbeider med grener i SVN. Hver policy har sine fordeler og ulemper, som vi vil se i neste avsnitt:

Aldri Branch

I denne policyen fortsetter hver utvikler bare å jobbe på bagasjen, og ingen forgrening og sammenslåing holdes her. 

Pros:

• Veldig enkel politikk å bli tatt.
• Minimal til ingen læringskurve. Utviklere må passere gjennom å lære om forgrening og sammenslåing.
  

Ulemper:

Hver utvikler forplikter seg på bagasjerommet, slik at bagasjen kan være ustabil når som helst, noe som kan være et større problem. 

Alltid gren

I denne policyen kan utviklere jobbe med hver funksjon på en egen gren i stedet for på stammen selv. Når endringene er gjort, kan det bli vurdert på en gren og senere fusjonert med stammen. 

Pros:

• Som hver vil bli utviklet på en egen gren, vil stammen forbli stabil på et hvilket som helst tidspunkt. Fordi tingene blir testet og utviklet på grenen, har kofferten alltid gjennomgått koden.

Ulemper:

• Hver utvikler har ikke en gjennomsiktig visning av andre utviklers funksjoner, og det kan skape flere konflikter mens de slås sammen med kofferten.
• Det kreves mer administrativ tid for å løse disse konfliktene og slå sammen grenen til bagasjerommet.
  

Gren når det trengs

I dette mønsteret fortsetter brukeren å arbeide på bagasjen for å redusere mengden forgrening og sammenslåing. Men en utvikler bør skape en gren når det er nødvendig. 

Hvordan identifisere dette behovet? I dette tilfellet bør utvikleren stille spørsmålet til seg selv: Hva om endringen min krevde flere endringer? Hvis jeg skal forplikte alt på en gang, vil det motvirke eller skape et problem for peer review?

Hvis du har et ja svar på noen av de ovennevnte spørsmålene, bør du opprette en ny gren for den funksjonen, og når du er ferdig med funksjonen, kan den slås sammen med bagasjerommet etter riktig testing på selve grenen.

Pros:

• Sammenlignet med "Always Branch", har denne metoden mindre forgrening og sammenslåing.
• Bagasjerommet er garantert å være stabilt hele tiden.
  

Ulemper:

• Selv om det innebærer mindre forgrening og sammenslåing, vil det legge til ekstra oppgaver for forgrening, sammenslåing, kompilering og testing.

Viktige tips

Bruk kroker

Vi kan bruke en pre-commit-krok for å sørge for at utviklere har angitt den nødvendige meldingen. Vi kan også bruke en post-commit-krok for å sende e-post til en høyere autoritet for kodevurderingen. 

Hold deg oppdatert

Det er alltid foretrukket å oppdatere koden til hodet for å sikre at du har den nyeste koden med deg. På denne måten vil det redusere sjansene for konflikter i kode og forbedre stabiliteten.

En ting om gangen

Tenk deg at du har jobbet med flere endringer, og du forplikter alle filer på en gang og sier at du har fullført oppgave 1, oppgave 2 og oppgave 3. Etter noen dager kan noen andre utviklere finne ut hvilke filer som er relatert til hvilken oppgave? Så det er en veldig enkel regel å følge: Foreta en endring om gangen, i stedet for å begå flere endringer i en enkelt forpliktelse.

Gjør bruk av loggmeldinger

Vi er menneskelige, derfor har vi en tendens til å glemme ting. Så det er alltid god praksis å legge inn en detaljert loggmelding mens du forplikter deg til endringer i SVN. Det vil hjelpe oss å forstå hva som har blitt begått når, slik at vi lett kan gå tilbake til den versjonen ved bare å se på loggmeldingen. La oss se på to forskjellige loggmeldinger:

1. "Fullførte endringer": Dette er ufullstendig, og vi kan ikke forstå hva som er begått.
2. "Fullført Facebook-integrasjon, lagt til Facebook SDK-filer": Dette er komplett og godt detaljert. Det viser hvilke endringer som er gjort og hvilke avhengige filer som ble lagt til.

Forplikte ofte

Hvis du jobber med en større oppgave, enn det anbefales å foreta endringer oftere mens du jobber med oppgaven, i stedet for å begå seg etter at oppgaven er fullført. Denne praksisen vil hjelpe deg med å komme inn i et hvilket som helst stadium av den aktuelle oppgaven.

Backup Repository

Endelig et notat for SVN-administratorer, gjør alltid regelmessige sikkerhetskopier av ditt arkiv. Dette vil hjelpe deg når det er en katastrofe.

Konklusjon

Som nevnt tidligere i denne artikkelen er det ikke angitt i steinregler definert for bruk av SVN. Så jeg har prøvd mitt beste for å finne noen retningslinjer for å jobbe med SVN basert på min samlede erfaring.