ProgrammeringsBaren! Småprat, om det du elsker!

[Gjest Slettet+9871234]

Takk for opplysningene.

 

Så det er versjons kontroll systemer? Da holder jeg meg til Git.

[GeirGrusom]

Takk for opplysningene.

 

Så det er versjons kontroll systemer? Da holder jeg meg til Git.

Ja, for det er så enkelt.

[Capitalist Hippie]

Git er fint det -- ta lokal backup før eksperimentering med mer avanserte features (rebasing o.a.).

 

..men selv uten backup kan en som regel ro seg tilbake til land igjen om en Googler litt..

[zotbar1234]

Ja, for det er så enkelt.

 

Til en hel rekke oppgaver -- betydelig enklere enn mange andre (og definitivt så ift svn/cvs).

[GeirGrusom]

Til en hel rekke oppgaver -- betydelig enklere enn mange andre (og definitivt så ift svn/cvs).

Jeg mente ikke at Git var vanskelig å bruke. Jeg har ihvertfall foreløpig til gode å ha noe som helst å si om hvilke kildekodeverktøy som benyttes på en arbeidsplass, da det er blir gjort av systemarkitektene og prosjektledere. Om jeg foretrekker Git, så er det irrelevant for de andre. Jeg kan fortelle om hvor fornuftig det er å bruke feature branches, distribuert system osv. men som noen nevnte i en annen tråd, så er det vanskelig å argumentere for funksjonalitet som andre ikke har benyttet seg av fra før.

[Matsemann]

Største problemet jeg har med Git er som med alt annet fra Linus: Brukerne. Jeg går 3. klasse Data, og har allerede i flere år fått høre hvor "overlegent og bra det er" i forhold til alt annet, av mennesker som så vidt kan Git og aldri prøvd noe annet.

 

Og når de en bruker Git med er alt for glad i rebase-funksjonen. "Det blir sååå rent og fint tre". Hmmf.

 

At det er distribuert ser jeg hverken som en fordel eller en ulempe; til hvert sitt bruk. På jobb er det greit med sentral. Når jeg har kjørt pull-requests mot OS-prosjekter (typ github) har distribuert vært bra.

[zotbar1234]

Jeg kan fortelle om hvor fornuftig det er å bruke feature branches, distribuert system osv. men som noen nevnte i en annen tråd, så er det vanskelig å argumentere for funksjonalitet som andre ikke har benyttet seg av fra før.

 

Vanskelig er det ikke (det er en rekke realistiske scenarioer som cvs/svn bare ikke støtter) - om man får gehør er dog ikke garantert. At en ikke har benyttet seg av funksjonalitet fra før av, betyr hverken at funksjonaliteten ikke er nyttig eller at den ikke ville ha optimalisert arbeidsflyten betydelig. Sagt på en annen måte -- prøv å forklare en amish hvorfor 100Mbps nettforbindelse er nyttig.

 

Største problemet jeg har med Git er som med alt annet fra Linus: Brukerne. Jeg går 3. klasse Data, og har allerede i flere år fått høre hvor "overlegent og bra det er" i forhold til alt annet, av mennesker som så vidt kan Git og aldri prøvd noe annet.

 

Nevn 3 typer funksjonalitet som alternativene til Git/Mercurial har som de to sistenevnte ikke har (at merging av branches krever vanvittig mye innsats, slik det er med svn, er ikke "funksjonalitet" jeg etterlyser).

 

Og når de en bruker Git med er alt for glad i rebase-funksjonen. "Det blir sååå rent og fint tre". Hmmf.

 

Jeg har mistet tellingen på hvor mange ganger jeg har brukt rebase. Og jeg har savnet muligheten til å skrive om mine commits med svn den tid jeg brukte svn. Det var ingen praktisk anledning til det, men akk og ve.

 

At det er distribuert ser jeg hverken som en fordel eller en ulempe; til hvert sitt bruk.

 

Heh. Bruken kan gjerne være basert på ideen om en "master" repository, uansett hva det underliggende verktøyet støtter ellers. Men med sentraliserte versjonskontrollsystemer har man kun den ene muligheten. Det gjør disse systemene underlegne de distribuerte.

 

Det må jo heller ikke nødvendigvis være nettopp git. Gi meg et system som gir meg muligheten til å bla i historikken, committe, stokke om på historikken mens jeg sitter på et fly uten nett, søke i historikken (ekvivalent av hg grep/git grep); et system som ikke krever bedritne tredjepartsverktøy for å støtte noe så enkelt som branch merging (svnmerge.py, say no more) og som ikke tar en jævla evighet mens jeg prøver å finne ut hvem som har committet nettopp disse to linjene, fordi skrotverktøyet har en master å forholde seg til og den er veldig langt unna over en syltynn kanal.

 

