https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html Компания WANdisco, оплачивающая работу нескольких разработчиков Subversion и выпускающая на базе данной централизованной системы контроля версий несколько коммерческих продуктов, объявила (http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-12-20) о решении реализовать собственными силами пожелания, наиболее часто высказываемые пользователями Subversion, такие как функций по быстрому слиянию и созданию веток. <br><br><br>Результат работы планируется интегрировать в основную ветку исходных текстов Subversion и довести их до готовности до выхода релиза Subversion 1.7, который намечен на 2011 год. Работа будет проведена (http://blogs.wandisco.com/2010/12/20/shaking-up-subversion-by-listening-to-the-user-community-and-then-committing-to-do-the-work/) в тесном сотрудничестве с независимым сообществом разработчиков проекта Subversion, от которого будет зависеть конечное решение о включении созданных в WANdisco улучшений.<br><br><br>Некоторые из улучшений (http://www.wandisco.com/svndisco), которые намере...<br><br>URL: http://www.wan https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#77 Sun, 29 Mar 2020 11:40:31 GMT На дворе уже 2020, а svn всё ещё жив и процветает.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#76 Tue, 28 Dec 2010 17:41:37 GMT &gt; Ты как всегда в своем троллеламерском стиле.<br><br>С зеркалом закончите разговаривать, сообщите. :)<br><br>&gt; при нормальном дизайне VCS working copy не прибит гвоздями к репозиторию,<br><br>Озвучьте критерии "нормального дизайна VCS", пожалуйста. Можно с примерами.<br><br>&gt; т.е. схема которую предлагают адепты недоразвитого git'а (push 1&gt;bare, pull bare&gt;2, <br>&gt; rebase@2) работает без необходимости сторонних репозиториев (push 1&gt;2, rebase@2).<br><br>*sigh*<br><br>"1" и "2" -- это репозитории (так понимаю) или ветки? Если первое, то какая проблема с fetch 2&lt;1 или push в не-чекаутный бранч, если всё равно затем rebase?<br><br>Пока похоже, что у Вас проблемы с pull vs push, а не чем-либо ещё. И если так, то неудивительно.<br><br>PS: судя по слогу и уровню аргументации, это опять подросток из оракла.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#75 Tue, 28 Dec 2010 16:56:21 GMT &gt; А вот это по-настоящему серьезный, сугубо технический и объективный аргумент!<br><br>Вообще-то это нормальный аргумент. Причём объединяет в себе как причины, так и следствия убогости базара. Был бы хорошей VCS - был бы распространён чуть шире чем нигде это следствие. А причина - зачем ставить левоту когда везде есть и уже используются git/hg?<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#74 Tue, 28 Dec 2010 16:52:21 GMT Ты как всегда в своем троллеламерском стиле.<br><br> при нормальном дизайне VCS working copy не прибит гвоздями к репозиторию, т.е. схема которую предлагают адепты недоразвитого git'а (push 1&gt;bare, pull bare&gt;2, rebase@2) работает без необходимости сторонних репозиториев (push 1&gt;2, rebase@2). Элементарно, казалось бы. Но нет, мы пойдем другим путём.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#73 Mon, 27 Dec 2010 10:20:44 GMT &gt;&gt; Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push.<br>&gt; Алгоритм абсолютно такой же как при наличии отдельного bare репозитория,<br>&gt; только без него. Это же и идиоту очевидно<br><br>Ясно, слабо. _Это_ действительно очевидно.<br><br>PS: какой-такой "отдельный bare repo", задумайтесь хоть... и откуда "такой же", когда вместо одной сущности вдруг появляется две, причём речь именно о поддержании их взаимной синхронизации при совершении push.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#72 Mon, 27 Dec 2010 10:19:29 GMT &gt;&gt; ...а либо про него Вам наврали, что "простой" (он не простой), либо ...<br>&gt; "простой для изучения" и "простой для использования" -- это немного разные понятия <br><br>Разумеется. Я считаю, что git достаточно сложен в изучении и бывает сложен в применении, но результат того _для меня_ стоит. Но не для ламера, надо быть хотя бы честным чайником.<br><br>&gt; и вот когда вы спрашиваете кого-то "&lt;такой-то&gt; инструмент -- он простой?"<br><br>Предпочитаю не задавать неоднозначных вопросов, чтоб не огорчаться ответами невпопад. :) Вы прекрасно озвучили проблему с наивным стилем вопрошания.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#71 Mon, 27 Dec 2010 07:00:28 GMT А что, заставлять программеров пользоваться консолькой при каждом коммите/синхронизации/etc уже верх конструктива? Или есть всё же нормальные плагины к эклипсу? Если да, почему не гуглятся?<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#70 Mon, 27 Dec 2010 00:54:16 GMT &gt; Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push.<br><br>Алгоритм абсолютно такой же как при наличии отдельного bare репозитория, только без него. Это же и идиоту очевидно, только у любителей git видимо совсем чуждая нормальному человеку логика.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/73559.html#69 Sun, 26 Dec 2010 22:27:31 GMT &gt; ...а либо про него Вам наврали, что "простой" (он не простой), либо ...<br><br>"простой для изучения" и "простой для использования" -- это немного разные понятия<br><br>инструмент зачастую бывает простой для использования -- но СЛОЖНЫЙ для изучения!!<br><br>----------<br><br>..наглядный пример: КАРАНДАШ!<br><br>карандошом легко писать слова (но это когда вы уже _научились_ правильно пользоваться карандошом)..<br><br>....но вспомните -- сколько требуется времени и усилий человеку чтобы овладеть навыком использования карандаша (для написания слов)!!! :-)<br><br>времени явно больше чем время что требуется на изучение Git :-) :-)<br><br>----------<br><br>и вот когда вы спрашиваете кого-то "&lt;такой-то&gt; инструмент -- он простой?" что вы ожидаете услышать? ответ на тему того что инстурмент простой для обучения? или что инструмент просто для повседневной работы?<br>