Организация Apache Software Foundation представила (https://blogs.apache.org/foundation/entry/the_apache_softwar...) релиз системы управления версиями Subversion 1.8.0 (http://subversion.apache.org). Несмотря на развитие децентрализованных систем, Subversion пользуется большой популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. При подготовке нового выпуска основное внимание было уделено адаптации применения Subversion в корпоративной среде, упрощению администрирования и автоматизации выполнения типовых операций.
Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal, GCC, LLVM, Mono, WordPress и Ruby. Тем не менее наблюдается большой отток проектов на Git, в частности c Subversion на Git за последнее время перешли проекты Django, PHP, MediaWiki, Ruby on Rails и nginx. Поддержка Subversion реализована в таких хостингах открытых проектов, как Google Code, CodePlex и SourceForge.Среди ключевых улучшений (http://subversion.apache.org/docs/release-notes/1.8.html):
- Улучшены средства по отслеживанию слияний и выявлению конфликтов в дереве исходных текстов, направленные на упрощение поддержания проектов в которых практикуется частое отделение и слияние веток. В новом выпуске представлены новые возможности по автоматизации слияний на стороне клиента и выявлению конфликтов в процессе операций слияния веток и обновления кода. Кроме того, клиент Subversion теперь рассматривает отслеживание перемещения рабочих копий элементов в качестве первичных операций, что является базисом для более полной общесистемой поддержки перемещения и переименования объектов в будущих выпусках;- Для администраторов представлен унифицированный механизм для управления конфигурацией Subversion на стороне клиента, в том числе для распространения шаблонов игнорирования и автоматического определения свойств. Указанный механизм реализован путем встраивания наследуемых свойств, связанных с конфигурацией, непосредственно в репозиторий;
- Расширены возможности бэкенда с реализацией хранилища FSFS, в котором появилась поддержка кэширования свойств ревизий, упаковки свойств ревизий в файл и обеспечения сохранения только различий (delta-изменений) для свойств и содержимого директорий. В итоге удалось достигнуть повышения производительности и снижения потребления дискового пространства;
- Осуществлён уход от использования HTTP-библиотеки Neon, вместо которой для организации доступа клиента к репозиторию по HTTP задействована более новая библиотека Serf. Serf значительно опережает по скорости работы с репозиторием библиотеку neon (http://www.webdav.org/neon/), за счёт использования таких техник как конвейерная обработка и кэширование запросов;
- Хранилище на базе BerkeleyDB признано устаревшим и больше не будет развиваться. Все усилия по разработке будут связны с усовершенствованием хранилища FSFS. Тем не менее поддержка BerkeleyDB будет сохранена, но кроме исправления ошибок реализация новшеств теперь прекращена.
URL: https://blogs.apache.org/foundation/entry/the_apache_softwar...
Новость: http://www.opennet.ru/opennews/art.shtml?num=37207
svn остается только в больших проектах, которые на подобных vcs сидят уже годы.Правда, так пока и непонятно, как можно в git лочить двоичные файлы для избежания конкуретного изменения.
>непонятно, как можно в git лочить двоичные файлы для избежания конкуретного изменения.Это, наконец-то "вброс" svn-против-git, и мы дождались?
Объясните, что такое это ваше "лочить двоичные файлы для избежания конкуретного изменения" и причём тут VCS? Желательно _не _упониная **CVS**.
Я очень люблю git и пытаюсь заставить перевести на него большой продукт, но действительно не нашел информации в ProGIT и гугле, stackoverflow и т.д. - как можно предоставлять эксклюзивные права на запись только одному человеку, в текущий момент залочившего его.Иными словами, ситуация:
Есть perforce. У perforce есть Exclusive Checkout - т.е. пользователь, который зачекаутил файл - отобрал права на запись у всех других пользователей. Таким образом данный пользователь гарантированно выложит файл в корректном состоянии (после его коммита он будет корректен) и это не повлечет за собой никаких негативных последствий. Как такое сделать в git ? git - распределенная система контроля версий, каждый работает со своим локальным репозиторием, поэтому всякий контроль за данными на главном репозитарии отсутствует. Если я ошибаюсь - я очень этому рад - подскажите мне тогда, как это реализовать. Буду правда очень благодарен.И не надо двачевской чуши на опеннете плз. И с "вбросами" своими идите в думу.
Почему бы этому пользователю просто не работать в своей ветке? Тогда гарантировано его файл никто "не тронет". Если у вас все разработчики трудятся в одной ветке, то проблема синхронизации изменений в файлах явно ваша, а не git'a.
> Почему бы этому пользователю просто не работать в своей ветке? Тогда гарантировано
> его файл никто "не тронет". Если у вас все разработчики трудятся
> в одной ветке, то проблема синхронизации изменений в файлах явно ваша,
> а не git'a.А мержить картинки (или другие бинарники) кто потом будет?
> А мержить картинки (или другие бинарники) кто потом будет?Тот же, кто у вас там _независимо изменённые .EXE "мержит". Какие проблемы-то?
>> А мержить картинки (или другие бинарники) кто потом будет?
> Тот же, кто у вас там _независимо изменённые .EXE "мержит". Какие проблемы-то?Если озаботиться с проставкой лока, то никаких "независимо изменённых" .exe не будет.
> Если озаботиться с проставкой лока, то никаких "независимо изменённых" .exe не будет.Да, вместо этого "whole shebang" будет курить бамбук, когда Вася ввинтит лок и потом возьмет больничный.
> будет курить бамбук, когда Вася ввинтит лок
> и потом возьмет больничный.Нет, просто сопрёт лок. http://chestofbooks.com/computers/revision-control/subversio...
> Нет, просто сопрёт лок.Тогда фигли толку с таких локов?
>> Нет, просто сопрёт лок.
> Тогда фигли толку с таких локов?Толк в том, что это будет сделано сознательно. И все (включая менеджера и человека поставившего лок) будут знать, что он это сделал сознательно.
И если кто-то повадился игнорить локи, что просто получит по щам от манагера.
> У perforce есть Exclusive Checkout - т.е. пользователь, который зачекаутил
> файл - отобрал права на запись у всех других пользователей.Без CVS-а обошёлся. Мастер.
> образом данный пользователь гарантированно выложит файл в корректном состоянии (после
> его коммита он будет корректен) и это не повлечет за собой
> никаких негативных последствий. Как такое сделать в git ? git -
> распределенная система контроля версий, каждый работает со своим локальным репозиторием,
> поэтому всякий контроль за данными на главном репозитарии отсутствует. Если я
> ошибаюсь - я очень этому рад - подскажите мне тогда, как
> это реализовать. Буду правда очень благодарен.Если ты мне объяснишь, как пользователь на машине А, "чекаутящий" файл из своей локальной копии репа, узнает, что пользователь на машине Б уже "зачекаутил" этот файл из _соего локального репа, я расскажу тебе куда им прикрутить те блокировки...
> И не надо двачевской чуши на опеннете плз. И с "вбросами" своими идите в
С вопросами про git пройдите _из _новости про SVN.
>Если ты мне объяснишь, как пользователь на машине А, "чекаутящий" файл из своей локальной копии репа, узнает, что пользователь на машине Б уже "зачекаутил" этот файл из _соего локального репа, я расскажу тебе куда им прикрутить те блокировки...Я про это и говорю - что не вижу ни одного способа (нормального) этого сделать.
P.S. Почему такой хамский тон? Я унизительно оскорбил Вас? Если нет, то это тогда я Вас прошу "пройти" из opennet.ru.
> P.S. Почему такой хамский тон?нормальный тон. не нравится — тебя тут никто не держит.
Ожидался нормальный ответ, а не гопоты. Ну да ладно. Правильно как-то на хабре писали, что раньше программисты помогали друг другу, а сейчас стараются всячески утереть нос.
> Ожидался нормальный ответ, а не гопоты.твои проблемы. никто не обязан соответствовать твоим ожиданиям.
> на хабре писали
ну и зачем вообще после этого с тобой говорить? вот и не буду. не друг ты мне.
Да идите с андрюшей друг-друга ... дружите :)Чел задал нормальный вопрос. Без хамства. Но лыцари с радугой на флагах бдят.
PS: опеннет не лучше хабра. такое же унылое ... и сделали его таким вы.
> Чел задал нормальный вопрос. Без хамства.ему ответили. *очень вежливо* ответили, что спросил он полную глупость. он не понял и полез в бутылку. его право.
> PS: опеннет не лучше хабра. такое же унылое … и сделали его
> таким вы.да, шлюх не завезли. а вот дураков, к сожалению, можем экспортировать.
>> Если ты мне объяснишь, как пользователь на машине А, "чекаутящий" файл из своей локальной копии репа, узнает, что пользователь на машине Б уже "зачекаутил" этот файл из _соего локального репа, я расскажу тебе куда им прикрутить те блокировки...
>
> P.S. Почему такой хамский тон? Я унизительно оскорбил Вас? Если нет, то это тогда я Вас прошу "пройти" из opennet.ru.
> Ожидался нормальный ответ, а не гопоты. Ну да ладно. Правильно как-то на хабре писали, что раньше программисты помогали друг другу, а сейчас стараются всячески утереть нос.Митрофаныч вам поставил совершенно справедливый контрольный вопрос, вопрос на проверку понимания той задачи, которую вы тут раскручиваете.
Вы на этот вопрос ответить не смогли, и начали придираться к форме, пытаясь замять содержание.
И что же это был за контрольный вопрос? Насчет понимания что значит "распределенная"? Так я это уже ответил. Я неправильно понял вопрос? Поясните.
> И что же это был за контрольный вопрос? Насчет понимания что значит "распределенная"? Так я это уже ответил.Вопрос прямо выше в цитате. И в самом исходном сообщении.
А вы сейчас просто пытаетесь отвлекать внимание на рассуждения не относящиеся к теме.> Я неправильно понял вопрос? Поясните.
Неправильное понимание контрольных вопросов также засчитывается, как непонимание задачи (которую вы сами же и раскрутили).
Вы можете ответить на вопрос? Сейчас как раз, отвлекаете внимание Вы. Я переспросил вопрос, попросил уточнить. От вас - никакой полезной информации.
> Я переспросил вопрос, попросил уточнить. От вас - никакой полезной информации.Глупые люди могут извлечь полезную информацию только из готовых разжеванных ответов.
Умные люди могут извлечь полезную информацию еще на стадии формулирования вопроса.Наиболее полезная информация для вас была в вопросе, который вам задали для вашей самопроверки.
Если вы не знаете ответов на вопросы, тогда и не надо решать, какая информация полезная, а какая - нет. А если считаете, что вы можете оценить полезность информации, тогда и ответ вы должны быть в состоянии найти.
>Я унизительно оскорбил Вас?Нет, ты пришёл в тему про svn со _своими проблемами с _git.
Тебя тут не ждали.
>Если нет, то это тогда я Вас прошу "пройти" из opennet.ru.
>>Я унизительно оскорбил Вас?
> Нет, ты пришёл в тему про svn со _своими проблемами с _git.Хочется убивать! Правильно - тонну помоев на него за это! Так победим!
> Хочется убивать! Правильно — тонну помоев на него за это! Так победим!да. может, станет одним дураком меньше.
>> Хочется убивать! Правильно — тонну помоев на него за это! Так победим!
> да. может, станет одним дураком меньше.Ты серьёзно?
>>> Хочется убивать! Правильно — тонну помоев на него за это! Так победим!
>> да. может, станет одним дураком меньше.
> Ты серьёзно?куда уж серьёзней-то. я вообще категорически против популяризации пингвинуса и всяких хороших программерских инструментов, а популяризацию среди дураков и вовсе считаю вредной.
>>>Я унизительно оскорбил Вас?
>> Нет, ты пришёл в тему про svn со _своими проблемами с _git.
> Хочется убивать! Правильно - тонну помоев на него за это! Так победим!Призыв?? Вредоносрый ресурс - в список.
Скажи ещё что флейм не был ожидаемым результатом Поста №1.
Но _тоньче №№42 и 113, за что хвалю.
И что в этой фиче хорошего? Ну залочил пользователь А файл. Остальным что делать прикажете? Курить пока он не разлочит его? А если им тоже надо этот файл поменять, то чем это будет отличаться от ситуации в гите когда кто выкладывает тот и мержит?
> И что в этой фиче хорошего? Ну залочил пользователь А файл.Еще веселее когда кто-то это сделал по ошибке и все отфакапились. На 8 рыл - один топор, да и тот без топорища. Один рубит - а семеро в кулак трубят.
Эффективная разработка у господ с централизацией головного мозга, чо.
> И что в этой фиче хорошего? Ну залочил пользователь А файл. Остальным
> что делать прикажете? Курить пока он не разлочит его?Заняться другой работой. Возможно это будет более полезно, чем мержить потом бинарники.
> А если им тоже надо этот файл поменять, то чем это будет отличаться
> от ситуации в гите когда кто выкладывает тот и мержит?Отличается тем, что будет знать на что идёт.
Workflow - как бе разный. Ну долго ешё будете сравнивать тёплое с мягким?
> Таким образом данный пользователь гарантированно...нагнет работу других пользователей, ха-ха :). А это, мерж зачем придумали по вашему?
итого: человек три новых буквы-то выучил, а модель в мозгу как была централизованая, так и осталась. ну зачем тебе гит, если ты всё равно хочешь сделать из него свн?
Я ничего сделать не хочу. Что здесь за контингент.. Боже.Я всего лишь хочу сказать, что у нас в компании большой продукт, который уже давно на перфорсе работает и все к нему привыкли. Когда вопрос стоял о эксплюзивном локе - я не нашел что ответить про это с git, потому, как не знаю, как это сделать. Я прочитал книгу proGit и до сих пор не знаю, каким образом. Если вы все такие умные и все знаете - хотя бы скажите где об этом можно почитать или узнать это, что вы все свои "ниасилил" и прочую чушь несете? Школьники? Сразу видно уровень интеллекта. Настроены не на помощь, а на унижение товарища.
И напоследок: ну может я и хочу установить себе "модель в мозгу распределенной системы контроля версий" - от твоего комментария мне какая польза? Твой комментарий, - мусор.
> Настроены не на помощь, а на унижение товарища.…
> Твой комментарий, — мусор.не товарищ ты мне.
> Я ничего сделать не хочу. Что здесь за контингент.. Боже.Действительно, что за контингент? Пытается юзать DVCS как жестко централизованную VCS и удивляется что это плохо работает.
Git был сделан чтобы разработчикам было удобно. А вот когда какое-то удилище на каком-то ремотном сервере залочило файл а разработчику позарез надо его поменять - это не только не удобно, это еще и контрпродуктивно зачастую. Особенно прикольно если человек вывесил лок и потом заболел/свалил/... - во потом все бурно радуются, получив рукоятью грабель в лоб.
> ответить про это с git, потому, как не знаю, как это сделать.
А никак, по большому счету. Парадигма работы другая. У каждого есть своя репа. Он там делает что хочет. А другие (те кто вмерживает изменения) вовсе не обязаны потом принять именно что угодно. Так и разработчику удобно и что попало в проект все-таки не коммитится. Но сервак в центре в случае GIT лишь точка обмена траффиком, а не контролер процесса. Потому что указанное поведение - это баг а не фича. Я видел как это выглядит в таких системах: надо файл отредактировать, какой-то пупкин влупил лок и удалился восвояси. Ищи его потом свищи, или проси админов его снять. Абсолютно контр-продуктивное решение при нормальной реализации рабочего процесса.
> хотя бы скажите где об этом можно почитать или узнать это,
Для этого надо просто вправить себе мозг и осознать что git != svn. Совсем. Юзать DVCS в режиме "этакий централизованный VCS" - редкостное извращение. Это как по шоссе на боинге разъезжать, с аргументом что "ну он же может немного кататься по взлетной полосе?!"
> видно уровень интеллекта. Настроены не на помощь, а на унижение товарища.
А что им еще делать, если товарищ демонстративно забивает гвозди микроскопом и обижается на кручение пальцем у виска?
DVCS подразумевают иной набор подходов к разработке. Удобный для разработчиков, прежде всего. Git делали разработчики. Сами себе. Ориентируясь на свои нужды. Чтобы им было удобно. Это так сложно понять?
> И напоследок: ну может я и хочу установить себе "модель в мозгу
> распределенной системы контроля версий" - от твоего комментария мне какая польза?
> Твой комментарий, - мусор.Чтение мануалов вслух - услуга платная.
Я понял абсолютно все, из того что вы сообщили. И, может быть частично, но понимал до этого.И я не пытаюсь использовать раср. VCS как централизованную, в моей компании просто не хотят осваивать новые технологии. А когда встал вопрос "А что нам делать с картинками, например?" в git (и т.д) - я просто не смог ничего ответить.
Да, возможно действительно стоит задуматься над тем, где хранить двоичные файлы.
Просто, не знаю, поддержите ли Вы меня или нет, но мне бы было не очень удобно иметь для этого другой инструмент, хотелось бы, чтобы это все работало сразу (да, каким-то волшебным магическим образом (опять не пинайте, я знаю, что такое распределенная VCS), за напоминания об этом я не плачу деньги :)), возможно. отчасти, потому, что тогда его удастся внедрить к нам. Но, тогда вопрос - нужны ли нам костыли (для лока) и (от лока), т.к. и то и то имеет минусы, но как-то с двоичными файлами работать надо.Можете предложить какой-нибудь вариант? Может уже сталкивались, есть успешный опыт внедрения? Я буду рад помощи. Но только "помощи", а не "ниасиляторы - долой".
Забыл дополнить - не "не хотят осваивать новые технологии", а хотят, но приучить к новой технологии некоторых людей может оказаться гораздо труднее (ввиду ряда причин), чем "незаметно пересесть" на другой инструмент. Это как пересесть с винды на Linux, а в качестве оформления поставить копию виндовой темы. И пользователи не будут особо париться (если, конечно, все условия соблюдены, типа "приложения все работают так же" и т.д.), и платить не надо. Надеюсь, мораль ясна.
> И я не пытаюсь использовать раср. VCS как централизованнуюпытаешься. какой, нафиг, «лок» может быть у DVCS? у неё *нет* «центрального сервера». вообще. все сервера равноправны. а «сервер компании» — это просто такая машина для бэкапов.
именно поэтому я сказал, что надо мозг патчить. и сидеть на svn, если так нужен «центральный сервер». никто же, я так понимаю, палками на git не гонит.
Каюсь, в первом своем посте я написал так, как-будто пытаюсь. На самом деле смысл был в том, что "жаль, что в git нет лока и не может быть, - так бы сразу внедрили неглядя".
Прошу прощения. Наверное, вся полемика из-за него и пошла.
> Наверное, вся полемика из-за него и пошла.хм. да, пост выглядел как «нужен гит, но он кривой!»
> И я не пытаюсь использовать раср. VCS как централизованную,Тогда какие, к черту, локи? Вы кто такое чтобы на моей машине что-то там лочить? Это моя машина. Куда хочу - туда кручу. А вот то что вы не обязаны взять у меня вообще любой крап который я нагенерил - да, не обязаны. Поэтому над своей копией, например, линуксного ядра - я в моем праве извращаться как мне будет угодно. Но это никого не обязывает взять мои изменения и принять их в майнлайн :)
> в моей компании просто не хотят осваивать новые технологии.
А те кто писал гит - даже и не пытались косить под "хороший svn". Они сделали именно DVCS. В котором натурально нет никаких эксклюзивных узлов с особыми правами. Все копии репок натурально равноценны. А где и как происходит синхронизация - вопрос договоренностей между участниками процесса. Это собственно и есть распределенная разработка.
> А когда встал вопрос "А что нам делать с картинками, например?" в git (и т.д) -
> я просто не смог ничего ответить.Ну так тут народ уже придумал эн вариантов. Можно переучить, докостылить, поюзать нечто ориентированное на централизацию или что там еще. Никаким взмахом волшебной палочки гит локам не научится - просто потому что у DVCS логика работы другая. Она не такая как у централизованной VCS. Там действительно нет никаких центральных ауторити которые какие-то правила диктуют. Вот лежит у меня репа с линевым ядром. И я могу отмотать на 20 коммитов назад забыв какой либо сервак спросить. И любой файл отредактировать могу. И закоммитить себе - могу. И потом работать с моими локальными изменениями мотаясь по версиям могу. Вообще без каких-то левых серваков где-то там. Другое дело что для того чтобы эти изменения появились где-то еще, кто-то у меня их должен взять. Как именно это организовано - очень зависит от. Well known сервак на котром некто что-то мержит - лишь 1 из опций, ничем таким не особенная. Из кучи других.
> Да, возможно действительно стоит задуматься над тем, где хранить двоичные файлы.
Стоит задумываться о свойствах применяемого инструмента и его логике работы.
> Просто, не знаю, поддержите ли Вы меня или нет, но мне бы
> было не очень удобно иметь для этого другой инструмент,По крайней мере проекты которые хостят в гите картинки с графикой я видел, но - разумные объемы. И оно там разрабатывается разумными людьми. Которые доводят до разумного состояния картинки у себя локально, в каком-нибудь trello "всей толпой", или там где еще, и только потом уже оно в git отправляется. Так что хранятся только реально разные картинки без особого флуда изменениями на каждый пшик.
> хотелось бы, чтобы это все работало сразу (да, каким-то волшебным магическим
> образом (опять не пинайте, я знаю, что такое распределенная VCS),Увы, чудес не бывает. Есть инструменты. Есть их свойства. Не учитывать их - не получится.
> Можете предложить какой-нибудь вариант?
Народ уже несколько вариантов придумал вроде. Что я могу еще придумать? Сказать что чудес не бывает? :)
Да не переживайте вы так. Гит по многим параметрам говно хуже свн-а. Интерфейс у него плохой, разобраться сложно (при, вообщем то простоте, идеи распределенности). Интерфейс меняется постоянно поэтому от версии к версии, даже дефолтные параметры. Хранить права на файлы не умеет. И т.д. и т.п.В плане локов на файл это конечно у вас что-то, что не в системе контроля версий должно решаться. Может быть правами на файл в основном репозитории? Или хуками на коммиты...
Спасибо за адекватный ответ.
Да, я уже задумался о том, что git вообще-то создавался немного для других целей...
Хуки на коммиты, может и помогли, но:
во-первых, это костыль;
во-вторых, лучше использовать git по назначению (для хранений не-двоичных данных), а для двоичных данных придумать что-нибудь другое.Я пришел к такому выводу, по крайней мере. Другое дело, что не придумал пока, что конкретно делать с двоичными файлами.
> во-вторых, лучше использовать git по назначению (для хранений не-двоичных данных), а для
> двоичных данных придумать что-нибудь другое.Де не, без проблем: пусть этот ваш Адобе запилит для jpeg-ов diff и merge -- и прямая дорога в git! </неужели закончили>
> а для двоичных данных придумать что-нибудь другое.
> Я пришел к такому выводу, по крайней мере. Другое дело, что не
> придумал пока, что конкретно делать с двоичными файлами.Не думаю, что хранение двоичных данных(не являющихся производными од других данных) вне репозитория чем-то поможет. Всё то-же отсутствие мержа и диффа. Самописные локи в лучшем случае. Зато геморроя прибавится. Особенно, если(когда) специалист писавший скрипты свалит в отпуск/больничку/к конкурентам.
А вот результат компиляции вполне может(должен) жить где-то снаружи. Но тоже не всегда получается с приемлемыми затратами....
Можно сделать отдельный репозитарий для двоичных файлов. Соответственно проблема с правами решится. Только придется пересмотреть процесс сборки/настройки проекта.
> Хранить права на файлы не умеет.орли? а почему у меня умеет? я волшебник?
Вы поставили внешний костыль.
Никакие внешные костыли не нужны. Unix permissions сохраняются/восстанавливаются из коробки.
> Никакие внешные костыли не нужны. Unix permissions сохраняются/восстанавливаются из коробки.я тут просто не совсем понял: он так тонко поесть пытался и мы ему испортили трапезу, или действительно…
> Вы поставили внешний костыль.ага. файловую систему.
Опишу ситуацию. Человек залочил ещё в VSS файл, чтобы вот так вот "корректно его изменить". Не доделал, пошёл домой, сломал ногу, увезли в больницу. Файл остался лоченный. Пароля к компу нет, админ в отпуске, выпускать релиз надо. Глаза у всех красные. В общем, локи файлов для системы хранения версий - это бред полный. Не надо так делать.
Да, я согласен.
Но как быть с двоичными файлами? Картинками? и т.д.
> Да, я согласен.
> Но как быть с двоичными файлами? Картинками? и т.д.может, не хранить их в системе, которая предназначена для текстовой информации? всё равно же ни diff, ни merge с ними не получится.
>> Да, я согласен.
>> Но как быть с двоичными файлами? Картинками? и т.д.
> может, не хранить их в системе, которая предназначена для текстовой информации? всё
> равно же ни diff, ни merge с ними не получится.Есть и другие функции у VCS.
* revert. возможность откатить неверные изменения.
* возможность взять версию продукта за любое время
* лог изменений
* синхронное обновление кода и (например)картинок для веб сайта
* diff смотреть всё-таки можно.
* при наличии связи с багтрекером можно оформить баг на картинку.
всё это отлично оформляется несложными скриптами. которые картинки хранят отдельно, тексты — отдельно. автомобильная аналогия в студии: от того, что у «форда» колёса примерно той же формы, что и у карьерного самосвала, «форд» не становится заменой самосвалу. и наоборот. а вот вместе их использовать вполне можно: на одном замов возить, а на другом грузы.
Это уже "несложные скрипты", а не git, к сожалению. Я же спрашиваю, как это сделать средствами именно git. И, ввиду ее архитектуры, не вижу ни одного способа.
> Это уже «несложные скрипты», а не git, к сожалению. Я же спрашиваю,
> как это сделать средствами именно git. И, ввиду ее архитектуры, не
> вижу ни одного способа.ну да. «как есть суп молотком? ну что вы мне ложку суёте, я же сказал — мне молотком надо! фигня неудобная ваш молоток, даже пожрать толком не получается!»
Вы предлагаете только из-за того, что нельзя работать с двоичными данными в git не работать с git? Тогда к чему все ваши предыдущие комментарии? :)
> Вы предлагаете только из-за того, что нельзя работать с двоичными данными в
> git не работать с git?скажи, ты в детстве головой ударился и потому такой дурак, или это возрастное?
>> Вы предлагаете только из-за того, что нельзя работать с двоичными данными в git не работать с git?
> скажи, ты в детстве головой ударился и потому такой дурак, или это возрастное?А на вопрос ответить? :) Что фетишь в опасносте?
> А на вопрос ответить?зачем отвечать на идиотский вопрос, который задал идиот?
> всё это отлично оформляется несложными скриптами. которые картинки хранят отдельно, тексты
> — отдельно.VCS для исходников и самопальная VCS (которую мы не будем называть VCS) для картинок
> автомобильная аналогия
аналогии идут лесом.
>> всё это отлично оформляется несложными скриптами. которые картинки хранят отдельно, тексты
>> — отдельно.
> VCS для исходников и самопальная VCS (которую мы не будем называть VCS)
> для картиноки в чём проблема? в том, что один раз сделать и использовать — это надо мозг иметь, потому лучше безмозгло мучиться с неподходящим инструментом? хозяин — барин.
>> автомобильная аналогия
> аналогии идут лесом.а без аналогий-то вообще никак не доходит.
>> VCS для исходников и самопальная VCS (которую мы не будем называть VCS)
>> для картинок
> и в чём проблема? в том, что один раз сделать и использовать
> — это надо мозг иметь, потому лучше безмозгло мучиться с неподходящим
> инструментом? хозяин — барин.Не надо мучится с неподходящим инструменнnом. Возьми svn
>>> автомобильная аналогия
>> аналогии идут лесом.
> а без аналогий-то вообще никак не доходит.Может проблема с аргументацией? Как-то странно, что вокруг все тупые. Такая мысль не посещала?
> Не надо мучится с неподходящим инструменнnом. Возьми svnкоторый ещё менее подходящий. круто.
> Может проблема с аргументацией? Как-то странно, что вокруг все тупые. Такая мысль
> не посещала?не странно: большинство людей думать и не умеет, и не хочет. странно было бы, если бы большинство умело и хотело. это был бы идеальный мир вообще.
>> Не надо мучится с неподходящим инструменнnом. Возьми svn
> который ещё менее подходящий. круто.Просто научись им пользоваться.
>> Может проблема с аргументацией? Как-то странно, что вокруг все тупые. Такая мысль
>> не посещала?
> не странно: большинство людей думать и не умеет, и не хочет. странно
> было бы, если бы большинство умело и хотело. это был бы
> идеальный мир вообще.С таким уровнем аргументации неудивительно видеть всех остальных идиотами.
>>> Не надо мучится с неподходящим инструменнnом. Возьми svn
>> который ещё менее подходящий. круто.
> Просто научись им пользоваться.да без проблем. как оно без интернетов работает? мне дифф нужен с одной из старых ревизий. а? опаньки.
а bisect оно умеет? как так «бери перл-скрипт»? это же уже *дополнительный скрипт, а не svn*!
и так далее.
> С таким уровнем аргументации неудивительно видеть всех остальных идиотами.
ну да, я изначально рассчитываю на умных людей. а потом приходят идиоты и сетуют на то, что аргументация непонятна. ну так на идиотов и не рассчитывалось, идиотам — аналогии.
> да без проблем. как оно без интернетов работает? мне дифф нужен с
> одной из старых ревизий. а? опаньки.Разумеется работает, если репозиторий расположен в корп. сети. Не надо натягивать ваш жалкий опыт на всех.
> а bisect оно умеет? как так «бери перл-скрипт»? это же уже *дополнительный
> скрипт, а не svn*!Бисект не всем нужен. У меня peristine данные пол гига. Искать нужную ревизию перебором - можно застрелиться.
> и так далее.
Нужно читать "больше не знаю"?
>> С таким уровнем аргументации неудивительно видеть всех остальных идиотами.
> ну да, я изначально рассчитываю на умных людей. а потом приходят идиоты
> и сетуют на то, что аргументация непонятна. ну так на идиотов
> и не рассчитывалось, идиотам — аналогии.Ну-ну.
>> да без проблем. как оно без интернетов работает? мне дифф нужен с
>> одной из старых ревизий. а? опаньки.
> Разумеется работает, если репозиторий расположен в корп. сети. Не надо натягивать ваш
> жалкий опыт на всех.вот именно: не надо натягивать свой опыт на всех. 21-й век, зачем мне ходить на работу, если я с таким же успехом могу всё делать дома?
>> а bisect оно умеет? как так «бери перл-скрипт»? это же уже *дополнительный
>> скрипт, а не svn*!
> Бисект не всем нужен. У меня peristine данные пол гига. Искать нужную
> ревизию перебором — можно застрелиться.здорово. «мне не нужен — значит, бесполезен».
>> и так далее.
> Нужно читать «больше не знаю»?нужно читать «бисера жаль».
> вот именно: не надо натягивать свой опыт на всех. 21-й век, зачем
> мне ходить на работу, если я с таким же успехом могу
> всё делать дома?Ещё раз. Не нужно обобщать. Вам нужен оффлайн доступ, многим не нужен.
>> Бисект не всем нужен.
> здорово. «мне не нужен — значит, бесполезен».Вы читать умеете? Я млять оставил в своей цитате главное. НЕ ВСЕМ.
>>> и так далее.
>> Нужно читать «больше не знаю»?
> нужно читать «бисера жаль».Что, мало бисера? Верю.
> Ещё раз. Не нужно обобщать. Вам нужен оффлайн доступ, многим не нужен.кажется, это ты мне предложил «научиться работать с инструментом». я тебе сказал, что мне нужно от инструмента. инструмент этого не умеет. внимание, сейчас будет очень сложный вопрос: как обучение поможет мне получить фичи, которых у инструмента просто нет?
>> Ещё раз. Не нужно обобщать. Вам нужен оффлайн доступ, многим не нужен.
> кажется, это ты мне предложил «научиться работать с инструментом». я тебе сказал,
> что мне нужно от инструмента. инструмент этого не умеет. внимание, сейчас
> будет очень сложный вопрос: как обучение поможет мне получить фичи, которых
> у инструмента просто нет?Для особо тугих поясняю. НЕ ВСЕМ нужно то, что нужно тебе. Поэтому принципиальная невозможность использования svn это только твоя, ничем не обоснованная, точка зрения. Если ты не видишь, как им могут пользоваться другие - подучись работе с этим тулом не только в своём мирке.
Ну или, что проще, не болтай ерундой.
специально для тебя повторю вопрос: «как обучение поможет мне получить фичи, которых у инструмента просто нет?»это ТЫ мне предложил «научиться с ним работать». изволь ответить, будь столь любезен.
для особо тугих: ты предложил МНЕ. поэтому меня волнует то, что надо МНЕ. а теперь вернись к первой строке и ответь на вопрос, пожалуйста.
> ты предложил МНЕ. поэтому меня волнует то, что надо
> МНЕ. а теперь вернись к первой строке и ответь на вопрос,
> пожалуйста.Давай я тебе просто верну комент про бисер?
> Давай я тебе просто верну комент про бисер?ты сам загнал себя в тупик, поэтому можешь прекращать изворачиваться.
>> Давай я тебе просто верну комент про бисер?
> ты сам загнал себя в тупик, поэтому можешь прекращать изворачиваться.Ага. Так вот как понимать твои каменты про бисер, гугль и нищебродов.
> Ага. Так вот как понимать твои каменты про бисер, гугль и нищебродов.так и понимать. люблю, знаешь, над дураками поиздеваться. ты вот — годный объект был.
>> Ага. Так вот как понимать твои каменты про бисер, гугль и нищебродов.
> так и понимать. люблю, знаешь, над дураками поиздеваться. ты вот — годный
> объект был.Опять дартаньяна включил...
>> Разумеется работает, если репозиторий расположен в корп. сети. Не надо натягивать ваш жалкий опыт на всех.
> вот именно: не надо натягивать свой опыт на всех. 21-й век, зачем
> мне ходить на работу, если я с таким же успехом могу всё делать дома?Ну дык на твой виндус ваш админ же поставил кнопочку с загадочными буквами VPN. Ну вот тыркни ея как обычно, и "репозиторий расположен в корп. сети" ВНЕЗАПНО! станет доступен из дому. Эти админы - просто шаманы да ангра? :) Давай тащи пиво и не трогай кнопочки.
скажи мне, дебил, как он будет доступен, если интернетов нет?
Я бы с радостью, но нужно как-то регулировать их изменения.
Вот допустим имеется lib.dll.
Я у себя на локальном клонированном репе изменил файл, закоммитил. Начинаю пушить - а за то время, пока я у себя менял файл, коммитил и перед пушем - кто-то другой уже обновил этот файл - в результате я его данные затру своими.
> Я бы с радостью, но нужно как-то регулировать их изменения.
> Вот допустим имеется lib.dll.
> Я у себя на локальном клонированном репе изменил файл, закоммитил. Начинаю пушить
> — а за то время, пока я у себя менял файл,
> коммитил и перед пушем — кто-то другой уже обновил этот файл
> — в результате я его данные затру своими.с какого испугу? push просто не пройдёт, гит предложит сначала смержиться с сервером. конечно, если ты любишь экстрим, можно сказать push --force — но тогда ты сам себе вивисектор.
Это хорошо, но тогда может возникнуть такая ситуация:Я вижу, что git не дает запушить, говорит, что надо смержиться/отрезолвиться и т.д.
Ок. Я беру последнюю версию библиотеки lib.dll, опять ее у себя заменяю и снова делаю push. За это время (за второй раз) опять кто-то изменил lib.dll и мне нужно снова взять новую и у себя ее заменить и затем снова запушить. И так может быть 100500 раз. Как от этого избавиться? Вы поняли, к чему я вообще клоню?
> Как от этого избавиться?прекратить заниматься онанизмом и наладить, наконец, рабочий процесс.
Например?
> Например?например, не совать говно в репозитории.
> Например?Например, разбить проект по модулям, заодно уменьшив размер команд до разумных значений (уже 10 человек в одной команде - очень неэффективно), чтобы отдельные команды работали над отдельными модулями, а не сразу тысяча человек ломилась в единый репозиторий.
есть мнение, что пояснять бессмысленно: если этого ещё не сделано, то никто делать и не будет. «это было хорошо для наших дедов, хорошо оно и для нас!» и «нечего тут умничать, и без того всё работает!»
Научиться, наконец, компилить dll-ки и перестать хранить их в репоззитории.
> Научиться, наконец, компилить dll-ки и перестать хранить их в репоззитории.:) Есть ещё яйца в яичницах!
А при чём здесь git или svn?
а в чем принципиальная проблема с двоичными файлами? для картинок ставится дифовалка картинок. а для того, для чего дифф не актуален используется git checkout --ours / git checkout --theirs.
это всё от того, что неумение нормально организовать работу пытаются «прикрыть» какими-то программными костылями. у одних вон какие-то конфиденциальные файлы в общем репозитории валяются, у других жизнь не жизнь, если что-то не залочить…
Да мне на надо прямо лочить, мне не важно, какими средствами будет реализована безопасная работа с двоичными файлами. Мне нужно:
а) чтобы это работало из git (без скриптов и прочей лабуды, т.к. здесь разговор ведется о git)
б) чтобы это было, повторюсь, безопасно.
define безопасно
Отписал выше.
> Отписал выше.так вот: тебе не «безопасность» нужна, а программный костыль для решения хреново налаженого рабочего процесса. у тебя хреновая музыка, и её не починишь сменой инструментов — музыкантов менять надо.
> Да мне на надо прямо лочить, мне не важно, какими средствами будет
> реализована безопасная работа с двоичными файлами. Мне нужно:
> а) чтобы это работало из git (без скриптов и прочей лабуды, т.к.
> здесь разговор ведется о git)
> б) чтобы это было, повторюсь, безопасно.ну и сделай один репозитарий публичный а другой для релизов. на первый у всех права на второй только у тебя куда ты пушиш картинки
> ну и сделай один репозитарий публичный а другой для релизов. на первый
> у всех права на второй только у тебя куда ты пушиш
> картинкис гитом — достаточно бранчей и gitolite, например. но я совершенно не уверен, что у них есть «ответственный за релиз».
p.s. запятые где? знак мягкий где? фуфуфуфу!
> Опишу ситуацию. Человек залочил ещё в VSS файл, чтобы вот так вот
> "корректно его изменить". Не доделал, пошёл домой, сломал ногу, увезли в
> больницу. Файл остался лоченный. Пароля к компу нет, админ в отпуске,
> выпускать релиз надо. Глаза у всех красные. В общем, локи файлов
> для системы хранения версий - это бред полный. Не надо так
> делать.Это он неумения.
1. В VSS-е можно выставить multiplie checkout, и тогда лок будет просто предупреждением.
2. Сломать пароль в VSS не сможет только ленивый.Локи иногда полезны, хотя я например никогда ими в SVN не пользовался
На лицо полное непонимание принципов работы VCS в общем. Бинарный файл заменяется целиком, поэтому после любого коммита он остаётся в консистентном состоянии. Проблемы, которую вы предполагаете, вообще не существует.
> Есть perforce. У perforce есть Exclusive Checkout - т.е. пользователь, который зачекаутил файл - отобрал права на запись у всех других пользователей. Таким образом данный пользователь гарантированно выложит файл в корректном состоянии (после его коммита он будет корректен) и это не повлечет за собой никаких негативных последствий.Вы где-то в 1994-ом застряли?
На некорректно поставленный вопрос довольно проблематично дать корректный ответ.
В perforce есть lock. Основное его назначение было --- не раздражать мозг менеджеров при переходе с SourceSafe или SCCS.
К "гарантированно выложит файл в корректном состоянии" lock на файл не имеет никакого отношения (я полагаю, в любой хоть сколько-нибудь вменяемой VCS с клиент-серверным подходом).
> Мы выбрали SVN в виду отсутствия некоторых фич в git. В частности
> невозможность отобрать права на read на некоторые директории в проекте.А зачем тогда вообще давать доступ к репозиторию?
Проект-то соберётся? Если да, то подпроекты разумно поместить в независимые репозитории.
> А зачем тогда вообще давать доступ к репозиторию?Что бы была история и прочие радости. И что бы она осталась с нами.
> Проект-то соберётся? Если да, то подпроекты разумно поместить в независимые репозитории.
Некоторые не соберутся. Например перевод ресурсных файлов. Некоторые соберутся в урезаном варианте(без подписи).
Выделить как отдельные проекты было бы неплохо. Но времени нет. Моего личного, неоплачиваемого времени.
>> А зачем тогда вообще давать доступ к репозиторию?
> Что бы была история и прочие радости. И что бы она осталась
> с нами.
>> Проект-то соберётся? Если да, то подпроекты разумно поместить в независимые репозитории.
> Некоторые не соберутся. Например перевод ресурсных файлов. Некоторые соберутся в урезаном
> варианте(без подписи).
> Выделить как отдельные проекты было бы неплохо. Но времени нет. Моего личного,
> неоплачиваемого времени.Ну, то есть яма, и яма эта углубляется. Удачи :-)
> Ну, то есть яма, и яма эта углубляется. Удачи :-)Яма - да. Ситуация улучшается. угудать 50% тоже не плохо.
Можете мне поставить хоть тысячу минусов, но ПРАВДА дороже. Имею исключительно отрицательный опыт работы с svn, хотя работал с этой системой очень долго. Некоторые уникальные возможности svn исходят из архаичности и убожества svn, сама модель svn устарела морально.Да, сейчас я на Mercurial и 99% возможностей svn он умеет и при этом без характерных минусов. Умеет и ограничение прав доступа на папки на стороне сервера и многое другое, и внешние репозитории svn и git.
Примите соболезнования все те кто так и не смог в силу обстоятельств перейти на нормальные git и hg.
SVN по прежнему впереди всех за счет повсеместной и качественной поддержки (OS, IDE, collaboration tools) и экстремальной простоты использования. А назвать git "нормальным" может только тот, кто привык работать бубном и книгой заклинаний.
> А назвать git «нормальным»
> может только тот, кто привык работать бубном и книгой заклинаний.ты ошибся, это ты про svn написал.
http://git-animals.tumblr.com/
> http://git-animals.tumblr.com/Смешные картинки из интернета - это, конечно, серьезный аргумент.
Открой для себя http://tortoisehg.bitbucket.org - да, это для Mercurial и это GUI работает на всех ОС и очень удобное. Поэтому я им и пользуюсь, потому что и самому приятно и коллегам не стыдно предложить.
не люблю Tortoise, попробуй http://javaforge.com/project/HGE
> работает на всех ОС и очень удобное.А вот тут знакомый разработчик матом крыл. И вообще - "а какого этот битбакет свататает какую-то мышевозильную хрень, к тому же кривую и неудобную?!"
Да, если что - для разработчика совершенно нормально уметь эффективно пользоваться командлайном для повышения эффективности своей работы. А эта дребедень с кнопками нужна только глупым секретуткам. Которые вообще не понятно что делают в VCS.
> Да, если что - для разработчика совершенно нормально уметь эффективно пользоваться
> командлайном для повышения эффективности своей работы. А эта дребедень с кнопками
> нужна только глупым секретуткам. Которые вообще не понятно что делают в
> VCS.тем не менее, в git gui, например, очень удобно коммитить только выбраные строки. из консоли тоже можно, конечно, но не так удобно.
>> работает на всех ОС и очень удобное.
> А вот тут знакомый разработчик матом крыл. И вообще - "а какого
> этот битбакет свататает какую-то мышевозильную хрень, к тому же кривую и
> неудобную?!"
> Да, если что - для разработчика совершенно нормально уметь эффективно пользоваться
> командлайном для повышения эффективности своей работы. А эта дребедень с кнопками
> нужна только глупым секретуткам. Которые вообще не понятно что делают в
> VCS.вы, похоже, путаете разработчика с рядовым кодером
Mercurial и из консоли удобен, а GUI TortoiseHg 2.8 выше всяческих похвал по функциям и возможностям. Ни одна GUI для git под Linux не стоит даже отдаленно с TortoiseHg - я все возможные GUI для git перепробовал и знаю о чем говорю, но это лишь мое мнение.
> Mercurial и из консоли удобен, а GUI TortoiseHg 2.8 выше всяческих похвал
> по функциям и возможностям. Ни одна GUI для git под Linux
> не стоит даже отдаленно с TortoiseHg - я все возможные GUI
> для git перепробовал и знаю о чем говорю, но это лишь
> мое мнение.gui для git - это оксюморон, этого горбатого cli-only только могила исправит
> gui для git — это оксюморон, этого горбатого cli-only только могила исправитда, git — неплохой детектор мышек в черепе.
а я знаю отличный инструмент для работы с git: командная строка оболочки. и в очень редких случаях, когда надо закоммитить не полностью файл, а только несколько патчей из него — git gui.
git add -p file с этим отлично справляется - очень удобно кстати
> git add -p file с этим отлично справляется - очень удобно кстатисовершенно неудобно. git gui для того же самого намного удобней.
Есть еще SourceTree от Atlassian, для начала сойдет.
Пытался посунуть его продвинутому пользователю офтопа (нужно для совместной работы). не взлетело. Нужно еще проще. Осталась последняя надежда github client
> IDE, collaboration tools) и экстремальной простоты использования.Особенно просто когда надо отмотать на пару версий назад. Там так просто отматывается что полсерванта перекачивается заново. Каждый раз. На каждый пук.
Да, это эталонно простая и удобная работа с ревизиями, спору нет. Хотя, конечно, может быть вам VCS надо для сервировки файлов, хранения блобов на 100500 мегабайтов или там что еще. А работа с версиями - да хрен с ней, собственно :)
>> IDE, collaboration tools) и экстремальной простоты использования.
> Особенно просто когда надо отмотать на пару версий назад. Там так просто
> отматывается что полсерванта перекачивается заново. Каждый раз. На каждый пук.если цель работы с версиями - отматываться с частотой 50 герц, то git - наше все, ага
> если цель работы с версиями — отматываться с частотой 50 герц, то
> git — наше все, агацель — иметь быстрый и удобный инструмент. а если «просто хранить историю», то обычный скрипт, инкрементально бэкапящий весь каталог проекта, справится ничуть не хуже.
> цель — иметь быстрый и удобный инструмент.а крестиком вышивать?
> а если «просто хранить историю»,
> то обычный скрипт, инкрементально бэкапящий весь каталог проекта, справится ничуть не
> хуже.у вас блестящее будущее, дерзайте, мой друг!
> у вас блестящее будущее, дерзайте, мой друг!благодарю за разрешение.
> Умеет и ограничение прав доступа на папки на стороне сервера и многое другоеТак ты в конце концов поделишься знанием, или так и будешь вещать?
>> Умеет и ограничение прав доступа на папки на стороне сервера и многое другое
> Так ты в конце концов поделишься знанием, или так и будешь вещать?зачем тебе знание об hg, если ты спрашивал про git? O_O
>>> Умеет и ограничение прав доступа на папки на стороне сервера и многое другое
>> Так ты в конце концов поделишься знанием, или так и будешь вещать?
> зачем тебе знание об hg, если ты спрашивал про git? O_OМне нужны любые знания.
> Мне нужны любые знания.любой каприз за ваши деньги. только учти: поиск в гугле у меня стоит ОЧЕНЬ дорого. а чтение вслух найденого ещё дороже.
>> Мне нужны любые знания.
> любой каприз за ваши деньги. только учти: поиск в гугле у меня
> стоит ОЧЕНЬ дорого. а чтение вслух найденого ещё дороже.Я уже понял, что твои знания заканчиваются на уровне "DCVS всегда лучше CVS"
> DCVS
> CVSа что это такое? O_O
>> DCVS
>> CVS
> а что это такое? O_OНе заморачивайся.
> Не заморачивайся.и не начинал. я забавляюсь, а не «заморачиваюсь».
> а что это такое? O_OНу может он написал распределенный вариант CVS? Но маловероятно... :D
Или он настолько амеба что не понимает что VCS != CVS :)
ну да, какая разница — что «concurrent versions system», что «version control system»… тем не менее, возмущается, что его с ложки не кормят.
> ну да, какая разница — что «concurrent versions system», что «version
> control system»… тем не менее, возмущается, что его с ложки не
> кормят.нечего ответить - придирайся к опечаткам
> нечего ответить — придирайся к опечаткамбезграмотен — говори, что нечего ответить, поэтому придрались к опечаткам.
buzzword-гуру - ничего не слушай, всех учи
> buzzword-гуру — ничего не слушай, всех учиэто ты представиться пытаешься? не трудись, и так поняли.
>> а что это такое? O_O
> Ну может он написал распределенный вариант CVS? Но маловероятно... :D
> Или он настолько амеба что не понимает что VCS != CVS :)Буквы попутал. Ясное дело имеется в виду DVCS и VCS
УГ-то УГ, но когда проект громадный и с длинной историей, тащить её целиком тоже не круто.Всем гит хорош, но вот если бы ещё какой-то режим, в котором бы объекты тянулись по требованию с сервера - цены бы не было ))
А права доступа, которые так любят компании... Хрен знает, чего с ними делать))
> УГ-то УГ, но когда проект громадный и с длинной историей, тащить её
> целиком тоже не круто.не тащи. --depth=1
разрабатывать толком не сможешь, но тебе оно и не для этого. потому как если ты серьёзно работать над проектом собираешься, то один раз клонировать репозиторий несложно.> Всем гит хорош, но вот если бы ещё какой-то режим, в котором
> бы объекты тянулись по требованию с сервера — цены бы не
> было ))тут как раз вот новость о такой системе контроля версий. svn называется.
> А права доступа, которые так любят компании… Хрен знает, чего с ними
> делать))использовать. можно самому скрипты сделать, а можно, например, gitolite взять.
--depth=1 использую, но он глючит, даже если не коммитить. И кстати тянет не 1 последнюю версию, а 2 )svn - не такая система. Я имею ввиду, чтобы объекты тянулись с сервера и локально кэшировались. Представь это как гит с неполной БД объектов.
Лог это конечно очень круто, но то, что происходило 3 года назад, нужно далекооооо не всегда. А место занимает.
> А место занимает.база размером в гиг — это что-то наподобие linux. и даже при этом гиг — не то, чтобы немного, а вообще незаметно. ну право, во времена терабайтных винтов «много занимает» — это как минимум сотни гигабайт. если найдёшь такой проект — покажи, мне интересно. :3
а какие глюки-то c depth? не замечал. ну, кроме того, что да — две ревизии притащило. никогда внимания не обращал, честно говоря.
> УГ-то УГ, но когда проект громадный и с длинной историей, тащить её
> целиком тоже не круто.Какая разница какая история? Тащить её надо один раз. Не круто - ждать полчаса log или annotate, которому надо лазить по сети.
> А права доступа, которые так любят компании... Хрен знает, чего с ними
> делать))Элементарно решаются хуками, как и везде.
Кстати да, svn еще примечателен МЕДЛЕННЫМ клонированием и еще какие-то замуты с историей, помню медленно было с сервера получать.А самое главное - svn не работает без централизованного сервера. Уже только один этот пункт это ведро гвоздей в гроб svn-а.
Mercurial и git наголову выше svn.
> А самое главное - svn не работает без централизованного сервера.Частично работает.
Нет, никак не работает. Более того, даже сделав рядом регулярно обновляемый svn-mirror, настроить репозиторий так чтобы коммитить в апстрим а обновлять с зеркала, невозможно.
> Нет, никак не работает. Более того, даже сделав рядом регулярно обновляемый svn-mirror,
> настроить репозиторий так чтобы коммитить в апстрим а обновлять с зеркала,
> невозможно.Частично работает. Без всяких мирроров и прочей требехи.
svn add
svn changelist
svn cleanup
svn help
svn info
svn revert
svn resolve
svn resolvedдля локальных файлов
svn diff
svn cp
svn rm
svn mv
svn export
svn mkdir
svn patch
svn pd
svn pe
svn pg
svn pl
svn statusВсем этим, сюрприз-сюрприз, ты можешь пользоваться оффлайн.
Никак не работает. Из перечисленного набора функций нельзя собрать VCS.svn help особенно повеселило.
> Никак не работает. Из перечисленного набора функций нельзя собрать VCS.В таком случае гит тоже не работает оффлайн.
xxxx@mobile ~ % git clone git://my-super-repository
Cloning into 'my-super-repository'...
fatal: unable to connect to :
: Name or service not known
> поэтому для больших проектов - git, а для небольших рабочих коллективов - hg.А для небольших проектов с большим рабочим коллективом? А для больших проектов с мальньким рабочим коллективом? А если небольшой проект с неольшим коллективом вырастает в большой с большим - VCS менять? Не надо бред - git это стандарт, а hg вместе с bzr - маргинальщина для питонщиков.
>> поэтому для больших проектов - git, а для небольших рабочих коллективов - hg.
> А для небольших проектов с большим рабочим коллективом? А для больших проектов
> с мальньким рабочим коллективом? А если небольшой проект с неольшим коллективомдля небольших разработчиков с маленьким инструментом! </всё не заканчиваются>
Mercurial от гита, пожалуй, лишь тем, что он может сохранять имя ветки в метаданных коммита, а гит — не может.
В остальном у них почти идентичный функционал, что бы не говорили фанатики гита.
>идентичный функционал, что бы не говорили фанатики гита.s/фанатики гита./фанатики ртута./
s/фанатики .+\./фанатики./
hg вообще нигде не нужен
Вы искали что-то подобное? http://gitolite.com/gitolite/locking.html
Если нужны подробности -- гуглите в английском гугле по фразе "git lock file".А тут немного интересных размышлений на тему: http://stackoverflow.com/questions/119444/locking-binary-fil...
"This becomes simply a communication issue."
"Since (AFAIK) the Subversion locks are just advisory, an e-mail or instant message could serve the same purpose. But even if you don't do that, Git lets you fix it."
"No, there's no locking mechanism per se. But a locking mechanism tends to just be a substitute for good communication. I believe that's why the Git developers haven't added a locking mechanism."
И я полностью с этим согласен. Должен быть налажен рабочий процесс. Патчи должны проходить ревью. Мержить их должны интеграторы. Между разработчиками должна быть активная коммуникация. Лок -- это просто попытка такую коммуникацию заменить запретами. В нормальной схеме разработки лок -- это ненужный механизм.
не поможет. ему сразу сказали, что не инструменты надо полировать, а музыкантов менять. не помогло.
проблем с лочением у git нет
> проблем с лочением у git нети с мержем бинарников! //нет $объедка, нет проблемы
ждём еби^w слакбилдов.
nginx уехал на mercurial
> nginx уехал на mercurialПодтверждаю. Зашел на их сайт и вижу что там репозитории все Mercurial. Разумный выбор.
Валить надо с УГ svn. На нормальные современные DVCS и гнать поганой метлой дилетантов, осиливших только svn.
во-во, так и появился systemd, "починеный" udev с kmod, в котором modprobe -l deprecated и не нужен, пользуйтесь find, wayland etc. вокруг же одни дураки.
прискорбно, но opennet все больше напоминает желтый ресурс с соответствующими "оналитегами"
Как всегда, не совместимо с предыдущими версиями.Виндузятники тортоис обновили, я в командной строке получаю "This client is too old"
Пора оставшиеся svn репы на hg мигрировать.
> Как всегда, не совместимо с предыдущими версиями.
> Виндузятники тортоис обновили, я в командной строке получаю "This client is too
> old"
> Пора оставшиеся svn репы на hg мигрировать.Зачем же вы обновили свою рабочую копию?
Это забавно, но я очень долго не обновлял svn и всех держал на версии 1.6.Потом решил, что всё-таки пора. Обновил всё до 1.7, разослал всем письмо, чтобы скачали новый тортоис. Дал инструкцию, как тортоисом обновить старую рабочую копию.
Это было буквально позавчераПока все прочитали письмо и скачали тортоис, вышла версия 1.8, и всё :)
я только одного не понял: какого дьявола установкой корпоративного софта занимаются пользователи, а не администратор?
>занимаются пользователи, а не администратор?У него про-двинутые пользователи. Обзавидуйся.
>>занимаются пользователи, а не администратор?
> У него про-двинутые пользователи. Обзавидуйся.да вот почитал описание радостей. уже обзавидовался.
Автоматизация установки обновлений по рабочим станциям
> Автоматизация установки обновлений по рабочим станциямWake On LAN + скрипт обновления
> Как всегда, не совместимо с предыдущими версиями.
> Виндузятники тортоис обновили, я в командной строке получаю "This client is too
> old"
> Пора оставшиеся svn репы на hg мигрировать.Разумное решение - мигрировать на hg окончательно, там ни разу такого не видел чтобы новые репозитории не читались старыми клиентами...
> Разумное решение - мигрировать на hg окончательно, там ни разу такого не видел чтобы новые репозитории не читались старыми клиентами...рабочую копию от репозитария отличаем?
клиент
# cat /etc/redhat-release
CentOS release 5.9 (Final)# rpm -qa | grep subversion
subversion-1.6.11-11.el5_9# cd /tmp/
# svn co http://svn.example.net/test/ test
Checked out revision 7854.# touch test/file.txt
# echo "Hello world" > test/file.txt# svn add test/file.txt
A test/file.txt# svn -m "Test commit" commit test/
Adding test/file.txt
Transmitting file data .
Committed revision 7855.сервер
# cat /etc/redhat-release
CentOS release 6.4 (Final)# rpm -qa | grep subversion
subversion-javahl-1.8.0-1.x86_64
subversion-python-1.8.0-1.x86_64
subversion-1.8.0-1.x86_64
subversion-perl-1.8.0-1.x86_64И все работает ;)
Да... Не думал я что www.opennet.ru - филиальчик лора...
Уныло и печально.
> Да… Не думал я что www.opennet.ru — филиальчик лора…
> Уныло и печально.так уходи. тут и без тебя дураков немеряно, впрору экспорт налаживать.
до сих пор на 1.6. и если честно переходить на 1.7 не тянет совсем, а уж на 8 и подавно.
> до сих пор на 1.6. и если честно переходить на 1.7 не
> тянет совсем, а уж на 8 и подавно.в какой-то из версий до авторов svn наконец дошло, что гадить своими рабочими каталогами по всему дереву прокета — nekulturna. как по мне — одно это уже достаточная причина, чтобы обновиться.
>> до сих пор на 1.6. и если честно переходить на 1.7 не
>> тянет совсем, а уж на 8 и подавно.
> в какой-то из версий до авторов svn наконец дошло, что гадить своими
> рабочими каталогами по всему дереву прокета — nekulturna. как по мне
> — одно это уже достаточная причина, чтобы обновиться.Для тех кому это надо достаточно обновить клиента а не мигрировать на новый сервер, удивительно, да?
> Для тех кому это надо достаточно обновить клиента а не мигрировать на
> новый сервер, удивительно, да?Опубликуйте матриссу совмесстимости и неизменносси сетеваго протокола. Пожалуйста! А то ж обсуждение затухает.
> удивительно, да?удивительно, да. я как-то не слежу за совместимостью версий svn, мне пофигу. при нужде git умеет импортировать.
>> удивительно, да?
> удивительно, да. я как-то не слежу за совместимостью версий svn, мне пофигу.
> при нужде git умеет импортировать.удивительно, но svn тоже умеет
> удивительно, но svn тоже умеета это уже личные трудности бедняш с svn. как я уже говорил, мне поддержка svn интересна ровно до той черты, за которой работает git-svn.
>> удивительно, но svn тоже умеет
> а это уже личные трудности бедняш с svn. как я уже говорил,
> мне поддержка svn интересна ровно до той черты, за которой работает
> git-svn.а мне поддержка git вообще не интересна и что с этого? Новость про svn!
> а мне поддержка git вообще не интересно и что с этого?ничего.
> Новость про svn!
и что с этого? древовидные комментарии удобны в том числе и тем, что в отдельной ветке можно вести совсем отдельную беседу.
> и что с этого? древовидные комментарии удобны в том числе и тем,
> что в отдельной ветке можно вести совсем отдельную беседу.очень интересно читать в новости об svn ваши потоки сознания о git!
> очень интересно читать в новости об svn ваши потоки сознания о git!я сегодня добрый, могу бесплатно научить тебя закрывать браузер. это несложно.
>> очень интересно читать в новости об svn ваши потоки сознания о git!
> я сегодня добрый, могу бесплатно научить тебя закрывать браузер. это несложно.лучше научись контролировать свои потоки сознания, полезно тебе и окружающим польза
а ещё я могу бесплатно сказать себе, куда ты можешь засунуть свои непрошеные советы.
Я смотрю, господина пронесло по полной. Аж весь топик заляпал своими очень важными комментами.
> Я смотрю, господина пронесло по полной. Аж весь топик заляпал своими очень важными комментами.Понос головного мозга дело опасное, но АНАЛИТЕГИ не сдаются :D
>в какой-то из версий до авторов svn наконец дошлоВ 1.7, плюс там ещё всякие нужные фишки появились. Вообще, для небольших проектов и компаний svn вполне ничего. Всю жопу начинаешь осознавать когда пытаешься работать с крупным открытым проектом для которого у тебя нету прав ни коммитить, ни ветки создавать - тут-то и понимаешь нафига придумали git. Благо сейчас почти у всех есть зеркала на github.
на крайний случай есть git-svn.
>> до сих пор на 1.6. и если честно переходить на 1.7 не
>> тянет совсем, а уж на 8 и подавно.
> в какой-то из версий до авторов svn наконец дошло, что гадить своими
> рабочими каталогами по всему дереву прокета — nekulturna. как по мне
> — одно это уже достаточная причина, чтобы обновиться.Наоборот, с каталогами по дереву SVN можно было хоть как-то пользоваться. Например, сделать только в нужной поддиректории вместо git-svn, или переключить только отдельную директорию на локальное зеркало вместо основного репозитория, или вынести нужноую поддиректорию из дерева. Теперь - хрен.
SVN все еще достаточно неплохая система контроля версий, особенно для компаний. GIT больше для опенсощены канает, чтобы легче было форкать, собирать манатки, собирать версию со своим фиксом с блекджеком, итд.Еще svn хорош там где много бинарников, меньше места на машине клиентов.