"The git parable" er egentlig en veldig logisk motivasjon for et slikt system.

[Matsemann]

Hehe, her er du et veldig godt eksempel på det jeg presenterte i forrige innlegg. Git/Hg er bra, men jeg tror ikke på at ett verktøy er best i alle tilfeller, hverken når det gjelder språk, OS, vcs etc.

 

Som sagt, at du vil sjekke commits mens du sitter på et fly betyr ikke at alle har behovet. Har du det, velg et distribuert. Har man ikke det, er sentralt greit og byr på andre muligheter.

Rebase er en nyttig funksjon, men brukes til mye den ikke burde bli brukt til. Ref. "rent tre". Et prosjekt jeg var borti brukte rebase til å lage enkelte giga-commits, typ en commit per versjon. Slike tilfeller burde man heller ha en master branch som blir merga med working branch, bruke tags, eller noe annet. Også irriterende med folk som rebaser lokalt etter å ha pusha, for så å pushe rebasinga og f*cke opp hele repoet.

[Lycantrophe]

Det å lage svære commits med rebase bryter jo med hele idéen bak (D)VCS og er misbruk av rebase. Det er et argument mot idioter, ikke mot rebase i seg selv.

 

Jeg må innrømme at jeg ikke klarer å se hvilke fordeler SVN har kontra git (og mercurial) for den saks skyld. -At- det er sentralt holder ikke, fordi man kan ha det slik med git/hg og.

[Matsemann]

Det å lage svære commits med rebase bryter jo med hele idéen bak (D)VCS og er misbruk av rebase. Det er et argument mot idioter, ikke mot rebase i seg selv.

Jeg har heller aldri påstått noe annet.

 

Hva er en programmerers siste ord/kode?

 

Pre-CSS:

	   </td>
	  </tr>
	 </table>
	</td>
   </tr>
  </table>
 </td>
</tr>
  </table>
 </td>
</tr>
</table>
</body>
</html>

 

Post-CSS:

		  </div>
		 </div>
		</div>
	   </div>
	  </div>
	 </div>
	</div>
   </div>
  </div>
 </div>
</div>
  </div>
 </div>
</body>
</html>

 

C/C++ m.fl.:

if (launchMissiles = true)
{
  FireNukes();
}

 

Lisp:

)))))))))))))))))))))))))))))))))))))))))))))))))))

 

SQL:

mysql> UPDATE users SET password = '123456'; WHERE username='MyName';
Query OK, 4858210 rows affected (0.51 sec)

[Lycantrophe]

Jeg har heller aldri påstått noe annet.

Da er vi enige :> Jeg har fortsatt å se noen god grunn for hvorfor man skal velge SVN kontra git. Mercurial virker ok, men som en litt kjipere variant av git. CVS er ikke noe særlig :/

 

Java:

throw NullPointerException

[zotbar1234]

Som sagt, at du vil sjekke commits mens du sitter på et fly betyr ikke at alle har behovet. Har du det, velg et distribuert. Har man ikke det, er sentralt greit og byr på andre muligheter.

 

"Nevn 3 typer funksjonalitet som alternativene til Git/Mercurial har som de to sistenevnte ikke har". Jeg er litt nysgjerrig på hvilke "andre muligheter" er det et sentralisert versjonskontrollsystem tilbyr, som gjør det tankesettet til et levedyktig alternativ.

[Matsemann]

En fordel med SVN over Git, som delvis henger sammen med at git er distribuert er at man i svn kan sjekke ut bare en del av treet, bare sjekke inn en del av treet osv. Kan ikke sjekke ut bare en del i Git, siden en må ha hele repoet lokalt.

 

Distribuert har man ikke mulighet for tilgangskontroll på samme måte som en kan i et sentralisert system. Det tilsvarende i Git blir å godkjenne en pull-request til en som allerede har hele repoet. Altså skal de få gjort en jobb må du gi de tilgang til alt, og skal du ha kontroll må du manuelt godkjenne det de pusher (pr). Sentralisert kan man kontrollere lett hvem som får tilgang til hvilken del (grein) av kodebasen, og gi de tilgang til å pushe/sjekke inn i bare visse deler, uten at de noensinne får tilgang til deler av kodebasen de ikke trenger.

 

Nå nevn 5764 ting Git/Hg kan som alternativene ikke kan.

Endret 8. desember 2012 av Matsemann

[zotbar1234]

