From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2007-01-12 22:38:18
Hello,
* On Thu, Jan 11, 2007 at 10:20:00PM +0200 Marko Mäkelä wrote:
> Right, I wouldn't ever trust an unencrypted protocol (such as CVS pserver)
> for non-anonymous access either.
I wouldn't even trust pserver for anonymous access, as long as the
pserver CVS does not ly on a separate machine and operates on a
read-only copy of the repository.
Even the CVS developers themselves always stress the fact that pserver
was never designed to be used in the public. There was no attempt to try
to protect it against any break-ins. In fact, many of the developers
even discourage using it in intranets.
> > rsync does a very good job sync'ing CVS repositories, too.
>
> But if the transfer is aborted for some reason, you will end up having
> the remote copy in a severely inconsistent state.
Why should be in "severely inconsistent state"? Some files have been
updates, some not. Anyway, no single file is wrong (due to the working
of rsync). I can still get any revision that is on the file not rsync'ed
yet. Doing another rsync fixes the problem immediately.
> Also, in case the file system containing your master repository becomes
> corrupted for whatever reason, if you do "rsync -n" first to see what
> needs to be copied, with Subversion fsfs you'll get alerted if you see
> any changes to old files. With CVS, changes to old files are normal,
> and you would be less likely to notice this.
Well, yes, CVS stores tags in the files directly, thus, every file gets
changed when "cvs tag" is executed. Additionally, this is the reason why
tagging is so slow.
> So, you will have to preserve old backed-up versions of the CVS
> repository to be sure that nothing is corrupted.
Well, if you do not do keep backups, you have a problem anyways. Your
data should be worth it, isn't it?
BTW: Regarding the number of bugs which corrupt the Berkeley DB, I don't
think it is advisable to not keep many backups. THIS is my main concern
with SVN.
> > 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?
The bottomline: My arguments are all based on Berkeley DB.
> I find it great that Subversion commits are truly atomic. Also, you can
> rename and remove files and directories without having "Attic" directories
> appear all over the repository.
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.
You might want to have a look at the thread at
http://lists.gnu.org/archive/html/info-cvs/2006-10/msg00084.html.
> I switched from CVS (after almost 10 years of using it) to Subversion in
> late 2005, so I didn't have to deal with the potential horrors of the
> original BDB-backed Subversion. I know of one company that has all its
> documents and source code in a single Subversion fsfs repository, tens
> if not hundreds of thousands of revisions. And surprisingly, it works
> for them.
Of course, SVN is mature until now. Nevertheless, I believe CVS (*not*
CVSNT!) to be "more mature" than SVN. Somehow, I have more sympathy to
the CVS/RCS file format. (I used RCS "by hand" more than 10 years ago.)
Regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.