Так и не надо с командой.
Просто используйте свой локальный репозиторий, и изредка отправляйте изменения на удалённый.
По сути, в этом и заключается разница между распределённой и централизованной системами контроля версий - в наличии в распределённой системе локальной копии главного репозитория.

Насчёт бесплатных svn-хостингов много не насоветую. Слышал про www.assembla.com. Сам не пробовал.

А какой визуальный клиент используете?

Вы про гит? Как-то приспособился обходиться без визуального клиента. Настроил meld в качестве средства визуального сравнения, а остальное - из консоли.
Знаю, что есть TortoiseGit. И прямо с git-ом в комплекте есть gitk - это простая такая штука.

Да, про Git. И про все остальное, может, еще кто-то поделится.
А репозиторий можно и на флэшке сделать.
Бинарные файлы хранить (схемы, платы), похоже в Git "правильнее" будет.

Почему бы GIT просто не назвать избыточным локальным архивом вместо 'распределенный'?
Это было бы правильнее.


По сути GIT всегда локальный.
Сделайте SVN локальным и приделайте backup от него на сервер и получите GIT.

Но GIT еще и избыточен поскольку всегда сохряняет версии файлов целиком, а не изменения как в SVN.
Вообщем полное недоразумение.

Хотя GIT наиболее близок по духу к обычным архивам чем все остальные контроли версий. В этом смысле, да, он более прогрессивен.

Но с другой стороны современные среды разработки и так создает папку history где автоматом сохраняют все старые версии.

На множество серверов. И ещё в обратную сторону. И быстрое, удобное ветвление и слияние. А так да, svn и git похожи.

"Современные" - это дельфи что ли?

Зачем на каждый чих? В этом и прелесть SVN - она лезет в репозиторий, только когда ее попросишь, а иначе все локально.

Я на все эти бесплатные хостеры давно забил и всем советую. Правильный фрилансер ставит дома NAS - например у меня Synology DSXXX. На нем же крутятся фильмы, фотки, музыка и другая фигня. SVN-сервер там - стандартная приблуда и настраивается прямо из коробки. На домашнем роутере пробрасываем порты и на NAS запускаем родную службу DDNS, которая кстати работает чотко и денег не просит, бо за оборудование уже заплачено. Вот вам и доступ откуда угодно.
Бекапы опять же делаются каждую неделю средствами NAS вместе с фотками, SVN репозиторием и прочей фигней на один фирменный сервак за 2000 км, к которому я по счастливой случайности имею доступ по rsync и VPN. Очень медленно, но верно. Но можно и на флешку.

Клиент - TortoiseSVN - простенько и со фкусом.

"Всё локально" - что входит в это "всё"? Можете перечислить операции, для которых svn не требуется доступ к серверу?

Вот это и расскажите своим сослуживцам, которые, по вашим словам, "некоторые люди конкретно не понимают".
Или SVN у вас вхолостую работает на домашней NAS "шоб було"?

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

Да, это Вас удивляет?

Зачем язвить? Мне что, есть смысл балаболить? DNS ресолвер предоставляет сама Synology http://myds.synology.com/, раньше пользовался бесплатным no-ip, но задолбали они меня своими мылами.

Копирование/перемещение/удаление файлов/директорий, создание веток. Доступ требуется для обращения к предыдущим ревизиям (в том числе для просмотра лога), фиксации, слияния веток.

Ну, собственно вот про это я и говорил - "на каждый чих"
В случае с гит доступ к удалённому репозиторию требуется только для отправки изменений туда и закачки изменений оттуда. Остальное можно локально. В этом я вижу большой плюс гита.

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

Ха, теперь я занял позицию: не нужен мне этот ваш git, меня и в svn все устраивает

ИМХО этот плюс важен для больших проектов или большой команды/частых изменений извне и медленного интернетв. Для эмбеддерских проектов или пары человек мне кажется, это не сильно важно. Я вообще распределенки не рассматривал, так как дотрагивался к большим фирмам и у них был SVN или Subversion, у меня SVN установился и заработал сразу и в конце концов все понятно с бэкапами. Неудобств, кроме длительного времени синхронизации изменений в случае больших файлов и медленного канала, да и то только в разовых случаях, я не увидел.

