Re: [PATCHv2 5/5] fast-import: Fix minor data-loss issue with directories becoming symlinks
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Jul 6, 2010, 20:19 UTC
- Message-ID
- <20100706201935.GB19476@spearce.org>
- In-Reply-To
- <AANLkTimrD1LOZBb0YyzlrKgTc7bGWTxdf05cpwPR6WSw@mail.gmail.com>
Elijah Newren <newren@gmail.com> wrote:
Show 29 quoted lines
> 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.