347
347
Entries get a new revision when they are modified in
348
348
any way, which includes a merge with a new set of
349
parents that have the same entry. Currently we do not
350
check for that set being ancestors of each other - and
351
we should - only parallel children should count for this
352
test see find_entry_parents to correct this. FIXME <---
353
I.e. if we are merging in revision FOO, and our
354
copy of file id BAR is identical to FOO.BAR, we should
355
generate a new revision of BAR IF and only IF FOO is
356
neither a child of our current tip, nor an ancestor of
357
our tip. The presence of FOO in our store should not
358
affect this logic UNLESS we are doing a merge of FOO,
349
parents that have the same entry.
361
351
# XXX: Need to think more here about when the user has
362
352
# made a specific decision on a particular value -- c.f.
364
354
for path, ie in self.new_inv.iter_entries():
365
previous_entries = ie.find_previous_heads(self.parent_invs)
355
previous_entries = ie.find_previous_heads(
357
self.weave_store.get_weave_or_empty(ie.file_id))
366
358
if ie.revision is None:
367
359
change = ie.snapshot(self.rev_id, path, previous_entries,
368
360
self.work_tree, self.weave_store)
added
removed
bzrlib/commit.py
