to post messages and comments.

А я тут подумал — ведь дохуя программистов которые не воспринимают код как текст вообще. Им IDE само делает рефакторинг, переименовывает все вызовы и так далее. А тут внезапно надо мержить, и где-то поменялась переменная, а в другом месте ты её вызвал. Это уже непривычно и анноит, надо ходить по проекту и исправлять руками ошибки. А когда конфликт — это вообще пиздец, всё раскрашивается красным, их выкидывает из зоны комфорта на орбиту Юпитера.

Есть ли в природе VCS, которые умеют адекватно работать с файлами, которые фактически являются архивами (e.g. svgz, odt). Посмотрел как это предлагается делать в Fossil и что на эту тему умеет git — всё фигня, по треть решения от необходимого. Нужно:
* Хранить только дифф изменившихся внутри архива файлов
* Причём без дополнительных приплясываний внутри working directory для конвертации архивноформатных файлов между хранимым и редактируемым видом
* Было бы ещё здорово, если б оно в diff могло сравнивать распакованные данные.

Вообще "зачем сохранять промежуточные версии" — вопрос нериторический. cvs — а её проприетарные аналоги ещё продаются за дикие бабки, и немалая доля тех кто принимает решения и обучает в вузах умеет только в них — в общем случае не гарантировала даже что ты сможешь счекаутить и собрать какую-то прошлую версию. Учитывая что писать внятные сообщения к коммитам они тоже не умеют и не учат — остаётся только функция "найти виноватого". Что, действительно, не так уж и ценно.

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

vcs ?

Засовывать какой-нибудь git/mercurial/etc. во что-нибудь типа btsync/dropbox/etc. не самая хорошая идея ведь, да?
Помнится, попытка работать в таком синхронизируемом репозитории приводила к кровькишкирас*о этого самого репозитория.

Я тут пока что остался без домашнего серверка, а репозитории синхронизировать хочется. Но безо всяких там github/bitbucket/etc.

попытка залить централизованный репозиторий с исходниками (хрен знает с какой долгой историей) в mercurial — клонирование такого репозитория занимает 30 минут, а смена бранча почти 1 час (диск классический, не SSD).
git вообще не осилил столько гигов.

резюме: dvcs нужно только для хорошо раздробленных проектов и стартапов.
пока непонимаю, как его можно применить в текущих проектах

Сегодня 10 часов утра, практически без объявления войны, преспешники централизированных систем контроля версий, таких как SVN и TFS возглавляемые опытным и опасным полководцем Ярославом Германом, перешли в наступление на хорошо укреплённые баррикады последователей GIT и Mercurial, оборона которых подконтрольна вашему покорному слуге.
<бла-бла-бла>
Приходите в кафетерий офиса на Жилянской и поддержите светлую сторону разработки, блабла

Середина 2013 года, в епаме обсуждают преимущества git относительно SVN

А вот интересно, есть ли такие системы контроля версий, которые при слиянии учитывают синтаксис конкретного языка, то есть, если один разработчик поменял везде название переменной, а другой произвел изменения над кодом, в котором эта переменная (до переименовывания) участвует, то такая система сможет слить изменения автоматически (естестенно, если слияние не тривиальное она должна расценивать это как конфликт) и разрешать таким образом львиную долю конфликтов слияния.
Такое уже есть, или это нинужно ?

У меня тут гранитная табличка с золотыми буквами завалялась.
Баянистая, конечно, но может кто ещё не видел, подниму по-выше:
----
Новый проект (размер не имеет значения) — git init
Новая фича — новый бранч

Отчего сениоры не доверяют контролю версий? Зачем комментить старый код, который может когда-нибудь пригодиться, но сейчас не должен использоваться, а не удалить его просто, а когда нужно просто вытащить его из истории? :(

нужно, для работы над веткой, сделать некоторое изменение, которое потом, при мердже в основную ветку, надо отменить. при этом желательно иметь вожможность его вернуть, при вовращении к работе над веткой. как это лучше сделать?
пока не придумал ничкго лучше, чем держать патч с этим изменением и применять его при переходе к работе с веткой, но не комитить его. недостаток: при переходе к другим веткам это изменение придется reset'ать, а при возврящении снова накатывать. и сам патч придется где-то отдельно хранить.
можно еще сделать такой комит в начале ветки и отменить его перед мерджем или после него. проблема: лишний мусор в истории.

[email protected]yesyes: да, и проблема в том что никто не хочет веток, всё в транк комитят
ne_formal: yesyes, сколько человек?
yesyes: больше 150
yesyes: некоторые даже не знают что такое ветки
ne_formal: эм, стой.. как 150 человек работают с одним транком?. они же тогда дожны перманентно пытаться что-то закоммитить
yesyes: да

Столкнулся с тем, что не могу вытащить из SVN-репозитория файл.
Файл закоммитили из под винды с NTFS, а достать пытаюсь под маком с HFS+.
Проблема в том, что его название сильной больше 256 знаков по длине.
Потому получаю ошибку от макоси, что с такими работать не умеет.
Но проблема получается фундаментальная и не зависит от средства контроля версий.
Такой файл можно получить даже просто по почте.

Я не так давно радовался возможности коммита из IDE, а сегодня порадовался тому, что-таки не забываю консоль.
чарма весь день рапортует, что коммиты успешны, даже 2 раза пуш делал — всё супер!
Смотрю, в очередном коммите нет нового файла(обычно чарма их предлагала добавить тут же), лезу в консоль и...
$ hg st
M main/web_responses.py
? reportapp/__init__.py
? reportapp/tests.py
? reportapp/views.py
Это ли не чудо? Новый каталог вообще не добавлен! Не беда, добавляем, коммит, пуш и
abort: push creates new remote branches: dev_reports!
(use 'hg push --new-branch' to create new remote branches)
А мужики-то не знали!^W^Wчарма ничего не сказала.

Впервые за несколько лет воспользовался возможностью коммита из IDE(vim не считаем). И это... это работает!
он сам сумел hg commit -m "[+] new feature" && hg push
НЯ, товарищи!

вот поработал с git на github'е, поигрался с hg на досуге.
выводы (субъективные):
git для красноглазиков (даже используя TortoiseGit!!), юзает много чего из msys'а, под виндой это очень неудобно.
hg, по сравнению с git'ом, глоток свежего воздуха — работает все из коробки, кроме tortoisehg ставить больше ничего не надо, даже web сервер в комплекте идет

резюме: буду юзать git только если надо (как сейчас — патчи отсылать).
для себя, для своих новых мелких проектов буду юзать hg