Subversion er nu Apache Subversion

Windcape (49) skrev:

Jeg har endnu ikke set argumenter for hvorfor det skulle være nemmere at bruge en terminal. Argumentet er jo bare at der ikke er nogen som har lavet en GUI oven på terminal kommandoerne endnu!

Måske burde jeg lige adresse dette specifikt.

Ja, i princippet kunne du lave en GUI-komponent til hver eneste ting man kunne tænkes at få brug for, men hvis du gjorde det, ville din GUI meget hurtigt blive overplastreret med funktioner du stort set aldrig bruger og ødelægge overskueligheden fuldstændigt.

Spiderboy:

Og versionstyring er ikke hverdagsbrug? Det er jo netop hvad jeg mener det er.

At lade komplekse ting kræve løsning via en terminal er sådan set okay, så længe basale funktionaliteter er tilgængelige i ens IDE.

Spiderboy (51) skrev:

Ja, i princippet kunne du lave en GUI-komponent til hver eneste ting man kunne tænkes at få brug for, men hvis du gjorde det, ville din GUI meget hurtigt blive overplastreret med funktioner du stort set aldrig bruger og ødelægge overskueligheden fuldstændigt.

Der er jo ingen som siger at GUI skal præsentere alle muligheder samtidig altid. Det er kun Eclipse udviklerne som har sådan en underlig tilgangesvinkel til udvikling.

IDE integration med TFS eller SVN i Visual Studio er helt fint, og nemt overskueligt. Jeg kan ikke se hvorfor git skulle være anderledes, det ville jo være samme GUI, bare forskellige underliggende kommandoer til de fleste ting.

De generelle koncepter i VCS er jo stort set ens ligegyldig hvilket system du bruger.

Windcape (52) skrev:

At lade komplekse ting kræve løsning via en terminal er sådan set okay, så længe basale funktionaliteter er tilgængelige i ens IDE.

Det er jo også lige præcis det jeg siger i #50. Jeg argumenterer på ingen måde imod integration i IDE'en. :-)

Windcape (52) skrev:

Der er jo ingen som siger at GUI skal præsentere alle muligheder samtidig altid. Det er kun Eclipse udviklerne som har sådan en underlig tilgangesvinkel til udvikling.

Men alle tænkelige og utænkelige funktioner du muligvis kunne få brug for skulle være tilgængelig et eller andet sted. Også meget specialiserede ad-hoc opgaver.

arne_v (41) skrev:

Hvis det er bug fixing.

Ellers vil der typisk være flere rettede filer.

Det er ikke hensigtsmæssigt at check ting ind som ikke builder eller vil fejle runtime p.g.a. at der mangler noget.

Hvis man tilføjer en metode, kan man sagtens lave et commit, inden man tager den i brug. En refaktorisering vil selvfølgelig berøre flere filer, så der giver det mening, at inkludere det hele.

Hele pointen med at bruge branches er også, at hver eneste branch ikke behøver kunne bygge hele tiden. Den skal bare kunne gøre det, når den integreres.

arne_v (44) skrev:

Jeg har en noget anderledes tilgang.

Det er vigtigt at det som er checket ind:
- builder
- kan starte op (i det mindste så meget at der står "denne feature er ikke færdigimplementeret endnu")

Ellers bliver det hurtigt meget problematisk for projekter med mange udviklere. Man skal kunne update uden at være bange for at pludseligt ingen ting virker.

Og jeg vil mene at reviews er nemmere hvis alle rettelser som vedrører en bestemt enhacment eller bug fix er bundtet sammen - de skal jo alligevel reviewes sammen.

Jeg ser det ikke som modstridende at ting skal kunne bygge, selvom jeg dog ikke har det som et krav på samme måde. Det meste af dit arbejde er inkrementelt alligevel, og så giver det også meningen, at dine commits beskriver din proces, så man kan gå fem skridt tilbage og videre derfra, hvis det er mest hensigtsmæssigt.

Som themuss også skriver, behøver det heller ikke betyde noget for hverken review eller historik. Man kan sagtens lade den detaljerede historik fremgå kun på ens topicbranch og således kun have et commit, der beskriver den nye feature, når man integrerer. Man kan tilsvarende let lave en diff over alting på den ene branch, hvis man vil foretage review ad én gang.

Mht. review er det dog stadig min holdning, at folk ikke kan overskue det tilfredsstillende, hvis der foregår for meget på en gang. De fleste har derimod lettere ved at forholde sig til, at du måske mangler et tjek, hvis et commit på få linjer reviewes.

Windcape (46) skrev:

Det kan aldrig blive hurtigere at du skal forlade dit udviklingsmiljø for at lave et commit.

Forlade mit udviklingsmiljø? Har du hørt om multitasking? Det er snart længe siden, det blev introduceret.

Jeg kan sagtens have både udviklingsmiljø og en terminal åbent på samme tid, og så er det altså bare et tastatryk, der adskiller de to ting (ligesom hvis jeg i øvrigt skulle have fat i en menu i udviklingsmiljøet).

Windcape (46) skrev:

Og derudover tror jeg du kraftigt overvuderer hvor mange der rent faktisk bruger VCS som andet end backup, og history log. Det er jo nemt nok i dit eget firma, men prøv at kigge i større organsationer.

Netop Open Source projekter har bedre / mere moderne strukture er fordi at folk spendere tid på det derhjemme. Hvis der stod en chef og kiggede dem over skuldren, så ville de sikkert stadigvæk bruge CVS.

Det er da muligt, at det ofte er sådan, men hvad er dit argument? At folk bruger VCS til backup betyder jo bare, at de dels har misforstået konceptet og dels kunne nøjes med noget helt andet...

Derudover ved jeg ikke, hvem du tænker på som store virksomheder, men du skal være velkomne til at komme med nogle bud, for hvem versionskontrol er fuldstændig ligegyldigt.