[00:00] jam: also new patch; btree refactoring that was needed in pack repo [00:32] poolie: slugging? [01:00] When branching from launchpad, does one have to have a launchpad account? [01:00] nope [01:00] the branches are accessible over plain old http [01:00] I keep getting a permission denied error. [01:01] Ah. [01:01] Okay, how do I translate the lp:BRANCH URL to an http URL? [01:01] abadger1999: private branches require a lp login [01:01] abadger1999: because access control [01:02] lifeless: How do I tell if they're private? [01:02] abadger1999: what are you actually doing? [01:02] https://code.launchpad.net/trac-bzr [01:02] I'm updating the Fedora package. [01:02] abadger1999: as in, pastebin [01:03] And I'm writing instructions for other people to retrieve the branch in case they need to verify that what I packaged is what's upstream. [01:03] So I just need to figure out how to tell them to retrieve: "bzr branch lp:trac-bzr" [01:04] that should work for you [01:05] mwhudson: ahh.... Thanks! I see my error now. [01:05] I do have a launchpad account registered in bazaar.conf [01:05] But I've changed my ssh key since it was registered. [01:06] So I was assuming lp: was erroring because I was anonymous but it was really because my ssh key didn't match. [01:12] ah === mw is now known as mw|out [01:40] spiv: sorry for death-by-a-thousand-replies [01:41] spiv: also I think you might benefit if you think about hooks a little differently; [01:41] jelmer: ? [01:41] spiv: because they are intended to allow plugins to add actions, they -by definition- cannot operate on a per-hooked-thing basis [01:42] spiv: rather they look like C-object-style with object as the first parameter; [01:42] spiv: as such, its _never_ right to add a hook function just-for-one-instance; instead its always add-hook-thunk, which acts-when-appropriate [01:48] lifeless: yeah. That's why I had the alternative implementation that did just that. But it seemed more complicated in this instance. [01:48] Hmm. [01:49] spiv: WeakKeyDictionary FTW ? [01:49] spiv: surely thats all you need [01:49] The problem is that WeakKeyDictionary just silently drops the entry when the ref goes away. [01:49] I just had an idea. [01:50] I *might* be able to get away with using a WKD + my own weakref, so that the callback on my weakref can retrieve the value out of the WKD before it goes away. [01:50] subclass ReferenceType [01:51] (Weakref callbacks are guaranteed to be called in reverse order of weakref creation) [01:51] Right, I can do that too. But again that's significantly more complicated. [01:51] k [01:52] I'm willing to add the complexity if people think its worth it, but I thought that it would be best to try the simplest approach first. [01:52] I think fitting the pattern hooks are designed around is simpler [01:52] It is frustrating that WKD is so close to what I need, but not quite there. [01:52] the thing that is unique in this case is wanting a 'done with' event [01:53] and I think it would be easier for you if you had a 'done with medium' hook :P [01:53] Heh. [01:54] It would be. Any suggestions on how to implement that easily? :) [01:54] add a __del__ to Medium [01:54] It already has one. [01:54] add a hook that triggers during del [01:54] with a signature of (weakref(hook)) [01:55] I'm not sure why I haven't tried using that __del__, actually. [01:55] (so that we aren't adding refs to the hook accidentally) [01:55] spiv: this is I think why I mentioned /thinking/ about hooks differently [01:55] Well, I already did try thinking that way. [01:56] As I hope the alternative patch in my original mail shows :) [01:56] spiv: sure, I think I'm expressing myself badly [01:57] I just mean that it seemeed simpler to you to try and work against the current [01:57] which suggests you haven't quite internalised the reasons behind the stream [01:57] [to me] [01:58] aaaanyhow, I'll stop blathering and let you get on with it; [01:59] Well, I don't think so. I just failed to see a nice way for a single hook function to find the right medium to associate with when using weakrefs. That didn't mean there wasn't, just that I didn't find one yesterday afternoon. [01:59] spiv: isn't the hook called with the medium ? [01:59] I definitely appreciate that it's not so nice to have lots of hook function registrations. [02:00] It is, but I was keeping weakrefs in the counter object to keep the impact as obviously minimal as possible. [02:00] And WKD is unfortunately nearly but not quite what I needed... [02:01] a hook even on del would do it, and will trigger when the WKD will too [02:01] Yeah, seeing as there's already a __del__ I think I may as well use that. [02:01] If there wasn't already a __del__, I think weakrefs would be the way to go. [02:08] jam:? [02:08] markh: yes? [02:08] I notice the 1.7 branch is labeled as 1.7.1rc1 - should I just skip a 1.7final? [02:09] or jump back a rev or 2 [02:09] (maybe I should be using a tag on that branch? I haven't looked I admit...) [02:10] markh: We need to do a 1.7-final [02:10] you can either use the tarball [02:10] or use rev 3705 [02:12] ok, will do. When do you expect 1.7.1 final? [02:15] heh - so, how do I force a branch *back* a revision? Using -rfoo when the current rev is greater than foo doesn't seem to do anything? [02:15] What -rfoo? pull works... [02:17] markh: uncommit [02:17] markh: or pull -rfoo --overwrite [02:17] lifeless: I just thought of override as you said it - sorry for the noise! [02:18] overwrite too :) [02:19] wow [02:19] bzr heads -> 1.6GB used [02:21] 1.6 billion heads are better than one. [02:21] eeepic fail [02:23] I think its the svn-branch-open-leak-fail [02:23] jelmer: is that fixed? [02:24] lifeless: so generally, I think there is a lot of cleanup we *could* do, and some discussion to be had. But we can do that after it lands. [02:25] jam: 'it' ? [02:25] lifeless: iter_changes in pyrex [02:25] ah yes [02:25] I want to make it much smaller and more many-function clean [02:25] Oh right, the __del__ isn't on SmartClientMedium, just one of its subclasses. I'll see if I can workaround WKD's deficiency... [02:26] super(self, Class).__del__() [02:26] ? [02:26] markh: well for making a release, you are probably fine to do "bzr revert -r -2" make foo; bzr revert ; make foo [02:26] and build both the 1.7-final and 1.7.1rc1 [02:27] lifeless: I'm pretty sure it is super(Class, self).__del__() :) [02:27] lifeless: I really don't want to add __del__ to objects that don't already have them [02:27] jam: MEH, DETAILS [02:27] sorry for shoutig [02:27] lifeless: that would mean the debug option would be penalising things even when not used. [02:27] jam: ah, thanks. As it turns out I've built 1.7.1rc1 first, but that should be fine as it stands. I've build 1.7 and will testing that now... [02:27] spiv: so as always, can we push the __del__ into an attribute other than self, to avoid circlese [02:28] spiv: sometimes its the right thing to do though [02:28] jam: or, just use weakrefs :) [02:30] I wasn't following closely, just poking at __del__ [02:50] jam: oh bugger [02:50] jam: guess what I just did [02:50] ? [02:50] found a problem, or submitted your version? [02:50] submitted la version robert [02:50] and then took a shower, so its well and truely in progress [02:51] np, we can always submit another one :) [02:51] do you want to queue yours up now ? [02:53] sure [02:53] you didn't do any other changes? [02:53] nup [03:15] spiv: is there a way to tell RemoteRepositoryFormat to create a specific backend format ? [03:19] lifeless: I think if you pass something other than a RemoteBzrDir to RemoteRepositoryFormat.initialize it might work. [03:20] I'm trying to test RemoteRepository with a chk_bytes supporting backend [03:22] I don't think we have many tests of RemoteRepo on top of specific backends. The ones we do have probably all do it by making the backend repo directly, then re-opening that via a SmartTCPServer_for_testing. [03:28] +class TestCaseWithRepositoryCHK(TestCaseWithRepository): [03:28] + [03:28] + def make_repository(self, path): [03:28] + TestCaseWithRepository.make_repository(self, path) [03:28] + return repository.Repository.open(self.get_transport(path).base) [03:28] that works, ilttle fuglay [03:41] http://spooky-possum.org/cgi-bin/pyblosxom.cgi/harmless.html [03:45] hrm - 'bzr selftest' has 41 threads running for me! [03:46] make that 72 :) [03:49] eek - and counting - just crashed through 300! [03:51] 500! How much can vista on a vm handle! [03:53] 'running' in a very loose sense i think [03:54] yeah [03:55] 1/2GB ram, 6000 handles open... [04:19] markh: well it is *testing* :P [04:44] jam: this is wrong/missing: [04:45] # source_branch: http://bzr.arbash-meinel.com/branches/bzr/1.8-\ [04:45] # dev/trivial_python_compat [04:59] anyone around for a quick irc teddy bear session [04:59] * beuno tries to resist asking what that would be [05:04] I just used Google's image search on "IRC teddy bear" and got http://images.villagevoice.com/issues/0521/expo-011s.jpg Something is clearly wrong with the world. [05:05] AfC: i need a drink now [05:06] And a cigarette. [05:08] (possibly i needed a drink already, before clicking that link, mind) [05:11] Possibly you had a drink already, if you're clicking links AfC pastes with disturbing prose around them :p [05:14] i'm thinking this image may not be good to clik at work [05:14] I figured I had done my part to make it clear that the aforementioned link was for mature audiences only. That said, the real question is what Robert is doing looking for an IRC teddy bear. Fascinating, really. [05:15] and why he would need someone else... [05:17] I was going to say I myself could use an IRC piggy bank, but I figured I should google it first, just to be safe. [05:17] And somehow I end up with http://gadgets.boingboing.net/2008/06/19/bandai-ikemenbank-pi.html [05:17] * fullermd boggles. [05:18] * beuno wonders if google substitute "IRC" for something kinky internally [05:19] Well, I still sometimes end up with 'International Reply Coupon' on my first acronym-fault... [05:22] AfC: when designing things its often easier to discuss it with someone [05:22] AfC: they are a teddy bear, if they are not needed for content so much as for the fact-of-discussion [05:23] AfC: and being on IRC was well, being on IRC :P [05:28] Well, way to make it boring in comparison :p [05:29] Here we were, picturing stuffed animals engaging in all sorts of bazaar acts... [05:30] lifeless: it's also called "rubber ducking" sometimes. [05:30] jml: thats so much more open to misinterpretation [05:30] jml: it has rubber, and water sports, and its fowl [05:31] quick! get me my pun glasses! [05:38] fingers crossed, all my status work will have landed in 30 minutes or so [06:53] hi all ! [06:57] yay, status stuf landed [06:57] have a good weekend all [07:07] Weekend indeed... it's only an hour into Friday :p [07:08] you too lifeless [07:08] * beuno is happy to be on the other side for once [07:15] hi [07:15] night lifeless [07:43] abentley: bb is down :-/ [07:44] poolie: restarted [08:02] abentley: which one ? :D [08:04] abentley: joke aside, I playfully thought about multiple BB instances... interesting problem (not worth the trouble though) [08:28] oh, thanks! [08:28] hi vila, abentley [08:29] vila, that was a 'tweak' overall for the 2.6 stuff [08:30] ha, ok, hmm, I'm checking a bit more but I see your points and will merge most of it (at least) [08:31] I've checked that Exception.message has indeed be deprecated, that leave only the unicode stuff [09:10] what means format: unnamed in bzr info? e.g. I create bzr init-repo --1.6.1-rich-root and then branch or checkout under it, then shared repo shows format: 1.6.1-rich-root, but branch under it format: unnamed. [09:13] tvainika: it means bzr doesn't have a short label for the combination of branch format & repo format you have. "bzr info -v" will tell you more. [09:15] tvainika: "unnamed" isn't very helpful. There's a bug filed about that: https://bugs.launchpad.net/bzr/+bug/202083 [09:15] Launchpad bug 202083 in bzr "need better short names for format combinations" [Undecided,New] === cjwatson_ is now known as cjwatson [12:44] bzr revert returns with bzr: ERROR: Could not acquire lock "D:/duscher/docs/ProjektM/dev/.bzr/checkout/dirstate" [12:44] i am using bzr.dev newest version and I rebooted my computer to make sure there is no system lock.... [13:13] jonnydee: I think that's either been fixed or I saw a patch in the pipe that fixes it [13:13] * awilkins wonders if anyone else but him uses msvc 7.1 to build the extensions [13:31] awilkins: ok, so until now the fix seems not to be in bzr.dev because I did an update of my bazaar installation right before I tried to revert... So I hope the patch comes soon, thanx :) [13:33] jonnydee1: I think it's http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48DC0B60.4010201%40arbash-meinel.com%3E [13:33] So if you do a bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C48DC0B60.4010201@arbash-meinel.com%3E to your bzr.dev, maybe it will fix it :-) === asabil is now known as asabil_is_not_as === asabil_is_not_as is now known as asabil [15:40] is there a way to cherry-pick commits between branches ? === _Verterok_ is now known as Verterok [15:47] asabil: bzr merge -rx..y ../other-branch [15:48] well, real cherry picking with merge tracking [15:48] and commit message preservation [15:50] bzr replay -rx..y ../other-branch for the second point === fta_ is now known as fta === ja1 is now known as jam [16:19] I'm looking at a bug in the trac-bzr plugin and have a question. [16:19] bzr's NEWS file says that _get_weave() was deprecated in favour of RevisionTree.plan_merge(). [16:19] But there is no plan_merge() in Tree. [16:20] Does the document mean: One of these: 'plan_file_lca_merge', 'plan_file_merge' ? [16:21] Or does it mean VersionedFile.plan_merge() ? [16:39] Looks like I'm working on https://bugs.launchpad.net/trac-bzr/+bug/263300 [16:39] Launchpad bug 263300 in trac-bzr "Does not work with bzr 1.6" [Undecided,New] [16:42] hi [16:42] how can I generate a patch (like the send command) unsing directly bzrlib ? [16:46] Okkin: Do you want a patch or a bundle? [16:47] jelmer: How do you keep track of what API breaks are going on in bzrlib that might affect you? [16:47] Okkin: i.e., are you looking to generate a patch, or do you want to be able to merge from the produced output? [16:48] Odd_Bloke: a blundle [16:48] sorry [16:49] i want to merge the result in a remote branch that is only accessible by email [16:49] Okkin: Then I'd suggest looking at the code for the send command. :) [16:50] that want i was doing in fact :) [16:50] but I'm lazzy on friday [16:51] Okkin: Well, that's what most of us would have to do to help you, and it's Friday for us as well. ;) [16:51] Odd_Bloke :) [16:53] I understand so well the friday laziness [16:58] sabdfl had a sudden posting spree to the bzr list about 16 hours ago. [17:04] Odd_Bloke: read NEWS? [17:07] LarstiQ: Sure, but at what point? [17:07] Because presumably he's going to want to have made the changes before the release containing said NEWS. [17:29] Odd_Bloke: right [17:29] Odd_Bloke: pull bzr.dev from point to point and read NEWS? :) [17:29] * LarstiQ heads off [17:35] LarstiQ: Yeah, I'm wondering how that could be improved. [17:35] Or, rather, if it needs to be. [17:39] hi folks. i've been using mercurial for the last year, and i was using bzr and arch before that [17:39] since a year has passed i've decided to survey the field again [17:40] resolve: Hi. :) [17:40] i've been very happy with mercurial - generally it did what i wanted without trouble [17:41] but bzr seems to have made decent progress recently, and the ability to use launchpad does seem nice [17:41] any of you here switched to/from bzr from mercurial? [17:43] has 1.7 made any changes related to the repo blowout on http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html ? [17:46] resolve: I'm not sure about 1.7, but there are some improvements of that ilk in the pipeline. [17:46] In the development{1,2} formats. [17:46] 1.7 may have included development1, I'm not sure... === gotgenes_ is now known as gotgenes [17:56] la la la, pqm blocked [17:56] :-/ [17:57] any LOSA around ? [18:00] jam: pqm is blocked on a successful merge, once again :-/ I hate leaving for week-end like that, could find a LOSA and kill the offending (ssh ?) process (worked well the las timeS it occured) [18:01] s/could/could you/ [18:01] pqm has been updated to bzr-1.6.1 (AFAIK) in the hope it will fix the problem. It doesn't apparently [18:02] vila: what I want to know, is why does it always happen with *your* branches? :) [18:02] Shooting in the dark again but: it looks like I'm the only one triggering this [18:02] My only guess is that it happens with branches "freshly" pushed on lp [18:02] maybe because you are using 'lp:' ? just a guess [18:03] I always use my own [18:03] still, it doesn't make a lot of sense [18:03] that too but that a bit short as a diagnosis :-/ [18:03] since it isn't failing to *merge* it is failing to commit [18:03] yeah [18:03] not even failing [18:04] the commit succeeds even when the process is killed, something else should block... [18:07] what do I do with "bzr: ERROR: [Errno 17] File exists" ? [18:08] if you use lp: and PQM has a launchpad login then it will use ssh, presumably everyone else will submit with http? [18:08] ignas: during what operation? [18:08] james_w: bzr ci [18:08] ignas: running again with -Derror will give some clue as to what is going on [18:09] james_w: where do you want your traceback? [18:09] ignas: my guess is https://bugs.launchpad.net/bzr/+bug/242510 [18:09] Launchpad bug 242510 in bzr "Pack already exists when pushing/autopacking" [High,Fix committed] [18:09] ah, no, wrong message I guess [18:10] ignas: paste.ubuntu.com or anywhere similar is fine [18:10] not pastebin.ca [18:10] james_w: http://paste.ubuntu.com/50932/ [18:11] wow, that's an odd one [18:11] I guess you're not running bzr.dev? [18:12] nope [18:12] Bazaar (bzr) 1.7.1rc1 [18:13] james_w: i have a dev version [18:13] i can try using it [18:15] when i'll bzr pull it [18:16] it seems like one of opendir, readdir or closedir are returning "File exists" [18:16] The man pages don't say that that will happen though [18:19] I'm stumped [18:19] ignas: please file a bg [18:21] https://bugs.launchpad.net/bzr/+bug/274875 [18:21] Launchpad bug 274875 in bzr "Unexpected File exists error when trying to commit" [Undecided,New] [18:30] ouch [18:30] branched the branch locally [18:30] and tried committing the same changes [18:30] it failed with the same error [18:32] Anyone here use bzr commit --fixes ? [18:32] yep, i can't commit into any of the branches in that shared repository [18:32] and I really do not like it... [18:32] frankly - it is preventing me from working :/ [18:32] I'm wondering what the syntax is for marking a bug fixed in launchpad... --fixes 1234 OR --fixes lp:1234 OR .... [18:33] ok, i can't do any bzr commits on my machine... [18:34] ok, I can with bzr.dev [18:37] hmm, i will recompile bzr.dev and see then [18:37] yep, still works [18:38] abadger1999: the latter [18:38] james_w: Excellent. Thanks [18:39] so bzr.dev works, bzr 1.7.1rc1 packages from PPA - don't [18:44] Augh, what big new thing landed in bzr.dev that's making pulling it so slow? :( [18:51] hi folks, bzrtools is driving me crazy [18:51] i have this in my sources.list: http://ppa.launchpad.net/bzr-beta-ppa/ubuntu hardy main [18:52] but bzrtools is always getting out of sync. either it's too old, or if i branch lp:bzrtools, it's too new [18:52] barry: Switch to Fedora :-) [18:52] how am i supposed to keep these in sync?! [18:52] abadger1999: yeah, not actually an option :) [18:53] barry: There was just a discussion about this on the bazaar mailing list. [18:53] * abadger1999 looks for URL [18:53] barry: My solution is to run from source. :| [18:54] Peng_: i might have to do that :/ [18:54] The devs uploading the ppas came up with a plan to "do better" about keeping them in sync. [18:55] abadger1999: cool. at least they're aware of the problem. i need to figure out something to get my bzr shelve back now, but i'll install from src if i have to for the short term [18:55] barry: Here's where the thread starts: https://lists.ubuntu.com/archives/bazaar/2008q3/047810.html [18:56] abadger1999: thanks [18:57] barry: No problem. I think bzr should change it's release practices to make this better for everyone but... I'm only a distro packager and occassional bug fixer so I don't have much clout. [18:58] abadger1999: i see that shelve is a candidate for pulling into the core. that's the one that always kills me, so that would benice [18:58] [18:59] barry: My problem as a packager is that we get into situations where one set of plugins only works with an older version of bzr. [19:00] Meanwhile other users want to have the newer bzr because someone they work with has upgraded their repository to an incompatible version. [19:00] abadger1999: i don't envy packagers jobs at all! y'all do a great job with a tough problem [19:00] heh. [19:01] barry: Were you at PyCon and attended the BoF on packaging? [19:01] i was! [19:02] abadger1999: you too? /me looks at abadger1999's info [19:02] barry: Yep. I'm toshio, the skinny Fedora guy :-) [19:02] :) [19:02] nice to see you here [19:03] likewise :-) [19:03] abadger1999: i see a lot of traffic on the distutils-sig. i have no time to keep up with it, but how do you think it's going w.r.t. distro needs? [19:03] barry: I'm sad to say I haven't been able to keep up with it either. [19:04] barry: when I take a look at the code, it doesn't look like there's much going on. [19:04] * barry perfects his clonebot [19:04] But there might be discussion that just hasn't been implemented yet. [19:04] abadger1999: lots of grand ideas [19:04] Right. [19:06] at least they're getting phillip involved. sometimes guilt is the best motivating factor in floss (it's worked on me *many* times :) [19:06] Yeah. That is good. [19:06] I've been migrating some build scripts over to paver recently. That seems to fit the distro packagers needs a lot better than vanilla setuptools [19:07] i'm not familiar with paver [19:07] http://www.blueskyonmars.com/projects/paver/ [19:07] It's something like a make/setuptools cross. [19:08] neat: kevin dangoor [19:08] It imports distutils (and setuptools if available) so you can have those commands if you want them. [19:08] * barry bookmarks [19:08] But it allows you to define custom tasks easily. [19:08] sort of like a cleaner scons? [19:08] And add more declarative information. [19:09] I haven't actually used scons. [19:09] i built a huge system with scons in my previous job. nicely modular, but the hard things were *really* hard [19:09] barry: I just synced bzrtools into bzr-ppa [19:09] Mak esure you have both [19:10] I'm going to try and keep them in sync more [19:10] jam: cool, thanks! i think the thing was i was using bzr-beta-ppa [19:10] barry: it doesn't usually have "beta" releases, and it always wants tobe in lock-step... [19:10] which didn't have bzrtools [19:10] you can probably use both [19:10] hmm... Yeah. paver aims to make things always easy. [19:10] so Ubuntu is trying to upgrade bzr and bzr-svn, but is complaining that they can't be authenticated? Anyone know what might be up w/ that? [19:10] jam: awesome, thanks [19:11] abadger1999: i'm really looking for something better for mm3 development, than just setup.py develop [19:11] it also looks like the "upgrade" verison is the same as the one that's installed, but I'll ask about that in #ubuntu. :p [19:11] abadger1999: but virtualenv just doesn't DTRT for me [19:11] abadger1999: thanks for the paver link [19:13] barry: Cool. Keep in touch because I'm very interested in this too. [19:13] abadger1999: definitely! [19:14] gotta run. thanks everyone! === bac is now known as bac_dog_walk [20:04] jam: No LOSA around ? :-/ [20:04] nobody has responded [20:05] jam: thks [20:05] it is friday night after all [20:08] * vila remembers his first *day* as intern: 'del library member', damn that's long, hey tutor, why so long ? EEEEEEEEERK Of course you have backup tutor ? And why the 'del' command doesn't check its arguments before running ? [20:08] .win 11 [20:10] pfff, dos was just a child in those days :) No the system name was Pick or something and the script language 'English', it was supposed to be natural (like real people the script was ignoring what it didn't understand :-D ) === bac_dog_walk is now known as bac [20:18] Well, I did my best to summon fullermd, but that should really be friday night :) === bac is now known as bac_walk [20:39] hi === bac_walk is now known as bac [21:06] vila: well, mthaddon was nice enough to restart it [21:07] yeah for mthaddon ! [21:07] yeah for jam ! [21:07] :) [21:07] vila: you may need to resubmit your patch [21:07] or *not* for now :) [21:08] hehe, yeah, I'll left pqm alone for the week-end ;-) [21:09] jam: hi! please, what's the status of "put merge_lca_multi into bzr.dev" ? [21:09] guilhembi: 1.7.1rc1 is out and in ~bzr-beta-ppa [21:09] I need to merge it back, though the pqm was wedged for a bit [21:10] jam: uh, merge it back... to where? [21:10] guilhembi: it is in the 1.7 branch, I need to merge that into bzr.dev [21:11] jam: 1.7.1rc1 is out? where (bazaar-vcs.org only mentions 1.7) ? [21:11] it is available at https://launchpad.net/bzr/1.7/1.7.1rc1 I just need to update the other pages === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.7 now available! please test bzr-1.7.1rc1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [21:28] Any people here who use looms? [21:28] I'm wondering if they solve my problem or not. [21:29] I have a sequence of patches. and I want to be able to get them in two forms: [21:29] 1) Independent patches against the base revision. These would be suitable for sending to upstream if I have no idea of the order that upstream is going to take the patches in. [21:30] 2) A sequence of patches against revision. These patches would be suitable for applying when creating a distribution package. [21:30] I know how to do #2 using separate branches. [21:30] I'm not sure how to do either one using looms. [21:31] abadger1999: looms naturally satisfies number 2 [21:32] james_w: Excellent. How do I convert the threads into the patches I need? [21:32] Is it a semi-manual process? [21:33] abadger1999: export-loom I think is the command [21:35] james_w: hmm... Okay. That gets me from loom to branches. [21:36] maybe the command you want doesn't exist yet then [21:36] I would like the same command as you, so I'll write it one day :-) [21:36] :-) [21:39] Ah. Okay for #2 this will work: [21:39] bzr diff -r thread:lp:trac-bzr..thread:no-repo [21:39] bzr diff -r thread:no-repo..thread:get-ancestry [21:39] Generates two patches with the changes stacked on top of each other. [21:39] I foresee #1 being harder to achieve. [21:39]