Charles Lepple <[email protected]>: > > 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.
What is presently happening is that 1. The Eaton_SDK branch is rooted on 2011-09-18T17:22:[email protected] "Add the missing '-q' option (closes Alioth patch #301145". 2. It begins with 3 commits: Create Eaton_SDK branch Add missing executable property Add missing ignore property 3. It continues with a deleteall commented "Remove this branch because properties of some files are wrong" 4. It ends with a single commit, "Re-create Eaton_SDK branch with (hopefully) rights files properties." If you want to forget the part you think of as Eaton_SDK@n-1 (before the deleteall) that is easy enough to arrange with a couple of deletes - but this straight-up translation of the operations on the branch seems to me to be the least surprising thing reposurgeon can do in the general case. I took your advice about turning tip branch delete into tags. That turned out to clean up the other bit of loose debris - the rst.old directory copy - in a natural way. I'm now testing some fixups on three misplaced or misnamed tags: # Tag location and name fixups delete =C & /Remove 2.6.0 tag/ obliterate quiet tag v2.6.0 move /Missing website update for 2.6.0/ delete =T & /^wrong tag name/ tag 2.0.4 rename v2.0.4 delete =T & /re taging 2.2.2/ delete =C & /moving the tags following a last change in Testing/ tag v2.2.2 move /fix HAL_CALLOUT_PATH for distcheck/ ...and my test run just popped up gitk. It looks like those commands had exactly the desired effect. I had just now written the 'tag' major command with 'move', 'rename', and 'delete' subcommands to express them; I have no doubt it will prove useful in the future. Here's my remaining list of known issues. Discussion follows: # Known problems: # 1. Anomalous commits on the root branch. # 2. Have yet to find a clean merge point for any branch. # 3. set-eol-style operations get lost; see tags emptycommit-3003, # emptycommit-2582, emptycommit-2175. The root branch is a dumping ground for any commit for which the code couldn't find a common directory prefix in the fileset that maps to a branch. As expected, it includes a bunch of junk directory copies we can just delete. But there are some commits on it that that have real fileops. Here are two examples: 2005-07-27T17:19:[email protected] cgi enhancements step1 2005-07-22T07:44:[email protected] various changes on newhidups and dummy-ups I need to figure out where in the branch topology those commits are supposed to live and why they didn't land there. Might be they mix file operations on divergent Subversion branches (groan!) in which case my branch-analysis code is going to have to become significantly twistier. I have yet to find a clean merge point for any branch. I think this means my cleanliness test is wrong. I'll work on that. I don't know what to do about the svn:eol properties. git's handling of cross-platfform line termination issues doesn't seem very well documented. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
