[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Sharing SVN-Repository between Linux/x86 and WinNT

From: Aaron Optimizer Digulla <digulla_at_hepe.com>
Date: 2003-12-08 22:02:38 CET

On Mon, Dec 08, 2003 at 09:06:46PM +0100, Branko ??ibej wrote:

> Aaron Optimizer Digulla wrote:
>
> >On Fri, Dec 05, 2003 at 12:17:47AM +0100, Branko ??ibej wrote:
> >
> >
> >
> >>>I've created a repository on a Memory stick under Linux and
> >>>then tried to checkout the contents on WinNT but I just
> >>>get the message that the DB is corrupt and that I must
> >>>use the DB utils to recover it.
> >>>
> >>>Isn't it possible to access the same repository from Windows
> >>>and Linux (for example via NFS or Samba)?
> >>>
> >>>Doesn't the DB store its files in binary mode?
> >>>
> >>>
> >>>
> >>>
> >>Binary mode has nothing to do with it. Berkeley DB databases can not be
> >>used on different platforms. You must use a portable dump format to move
> >>them, either using BDB's db_dump/db_load utils, or (for an SVN
> >>repository) our svnadmin dump/svnadmin load.
> >>
> >>
> >
> >:-( That's bad. Well, it seems that I have to resort to CVS then.
> >
> >
> What for? Won't svnserve work just fine?

Well, actually, the data is on a memory stick ... I could put the
repository on the web but on the Windows side, I'm behind a firewall...

> (By the way -- using the same CVS files from both Windows and Linux is
> likely to play merry hell with your data, because things _will_ break,
> except that CVS won't tell you about it until it's too late).

Can you be more precise, please? Most of my "data" is Java source (so
CR/LF is no problem) and the rest is stores as binary, anyway.

> >Or as my old boss said: "Most people who use a DB will find that it
> >causes more trouble than it solves." ;-)
> >
> That's a very simplistic view of life. Anyway, SVN developers aren't
> "most people." :-)
>
> >From my point of view, extending CVS would have been more simple.
> >
> Your point of view is somewhat suspect, since you haven't tried to
> implement Subversion's features on tup of CVS.

Well, the only feature which I would need is directory versioning.
I must admit that I like the idea of SVN but, well, for me, it
creates more problems than it solves right now (it's a hell to
compile because I would like to use the Python module on both Win
and Linux).

> > Especially when you look
> >at the list of dependencies (CVS: None. Subversion: Apache,
> >
> Apache is ot a dapandency

wel, you need apr, apr-util, neon. I guess there is a good reason
why you have copies of these in the sources ...

> >Is the "stale lock" bug (svn sometimes leaving a lock on the DB)
> >solved already? If it is: How many hours did you spend on this one?
> >
> Does it matter? How many hours do you think we'd spend on getting atomic
> commits into CVS? Yikes!

Well, does this matter? I mean how many developers actually *need* atomic
commits? Or to put this another way: How big a problem is this? When
I do an update and it breaks, I do another update. That's not much
effort.

> Show me one solution to CVS's server process leaving locks in the
> repository (apart from the "admin goes and removes the lock files by
> hand", or the next step, "cron removes CVS lock files").

Well, when something's wrong with CVS, I can use vi and rm to fix it.
When I started to use svn (0.23, I think), it corrupted the database
four times until I realized that I should not press Ctrl-C on Windows
while it does a checkout. That's bad.

From here, svn has many neat features (most of which are interesting
from a theoretical point of view) but it has some big flaws and the
biggest of them is the stability of the data underneath. I mean:
The whole point of all this is that it should be impossible to
loose data.

I would like to really urge you to put more energy into making sure
that, no matter what happens, all data can be rescued (which probably
means to duplicate everything into the logs and when the logs have
been written to disk, to update the actual tables). As it is,
I'm too uneasy to trust svn with valuable data.

Oh, and a portable DB would be nice, too. It's not always possible to
setup a server but you almost always have file sharing.

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits." 
http://www.philmann-dark.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 8 22:23:17 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.