[00:00] ah yes, we're not doing the original merge sort anymore [00:00] well we're doing the same order but different numbers? [00:00] lifeless: right, same ordering [00:00] new root nodes would post-increment the branch counter [00:00] while new intermediate nodes would pre-increment it [00:01] so there are 2 "0.8.1" revisions right now [00:01] I read the patch :) [00:01] lifeless: We also should have a fix for ghosts [00:01] For the immediate work, I'm replicating bzr.dev [00:01] and pre-filtering ghosts [00:02] poolie: awake now [00:02] by fix you mean: a ghost should reserve a revno for itself' ? [00:02] lifeless: right [00:02] At least, that is my idea [00:02] I could implement it either way [00:02] I think thats wrong - because there is an unknown quantity of revnos to reserve [00:03] one is no more or less correct than 0 or 50000 [00:03] and as it is a ghost we have no information to show about it in log etc [00:03] actually, by wrong I mean no more correct than our current behaviour. [00:04] jam: Well, yes, but that's not the sort of job I can get a mortgage with. ;) [00:04] lifeless: I sort of understand your point, but there is also: http://rafb.net/p/hfnZd187.html [00:04] Assume 'C' is a ghost in both cases [00:04] In the latter, a spot is reserved for 'd' [00:04] D is not a ghost right? [00:04] lifeless: correct [00:04] what revno does D get today [00:05] 0.1.1 [00:05] today [00:05] and you are saying it should get 0.1.2 [00:05] ? [00:05] lifeless: yes [00:05] C would be 0.1.1 in both cases [00:05] but what if theere is F, a parent of C in both cases [00:05] lifeless: obviously we can't go into nodes that we haven't seen at all [00:06] parents of ghosts [00:06] good morning igc :) [00:06] I *can* mimic current behavior [00:06] it just turns out to be *more* work [00:06] I don't see what paste as an argument for or against; one graph isn't a subset, theres no reason for numbers to be stable [00:06] And I'm hesitant to write tests that require it [00:06] morning igc [00:06] it's desirable they be stable across releases [00:07] hi jam, lifeless [00:07] poolie: we've violated that so hard that integer is seeking a restraining order on bzr [00:07] poolie: well, they are already going to change as of today :) [00:07] though not dramatically [00:07] jam: I'm all for doing less work; but I'd justify it on that basis not on correct, as correct is ... vague here [00:07] just removing a bug for it [00:09] lifeless: sure, I suppose I'm a bit concerned about knock-on effects [00:09] right now, because we prune ghosts [00:09] the next layers don't worry about whether 'get_revision()' could fail [00:09] I'd expect log to fail [00:09] etc [00:10] though, I have gotten the feeling we've been trying to push ghost handling further up the stack [00:10] jam: we want to stop hiding bugs [00:10] for instance a ghost on the mainline should be supportable [00:10] So 'bzr log' could just show that there is a known revision_id, even if it doesn't know the info [00:11] poolie: the one "savior" here, is that it is only changing the "0.X" numbers [00:12] the rest of the numbers are stable either way [00:12] 0.X.Y, I guess [00:13] I guess I'll stick with the current scheme, going via the "principle of minimal change" [00:13] I might just comment out those tests [00:14] erm [00:14] delete [00:15] or fix [00:15] please [00:17] anyway, enjoy your day [00:19] you too [00:19] I'm wowing tomorrow FWIW [00:24] jam: do we nest branches as deeply as the original merge_sorted did ? [00:43] oh wow WT.remove is crufty [01:18] * igc bbl [01:56] jelmer: you use trac-bzr much? [02:07] jam: ping; an ack on my reply-to-the-annotate-patch would be nice [02:21] lifeless: ping [02:22] laszlok: hi [02:23] re the jokosher email, what does remixing mean? [02:23] changing things around [02:24] if you're happy with the branches and tags you have today, then you don't need to change stuff - just convert systems [02:24] * jdong resists temptation to turn "remixing" into a Barack Obama energy plan jab.... [02:25] basically branch refactoring [02:25] yup. its much more complex to do that; but I got the impression from your mail that you had something other than a direct switch in mind [02:27] not particularly, i think as long as all out svn branches come out as separate bzr trees it should be okay [02:27] * laszlok checks the stale branches in the svn repo [02:27] yes, they should [02:28] so the svn import will automatically split them up into different repos [02:28] if you install bzr-svn and just run bzr svn-import SVN_REPO_ROOT /tmp/svn-conversion [02:28] different repos with the same parent [02:28] we'll know soon enough [02:28] svn-import can be run incrementally so you could do this somewhere more persistent than /tmp too :) [02:29] launchpad it currently mirroring the svn trunk, is there a special way to import it, or is it just a simple push? [02:29] this will supercede the launchpad mirror [02:30] we'll end up with a bunch of branches - you can push some or all of them to launchpad, owned by you, or by a jokosher team if you have one [02:30] and we'd turn off the launchpad mirror of svn trunk [02:46] beuno: ping [02:53] lifeless: i did the svn-import with the repositiory root, but all the branches and tags directories are now in the bzr branch :/ [02:53] laszlok: really? It should create many branches in a shared repository [02:54] how do i get a list of branches in the shared repo [02:55] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [02:55] some idea? [02:55] i'm on intrepid. [02:55] ssh-add dont work. [02:55] laszlok: 'bzr branches' [02:55] (or just ls :)) [02:55] yeah there are none [02:55] laszlok: how big is the output directory? [02:55] and whats the jokosher svn url [02:56] 26MB, and when i do a branch of the shared branch the files appear [02:56] do the branches/ and tags/ dirs have to be at the top level? [02:57] laszlok: I'll defer to jelmer: on that; [02:57] cause in jokosher we have modules with separate branches and tags folders [02:57] whats the svn repo url ? [02:57] maybe that confused it [02:57] http://svn.jokosher.python-hosting.com [02:59] I was fairly sure that this is a common layout bzr-svn understands [02:59] oh except -art and -extra are different [02:59] right because they don't release [03:00] stupid historical reasons [03:00] so you want four projects essentially? [03:00] if we can just get JonoEdit converted, that will be enough [03:01] gst-chanplit is in gstreamer-cvs now, and the other two are just files. ie no history needs to be saved [03:01] ok [03:02] laszlo@sescento:~/Software/svn/bzr-jokosher-convert$ bzr st [03:02] bzr: ERROR: No WorkingTree exists for "file:///home/laszlo/Software/svn/bzr-jokosher-convert/.bzr/checkout/". [03:03] if i branch from bzr-jokosher-convert, then i have a proper working directory [03:03] strange [03:06] laszlok: the converter doesn't create working trees because you can end with with gb's of data that way [03:06] laszlok: imagine a svn repo with several thousand branches/tags [03:06] maybe all of them are shared history [03:07] okay, but doesn't svn do the same thing when you checkout the entire repo? [03:09] svn will create working trees because all the svn commands to get data locally are working tree centric [03:13] so svn checkout some-root will indeed give huge downloads and huge disk usage [03:13] this isn't really a feature [03:26] okay its getting late. thanks for you help lifeless, i will try to see why it isn't splitting the branches tomorrow [03:27] laszlok: gnight [03:35] If I merge in an unrelated branch and it adds a file with the same name as a previously ignored/unversioned file, is there a way to make bzr not treat it as a conflict? [03:35] Or, at least, not report a conflict if the files are identical? [03:39] ToyKeeper: Well, you can just do "bzr resolve FILE" manually after the merge. [03:39] Yeah, I do. It just seems odd to conflict when the files are identical. [03:40] ... just running some experiments for keeping $HOME in bzr. [03:40] I know what you mean. bzr is being conservative and so assumes they have different identities in that situation, regardless of content. [03:42] I think I'll probably stick with my current svn-based home repo, but it's interesting to find ways to do similar things in bzr. [03:42] It would probably be fairly easy to write a plugin to add a "resolve-harder" command that would notice that situation and auto resolve them for you. [03:43] I'm using externals and partial checkouts and symlinks extensively in svn, so the approach is rather different with bzr. [03:43] laszlok, bzr-svn should be able to deal with branches/tags at non-top-level [03:44] Maybe bzr should deal better with that case natively, although "unversioned file with same contents as added-by-merge file" does sound like a fairly rare case. [03:45] spiv: Yeah, pretty uncommon. I had never encountered it until I tried to do something funky. :) [03:46] It's also a bit confusing I think how bzr can have conflicts involving unversioned files; I've seen that surprise people (mainly in the context of the 'bzr up causes weird merge-conflicts-conflicts' bug) [03:46] laszlok: it worked for me: [03:46] $ bzr branches repo [03:46] JonoEdit/branches/0.1 [03:46] JonoEdit/branches/0.2 [03:46] JonoEdit/branches/0.9 [03:46] JonoEdit/branches/Elleo-SoC [03:46] JonoEdit/trunk [03:46] It's not very well-suited to tracking $HOME. I love bzr for most purposes, but it's not as good as svn at being a versioned filesystem with different views on every checkout. [03:46] gst-chansplit/trunk [03:47] lifeless: what command did you use for conversion? [03:48] bzr $ cd /tmp/ [03:48] $ mkdir jokosher [03:48] $ cd jokosher/ [03:48] bzr svn-import http://svn.jokosher.python-hosting.com repo [03:52] Hmm, this still isn't fixed. [03:52] w3m -dump http://www.jokosher.org/ | grep -i viagra | wc -l [03:52] 18 [03:56] oh yay hackage lol [03:56] lifeless: before it was copying x/1500 revisions, now its doing x/1391. So its not copying the entire repo [03:56] i guess it working now [03:57] laszlok: you might want to edit that homepage [03:57] laszlok: to remove the advertising spam :P [03:57] ToyKeeper: yeah we know but jono is too lazy to do anything about it [03:57] oh, only jono can edit ? [03:57] yeah its on his host [03:57] hah! [03:57] i dont think hes upgraded his wordpress in a while either [03:58] mailed him a nag [04:03] just reading the chan topic, was there a bitkeeper->bazaar converter before, or was it special for mysql? [04:04] there were some tools that could poke at bitkeeer [04:22] i'm storing some php files in a bazaar branch and publishing it via my http on my website. Was surprised to see that you could use "bzr branch" to get the php files without them being executed. How does that work? If I try to get the php file, say with wget, it gives me the output of the php script. [04:24] bzr branches are stored in special files in .bzr/ directories, rather than just as the original files. [04:24] oooooh right, confusing the working-copy/repository issue [04:24] thanks spiv [04:25] Right. [04:25] just got a bit of a fright that I might have been overlooking something that allowed people to download all my .php database config files ;) [05:02] emgent, pong [05:10] lifeless: i think i found the problem; there was a branching-scheme = single-JonoEdit in the ~/.bazaar/subversion.conf from a previous checkout [05:11] laszlok: that would do it [05:14] beuno: i saw your bzr-upload [05:14] seems very good plugin :) [05:14] are you packaging it ? [05:14] emgent, thanks :) jelmer has packaged it [05:14] he's looking for a sponsor to get it into Debian [05:15] oh nice! [05:16] I was thinking but now is ok :) [05:16] s/but/to package it but/ [05:16] emgent, cool, thanks anyway. There may be other bzr plugins in need of packaging [05:20] emgent, seems I found a sponsor, and it's being built now! [05:20] (talk about coincidence) [05:21] nice :) [05:21] emgent, if you could request the sync into intrepid once it's uploaded, that would be great [05:21] uhm.. but debian NEW package need FTP master work :) [05:22] beuno: sure will do when i see it in debian :) [05:22] emgent, yeah, and it's debconf now, so it will take a while [05:22] s/see/will see/ [05:22] true :) [05:22] ~1 month [05:22] hhehehe [05:22] * beuno crosses fingers [05:22] Debian FTP Masters are very slow :) [05:23] yeah, and even more so if they're full of bear on a beach in winter [05:23] heheh true :) [05:45] can bazaar do partial branches? [05:46] mxpxpod, partial as in history or as in files? [05:46] as in files [05:46] like, if I just want to grab one directory out of a branch [05:47] you can't currently do that, no [05:47] is support for it coming? [05:47] mxpxpod: yes [05:47] lifeless: is there a blueprint for it? [05:48] Verterok, ping [05:48] beuno: pong [05:48] Verterok, hi! Just saw you released xmlouput 0.5. Cool! Just one thing, did you maybe link it incorrectly on the wiki? [05:49] beuno: let me check [05:49] beuno: yeap, copy & paste madness :P, thanks for pointing it ;) [05:50] Verterok, :) I wasn't sure which part was mixed up [05:51] beuno: fixed now [05:51] Verterok, thanks [05:52] beuno: actually, thank you :) [05:52] lifeless: because I'm not seeing anything on it [05:55] mxpxpod: the concept is called 'views' and Ian Clatworthy has been doing most towards it [05:55] * beuno heads to bed. Have to go pick up someone at the airport in 5 hours :/ [05:55] lifeless: ok, thanks [05:56] night beuno [05:56] g'night lifeless! [05:56] have a good weekend [05:57] you too [05:57] Verterok, we should meet up soon and get the automatic testing on it's way ;) [05:58] beuno: indeed [05:59] beuno: there are big chances that I'll be offline during saturday, maybe I can start hacking a proof of concept :) [06:00] auto testing? [06:00] lifeless, we're planning to setup a server which auto-updates and runs the full test suite against all the plugins [06:00] get reports [06:01] beuno: thats a good idea [06:01] and maybe send them to the list, if people don't get annoyed by them [06:01] beuno: can I suggest separately running the set that my patch bundles? [06:01] (Preferrably by doing the bundling action and seeing what works) [06:01] lifeless, so, full test suite, and then just the plugin's? [06:02] we want to catch plugins that break bzr, and plugins that bzr breaks [06:02] the full test will include the bundled plugins [06:02] beuno: you saw the patch I'm referring to right? [06:02] lifeless, nope, not that I recall [06:02] lifeless: that sounds like a good start point, and from there start adding extra plugins :) [06:03] pls wait for BB [06:03] http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1217210104.21600.106.camel%40lifeless-64%3E [06:03] that patch [06:03] ubottu: please be learning about bb, kthxshutup [06:03] lifeless: Error: I am only a bot, please don't think I'm intelligent :) [06:03] ubottu: hey, I told you to shutup alread [06:03] lifeless: Error: I am only a bot, please don't think I'm intelligent :) [06:04] lifeless, ah, I understand. The more "official" plugins [06:04] or the ones that will be bundled, so we need to pay more attention to [06:04] beuno: well specifically - *what the tarball will have and how it will install* [06:05] which is different from taking the list, installing from the plugins own installer [06:07] lifeless, ok, sounds like a good idea. From the looks of it, they just get copied, instead of being installed. [06:07] they get copied into the tarball; and then the bzr installer copies them out again yes [06:07] thats the open bug in the patch discussion in fact :) [06:08] now, if someone wanted to fix that ... that would rock :) [06:08] Verterok, we'll ping-pong over the weekend then, and see where we get, and when you're free [06:08] lifeless, the bug being the individual setup's don't get run? [06:08] yes [06:08] most plugins won't give a rats [06:08] but some will [06:08] so we need to figure out how to do that gracefully [06:09] ok, we'll see what comes out of it :) [06:09] I'm really off now [06:09] night! [06:09] beuno: tomorrow I'll be at home.. [06:10] beuno: g'night [06:18] beuno: btw [06:18] beuno: I've just done partial tree exports [06:30] hi everyone, good night (at least here) [06:30] a little question if you don't mind [06:31] I was committing a change to LP, interrupted it by mistake and now I get a lock: http://paste.ubuntu.com/35401/ [06:31] I don't know how to break it. can anyone suggest a way out? [06:32] marianom: bzr should have broken the lock when you hit ctrl-C, unless you were physically interrupted? [06:32] anyhow, bzr break-lock URL [06:32] lifeless: I was the cause of the error, however I did a break lock but get the unsupported error [06:33] I used the same info I got from the error message to perform the action [06:33] marianom: oh the error is borked there is a bug [06:33] pass the url to your branch [06:33] upps [06:33] ok [06:33] https://code.edge.launchpad.net/easyark/trunk [06:37] all sorted [06:37] ? [06:37] marianom: bzr+ssh://bazaar.launchpad.net/~easyark/easyark/trunk [06:38] (Or just lp:easyark should work too) [06:42] sorry I didn't get it. Can I try to commit again or should I do something with the command you paste? [06:44] marianom: once you've broken the lock you can commit again, yes. [06:45] marianom: is that clear, or are you still stuck? [06:45] in a minute I tell you spiv [06:45] I did $ bzr break-lock bzr+ssh://bazaar.launchpad.net/~easyark/easyark/trunk [06:45] but I get permission denied [06:46] Oh, you need marplatense@bazaar.launchpad.net rather than just bazaar.launchpad.net I guess. [06:46] ok let's see [06:46] (I tend to forget that because I've set up my ~/.ssh/config so that I don't need that bit) [06:47] Basically, you just need to use the same branch URL you used to do "bzr co" in the first place. [06:48] ok, the lock is gone, committing now [06:50] it worked. thanks spiv, lifeless for your support [06:51] marianom: great! Glad we could help. [07:26] I've got what seems to be a late regression on windows just before the branch 1.6 was made. Should I submit it with 1.6 as the target, or still use -dev and note it should also be merged to 1.6, or something else? [07:28] markh: either, probably. I think BB won't pick it up if you don't target it to bzr.dev, though. [07:29] Typically we use subject lines like "[MERGE][1.6] Fix frobnicator..." [07:29] spiv: ok thanks, I'll target .dev and make a note about 1.6 [07:29] ah - then it implicitly targets both? [07:29] Nah, we do that just for human benefit :) [07:29] ie, use that subject line, but attach a bundle targetting .dev? [07:30] (Targetting .dev in the merge directive makes sense because usually bugs in release branches need to be fixed in .dev as well...) [07:30] BB then ignores the [1.6], but its a clue for humands :) [07:30] yeah [07:30] Happily this doesn't happen often enough that we've really needed smarter tools :) [07:30] * markh must have means humanoids [07:30] Or human hands smooshed together. [07:30] yeah - I'm saying the tool can ignore the [1.6], but the humanoids can instead. [07:31] :) [07:31] lifeless caused the regression :) os.listdir doesn't return errno.ENOTDIR on windows :( [07:31] D'oh. [07:40] markh: yay! [07:41] :) === thekorn_ is now known as thekorn [08:08] later everyone [09:16] Hello lifeless, how are you doing? I did what you suggested yesterday and, indeed, a "bzr pack" on my repository which is located on the network share failed. I've attached it to the Bug report. [09:28] hi, just a question: is it ok to change the title of a bug report when the problem has been narrowed down? I've done this right now, but now I wonder if this is appreciated or not.. Could someone give me an advice, please? [09:29] jonnydee: yes, definitely [09:29] ok, thanks a lot :) [09:30] Thanks for gardening bugs! :) [09:33] markh: That's not the only lifeless-related not-a-directory error on windows ; I found one too [09:34] http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C489ACEB7.1010503%40gmail.com%3E [09:36] Oh, no problem. I like being able to contribute at least somehow to the wonderful Bazaar community :) [09:46] hi [09:49] a simple question about CRLF: someone said a new feature about CRLF management will be introduced in bzr 1.6; have you got some more details ? thank you [09:54] lopio: AFAIK line endings support is not going in because versioned properties are not going in either. [09:55] lopio: I personally find it less necessary with each passing year ; the only code editor I use that cares is the VB6 IDE, and I never edit that source on Linux anyway. [09:56] lopio: Do you have something badly behaved that messes with your line endings? [09:56] my problem is that now we develop both under xp and hp-ux using cvs [09:57] And CVS is the thing messing with the line endings? [09:58] when you checout file under xp a LF is added automatically and when you commit is removed; nothingg is done under HP and everything is right [09:59] lopio: Are your code editors line-ending aware? [09:59] (on XP) [10:00] this is possible cause there is such a behaviour when you want to bypass this mechanism for example for binary file (cvs add -kb) ) [10:00] What are you using? (the windows notepad is about the only editor I know of that isn't ending aware now) [10:02] lopio: Can your windows folk not move over to using *nix line endings? [10:02] for example if you open a .ksh file file with worpad this file is reformatted [10:04] on the other side .bat file must contains CRLF on XP [10:06] To manage your repository with cvs you have to : 1) add ascii file with cvs add 2) add binary files with cvs add -kb [10:06] lopio: It sounds like your biggest problem is that Wordpad is rude enough to change line endings without asking you. [10:07] the xp cvs client add or remove LF when co and ci ascii file. nothing else [10:07] Yes, I understand the feature, I've tutored people on the SVN equivalent. [10:08] Although I find the SVN behaviour to be better (only do line endings when explicitly told to, not by default) [10:08] I'm not the only developer so i don't know which editors could be used -))) [10:09] I don't like that the SVN approach is not user configurable [10:09] Using Wordpad for code is madness, I tell you, Madness!!!!! ;-) [10:09] if a file has svn:native, I can't use LF on windows even if I want to [10:12] lopio: At any rate ; I've not seen line ending support being discussed in here or on the list, so I doubt it's going into 1.6 (unless it says so in NEWS, which it doesn't). [10:12] 1.6 is basically a wrap now in terms of features. [10:13] someone said this cvs / svn mechanism could corrupt files and this is why could not be implemeted in bzr. On the other side i think this could be a blocking problem in a multiplatform environment. [10:13] checkeol plugin is an attempt to solve it [10:13] The CVS flavour certainly can corrupt files if you forget to mark them as binary ; I've seen cases where this is so [10:14] yes but it's a mistake not a corruption [10:16] Tell that to Visio when it can't load the file. "Oh, it's just a mistake..... [10:16] And you can't un-do it because there are a mixture of CRLF and LF sequences in there [10:17] That's why I like the SVN approach of treating everything as binary by default better [10:19] i agree [10:20] what about this answer in launchpad : [10:20] question "CRLF management will be possible ?" [10:20] vila answer "There is a work in progress regarding eol handling and keywords expansion that may find its way into bzr 1.6, search the