Минуточку! Там в списке достоинств гита был ещё пункт "быстрое, удобное ветвление и слияние". А это очень крутая штука.
Скажем, сижу я, работаю над одной новой функцией. Тут является начальник, и говорит мне:
"Сейчас приедут заказчики, нужно срочно показать прибор."
Тогда я быстренько занычиваю (git stash) текущее состояние проекта, переключаюсь на стабильную ветку (git checkout master), компилирую прошиваю, демонстрирую. После этого возвращяюсь к отложенному состоянию, и продолжаю работать как ни в чём не бывало.
Ещё очень удобно иметь при разработке ветки для каждой новой фичи. Устал работать над одной - переключился на другую. Закончил фичу - переключился на мастер-ветку, влил в неё изменения из фичеветки, и удалил её. Можно при этом упорядочить историю, поменяв местами коммиты из фичеветки или объединив часть их в один коммит.
ЗЫ. Мне нравится развитие темы. Всё же git vs svn гораздо лучше, чем "крутым ымбеддерам системы контроля версий не нужны"

Это потому что ты feature branches не используешь. В svn с ветками и слиянием всё достаточно печально. Они годятся для крупных ответвлений, но для оперативной работы в параллельных направлениях они слишком тяжелы, а слияние по сути делается на сервере. В git же этот момент реализован очень эффективно - ветка есть указатель на конкретный коммит (коммит в гите - это объект-слепок какого-либо состояния проекта), т.е. ничего не весит, работает это мгновенно. Слияние тоже реализовано хорошо (есть несколько стратегий). А слияние результата работы в ветке (я имею в виду feature branch) со сквошем позволяет не замусоривать историю релизной ветки подробностями о мелких "технологических" коммитах - в истории главной ветки только значимые коммиты с соответствующими внятными сообщениями.

Именно возможность легко, быстро и прозрачно заводить экспериментальные коммиты (ветки), которые не будут потом мозолить глаза в истории релиза, и подвигла меня смотреть в сторону гита.

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

Очень кривая технология.
Поскольку "быстренько занычиваю" не что иное как переписывание файлов туда-сюда.
При этом не имеете одновременно двух копий сразу. А главное это все из командной строки! Жесть.



Как это у вас получаются незаконченные версии.
Тестирую после каждых нескольких десятков строк, никогда заканчивая работу не остается незаконченных версий.
С другой точки зрения законченных версий вообще не бывает, всегда идет развитие.

Разница в VCS видна лишь утонченным сомелье. Если просто и без изысков работать, то сгодится любая, и ничем они с точки зрения неискушенного пользователя не отличаются.

Я раньше в этой ветке приводил список команд, которые нужны для начала работы. Так вот, 95% пользователей VCS нуждаются исключительно в этих командах в 99% случаев.

а просто хранить на случай таких гостей готовую стабильную откомпилированную прошивку и прошивать ее по необходимости - не вариант?

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

ну как бы SVN это на ура делает...




хачу заметить что система хранения версий - это инструментарий. Им можно пользоваться по разному.
В некоторых конторах есть основная, всегда успешная версия (в неё коммитяться после кучи подписей всех отделов) и куча релизно-текущих веточек.
В других конторах есть текущая версия(разрабатываемая. коммиты = исправления и фичи) и отслоения по релизным веточкам(коммиты = исправления).
В третьих конторах есть кучи тееущих, кучи релизных, кучи разрабатываемых и совсем жесть - через систему хранения версий делать ремап
библиотек и окружения солюшена...

короче говоря потуги сезонные. кто весною решил круто всё упорядочить, кто осенью...разные обострения и взгляды
причём ослинные уши начинают сильно задевать за лодыжки в момент интеграции с другим софтом процесса разработки.
от тут косяки упорядочивания стаями слетаются..

