[00:09] <lifeless> mtaylor: btw
[00:09] <lifeless> mtaylor: please tell me if my fix works for you in builddeb
[00:10] <mtaylor> lifeless: I will check it
[00:10] <lifeless> mgz: yes, interbranch multimethod was extracted from previously plan branch methods
[00:10] <lifeless> mgz: most of the tests are just copies of the old branch ones
[00:13] <mgz> thanks.
[00:13] <mgz> lp:launchpad still hasn't finished branching...
[00:14] <lifeless> harh
[00:14] <lifeless> its a tad big
[00:16] <mgz> ha! ran out of disk space
[00:17] <lifeless> ><
[00:17] <lifeless> are you hoping to patch launchpad ?
[00:18] <lifeless> mgz: ^
[00:19] <mgz> I thought I'd see if the problem with group membership being seen as more important than direct subscription was something as simple as a badly-ordered if chain
[00:20] <lifeless> ah cool
[00:20] <lifeless> you'll want about 1.5GB
[00:20] <mgz> I think I'll check via the web interface before finding a big enough drive :)
[00:20] <lifeless> + a bit of slack
[00:21] <lifeless> I have a 4G VM
[00:21] <lifeless> with 550M free in it, to do LP development
[00:21] <lifeless> I documented that on the dev.launchpad.net wiki under running/vm, or something like htat
[00:22] <lifeless> I'm off to do various things; shall be back online periodically.
[00:26] <exarkun> I'm having difficulties merging some changes from one branch into another.
[00:27] <exarkun> http://pastebin.com/PQ2hFcCd
[00:27] <exarkun> Is something wrong with that?
[00:30] <mgz> branching rev 0 isn't something I've every tried personally.
[01:02] <spiv> Good morning.
[01:03] <spiv> exarkun: there's a bug about that
[01:03] <spiv> exarkun: are you aware that branching rev 0 is essentially the same as doing "bzr init"?
[01:04] <spiv> exarkun: IIRC there's a bug that rev 1 cannot be a merge commit.
[01:07] <spiv> exarkun: See https://bugs.edge.launchpad.net/bzr/+bug/242175, and the bug it links to (and the bugs linked to from its comments...)
[02:25] <exarkun> How about this one, http://pastebin.com/h1Z2U7Qk
[02:25] <exarkun> It seems odd to get conflicts when merging like that.
[02:27] <spiv> exarkun: that seems odd to me too
[02:27] <spiv> exarkun: file a bug :/
[02:42] <exarkun> will do
[02:42] <exarkun> I don't know if I'll file all the bugs I ran into tonight :/
[02:42] <exarkun> it's five so far, that seems excessive
[02:43] <exarkun> I can't seem to bring myself to try isolating the most recent
[03:00] <spiv> Oh, hmm.
[03:01] <spiv> exarkun: oh!
[03:02] <spiv> exarkun: I'm silly; it would be because "bzr merge -r 2..16" doesn't include the changes from 1->2.
[03:02] <exarkun> :(
[03:02] <exarkun> That explains some issues, I guess
[03:03] <spiv> exarkun: Usually the way you'd express "merge up to point X" is by simply "bzr merge -r X"
[03:04] <spiv> I think we could give better feedback in this case, perhaps.
[03:04] <exarkun> This whole thing I'm doing has problems.  But on the other hand, I'm done now, so I hopefully I don't have to care.
[03:04] <spiv> Like explicitly announcing if the merge is a cherrypick.
[03:11] <lifeless> mmm sadness
[03:11] <lifeless> bzr-builddeb has no direct merge-upstream tests
[07:07] <spiv> Hmm, I think I may have stumbled upon a reason why 'get_stream_for_missing_keys' is needed even for initial fetches which.
[07:07] <spiv> ...which should be able to easily enough send a complete stream.
[07:08] <lifeless> ghosts?
[07:20] <spiv> lifeless: overly aggressive calculation of "uninteresting" chk root nodes.  The logic doesn't seem to allow for the possibility that two different inventories might refer to the same chk_maps.
[07:20] <spiv> Still digging into the details.
[07:59] <vila> hi all
[08:19] <aidalgol> I'm using the development version of a project that uses Bazaar.  Instead of pulling updates from the repository on the Internet onto both my laptop and desktop, I want to pull them from the Internet to only my dekstop and then push them to my laptop.  How do I do this?
[08:19] <aidalgol> (Without using shared directories.)
[08:19] <lifeless> on your desktop run bzr pull
[08:19] <aidalgol> Right, figured that much out. :)
[08:19] <lifeless> then bzr push bzr+ssh://laptop/path/to/branch
[08:20] <aidalgol> Is there a way to not use SSH?
[08:20] <lifeless> finally on the laptop run 'bzr update' if there is a tree where the branch is (if there is the push will alert you to that fact)
[08:20] <lifeless> btw, shared repositories are totaly unrelated to your request; can I ask why you said you didn't want to use them?
[08:20] <aidalgol> Shared?
[08:20] <aidalgol> I haven't heard of that.
[08:21] <lifeless> ah sorry
[08:21] <lifeless> I misread, you said 'shared directories'. My bad - ignore my question.
[08:21] <lifeless> uhm yes, you can use any protocol bzr supports.
[08:21] <aidalgol> lol OK :)
[08:21] <lifeless> But ssh is best. Is it a problem for you?
[08:21] <aidalgol> I don't want to set up ssh on my system.
[08:22] <aidalgol> I only do this kind of thing at home on a fairly secure LAN.
[08:22] <aidalgol> So, for syncing my files, I've been using Unison's unsecure protocol.
[08:22] <aidalgol> Because I have good physical security.
[08:23] <lifeless> its not about security
[08:23] <lifeless> ssh runs the bzr server at the far end so its very very effiicent
[08:23] <aidalgol> I'll take a look at the list of protocols bzr supports.
[08:24] <maxb> In this case, the recommendation to use ssh is not about security, but because it's an excellent way of making two machines talk to each other
[08:24] <maxb> Unless you're stuck running Windows?
[08:25] <aidalgol> Convenience is more important than efficiency for me.
[08:25] <aidalgol> maxb: No, thank heavens.
[08:27] <maxb> Setting up ssh on Linux *is* convenient
[08:27] <maxb> Because every distro provides it packaged
[08:27] <aidalgol> bzr serve looks like a good option.
[08:28] <aidalgol> I agree it's convenient, but I'd rather not run a system daemon if I don't have to.
[08:41] <aidalgol> What's the LOCATION syntax?
[08:41] <aidalgol> I ran bzr serve --port=X on my desktop.
[08:42] <aidalgol> Not I need to run bzr pull [something] on my laptop, right?
[09:13] <mwhudson> hmm
[09:13] <mwhudson> i seem to be getting bzr bugmail now
[09:13] <lifeless> \o/ ?
[09:13] <mwhudson> You received this bug notification because you are a member of bzr-qa, which is subscribed to Bazaar.
[09:13] <lifeless> oh right
[09:13] <lifeless> thats unexpected ;)
[09:13] <lifeless> it might be because you're in bazaar-canonical.
[09:13] <lifeless> I think the group layout isn't quite right.
[09:14] <mwhudson> err
[09:14] <lifeless> are you in bazaar-canonical ?
[09:14] <mwhudson> i'm in ~bzr, indirectly, which owns ~bzr-qa, but i'm not _in_ ~bzr-qa
[09:14] <lifeless> oh
[09:14] <mwhudson> lifeless: yeah
[09:14] <mwhudson> so i don't know why i'm getting these emails
[09:14] <lifeless> right, so poolie rearranged things this morning
[09:15]  * mwhudson looks at some headers
[09:15] <lifeless> ~bzr is meant to give you that bugmail anyway
[09:18] <mwhudson> i guess i'll see how much mail this results in before complaining further :)
[09:19] <lifeless> I'll try to look tomorrow
[09:20] <lifeless> feel free to drop me a mail your midday if its driving you batty ;)
[09:23]  * lifeless changes a few things, just because
[09:27] <hayalci> Hi, I can't use recorded passwords with bzr-svn
[09:27] <hayalci> I tried authentication.conf
[09:28] <hayalci> and tried some settings, but bzr either asks for password, or gives the error message :
[09:28] <vila> hayalci: svn handles its own cache which bzr-svn is able to use
[09:28] <hayalci> bzr: ERROR: Permission denied: ".": OPTIONS of 'http://...." : authorization failed: Could not authenticate to server: rejected Basic challenge
[09:29] <vila> hayalci: do one successful auth with svn and things should be fine
[09:31] <hayalci> vila: thanks for the info
[09:32] <hayalci> that worked with a tweak. I am using KDE, and kwallet for password storage. While svn can store and access passwords in kwallet, bzr-svn couldn't
[09:33] <hayalci> after forcing svn to not use kwallet, and storing password in a file, bzr-svn could access the svn repo
[09:33] <hayalci> Actually, that's ok with me. That password is not important.
[09:38] <vila> hayalci: may be worth filing a wishlist bug against bzr-svn for the record
[09:57] <poolie_> spiv, hi?
[09:59] <poolie_> does https://bugs.edge.launchpad.net/bzr/+bug/601798 ring any bells for you?
[10:00]  * spiv looks
[10:02] <spiv> poolie_: that's weird, it looks like 559436, but that was fixed in exactly 2.1.1, which is what they are running
[10:03] <spiv> Or at least, that's when NEWS claims it was fixed...
[10:04] <spiv> The NEWS file in -rtag:bzr-2.1.1 agrees, though.
[10:05] <poolie_> sorry i was offline, more maverick/hardware problems :-(
[10:06] <lifeless> poolie_: what did they say ?
[10:09] <spiv> poolie_: ouch :(
[10:09] <spiv> poolie_: I left a comment on the bug with my thoughts
[10:11] <poolie_> thanks
[10:11] <poolie_> lifeless, it's working now
[10:11] <lifeless> poolie_: \o/
[10:11] <poolie_> burned a cd at low speed, booted from that, reset bios back to ahci
[10:11] <poolie_> despite appearances it can boot from cds in ahci mode, they just appear as a different device
[10:11] <lifeless> glub
[10:12] <lifeless> ah
[10:14] <lifeless> vila: tell me about this config lock patch
[10:14] <lifeless> vila: where do you think its up to, is it ready, are you happy with it?
[10:15] <vila> lifeless: given the discussions I'm more inclined to wait for the sprint to discuss it, there so many things to do with configs that I didn't even mention in the patch that I think we need to talk about
[10:15] <vila> lifeless: the patch itself...
[10:16] <vila> well, it needs at least to be split (once or several times) to make my intents and constraints clearer
[10:17] <vila> using a transport for example was required to use lockdir but also a good thing in itself if we want all IOs to go thru a transport object
[10:17] <vila> _get_parser() is currently abused by tests as a way to create a config file and we need something better
[10:18] <lifeless> whats wrong with that ?
[10:18] <lifeless> by which I mean
[10:18] <lifeless> what problems does that cause
[10:18] <vila> overall, far too many things stuffed in this patch were not related to the bugfix itself
[10:19] <vila> _get_parser() ? Well, in some cases if the config is not empty, supposing that it came from a file make things simpler
[10:20] <vila> I don't remember the exact context/failing test, but at one point it was obvious/knee-jerk that this wasn't worth maintaining (I tried to nevertheless)
[10:21] <vila> I think it was related to the ability to use _parser.reload() which itself requires a file name rather than rebuilding a configobj object
[10:22] <vila> rebuilding the configobj object helped with failures with the intrumented one (hence the addition of reload() there)
[10:22] <vila> and this last addition was a bit silly since its implementation is a no-op
[10:23] <vila> kind of: ok this bug fix is simple: oh wait, I need a small refactoring here, oh wait, unrelated tests are failing, one more bit of refactoring, oh wait, etc
[11:16] <poolie_> hi there vila
[11:16] <poolie_> and good night
[11:16] <poolie_> vila, would it make any sense to send an rfc email about config locking just to summarize the progress at a higher level than an mp?
[11:18] <vila> poolie_: it would, I have a list of other points I haven't mentioned so far regarding config
[11:23] <lifeless> the python-ideas thread on their use of hg makes me sad
[11:23] <lifeless> consensus emerging seems to be to not accept branches from non-committers.
[11:23] <lifeless> !
[11:25] <poolie_> really
[11:25] <lifeless> really
[11:25] <lifeless> bai
[11:27] <mwhudson> lifeless: !
[11:28] <lifeless> yeah
[11:28] <mwhudson> doesn't that almost completely miss the point?
[11:28] <lifeless> 'pulling all the patches generates too much noise people won't review, so people should make a single patch and put that in the bug tracker'.
[11:28] <lifeless> mwhudson: you'd think so.
[11:28] <mwhudson> err
[11:28] <mwhudson> does hg not have merge --preview?
[11:28] <mwhudson> or some moral equivalent
[11:40] <jamesh> I think there are lots of people who still want linear histories
[11:40] <jamesh> even though they're using DVCS
[11:40] <jamesh> they consider the extra non-linear history to be noise rather than valuable information
[11:42] <lifeless> yes
[11:42] <lifeless> add to that
[11:42] <lifeless> hg doesn't do nonlinear history - it logs all left-aligned, all patches show.
[11:45] <jamesh> they should fix that
[12:53] <lifeless> gnight
[14:33] <knielsen> Hi, I'm looking for docs on bzr formats (bzr 2.1.1), `bzr info` says format: rich-root-pack and `bzr checkout` says "on-the-fly conversion from RepositoryFormat2a() to RepositoryFormatKnitPack4()". But I didn't find info about those formats in docs (http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/formats-help.html)
[14:33] <knielsen> anywhere I can find info on that/those formats?
[14:36] <spiv> knielsen: 'RepositoryFormat2a()' is the internal name for the '2a' format
[14:36] <spiv> knielsen: and 'RepositoryFormat2a()' is the internal name for the 'rich-root-pack' format
[14:37] <knielsen> spiv: right, so RepositoryFormatKnitPack4 and rich-root-pack are two different names for the same format?
[14:37] <spiv> Oops, copy-and-paste screwup
[14:38] <spiv> Right, 'RepositoryFormatKnitPack4' is the same format as 'rich-root-pack'
[14:38] <spiv> 'rich-root-pack' is quite old, it dates back to bzr 1.0
[14:38] <knielsen> spiv: right, so the question is, where can I read about that rick-root-pack format?
[14:38] <knielsen> ok, yes I suspected that it was old, that's the main info I need, thanks
[14:38] <spiv> Basically you should be using '2a' for everything.
[14:39] <spiv> Please file a bug about the documentation being a bit lacking there.
[14:40] <knielsen> ok, will do
[14:40] <spiv> Thanks!
[14:40]  * spiv goes to bed
[14:42] <parthm> knielsen: there is bug #567064 about improving the message.
[14:45] <spiv> parthm: that's a related but different bug, I think
[14:47] <parthm> spiv: yes. i suppose it could avoid using internal names + give a suggestion of upgrading to 2a.
[15:08] <GaryvdM> Hi mgz
[15:14] <knielsen> filed as https://bugs.launchpad.net/bzr/+bug/601912
[16:26] <rioch> I've written an app which I now want to use bazaar to do version control. If I do bzr init <project> will it pick up everything that is already there, or should I create it blank and then add the files and commit them?
[16:29] <GaryvdM> rioch: You can do bzr init in you existing dir. You will then need to do bzr add and bzr commit.
[16:31] <rioch> GaryvdM: thanks :)
[16:52] <rioch> I created a branch with bzr init, then decided to start again and deleted the project, copied the files across from a backup, and now when I do bzr init I get this error: bzr: ERROR: Already a branch: ".".
[16:55] <maxb> Sounds like you deleted all the visible contents of a directory, but kept the .bzr subdir
[16:56] <rioch> maxb: I thought that too, but that's gone as well.
[16:57] <maxb> That error message is a clear indication there is a .bzr in the location you are trying to init
[16:58] <rioch> maxb: well, I emptied my trash and now it works, so maybe it was aware I deleted it?
[20:17] <lifeless> morning
[20:25] <GaryvdM> Hi lifeless
[20:27] <mgz> hey all.
[20:27] <GaryvdM> Hi mgz
[20:28] <GaryvdM> mgz: re py2exe extraction - It work for just bzr, but not with plugins. I've not debug much...
[20:29] <mgz> you also have a slight problem with both me and you changing the bzr setup.py and those new bits not being copied across yet
[20:29] <mgz> easy to fix though.
[20:29] <GaryvdM> I'm working on been able to specify revision specs.
[20:29] <lifeless> \o/
[20:29] <GaryvdM> mgz: Yes - I'll fix that when I get it to work. :-)
[20:34] <mgz> I've just been tracking down the double-auth thing from the other day, it's a mess of abstractions.
[20:35] <mgz> basic issue is the http connection creation is deeper than the try-smart-protocol-then-dumb, so if the first bit fails it throws away everything it has set up so far including the auth information
[20:36] <mgz> also it doesn't store the credentials unless it actually gets a 200, so 401-404 will raise without recording that it actually got past the auth correctly.
[20:36] <lifeless> \o/
[20:37] <mgz> so, it's what I expected, which I might be able to fix, plus a bigger issue in bzrdir that I have no idea for.
[20:38] <lifeless> whats the bigger issue?
[20:43] <mgz> well, when it's probing for formats, it has no concept of an http connection
[20:43] <lifeless> yes
[20:44] <mgz> so I don't see any clear way of preserving the auth credentials, that are stored on the connection, across two seperate probes
[20:44] <mgz> except some global store, which is sort of what the text file on disk is.
[20:44] <lifeless> the probes don't make a new transport object
[20:45] <iocor> how do I find out what changed between bzr version 1.18.1 and 2.1.1
[20:45] <mgz> but the auth stuff is on the request, not the transport
[20:46] <lifeless> iocor: read the NEWS file for 2.1.1
[20:46] <iocor> lifeless: is that online anywhere?
[20:47] <GaryvdM> iocor: http://doc.bazaar.canonical.com/latest/en/release-notes/index.html
[20:48] <lifeless> sure
[20:48] <mgz> ah, or is it...
[20:48] <lifeless> or http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/head:/annotate/NEWS
[20:48] <lifeless> I think thats the url anyway, :)
[20:50] <GaryvdM> http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/annotate/head:/NEWS
[20:50] <GaryvdM> But it breaks because annotate takes to long.
[20:50] <mgz> 's on ConnectedTransport._shared_connection which I guess I'll poke and see if it survives
[20:53] <mgz> ...does seem to have the same id
[20:54] <lifeless> mgz: thats a feature
[20:54] <lifeless> tcp is slow.
[20:54] <lifeless> reuse is good.
[20:54] <mgz> goodie, so, it's cleverer than I feared
[20:55] <lifeless> I like to think of it as simpler.
[20:55] <lifeless> :P
[20:55] <mgz> if it was simple, wouldn't have taken this long to find out ;)
[21:12] <mgz> ...now I have to look into writing http tests that don't leak horribly
[21:12] <lifeless> \o/
[21:14] <mgz> semi-related, if you get the username or password wrong is it expected to get:
[21:14] <mgz> bzr: ERROR: Invalid http response for http://float.endofinternet.org/bazaar/testauth/.bzr/branch-format: Unable to handle http code 401: Authorization Required
[21:15] <mgz> it seems... unhelpful.
[21:15] <lifeless> mmm, I wouldn't say expected.
[21:15] <lifeless> if its a single line then its just the regular exception-printout
[21:26] <iocor> i've got some pythoncode that uses bzrlib, and we're attempting to make commits, and for some reason we're unable to make updates to files
[21:26] <iocor> anyone got any ideas why?
[21:26] <lifeless> paste the code
[21:26] <lifeless> I have a few minutes, I'll have a peek for you
[21:26] <iocor> thanks man
[21:27] <iocor> http://dpaste.com/214900/
[21:27] <iocor> this is the commit function
[21:28] <iocor> http://dpaste.com/214902/ class initialiser
[21:28] <iocor> http://dpaste.com/214903/
[21:28] <iocor> function to update files
[21:29] <lifeless> ok, so you don't have a tree on disk ?
[21:30] <iocor> calling commit is meant to write the tree out to disk
[21:30] <lifeless> uhm
[21:30] <lifeless> some terms
[21:30] <GaryvdM> iocor: small nit pick: line 16 of http://dpaste.com/214900/ should not be necessary.
[21:31] <GaryvdM> "self.b = bzrlib.branch.Branch.open(self.b.base)"
[21:31] <lifeless> iocor: a branch is a line of development
[21:31] <lifeless> iocor: a Tree is a single collection of the users files, either editable (a WorkingTree) or immutable (a RevisionTree)
[21:32] <lifeless> iocor: a 'commit' takes a Tree and puts it into the branch's Repository, and updates the branch last_revision.
[21:32] <lifeless> iocor: so if you have a WorkingTree, to commit you just do 'tree.commit()'
[21:32] <iocor> lifeless: ok, so I'm looking to take in some changes, apply them to the current branch to get a new branch
[21:33] <iocor> or
[21:33] <iocor> an update to the branch
[21:33] <iocor> it's very simple linear style committing
[21:34] <lifeless> iocor: your code won't work properly prior to 1.18 anyway, I would just not support it.
[21:34] <iocor> also, I'm using bzr 2.1.1 but the branch isn't getting updated
[21:34] <lifeless> not your fault, just bzrlib internals.
[21:34] <lifeless> what is in _update_tree ?
[21:34] <iocor> and the #as of 1.18 thing isn't executed
[21:34] <iocor>         self.PrevTree = self.TransPrev.get_preview_tree()
[21:34] <iocor> one line
[21:35] <iocor> also, I inherited this system and it isn't particularly well documented or functional on anything other than bzr 1.18.1
[21:35] <iocor> at all
[21:35] <lifeless> uhm
[21:35] <lifeless> so that one line
[21:35] <lifeless> is discarding all the data you've got
[21:36] <lifeless> to work with PreviewTree there is a strict sequence you have to follow
[21:36] <lifeless> 1) make a Transformpreview
[21:36] <iocor> (happens at class init)
[21:36] <lifeless> 2) call methods on it to create/move/delete files
[21:36] <iocor> lifeless: I note that creating files and deleting files works just fine
[21:36] <lifeless> 3) call get_preview_tree()
[21:36] <iocor> modifying their contents doesn't
[21:37] <iocor> ohic
[21:37] <lifeless> 4) call that-tree.commit()
[21:37] <iocor> so in fact, this is pretty broken?
[21:37] <iocor> aaaaaaaaaaaaaaaaaaaaah
[21:37] <lifeless> I may be wrong
[21:37] <lifeless> but looking at _PreviewTree.__init__
[21:37] <iocor> lifeless: is this going to be massively painful to fix?
[21:37] <lifeless> I don't see why
[21:38] <lifeless> just don't call _update_tree where you are
[21:38] <iocor> ok
[21:38] <lifeless> and don't call self.PrevTree = self.TransPrev.get_preview_tree() in init
[21:38] <lifeless> instead, do that line in your commit
[21:39] <iocor> I have a merge function also
[21:39] <iocor> should I call it there?
[21:40] <lifeless> actually
[21:40] <lifeless> I may be wrong about risk of making new trees
[21:40] <lifeless> jus tshove a self.PrevTree = self.TransPrev.get_preview_tree() call into your commit function
[21:42] <iocor> and don't remove the updatetree calls elsewhere?
[21:42] <lifeless> yeah
[21:42] <lifeless> see how that works
[21:42] <lifeless> can I ask, what this is for?
[21:42] <iocor> to cut a long story short, an online ide for python that controls robots and has to be deployed in an environment where we can't install software, so it's web-based
[21:43]  * lifeless whistles
[21:43] <lifeless> thats pretty cool
[21:43] <iocor> :D
[21:44] <iocor> lifeless: http://studentrobotics.org
[21:44] <iocor> :O
[21:44] <iocor> :OI
[21:44] <iocor> :O
[21:44] <iocor> I think
[21:44] <iocor> you just fixed it
[21:45]  * iocor waits for the tests to finish
[21:45] <iocor> oh my god
[21:45] <iocor> lifeless: I owe you all my internets for a wek
[21:45] <lifeless> glad I could help
[21:49] <iocor> :D:D:D:D
[21:56] <GaryvdM> Bla - just realised, the feature I've been planing for the last hour, was already implement by Ian, just not in use :
[21:56] <GaryvdM> :-)
[21:56] <lifeless> :P
[22:00] <fullermd> Superrelativistic implementation FTW.
[22:03] <lifeless> nah
[22:03] <lifeless> guido's time machine
[22:04] <lifeless> dude just can't seem to keep it locked up
[22:05] <fullermd> Well, it's a time machine.  If you forget to lock it up ONCE, it's the same as never locking it up.
[22:11] <GaryvdM> Bla - SEACOM down for 6-8 days: http://www.seacom.mu/news/news_details.asp?iID=143
[22:12] <GaryvdM> I nice reminder of how slow SAT3 is.
[22:45] <GaryvdM> For Ian's new window installer build script, he added the ability to define more than one series.
[22:45] <GaryvdM> See http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/annotate/head:/bazaar_releases.py
[22:46] <GaryvdM> For 2.2 I need to specify defined revisions.
[22:46] <GaryvdM> But for .dev, I want it to use the latest version for each plugin.
[22:47] <GaryvdM> You can specify a revision spec per Project/Plugin object.
[22:49] <GaryvdM> But the way that is currently defined, you can only define the 2 series to have the same plugin versions, as they are shared.
[22:50] <GaryvdM> I'm not sure how to change this so that I can have different plugin versions, but not have to repeat plugin details, and be syntactical clean.
[22:52] <GaryvdM> Maybe add a copy_write method, define the plugins globally, and copy_write with the specific revision for the series.
[22:53] <GaryvdM> Any better ideas?
[23:13] <poolie> hi GaryvdM
[23:13] <poolie> hi jam
[23:13] <GaryvdM> Hi poolie
[23:14] <mgz> hm, got another mail with team membership overriding direct subscription for X-Launchpad-Message-Rationale and bottom note
[23:14] <lifeless> heh
[23:14] <lifeless> hi poolie
[23:15] <mgz> as I completely failed to branch launchpad, guess I better just file a bug
[23:15] <lifeless> poolie: I was out by 2 hours on my thing this morning :O
[23:19] <poolie> in which direction
[23:19] <lifeless> just finished