On 07/03/12 15:38, Sam Vilain wrote: > On 3/6/12 2:34 PM, Andrew Sayers wrote: >> I've now added a bit of documentation and uploaded my code to github: >> https://github.com/andrew-sayers/Proof-of-concept-History-Converter >> >> I haven't attached it here because the code isn't at a stage where it >> would be useful to review line-by-line. Comments are welcome if you >> really want to though :) > > I just took a look at your readme—did you consider writing the tool to > work against an svn-fe import, rather than using SVN::Dump? Do you think > it could be adjusted to be like that? I did consider writing svn-branch-export.pl against a branch created by svn-fe, but right now it doesn't provide enough information to do a good job (e.g. copyfrom properties). I understand that support is in the works, but this project is more about getting a scrappy end-to-end solution so we can see what the issues are (is there any demand for DVCS-neutral SVN history export? What are the hard cases and how do you represent them?). I'm keen to make sure that documentation and tests are done in such a way that a future git-based exporter could use them without relying on any of the actual code. I also considered writing git-branch-import.pl against the raw svn-fe output. As well as the technical issues with this approach, I felt like these were better tackled as orthogonal problems. Producing an accurate representation of the SVN history is a very different problem to producing a user-friendly representation, and separating those concerns seems like it will make life easier down the line. For example, a user-friendly representation might convert svn:ignore properties to .gitignore files, but that would make bidirection hard to implement without an accurate representation in the middle. - Andrew -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html