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:[email protected]" (SVN:3330) should be "2011-11-15T22:22:[email protected]" (SVN:3321) on the trunk, not "2011-11-24T08:56:[email protected]" (SVN:3329), which is the deletion commit (and therefore the end of Eaton_SDK@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@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
