I'll add something here, that's really simple:
file:// Only good for a single user, very fast and simple, no server
required.
(I believe it's ok to use file:// for multiple users, as
long as those
users are all on the same machine; no network file
shares.)
svn:// Very good, fast, simple server to install svnserve. Simplest
and fastest
way to enable network access. However, until 1.5 some
features are not
available. Assuming you want usernames (helps track
changes) then
passwords must be stored plain-text in a file. (Can
root
configure the file once, and assign blank passwords for
everyone?
I don't know.)
svn+ssh:// You really want to configure RSA keys for
auto-authentication. Rather
slow. But reliable and usable otherwise.
http:// Not as fast as svn://, but not unbearable. Very flexible in
terms of
authentication and access control. Installation is not
for the faint
of heart. The average new user would have a very hard
time figuring out
how to get this working the first time. But it's
necessary if you need
to grant permissions on the per-folder level, or
authenticate against
something other than plaintext. (Until 1.5, when
svnserve will be able
to authenticate flexibly.)
https:// Exactly the same as http:// but with ssl for added
security & complexity.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning_at_dell.com]
> Sent: Tuesday, February 26, 2008 1:59 PM
> To: andy.levy_at_gmail.com
> Cc: listman_at_burble.net; troy.bull_at_gmail.com;
> users_at_subversion.tigris.org
> Subject: Re: svn not atomic with file:/// access?
>
> >>>>> "Andy" == Andy Levy <andy.levy_at_gmail.com> writes:
>
> >> of course we'd like to use the most robust mechanism for
> access >> and of course we'd prefer it if users can't delete
> the repository >> but we're also trying to make Subversions
> performance palatable to >> our user-base, which is proving
> to be a challenge..
>
> Andy> As I said in my earlier response, safety should take
> priority Andy> over speed when talking about a system like
> Subversion. There Andy> is a tradeoff that has to be made,
> but IMHO that analysis Andy> shouldn't include leaving the
> door open to have the entire Andy> repository deleted by an
> errant keystroke on the part of any Andy> user.
>
> ... or messed up. Deletion of a whole repository is easy to detect.
> Grab a backup and you're back in business (minus some hours
> of work, of course).
>
> The nastier problem is a user error, or application/OS error,
> that scribbles on the repository in a non-obvious way. That
> might leave you with bad data, or a missing commit, or other
> issues. Depending on the specifics, it might go undetected
> for a long time. Perhaps long enough that you no longer have
> backups far enough back...
>
> I always use svn:// access for everything, for a repository
> that's well over 10 GB, the working directory tends to be several GB.
> Checkout is a bit of a wait, but you only do that a few times
> per year. The rest is quite acceptable. Worst case is about
> the same speed as CVS, best case is much faster (and
> functionaly vastly
> superior!)
>
> paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________
This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at netadmin_at_patni.com and delete this mail.
_____________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-28 21:59:12 CET