|
|
|
|
|
|
от Сава Чанков(21-04-2005)
След като BitMover Inc. (производителят на BitKeeper - системата за контрол на версии, използвана за разработка на ядрото Linux) прекрати безплатния лиценз, Линус Торвалдс заедно с други разработчици на ядрото се е захванал да разработи собствен инструмент за тази цел.
Корпорацията BitMover Inc. е прекратила безплатния лиценз заради реверсивното инжинерство на нейния продукт от Андрю Триджъл (който в миналото e постигнал доста успехи в тази област). Линус е видимо недоволен от действията на Триджъл, наричайки проекта му "лош".
Разработката на собствена система за контрол на версиите се налага защото съществуващите (включително популярната CVS) се справят доста зле с проект от такава величина. "Десетки секунди за прилагането на кръпка просто не е приемливо време", казва Линус.
По думите на Торвалдс, новата система, наречена не без чувство за хумор git (англ. - мизерник), е " глупав(но много бърз) управител на съдържанието на директории. Не може да прави много, но това, което _прави_, е да управлява съдържанието на директориите ефикасно". Новата версия на ядрото, 2.6.12-rc3, е направена с нейна помощ. Доста новини за напредъка й излизат на kerneltrap.org
<< Утре започва WebTech 2005 - София | Индия спира софтуерните патенти. >>
|
|
|
|
|
Очаквах го От: Пламен Недков На: 21-04-2005@11:04 GMT+2 Оценка: 1/НеутраленАз лично очаквах това да се случи. А всъщност това беше и едно от логичните решения.
[Отговори на този коментар]
Към: Очаквах го От: MiCRoPhoBIC <plamen __@__ tonev__dot__net> На: 21-04-2005@11:48 GMT+2 Оценка: 1/НеутраленАз пък очаквах по-рано да започне да се оглежда за свободен софтуер за целта. А не когато ножа опря до кокала. Ама верно - на него не му дреме за 'свободата'.
Един цитат:
Among the differences: Git can't rename a file; users must instead delete one and recreate it elsewhere with the new name, McVoy said. And it doesn't handle space efficiently; a tiny one-character change to a 1MB file in Git will result in a 2MB file, whereas BitKeeper's file will grow only by one byte.
Страшен tool.
[Отговори на този коментар]
Към: Към: Очаквах го От: Георги Чорбаджийски <georgi__at__unixsol[ точка ]org> На: 22-04-2005@5:29 GMT+2 Оценка: 1/НеутраленЗа неможенето да преименува - това са глупости. Защо слушаш точно McVoy да говори за програмата която му е конкуренция и го заменя. Все едно да слушаш как дявола чете евангелието.
[Отговори на този коментар]
"Реверсивното инженерство" в детейли От: blackbird <kosio __@__ spirov__dot__com> На: 21-04-2005@13:07 GMT+2 Оценка: 1/НеутраленTочно вчера се разбра какво е било "реверсивното инженерство". "Сложен" процес в три стъпки.
Стъпка първа:
$ telnet thunk.org 5000
Стъпка втора:
help
Стъпка трета:
$ echo clone | nc thunk.org 5000 > e2fsprogs.dat
:-)
http://www.groklaw.net/article.php?stor...
Линкът по-горе е една от най-смешните статии, които съм чел...
Редактиран на: 21-04-2005@13:15
[Отговори на този коментар] CVS -> git!!! От: Andrew На: 21-04-2005@14:51 GMT+2 Оценка: 1/НеутраленНе ми стана съвсем ясно защо маса свободен софтуер ползва cvs или cvn, а линус и компания първо избират комерсиална система и когато се оказва, че тя не е точно това което им трябва тръгват да откриват топлата вода???
Ама айде за спорта да вземеме да мигрираме и sf.net към новата система...
[Отговори на този коментар]
Към: CVS -> git!!! От: Георги Чорбаджийски <georgi (a) unixsol< dot >org> На: 21-04-2005@15:58 GMT+2 Оценка: 1/НеутраленЗащото са централизирани и просто не стават.
[Отговори на този коментар]
Към: Към: CVS -> git!!! От: pirx <pirx< at >anons __точка__ bg> На: 21-04-2005@19:33 GMT+2 Оценка: 1/НеутраленGNU Arch? Той не е централизиран, дори напротив.
[Отговори на този коментар] Към: Към: Към: CVS -> git!!! От: Георги Чорбаджийски <georgi__at__unixsol< dot >org> На: 21-04-2005@21:05 GMT+2 Оценка: 1/НеутраленСпоред Линус е бавен. Мисля че човека знае най-добре, все пак той ще работи яко с утилката, така че преди да седне да си пише е пробвал, тествал и е видял че не става. Нито arch, нито monotone, за cvs да не говоря, а пък разработчиците на svn специално отворено писмо написаха към юзърите да не тормозят Линус с предложения да ползва svn, щото не му върши работа :)
btw: вижте http://kerneltrap.com/ там има няколко статии за git, прочетете коментарите и ще разберете защо другите не стават.
Цитирам какво беше написано в един от коментарите (в него добре се обяснява какъв е проблема)
http://kerneltrap.org/node/5014
"Most SCMs are designed to work on the "I'm the boss and I pay your wages, you'll do what I tell you" basis. For the BSDs that works because you have one guy controlling everything and a *s*m*a*l*l* team of developers. So you have ONE master setup, and everybody works in their own little patch of it - management ensuring that you don't get two people working on the same stuff at the same time.
That last sentence is the BIG PROBLEM behind most SCMs. They cannot cope with "several workers, one bit of code". Two workers trying to check out the same bit of code? Most SCMs have conniptions and then fall over in a heap. Then try and use that to manage Linux, where you get hundreds of developers all falling over the same *few* *lines* *of* *code* to fix a bug or whatever, and pretty much any semi-commercial SCM is dead in the water even before it's gone down the slipway!
The reason BK was so good for Linus is that (a) it allowed every developer to have their *own* *master* version, and (b) it allowed every developer to say "I want *these* changes, but *not* *those*, from *that* master tree". So, for example, Andrew Morton maintains the mm testing tree with maybe 30 different enhancements over Linus' main tree. And when Linus decided that feature X was mature enough, he did a "bk get" on *just* *that* *one* *feature*.
CVS, being file based, would have been a pain. And, to make it worse, if several other features had been added to the files Linus wanted, he would have got those features as well.
Basically, BK (and now git) are different from other SCMs because they have distributed masters, not just one HEAD, and they allow selective merging of feature sets between trees, not simply checking in and out individual files."
....и не на последно място са БЪРЗИ.
Още един цитат от тази страница:
All indications are that within a few weeks, git will become a better SCM for the kernel project than any other free SCM is today. Partly that's because it is focused very narrowly (for now) on features and constraints of the kernel. But partly it's because Linus has taken a fresh look at SCM, has come up with some innovative ideas, and is leveraging highly incremental development (and a handful of eager volunteers) to make rapid progress.
git is self-hosting (and has been from very early on), and is already being used for actual kernel work. That's pretty impressive.
Редактиран на: 21-04-2005@21:10
[Отговори на този коментар]
Към: CVS -> git!!! От: Защото ... На: 21-04-2005@19:56 GMT+2 Оценка: 1/НеутраленДве от нещата които BK може а почти никой друг проект не са:
1) Равноправни хранилища на принципа Всеки със Всеки. В BitKeeper *няма* дори идея за централно хранилище. Всички са напълно равноправни.
2) 99% offline режим. Можете да правите абсолютно всичко освен да синхронизирате с други хранилища седейки някъде на плажа далеч от всеки повей за безжична или каквато и дае друга връзка.
3) BK е много силен при смесването на различни версии.
Комбинацията от тези неща пък позволява лесно разпалеляване на процеса с едновременна разработка на много версии и последващо смесване между тях. А това понякога е жизнено важно ... за фирма като нашата например.
Не е тайна, че MySQL BitKeeper от години. Явно ще има сериозни сътресения, но още на знам какви.
[Отговори на този коментар]
|
|
|
|
|
|
|
|