[darcs-users] [issue1627] seamless SVN integration

Eric Kow kowey at darcs.net
Mon Sep 28 07:02:45 UTC 2009


Hi everybody,

I'm just redirecting the issue1627 discussion here.  I'll keep an eye on
this thread and summarise any conclusions on the tracker.

If I condense this a tiny bit:

Eric Kow
--------
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.  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

Nicolas Pouillard
-----------------
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.

Guillaume Hoffmann
------------------
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)

Nicolas Pouillard
-----------------
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 at r487" option.

Eric Kow
--------
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).

Nicolas Pouillard
-----------------
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...

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090928/1368b1d5/attachment.pgp>


More information about the darcs-users mailing list