[00:39] <mwhudson> jelmer: still here?
[00:44] <jelmer> mwhudson, somewhat
[00:45] <mwhudson> jelmer: python2.4, bzr 1.16.1 (1.17dev soon maybe), bzr-svn 0.6.3, subvertpy 0.6.8
[00:45] <mwhudson> jelmer: all should work together ok?
[00:46] <jelmer> mwhudson, yes
[00:48] <mwhudson> jelmer: subvertpy.tests.test_properties.TestProperties.test_time_from_cstring fails, should i worry?
[00:48] <jelmer> not really, I think that's still the same test
[00:48] <mwhudson> ok
[00:55] <jfroy> jelmer: new bug, never seen this before: https://bugs.launchpad.net/bzr-svn/+bug/394527
[01:04] <poolie> hello garyvdm
[01:06] <garyvdm> Hi poolie
[01:08] <lifeless> poolie: I'm off for a bit as discussed
[01:17] <jfroy> jelmer: I'm not sure I understand your comment on the bug.
[01:17] <jfroy> But does it basically mean I should make a smaller commit (a batch of commits)?
[01:30] <mrooney> hey bzr friends, it looks like the Limitations section of http://bazaar-vcs.org/BzrForeignBranches/Subversion is out of date (some of the limitations are addressed which is great!)
[01:31] <mrooney> jelmer: specifically I noticed the first and last subversion file properties, this is your domain, correct?
[01:46] <mwhudson> the bzr-svn tests still segfault :(
[01:48]  * igc back
[02:04] <garyvdm> igc: I've just landed my tree widget into lp:qbzr
[02:05] <igc> garyvdm: excellent! I'll take a look tonight
[02:06] <garyvdm> and I'm busy changing qcommit, qadd, and qrevert to use it.
[02:07] <igc> garyvdm: cool. So that means I can add files in a directory yet to be added when that's done?
[02:07] <garyvdm> igc: Yes - I've got it showing the contents of a unversioned dir.
[02:08] <igc> garyvdm: hooray!
[02:08] <garyvdm> But getting it to decide how to pass the parameters to the subprocess is a bit of a challenge
[02:10] <garyvdm> If you change the selection in a subdir, it needs to pass the subitems and say --no-recurse. And if you don't change any thing, it must not pass the sub items, and not pass --no-recurse.
[02:11] <garyvdm> And if you have mix????
[02:11] <garyvdm> igc ^^^
[02:12] <igc> garyvdm: why is no-recurse needed when a subitem is selected? If that itself was a subdir, I'd expect it to recurse from there?
[02:13] <garyvdm> If you have 1 sub items that is deselected, you need to pass no-recures, and pass all the other items that remained selected.
[02:13] <garyvdm> igc ^^^
[02:14] <igc> garyvdm: ok, I'll give it a go tonight. Thanks for getting this going
[03:27] <RenatoSilva> https://bugs.eclipse.org/282226
[03:33] <bob2> is there a bzr.dev-as-2a branch somewhere?
[03:36] <spiv> bob2: Probably only as throw-aways on a couple of devs laptops.
[03:37] <spiv> I don't think we want to start inviting people to make rich-root revisions that they might submit back to us until bzr.dev itself is in a rich-root format.
[03:37] <bob2> ah, fair enough
[03:40] <poolie> jelmer: are you still here?
[03:56]  * igc lunch
[04:50] <poolie> spiv, hello! how's it going?
[05:59] <spiv> poolie: good, I have InterDifferingSerializer and streaming fetch sharing the same code for generating new roots.
[06:02] <spiv> I got a bit alarmed at https://bugs.edge.launchpad.net/bzr/+bug/196080/comments/1 this morning
[06:36] <poolie> yeah, i saw your reply
[06:36] <lifeless> it would be nice if fixed bugs could not be touched except by team members
[06:42] <poolie> not reopened?
[06:44] <lifeless> not touched, even comments on fixed tasks are noise - I'd much rather the user get directed to open a new bug
[06:45] <poolie> cos i just reopened a fixed bug in launchpad to point out it's actually not fixed
[06:45] <spiv> Well, perhaps after say 3 months?
[06:45] <lifeless> spiv: something.
[06:45] <poolie> arguably i should have opened a new one but that's kind of noise too
[06:45] <poolie> some kind of warning would be good
[06:45] <lifeless> poolie: true, OTOH the lp dev could: dup it, reopen the original.
[06:45] <spiv> Certainly I wouldn't immediately assume it's wrong for a user to reopen a bug within a week, but for sufficiently old bugs it's almost certainly better to open a new bug.
[06:46] <lifeless> I have a strong bias to 'always open new bugs'
[06:46] <lifeless> because dupping is easy
[06:47] <spiv> Yeah, I flied a bug about this today.  I think there should be a way to take a comment and automatically turn it into a new bug (and remove/hide the original comment).
[06:47] <spiv> So that splitting becomes easier, although still not as easy as marking a dupe.
[06:48] <spiv> Oh, interesting, read_inventory_from_string doesn't work with CHKSerializers.
[06:48] <spiv> Or perhaps I'm feeding the wrong thing to it.
[06:49] <spiv> No, I don't think I am...
[06:50] <lifeless> spiv: it can't
[06:50] <lifeless> spiv: or rather, its used in places that want to do one IO to get an inventory and so we chose to make it error, IIRC.
[06:50] <spiv> Hmm, well, the code we had is feeding the wrong thing, rather than my code per se ;)
[06:57] <stefanlsd> garyvdm: congrats on getting qbzr 0.11 into karmic :)
[06:57] <garyvdm> stefanlsd: Thanks for all the help.
[06:58] <garyvdm> stefanlsd: I guess I got to find some other packaging to do :-)
[07:00] <stefanlsd> garyvdm: np! yeah!  lots of stuff to do!   :)
[07:02] <lifeless> poolie: http://paste.ubuntu.com/207940/
[07:02] <spiv> Ah, I see, get_stream_for_missing_keys is producing fulltext inventories...
[07:04] <poolie> typo introducead
[07:05] <vila> hi all, I'll be barfu (back after reboot for update :)
[08:24] <lifeless> gnight
[08:25] <johnskulski> I have shelved some changes. then i made a change and committed. now when i try to unshelve I get an error about it not merging cleanly. How can I go forward?
[08:35] <lifeless> unshelve --force ?
[09:10] <lifeless> poolie: you might enjoy  http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html
[09:24] <vila> poolie: regarding bug #261770, it seems that both users really wanted 'bzr revert -rxxx' even if they tried 'bzr uncommit -r xxx' they both wanted to follow that by 'bzr revert'
[09:24] <vila> poolie: so what fix do you think about here ? Giving a proper error message pointing to bzr revert ?
[09:25] <vila> poolie: making uncommit -r accept non left-hand revisions seems wrong to me
[09:25] <lifeless> vila: why ?
[09:25] <vila> if it's not in my left-hand ancestry I didn't commit it, how come I can uncommit it ?
[09:26] <lifeless> someone pushed to it pivoting your history
[09:26] <lifeless> so you may well have committed it
[09:26] <lifeless> also, I don't see why not being the committer should have anything with the ability to uncommit
[09:28] <vila> because, to me, uncommit means: "Oh wait, that (these) commits were wrong, put me in a state where I can commit again (i.e. don't change a single bit in working tree, the state is fine, but put me in the ancestry graph at *that* point)
[09:28] <lifeless> sure
[09:29] <lifeless> I don't see why we should cripple its ability
[09:29] <vila> what the reporters want (in *both* cases) is: give me the working tree at that revision
[09:29]  * igc dinner
[09:29] <lifeless> vila: well, I'd investigate why they thought uncommit would change the wt
[09:29] <lifeless> vila: but that seems orthogonal to me
[09:30] <vila> lifeless: full agreement, hence my question
[09:30] <lifeless> vila: let me put this another way
[09:30] <lifeless> vila: given that uncommit == 'bzr pull . -r <arg> --overwrite' minus the tree changes
[09:31] <lifeless> vila: why put additional constraints on it
[09:32] <lifeless> well, its really EOD for me now.
[09:32]  * lifeless puts the laptop away
[09:32]  * vila tries the desktop
[09:32] <vila> lifeless: I see, have a good eveniing
[10:09] <poolie> hi vila
[10:10] <vila> hey poolie !
[11:05] <vila> jam: too early, go back to sleep !
[14:09] <jam> vila: definitely too early, just my machine losing and then gaining network access :)
[14:10] <vila> jam: :-D
[14:10] <vila> good morning jam (should be better now :-)
[14:10] <vila> jam: It could have been your son waking you up and you not finding your sleep anymore :-)
[14:11] <jam> yeah
[14:11] <jam> that certainly happens sometime
[14:11] <jam> but I usually don't have trouble finding my sleep
[14:11] <jam> my wife does, though
[15:33] <mozmck_work> is it possible/recommended to have multiple unrelated projects in one repository?
[15:34] <ddaa> it is possible
[15:35] <mozmck_work> I have numbers of personal projects I am working on, and my thought is that it would be nice to have my whole projects directory in one repository so I can do a single commit or update to save work on them all at once.
[15:35] <ddaa> that's something different than putting different projects in one repository
[15:35] <mozmck_work> ok, what would be the best way to do that?
[15:36] <ddaa> the short answer is: you can't
[15:36] <ddaa> the slightly longer is: you could look at the scmproj plugin which might do something close to what you want
[15:37] <ddaa> the longer is: "I'm not sure you are clear on what you want to do. Why do you want to do commits in unrelated projects at once?"
[15:38] <ddaa> What we call that in bzr land is "nested trees". And they are not supported yet, with no defined timeline.
[15:39] <ddaa> The main use case for nested trees tracking is recording which revisions of multiple interdependent projects go toghether.
[15:39] <ddaa> Unless you have a specific need for something like that, I would just write myself some shell scripts.
[15:40] <mozmck_work> ok, I have a projects directory with 10 or 20 different projects. PIC micro firmware, computer software etc.
[15:40] <mozmck_work> sometimes I may work on 3 or 4 or more of these in a day
[15:41] <mozmck_work> they are currently not in version control at all, but I want to put them there for revision history, and because I work on them on 3 or so different computers from several locations.
[15:42] <mozmck_work> my thought was if I could just put the whole projects directory as a repository I could commit everything under it at once.
[15:42] <dash> mozmck_work: are you changing everything at once? would they all hav ethe same commit message? :)
[15:43] <mozmck_work> hmmm, the commit message would be a problem I guess.
[15:43] <dash> i guess i'm not understanding why you'd want to commit to separate projects simultaneously
[15:43] <mozmck_work> I should probably just commit each one when I get done with it.
[15:43] <dash> probably :)
[15:44] <mozmck_work> well, to save time and having to remember which ones I even worked on!
[15:44] <ddaa> The recommended style in bzr is actually: commit whenever you have a "good" state, or a state you want to share.
[15:45] <dash> mozmck_work: that sounds weird :)
[15:45] <dash> why wouldn't you commit after running your tests?
[15:45] <mozmck_work> yeah, but I'm working alone.
[15:46] <ddaa> It's recommended to do multiple commits on a branch within a single session, as dash said, after runnig the tests.
[15:46] <mozmck_work> well, some of these are for work, and I work on them at work and at home.
[15:46] <dash> ok?
[15:46] <mozmck_work> so I use a thumb drive right now to bring stuff back and forth.
[15:46] <dash> sure
[15:47] <mozmck_work> and I forget at times which computer has the newest version of which program.
[15:47] <mzz> bzr can certainly be useful for that kind of sharing, but the recommended way to use it is to commit considerably more frequently than once a day when you're moving between systems
[15:47] <mozmck_work> that's what I'll need to do.
[15:47] <dash> mozmck_work: why are you waiting so long to commit?
[15:48] <mzz> (I do use bzr to prevent getting confused and having multiple diverging versions of the code spread across systems)
[15:48] <ddaa> mozmck_work: note, you will not NEED to commit more often. We say it's good practice, and doing so gives you the full benefit of the tool.
[15:48] <mozmck_work> I'm not yet because I don't use VCS.
[15:48] <mozmck_work> I need to or my code will be at work when I want it at home :)
[15:48] <mzz> you most definitely *can* stick multiple projects into the same branch, which would let you commit all of them. But if you do that it's relatively hard to get a single project back out.
[15:49] <mzz> bzr isn't like svn in that
[15:49] <mozmck_work> mzz: that makes sense.
[15:50] <mozmck_work> it was kind of a wild idea I guess :)
[15:50] <mzz> assuming both systems are networked I'd use one bound branch per project and a shared repository somewhere reachable from both
[15:51] <mzz> that just leaves figuring out how to deal with changes that aren't quite ready for a commit before you move between systems
[15:51] <mozmck_work> I can set up a server to network them.
[15:51] <mozmck_work> what is a bound branch?
[15:52] <mzz> if they're not networked you can put that shared repo on a thumb drive
[15:52] <mzz> I'm hoping bound branches are explained in the documentation, sec...
[15:53] <mzz> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-checkouts but that's not ideal. Can someone give me a better doc link?
[15:53] <mzz> or give mozmck_work a better doc link, really
[15:53] <mozmck_work> ok, I can find it.  but only one shared repository per project right?
[15:54] <mzz> well, depends
[15:54] <mzz> afaict you won't need more than one for what you're doing
[15:54] <mzz> <-- not a bzr expert though
[15:55] <mozmck_work> me neither (obviously!)
[15:55] <mozmck_work> I'll keep reading.  there's too many options...
[16:04] <igc> night all
[16:07] <awilkins> Wowzer, sourceforge.net got all purrrty
[16:07] <Xavura> impossible!
[16:07] <Xavura> oh wow
[16:10] <ddaa> why do sf.net look like twitter all of a sudden?
[16:11]  * awilkins registers sourcetwit.net
[16:11] <Xavura> they're kinda late to hop onto the web 2.0 bandwagon but err
[16:12] <ddaa> Apparently, their web20 script monkeys STILL have not heard of this innovation: margins
[16:13] <Xavura> rofl
[16:13] <kfogel> bzr pack
[16:13] <kfogel> bzr: ERROR: Pack '39d0c482e6e64ea0f509082e76b76e37' already exists in <bzrlib.repofmt.groupcompress_repo.GCRepositoryPackCollection object at 0x8ba604c>
[16:14] <kfogel> anyone know what that's about? ^^
[16:14] <Xavura> does look a bit croweded
[16:14] <ddaa> that's a bug in bzr-hg, bzr-git whatever your are trying to use.
[16:14] <kfogel> That was from the final command in 'bzr reconcile && bzr upgrade --2a && bzr pack' with very latest bzr bleeding-edge.
[16:14] <kfogel> ddaa: (were you responding to me?)
[16:15] <dash> also they bought Ohloh
[16:15] <ddaa> kfogel: yup, I guessed (apparently wrong) what you were trying to do.
[16:15] <kfogel> ddaa: yeah, this was just a straight upgrade to the brisbane-core format
[16:15] <mzz> well, http://sourceforge.net/ is currently giving me a *very* pretty 500 page
[16:15] <mzz> I'm not sure that's what you folks meant though
[16:16] <ddaa> mzz: well, no. But I guess you can still see the improvement from where you stand :)
[16:16] <jelmer> kfogel, Afaik that happens if you try to pack while there is nothing to pack, and you end up generating a new pack file with the same contents (and hash)
[16:20] <Peng_> jelmer is correct. There could always be some other cause, of course, but it's probably that. Bug #382463.
[16:21] <kfogel> Peng_: dang it.  I just was over in the bug tracker finding that bug.  I should have waited for you to say it!
[16:23] <Peng_> "bzr pack" on older formats just reorganizes data, so they short-circuit when there's only 1 pack file, but BBC recompresses too, so packing when there's only one pack may still lead to a different file.
[16:23] <Peng_> So it's a bit harder to decide what to do to fix it.
[16:30] <kfogel> Peng_: well, it could attempt to recompress and then if there's no advantage, just remove the attempt and say nothing.  (Or, if it wanted to be really fancy, it could store a flag the first time saying it has been compressed, and with what algorithm/compression-level, so it would know not to bother trying to do better unless there's been an upgrade).
[16:33] <Peng_> kfogel: Yeah, but then all of that CPU would have been wasted for nothing.
[16:33] <kfogel> Peng_: Not in the latter case.  But wasting CPU is better than an error message for a non-error in any case!
[16:33] <kfogel> :-)
[16:44] <gioele> hello
[16:53] <Peng_> kfogel: You could propose the flag thing in the bug. ;-D
[16:54] <mozmck_work> in .bzrignore, can I use dir/*.* to ignore everything in certain directories?
[16:54] <gioele> I'm experimenting with bzr-svn. Is there a way to make sure that it does not commit anything to the remote svn repository?
[16:54] <gioele> mozmck_work: yes
[16:54] <Peng_> gioele: You could not run "commit".
[16:54] <Peng_> mozmck_work: What if the filenames don't have "." in them?
[16:54] <jelmer> gioele, don't use the "checkout" or "push" commands
[16:54] <Peng_> mozmck_work: Just ignore dir/ or, if you want to version the directory for some reason, dir/*
[16:55] <gioele> jelmer: what about commits?
[16:56] <jelmer> gioele, if you commit in a checkout, it'll be committed to the master branch as well
[16:56] <jelmer> gioele, if you commit in a standalone branch that was created from a svn branch, it won't affect the branch it was cloned from
[16:56] <gioele> jelmer: perfect
[16:56] <jelmer> gioele, if the svn repository has a read-only URL you could use that
[16:56] <mozmck_work> I tried dir/*.* and then ran "bzr ignored" and it didn't list any files from that dir as being ignored
[16:56] <jelmer> that way you're always sure you won't do any writes
[16:57] <gioele> jelmer: sadly it has not it.
[16:57] <Peng_> mozmck_work: You do know that ignore rules do not apply to already-versioned files, right?
[16:57] <mozmck_work> yes, I'm setting up .bzrignore before I add any files
[16:58] <mozmck_work> dir/* didn't work, but dir/ did
[16:58] <kfogel> Peng_: it's too obvious; anyone looking seriously at this bug will see all the options.  I think the bottleneck is dev attention, not solutions.
[16:58] <jelmer> we have a lot of these bugs related to simple unpolished bits of bzr
[16:58] <Peng_> kfogel: Well, I don't think anybody else proposed it.
[17:00] <gioele> OK, next topic: how important is it to have svn 1.5 instead of svn 1.4 with regard to bzr-svn? Are there thinks that I can't do when only svn 1.4 is available on the remote repo?
[17:01] <dash> svn 1.5 supports revision properties
[17:01] <dash> which bzr-svn will used to store metadata
[17:01] <dash> on 1.4 and earlier ti uses file properties, which are a little more intrusive
[17:05] <awilkins> 1.4 svn repositories support revision properties, but you need to use bzr-svn against the 1.5 API to use them
[17:06] <awilkins> gioele: So as long as your CLIENT uses 1.5 or above, you will gain the benefit
[17:06] <dash> oh!
[17:06] <dash> news to me
[17:07] <awilkins> SVN has supported revision properties for as long as I can remember, back to about v 0.39
[17:29] <ddaa> awilkins: I think the news is something like "unprivileged users can now set them at commit time"
[17:51] <gioele> awilkins, dash: thank you
[18:20] <gioele> wow: subvertpy does not provide very useful exceptions: "bzr: ERROR: subvertpy.SubversionException: ("In directory 'svn/branches/src/...'", 155009)"
[18:21] <Peng_> ERR_WC_BAD_ADM_LOG, apparently.
[18:28] <SamB> gioele: what, you want it should convert the svn error number into human-readable form?
[19:10] <jskulski> hey all, I shelved some changes, and made some changes to my tree (moved functions to a new file) and now bzr unshelve says that it won't be clean. Is there a way I can point it at the new file or get a patch I can apply and delete it from the shelf?
[19:43] <verterok> beuno_: ping
[19:43] <beuno_> verterok, hey
[19:43] <verterok> beuno_: do you have a minute to chekc verterok.com.ar?
[19:43] <beuno_> verterok, sure
[19:44] <verterok> beuno_: it's returning 404's :/
[19:44] <beuno> argh
[19:44] <beuno> I must of screwed up migrating
[19:44] <beuno> oh
[19:44] <beuno> *I* didn't
[19:44] <beuno> someone else did
[19:45] <verterok> beuno: oh, nice! it's always good to don't be the one who broked it ;)
[19:45] <beuno> verterok, DNS FAIL
[19:45] <beuno> sorry  :(
[19:45] <beuno> fixing it now
[19:45] <beuno> but it will take an hour or two to propagate
[19:45] <verterok> beuno: ok, thanks!
[19:46] <verterok> beuno: I noticed because of Bug #394847
[19:47] <beuno> verterok, I can mirror the account on a different server in the mean time if it's critical
[19:47] <verterok> beuno: not critical, thanks!
[19:48] <Pilky> anyone with any experience with GPL licensing technicalities? I want to know if I write an Obj-C API to hook into bzr, whether I can licence it as LGPL?
[19:49] <fullermd> By the standard interpretation, no.
[19:50] <Pilky> :/
[19:50]  * Pilky stabs GPL
[19:53] <fullermd> Now, theoretically Canonical owns all the copyrights, so you could potentitally negotiate other terms with them.
[19:53] <Pilky> well the only reason is I want to use the API to write a GUI for bzr on OS X
[19:54] <Pilky> but I want as much of the code as possible to be licensed as MIT
[19:54] <dash> do like bzr-eclipse does and use bzr-xmloutput
[19:55] <Pilky> I considered that before but it seems a bit hackish
[19:56] <Pilky> using bzrlib I can take python objects and convert them to Obj-C quite easily
[19:58] <Peng_> You can negotiate other terms with Canonical. Well, the website says so; I dunno if anyone ever has.
[19:59] <Pilky> yeah I'll probably look into that
[20:00] <Pilky> if they allowed my API to be licensed LGPL or even MIT it could help provide a boost for bzr on OS X as a means of talking to other tools
[20:01] <Peng_> Since Canonical owns everything, relicensing would be pretty easy, if they decided to.
[20:01] <Pilky> yeah, I mean I'm not looking into relicensing bzr itself
[20:01] <beuno> well, it's unlikely that Canonical will relicence bzr to MIT for distribution
[20:02] <Pilky> just whether I can create code that talks to bzr lib that doesn't have to be condemned to GPL status
[20:02] <dash> more's the pity
[20:02] <Peng_> LGPL is possible... Mercurial is firmly non-LGPL, though, so Bazaar might make the same decision.
[20:03] <LarstiQ> Obj-C?
[20:03] <LarstiQ> Pilky: you're not at EuroPython by any chance?
[20:03] <Pilky> nope
[20:03] <LarstiQ> ah ok, pure coincidence then
[20:03] <Pilky> how so?
[20:04] <LarstiQ> Pilky: there has been at least one talk about python and objc and some interest on the mailing list
[20:04] <Pilky> ah cool
[20:04] <LarstiQ> and then at least one bof iirc
[20:04] <Pilky> well I'm going to be looking into PyObjC for building this bzr API
[20:05] <LarstiQ> whereas before that, I hadn't really seen much activity on it
[20:05]  * LarstiQ nods at Pilky 
[20:05] <Pilky> yeah, a lot of people see Obj-C as some scary weird language, when they get introduced to it and can see that you can talk to cocoa with Python and Ruby as well then they get more interested ;)
[20:05] <monteldeonte> Can someone help me with bzr?
[20:06] <LarstiQ> Pilky: I feel old now :)
[20:06] <dash> monteldeonte: no, you're doomed
[20:06] <LarstiQ> monteldeonte: sure, what can we help you with?
[20:06] <LarstiQ> dash: oi :P
[20:06] <Pilky> heh
[20:06] <dash> monteldeonte: (what is your problem? :)
[20:06] <monteldeonte> lol
[20:06] <monteldeonte> Is there a way that i can sync a bzr branch with svn?
[20:06] <Pilky> so yeah, who would be the best person at canonical to get in touch with about my licensing problem?
[20:06] <dash> monteldeonte: probably. what's your situation?
[20:07] <LarstiQ> monteldeonte: in general, yes, with bzr-svn. There are some corner cases, so as dash said, could you elaborate on your situation?
[20:07] <LarstiQ> Pilky: Martin Pool
[20:07] <Pilky> ok cool, thanks!
[20:07] <monteldeonte> I need to import the SVN from a project, and upload it to a branch
[20:07] <monteldeonte> I also need to be able to sync it with the branch
[20:08] <monteldeonte> i mean'
[20:08] <SamB> Pilky: you can write code and license it under more liberal terms, but if you link it with canonical's code you'd need to provide the source anyway, as per the GPL...
[20:08] <monteldeonte> sync the SVN every now and then
[20:08] <dash> monteldeonte: sure. install bzr-svn and you can treat svn branches like bzr ones, mostly
[20:08] <monteldeonte> dash: I know, i have. I just dont know how to use it
[20:08] <Pilky> SamB: well it will remain open source, but I don't want to licence it as GPL as that will limit uptake IMO
[20:09] <dash> monteldeonte: 'bzr branch svn://yoursvnurl/.../'
[20:09] <LarstiQ> monteldeonte: `bzr branch http://host/svn/repo/path/in/repo/to/branch`
[20:09] <SamB> and if this is all Python code we're talking about I frankly don't think it makes a difference
[20:09] <monteldeonte> LarstiQ: then how to i update the SVN?
[20:10] <dash> monteldeonte: 'bzr push <svn url>'
[20:10] <LarstiQ> monteldeonte: if you have commits in your bzr branch you want to get into svn, what dash said
[20:10] <LarstiQ> monteldeonte: basically, you can treat svn branches as any other bzr branch
[20:10] <SamB> monteldeonte: you just run "bzr pull" in your local copy of the SVN branch
[20:10] <fullermd> Y'know, I was just thinking, it's been so boring here lately, let's have a license discussion   :p
[20:11] <monteldeonte> I mean, when there is a new revision on the SVN, how do i sync it with the branch?
[20:11] <SamB> monteldeonte: (it's a good idea to keep a pristine copy of the SVN branch, since SVN makes such a terribly slow DVCS)
[20:11] <dash> monteldeonte: 'bzr merge'
[20:11] <SamB> then you run "bzr merge ../code-from-svn"
[20:12] <SamB> where ../code-from-svn is the pristine bzr copy of the branch SVN branch that you just pulled into
[20:12] <monteldeonte> I am sorry,
[20:12] <monteldeonte> I dont get it
[20:14] <monteldeonte> LarstiQ: Ok, what is the first thing i do
[20:14] <LarstiQ> monteldeonte: first, branch from svn.
[20:15] <monteldeonte> k, h.o
[20:15] <SamB> monteldeonte: basically, bzr-svn just allows Bzr to treat SVN branches as Bzr branches
[20:15] <SamB> really, really *slow* Bzr branches
[20:15] <LarstiQ> monteldeonte: (you mgith be more comfortable with a checkout style, but we'll come to that later)
[20:16] <SamB> and you really don't want to do a bzr checkout directly from SVN
[20:16] <SamB> well, maybe a heavyweight one ...
[20:16] <LarstiQ> SamB: that, and if you're sitting next to the server...
[20:16] <SamB> ... but I've had those fail in mostly-incomprehensible ways
[20:16] <SamB> LarstiQ: does that actually help much?
[20:17] <SamB> I suppose if it has a 10th or less the round-trip-time as usual ...
[20:17] <LarstiQ> SamB: very small latency, lots of bandwidth
[20:17] <SamB> LarstiQ: the bandwidth doesn't seem to be much of an issue usually
[20:17] <LarstiQ> SamB: talking a gigabit office connection
[20:17] <LarstiQ> SamB: are you using tdb or sqlite?
[20:18] <SamB> what? I don't actually run any of the SVN repositories I pull from ... or are you talking about bzr-svn's cache?
[20:19] <monteldeonte> LarstiQ: OK, now what
[20:20] <monteldeonte> Say there is a change in the SVN, how do i get it?
[20:20] <SamB> LarstiQ: using tdb or sqlite *where*?
[20:20] <monteldeonte> Do i have to do that over again?
[20:20] <SamB> monteldeonte: I would suggest keeping that directory just for the stuff from SVN
[20:21] <SamB> and use a different one to hold your local branch
[20:21] <SamB> which you would create by "bzr branch copy-of-svn my-branch"
[20:21] <SamB> monteldeonte: then, when you want to update from svn, you can just go in the one you branched from SVN and run "bzr pull"
[20:21] <LarstiQ> SamB: bzr-svn's cache
[20:22] <SamB> and you go back to yours and run "bzr merge"
[20:22] <monteldeonte> hah! you guys rock!
[20:22] <LarstiQ> monteldeonte: SamB's advice is sensible.
[20:22] <monteldeonte> I think i got it good now.
[20:28] <monteldeonte> LarstiQ: OK, i already have a bzr branch, the one i was updating manually. How do i remove the stuff from that, and put this one into there?
[20:28] <monteldeonte> should i just remove it and make a new one?
[20:29] <monteldeonte> SamB: ?
[20:29] <LarstiQ> monteldeonte: if you intend to use it to interact with svn but didn't produce it with bzr-svn, I'd ditch it if you can
[20:29] <monteldeonte> k kool
[20:34] <monteldeonte> LarstiQ: the old address for the branch was lp:noxbot now it is lp:~m.deonte/noxbot/main, how do i get that back?
[20:35] <LarstiQ> monteldeonte: lp:noxbot is a shorthand, lp:~m.deonte/noxbot/main looks like the expansion for that
[20:35] <LarstiQ> monteldeonte: if they no longer match, you can do `bzr pull --remember lp:noxbot`
[20:38] <monteldeonte> woo hoo!
[20:40] <monteldeonte> LarstiQ: So, when there is a change in the SVN, all i do is bzr pull and then bzr push?
[20:40] <LarstiQ> monteldeonte: as long as svn and local don't diverge, yes
[20:41] <LarstiQ> monteldeonte: if they do, you need `bzr merge`
[20:41] <monteldeonte> LarstiQ: Diverge?
[20:41] <LarstiQ> monteldeonte: SamB outlined a workflow for that
[20:41] <LarstiQ> monteldeonte: say if you commit something locally, and someone commits something in svn
[20:41] <LarstiQ> monteldeonte: neither is then anymore a strict superset/subset of the other
[20:42] <monteldeonte> Wait, so if this guy commits on SVN,
[20:42] <monteldeonte> What do i do?
[20:42] <LarstiQ> monteldeonte: first, `bzr pull`
[20:42] <monteldeonte> then
[20:43] <LarstiQ> monteldeonte: then, if it says you need to use `bzr merge`, that
[20:43] <monteldeonte> Oh, it will tell me?
[20:43] <LarstiQ> monteldeonte: as SamB said, I'd advise to keep one local mirror you only pull into, and only commit just before you synchronise with svn
[20:43] <LarstiQ> monteldeonte: yes
[20:43] <LarstiQ> monteldeonte: and use a local branch of that mirror to do actual work
[20:45] <monteldeonte> LarstiQ: OK, so when someone gets this branch, how do they update it?
[20:47] <LarstiQ> monteldeonte: just the usual pull/merge. Other than svn, are you familiar of how bzr works?
[20:47] <LarstiQ> s/of/with/
[20:48] <monteldeonte> not really.
[20:49] <LarstiQ> ok
[20:49] <monteldeonte> LarstiQ: Wait, so will that other person have to have brz-svn installed?
[20:49] <LarstiQ> monteldeonte: if they interact only with your bzr branch? No.
[20:49] <SamB> monteldeonte: only if they also want to pull from SVN
[20:49] <SamB> well, merge is more like it
[20:49] <LarstiQ> monteldeonte: if they want to communicate directly with svn, then yes
[20:51] <monteldeonte> OK, so say someone downloads my branch. When i push to bzr, what do they do to get it?
[20:52] <LarstiQ> monteldeonte: bzr pull
[20:52] <monteldeonte> Will that pull from the SVN?
[20:53] <LarstiQ> monteldeonte: no, from the same location they got your branch
[20:53] <monteldeonte> shweet
[20:53] <LarstiQ> monteldeonte: In case you hadn't seen it yet, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[20:54] <LarstiQ> monteldeonte: I have to go now unfortunately (well, drinking beer)
[20:54] <LarstiQ> monteldeonte: so good luck and I'll check in when I get back
[20:54] <monteldeonte> Ok, thank you for your help
[20:54] <monteldeonte> I think i get it now
[20:54] <monteldeonte> Ok, thansk
[20:54] <LarstiQ> good
[21:18] <gioele> I cannot understand the wording of section 8.2.3: it first gives an example using 'svn-import', then says 'Here's the recipe from above updated to use a central Bazaar mirror:' adn then gives and example where svn-import is not mentioned
[21:19] <gioele> section 8.2.3 == http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#bzr-svn
[21:19] <Peng_> gioele: Well, use "bzr svn-import" to import all the branches from a repo. Use "bzr branch" for one branch.
[21:20] <Peng_> gioele: The end result is equivalent; svn-import just makes it easier to import multiple branches at once.
[21:24] <gioele> Peng_: from what I see the leading text should say "In addition to svn-import, also XXX can be used to create a central Bazaar mirror. Here is the recipe from above updated to use method XXX"
[21:26] <Peng_> Ehh. I don't have documentation paged into my brain.
[21:27] <gioele> Peng_: well, as I wrote, my comment was about the "wording" of that section
[21:28] <Peng_> I such at English.
[21:46] <fbond> Hi.  I was just thinking -- there's been some talk of support for history editing on the ML.  Would it make sense at all to build this around shelve, instead of following the rebase model?
[21:46] <fbond> Some automation on top of shelve would get me just about everything I would want...
[21:47] <mozmck_work> I've used git just a little.  It looks like a git branch is about equivalent to a bzr tag - right?
[21:47] <gioele> in bzr help svn-layout there is an example of a custom repository layout. It uses a new section inside ~/.bazaar/subversion.conf. The example use "[203ae883-c723-44c9-aabd-cb56e4f81c9a]". How do I know which number should I put there for my repository?
[21:48] <garyvdm> mozmck_work: No - because a tag does not move forward when you commit.
[21:48] <mozmck_work> hmmm, what does that mean?
[21:49] <dash> a bzr tag is just a name for a revision
[21:49] <mozmck_work> I see.
[21:49] <mozmck_work> in git you can have say a release branch and the main dev branch "master"
[21:49] <jocr> !help
[21:50] <mozmck_work> and change between them in the same working directory with a simple command
[21:50] <dash> mozmck_work: right. the normal bzr workflow is two separate dirs
[21:50] <dash> but you can use 'bzr switch' if you really want to use the same working copy.
[21:51] <mozmck_work> that was my next question!
[21:51] <mozmck_work> I don't know yet which I would prefer.
[21:52] <mozmck_work> if you have 2 branches I guess they can go in the same repository.
[21:52] <dash> that's what repos are for
[21:54] <mozmck_work> thanks.  I'm slowly figuring it out - I think...
[21:56] <jocr> where can I find information about how bzr deals with merge conflicts. I haven't been able to find the right documentation yet.
[21:57] <garyvdm> jocr: what do you want to know?
[21:57] <a_c_m> anyone know of any php libs or apps that can browse a bzr repro ?
[21:57] <jocr> I see a bunch of suffixes on files that had conflicts and I just wanted to know which file was what
[21:58] <jocr> suffixes are like BASE or BASE.moved or OTHER
[22:00] <Peng_> a_c_m: This was discussed a bit on the mailing list recently.
[22:00] <a_c_m> Peng_: ahh cool any good conclusions, or is there somewhere online the mailing list is stored?
[22:01] <Peng_> a_c_m: The answer was "no", and yes, but I don't have a link handy. :P
[22:02]  * Peng_ goes to eat.
[22:02] <Peng_> Sorry!
[22:02] <a_c_m> Peng_: shame :(
[22:02] <fbond> window goto (st
[22:02] <fbond> Whoops.
[22:03] <jocr> !BASE
[22:03] <jocr> !.BASE
[22:04] <garyvdm> jocr: sorry - I can find any docs - allthough I'm sure that there are.
[22:04] <jocr> that's o.k. I'll keep looking
[22:04] <garyvdm> .THIS is the file from the branch that you merged into
[22:04] <garyvdm> .OTHER is the file from the branch that you merged from
[22:04] <gioele> jocr: bzr help conflicts
[22:04] <gioele> (in general bzr help topics is quite helpful)
[22:05] <garyvdm> .BASE is the version of the file that both branches have is common.
[22:07] <jocr> I see, I was starting to deduce all this but thanks for the help.
[22:07] <jocr> Another question is if I get a version of the file that I want to keep, say the .BASE version do I delete the others and to bzr resolve to fix the conflict?
[22:08] <garyvdm> rm foo
[22:08] <garyvdm> mv foo.BASE foo
[22:08] <garyvdm> bzr resolve foo
[22:09] <jocr> I see thanks again. and thanks gioele, I'll read the help file here
[22:09] <garyvdm> All though it's very unlikely that you want to keep the BASE
[22:10] <garyvdm> If it's a binary file, you generally keep the THIS or the OTHER
[22:10] <jocr> no it's a source file with some different fixes in both versions
[22:10] <jocr> that is the THIS and OTHER versions
[22:30] <lifeless> moin
[22:34] <RenatoSilva> where can I see the source of builtins.tree_files(file_list)
[22:36] <bob2> bzrlib/builtins.py
[22:36] <garyvdm> bzrlib/builtins.py line 71?
[22:37] <RenatoSilva> bzrlib is at?
[22:38] <garyvdm> root of bzr.dev
[22:38] <RenatoSilva> I can't find it in bzr home
[22:38] <RenatoSilva> what is bzr.dev
[22:39] <garyvdm> Trunk of bzr
[22:40] <garyvdm> http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head%3A/bzrlib/builtins.py#L70
[22:40] <RenatoSilva> what are the .pyd files?
[22:40] <RenatoSilva> garyvdm: thanks
[22:41] <RenatoSilva> I need to browse over the code
[22:42] <RenatoSilva> it's just bzr branch lp:bazaar/trunk, right?
[22:42] <garyvdm>  bzr branch lp:bzr
[22:44] <RenatoSilva> ok
[22:44] <RenatoSilva> Does anyone suspect how can Programação become into Programa‡Æo?
[22:45] <garyvdm> The text is bing decode in the wrong charset
[22:45] <garyvdm> *being
[22:45] <RenatoSilva> It's what comes from WorkingTree.id2abspath
[22:46] <RenatoSilva> I'm trying stuff like  print u'Programação'.encode('latin-1').decode('cp850')
[22:46] <RenatoSilva> Without sucess, none of them lead to the above string
[22:46] <dash> try removing the decode?
[22:46] <dash> it's probably just latin-1
[22:47] <lifeless> RenatoSilva: python -c 'import bzrlib; print bzrlib.__path__' will tel you where bzrlib is being loaded from
[22:47] <RenatoSilva> dash: tried
[22:48] <RenatoSilva> dash: how can Programação become into Programa‡Æo?
[22:48] <RenatoSilva> dash: that's what I mean
[22:52] <Peng_> Is it a bad idea for multiple, completely unrelated projects to use the same file IDs?
[22:53] <lifeless> Peng_: it would be odd
[22:53] <lifeless> Peng_: not necessarily bad; why?
[22:54] <RenatoSilva> hum, what is this: http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1127
[22:55] <Peng_> lifeless: bzr-git does it. I was just curious.
[22:55] <RenatoSilva> How can Bzr guess that the string is either unicode or utf-8 encoded?
[22:55] <lifeless> Peng_: it does?
[22:55] <lifeless> Peng_: what algorithm?
[22:55] <RenatoSilva> when it is str, it is not necessarily utf-8 encoded right?
[22:56] <Peng_> lifeless: It just uses the file's relative path.
[22:56] <lifeless> RenatoSilva: that function isn't guessing
[22:56] <jelmer> Peng_: Well, with some escaping
[22:56] <Peng_> jelmer: Oh.
[22:56] <Peng_> Hi jelmer. :D
[22:56] <Peng_> I guess you have to do that because Git doesn't have convenient repository UUIDs like svn?
[22:56] <RenatoSilva> lifeless: because the user should call it only for such cases?
[22:56] <jelmer> Peng_, right
[22:56] <lifeless> RenatoSilva: first it checks if it *is* unicode, and if its not unicode it expects to be given a utf8 str
[22:57] <jelmer> Peng_: And I could use the sha of the path or something like that
[22:57] <lifeless> RenatoSilva: yes, we use utf8 for our disk data structures
[22:57] <jelmer> Peng_, But that would just cause indirection because there wouldn't be a way to go from file id to path cheaply
[22:57] <lifeless> RenatoSilva: and we use that function when handling deserialisation from them
[22:57] <RenatoSilva> lifeless: so it *expects*, it should not be called for non-utf-8
[22:57] <lifeless> RenatoSilva: thats right
[22:58] <Peng_> jelmer: Would it be possible to include the revision ID that introduced the file?
[22:58] <Peng_> bzr-svn does that, IIRC?
[22:58] <jelmer> Peng_: That would be possible, but expensive, and there's no point
[22:58] <lifeless> jelmer: does it prefix it with git: or something?
[22:58] <lifeless> jelmer: there is a point
[22:58] <RenatoSilva> lifeless: it seems the problem is in WorkingTree then
[22:58] <Peng_> lifeless: No prefix.
[22:58] <lifeless> jelmer: consider a repo with any projects; the per-file graph is often loaded in bulk by bzr (e.g. for annotate)
[22:59] <RenatoSilva> lifeless: http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/workingtree.py#L204
[22:59] <lifeless> jelmer: having the same fileid in many projects with do very odd things to the per-file graph size and index shape
[22:59] <lifeless> s/with/will/
[22:59] <Peng_> lifeless: Will it actually cause problems, though?
[22:59] <Peng_> lifeless: I mean, errors?
[22:59] <RenatoSilva> lifeless: it also expects utf-8 or unicode
[23:00] <lifeless> Peng_: it will cause slowness
[23:00] <jelmer> lifeless: if we have to include the revision sha in which a file was introduced it means different slowness
[23:01] <jelmer> lifeless, because we can't just fetch an arbitrary tree and know the file ids in it, we have to search history
[23:01] <Peng_> How does bzr-svn do it?
[23:01] <jelmer> Peng_: It searches history, and caches heavily
[23:02] <Peng_> jelmer: Why have bzr-svn and bzr-git do it differently?
[23:02] <lifeless> jelmer: tree-1 in the target will know, and it should be cheap to access
[23:02] <lifeless> jelmer: also, do you do rename heuristics at import?
[23:02] <jelmer> lifeless, we don't necessarily have tree-1
[23:02] <jelmer> lifeless, we don't do rename heuristics yet
[23:02] <jelmer> lifeless, when we do, I agree it would make sense to start looking at this
[23:02] <lifeless> I suspect your file id allocation will mean you cannot do file rename heuristics :>
[23:02] <jelmer> lifeless, That's not a problem
[23:03] <jelmer> lifeless, We can't introduce rename heuristics without changing the mapping anyway
[23:03] <jelmer> lifeless: so if we have to change the mapping anyway, we might as well change the file id allocation
[23:03] <lifeless> ok, good
[23:03] <jelmer> and introduce all of the infrastructure to deal with more complex file ids
[23:04] <lifeless> because, at the moment, bzr-git repos of all of ubuntu will behave terribly.
[23:04] <jelmer> Peng_: bzr-svn does roundtripping, bzr-git does not
[23:04] <jelmer> lifeless: right
[23:05] <lifeless> RenatoSilva: is WorkingTree.open() being called with a str, rather than a unicode ?
[23:05] <lifeless> bbs
[23:05] <Peng_> jelmer: Why doesn't bzr-git do roundtripping?
[23:05] <jelmer> Peng_: The effort hasn't been put in and there's no really good place to put the bzr metadata
[23:05] <RenatoSilva> lifeless: I'm trying to look at the right file, brb
[23:05] <jelmer> Peng_, The only real place is the git commit message, and that's a bit intrusive
[23:06] <RenatoSilva> lifeless: tree = WorkingTree.open_containing(default_branch)[0]
[23:06] <lifeless> default_branch should have been decoded by the command argument parser from your console encoding
[23:07] <RenatoSilva> lifeless: def tree_files(file_list, default_branch=u'.', canonicalize=True,
[23:08] <RenatoSilva> lifeless: tree, file_list = builtins.tree_files(file_list)
[23:08] <Peng_> jelmer: ok :)
[23:08] <RenatoSilva> lifeless: i.e. default_branch is '.' however the complete path is returned in output
[23:10] <lifeless> RenatoSilva: yes, that shuold all be fine; u'.' when passed to the file system means we get a filesystem encoding decoded cwd
[23:12] <mathrick> who could give me some help with implementing rebase --interactive support?
[23:12] <mathrick> ie. retroactive history shaping
[23:12] <dash> mathrick: evil
[23:13] <mathrick> dash: how else am I supposed to submit clean patches to projects?
[23:13] <RenatoSilva> lifeless: I think that the path comes from tree = WorkingTree.open_containing(osutils.realpath(file_list[0]))[0]
[23:13] <dash> mathrick: what's wrong with diff
[23:13] <dash> mathrick: i assume you mean non-bzr projects?
[23:14] <mathrick> dash: I mean bzr projects
[23:14] <lifeless> RenatoSilva: it could as well, yes.
[23:14] <mathrick> non-bzr ones of course get plain diffs
[23:14] <dash> mathrick: then why would it matter?
[23:14] <dash> mathrick: send a bundle
[23:14] <lifeless> RenatoSilva: are you on windows?
[23:14] <mathrick> dash: then I can't split them into featuresets and comment each one in a separate mail
[23:14] <mathrick> which is the preferred form for very many projects
[23:15] <mathrick> including, I believe, bzr :)
[23:15] <dash> mathrick: why'd you do multiple features in a single branch? :)
[23:15] <lifeless> mathrick: its nice to get clean featuresets; its more important to get patches though :)
[23:15] <mathrick> dash: no, it's for bigger patches implementing a single feature / set of related features
[23:15] <dash> I just finished breaking up a gigantic change into about 5 separate feature sets
[23:16] <dash> but i used loom and it's for syncing one SVN repo to another
[23:16] <RenatoSilva> lifeless: yes
[23:16] <RAOF> You could do that with bzr merge cherrypicking, assuming each commit contains a single feature.
[23:16] <lifeless> RenatoSilva: what bzr version do you have?
[23:16] <poolie> hello all
[23:16] <dash> mathrick: right, that sounds like a mistake to me
[23:16] <mathrick> dash: howso?
[23:16] <RenatoSilva> lifeless: I think that there may be a problem in http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1127
[23:16] <lifeless> hi poolie
[23:17] <lifeless> RenatoSilva: what bzr version are you using?
[23:17] <dash> mathrick: I don't see the problem with one branch and one merge per feature
[23:17] <RenatoSilva> lifeless: ignore the line please, I mean realpath method
[23:17] <mathrick> dash: the point is that a single feature should be multiple patches when it's big enough
[23:17] <dash> mathrick: yeah, i don't really believe that
[23:18] <mathrick> but it happens
[23:18] <mathrick> case in point, wine's DIB engine
[23:18] <dash> heh
[23:18] <mathrick> they have specifically rejected patches which did that as a single "all-in-one" dump before
[23:18] <RenatoSilva> lifeless: 1.15
[23:18] <lifeless> mathrick: what dash is saying is that you should do each component in a separate branch
[23:18] <RenatoSilva> lifeless: in tree = WorkingTree.open_containing(osutils.realpath(file_list[0]))[0]
[23:19] <lifeless> RenatoSilva: please try bzr 1.16
[23:19] <RenatoSilva> lifeless: something is going wrong...
[23:19] <lifeless> bialix recently changed the command interpreter to decode all arguments to unicode
[23:19] <lifeless> for problems like that
[23:19] <mathrick> lifeless: but that's not how it happens. That's precisely the point, I can't know what I will end up implementing before I start
[23:19] <RenatoSilva> lifeless: is there a windows installer for 1.16?
[23:19] <dash> mathrick: waiting until all your changes are done seems like a poor time to break stuff up
[23:19] <lifeless> RenatoSilva: I don't know, have a look :)
[23:19] <lifeless> mathrick: I know, and I agree.
[23:20] <dash> mathrick: i'm not saying you have to know before you start
[23:20] <lifeless> mathrick: we want tools to do this; that doesn't actually imply rebase though it can be used if you haven't published your code.
[23:20] <mathrick> lifeless: I only used the shorthand because that's where it is in git, which is well-known
[23:20] <dash> just that once you know, put your unrelated changes into a different branch :)
[23:20] <lifeless> I wrote a manifesto about this a few weeks back
[23:20] <mathrick> I don't want to imply it should be inside bzr rebase
[23:21] <mathrick> lifeless: link?
[23:21] <mathrick> and that's exactly what I want, to give tools
[23:21] <RenatoSilva> lifeless: downloading...
[23:21] <lifeless> mathrick: https://lists.ubuntu.com/archives/bazaar/2009q2/059263.html
[23:21] <lifeless> breakfasting
[23:22] <mathrick> dash: the historical patch order is never the same as logical. Forgotten files and stupid typos happen. I want tools to be able to reshape that easily, instead of devolving to a bunch of dirs with branches and fighting with diff
[23:23] <mathrick> lifeless: oh good, that seems interesting. I was actually wondering myself about being able to edit it without losing the actual patches as they happened
[23:23] <dash> mathrick: and my point is that the historical patch order is also important, and some people are altogether too eager to destroy that. :)
[23:23] <mathrick> dash: that's another problem that needs solving, not denying the problem #1 doesn't exist
[23:23] <mathrick> s/doesn't//
[23:24] <mathrick> also, it should help / interplay with how I wanted loom to work (as opposed to how it actually works today(
[23:24] <dash> mathrick: I just think the prevalence of that particular problem is overstated
[23:24] <RenatoSilva> installed but the same error: bzr xmlstatus > file is returning <?xml version="1.0" encoding="UTF-8"?><status workingtree_root="C:/Programa‡Æo/"></status>
[23:25] <mathrick> dash: I don't think so. If I want to present patches in a logical order, my VCS gives me absolutely no tools above diff. That's not the brave new world we were supposed to have with DVCS
[23:25] <dash> who says? :)
[23:26] <mathrick> it's silly that it's distributed and facilitates the exchange easily except for when you want to send patches by email and discuss them
[23:26] <mathrick> dash: says what?
[23:26] <dash> mathrick: what we were supposed to have
[23:26] <mathrick> dunno. I see a problem the tool fails to solve
[23:26] <RenatoSilva> lifeless: maybe C:/Programa‡Æo comes from encoding as cp1252 when it's expected cp850
[23:27] <mathrick> can we retroactively send brimstone upon the inventors of codepages?
[23:28] <RenatoSilva> lifeless: something in the chain guess that it should be cp1252, but it should not according to chcp command. If I run chcp 1252 before it, then the file chars are ok
[23:28] <dash> mathrick: if we could, it would have already happened
[23:28] <mathrick> dang
[23:28] <RenatoSilva> * is guessing
[23:34] <RenatoSilva> maybe the problem is here http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1058
[23:42] <mathrick> lifeless: I don't understand the "Integration" section
[23:47] <lifeless> is the file on disk encoded in cp1252/
[23:47] <lifeless> ?
[23:47] <lifeless> RenatoSilva: ^
[23:48] <lifeless> RenatoSilva: please file a bug about this; it could be a bug in bzr-eclipse, xmloutput or bzr, or even just a wrongly encoded filename on disk
[23:52] <RenatoSilva> lifeless: yeah, it could be a bug in many places hehe
[23:53] <RenatoSilva> lifeless: the file is created by > as latin-1, which is covered by cp1252 afaik
[23:56] <RenatoSilva> lifeless: there no workaround to do, unless there is a way to make an _actual_ encoding conversion
[23:56] <RenatoSilva> * there is
[23:56] <RenatoSilva> WorkingTree.id2abspath is returning an unicode string from a non-utf-8 encoding
[23:58] <RenatoSilva> the terminal expects to receive a cp850 output, and treats it as that, then put that in file
[23:58] <RenatoSilva> well, actually it is cp850