Split FTP LIST parsing code into individual files for each listing style.

Split FTP LIST parsing code into individual files for each listing style.

This turns out to be much better code organisation strategy. We're going
to have even more parsers.

TEST=Covered by net_unittests.
BUG=25520
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=33807

[Paweł Hajdan Jr., 2009-12-03 18:40:33]

This patch just moves code around and doesn't change behavior.

I chose to change the name ordering a little, so that the directory listing
files appear together in the directory listing in a sane order. IMHO it's better
that way.

[wtc, 2009-12-03 19:10:28]

A quick comment first: our naming convention is to use
_win.cc instead of _windows.cc for Windows-only files.

[Paweł Hajdan Jr., 2009-12-03 19:38:29]

On 2009/12/03 19:10:28, wtc wrote:
> A quick comment first: our naming convention is to use
> _win.cc instead of _windows.cc for Windows-only files.

It's for all systems. It's a parser of Windows FTP LISTing style. :)

[wtc, 2009-12-03 21:37:42]

Ah, I see :-)

[Paweł Hajdan Jr., 2009-12-04 07:47:54]

On 2009/12/03 21:37:42, wtc wrote:
> Ah, I see :-)

Good. Could you also review the code?

[eroman, 2009-12-04 08:59:00]

please, please, use "svn cp" to create these new files, so they preserve the
history from their old locations.

LGTM with comment above.

[Paweł Hajdan Jr., 2009-12-04 09:20:46]

On Fri, Dec 4, 2009 at 09:59, <eroman@chromium.org> wrote:

> please, please, use "svn cp" to create these new files, so they preserve
> the
> history from their old locations.
>

Oops. I used git with this change. These files do not have too long history,
most of them are still in their original version, and it's a bit harder (but
possible) to get to the history. Can I commit with git?

I can use svn checkout (but I don't have any now), but this would take me a
long time. git is so much convenient...

[eroman, 2009-12-04 09:39:35]

I don't know enough about git to advise on a workaround; Evan or someone on
#chromium might now.

I can grudgingly live with this being committed as an add if it is really that
much trouble.

But in general I think it is bad practice to move files without preserving their
sv history, since it makes understanding what happened to a file using svn more
painful.

still LGTM.

[wtc, 2009-12-08 01:46:41]

Pawel,

Perhaps you can keep an svn tree around for the changelists
that need svn cp.  You can still use git and go through the
code reviews as usual.  But before you commit, regenerate
a CL using "svn cp".