Я пытался решать подобную проблему, и как раз теми инструментами, которые описаны выше (просто удивительное совпадение), и тоже столкнулся с тем, что не существует нормального способа работать с odt в subversion. На самом деле возможность просматривать diff-ы в odt - это не самая большая проблема, и существуют утилиты, которые её решают. Значительно более серьезная проблема - это трехстороннее слияние документа (merging), когда делаешь svn up, и он тебе из трех документов (предыдущая версия, обновленная версия из репозитория, твоя версия) должен сделать что-то среднее.
Пытаясь по-всякому выкручиваться, я сначала попробовал использовать wiki или что-нибудь вики-подобное (типа markdown). Такой вариант довольно неплохо подходит для внутренней документации или для документов, которые не предъявляют серьезных требований к оформлению.
Мой случай как раз оказался не таким (оформление должно было быть ГОСТовским), поэтому я пока остановился на суровом варианте - использовать LaTeX. У него нет никаких проблем с diff-ами и системами управления версиями, но есть, конечно, другая серьезная проблема - с наскоку его не освоишь. Я в общем согласен, что заставлять верстать в LaTeX-е секретарш - это чересчур жестоко и малоперспективно, но вот когда речь идет о "студенческих нуждах", пожалуй, лучшего средства не найти.
Я не говорил, что это плохо. Всё зависит от того, с чьей позиции это рассматривать.
Для владельца сайта частое индексирование - признак того, что "яндекс его любит", а это, наверное, хорошо.
Для самого Яндекса тот факт, что он ходит на сайты чаще других, наверное, безразличен.
Для хостера, который размещает этот сайт, частое нашествие яндекса, как правило, безразлично. Но случаются исключения. Эти исключения - сайты горе-кодеров, которые даже не знают, как правильно расставлять индексы на базах, но которые, тем не менее, собрали на своих сайтов достаточное количество контента, так любимого всеми поисковиками.
И вот, когда случается очередной крупный апдейт базы на Яндексе, можно наблюдать такую картину: роботы Яндекса, обнаружив лакомый кусочек жирного контента, небольшими, по 2-3 бота, стайками, окружают несчастный сайт и начинают долбить его запросами с частотой, недоступной биологическому существу. Сайт, не ожидавший такой нагрузки (обычно такие сайты ориентируются на посещаемость 5-10 человек в сутки, и "летают" исключительно на localhost'е), начинает медленно умирать. Смерть его не тиха и печальна, а сопровождается огрушительным ревом запросов в MySQL: "Сделай мне select по декартовому произведению из 5 таблиц".
Глядя на рев десятка таких сайтов, администратор, ответственный за работоспособность сервера, понимает - вот он, апдейт!
Конечно, яндекс в этой ситуации не первый, кого нужно обвинять, однако почему-то никогда не наблюдал я, чтобы сайт таким же образом ложился под натиском роботов гугля или другого поисковика - они всегда ведут себя более этично по отношению к своим подопечным.
- пользователь отказывается от каких-либо претензий к создателям и владельцам сервиса;
- пользователь обязуется не иметь таких претензий в будущем.
Вообще от всех претензий отказывается? Представим себе ситуацию, что я зарегистрировался на сайте, а потом кто-нибудь из создателей или владельцев сервиса по стечению обстоятельств, выезжая со стоянки, помял свои автомобилем припаркованный мной самокат. Теперь я, повязанный соглашением на сайте, не имею права иметь претензии к этому человеку?
Предлагаю ознакомиться с соглашениями тех, кто на этом собаку съел. http://www.google.com/accounts/TOS
Хочется сделать небольшие, но, как мне кажется, полезные дополнения к способам передачи файлов
Если нужен защищенный способ передачи файлов, и не хочется отказываться от возможностей, предоставляемых svn, то можно воспользоваться доступом через svn+ssh. В этом случае клиент соединяется с сервером через SSH, запускает на серверной стороне svnserve, и теперь все данные между клиентом и сервером передаются по защищенному протоколу. Процесс аутентификации также перекладывается на плечи SSH-демона. Этот способ достаточно кратко (и мне кажется, даже чересчур кратко) описан в SVN book.
Кстати, через svn+ssh умеет работать и TortioseSVN, достаточно при инициализации репозитория вручную набрать протокол svn+ssh://user@host/full/path/to/repo/.
> Ставите svn, его транк является корнем www сервера. Т.е. при любом коммите мы тут же имеет новую версию на www.
Некоторые могут подумать, что имеется в виду "сделайте svn checkout своего проекта в корне сервера". Такая вещь крайне опасна, т.к. эта команда создает служебный каталог .svn с файлами text-base/FILENAME.svn-base, а вы ведь не хотите, чтобы исходники ваших скриптов были доступны любому желающему через веб... Для решения этой проблемы можно ограничивать доступ к каталогу .svn с помощью .htaccess или других средств веб-сервера, а ещё лучше хранить рабочую копию отдельно, а в корень www делать "svn export" по необходимости.
Хочется пожелать уважаемым здравым головам твердых лбов. Потому что, только имея достаточно твёрдый лоб, можно:
- решить проблемы с получением лицензии на телематические услуги;
- найти место в приличном дата-центре в Москве;
- не умереть в борьбе с DDoS-ом против одного клиента, который положит сразу весь сервер;
- обеспечить качественный сервис и техподдержку, когда количество клиентов перевалит даже за первую сотню ...
Ну, и конечно, нужно быть действительно очень хитрым, чтобы не стать "одним из". Судя по информации с http://hostobzor.ru/, только в одной Москве хостинг-провайдеров зарегистрировано больше сотни.
А "хостинг для гиков" - это, на мой взгляд, дело наживное и далеко не самое сложное в реализации.
> можно даже сказать, что Nero для Linux является аналогом проприетарного софта
Прочитал несколько раз. Наверное, всё-таки "Nero для Linux является аналогом свободного софта".
Сам с удовольствием пользуюсь k3b, никаких проблем с совместимостью и прочим не испытывал. Ещё у меня одно время был компьютер с CD-R приводом, но без иксов, я использовал cdrecord, и даже умудрялся файлы через webmin записывать.
Пытаясь по-всякому выкручиваться, я сначала попробовал использовать wiki или что-нибудь вики-подобное (типа markdown). Такой вариант довольно неплохо подходит для внутренней документации или для документов, которые не предъявляют серьезных требований к оформлению.
Мой случай как раз оказался не таким (оформление должно было быть ГОСТовским), поэтому я пока остановился на суровом варианте - использовать LaTeX. У него нет никаких проблем с diff-ами и системами управления версиями, но есть, конечно, другая серьезная проблема - с наскоку его не освоишь. Я в общем согласен, что заставлять верстать в LaTeX-е секретарш - это чересчур жестоко и малоперспективно, но вот когда речь идет о "студенческих нуждах", пожалуй, лучшего средства не найти.
Для владельца сайта частое индексирование - признак того, что "яндекс его любит", а это, наверное, хорошо.
Для самого Яндекса тот факт, что он ходит на сайты чаще других, наверное, безразличен.
Для хостера, который размещает этот сайт, частое нашествие яндекса, как правило, безразлично. Но случаются исключения. Эти исключения - сайты горе-кодеров, которые даже не знают, как правильно расставлять индексы на базах, но которые, тем не менее, собрали на своих сайтов достаточное количество контента, так любимого всеми поисковиками.
И вот, когда случается очередной крупный апдейт базы на Яндексе, можно наблюдать такую картину: роботы Яндекса, обнаружив лакомый кусочек жирного контента, небольшими, по 2-3 бота, стайками, окружают несчастный сайт и начинают долбить его запросами с частотой, недоступной биологическому существу. Сайт, не ожидавший такой нагрузки (обычно такие сайты ориентируются на посещаемость 5-10 человек в сутки, и "летают" исключительно на localhost'е), начинает медленно умирать. Смерть его не тиха и печальна, а сопровождается огрушительным ревом запросов в MySQL: "Сделай мне select по декартовому произведению из 5 таблиц".
Глядя на рев десятка таких сайтов, администратор, ответственный за работоспособность сервера, понимает - вот он, апдейт!
Конечно, яндекс в этой ситуации не первый, кого нужно обвинять, однако почему-то никогда не наблюдал я, чтобы сайт таким же образом ложился под натиском роботов гугля или другого поисковика - они всегда ведут себя более этично по отношению к своим подопечным.
Верно замечено, активность яндекса порой сравнима с активностью недорогой DDoS-атаки ;)
- пользователь отказывается от каких-либо претензий к создателям и владельцам сервиса;
- пользователь обязуется не иметь таких претензий в будущем.
Вообще от всех претензий отказывается? Представим себе ситуацию, что я зарегистрировался на сайте, а потом кто-нибудь из создателей или владельцев сервиса по стечению обстоятельств, выезжая со стоянки, помял свои автомобилем припаркованный мной самокат. Теперь я, повязанный соглашением на сайте, не имею права иметь претензии к этому человеку?
Предлагаю ознакомиться с соглашениями тех, кто на этом собаку съел. http://www.google.com/accounts/TOS
Если нужен защищенный способ передачи файлов, и не хочется отказываться от возможностей, предоставляемых svn, то можно воспользоваться доступом через svn+ssh. В этом случае клиент соединяется с сервером через SSH, запускает на серверной стороне svnserve, и теперь все данные между клиентом и сервером передаются по защищенному протоколу. Процесс аутентификации также перекладывается на плечи SSH-демона. Этот способ достаточно кратко (и мне кажется, даже чересчур кратко) описан в SVN book.
Кстати, через svn+ssh умеет работать и TortioseSVN, достаточно при инициализации репозитория вручную набрать протокол svn+ssh://user@host/full/path/to/repo/.
> Ставите svn, его транк является корнем www сервера. Т.е. при любом коммите мы тут же имеет новую версию на www.
Некоторые могут подумать, что имеется в виду "сделайте svn checkout своего проекта в корне сервера". Такая вещь крайне опасна, т.к. эта команда создает служебный каталог .svn с файлами text-base/FILENAME.svn-base, а вы ведь не хотите, чтобы исходники ваших скриптов были доступны любому желающему через веб... Для решения этой проблемы можно ограничивать доступ к каталогу .svn с помощью .htaccess или других средств веб-сервера, а ещё лучше хранить рабочую копию отдельно, а в корень www делать "svn export" по необходимости.
- решить проблемы с получением лицензии на телематические услуги;
- найти место в приличном дата-центре в Москве;
- не умереть в борьбе с DDoS-ом против одного клиента, который положит сразу весь сервер;
- обеспечить качественный сервис и техподдержку, когда количество клиентов перевалит даже за первую сотню ...
Ну, и конечно, нужно быть действительно очень хитрым, чтобы не стать "одним из". Судя по информации с http://hostobzor.ru/, только в одной Москве хостинг-провайдеров зарегистрировано больше сотни.
А "хостинг для гиков" - это, на мой взгляд, дело наживное и далеко не самое сложное в реализации.
Любовь к бетам - это любовь вопреки :) Используйте стабильные версии, если не уверены в своих чувствах.
Прочитал несколько раз. Наверное, всё-таки "Nero для Linux является аналогом свободного софта".
Сам с удовольствием пользуюсь k3b, никаких проблем с совместимостью и прочим не испытывал. Ещё у меня одно время был компьютер с CD-R приводом, но без иксов, я использовал cdrecord, и даже умудрялся файлы через webmin записывать.