Что именно svn делает на ура? Позволяет без доступа к серверу вести параллельную разработку в нескольких ветках, сливая результаты в стабильную ветку? Позволяет (опять же без доступа к серверу) в произвольный момент времени переключиться из рабочей ветки в стабильную без коммита/потери промежуточного результата?
Позволяет без доступа к серверу сдеолать дифф с любой версией?
Нет, svn этого не делает. Ни на ура, ни как либо иначе. С доступом к серверу часть этих функций можно реализовать на svn. Но это уж точно не будет так легко и непринуждённо, как с git.

Спасибо, Кэп!
Как вы наверное догадались, я описывал лишь один из способов использования данного инструментария - тот, который использую сам.

Это называется сеять самому себе грабли.
Ну какие вы там функции то себе придумываете ради которых надо создавать отдельные ветки (версии)?
И что потом помните в какой версии какая функция?
Не забываем, что согласно вашей легенде вам чтобы посмотреть просто исходники какой-нибудь версии с новой функцией нужно лезть в командную стороку, вполнять checkout .
Потом открывать редактор и т.д.

Далее ИМХО.

GIT создавался для линукса и ветки в нем просто фильтры от гигантского количества мусора от чужих платформ.
И планировалось в нем долго и обособленно работать с небольшим количество файлов относящихся к определенной платформе.
Потому там и не экономят место, но зациклены на быстроте. Ибо файлов во всем дистрибутиве десятки тысяч.
Инструмент явно не для малых embedded систем.

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

я не буду утверждать что лучше что хуже. вполне гит востребован для создании локальной аля системы хранения. не юзал его.
но с кочки зрения процесса разработки, в плане организации на предприятии, централизованное хранение исходников - есть выигрышная вещь.
например разбивая общую задачу на составный подзадачи, и распаралеливая их выполнение, мы можем обеспечить отдельное "кусочное" тестирование
под каким нить серваком непрерывной разработки. тем самым получая ОБЪЕКТИВНО количественный результат для оценки текущего состояния дел.
или немного по другому - фидбэк быстрее, оценка быстрее, подправление процесса(если не туда ползёт) быстрее, обнаружение ошибок быстрее.

возможно гит хорош когда команда разработчиков вылетает на самолёте и надо срочно что то создать на коленке - хз...я скорее всего не чувствую
этот момент и соответственно плюсы такого подхода...

Я тоже про начальника не сильно согласен.
Достаточно просто локально сделать чекаут стабильной ветки и своей ветки разработки. Переключение между ними - просто переход в другую папку в експлорере.
Стабильный чекаут - пусть себе лежит на диске на всякий выездной случай. Если анонсировали новую версию - можно его апдейтить время от времени.
По поводу с сервером или без - это как кому нравится имхо

Вот в этом-то всё и дело : "не юзал, но мнение имею". Гит даёт всё то же, что и свн, плюс много больше, за счёт локального репозитория, быстрых веток и возможности синхронизации с несколькими удалёнными серверами. То есть, централизованное хранение исходников - очень даже присутствует, а распараллеливание задач - вообще родная стихия гита.


Ага. Скачать мегабайты, сейчас, положим, можно быстро. А перенастроить среду разработки и сборки на другую папку?

Вы невнимательно читали. Речь не про продакшен, а про разрабатываемое изделие. Когда новая стабильная (читай - рабочая) версия появляется несколько раз на дню. Добавили новую функцию, проверили - влили в главную ветку. В вашем варианте к этому добавляется отправка этого варианта на сервер и чекаут его в другую папку.
Для выездного случая гит вообще вне конкуренции - вся история при вас, можно быстренько получить любую предыдущую версию. Можно сделать ветку-исправление бага. Можно отложить эту ветку, если не получается, и начать другую. В общем, очень, очень удобно.