En fordel med SVN over Git, som delvis henger sammen med at git er distribuert er at man i svn kan sjekke ut bare en del av treet, bare sjekke inn en del av treet osv. Kan ikke sjekke ut bare en del i Git, siden en må ha hele repoet lokalt.

 

Kan du forklare hvordan det er en fordel å kunne hente ut en ikke-konsistent commit?

 

Distribuert har man ikke mulighet for tilgangskontroll på samme måte som en kan i et sentralisert system.

 

Det er helt riktig -- man slipper å gi alle som skal committe skriverettigheter til masterrepo. Igjen, en ulempe med sentralisert versjonskontrollsystem.

 

Det tilsvarende i Git blir å godkjenne en pull-request til en som allerede har hele repoet.

 

Det finnes adskillig flere måter å gjøre det på.

 

Altså skal de få gjort en jobb må du gi de tilgang til alt, og skal du ha kontroll må du manuelt godkjenne det de pusher (pr). Sentralisert kan man kontrollere lett hvem som får tilgang til hvilken del (grein) av kodebasen, og gi de tilgang til å pushe/sjekke inn i bare visse deler, uten at de noensinne får tilgang til deler av kodebasen de ikke trenger.

 

Beklager, men, altså, nei. Tilgangskontroll er et av de store *problemene* med sentralisert versjonskontroll; ikke en fordel.

 

Nå nevn 5764 ting Git/Hg kan som alternativene ikke kan.

 

Er du ironisk nå, eller vil du virkelig ha listen over ting som alternativene ikke kan?

[Matsemann]

Kan du forklare hvordan det er en fordel å kunne hente ut en ikke-konsistent commit?

Kan ikke du snart komme med egne argumenter for noe?

Det kan være konsistent selv om man bare ser en del av treet.

Det er helt riktig -- man slipper å gi alle som skal committe skriverettigheter til masterrepo. Igjen, en ulempe med sentralisert versjonskontrollsystem.

Her må du vri veldig for å få det på din side. Her skrev jeg bare en fordel sentralisert kan ha. At distribuert har andre fordeler gjør ikke det til en ulempe for sentralisert.

Det finnes adskillig flere måter å gjøre det på.

Klarer du å nevne noen?

 

Jeg var ironisk, fordi du dikterer en diskusjon og ønsker å kåre en "vinner" av VCS. At du ikke ser fordeler med noe av det jeg listet opp forteller litt om hvor farget du er i ditt syn. Andre kan faktisk ha behov du ikke har.

Endret 8. desember 2012 av Matsemann

[sindreij]

Noen klarer seg uten VCS, noen klarer seg med svn og noen må ha mulighetene git tilbyr. Selv ser jeg ingen grunn til å bruke noe annet enn git (eller Mercurial, bruker git siden det er det jeg kjenner). Jeg brukte en gang svn, men ser meg aldri tilbake. Jeg kjenner også folk som jobber i store selskaper som bruker svn og ikke kan bytte over til git fordi det er en for stor jobb og holder på å gå på veggen av irritasjon over svn. Den største fordelen til git mener jeg at det faktisk er mulig å jobbe med brancher, og det gjør det til en utrolig bra workflow. Det er også mulig å jobbe med brancher i svn, men da må du bruke tredjeparts verktøy, og selv da har det en tendens til å gå skikkelig dårlig.

 

Den store bakdelen med git er at det er et kraftig verktøy, og dermed er det veldig mulig å skyte seg selv kraftig i foten, for eksempel rebase på commits som allerede er pushet. Dog er det vel hindre for å gjøre slik (som man kan fjerne ved å bruke --force).

 

Eneste grunnene jeg kan se til å bruke svn er enten at man har en stor kodebase som man ikke har tid til å endre til noe annet, eller at man ikke har tid til å lære alle utviklerne noe annet.

[tomsi42]

Vi har brukt SVN også til brancher, og jeg syntes ikke det var så plagsomt. Det som er viktig er å lære seg svakhetene og styrkene til verktøyet, og bruke det riktig. Prøver man å bruke SVN som git eller omvendt, så blir det bare tøys.

[zotbar1234]

Kan ikke du snart komme med egne argumenter for noe?

 

Jeg vet ikke helt om jeg forstod hva du etterlyste.

 

Det kan være konsistent selv om man bare ser en del av treet.

 

Ja, det kan det. Men vil ikke alltid være det. Hvordan får du det til å være en fordel?

 

Her må du vri veldig for å få det på din side. Her skrev jeg bare en fordel sentralisert kan ha.

 

Å måtte gi skrivetilgang til masterrepo er ikke en fordel.

 

