From: Jeff K. <sla...@um...> - 2010-06-15 16:23:28
|
I noticed a parenthesis error that was causing t_print to print out the current transcript even if it hadn't changed. That's been fixed and the patch has been re-uploaded. I'm also having our test machines use this version of the patch (applied to HEAD) for testing, and they appear to be fine. Jeff Kelley sla...@um... Campus Computing Sites Information and Technology Services University of Michigan On Jun 4, 2010, at 1:28 PM, Jeff Kelley wrote: > I've attached a new version of this patch to the original. It defines a new status, PR_REPLACE, that does everything PR_DOWNLOAD does except that it doesn't add the leading - to the to-be-printed line but does set fs_minus. > > Jeff Kelley > sla...@um... > Campus Computing Sites > Information and Technology Services > University of Michigan > > On Feb 18, 2010, at 11:06 AM, Jeff Kelley wrote: > >> Andrew, >> >> I've updated the patch description with an example of how to reproduce the issue it hopes to fix. As far as re-doing the patch is concerned, it looks like this is the relevant portion of t_print that handles this for directories to be deleted: >> >> if ( print_minus ) { >> /* set fs_minus so we can handle excluded files in dirs to be deleted */ >> fs_minus = 1; >> fprintf( outtran, "- " ); >> } >> >> We don't want to set print_minus in this case, since the first line will not be a deletion (it'll be the link). If you want to avoid inspecting fs and tran in t_print, then it looks like we'll need a flag other than PR_DOWNLOAD to pass to t_print. Maybe PR_REPLACE? >> >> Jeff Kelley >> sla...@um... >> Campus Computing Sites >> Information and Technology Services >> University of Michigan >> >> On Feb 9, 2010, at 11:45 AM, Andrew Mortensen wrote: >> >>> I did see it. Don't set fs_minus in t_print: that routine is for output, not changing state. >>> >>> Please also update your report with the information you've got here, and include minimal command file + transcripts exercising the bug. >>> >>> andrew >>> >>> On Feb 8, 2010, at 10:49 PM, Jeff Kelley wrote: >>> >>>> I just wanted to make sure people saw this patch I sent in. I've confirmed it works for cases where you have the following: >>>> >>>> /some/dir >>>> /some/dir/foo >>>> >>>> where 'foo' matches an exclude pattern. Replacing the loadset with this: >>>> >>>> l /some/dir -> /some/other/dir >>>> >>>> results in an error removing the directory /some/dir, as it isn't empty. The patch sets 'fs_minus' to 1 in cases where the transcript has a link and the filesystem has a folder. With this patch, fsdiff -A generates a line that removes /some/dir/foo, resolving the problem. >>>> >>>> Please let me know if there's anything else you need me to do for this patch. Also, see bug 1985781, which I submitted a while back but couldn't reproduce. This patch will fix that issue. Thanks in advance for your help. >>>> >>>> Jeff Kelley >>>> sla...@um... >>>> Campus Computing Sites >>>> Information and Technology Services >>>> University of Michigan >>>> >>>> On Jan 29, 2010, at 4:34 PM, SourceForge.net wrote: >>>> >>>>> Patches item #2942523, was opened at 2010-01-29 16:34 >>>>> Message generated for change (Tracker Item Submitted) made by slaunchaman >>>>> You can respond by visiting: >>>>> https://sourceforge.net/tracker/?func=detail&atid=749494&aid=2942523&group_id=141444 >>>>> >>>>> Please note that this message will contain a full copy of the comment thread, >>>>> including the initial issue submission, for this request, >>>>> not just the latest update. >>>>> Category: UNIX >>>>> Group: v1.X >>>>> Status: Open >>>>> Resolution: None >>>>> Priority: 5 >>>>> Private: No >>>>> Submitted By: Jeff Kelley (slaunchaman) >>>>> Assigned to: Nobody/Anonymous (nobody) >>>>> Summary: Fix for replacing dirs with symlinks >>>>> >>>>> Initial Comment: >>>>> If you have a directory that is to be replaced with a symlink, and that directory has an excluded item in it, fsdiff doesn't create a line for lapply to remove the file. This patch fixes that behavior. >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> You can respond by visiting: >>>>> https://sourceforge.net/tracker/?func=detail&atid=749494&aid=2942523&group_id=141444 |