Короче, друзья. Почитайте про гит, попробуйте, и уже потом выносите суждение.
Вот, например, неплохое начало. Пара-тройка вечеров, и вы уже в теме.
Ну или классическая книжка про гит (или её версия в pdf).

Это интересно. Какая у вас среда разработки? И почему ее надо перенастроить?
Не знаете конфигурационных файлов своей среды?
Среда не поддерживает относительных путей?

И зачем все таки версии и ветки если просто добавляете несложные функции в программу?
Макросы и условная компиляция уже не работают? В ваших программах проявляются местные эффекты (т.е. изменение поведениея только из-за появления новых блоков текста в исходниках)?

Пока сценарии приводимые для использования с GIT малореалистичны. Как будто придуманы. Либо присутствуют больее серьезные вынуждающие обстоятельства (например тот самый начальник).

Многие уже честно признались, что контроль версий используют просто для синхронизации между рабочими местами. В принципе можно понять если нет другого варианта.

Кстати, хотел спросить по SVN - и использование externals.
Допустим у меня есть trunk-и для разных проектов со своими папками, но, допустим, один человек хочет иметь у себя только папки models из всех этих транков в одной локальной папке. Чтобы не лазить по репозиторию и не делать индивидуальные чекауты, можно ли просто создать в репозитории пустую папку с названием all_models, например, у которой в свойствах externals были бы заданы все нужные папки? Чтобы при ее чекауте все они вытаскивались автоматом.
В принципе коммиты в этом случае не требуются - в основном это для быстрого обзора.

Существует такая практика?

Конечно существует.
Ручками пишутся скрипты для SVN сервера с использованием svnsync.
Создавайте еще один программный проект, учитесь писать скрипты, потом заниматься поддержкой, привыкайте к командной строке... Не ленитесь короче

Да, всё можно. Создаёте свою директорию all_models, в её свойствах задаёте svn:externals, где для каждого external'са будет пара <dir_name> - <url_path> (dir_name - название местной директории, url_path - полный путь до директории в стороннем репе). Затем svn update, и вуаля. Если есть доступ по записи в те репы, то можно вносить правки и коммитить.

Речь идет на SVN сервере создать такую директорию. Чтобы видимо не лазить по компьютерам юзеров.

Если бы вы хоть немного знали устройство и возможности Subversion, вы бы не писали таких глупостей. Человек конкретно спросил по фичу svn:externals, ни слова ни сказал про сервера и прочее. Вы что-то домысливаете себе, фантазируете... Половина темы замусорена вашим беспредметным флудом. Будьте принципиальны, воспользуйтесь своим право модератора и забантьте себя хотя бы на участие в этой теме за постоянный флуд и введение в заблуждение других участников, которые [пока] не разбираются в теме. Это сделает вам честь и поправит изрядно пошатнувшуюся репутацию.

Да, когда тролль -- модератор - это проблема...

Так. Все по регламенту.
Я высказываю свои мысли и стараюсь держаться в контексте автора топика.
Контекст напомню таков, насколько можно понять:
Есть небольшая фирма с программистами со своими достаточно изолированными проектами на которой всех хотят перевести на SVN.
Все!.

Это моя тема поскольку я сам работаю с такими фирмами. Более того, автоматизирую бизнес процессы. Думаю опыт имею.
Перевод темы на мировые проблемы как тут некоторые пытаются, и на проблемы корпораций я не делаю. Все корректно.

Последний вопрос стоял организовать директории в репозитарии. Где репозитарий у автора находится? Блин, на сервере!
Так кто кого тролит?

Кстати сейчас у меня стоит полная тестовая архитектура c TurtoiseSVN и VisualSVN Server с независимыми станциями в разных доменах со связью через удаленный роутер в интернете.
Все грабли SVN видны как на ладони.

С чего вы взяли, что там хотят организовать директории в репозитории? Человек чётко и ясно написал, что ему нужны выборочно фрагменты (директории) из разных репозиториев. Очевидно, что они ему нужны локально на своём компе. И он правильно предположил, что это можно простым способом организовать с помощью svn:externals. Почитали бы, что-ли, хоть доку на svn. Вдумчиво, не "по диагонали".


