silverdr_at_inet.com.pl
Date: 2007-01-13 16:12:47
On 2007-01-12, at 22:38, Spiro Trikaliotis wrote:
> BTW: Regarding the number of bugs which corrupt the Berkeley DB,
Is that SO bad?! This format is in quite heavy use for ages now,
especially in the BSD derivatives. How would it survive that long
being so buggy as you suggest? I am asking, not challenging...
> I don't
> think it is advisable to not keep many backups. THIS is my main
> concern
> with SVN.
Well, you don't have to go with Berkeley DB if that's your problem.
SVN allows different backends these days.
>>> Personally, I do not like binary formats (as SVN uses it) very
>>> much, not
>>> to speak about databases. ;) If something goes wrong (mostly user
>>> error), if it is really needed, I can edit the CVS repository by
>>> hand -
>>> I have done this more than once, especially when I started using
>>> CVS.
>>
>> Me too. With Subversion fsfs, you can just delete the two new
>> files per
>> revision and tweak the third file (it's plain text).
>
> But the two new files are binary, aren't they? I must admit I never
> used
> fsfs myself, only Berkeley DB. In fact, most people I spoke about tell
> me that Berkeley DB is the best solution. Is this wrong?
It's been the most widely used for some time. Recent tendencies are
for FSFS
[...]
> I never said SVN does not have its own advantages. I like the
> atomicity,
> too. I also like the possibilities with renamend and removing files. I
> don't mind the "Attic/" directories in the repository, they don't
> do any
> harm.
They are PITA for purists ;-)
What I still dislike in SVN, even after some time of getting used to
it, is the revision numbering per _repository_ rather than per
project. I prefer not to maintain a growing number of repositories
while it's still confusing for many (especially new to SVN) people
when they encounter xteen revisions of difference between their last
commit and the current state, all e.g. with no apparent changes to
their project contents.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.