From: Elijah Newren Date: Tue, 06 Jul 2010 19:48:50 GMT Subject: Re: [PATCHv2 5/5] fast-import: Fix minor data-loss issue with directories becoming symlinks Message-ID: In-Reply-To: <20100706193455.GA19476@spearce.org> On Tue, Jul 6, 2010 at 1:34 PM, Shawn O. Pearce wrote: > newren@gmail.com wrote: >> From: Elijah Newren >> >> When fast-export runs across a directory changing to a symlink, it will >> output the changes in the form >>   M 120000 :239821 dir-changing-to-symlink >>   D dir-changing-to-symlink/filename1 >> When fast-import sees the first line, it deletes the directory named >> dir-changing-to-symlink (and any files below it) and creates a symlink in >> its place.  When fast-import came across the second line, it was previously >> trying to remove the file and relevant leading directories in >> tree_content_remove(), and as a side effect it would delete the symlink >> that was just created.  This resulted in the symlink silently missing from >> the resulting repository. > > Ugh. > > I'm not against making the input parser more robust, but this is > a violation of the stream format from fast-export.  The stream is > incremental, a command like 'M' takes place immediately.  It is > wrong for a frontend to output 'M foo', then 'D foo/bar'. > > IMHO, if fast-export is doing what you say above, the bug lies in > fast-export, and therefore the fix should too. Okay, I'll fix up fast-export. Do you want me to drop this fast-import patch, or does it still make sense as an extra robustness check? Elijah