At distribuert har andre fordeler gjør ikke det til en ulempe for sentralisert.

 

Sentralisert arbeidsflyt har ingen fordeler som man ikke har med distribuert arbeidsmodell (først og fremst fordi at et distribuert system kan brukes som sentralisert, om man så ville).

 

Klarer du å nevne noen?

 

Vi snakker altså om å ta med bidrag fra folk til prosjektet i distribuert vs. sentralisert arbeidsflyt. I en tilfeldig rekkefølge:

 

* Eget område for bidragsyteren sin branch (med eksempelvis gitolite. Ja, det er plassmessig veldig billig (med gitolite, iallfall)), som de med skrivetilgang til "master" har en pull/merge fra.

* git am/git format-patch (*lysår* foran manuelle diff-er)

* Få bidragsyteren til å publisere sitt tre på den måten vedkommende er komfortabel med og ta en merge fra bidragsyteren sin remote. Legg merke til at oppgaven om å løse konflikter overlates til bidragsyteren.

* Med noen verktøy (f.eks. gitolite) kan man avgrense hvilke filer en gitt bruker får lov til å oppdatere, hvilket var, med mindre jeg misforstod, et av hovedpoengene dine med adgangskontroll med svn. Så om man først insisterer på å gi en bruker skrivetilgang til det som døpes som "master", kan man likefullt avgrense hva vedkommende får oppdatere i master.

 

For en enlinjers patch uten commitmelding vil patch (verktøyet, altså) + e-post duge med svn også. Såsnart man beveger seg utenfor dette, er ikke manuelle diff-er et reelt alternativ.

 

At du greier å legge frem et krav om å gi skrivetilgang til masterrepo som en fordel som svn innehar er helt hinsides fornuft.

 

(...)ønsker å kåre en "vinner" av VCS.

 

Jeg har aldri på noe tidspunkt antydet at det var en konkurranse å vinne; vennligst ikke legg frem dine ideer som mine.

 

At du ikke ser fordeler med noe av det jeg listet opp (...)

 

Det du har listet opp er ikke fordeler.

 

Andre kan faktisk ha behov du ikke har.

 

Soleklart.

 

Men behov og fordeler er to forskjellige ting. At man ikke har behov for et distribuert arbeidsflyt er ikke ensbetydende med at et sentralisert versjonskontrollsystem er et riktig eller et mer fordelaktig valg (selv med fravær av behovet for distribuert arbeidsflyt). Og iallfall ikke når svn selges som alternativ.

 

Det er mulig at svn hadde noen fordeler ift sine forgjengere en gang i tiden. Jeg ser ikke helt hvilke fordeler svn skulle hatt i dag, gitt alternativene. Er det noen vertkøy bygget på toppen av svn som gjør opplevelsen bedre og som ikke har en motpart i git/hg-verden?

 

Vi har brukt SVN også til brancher, og jeg syntes ikke det var så plagsomt.

 

Ift. git/hg? svnmerge.py alene burde være "plagsomt nok".

 

Det som er viktig er å lære seg svakhetene og styrkene til verktøyet, og bruke det riktig.

 

Utvilsomt. Hva var styrken til svn igjen, gitt alternativene? (for ordens skyld, med "styrke" mener jeg i dette tilfellet oppgaver som svn gjør bedre enn alternativene -- raskere og krever mindre av brukeren).

[Matsemann]

Å måtte gi skrivetilgang til masterrepo er ikke en fordel.

 

At du greier å legge frem et krav om å gi skrivetilgang til masterrepo som en fordel som svn innehar er helt hinsides fornuft.

Stråmann, aldri det jeg har skrevet... Jeg skrev man kan gi folk tilgang til deler av repo, som en fordel, noe git ikke kan. Det har også sine ulemper at folk må ha tilgang, men at du overser fordelen jeg legger frem og vrir og vender er en fin måte å dra en diskusjon i dass.

[zotbar1234]

Å måtte gi skrivetilgang til masterrepo er ikke en fordel.

Stråmann, aldri det jeg har skrevet...

 

Vel, du skrev spesifikt dette:

 

" ... og gi de tilgang til å pushe/sjekke inn i bare visse deler"

 

som jeg tolket som skrivetilgang.

 

Jeg skrev man kan gi folk tilgang til deler av repo, som en fordel, noe git ikke kan.

 

Skrivetilgang kan begrenses på brukerbasis. Lesetilgang kan ikke det med vilje (jfr ikkekonsistente utsjekk) - jeg ser fremdeles ikke hvor fordelen skulle dukke opp.

 

men at du overser fordelen jeg legger frem (...)

 

Hvilken fordel var dette?