Some thoughts on loom

[Robert Collins]

On Sat, 2008-04-12 at 06:51 -0400, Forest Bond wrote:
> Hi,
> 
> I've been using loom for a little bit now, and had some difficulty applying it
> as a quilt replacement due to the over head of merging every time I switch
> threads following a commit.  I felt like I was resolving more conflicts than I
> should have been.  This suspicion was confirmed when I did the following:
> 
> Assume I have a loom that looks something like this:
> 
>   B
>   A
> ->trunk
> 
> I have already committed any merges necessary to move between threads without
> committing.
> 
> I do the following:
> 
> 1. bzr -r thread:trunk -r thread:A

There's no verb here. Do you mean 'merge' ?

> 2. bzr revert --forget-merges
> 3. bzr commit (trunk and A now have the same code content, but their histories
>    don't contain the same commits).
> 4. bzr up-thread (no problems)
> 5. bzr combine-thread
> 
> Loom now looks like this:
> 
>   B
> ->trunk

What does 'bzr st' show ? I think there is a bug here at the moment.


> Now:
> 
> 6. bzr up-thread
> 
> This causes a conflict.  `bzr diff' prints this:
> 
> --------------------------------------------------------------------------------
> === modified file 'tests.py'
> --- tests.py    2008-04-11 21:42:31 +0000
> +++ tests.py    2008-04-12 10:40:23 +0000
> @@ -170,6 +170,8 @@
>                  resumed = True
>          assert self.task.finished
> 
> +<<<<<<< TREE
> +=======
>      def _testPausePrecludes(self, action):
>          paused = False
> 
> @@ -188,6 +190,7 @@
>      def testPausePrecludesFail(self):
>          return self._testPausePrecludes('fail')
> 
> +>>>>>>> MERGE-SOURCE
>  class SuccessfulSimpleTaskTestCase(TaskTestMixin, TestCase):
>      def setUp(self):
>          def fn(self):
> --------------------------------------------------------------------------------
> 
> This conflict doesn't make sense to me.  It looks like a false positive.
> 
> Can anyone explain?

I think in a revision graph sense you have the following:

B:[A]
A:[trunk-1]
trunk-2:[trunk-1]
trunk-1:[]

A and trunk-2 have the same textual content

Going up from 'trunk' to 'B' in your last step is the same, when you
have separate branches as doing:
'bzr merge trunk' in a branch called 'B'.
So in that graph, you are merging together two sides.
one side:
B, A, trunk-1
other side:
trunk-2, trunk-1

The common ancestor is trunk-1.

In this case bzr can't tell that B is actually meant to be successive
work from trunk-2 aka A.

If instead you did:

1. bzr switch trunk
2. bzr merge -r thread:trunk..thread:A
3. bzr revert --forget-merges
4. bzr commit (trunk and A now have the same code content, but their histories
   don't contain the same commits).
5. bzr up-thread (no problems)
6. bzr commit (joins the history)
7. bzr up-thread (no problems)
8. bzr commit

you can then safely combine-thread to remove thread A.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080414/c34fe027/attachment.pgp