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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harald Meland wrote:
>>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.

Sure.  We want to provide the user with the input they need, to resolve
the conflict, though.

>>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).

It is a problem because if the parent directories are also missing, we
might have to recreate them.

> If a rename has taken place, one could argue both ways.
> I'm leaning towards the latter reasoning, myself.

Yeah, I typically take OTHER in conflicts where one value must be taken,
because it will show up in status and is easy to revert, whereas taking
OTHER when you've got THIS is trickier.  So I'd probably apply that here
for consistency.

>>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.

But files in an unknown directory won't be shown at all by status,
inventory, etc.

>>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?

Right.

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

I agree, I'm just not sure what the right approach would be.

> 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?


>>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.

Good thought.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDKW+G0F+nu1YWqI0RAigZAJ47h4/rarqoPBnvMHjwGTyqaktmJQCfR8Cv
xh/y83HBIPsE+qaFVH0Hnkg=
=UuMx
-----END PGP SIGNATURE-----