[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] cvs, servers and stuff.

On Monday, 14 August 2006, at 13:42:19 (+0900),
Carsten Haitzler wrote:

> yeah - though that might be harder than we think. the other problem
> here is consistency - we want a user using the 1 server once they
> started as if anon servers don't update at the same time - they will
> have problems with consistency.

Not necessarily.  A nice lengthy TTL on the records (say, 12 hours?)
will make sure they get the same mirror, at least throughout any given
day.  The problems we'd face really wouldn't be any different from any
other set of mirrors.

> having a faster/lighter/easier access method (svn? who has something
> to say? i prefer the "devil you know" but since this problem keeps
> coming up... time to bit the bullet?)

What it's telling us is that any single server is going to have its
ass handed to it by E anoncvs users.  I don't think replacing one with
another is the solution, SCM system notwithstanding.

> this was kind of part of what i was getting to - to make sure that
> we dont tread on your feet any more - move to our own box - and yes
> - anoncvs mirrors will be good - but maybe using svn in the end will
> make this easier.  i am broaching the topic to start just this
> discussion. i am not set on a path at all - but if we are causing
> pain - we need to address it.

Honestly, it hasn't affected us really at all.  We're more concerned
about the users....

> checkouts from svn are just ridiculous. agreed. but its the server
> side i am asking about. as i said - i HEARD it is easier on the
> server - i am after details from those having been there, done that.

I have not run an anon SVN server, so I can't speak to that point.  I
can only say that it makes no sense that a standalone, dedicated
server like cvs would have less overhead than Apache, which we all
know is a web server, a shared filesystem server, an embedded language
engine, a proxy server, an authentication and authorization system,
...need I go on?  :-)

> yeah - bdb - oh yay. lets break format all the time.. ;)

If you think BDB was bad, Subversion is just as bad.  Upgrading from
one version of svn-server to another can often involve a change of
repository format, in which case the ONLY migration path is the

1.  Use the old version of the server to create a "dump" of the
    repository.  You must remember to do this BEFORE upgrading, or
    pray that you have a static copy around.  I speak from experience
    when I say this gets nasty.  To say nothing of what happens when
    the dump fails....
2.  Upgrade SVN.
3.  Load the repository from the dump file, creating each revision
    from scratch based on the file data.  This takes an amount of time
    directly proportional to the number of revisions and the
    complexity of each changeset.  Again, you just have to hope it
    doesn't fail.

But that's a bit off-topic....  I don't have actual data for you, but
I can't imagine how CVS would be harder on the server than SVN....

> agreed - unless svn is less overhead. that is the question. an svn
> anon server serving 1000 users - and then an cvs anon server serving
> the same src and the same people - which one consumes less disk
> io/cpu/memory? thats what i want to know - and if it is less - is it
> significantly less? or just like 5% (not worth worrying about)

I was speaking to Inc the other night, and he (more or less) offered
an SVN mirror if we were interested.  I said we would be interested in
any mirror that could sync off the CVS server and help share some of
the burden, SVN included.  If he's still willing to follow through on
that, it might be a good opportunity to compare the two.

On Sunday, 13 August 2006, at 23:49:06 (-0500),
brian.mattern@gmail.com wrote:

> There are tools to move from cvs to
> svn. E.g. http://cvs2svn.tigris.org/ I've never used one, so I can't
> vouch for them, but it seems like it would be a fairly
> straightforward operation.

"Seems" and "is" are entirely different.  You'd think doing a
repository dump would be a "fairly straightforward operation" too, but
I've had that choke on me too.

> The main thing that SVN has that won me over is the ability to do
> diffs without hitting the server. I generally check diffs a LOT
> before checking in. With CVS this is a slow pita. I also find svn
> log more useful than cvs log. But that's probably just familiarity.

It's quite easy to check out a parallel tree or do an export and
generate local diffs from that.  With CVS, you have the option of
equipping yourself to do local diffs or using the server.  With SVN,
you have no choice at all.

On Monday, 14 August 2006, at 12:20:09 (+0200),
Stephan Wezel wrote:

> That's not true that SVN needs lot more overhead. At least if you
> compile subversion from source you can disable unneeded features

This is an interesting point.  Has anyone ever tried building a
version of CVS which could do anoncvs but nothing else?  No commits?
That might have an interesting impact on the overhead question.

On Monday, 14 August 2006, at 15:29:28 (+0300),
Eugen Minciu wrote:

> Now I know this is probably not going to sound right but how about a
> git repository?.

git is quite compelling, actually.  Subversion's chief "advantage" is
also its Achilles heel:  Just like CVS, it lacks fundamental
capabilities of distributed development.  git is basically a GPL
implementation of the key design concepts of BitKeeper.  I think it
has a lot more to offer over CVS than SVN.

On Monday, 14 August 2006, at 10:30:51 (-0500),
Sthithaprajna Garapaty wrote:

> The reason I wanted to go the CVS way was so that we could avoid the
> importing hell you generally go through when switching systems (both
> on the server side and the client side).

The only reason to switch that we're looking at right now is to solve
the load issue.  I think raster's made it pretty clear that the focus
of this discussion is how to best utilize server resources, not what
everyone's favorite SCM system is.  I'm definitely going to look at
DCVS, but I don't think it's applicable to the topic at hand.

On Monday, 14 August 2006, at 23:51:19 (+0100),
Shish wrote:

> I've only ever used Apache + mod_svn myself though.

Exactly.  Have you met anyone who uses SVN without Apache?  Neither
have I.

> Even if you do go the apache + mod_svn route, since when was apache
> known for being bloated and slow?

Since about 1.2, I think.

> I've found tagging much cleaner, and you don't need to check anything
> out at all:
> svn cp http://server/project/trunk http://server/project/tags/0.4.2

FUD.  You can tag CVS without having a checkout.  (Try cvs -H rtag.)
And SVN doesn't even HAVE tagging.  It has copying, which contrary to
popular (SVN developer) belief, is NOT the same thing.  A (non-branch)
tag is a symbolic name assigned to a particular state of the
repository (i.e., a changeset).  It is not a copy.

But again, this is all moot.  I'm sure there are numerous people who
would love to argue with me till doomsday about how great and
wonderful Subversion is; many others have already tried.  It does
absolutely NOTHING to address the question at hand:  Is anonymous SVN
easier on the server than anonymous cvs?

> Unfortunately for the topic at hand, the only thing I can't say for
> certain is "SVN is better at dealing with server-killing loads caused
> by vast numbers of anon checkouts".

While this comment would certainly be relevant, your subsequent
comments lead me to believe you don't have the evidence to back it
up.  We're talking about significant numbers of checkouts (i.e.,
apples), and you're talking about web browsing (oranges).


Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@kainx.org>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
 "The breakup was mutual, but it was more mutual on my part."
                                                        -- Beth O'Hara