[Nut-upsdev] Eaton_SDK dangling branch solved

[Charles Lepple]

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