Stephen Butler <sbut...@elego.de>: > in the 0.5 draft, there's a paragraph about breaking history the > history of a flow. > : > You might want to add that flows may be connected by copyfrom info.
Good point. >[various observations, ending with...] > There's also the phenomenon of "evil twins", where an item is replaced > when it should have been changed. Arbitrarily breaking the flow > causes problems because the replace-operation is echoed on branches > by 'svn merge'. I think these are issues that should be documented somewhere *other* than the stream format description. What the dumpfile document should describe is how the stream defines actions on an abstract filestore; the semantics of flows and how the client tools work is a different level of description. > Perhaps reposurgeon will enable us to fix such problems offline, via > git-fast-import support, as discussed on this list recently. > > http://svn.haxx.se/dev/archive-2011-11/0328.shtml It's unlikely. The reason it's unlikely is that there is absolutely no notion of flow or container in the ontology of a git import stream. When you translate a Subversion repo to an import stream, copy operations basically disappear. Some of them turn into branch points, some into tags, and some (file copies on non-branch directories) vanish without trace - the only way you can tell the source and target files were ever related is their marks name the same blob, and even that relationship vanishes when you build a live repo from the stream. Since flow boundaries aren't representable in an input stream, you can't edit them by hacking an input stream. If you tried to map an import stream made from a Subversion history back to a Subversion history, you'd probably end up creating one copy operation per branch point. You'd end up with *a* flow structure, but not one that would necessarily bear much of any relationship to the flows in the original. In most cases it would be greatly simplified. Now, having said that...one thing I think reposurgeon demonstrates is that anyone who cared to put in a couple of weeks of Python hacking could produce an analogous tool for Subversion, a history editor specifically designed to retain and manipulate flow information. I'm not going to write that tool, but anyone who wants to could get a good running start by copying my stream-parser code. It's only about 300 lines and it's pretty well separated from the rest of reposurgeon. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
