Part of my Darcs dream.  I want Darcs to be able to just treat any SVN
repository as a mentally challenged Darcs repository.  

You should be able to pull revisions as patches and push patches as revisions.

You should also be able able to talk to the same SVN repository from multiple
Darcs repos which in turn should be able to exchange patches between each other.

I think we need to have a think about whether anything in Darcs needs to change
for this to happen, or if it's just implementation.  If it's just
implementation,  I suggest we do this for Darcs 2.5 or 2.6.

No need for any silly git-svn style tricks... just seamlessness

As a simplifying assumption if it helps, we can assume that somebody with write
access to the SVN repository is willing to use Darcs to apply Darcs patches to
it (rather than traditional diff-and-patch).

One detail is that we may need to disable random salt from issue27 (if it's
still random) when pulling patches and replace it instead with Ignore-this: SVN
repo: gforge.inria.fr:/bar/repo
Ignore-this: SVN revision: r487

It is indeed one of the killer feature of git, which really helped its adoption.

However I don't know how hard would this integration, I think we should first 
collect issues we will encounter.

Some thoughts:
* Can we pull a SVN revision without pulling some of the older revisions.
* How can be managed the SVN model of branches (or worst absense of model).
* How import the copying changes.
* How import the renaming changes (since they are encoded as copy;delete).
* How to deal with svn properties.

For the second point, we probably just want to follow the user URL: for instance 
pulling from svn://gforge.inria.fr/projectname/trunk will strip the trunk/ part 
of pathnames.

Good news, there is already a SVN library in Haskell :
http://hackage.haskell.org/package/HsSVN

I like the idea of directly talking to the SVN repo since it provides the
simplest user interface possible. Also, a good objective is to not require any
extra information added to the darcs repo, nor to the patches (Ignore-this:
...). This means that all the "intelligence" of this operation should be into
get/pull/push. "Intelligence" means converting in both ways,
revisions-to-patches and patches-to-revisions, which implies setting an ordering
on (possibly unrelated) patches. It should work so that there are no initial
assumptions on the darcs repo nor the SVN repo, so that a push or pull between
two unrelated repos would work as well as a push/pull between two unrelated
darcs repos.

In terms of performance, storing information about this revision-to-patch
mapping into the cache seems the best way to go, since the cache can be
reconstructed and discarded on demand. (eg repo format change)

About the revision-to-patch mapping

Maybe that "never storing/caching the revision-to-patch" is a manageable option.
Indeed one just need to setup a darcs repository that will just holds all the
subversion revisions as patches.

Actually in this scenario we have to be able the revision number of a patch, so
I'm for the "Ignore-this: SVN gforge.inria.fr:/bar/repo@r487" option.

Hmm, I don't know if it's time to invoke the discussions-on-darcs-users rule or
if we're still tracking :-P

One issue to address is how to keep track of patches that start out being darcs
patches and later become pushed over to Subversion.  As Guillaume says, we
ideally do not want to modify the patch (for example, to add SVN rev to its log).

Hum, maybe can do it the other way around for darcs patches that become SVN 
revisions. That is, adding a SVN property to put the darcs hash in the SVN repo.

Then this means that for every revision, we have a darcs patch, either with a 
special tag (Ignore-This: SVN <repo-URL>@<rev>) or with a svn property on the 
server.

This is maybe too poor w.r.t performance though...

Discussion redirected to
http://lists.osuosl.org/pipermail/darcs-users/2009-September/021609.html

I do agree with Nicolas that we should be careful to imagine all the issues that
can arise.

We'll need to come back here with a summary when this discussion peters out.

Because this requires a long and involved design phase, I propose we use  
http://wiki.darcs.net/Ideas/Subversion
to summarise the idea in its latest form.  

Discussion will continue on the darcs-users list; the bug tracker will just hold
the implementation status; the wiki will provide a rough design document.

Meanwhile, we're still waiting until enough details are fleshed out or somebody
decides to just write some code.

> Part of my Darcs dream.

Heh... that's the only reason I use git (it has git-svn, which works
beautifully).

> I want Darcs to be able to just treat any SVN repository as a mentally
> challenged Darcs repository.

As a first step, I suggest considering a SVN branch as a read-only Darcs
repository...  Write support will be more tricky, since SVN doesn't
allow pushing if you're not up to date.

                                        Juliusz

> * Can we pull a SVN revision without pulling some of the older revisions.

At first sight, no.

> * How can be managed the SVN model of branches (or worst absense of model).

Ignore it.  You pull from a SVN branch, not from the repo.

                                        Juliusz

> As a first step, I suggest considering a SVN branch as a read-only Darcs
> repository...  Write support will be more tricky, since SVN doesn't
> allow pushing if you're not up to date.

That's definitly a good way to get startet.