A FreeBSD Subversionre vált

FreeBSD

Befagyott a pokol, a FreeBSD Subversionre vált.

Tizennégy év sok idő, és úgy tűnik ennyi elég is volt a CVS-ből a FreeBSD-s fejlesztőknél. A FreeBSD-ben sok minden épül a CVS-re (commit scriptek, értesítők, webfelület, nem is beszélve a c(v)supról), de úgy tűnik ez nem tántorította el őket attól, hogy valami -remélhetőleg- jobbra váltsanak.

Az első árulkodó jel Peter Wemm FreeBSD-CVS-all listán megjelent commit üzenete volt, amely a CVS changelogban egy "SVN rev 179450 on 2008-05-31 06:03:23Z by peter" sort is tartalmazott.

A második egy új, subversion-freebsd port, amely -a Subversion fejlesztők kérése ellenére- a Subversion hamarosan megjelenő 1.5-ös fejlesztői ágát követi.
A RC változatot addig fogják követni, amíg meg nem jelenik a végleges kiadás. Az új portnál a neon helyett a serf library használatát javasolják.
A subversion-freebsd port tartalmaz pár saját "hacket": a $FreeBSD$ tag kifejtését kliens oldalon, a merge konfliktusok Perforce-szerű megjelenítését, illetve a commit template-eket.

Peter Wemm részletesen is leírja, hogy mik az új repository kezelésének szabályai, ír az elérési módokról ("cvsweb"), és arról is, hogy a subversion repository visszafelé (a CVS-be) exportálásra kerül, azaz a jelenlegi hozzáférési módszerek a jövőben is működőképesek lesznek.
Az időzítéssel kapcsolatban érdekes lehet, hogy a 7-es kiadásokat még CVS-ből, a 8-ast viszont már svn-ből képzeli el kiadni Peter.

A CVS mellett már régóta jelen van a Perforce repository, amelyben azon kísérleti kódokat tartják, amelyek még nem értek meg a CVS-integrációra. Az éles, publikus CVS-ből rendszeresen szinkronizálják a Perforce egy (FreeBSD) vendor ágát, amellyel szemben a fejlesztők frissen tarthatják a kódjukat.
A Perforce egy piaci, pénzbe kerülő SCM, de a kliens része ingyenes, így a FreeBSD fejlesztők eddig is "szabadon" használhatták.

A Subversionra váltás után kérdéses, hogy a Perforce továbbra is megmarad-e "fejlesztői homokozónak", vagy ezt a funkcionalitást is átveszi a nyilvános svn repo.

( pinyo_villany | 2008. 06. 01., v – 12:19 )

miért nem a git mellett döntöttek, több helyen is bevált és nem is kis projecteknél (linux, xorg, (debian is kezd átállni)); bar igaz érdekesen nézne ki, de akkor is ...

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

Nem véletlenül az 1.5-ös svn-nel kezdtek, az már közelebb áll ahhoz, amit a p4-szal csinálnak.
A gittel szemben nyilván több ok is szól (a technikai részét kihagyva):
- túl gyorsan változik még mindig
- talán még mindig áll rá az "összedobtunk valamit, ami nekünk kellett" megállapítás, emiatt nem feltétlenül konzisztens a cucc
- bár nem valószínű, hogy a Linux oldalon váltanának erről, mégiscsak felmerül a karbantartás és az elkötelezettség kérdése

És persze játszhat a licensz is (a CVS is GPL-es legjobb emlékeim szerint, nem mintha ez a múltnál sokat számítana), meg az is, hogy "csakazértsemertlinux", de ezek szerintem kevésbé voltak hangsúlyosak.

"talán még mindig áll rá az "összedobtunk valamit, ami nekünk kellett" megállapítás, emiatt nem feltétlenül konzisztens a cucc"

na igen, ebben lehet valami, mert néha a git is olyan tempóban változik, mint maga a kernel, valami eltűnik, valami megjelenik.

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

A git applypatch és applymbox parancsokat 2007 májusában távolították el, miután a funkcionalitásban jóval többet nyújtó, és az őket leváltó git am már 2005 október óta létezett...

