Nut upsdev - Jan 2012 - Eaton_SDK dangling branch solved

I've solved the problem of the detached Eaton_SDK branch.

What must have happened here is the branch creator did a
non-Subversion cp -r followed by an add of the target directory.
This registered a tree that duplicated trunk, *without* ancestry
information connecting it to its source revision.

The correct fix is to check each new text section against a list of
MD5 hashes of old text sections.  If I find a match, I then fill in
copyfrom_path and copyfrom_rev information so it looks (for purposes
of parent and branch computation) as though the branch creation had
been done with "svn copy".

It is a very good thing that I found this before I shipped 2.0.

rst.old remains detached, so there is still another corner case for me
to nail down.

2.0-pre5 and auxiliary files have been uploaded to

http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz

The fix for the "fossil write" bug is in this version.  Also note that
metadata modifications through mailbox_in can now match by Fossil-ID
if Event-Number is absent.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
        -- Miranda vs. Arizona, 384 US 436 p. 491

On Jan 4, 2012, at 12:24 PM, Eric S. Raymond wrote:
> I've solved the problem of the detached Eaton_SDK branch.
> 
> What must have happened here is the branch creator did a
> non-Subversion cp -r followed by an add of the target directory.
> This registered a tree that duplicated trunk, *without* ancestry
> information connecting it to its source revision.
This sounds vaguely familiar, yes.
> The correct fix is to check each new text section against a list of
> MD5 hashes of old text sections.  If I find a match, I then fill in
> copyfrom_path and copyfrom_rev information so it looks (for purposes
> of parent and branch computation) as though the branch creation had
> been done with "svn copy".
However, the original erroneous Eaton_SDK branch was deleted. The parent of the
commit at "2011-11-24T08:56:56Z!fbohe-guest at alioth.debian.org"
(SVN:3330) should be "2011-11-15T22:22:02Z!arnaud.quette at free.fr"
(SVN:3321) on the trunk, not "2011-11-24T08:56:01Z!fbohe-guest at
alioth.debian.org" (SVN:3329), which is the deletion commit (and therefore
the end of Eaton_SDK at n-1).

I think the method of turning branch deletion into a tag (that tags the previous
commit on that branch) will break the lineage between SVN:3329 and SVN:3330.

This might still be a divergence from the normal SVN method of making a remote
verbatim copy, then checking out that copy (such that the 2nd commit on the
branch is the one with the first set of deltas). See
http://trac.networkupstools.org/projects/nut/changeset/3330 for details
(normally, this commit would not change files, just the branch path).

-- 
Charles Lepple
clepple at gmail