(This is somewhat off-topic for python-dev, so I won't post more than = one message unless people really want me to) Martin v. L=F6wis wrote: > Fred L. Drake, Jr. wrote: > = >> (I'm really looking forward to Subversion 1.1; all the advantage of = >> Subversion, without the disadvantage of Berkeley DB...!) > = > = > What *is* the disadvantage of Berkeley DB that the file storage of > svn 1.1 will remove? One of the things that you could do in CVS that > you can't easily do because of the DB approach is to ultimately > remove a file, along with its entire history (by removing the ,v file). > Along with that goes the option of moving part of a repository into > another repository. Files are, by and large, big blobs of opaque bytes. They don't = belong in a database. The subversion developers made a mistake by = putting *everything* into bdbs. They should have put metadata into the = database and files into the filesystem. I doubt this is the = disadvantage perceived by the svn user community at large (they mostly = complain about umask problems), but it is the real problem with using = bdb in the way svn uses it. > [snip] > = > One problem that I had with svn+bsddb is that the DB files are > tied to a DB version, so you can't easily upgrade to a newer DB > version (without dump/load cycle). But This is half-true. You don't have to dump/load to move between = incompatible database versions, you just have to run the = sleepycat-supplied upgrade tool. Not to say that dump/load doesn't work... Jp
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4