Akkor most nézzük meg azt is, hogy hányszor változott a repository formátuma Subversionnél, és hányszor gitnél.

> túl gyorsan változik még mindig

ez pont a git mellett szolna. mig az svn repo formatuma rendszeresen valtozik, (svn adminoknak ismeros hercehurca major verziovaltasok kozott) addig gitnek egyetlen egyszer valtozott a formatuma, azis visszafele kompatibilis volt es a fejlesztes elso 2heteben volt.

megjegyzes: es meg mindig tamogatjak azt a regi formatumot :)

> talán még mindig áll rá az "összedobtunk valamit, ami nekünk kellett" megállapítás, emiatt nem feltétlenül konzisztens a cucc

konkret peldat tudnal mondani?

belso api valtozasok persze mindig vannak, de ott is egyertelmu mindig a valtozas iranya. bevezetnek egy uj apit adott funkciora, szepen atallnak ra, es mikor mar senki se hasznalja akkor torlik a regit. es ez a belso api. kulso apirol lasd az elobbi bekezdest.

> bár nem valószínű, hogy a Linux oldalon váltanának erről, mégiscsak felmerül a karbantartás és az elkötelezettség kérdése

ez nemileg ellentetben all az elozovel, ha tul gyorsan fejlodik akkor ahhoz ketsegtelenul sok fejleszto kell, tehat nem lehet problema, h keves a fejleszto ;)

de konkretan: svnnek hany fejlesztoje is van? a git git repojaban jelenleg tobb mint 400 fejlesztotol van commit.

A változással arra próbáltam célozni, hogy a subversion kevésbé tűnik mozgó célpontnak, mint a git (igaz, a repo-formátum épp ellene szól :). Ez is egy szempont.

Én is csak azon gondolkoztam, hogy vajon mi lehet az oka ennek a döntésnek, annak ellenére, hogy sokak szerint a git többet tud. Én ezekre jutottam.

Igazából semmit sem találtam a háttérről ("hivatalosan"), sőt, azt leszámítva, hogy igencsak látható jelei vannak az átállásnak (egyre több az svn-ből származó commit), még hivatalos bejelentést sem leltem.
Magyarul egy "valószínűleg" is kellene a cikk címébe.

Az ICC nem nyílt forrású, ráadásul nincs is natív FreeBSD-s változata (ettől függetlenül a linuxossal fordítható volt a kernel és a userspace (egy része) is, a portok közül elég soknál kellett módosítani a rengeteg "gccism" miatt)...

Röviden: fogalmam sincs hogy jutott ez eszedbe. :)

The project goal is to write a C99 compiler while still keeping it small, simple, fast and understandable. PCC is not affiliated with any other project, but the compiler has been imported into the OpenBSD and NetBSD base systems. The project is maintained by me (ragge).

btw 0.9.9-es ( :) ) verzio ota C99 fordito es egyre jobb kodot csinal (legalabbis egyre kissebb assembly-t), valamint portolgatjak mas platformokra

--
“A well placed underscore makes the difference between a s_exchange and a sex_change”
— 8048 Users Manual, Intel 1977.

Does git have keyword expansion?

Not recommended. Keyword expansion causes all sorts of strange problems and isn't really useful anyway, especially within the context of an SCM. Outside git you may perform keyword expansion using a script. The Linux kernel export script does this to set the EXTRA_VERSION variable in the Makefile.

See gitattributes(5) if you really want to do this. If your translation is not reversible (eg SCCS keyword expansion) this may be problematic.

Azaz a git nem tamogatja a keyword expansiont. Gyk: A $Autor$ stringeket ez a mechanizmus csereli $Author: pinyo_villany $ stringre. Kulso eszkozzel tamogatja, persze, de akkor mar egyszeru copy is nem?

( Replaced | 2008. 06. 01., v – 13:44 )

mondjuk akkor mar valthattak volna valami distributed cuccra

--
“A well placed underscore makes the difference between a s_exchange and a sex_change”
— 8048 Users Manual, Intel 1977.

( voroskoi | 2008. 06. 01., v – 14:32 )

CVS-ről SVN-re. Gratulálok. Nem tudom ki találta ki, de Isten éltesse sokáig :)