Disk cache: Add base files for implementation of file format version 3.

Disk cache: Add base files for implementation of file format version 3.

This CL just copies files from version 2 and moves around code inside each file
or deletes function not used anymore.

It does NOT change the copied code in any way so it doesn't compile.

The purpose of this CL is to preserve revision history and allow future code reviews
to concentrate on actual code changes as opposed to code moving from one place to
another. In other words, in the future it will be easier to track how the code
changed versus the current code (version 2.1)

BUG=241277
TEST=none
R=gavinp@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=204358

[gavinp, 2013-05-16 14:12:40]

Great!

Is there a version that compiles you can upload in a separate CL, so I can see
that with its tests?

[rvargas (doing something else), 2013-05-16 17:25:12]

On 2013/05/16 14:12:40, gavinp wrote:
> Great!
> 
> Is there a version that compiles you can upload in a separate CL, so I can see
> that with its tests?

Sure, I just assumed that your filter would catch
https://codereview.chromium.org/15203004/ :)

[gavinp, 2013-05-17 14:34:27]

On 2013/05/16 17:25:12, rvargas wrote:
> On 2013/05/16 14:12:40, gavinp wrote:
> > Great!
> > 
> > Is there a version that compiles you can upload in a separate CL, so I can
see
> > that with its tests?
> 
> Sure, I just assumed that your filter would catch
> https://codereview.chromium.org/15203004/ :)

I am not aware of a mechanism to trace issues that have not had mail sent on
which I am not a reviewer.

Thanks for the link.

[rvargas (doing something else), 2013-05-17 17:38:01]

On 2013/05/17 14:34:27, gavinp wrote:
> On 2013/05/16 17:25:12, rvargas wrote:
> > On 2013/05/16 14:12:40, gavinp wrote:
> > > Great!
> > > 
> > > Is there a version that compiles you can upload in a separate CL, so I can
> see
> > > that with its tests?
> > 
> > Sure, I just assumed that your filter would catch
> > https://codereview.chromium.org/15203004/ :)
> 
> I am not aware of a mechanism to trace issues that have not had mail sent on
> which I am not a reviewer.
> 
> Thanks for the link.

In any case that was not intentional, I meant to send the link but when I
realized I had forgotten that step I thought the watch list would catch it... I
don't use watch lists so I just assumed...

[gavinp, 2013-05-17 17:39:32]

On 2013/05/17 17:38:01, rvargas wrote:
> On 2013/05/17 14:34:27, gavinp wrote:
> > On 2013/05/16 17:25:12, rvargas wrote:
> > > On 2013/05/16 14:12:40, gavinp wrote:
> > > > Great!
> > > > 
> > > > Is there a version that compiles you can upload in a separate CL, so I
can
> > see
> > > > that with its tests?
> > > 
> > > Sure, I just assumed that your filter would catch
> > > https://codereview.chromium.org/15203004/ :)
> > 
> > I am not aware of a mechanism to trace issues that have not had mail sent on
> > which I am not a reviewer.
> > 
> > Thanks for the link.
> 
> In any case that was not intentional, I meant to send the link but when I
> realized I had forgotten that step I thought the watch list would catch it...
I
> don't use watch lists so I just assumed...

No worries. It's going to take me a while to dig down into these; my first set
of responses will be a bit slow as I digest it, but hopefully I can improve
responses by then. My apologies for the slowness, it's a lot to look at.

[rvargas (doing something else), 2013-05-17 18:12:47]

> No worries. It's going to take me a while to dig down into these; my first set
> of responses will be a bit slow as I digest it, but hopefully I can improve
> responses by then. My apologies for the slowness, it's a lot to look at.

I was really hoping for this particular CL to be pretty simple... that's why I'm
explicitly not _changing_ a single line of code :( ... there's not much to
really review.

[rvargas (doing something else), 2013-05-24 21:28:12]

I sort of changed my mind: updating this CL when the tree changes is a real pain
so I would appreciate not having to do that again.

[rvargas (doing something else), 2013-05-30 18:25:19]

ping

[rvargas (doing something else), 2013-06-01 01:18:12]

And yet another refactor touching these files just landed.

I'm not happy at all :(

[gavinp, 2013-06-04 17:02:29]

This patch is not applying to trunk now.

https://codereview.chromium.org/14991008/diff/40001/net/disk_cache/v3/backend...
File net/disk_cache/v3/backend_impl_v3.cc (right):

https://codereview.chromium.org/14991008/diff/40001/net/disk_cache/v3/backend...
net/disk_cache/v3/backend_impl_v3.cc:509: EntryImpl*
BackendImpl::OpenEntryImpl(const std::string& key) {
No method by this name exists in the header; I know this isn't supposed to
compile, but this just causes me a lot of confusion. Why would we want the
header and body to disagree so radically?

[rvargas (doing something else), 2013-06-04 17:31:13]

Yes, I know it doesn't apply to trunk right now because I have to go through
another painful manual three-way merging.

I'm not going to do that before knowing that I'll be able to commit after doing
it.

From the point of view of a review, rebasing to TOT is relevant.

https://chromiumcodereview.appspot.com/14991008/diff/40001/net/disk_cache/v3/...
File net/disk_cache/v3/backend_impl_v3.cc (right):

https://chromiumcodereview.appspot.com/14991008/diff/40001/net/disk_cache/v3/...
net/disk_cache/v3/backend_impl_v3.cc:509: EntryImpl*
BackendImpl::OpenEntryImpl(const std::string& key) {
On 2013/06/04 17:02:30, gavinp wrote:
> No method by this name exists in the header; I know this isn't supposed to
> compile, but this just causes me a lot of confusion. Why would we want the
> header and body to disagree so radically?

Because otherwise I would be violating the premise of no code being modified by
this CL.

This method will obviously be renamed (and the signature modified), but the bulk
of the code (of this method) should be used to compare against the
implementation of the new method XXX::OpenEntry.

If I just leave BackendImpl::OpenEntry here (the one that appears on the
header), we'll have a trivial forwarding method instead of the one that actually
provides the implementation, so the whole point of starting from existing code
is lost.

[gavinp, 2013-06-05 14:18:16]

rubber stamp lgtm, since this doesn't affect any compiling code, and isn't at
trunk anyway.

I'll reserve review/comments for the implementation CLs that follow.

[rvargas (doing something else), 2013-06-05 23:29:22]

Committed patchset #5 manually as r204358 (presubmit successful).