/brz/remove-bazaar : changes

» Changes from revision 3514.2.16

To get this branch, use:

bzr branch
http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

From Revision 3514.2.16 to 3511

expand all

Rev	Summary	Authors	Date
3514.2.16	Review feedback from Ian. Review feedback from Ian.	John Arbash Meinel	17 years ago
3514.2.15	Enable collapsing linear regions. Enable collapsing linear regions.	John Arbash Meinel	17 years ago
3514.2.14	Bring in the code to collapse linear portions of the graph. Bring in the code to collapse linear portions of the graph. Also, start handling when we get NULL_REVISION instead of a tuple key from various apis. We could probably handle it at a different level if we really wanted.	John Arbash Meinel	17 years ago
3514.2.13	Add the ability to prune extra tails from the parent_map. Add the ability to prune extra tails from the parent_map. Now we can get the right answer without having to add extra history.	John Arbash Meinel	17 years ago
3514.2.12	Start refactoring into helper functions Start refactoring into helper functions	John Arbash Meinel	17 years ago
3514.2.11	Shortcut the case when one revision is in the ancestry of th... Shortcut the case when one revision is in the ancestry of the other. At the cost of a heads() check, when one parent supersedes, we don't have to extract the text for the other. Changes merge time from 3m37s => 3m21s. Using a CachingParentsProvider would drop the time down to 3m11s.	John Arbash Meinel	17 years ago
3514.2.10	Handle more edge cases. Handle more edge cases. Specifically, we don't have to switch on the whole-ancestry logic until we have 3 or more LCAs, we were doing it when there was 2. However, when we do switch on the whole ancestry logic, it is possible to get extra 'tails' which have ancestors that are in the ancestry of the unique lca, but they themselves do not terminate on the unique lca. The current code is a bit of a compromise, as we probably should chase down more nodes to include. If we include more than 1 lca, then we run into the same problem, where common lines have to have one side 'win' and the other 'lose'. A different possibility would be to create an artificial ancestor node, which uses the common lines from the different LCAs, so that it is assumed they all come from the same source. This would end up ignoring cases where changes were reverted and then reintroduced.	John Arbash Meinel	17 years ago
3514.2.9	Add some debugging, and work on getting the graph right so w... Add some debugging, and work on getting the graph right so we get the weave insertion order correct.	John Arbash Meinel	17 years ago
3514.2.8	The insertion ordering into the weave has an impact on confl... The insertion ordering into the weave has an impact on conflicts. Basically, when A has ancestors B and C which have overlapping changes, inserting B before C will implicitly sort its lines earlier in the weave. If A resolves the conflict by preserving this ordering, then switching that ordering later will make those lines look like they originated in A, rather than in B and C. (Because diff can't track moved lines yet.) So bring in some explicit ordering constraints which are likely to fit the real world workflow. Specifically, prefer to add the left-hand parents before the right-hand parents. Since that is how the merge was done.	John Arbash Meinel	17 years ago
3514.2.7	Fix the failing test by implementing the fallback logic. Fix the failing test by implementing the fallback logic.	John Arbash Meinel	17 years ago
3514.2.6	Write a (failing) test for complex ancestry. Write a (failing) test for complex ancestry.	John Arbash Meinel	17 years ago
3514.2.5	Switch to the get_parent_map design I had settled on. Switch to the get_parent_map design I had settled on.	John Arbash Meinel	17 years ago
3514.2.4	Update NEWS about bug #238895 Update NEWS about bug #238895	John Arbash Meinel	17 years ago
3514.2.3	Fix a failing test in tree_implementations Fix a failing test in tree_implementations	John Arbash Meinel	17 years ago
3514.2.2	Restore a real weave merge to 'bzr merge --weave'. Restore a real weave merge to 'bzr merge --weave'. To do so efficiently, we only add the simple LCAs to the final weave object, unless we run into complexities with the merge graph. This gives the same effective result as adding all the texts, with the advantage of not having to extract all of them.	John Arbash Meinel	17 years ago
3514.2.1	Test for correct conflicts on delete + change Test for correct conflicts on delete + change	Aaron Bentley	17 years ago
3514	Implement aliases for remembered locations (abentley) Implement aliases for remembered locations (abentley)	Canonical.com Patch ...	17 years ago
3513	Fix ftp transport so that it handles the 'mode' parameter wh... Fix ftp transport so that it handles the 'mode' parameter when provided	Canonical.com Patch ...	17 years ago
3512	(bialix) Deprectate (Branch\|Repository).print_file, fix cmd_... (bialix) Deprectate (Branch\|Repository).print_file, fix cmd_cat	Canonical.com Patch ...	17 years ago
3511	Add Branch.set_last_revision_ex HPSS verb to accelerate push... Add Branch.set_last_revision_ex HPSS verb to accelerate push. (Andrew Bennetts)	Canonical.com Patch ...	17 years ago

Older »