Я, кстати, не считаю, что вы троллите - троллинг предполагает, что тролль разбирается в вопросе. Моё мнение совпадает с высказанной andrew_b ранее в этой теме оценкой (пост №42):



Мне только не понятно, что даёт вам внутреннее право и уверенность безапелляционно нести чушь на тему VCS на протяжении многих страниц.

Давайте без личностей.
Право мне дает формат этого форума. Я изо всех сил пытаюсь никого не обижать.

Мне только интересно что вы знаете и можете сказать о практике применения контроля версий.
Лучше бы рассказали о своей практике.
Только без ссылок на мануалы, слэнга и проч. шелухи. Только правду жизни, так сказать.

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

короче говоря мнимое удобство. просче и быстрее плоскую модель иметь. в конечном итоге именно на плоскую модель нацелены большинство
компиляторов и инструментариев.

Стараться мало, надо этого не делать. У вас тут это не очень получается. Со стороны действительно выглядит как троллинг.


Моя практика не интересна - она вполне ординарна и находится в русле общих подходов к этому делу, об этом знают все, кто применяет системы управления версиями по назначению.


Вы хотите, чтобы я вам пересказал содержимое мануалов и "проч. шелухи"? Пардоньте, это многовато букв и не формат для темы форума, да и смысла нет - кто хочет, тот будет разбираться по мануалам, а тут задаст конкретные вопросы, на которые уже можно конкретно ответить.


Что мешает тянуть externals не из HEAD (что по умолчанию), а из конкретной ревизии? Укажите номер ревизии, и пусть там они меняют свой HEAD сколько угодно, у вас будет стабильная привязка к конкретной версии.

правда жизни в том, что банальное сравнение с предыдущими версиями, поиск места "где же я за вчера накосячил" с SVN существенно удобнее и быстрее чем это сделает тотал коммандер.

Вообщем вы правы, если немного расшифровать ваш несвязный пост.

Если в директории какого либо рабочего проекта под SVN на компьютре одного юзера сделать поддиректорию выбираемую из другого репозитария SVN и зарегистрировать (commit) это в репозитарии рабочего проекта, то на компьютерах остальных юзеров после операции update того же самого рабочего проекта появится та же поддиректория с ее содержимым.

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

Хорошо, прогресс есть - вы поняли наконец, что речь с самого начала шла про рабочую копию (РК), а не сервер. Следующий уровень понимания будет, когда вы убедитесь, что мой пост в контексте заданного вопроса очень даже связный. Для этого вам нужно получше узнать, как работает механизм svn:externals.


Неправильно. Перечитайте внимательно тот мой "несвязный" пост - там очень связно и конкретно указано, что нужно сделать. Предварительно воспользуйтесь советом, данным выше - изучите механизм работы и применение svn:externals.


Кучу апдейтов делать не надо - достаточно одного для этой директории, куда назначены externals. Чтобы понять (если это необходимо), что изменилось в externals, а что нет, достаточно обычным штатным образом посмотреть svn log (или средствами GUI клиентов, я под вендой предпочитаю черепаху). В общем, один раз настраивается и дальше используется как обычно штатными средствами без всяких лишних телодвижений

Какую черепаху - TortoiseGit или ...SVN? Вы же говорили, что Git используете. Или что?

А вы знаете как работает svn:externals? Изучали структуры данных SVN-а?
Мы знаем только то, что написано в мануале. А еще я протестировал. Пока новой информации вы не сообщили.

Еще раз хочу напомнить, что рассматриваю локальную сеть пользователей с разными проектами.
Одной директорией вмещающей все external неверняка дело не ограничится. Будет их много.
И все превратится в абсурд. То что вы называете 'штатные средства' я и называю лишними телодвижениями, увеличением объема рутины.

Для таких вещей есть файл сервер.
Total Commander идеально для этого подходит.




