Re: [PATCHv2 5/5] fast-import: Fix minor data-loss issue with directories becoming symlinks

["Shawn O. Pearce" <spearce@spearce.org>]

Elijah Newren <newren@gmail.com> wrote:
> On Tue, Jul 6, 2010 at 1:34 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > newren@gmail.com wrote:
> >> From: Elijah Newren <newren@gmail.com>
> >>
> >> 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?

It probably makes sense to still do this in fast-import, deleting
something that doesn't exist is probably OK, its still going to
be deleted in the end anyway.

-- 
Shawn.