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