[darcs-users] [issue1627] seamless SVN integration

Eric Kow kowey at darcs.net
Mon Sep 28 19:41:18 UTC 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.

> * 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.

> * How import the renaming changes (since they are encoded as copy;delete).

See above.  addfile+hunk; hunk+rm old file.

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

> * How to deal with svn properties.

I don't know what these are, but below you suggest they would be
helpful.

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

-- 
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/148936d6/attachment.pgp>


More information about the darcs-users mailing list