Чтобы так делать вам надо SVN использовать просто как оперативный backup.
Получите нескончаемую череду версий, в которой невозможно будет что либо найти.
Сравнение, кстати, у SVN ужасно сделано по сравнению с Total.

В предыдущем посте имел в виду TortoiseSVN. Git использую сравнительно недавно и только для программерских проектов, а SVN использую уже не помню сколько лет (больше 10 точно). SVN очень хороша для своей модели (центральный реп) и, имхо, для хранения файлов типа электрических схем, печатных плат подходит лучше, чем Git.

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

Блин, опять я что-ли всех запутал?

В общем насчет externals, и моей идеи.
Все проекты находятся в одном репозитарии на сервере. У каждого проекта есть свой trunk и тэги.
Я хочу опять же в репозитарии, но не привязываясь к конкретному проекту, создать папочку all_models, и в ее свойствах прописать externals к нужным папкам из разных проектов.
Затем ссылку на папку all_models я даю заинтересованным пользователям и они делают чекаут на свои локальные компы. Если я добавляю новый проект, то мне достаточно на сервере изменить свойства папки один раз и пользователи, сделав апдейт, получат себе новые файлы. Таким образом пользователям не нужно заморачиваться со свойствами.

ПС. Ессно то же самое я могу сделать, сделав чекаут папки all_models, изменив ее свойства в рабочей копии и сделав коммит.

Так понятно? Или я что-то делаю не так?

Без разницы, где вы эту папку создадите - на сервере или в РК. На сервере - это надо лезть repo browser, и каждая ошибка фиксируется, в общем, не очень штатно и не удобно. Штатный способ - в РК. После коммита эта папка окажется в репе.

Все действия сводятся к:

1. Создать папку.
2. Создать у этой папки свойства (property) типа svn:externals, у каждого свойства указать пару <название папки> <путь до папки в репе>. Сделать svn commit.
3. При необходимости изменить список этих папок нужно просто добавить/удалить/изменить свойства папки с externals.

Пользователям ничего, кроме checkout и update делать не надо, про свойства им тоже даже знать не надо.

И опять запутали.
На сервере (т.е. локально сидя у этого физического сервера или через TeamViewer) 'папочку' можно сделать только в уже готовом репозитарии. Либо делать новый репозитарий. Т.е. отдельно стоящую 'папочку' не сделать.
Если на самом физическом сервере залезть в директорию где он хранит данные, то не увидите никаких привычных 'папочек'.
Визуальная оболочка VisualSVN тоже особых инструментов не предлагает.

Т.е. все что можно делать если не использовать скрипты, то только конфигурировать полученные после операции checkout директории на компьютере одного из клиентов.
Хотя конечно клиент (TurtioseSVN) может быть и на самом компьютере сервера.
Я так и делаю кстати.
Поскольку SVN невыносимо медленно работает даже на 2 Mbit линиях, я просто на флешке переношу на сервер импортируемые проекты.
Импортирую их там в репозитарий сервера (это будет localhost), там же делаю checkout с сервера обратно в новую локальную директорию на том же физическом компьютере и снова на флешке полученную директорию отношу на рабочий комп.
Там уже ей с помощью меню TurtoiseSVN делаю relocation. Т.е. меняю путь от директории к репозиторию с локального на удаленный домен.

Вот такая дискотека. Все ради науки.

Я имел ввиду через Repo Browser в TortoiseSVN - тогда не надо возле сервера сидеть.


Вы пробовали wordoвский документ открывать на такой линии? Вот это дискач. А от SVN на медленных линиях я тащусь - закончил работу, с чувством глубокого удовлетворения запустил коммит и пошел чай пить/кушать/спать в зависимости от размера. И никаких беспокойств.

Ну да нагружаем SVN чем угодно, только не контролем собственно версий.

А применить стандартный backup по idle не судьба была?
Когда я был озабочен долговечными резервными копиями у меня на стриммер сливалось каждый раз когда я от стола на 5 мин отходил. Даже забывал о существовании бэкапа.