windows - Arbejder med Mercurial lokalt og SVN eksternt?

Indlæg af Hanne Mølgaard Plasc

Problem



På arbejdspladsen bruger vi Subversion, men fordi ingen forstår, hvordan vi skal forgrene vores 'forgrening' indebærer kopiering af hele kodebase og behandling af det som et separat lager - det betyder alle ændringer, vi gør til 'patch' -grenen, skal kopieres/indsættes til hovedudvikling ('trunk') filial, så de er synkroniserede, og vi kan ikke bruge indbyggede fusionsværktøjer (Vi bruger manuelt WinMerge eller ligner de linjer, der blev ændret). Ingen ønsker at tage sig tid til at lære at bruge SVNs forgreningsfunktioner og i stedet opfordre til at bruge denne strategi som et alternativ.


Da jeg ikke kan overbevise alle andre om at se på virkelige forgreninger, ser jeg på at gøre noget for mig selv for at gøre fusionerne mindre smertefulde. Jeg har ønsket at se på Mercurial i et stykke tid nu (jeg har tidligere brugt Git lidt på min Mac ; Windows7 på arbejde) som en engros SVN udskiftning, hvis jeg kunne få buy-in.


Mit spørgsmål er dette: For det første ville det være vanskeligt at bruge Mercurial på min lokale maskine, hvis jeg skulle skubbe ændringer til to SVN-depoter? Lokalt kunne jeg bruge forgrening til at fusionere koden igen nemt, idet det ville være et simpelt spørgsmål at skubbe grenen til patchkoden, og dev-filialen (efter sammenlægning selvfølgelig) til dev-filialen i SVN, højre ?


For det andet, inden jeg introducerer Mercurial, er der en bedre måde at gøre dette på? Jeg har forsøgt at fortælle mine kolleger om brugen af ​​SVNs forgrening, men svaret jeg får er, at 'dette virker for nu', da ingen ønsker at tage sig tid til at lære SVN-forgrening, og for at være 100\% ærlig, har jeg aldrig brugt SVN forgrening mig selv, så jeg er ikke sikker på, hvor let/hårdt det er at bruge, og vil ikke risikere at forsøge at grene og knuse noget op.

Bedste reference


Først og fremmest for at være ærlig, hvis du får denne form for svar om de mest grundlæggende ting i SVN-forgrening, tror du virkelig, du kunne overbevise dem om at skifte hele deres depotsystem?


Selvfølgelig, 'vil ikke risikere at forsøge at grene og knuse noget op' er meget typisk for SVN, og noget, som Mercurial gør meget bedre; som du altid arbejder i et lokalt lager, eksperimentere og lave fejl er billig, og du kan bare lave en ny klon, hvis du rydder op. Jeg vil absolut anbefale Mercurial over SVN i stort set enhver situation undtagen for repositorier, der skal indeholde store mængder binære data som kunstarkiver.


Nu hvad angår dine spørgsmål,


I princippet kan du bruge samme arbejdskatalog til et Mercurial-lager og et SVN-depot. Du vil sandsynligvis tilføje .hg og .svn til SVN og Mercurials ignoreringsfiltre, og selvfølgelig vil ændringer, du forpligter dig til Mercurial, ikke automatisk forpligte sig til SVN. Men det kan være bekvemt at bruge Mercurial som et klud for lokal udvikling. Hvis du har to SVN checkouts, du vil gøre dette, kan du faktisk bare udveksle data mellem Mercurial kloner ved at trække eller skubbe fra den ene til den anden.


For at være ærlig, mener jeg dog som svar på dit andet spørgsmål, at den 'bedre måde' bare er at lære SVNs forgrenings- og fusionsmekanik. At køre Mercurial på toppen af ​​SVN kan være ret besværligt, og det kan være mere problemer end det er værd. Hvis du vil eksperimentere med SVN-fusion, kan du lave et test SVN-depot for at øve forgrening og sammensmeltning der.


Hvis dine kolleger har besluttet sig for SVN og ikke kan være generet om Mercurial, skal du nok bare leve med det. Måske er der noget trøst i, at der er mange i lignende situationer, jeg vil personligt gerne stoppe med at bruge SVN hurtigere end senere, men stadig i mit tidligere og nuværende firma er jeg desværre fast ved det. Selvom jeg i mit nuværende firma er åbne for at ændre det på et eller andet tidspunkt i fremtiden, arbejder vi allerede med git til et eksternt projekt.


Endnu en ting, jeg nok bør nævne: Der er værktøjer som hgsubversion-udvidelsen, der giver dig mulighed for at arbejde med Mercurial på toppen af ​​SVN, og konvertere alle forpligter sig til Mercurial-forpligtelser. Jeg vil ikke rigtig anbefale det selv, men hvis du er en nybegynder Mercurial-bruger, betyder den grundlæggende mismatch mellem SVN og Mercurial, at forgrening ikke er virkelig muligt, hvis du vil skubbe dine ændringer tilbage, du er nødt til at rebase hele tiden og du kan meget nemt ende med tab af data.

Andre referencer 1


Bemærk:


svn merge URL1 URL2


kan bruges til ikke-relaterede webadresser ( forskellige reposer ). Flette inden for et repo er bare en konvention og arbejdsgang



  ville det være vanskeligt at bruge Mercurial på min lokale maskine, hvis jeg skulle skubbe ændringer til to SVN-arkiver?



Nej, altid er gennemsigtig



  • Repo1 for MainSVN pull MainSVN + træk Repo2 + fusionshoveder + tryk

  • MainSVN Repo2 for DevSVN (pull DevSVN + push DevSVN)




  før jeg introducerer Mercurial er der en bedre måde at gøre dette på?



Se min startnotat - du kan i det mindste prøve native svn fusion mellem repos