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
pgpOpnww7segm.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
