Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 16 Sep 24 17:28:15, всего сообщений: 10763
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 7326 из 10763 ===================================== RU.UNIX.BSD =
От   : Alex Korchmar                    2:5020/400         08 May 18 22:09:30
Кому : Slawa Olhovchenkov                                  08 May 18 22:09:30
Тема : Re: /var/db/freebsd-update
FGHI : area://RU.UNIX.BSD?msgid=<1187509559@ddt.demos.su>+b686ac46
На   : area://RU.UNIX.BSD?msgid=2:5030/500+5af1e4bf
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=2:5030/500+5af200c8
Ответ: area://RU.UNIX.BSD?msgid=2:5005/49+5af284a1
==============================================================================
From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO> впрочем ты опять не сказал, что именно нельзя сделать
ничего из того что делается в vcs - нельзя.

Объяснять с нуля, зачем нужны вообще системы контроля версий и как именно
работают распределенные - во-первых, бесполезно, во-вторых попробуй сам кому
объясни хотя бы про то, чем ты умеешь пользоваться.

Ведь так прекрасна и удобна "новая папка(254)"

SO> а в чем проблема?
SO> если ты не делаешь svn ci то и пофиг на на коммиты.
то нахуй тебе вообще сдалась система контроля версий ?
Похоже, я тебя понял - ты ей и не пользуешься, как и Женя.

SO> вот именно. а у меня это невозможно, поскольку для меня атомарный набор
SO> изменний один, а публично -- другой.
это значит что он неатомарный. Атомарный нельзя разделить на два.

SO> уже и этого достаточно, а для полного кайфа они не разделяются по методу
SO> "публично только часть изменений".
значит будут две ветки с эпизодическим merge. Противно и неудобно (именно в
git это сделано плохо, хорошо в hg) но всяко лучше чем "новая папка(256)(копия)"

SO> самое. и если если я в логике
SO> делаю исправления, то править надо в двух местах.
merge, исправляем, commit, rebase.
Hеудобно, но a) сохраняется история изменений  в каждой ветке в отдельности
b) можно посмотреть чем отличаются ветки и вовремя заметить ошибку

но это у тебя какой-то особо запущенный случай, мне, во всяком случае для
freebsd, такого не надо, у меня нет нескольких разных кодов для разных случаев.
(в своих проектах есть, там есть stage который отличается от prod, это разные
ветки)

SO> svk mirror svn://svn.freebsd.org/base/stable/11 //mirror/FreeBSD
SO> svk sync //mirror/FreeBSD
SO> svk cp -p //mirror/FreeBSD //FreeBSD/export
не, это п-ц какой-то. 96й год на дворе. Во-первых, я работаю с файлами,
а не с патчами. У меня есть рабочее дерево исходников, и в идеале оно одно.
У исходников есть история, она нелинейна - есть история апстрима (апстримов),
есть мои правки поверх апстрима, есть правки моих правок из-за изменений в
апстриме, и еще я тут в корень просыпал гиг фото с котятками, хорошо бы это
вовремя заметить (нет, удалять не надо, у меня нет копии).
Все это (в виде, напомню, дерева развернутых исходников, а не отдельных патчей)
можно вытащить в любой момент на любое состояние, если текущая версия почему-то
кажется мне подозрительной, или я просто хочу посмотреть, как оно было, к
примеру, до kpti.

С патчами я вообще не работаю - что мне, патч редактировать, что-ли?

Я могу _сэкспортить_ набор патчей (не обязательно линейных), если мне кому-то
надо отдать только часть изменений, а моя внутренняя кухня ему без надобности,
но это делает за меня автоматика, мне только надо ей потыкать, какие именно
правки я хочу выделить в один набор.

> Alex

--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.102046 секунды