Re: [Fwd: [arch-users] Re: Gud lord!]

[Juanma Barranquero]

On Tue, 10 Jun 2003 16:16:17 -0400
Miles Bader <address@hidden> wrote:

> Well, no it's not.  If writing tools to get at the data is hard or risky then
> things still suck, no matter how well documented the format is.

Yeah, sure. But "binary repository" does not necessarily imply "getting
the data is hard or risky".

> For many users, of course, it's the same either way, but one of the big
> attractions of CVS was exactly that what it does is quite understandable, and
> when all else failed, you could use emacs to edit the repository...

As I've said in another message, what CVS does is not that
understandable for people with a non-Unix background (I think).

> Um, that's not exactly a comforting answer...
> 
> I'd rather have things _not get trashed_!

Yeah, but again: binary does not imply more fragile. What if you save
things compressed, but do two or three copies? I mean, if I were
implementing a "binary virtual filesystem" for source control, I'd do my
best to make the thing reliable against catastrophes... I'd expect the
same from actual source control developers.

Database systems like Oracle do save their data in binary, proprietary
formats, and in my experience you don't lose data often with Oracle.
Perhaps I've been fortunate ;)

> Failing that, I'd like the damage to be limited, and recoverable, and the
> more I can do this without using special tools, the better (special tools are
> great when they work of course, but ...).

I agree. Of course I'd rather have the data in clear text, easy to
access, than in binary formats. But if binary is going to buy me other
commodities, I'm willing to trust the developers (after a few
months/years of testing, of course ;)

All in all, I have a slight preference for Subversion, but any system
that works reliably, it's faster than CVS and improves on its worst
"features" is fine by me (when the time is ripe).

                                                                Juanma