SVN & DVCS workflow - preserving history

Is it possible to create streamlined workflow using both VCS (preferably SVN) and DVCS (preferably Mercurial or Git)?

Following facts describe desired workflow:

There is one central VCS server.
Main development happens on central server.
Anyone outside core development team (let's name him Joe) could take a snapshot of source code with complete history.
Joe would like to develop a feature in his own branch.
Joe doesn't have write permission to VCS, so
He's developing locally and committing to his own DVCS repo.
When he's finished he contacts main repo admin to merge his work into central.

And here comes the tricky part: Can his work be merged into central repo preserving it's history? So that the main development team could track Joe's individual commits?

I'd like to learn anything, that could point me in the right direction. If the workflow is not impossible to implement than feel free to throw a link to a tutorial. If you already have any experience with VCS-DVCS workflow than please share it. If it's not possible to implement it than the information why is also of great value to me.

I'm aware that the question may seem similar to others (such as vcs or dvcs workflow), but I couldn't find any clues whether or not the history is preserved.

Solution

You can do this with both Mercurial and with Git -- both projects have two-way bridges for interacting with Subversion.

For Mercurial, Joe will use hgsubversion to get a Mercurial repository on his machine with the full Subversion history. He then develops as normal using Mercurial. He will repeatedly pull in new revisions from the Subversion server and rebase his own changesets on top of them.

So let us imagine Joe has made three changesets on top of revision 2 from SVN:

... R1 --- R2 --- J1 --- J2 --- J3

He then pulls in new changesets from Subversion (just hg pull -- hgsubversion will understand that it should incrementally convert the new Subversion revisions into Mercurial changesets). The result is:

... R1 --- R2 --- J1 --- J2 --- J3
             \
              R3 --- R4

where the new branch represent the new Subversion revisions. Since Subversion is linear, he has to rebase his work on top of the new branch:

... R1 --- R2 --- R3 --- R4 --- J1 --- J2 --- J3

He keeps working like this, always rebasing instead of merging, and when it is time to send the changes back he asks you or someone else with commit rights on the Subversion repository to pull his Mercurial repository. You get

... R1 --- R2 --- R3 --- R4 --- R5 --- J1 --- J2 --- J3 --- J4

and you can now push the J1-4 changesets into Subversion:

... R1 --- R2 --- R3 --- R4 --- R5 --- R6 --- R7 --- R8 --- R9

The history is preserved: the four changesets become four revisions in Subversion. Please see my guide for more information and pretty pictures.