Why I don't use svn

koly

Вот статья, расположенная на http://www.cs.bris.ac.uk/~henkm/svn.html.
Я солидарен с автором как очередной пострадавший...

Why I don't use svn
Update, May 2005: The following is a little esay I wrote to blow some steam off in June 2004, when I used subversion for a while. Apparently it contains bad language -- please do not read on if you are easily offended. Please note that since that date, subversion has changed beyond belief and is now perfect.
Subversion is a version control system. Like CVS. It is designed as a successor to CVS, improving the functionality, speed, without losing the elegance and simplicity of CVS. Subversion has indeed the features that CVS is lacking, you can move files, and you can easily tag releases. It is also blindingly fast, and it has used the same update/commit approach that CVS uses. So far so good.
The reason I am no longer touching it with a bargepole is the implementation. svn has been implemented using Berkeley databases. Presumably because they are fast and efficient. All releases of all files are stored in a single database. This is fine, efficient, and everything else, until your database gets corrupted. At that stage you are up to your chin in shit.
The database is easily corrupted. In my case I added some memory to a machine, without knowing that the memory was flaky. The machine still worked, with the odd crash. Took the memory out again and the machine was stable again. At that stage I went to my client machine, and typed the usual command to commit some changes that I had made.
svn commit
The answer that comes back is 'Network connection unexpectedly closed'. I did the sensible thing, and went to Google to find out why svn would say something like this. Shock, horror, the web did not have an answer, other than people asking the question 'What does this error mean', only to get an answer 'Have you read Section X.Y of the subversion book'. Not helpful because the subversion book doesn't tell you either... So in a moment of desperation I started a server by hand, and hung an strace on it, the final dying moment of the process is a SIGABRT, just after it opens the database files.
By now several horror stories of corrupt databases that I have seen on the web come to my mind. Indeed, searching for 'corrupt svn' gives some answers. In particular, it is recommended to recover your subversion archive:
svnadmin recover
One is warned that this command may take several minutes to complete, but in my case the answer came within a second: it said that my database was corrupted. That was not the answer I was waiting for, I asked svn to recover, not to tell me that it was broken. I went back to the web for help, and there are now many pages that contain the answer:
"This is not subversion's fault, it is the database that is corrupt"
Three things come to mind: this statement is true, not very helpful, and the shit is deeper than I thought. The advice is now to recover the database rather than subversion:
db_recover
This program is also extremely fast in analysing the problem. It told me that there was an 'Error in log file'. It does not recover anything... In a desperate move I decided to remove the log files, and to my surprise everything recovers, db_recover works, svnadmin recover works, until you do anything with svn, whereupon you are back to square one. In short, all your previous releases are gone. What you are left with is what you have checked out.
The moral of this story
Do not use binary file formats unless you can decode them and repair them. It is the same old argument of ms-word vs latex. Of course latex is archaic, but if latex crashes I still have my source, once my word file is corrupted, that is the end of the story.
I am back to CVS. When there is a problem, whether caused by flaky memory, an unreliable hard-disk, or a programming error, I know that part of the repository will be corrupted. I know that one include file down there will contain a block of all zeroes. I know that half my files may be committed, and the other half isn't. But when shit happens (and shit happens) I will be able to repair it using, vi or emacs...
Subversion is a wonderful design, but the implementation has strayed too far away from things that we can understand.
For lots of fuming reactions see SlashDot, where some anonymous person (not me) posted a reference to this page. Apparently I am an idiot, I am glad I made your day!

Hastya

Поставил плохую память на машину, испортил базу.
При чем тут SVN?
особенно насмешило
>elegance and simplicity of CVS

koly

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

Hastya

безопасность чего?
CVS безопасна?
бэкапы надо делать?

stat7984215

Нефиг использовать Berkeley DB - в Subversion Book же написано, что у нее есть большие проблемы с надежностью. К тому же FSFS удобнее в использовании, да и в случае чего репозиторий на ней восстановить наверно проще будет.

в системе контроля версий безопасность - это первый приоритет

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

pilot

Why I don't use SVN:
SVN просто плохо написана. Плохой код.
Плохой код ведет к ошибкам.

SPARTAK3959

Пока что Berkeley DB у меня всегда recover'илась (в основном необходимость в этом возникала из-за неправильных прав доступа - то есть совершенно штатной ситуации). Бэкапы тоже есть, так что пользоваться svn я не боюсь.
К сожалению, восстанавливать FSFS вряд ли существенно проще - если она стоит на FAT и из-за выключения питания какая-нибудь ревизия в середине исчезнет, то вся информация станет не доступной. Зато диагностика и восстановление уцелевшей информации (что нужно автору статьи) в этом случае проще и понятнее.
Всем известный вывод - пользуйтесь надежными файловыми системами и делайте бэкапы перед изменением настроек/оборудования.

amkharchenko

А интересно, всякие берлиозы и эсэфы на чем держат svn? На fsfs?

shlyumper

на SF только CVS. и вапще, всем срочно покупать BitKeeper!

amkharchenko

Они же на sf.net хотят добавить чуть ли не с лета? Если не секрет, что хорошего в BitKeeper. Кроме того, что торвальдс его использует и у ему вроде нравится =)

ava3443

Насчёт торвальдса - у тебя устаревшие сведения. Bitkeeper давно уже для разработки ядра не используется.

amkharchenko

А че, ядра уже стали так часто качать, что уже BitTorrent понадобился?
К тому же я не говорю, что он используется. Я говорю, что Торвальдс его пеарил.

ava3443

сменили bitkeeper на git

ava3443

сорри, я конечно имел ввиду BitKeeper, а написал BitTorrent.

amkharchenko

Так это, батенька, называется оговорочки по Фрейду.

voronina

вставил память и репозиторий сдох

Memtest, badblocks уже отменили?

vijrel7878

i use svn every day and will be use it. Everything ok. The best of free version control system.

sergey_m

> на SF только CVS. и вапще, всем срочно покупать BitKeeper!
Вот ты пеаришь BitKeeper, а ты им пользовался? Или просто потому что он раньше с линуксом дружил и поэтому это круто?

shlyumper

я считаю сей тред говнотредом, и потому пишу сюда всякую лажу