[00:00] Jordan_U: Got a read-only $HOME? [00:00] RAOF: No [00:01] Sure? :) Lucid's been resuming with a readonly home for me on occasion ;) [00:01] ...and a read-only home is one trigger of that behaviour that I know. [00:02] RAOF: Yes, I have been working with files in $HOME without problems [00:02] Check ~/.bzr.log, make sure it's owned by you. [00:03] fullermd: Ahh, it's owned by root [00:03] Probably from trying to use etckeeper with bzr [00:04] * Jordan_U Thinks etckeeper in Ubuntu should not default to using bzr untill bzr can properly deal with being run with sudo [00:05] fullermd: That fixed it, thank you [00:50] hi [00:50] i'm trying to install bzr-git on windows [00:50] but am having no luck [00:50] bzr plugins does not list it. [01:11] Is there any reason I should not access a bzr branch stored on my Samba drive? [01:12] do you have filenames with : in them or mixed caase? [01:13] Shouldn't be for the first; for my projects, I use all lowercase names [01:13] Er wait no. [01:13] I don't use all lowrcase names [01:13] But the Samba share is hosted on a Liknux box and I don't have files with the same names but different cases in the same directory [01:13] (I do jhave a login.php in one directory and Login.php in another...) [01:46] Yay, bzr for windows finally downloaded [01:58] hi [01:58] i'm trying to use bzr dpush to push to a GIT repo, but am having the following problem: [01:58] C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+ [01:58] ssh://git@github.com/Noldorin/IRC.NET.git [01:58] bzr: ERROR: [Error 2] The system cannot find the file specified [03:10] hi [03:11] i'm trying to dpush using bzr-git [03:11] getting the following error though: [03:11] http://pastebin.com/m78e07c36 [03:34] As a guess, version mismatch. [03:35] That's a reasonably recent bzr-git, and a several version back bzr. [05:15] anyone on gentoo know where olive-gtk is hiding? [05:16] What is this "treeless branches" feature I keep reading about, and why is it important? [05:18] I dunno what you keep reading about, but a branch may or may not have a tree, depending on... well, whether it has a tree. [05:18] GuyFromHell: https://edge.launchpad.net/bzr-gentoo-overlay/ [05:19] GuyFromHell: bzr-gtk is part of that overlay [05:19] mneptok, oo, shiny. I could not find it anywhere [05:19] thank you [05:19] np np === BasicPRO is now known as BasicOSX [05:27] fullermd, what exactly is "tree" referring to? [05:29] The working tree, where you edit and read and touch and caress-by-the-fireside your files. [05:29] Ah, okay [05:31] * SamB_XP can't help but remember something about some windows pack-in called "wang" ... [05:31] If you have a branch with a [colocated] tree, you can get rid of the tree with 'bzr remove-tree', and you can get it back with 'bzr checkout' [05:32] (and some args to reconfigure also, I believe) === tro|| is now known as tro [08:31] i just did a "bzr add myfile", but then noticed that i'd misspelled the filename [08:31] i haven't committed yet, so is there some way to "unadd" the file? [08:31] Well, if you handed it a filename that doesn't exist, it shouldn't have done anything... [08:32] it does exist [08:32] but there's a misspelling in the filename [08:32] so i need to rename the filename [08:32] and "unadd" it from bzr, then add it again with the right name [08:32] then commit [08:32] i just don't know how to "unadd" it [08:32] Why unadd/readd, instead of just 'bzr mv'ing? [08:32] Anyway, you'd use 'rm' to unadd. [08:33] i tried rm and it complained about not being able to safely remove the file [08:33] * fullermd stabbies the !@&$ DWIM crap in there. [08:33] rm --keep [08:33] (and then add a bzr alias for it so it stops trying to outsmart you ever afreakingain :p) [08:34] thanks, fullermd [11:46] hello [11:47] i'm trying to use bzr-git to push a bzr branch to a git repo [11:47] however, i'm geting some horrible errors... [11:47] bzr: ERROR: exceptions.AttributeError: 'InterRepository' object has no attribute [11:47] 'fetch_objects' [11:47] the full log is here: http://pastebin.com/m78e07c36 [11:48] are you using dulwich,bzr-git and bzr trunk? [11:48] bob2: indeed i am [11:48] i believe everything is installed correctly, though i had some trouble yesterday... [11:49] Not on the latter you aren't. [11:49] bzr 1.17 on python 2.5.2 (win32) [11:49] oh, that's true [11:49] odd [11:49] i'm sure i had bzr 2.0 installed [11:50] you may well need actual bzr bzr [11:52] bob2: how do you mean? [11:52] as in bzr trunk [11:52] ah right [11:53] hmm [11:53] brb, restarting [12:15] fullermd: What's the status of DWIM? [12:15] vila landed it a few weeks ago. [14:08] Is there anything along the lines of architecture documentation for Bazaar? e.g. anything that helps understanding the internals? [14:30] maxb, maybe in the HACKING guide or in the developer doc section [14:31] maxb, in the tree, that is. [14:31] maxb, I've mostly got a sense of things from looking at commands in bzrlib/builtins.py and drilling down. [16:32] Using Ubuntu Karmic and trying to install bzr-explorer, but conflicts with qbzr version preventing this; latest qbzr version in Karmic is 0.14; bzr-explorer needs 0.17 [16:39] any suggestions ? [16:43] Adding QBZR PPA solved [16:52] hi [16:52] i hqave bzr 2.0 installed [16:52] but for some reason, when i run bzr from the command line, it uses version 1.17 [16:52] looks like i have bzr 1.17 in my path somewhere, but i can't figure out where :S [17:04] anyone? [17:08] Noldorin: 'bzr version' should show the path to the executable and bzrlib [17:08] hmm ok [17:08] Noldorin: ops, only the bzrlib path [17:09] verterok: c:\Python25\lib\site-packages\bzrlib [17:09] yeah [17:10] surely i want the one on program files though? [17:10] if i do... [17:10] "C:\Program Files\Bazaar\bzr.exe" version [17:10] i get v 2.0.3 [17:11] * Noldorin gets out procmon [17:13] Noldorin: check in c:\Python25\Scripts [17:13] ok [17:13] * verterok goes to the grocery store, brb [17:13] verterok: seems to be a bzr in there [17:13] should i remove it? [17:14] ah, removing it does the trick :) [17:14] thanks [17:17] not bzr says it can't find dulwich :S [17:17] yet it's in the python path [17:44] Noldorin: if you'r using the standalone bzr.exe I think you need to install plugins in a different place as bzr.exe use it's own python interepreter [17:44] verterok: yeah, so it seems [17:45] any idea what i need to do with dulwich? [17:45] since i want the bzr binary to use it [17:45] well, bzr-git actually [17:51] verterok: i've pasted the git and dulwich folders into C:\Program Files\Bazaar\plugins [17:51] but it's not recognising dulwich still [17:51] No module named dulwich.errors [17:51] Unable to load plugin u'dulwich' from u'C:/Program Files/Bazaar/plugins' [17:51] bzr: ERROR: Unable to import library "dulwich": bzr-git: Please install dulwich, [17:51] https://launchpad.net/dulwich [17:52] dulwich isn't a bzr plugin, it's a python module/library/whatevertheycallit. [17:53] I don't think you can use such things with the prebuilt bzr.exe; you'd have to use the python version. [17:53] fullermd: yeah, that's what i was thinking [17:53] (Or I could be full of bullcaca; I don't really know windows) [17:53] was wondering why bzr-git was looking for it in plugins there [17:53] heh [17:53] fullermd: i think you may well be rigtht - i may need the python version [17:54] fullermd: hrm, can't i just edit the PYTHONPATH for bzr.exe somehow? [17:54] http://osdir.com/ml/bazaar/2009-11/msg00361.html [17:55] I'm not sure you can; bzr.exe bundles it all up internally. [17:55] hrm [17:57] fullermd: so you recommend i just set up the python version of bzr 2.0, etc.? will it happily coexist along side the exe version? [17:57] I have no idea. It's been 13 years since I had a system running Windows. [17:57] hah ok [17:58] I'd tend to think having both would be sticky. [17:58] But it may not be. I'm well into "guessing" territory there. [17:59] mm, as am i [18:00] fullermd: if i only have either in my PATH, then things might be ok [18:01] brb [18:11] hi. Is there a way of finding out what "bzr update" will do without actually running it [18:58] hello. do i need the python installation of bzr to run bzr-git/dullwich? [19:46] Is Bundle Buggy genuinely still alive, or does HACKING.txt lie? [20:00] i have a question regarding how best to do something with bzr... [20:01] it's a little long, though... so rather than flooding the channel, i've pasted the question here: http://paste.pocoo.org/show/161426/ [20:07] pattern: you can just commit specific files [20:08] or use a makefile which will only rebuild things if there is a change [20:08] or make an ignored file where you list files to ignore [20:09] well, i could use a makefile that ignores files that aren't changed... however, LaTeX will still read them all to create the new pdf... so it doesn't really help [20:11] the only way to have those files not read by LaTeX is either to comment out the code that includes them, or to delete that code [20:11] commit specific files then [20:12] i do commit each individual file in bzr [20:12] but the problem is more with the files that have the code that includes the individual files [20:13] they're like #include directives in c [20:13] and i have those lines commented out while i'm working [20:14] each of those include directives is just \include{foo}, where "foo" is the filename [20:14] so it's not like the file that has these include directives actually contains the whole file it's "including" [20:14] it's just a direction to the compiler to include the file [20:15] the contents of those files are completely seperate from the file they're included in [20:15] and both the file that's doing the inclusion and the included file are seperately versioned in bzr [20:16] well, that's tricky [20:16] yep :) [20:16] there must be some way to avoid rebuilding deps if they're not changed [20:16] that's why i come to the experts :) [20:18] i'm pretty sure there's no way to avoid rebuilding the files that haven't changed other than either commenting out or deleting the include directives [20:21] actually.. there might be another way [20:22] i think LaTeX has some control flow commands, which i haven't been using yet [20:22] but i should look in to them [20:22] that way it could maybe skip a part of the file if a variable is set [20:22] that would be idea [20:22] ideal [20:23] then the variable could be set from the makefile [20:23] and make could be told to set this variable from the command line [20:23] that would be perfect [20:25] hmm... but now that i think about it... it might not solve the problem after all [20:26] as, say i bracketed off files 1-95 as being compiled or not depending on a variable... and check that version of the include file in while i worked on files 95-100 [20:27] at some point i'll want to bracket off files 1-100 while i work on files 100-105 instead [20:27] and that will entail rewriting the code in the include file [20:28] unless maybe i think of some way to reduce the granularity such that i can somehow include each individual file or not, from the command line [20:28] hi. do i need the python installation of bzr to get bzr-git/dulwich to work on windows? [20:28] anyway... this gives me some leads... [20:28] thanks for your help, gutworth! [20:29] getting the following error at present: http://pastebin.com/m3a6a2e4e === Guest46284 is now known as andrewblack [21:13] How alive/dead is the BundleBuggy project now that bzr itself no longer uses it? [21:15] > hi. do i need the python installation of bzr to get bzr-git/dulwich to work on windows? === khmarbaise_ is now known as khmarbaise [22:04] bob2: ping? [22:04] I don't have an answer [22:04] I was just wondering if you'd asked on the list [22:05] lots of people are on holidays atm so might not see discussion on irc [22:05] yeah, good point [22:06] probably worth a shot [22:06] bob2: it's a pain to set some of this beta stuff up when you don't know much about python (as i don't)... [22:06] it seems it's just dulwich that's causing the problem [22:06] i want bzr.exe to recognise it in the path [22:07] hrm [22:13] gutworth: i finally figured out a solution for my problem... what i'll do is keep all the include directives uncommented in files A and B, and then have my makefile run them through a filter that will comment out what i need and save the output under a new name, say A2 and B2 [22:13] A and B will be versioned, but A2 and B2 will not [22:13] and A2 and B2 will be the files that latex uses to compile [22:14] of course, what the script run by the makefile comments out will depend on what options i pass to make on the command line