On Tue, Mar 25, 2014 at 6:42 PM, Andy Goth <[email protected]> wrote:
> ...but this somehow fractured the timeline with several commit manifests > having P cards naming nonexistent predecessors. > i was hopeful until you said that :/. Once an artifact referenced by other artifacts is gone, if you have no way of 100% accurately reproducing it then... well... perhaps Richard can offer some hope, but i can't :/. BTW: i'm impressed by your casual use of the word "P-card" in everyday speech ;). i don't get to do that very often ;). I couldn't fix the repository in place without database editing beyond my > comfort level (zero), plus it's (currently...) impossible to generate > manifests having a predetermined SHA1 sum. It would have been okay to let > all the checksums change after the point of my edit, but still it seemed > like too much work. > i suspect a re-import from svn is the most expedient route here. > My solution was to transfer the contents of each commit to a new > repository. Since the repository has fewer than 150 commits; no branches; > no special tags, users, or configuration; no tickets, wiki pages, or > events; nothing special at all; and no requirement to preserve the > checksums, this was acceptable. For this repository, the transfer process > takes about four minutes on my computer, almost all of it spent inside > [fossil commit], presumably doing checksums. > i hope you've posted that later in this mail :). > The strange thing I do is open two repositories simultaneously within a > single directory, shuffling multiple copies of .fslckout. Then [fossil > update] performs the "edits" that are committed with [fossil delete], > [fossil add], and [fossil commit], and I use [fossil changes] to see what > needs to be deleted. > That sounds dangerous, but i don't inherently see a specific problem with it if it's done carefully. An alternate algorithm which might suit you better (but i have never tried): check out the first svn version, use (svn export) to set up your initial fossil version. Then incrementally check out svn versions, export them to the same fossil checkout dir, use (fossil addremove; fossil ci -m 'revision r####'). That should be relatively performant if you don't have to go over the network for the svn (otherwise woe possibly awaits you ;). > Since someone (me?) might find this script useful in the future, perhaps > as the foundation for a more comprehensive database regeneration procedure, > or a for stress test, I'm pasting it below: > Indeed you did :). Thanks. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
