The code produced is here:

http://www.bitbucket.org/frechtenstein/partial-soc/overview/

Knows anybody more about Frederic's work in GSoC ? Peter Arrenbrecht
asked about implementation details at 12th of July on the  mercurial-devel list.

Just to add my two cents to the plea here's my use case.
Given the high usage of open source libraries in my job it happens quite often
to have to look to the some part of the source of them just to clarify their
usage or simply to borrow some implementation ideas.
Recently i was evaluating Netbeans and i needed to look to the j2ee.jboss4
source to see if i could expand that plugin for our needs.
Given that the downloadable source zip is corrupted (it contains all the project
directories but only a very small number of source files) i had to resort to
download from the mercurial repository.

Well i only needed to look into j2ee.jboss directory, downloadable size 1.04 MB,
size on disk 1.39 MB, no need to compile it or the whole Netbeans project, but
nonetheless  i had to clone the WHOLE Netbeans source, downloadable size 1.35
GB, size on disk 1.74 MB, about 6 hours of download time. 
Almost 1300% increase in size, download time, bandwidth occupation respect to
what would be needed if partial cloning was available, and bandwidth doesn't
come for free. :(

IMO this together with issue883 are serious show stoppers that don't allow
Mercurial to spread as it would deserve.

Thomas wrote:
"Regarding FreeBSD: How big are changelog and manifest compared to the
other data in .hg?"

I don't have a full history conversion locally anymore, but I can clone one
of the converted branches of Ollivier Robert.  A partial history, starting from
an import of a src-tree snapshot on Thu Feb 21 23:29:26 2008 +0000 now
has a little over 400 changesets, and .hg/store/ includes:

keramida@kobe:/home/keramida/hg/freebsd/head/.hg/store$ ls -l
total 1556
-rw-rw-r--   1 keramida  users  -  274900 Mar  8 21:23 00changelog.d
-rw-rw-r--   1 keramida  users  -   23360 Mar  8 21:23 00changelog.i
-rw-rw-r--   1 keramida  users  - 1218894 Mar  8 21:23 00manifest.d
-rw-rw-r--   1 keramida  users  -   23360 Mar  8 21:23 00manifest.i
drwxrwxr-x  23 keramida  users  -    1024 Feb 22 20:07 data
-rw-rw-r--   1 keramida  users  -     229 Mar  8 21:23 undo
keramida@kobe:/home/keramida/hg/freebsd/head/.hg/store$

Just wanted to chime in and state that this is the only thing keeping me from
migrating over to Mercurial as well.

I just cannot believe that this issue has been around for 2 years and given such
low priority and importance.

Sure, partial clones/checkouts would be nice to have, but maybe helauer's
problem can be solved without them.

Regarding FreeBSD: How big are changelog and manifest compared to the other data
in .hg?

forest is a bit nice, but it isn't the same as partial checkouts.

The developers who work with the src/ tree of FreeBSD are very fond
of having a single place for src/ work, but being unable to check out
only the kernel source src/sys is one of the points they dislike about
Mercurial :-/

On the other hand, splitting the history in a multitude of repositories
is considered a bad idea.  It is nice to be able to check out by specifying
only _one_ changeset ID, instead of a forest of IDs :)

helauer, did you look at the forest extension?

Adding myself to the nosy list. Partial checkout are common at our site and
preventing the switch to mercurial. A intermediate improvement would be to have
options to follow links to separated out subdirectories (to allow for different
needed access rights), but that's only a workaround.

adjusted title and added nosy from issue515

Add myself to the nosy list.  Partial checkouts are one of the features
requested again and again by FreeBSD people, even to the point of
being a show-stopper for adapting Mercurial for a single FreeBSD src/ tree.

This is also discussed here:
http://www.selenic.com/mercurial/wiki/index.cgi/PartialClone

I would like to second what sandeepss said. 
Where I work we have 80Gb in each full branch on the central server and
developers create local sub-copies usually about 4Gb or so on their machines.
Usually there are about half-dozen of those cub-copies some in different branches.

There is no way people will go for 20 times increase in network delay or disk size.

Most of the data in the repository is tests and test data. We keep those
transactionally consistent with the source code across all branches (i.e. tests
and code always change together) because it makes sense. As a result everything
ends up in one repository.

I am really surprised that neither mercurial nor git support this. It seems like
 a very fundamental feature for me coming from perforce.

Please consider why this could be extremely useful.
Typically,  for a sufficiently large codebase, we have a humongous testsuite - broken down by 
components.

To add/update testcases in the CVS world is relatively easy - just COPY over the parent directory 
(with the "CVS" directories contained in it) from somewhere that the directory is visible ; make ur 
changes; add and commit. 
It is this behavior that is highly desirable - checking out codebases wont kill you, checking out entire 
test repositories will

1. hg co should support partial checkout (think -X and -I),
   to really save space.
2. hg revert should respect partial checkout, and ignore
   manually deleted files by default.
3. another term to replace 'Deleted'?

For having repositories with partial checkouts (to save space):
hg co (without -C) shouldn't restore manually deleted files.
hg ci (without -A) should treat them as unmodified
hg co -m probably has to abort in case a deleted file should be merged

anything else?