attn: abentley Re: [BUG] Merging repositories with a directory deleted

[Harald Meland]

[Aaron Bentley]

> Harald Meland wrote:
>> [Aaron Bentley]
>>>Let's say, worst-case scenario, the file doesn't exist in THIS, and some
>>>of its parent directories are also missing.
>>>
>>>1. Do I use BASE or OTHER for the path?
>
> I should have been clearer;  I don't think we should resurrect the file,
> but I do think we should indicate the changes that were made, because
> files are typically deleted after the code in them has been moved
> elsewhere.

Either due to moved code (refactoring) or due to the old file being
obsoleted.  I don't think bzr should try to guess the reason behind
the file's removal.

> So far, we've indicated conflicting changes by creating $path.BASE,
> $path.OTHER $path.THIS files.  If we do it the same way in this
> case, what should $path be?

This is not a problem unless the path has been renamed, either between
BASE and OTHER or between BASE and THIS (prior to being removed).

If a rename has taken place, one could argue both ways.  One argument
would go somethink like this:

  It's most common to merge into a THIS branch that you "own", and
  hence it'd be easier to recognize the file if it has the same path
  it had just before being removed in THIS.  Note that that may not
  coincide with neither the path it had in BASE nor the path it
  currently has in OTHER.

, while the other would go:

  As the reason for restoring the OTHER version of file, even though
  the file has been deleted in THIS, is to deal with refactoring, one
  should also honour any refactoring that's been done in OTHER -- and
  hence use the path from OTHER.

I'm leaning towards the latter reasoning, myself.

>>>2. Do I use the exact path from that tree, or do I invent a path by
>>>iterating up through parents in OTHER/BASE until I find something that
>>>exists in THIS?
>> 
>> I'm not sure what to do if foo/ has been deleted between BASE and
>> THIS, though; would it be possible to put the file in a
>> "unknown"-class directory and mark the tree as conflicted?
>
> Files in an unknown directory will not, themselves, be marked as
> unknown.

No, but we're talking "*.{BASE,OTHER}"-named files here, which I think
would be clear enough.  Still, I think it would be good to re-use any
path components that are shared by the branches, with whatever renames
they have in THIS.

>>>3. When I make the directories, do I also add them to the inventory
>>>of THIS?
>> 
>> I'm not sure I understand this question; which directories are you
>> referring to?
>
> If I were to create parent directories for the .OTHER and .BASE files.

So, if directory "foo" was present in BASE, removed in THIS, but
contains modified files in OTHER, the question is whether "foo" (or,
possibly, whatever OTHER has renamed the directory to) should be
added?

I'd say adding the directory would qualify as a surprising
resurrection of something that's been explicitly deleted.

However, even if the file isn't added, a "bzr add" would add both the
directory and its contents.  To make it easier to spot when such
things happen, would it be a good idea to add .BASE or .OTHER to the
first deleted-in-THIS path component?

>>>4. What do I do if there's something in the way?
>> 
>> If both THIS and OTHER added a file with the same path
>
> No, this is already handled.  The case I was asking about was
> If THIS deletes a file $FOO, and OTHER modifies it, and there's already
> a file named $FOO.BASE or $FOO.THIS, what should I do?

Re-invent the naming of conflict-signalling file names; if they rather
were named $FOO.{BASE,OTHER,THIS}-<seqence-number>, you could just use
the first unused sequence number.
-- 
Harald