----- Original Message -----
From: "Brian Mathis" <bmathis@directedge.com>
To: <users@subversion.tigris.org>
Sent: Thursday, March 04, 2004 21:40
Subject: bad access methods (was: 100% repeatable repo wedging)
[...]
> This brings me to the question of why are you using svn+ssh? Out of the
> 4 access methods you have to choose from, you've chosen (IMO), the 3rd
> most desirable one. They are, in order of desireability:
> 1. http
> 2. svnserve daemon
> 3. svn+ssh
> 4. file
not to forget https://
> The only time svn+ssh and file should be
> used is if the repo is for a single user project.
think about data/transfer security when using
svnserve without ssh.
> This isn't really aimed at you, but everyone using svn+ssh or file
> access methods :)
i think "apache 2" is a "monster application"
( setup, dependencies, memory usage, security issues )
and probably a lot of ppl do not want that extra overhead.
> It really makes no sense to me that you could have so many different
> ways to access the repo. If you look at any other multiuser database,
> they all have 1 frontend that is the interface to the disk files.
> Mysql, postgres, ldap, etc... Why is svn different?
sounds like 'comparing apples and pears' ;-)
svn is more like a filesystem/file manager, sql etc is a database.
and there are usually many ways to access a filesystem:
http, ftp, shell, ssh/shell, windows-explorer, konquerer, tortoise, ...
and i think svn offers the best functionality for all of them.
>
>
>
> Jarod Wilson wrote:
>
> >Hi all, first post, be gentle...
> >
> >A little history: I work for a mixed Windows and Linux shop (mostly
> >Windows). We've been using CVS for quite some time, but several
> >developers complain about its shortcoming, especially with the recent
> >restructuring of our source tree, which of course blew away all the
> >history on many files. Said developers are partial to Perforce, but we
> >are on a bit of a budget. I've done some homework, and Subversion looks
> >like the ticket for us.
> >
> >However, what looks good on paper isn't translating to production very
> >well. I've got Subversion 1.0 up and running from David Summer's rpms on
> >a Red Hat Linux 7.2 box (which is also our CVS server), with the
> >intention of using predominantly svn+ssh for access, since everyone
> >already has a shell account on the machine. I was able to import our
> >source tree just fine from the local machine after creating the repo,
> >check out, check in, etc. When we moved over to a Windows box using
> >TortoiseSVN, all hell broke loose. Basically, at least one in every two
> >actions taken resulted in db errors, with a message telling us to run
> >DB_RUNRECOVERY.
> >
> >Fast forward a bit, I nuked the repo, recreated it, then did an import
> >from a Windows box via TortoiseSVN. Everything looked fine. I even got
> >two machines set up, both checking in, checking out, diffing, repo
> >browsing, etc., simultaneously and everything (one box running Windows
> >2003 Server, one running Windows 2000 Pro). Excellent, I thought.
> >However, note that both machines were using my login. Then I went over
> >to another developer's machine, tried his login, and got db errors
> >(can't recall if they were immediate, or after a number of files had
> >been checked out). Running svnadmin recover on our repo isn't even
> >recovering it now. (I haven't tried using db_runrecovery directly yet).
> >
> >Now, I do have both a primary user and group defined for Subversion (u/g
> >svn/svn), and all developers are members of the svn group, so I don't
> >think I have any permissions issues, but I've been fighting this thing
> >for more than a week... I'm about to try a newer BerkeleyDB (4.2, versus
> >4.0 on our RHL7.2 machine) and Subversion on a Fedora Core 2 machine to
> >see if it is any better, but if anyone has any insight into what my
> >problem might be, I'd appreciate the help! I know everyone will REALLY
> >like Subversion over CVS, once we get it running in a stable fashion.
> >
> >TIA,
> >
> >
> >
>
> --
> Brian Mathis
> http://directedge.com/b/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 4 22:04:50 2004