[zltigo 2]

Зачем? У меня же есть бэкап.

Мое предостережение делать бэкапы Вы назвали "пугать". Сами делаете. Почему это я тогда пугаю?

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

А вообще сталкиваться приходилось. В зависимости от того, как именно упало, часть ревизий доступно, часть - нет. Что-то вытаскивается.

Аналогично.

Я вас умоляю! Это Release Candidate перед большим выпуском новой версии.

Ну зачем-самого себя обманывать :(. Возьмите НЕ Release Candidate. Там список не меньше.

Я просто первый по ссылке взял.

Вменяемые люди устанавливают стабильную версию

Ага, это удобно, но тогда Ваше утверждение, что все хорошо, по причне того, что тысячи людей тестировали превращается в утверждение, что тестировали каке-то невменяемые :) :) :) Шутка.

[AHTOXA 18]

Зачем? У меня же есть бэкап.

А вообще сталкиваться приходилось. В зависимости от того, как именно упало, часть ревизий доступно, часть - нет. Что-то вытаскивается.

В этом смысле хороши распределённые системы контроля версий. У каждого - полная копия репозитория.

[zltigo 2]

В этом смысле хороши распределённые системы контроля версий. У каждого - полная копия репозитория.

"Полные копии" создаваемые автоматически средствами самой системы не застрахованы от того, от того, что при таком дублировании дублируется уже поломаная информация.

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

 

[VCucumber 0]

Если Вы не знаете что в Дропбоксе все можно восстановить

видимо, не я один на те грабли наступил, поэтому уже можно

копию я искал на своём диске тоталом

 

то почему в Вашем незнании дропбокс виноват?

да виноват, своим непредсказуемым поведением

если бы я был разработчиком/постановщиком задачи, именно такого глюка не могло случиться в принципе

 

 

дропбоксе - никогда не тронет SVN

дропбокс - очень удобная штука если работаешь один на работе, дома или ещё чорте-где

если в команде - svn

мы работали в стартиме, когда ещё программеров всяких черепашек даже в проекте не было

тоже очень удобная штука, хотя может кто-то скажет, что слишком простая

в оставшихся случаях - rar, или zip по вкусу - два винта, четыре флешки и двд раз в месяц

 

[.crz 0]

Так у вас же не атомарный доступ ко времени происходит и возможны баги.

Запросили дату - вывели в файл, и тут же наступил новый день, а вы потом запрашиваете время и это время уже за следующую дату и в результате фигня.

На границе часа аналогично...

Согласен.

Баги не случались, так как использую только ____TIMESTAMP____

[AHTOXA 18]

"Полные копии" создаваемые автоматически средствами самой системы не застрахованы от того, от того, что при таком дублировании дублируется уже поломаная информация.

Полная копия (по крайней мере в git) делается с контролем целостности. Так что здесь мимо. Если я смог клонировать/обновить репозиторий, то он гарантированно цел.

[zltigo 2]

Полная копия (по крайней мере в git) делается с контролем целостности. Так что здесь мимо. Если я смог клонировать/обновить репозиторий, то он гарантированно цел.

В ОДНОПОЛЬЗОВАТЕЛЬСКОЙ системе/базе даных, когда пользователь гарантированно завершил работу, запустил проверку и скопировал - да без проблем. Только в этом случае НИКАКИХ принципиальных отличий от процедуры банального бэкапа нет.

 

 

[AHTOXA 18]

В ОДНОПОЛЬЗОВАТЕЛЬСКОЙ системе/базе даных, когда пользователь гарантированно завершил работу, запустил проверку и скопировал - да без проблем. Только в этом случае НИКАКИХ принципиальных отличий от процедуры банального бэкапа нет.

Вот вы же совсем ЕРУНДУ сейчас написали. Почитайте для начала о распределённых системах контроля версий, потом высказывайтесь капсом. Они специально заточены на то, чтобы отдавать каждому пользователю полную копию репозитория. Если бы при этом не были учтены многопользовательские тонкости, то системы просто не работали бы.

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

[zltigo 2]

Вот вы же совсем ЕРУНДУ сейчас написали. Почитайте для начала о распределённых системах контроля версий, потом высказывайтесь капсом. Они специально заточены на то, чтобы отдавать каждому пользователю полную копию репозитория. Если бы при этом не были учтены многопользовательские тонкости, то системы просто не работали бы.

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

 

 

[AHTOXA 18]

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

От повторения ерунда не перестаёт быть ерундой. Для начала прочитайте про разницу между "многопользовательская" и "распределённая".

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