darcs

Issue 1627 seamless SVN integration

Title seamless SVN integration
Priority feature Status needs-reproduction
Milestone Resolved in
Superseder Nosy List darcs-devel, darcs-users, dmitry.kurochkin, ertai, gh, jch, kowey, tda
Assigned To
Topics

Created on 2009-09-24.14:12:46 by kowey, last changed 2009-11-11.19:07:40 by tda.

Messages
msg8868 (view) Author: kowey Date: 2009-09-24.14:12:44
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
msg8869 (view) Author: kowey Date: 2009-09-24.14:25:27
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
msg8870 (view) Author: ertai Date: 2009-09-24.15:29:14
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.
msg8871 (view) Author: gh Date: 2009-09-25.09:41:43
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)
msg8878 (view) Author: ertai Date: 2009-09-26.13:44:20
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.
msg8879 (view) Author: kowey Date: 2009-09-27.16:27:50
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).
msg8880 (view) Author: ertai Date: 2009-09-27.20:47:01
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...
msg8881 (view) Author: kowey Date: 2009-09-28.07:07:35
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.
msg8896 (view) Author: kowey Date: 2009-10-01.10:36:58
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.
msg9233 (view) Author: jch Date: 2009-11-11.01:21:36
> 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
msg9234 (view) Author: jch Date: 2009-11-11.01:23:11
> * 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
msg9235 (view) Author: tda Date: 2009-11-11.19:07:34
> 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.
History
Date User Action Args
2009-09-24 14:12:46koweycreate
2009-09-24 14:25:30koweysetnosy: kowey, darcs-devel, dmitry.kurochkin
messages: + msg8869
2009-09-24 15:29:17ertaisetnosy: + ertai
messages: + msg8870
2009-09-25 09:16:35ghsetnosy: + gh
2009-09-25 09:41:45ghsetnosy: kowey, darcs-devel, ertai, dmitry.kurochkin, gh
messages: + msg8871
2009-09-26 13:44:23ertaisetnosy: kowey, darcs-devel, ertai, dmitry.kurochkin, gh
messages: + msg8878
2009-09-27 16:27:53koweysetnosy: kowey, darcs-devel, ertai, dmitry.kurochkin, gh
messages: + msg8879
2009-09-27 20:47:03ertaisetnosy: kowey, darcs-devel, ertai, dmitry.kurochkin, gh
messages: + msg8880
2009-09-28 07:07:40koweysetnosy: kowey, darcs-devel, ertai, dmitry.kurochkin, gh
messages: + msg8881
2009-10-01 10:37:01koweysetnosy: kowey, darcs-devel, ertai, dmitry.kurochkin, gh
messages: + msg8896
2009-10-14 13:12:05tdasetnosy: + tda
2009-10-23 22:40:03adminsetnosy: + nicolas.pouillard, - ertai
2009-10-24 00:04:59adminsetnosy: + ertai, - nicolas.pouillard
2009-11-11 01:21:38jchsetnosy: + darcs-users, jch
messages: + msg9233
2009-11-11 01:23:13jchsetmessages: + msg9234
2009-11-11 19:07:40tdasetmessages: + msg9235