Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of ben@reser.org designates
 50.197.89.41 as permitted sender)
Message-ID: <52A91EE5.6040207@reser.org>
Date: Wed, 11 Dec 2013 18:26:45 -0800
From: Ben Reser <ben@reser.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:26.0) Gecko/20100101 Thunderbird/26.0
MIME-Version: 1.0
To: Les Mikesell <lesmikesell@gmail.com>
CC: Bob Archer <Bob.Archer@amsi.com>,
 Mark Kneisler <mark.kneisler@tceq.texas.gov>,
 "Cooke, Mark" <mark.cooke@siemens.com>,
 "users@subversion.apache.org" <users@subversion.apache.org>
Subject: Re: Update-Only Checkout Enhancement
References: 
 <fe4db5e101bd4cd080e29b0e0e919ffb@DM2PR05MB797.namprd05.prod.outlook.com>
	<C07613594E445E4FBC779F202BC59EA03DC2C1FC96@DEMCHP99E84MSX.ww902.siemens.net>
	<6dd4da1c7e5f4a088f2dab506d14d907@DM2PR05MB797.namprd05.prod.outlook.com>
	<EA9A16E4E64F694BAD262610B0A2515C236E81CE@USALWEXMBX2.infor.com>
	<CAOAgVpxsLv0P1WVqf8LRsZN2ZbShMrq2E9F91qEd2YByhACD1g@mail.gmail.com>
	<52A8ADD8.2010900@reser.org>
 <CAOAgVpzCfb1fJrLqrS3yifUDcx3Cn8pFj_j2-r9N3=wZ-qyiBg@mail.gmail.com>
In-Reply-To: 
 <CAOAgVpzCfb1fJrLqrS3yifUDcx3Cn8pFj_j2-r9N3=wZ-qyiBg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 12/11/13 5:10 PM, Les Mikesell wrote:
> Not exactly.  Network traffic is generally bursty.  Clients rarely
> spend 100% of their time checking out files, so a very large number
> could share a local network even if they always deleted their
> workspaces and checked out fresh copies.  But when storing the
> pristine copies, they can't share anything - even if you map a shared
> network volume you don't want to share the workspaces.

Key phrase there local network.  When Subversion was written the vast majority
of the users were using it over a WAN.  This lead to the assumption that disk
space was cheaper than improving the network.  That's not necessarily
reflective of the use today, but it shaped the assumption that we would always
have pristines in the code that was written.

> Well, that's why programs have options - all situations are not the same...

Absolutely, the answer here isn't a one size fits all.  Nobody is objecting to
the idea of allowing this.  The problem is that the code is not designed to
allow this and it's a ton of work to change that.  I can think of a good 10
other things that would require the same level of effort that would improve
things for a lot more people

Once you no longer need a pristine there are a lot of potential scenarios that
require different behaviors.  So it's not even a simple matter of just changing
the working copy library to support pristines not existing.  It becomes
thinking about how to deal with these scenarios (not that all of them need to
be implemented immediately, but you probably want to not pigeon hole yourself
into an implementation that doesn't support them).

Some files don't delta very well and essentially change every bit when the file
changes, so those files update and commit are better off just transmitting full
text.  Some files do delta fine but are just large, if you change the file you
may want to run a diff and update/commit would benefit from deltas.

If you have a file that deltas well should you download the full text from the
server and produce a delta locally or just send the full text to the server?
The answer to this depends on the network.  If you're on a asymmetric
connection where upload or download or different whichever method that sends
the largest data over the fastest direction is better (e.g. a typical DSL or
Cable internet connection where download is faster it may be far better to
download full text and upload the delta you calculate).  If you're on a
symmetric network you just do whichever takes the least work (directly
sending/retrieving full text).  Due to laptops that came move between networks
you also can't just configure the file on the server side (i.e. set a property).

What about compressing the file.  If it compresses well then you could have
your cake and eat it too...  You save disk space and you still have the pristine.

The user may want us to retain the pristine data we retrieved to execute a
command or they may just want us to destroy it immediately to limit disk space.

For that matter the pristine store as of 1.7 doesn't even remove files.  So if
you're updating a working copy it will just continue to grow.  As of 1.8 we use
this to allow faster updates when you already have a copy of a version of a
file in the pristine store.  So we need some sort of "garbage collector" for
the pristine store even for the setup that has it:
http://subversion.tigris.org/issues/show_bug.cgi?id=4071

So all in all it's not a matter of throwing a simple option in and being done
with it.  I realize that your particular use case is probably one of the
simpler ones to deal with.  But it's by far the least common use case that we
hear complaints about with respect to the pristine store.

Please realize that considerable thought has gone into this.  It's just not
done yet.