[darcs-users] [issue1627] seamless SVN integration

[Nicolas Pouillard]

Excerpts from Eric Kow's message of Mon Sep 28 21:41:18 +0200 2009:
> On Mon, Sep 28, 2009 at 09:02:45 +0200, Eric Kow wrote:
> > However I don't know how hard would this integration, I think we should first 
> > collect issues we will encounter.
> 
> Sorry for throwing on more meta noise, but I think the wiki would be
> a nice place to do this because it would be one coherent document.
> 
> > Some thoughts:
> > * Can we pull a SVN revision without pulling some of the older revisions.
> 
> I hope so!
> 
> > * How can be managed the SVN model of branches (or worst absense of model).
> 
> > 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.
> 
> So basically I'd be happy with treating each branch/directory as a
> repository of its own, so that if you darcs get
>   svn://gforge.inria.fr/projectname/trunk
> and darcs get
>   svn://gforge.inria.fr/projectname
> 
> you get two completely unrelated repos that don't exchange patches.
> Tough luck; we're keeping it simple.  I think what I'm saying agrees
> with what you're saying.

Yes.

> > * How import the copying changes.
> 
> I propose that we model these as addfile+hunk patches that depend on
> all named patches that touch the file being copied.  This is basically
> us relying on the fact that SVN doesn't do commutation.

Might work.

> > * How import the renaming changes (since they are encoded as copy;delete).
> 
> See above.  addfile+hunk; hunk+rm old file.

Why not try to detect renaming? Remember that, one of the good point that git
made in the SVN world is to be able to better merge SVN branch than SVN
itself! It may works for darcs as well.

> More over, I think we should treat svn as a new format (darcs-1,
> darcs-2, svn) with no moves or replace patches

I don't think this is needed, we can just fail when pushing to the SVN repo.

> > * How to deal with svn properties.
> 
> I don't know what these are, but below you suggest they would be
> helpful.

It's like a little attributes mapping (think of [(String, String)]) attached
to each node of the hierarchy (including directories). These mappings are
versionned and used for various purpose. Like boring files (svn:ignore),
binary mode, the mime type, line-ending convention (this one was really a bad
idea), executable bit, a now points of branching and merging to do a better
job at merging (IMHO they failed).

> > 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...
> 
> I had the thought that maybe this could be stored exclusively in SVN.
> When you darcs push for the first time, it instantiates the map which
> all darcs repositories can use subsequently.

Hum this would require access to the files, this may not be possible over the
svn, or http(s?) protocols.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr