Re: 0.5 draft of new dumnfile docs

Stephen Butler <sbutler_at_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.

-- 
		Eric S. Raymond