ESR szerint a bzr verziókezelő haldoklik, az Emacs-nek git-re kellene váltania

Címkék

Úgy fest, hogy nem volt jó döntés 2009 végén a GNU Emacs projektnek CVS-ről Bazaar-ra (bzr) váltania. Eric S. Raymond szerint a Bazaar haldoklik és az agonizálása nem vet jó fényt a GNU Emacs-re sem. Ráadásul - Raymond szerint - a Bazaar egyik vezető fejlesztője nemrég leírta, hogy szerinte a verziókezelőjük miért bukott el. Raymond arra bíztatja az Emacs fejlesztőket, hogy olvassák el az írást, aludjanak rá egyet, gondolják át és cselekedjenek.

Raymond szerint a git nyert. Sajnálja, hogy így van, de el kell ismernie. A Mercurial-t preferálná, de az a projekt sincs valami fényes állapotban. Így Raymond elfogadta a git győzelmét és váltott. Az Emacs projektnek is azt javasolja, hogy váltsanak git-re. Raymond elvállalná a migrálási projekt technikai vezetését. A döntést azonban - mint írta - az Emacs projekt vezetőségének kell meghoznia. Richard Stallman azt válaszolta, hogy nem ragaszkodik a bazaar-hez.

A részletek itt olvashatók.

Hozzászólások

Igen, szerintem is haldoklik.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Azt hittem, az emacsben verziókezelő is van. Most nagyot csalódtam... :)

Ezek szerint hamarosan bezár a bazaar.

"A Mercurial-t preferálná, de az a projekt sincs valami fényes állapotban."

Mi a baj a Mercurial project állapotával? Tudja valaki?
--
♙♘♗♖♕♔

Nem, nincs ott. Ne is említsd azt az irtózatot.
(ez volt az egyetlen olyan VCS, aminek használatakor azt kérte a projekt, hogy a fordítási fájlból a fordítók rakják ki az automatán generált helyinformációs sorokat, mert ettől a (valóban) zajtól nagyon megnőne a repó mérete/letöltési ideje. WTF???. Azóta az ő eszük is megjött.)
___
Arany János: Grammatika versben

Pedig egy időben annyira menő volt, hogy sokan nem is értették, Linus miért nem azt választotta.

Úgy látom a honlapja alapján, hogy be is állt a fejlesztése. Érdekesség: http://www.google.com/trends/explore#q=%2Fm%2F05vqwg%2C%20%2Fm%2F08441_… Sajnos a Monotone-t és a Bazaar-t nem tudtam felvenni, mert csak általános keresésként engedte volna.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Az emacs nem haldoklik? :)

"Raymond szerint a git nyert. Sajnálja, hogy így van, de el kell ismernie."

A hírnek ezt a részét valahogy nem értem. Van egy jó verziókezelő. Ezen mit kell sajnálni? Használja, és örüljön, hogy van.

---
Science for fun...

Csak ezért Eclipse-t indítani elég overkill... :)
(Ugyan csak egy jó régi verzióról láttam videót, de az alapján annyira nem nyűgözött le. Pl én szeretem látni konkrétan mit commitolok, miközben írom a commit message-t, nem csak egy fájllistát...)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Git Windows alatt minenhogy hanyas. Kezdve azzal, mikor regen kirakta az msysgit ugyanazt a 2 megas binarist vagy 50x, minden git commandra kulon. Na meg a TortoiseGit is kisse furanak tunt a TortoiseSvn-hez kepest. Kezdve azzal, hogy egy mas Tortoise cuccnal nem lattam olyat, hogy kulso dolog kellett neki azok kozul, amit eddig hasznaltam (svn, cvs, hg, git)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A fenti két dokumentumot elolvasva és a Gitet ismerve kb. ez lenne számomra az egyetlen dolog, ami a Mercurial mellett szólna. A Git Windowsos változata valóban elég furán van összerakva. Viszont azt látom, hogy a körülöttem Gitet használó Windowsos emberek vagy parancssorban dolgoznak, vagy a fejlesztőeszköz Git pluginját használják. Nagyon kevés olyannal találkoztam, hogy valaki direkt ezért külső programot tett volna fel, pl. a TortoiseGitet.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Én pl Git-Extensiont használok win alatt (sőt linux alatt is, pedig mono-val bugos, de még mindig jobb mint bármi más), a telepítő felrakja az msysgitet, de ezzel többet nem kell foglalkozni, és tökéletes.
Évekig használtam ezzel a gitet anélkül, hogy egyetlen parancsot be kellett volna írnom a konzolba.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Na engem anno az Eclipse-s SVN pluginek minős(égtelens)ége leszoktatott az IDE-kben való pluginezésről. 1.7-es SVN óta végképp. Eclipseből soha, Visual Studio alatt talán ha 2 commitot eresztettem meg AnkhSVN-nel. Igaz, VS alatt nem lehet megúszni a plugint, különben csúnya dolgok történhetnek...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Na nekem egy alaposabb refactoring/áthelyezgetés/átnevezgetés során csúnya dolgok szoktak történni.

Akkor meg már jobb, ha az AnkhSVN elintézi helyettem. Igaz, ez az áthelyezgetés dolog főleg 1.6 és régebbi SVN-nél volt gáz, ahol minden könyvtár saját maga tartalmazta a .svn könyvtárat. Újabbnál már kevésbé probléma.

Egyébként mire használod a VS-t? C++ vagy .NET?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

C++. De alapvetoen konzolos arc vagyok, csak debuggolashoz kapcsolom be a Studiot. Persze ez project fuggo, fugg az sln file minosegetol is.

Az athelyezes az valoban szar svn-ben, sajnos azt manualisan csinalom es a history elvesztesevel jarhat. Primitiv, nem?

Remelhetoleg lassankent kiszorul az svn.

Sejtettem, igy viszont teged ez kevesbe ezert erint kevesbe.

Nalam azert a konyvtarstruktura nagyjabol koveti a nevtereket 1-2 nagyon ritka kivetelt leszamitva, ott fontosabb az sln es az svn szinkronban tartasa, amit elvegez az AnkhSVN helyettem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Egyébként a Prezi, UStream, Logmein mit használnak verziókezeléshez?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)