[darcs-users] [issue1627] seamless SVN integration
kowey at darcs.net
Tue Sep 29 06:49:22 UTC 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?
Note that if we do this with a new format, darcs mv would have to create
a rmfile and addfile patch in SVN repos.
> > > * 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)
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...
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
Size: 194 bytes
Desc: not available
More information about the darcs-users