[darcs-users] (no subject)

nicolas.pouillard at gmail.com nicolas.pouillard at gmail.com
Wed Sep 30 20:56:24 UTC 2009

>From nicolas.pouillard at gmail.com Tue Sep 29 14:18:53 UTC 2009
Content-Type: text/plain; charset=UTF-8
Subject: Re: [darcs-users] [issue1627] seamless SVN integration
From: Nicolas Pouillard <nicolas.pouillard at gmail.com>
To: Eric Kow <kowey at darcs.net>
In-reply-to: <20090929064922.GB31855 at dewdrop.local>
References: <20090928070245.GB22265 at dewdrop.local> <20090928194118.GA27160 at dewdrop.local> <1254167762-sup-4166 at peray> <20090929064922.GB31855 at dewdrop.local>
Date: Tue, 29 Sep 2009 16:18:53 +0200
Message-Id: <1254233567-sup-8888 at peray>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit

Excerpts from Eric Kow's message of Tue Sep 29 08:49:22 +0200 2009:
> On Mon, Sep 28, 2009 at 22:03:29 +0200, Nicolas Pouillard wrote:
> > > > * 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.
> Possibly.  If we do this, I think we *may* way to re-use the same scheme
> of making a mv patch that depends on all the named patches that affect
> the source file, so that funky unexpected things don't happen (given the
> lack of a copy operation in Darcs).  But I haven't thought very hard
> about what those funky things could be.
> This way things that come after the mv patch can commute before it
> but not vice versa
> > > 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.
> But won't this cause pain and suffering for Darcs users that create
> mv patches and then depend on them?

Right, but you have the choice of what is SVN repo for. You can for instance,
migrate slowly from SVN to darcs, and at some point no longer push to the SVN.

> Note that if we do this with a new format, darcs mv would have to create
> a rmfile and addfile patch in SVN repos.

I think we want to keep our darcs as we now it, and just have a partial
action for pushing to the SVN, a kind of best effort.

Hum *thinking*, but is there really an issue with mv patches, can't we just
transform to copy;delete when going to SVN? I'm maybe confused...

> > > > * 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).
> Everything makes more sense when explained with types :-)
> > > 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.
> Would it help if we assumed we had a remote darcs client that we could
> do apply with?  (My assumption here is that you can *read* SVN
> properties without one)

Yes properties are readable/writable within the protocol. I thought you meant
to store this mapping as an actual file in the SVN repo internal directory.

> This assumption would make this slightly less useful (you'd have to
> convince the remote site to install the Darcs client) but it could be
> a good "make something that works first" approach...


Nicolas Pouillard

More information about the darcs-users mailing list