-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Dec 17, 2009, at 01:26 PM, Aaron Bentley wrote:
>> Maybe I want to >> decide whether the work I had to do to land the code needs extra >> review. With a loom, there's no problem finding this. With a >> non-loom it's much more difficult especially if you've got several >> trunk merges interspersed. > >Sure, I can see the virtue of a stack-based approach if you want to view >the work separately. But this doesn't help me understand why you would >want trunk as the base thread. What happens if I update my trunk? In the loom-based approach, my bottom thread won't be updated until I explicitly take that step. In the branch based approach, all my branches will "see" the update. >I have thought about implementing a diff that ignores changes introduced >by merges. It's just a matter of tuits. That would definitely help. >> Updating the bottom thread and up-threading --auto falls into this. >> It's usually a trivial, inconsequential afterthought. Most changes >> on trunk don't affect my work, so I don't care about them. I'm >> merging trunk to be diligent. The fact that I can mentally segregate >> that to the bottom thread helps me ignore it completely in the common >> case, even if the end result is the same. > >I don't see how this lets you mentally segregate it to the bottom >thread. up-thread --auto affects all threads. Right, but it's the difference between thinking about it like: "oh, I'm just tracking trunk changes" to "I'm weaving in the trunk changes with my current work". I dunno, maybe I need to change my mental model, but to me there's a very distinct difference. >This is actually co-location of trees with their branches. You can >accomplish this with lightweight checkouts by putting the branch inside >the .bzr directory of the branch. > >$ bzr init foo >Created a standalone tree (format: 2a) > >$ bzr checkout foo bar >$ mkdir bar/.bzr/branches >$ mv foo bar/.bzr/branches/ >$ cd bar >$ bzr switch --force .bzr/branches/foo >Tree is up to date at revision 0. >Switched to branch: /home/abentley/sandbox/bar/.bzr/branches/foo/ Thanks, that helps a lot. I will definitely give this a shot for the next branch I'm working on. >Obviously, this is more steps than it should be, but it would be easy to >turn into a reconfigure operation. +1 >> I should note thought that there's a wart in looms related to this: >> export-loom. If I have to share my loom threads with others (e.g. a >> merge proposal), I have to export it into separate branches. > >You can also use import-loom to convert it to a pipeline, which will >preserve ordering information, so it can be used by lp-submit. Neat! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLK1Q5AAoJEBJutWOnSwa/Q74QAIr197c6mo81Y/BkO9V8F/ZK VRGxJdt2zmWa2TuZvytYtyxzw7lprxE7UqaOdrWLjrcNRtMsnHLXfVs6in+25mar zPhk214fiw0TGs6nvWq3m24SNB2WewgcxuXUe02t9jea899J+ObbllcFsHGuLOQF PAr1hWK9z5osw9uJFcO0YfeedQSQ4oX/HZpA2HlljVFzym3W2Ai5rUxZintV283g lpRJiRJbj5GA6Y7kuuWQF6l2Rv/bRrgF4YKg/GGi+CdG475sappCYnPJMKbYuOil QxXC0poT8k1enIwTFikaV04xSyg7CJF3vBZeQBjZ9ClXeADhzz02ZQ41EpB39UdW 4khzinw9TiZEf459w6LDR6iiqUh/lXSVdeA0h3Y00lRSzKsd1iUCiosMPKwuFpcA ZFuKIVlxCIzosGFrnfM8RT1JF6hFE+h6rga86aGs92JOUBUBJ9U5KtHZo5CPxuUx tiRAf/mNcm/Iozu1Km57xxfy9hDAHGK7QF/Mh7dCk3aM/MP3zeCdR/qtVlamfX3d me+o+iIUq4X1TgLGVlf9NcQTRAJmhjYYPYbaYFXYxu8PznJU5bQbVz82K+Ip8kGe F1mfDmP6cf38uMvkAc6eAwKQHfpxTyPl+ururJ5jWA/L8+YHUk3rMluzRrkbk7eG VggG9AkGT5lFsixDNlIv =CsJg -----END PGP SIGNATURE----- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
