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

RE: Tags and scalability (was Re: Enlightenment)

From: Kean Johnston <jkj_at_caldera.com>
Date: 2002-09-25 04:10:41 CEST

> Kean, I fear you don't understand how subversion's "cheap
> copies" work at all. You need to read our Design document,
> in our file-sharing area of the website.
You are absolutely correct, I don't understand it but I will
read the aforementioned doc. Thanks for the pointer.

> You're describing the exact same idea here -- the "cheap
> copy" -- just reinvented in a slightly different way. :-)
Hehe ... I guess that "proves" the validity of your original
design then if the "obvious" solution matches whats already
there. I'll be honest though, from a conceptual point of
view ONLY, the notion that symbolic tags are something
integral to the system as opposed to a user convention, just
makes more sense to me. Maybe my brain is wired more strangely
than previous evidence indicates :)

> Really, our rationale (two years ago) was that disk space grows FAR
> faster and cheaper than network bandwidth. So when given a
> choice, we chose to optimize for the network. Having cached copies is

> nice from a network standpoint: you can view and revert your changes
> without the network, and the client can send small diffs during
That last part is a good point. As for the price of disk versus
bandwidth, I guess that's a valid argument too. But in general,
my experience has told me that that kind of decision can come back
to bite you, usually 5 years down the line when things are so
entrenched that its almost impossible to deal with. Unless there is
a compelling systematic reason why duplicates should ALWAYS exist,
its just good practice to make their presense optional without
causing systemic meltdown.

If I can contribute coding cycles and work with Greg and the rest of
this list o hash out a design to MAKE theser things optional, is
there any reason to wait for after 1.0 if we could get it in before?
I don't know your intended release schedule and its dinner time so
I wont go searching :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 25 04:26:39 2002

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

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