=== knitt1 is now known as knittl === oubiwann is now known as oubiwann-holiday === oubiwann-holiday is now known as oubiwann_ === oubiwann_ is now known as oubiwann === oubiwann is now known as oubiwann_ === oubiwann_ is now known as oubiwann [14:27] hey [14:28] has anyone done anything with inotify and bzr to have an automatic push system? [14:36] daveb_: bzr already has automatic pushing, I think you mean automatic committing? [14:51] hi! i have one development branch and a packaging branch on lp. for the first rev of the packaging branch, the reference to the devel branch is clear. [14:51] but now, several devel revs later, easiest would be to copy the files i need to the packaging branch. but is there a way to associate the packaging rev with a devel rev, then? [15:15] glyph: yes, thats what i mean [15:25] has anyone done anything with inotify and bzr to have automatic commiting? [15:30] I wonder if you could use SparkleShare for that (if you convinced it to use bzr as a backed instead of git) [15:32] morning #bzr === jam1 is now known as jam === jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | | 2.3b4 is officially out ! (rm vila) [15:38] hey vila, are you still around? Just wanted to say happy new year [15:55] jam: yeah ! Happy new year to you too ! === beuno is now known as beuno-lunch [16:13] mgedmin: would there be an advantage to using git? [16:14] well, you could use unmodified sparkleshare, if you used git, I suppose [16:14] but I don't know if it fits your usecase [16:14] or if it's sufficiently functional in its current beta incarnation === Ursinha is now known as Ursinha-lunch [16:19] well, i want the some of the advantages of a VCS, but I really want something that is so simple that people dont have to think about using it, maybe implemented in a filesystem or something... high availability (offline access) is importaint. I was thinking of using some sort of wrapper for bzr, so that when ever anyone change something on their checkout, it would automatically commit it so it would be available... [16:22] sounds like you're looking for something like Dropbox (or Ubuntu One) [16:22] mgedmin: we like dropbox, we just want to be able to host it [16:23] and, well, versioning would be nice [16:23] * mgedmin nods [16:23] sounds like SparkleShare is exactly that then [16:24] if you're not allergic to c#/mono/git [16:24] or software that's in beta [16:24] yea, thanks for pointing me to it [16:24] * mgedmin is keeping an eye on it, but hasn't tried it yet [16:24] it looks promising [16:24] they say windows support is comming soon [16:29] i am running 2.3b4 and i tried bzr resolve --take-other modules/comment/comment.test but it says Text conflict in modules/comment/comment.test [16:32] chx: I think it's part of the upcoming 2.3b5, let me check [16:34] chx: yup, 2.3b5 [16:35] chx: I don't remember the details, but the behaviour in b4 is... blurry... [16:36] chx: but you can achieve the same effect with: cp c.t.OTHER c.t ; bzr resolve c.t [16:42] sure === beuno-lunch is now known as beuno === Ursinha-lunch is now known as Ursinha [17:45] hi [17:45] should bzr be installable via pip on win32? [17:45] I installed visual studio express 2008 [17:46] but the install script fails on ValueError in distuitls msvc9compiler.py [17:48] Anyone willing and able to help fix a messed-up install of bzr on debian? [17:52] phil`, how did you install? [18:04] sudo apt-get install bzr bzrtools [18:04] Here's the output: [18:04] The following packages have unmet dependencies: [18:04] bzr : Depends: python (< 2.6) but 2.6.6-3+squeeze4 is to be installed [18:04] [18:04] Had it installed and working for years [18:05] A while back, started getting 'packages held back' when doing apt-get update [18:06] Decided today to uninstall and re-install, but no go, same 'unmet deps' msg [18:09] AFAICT I have up-to-date python2.6 and python2.5 installed [18:11] phil`: This would tend to suggest the bzr package being seen is not the correct one for your distribution [18:11] Please pastebin your /etc/apt/sources.list [18:12] also the output of 'apt-cache policy bzr' [18:12] also say whether you have any files in /etc/apt/sources.list.d/ [18:12] newb: ?pastebin? (sorry) [18:13] A website for sharing text more conveniently than long pastes directly in the channel [18:13] e.g. http://paste.ubuntu.com [18:13] Gotcha [18:14] apt-cache policy: http://paste.ubuntu.com/549918/ [18:16] sources.list: http://paste.ubuntu.com/549921/ [18:16] sources.list.d is empty [18:18] ah [18:19] You seem to be using Ubuntu hardy packages on your Debian system [18:19] D'oh [18:20] For a Debian squeeze machine, I'd say you have a better chance using Ubuntu lucid packages thatn Ubuntu hardy [18:25] Installing now! Thank you maxb, you're a hero. [18:31] It's a shame we don't have a better solution for Debian, but setting up a buildd system isn't easy [18:31] I hear that [18:32] All good now! [18:50] now that I've been working on a project for a while, I've got lots of directories (including "trunk") in my parent directory (the one where I ran bzr init-repo). how can I tell which ones have been merged into trunk? [18:51] notmyname, bzr missing ..//otherbranch [18:51] that;s ../otherbranch [18:51] or the path to it [18:52] so I go to "trunk", run "bzr missing /path/to/otherbranch" and what do I see if it's been merged (or hasn't been merged)? a nice message? nothing? [18:55] if nothin is missing, then you get nothing [18:55] id something is, it tells you which revisions [18:58] You probably want 'bzr missing --mine-only ../trunk' or 'bzr missing --theirs-only ../otherbranch' [19:00] maxb: thanks. I was getting lots of output without those switches [19:00] beuno: maxb: thanks for the help [20:52] so I'm reading the DaggyFixes page [20:52] and I think I finally managed to understand it [20:53] but there is a use-case it doesn't cover: what if I want to use a testing feature that was introduced some time after the bug was introduced in order to test the fix? [20:56] glyph: then you use a later version of the branch [20:56] the point of doing it early, is so it is easier to apply the fix in lots of scenarios [20:57] if you need new test infrastructure, then that no longer applies [20:57] but it also clearly means that you won't be able to easily apply the new bugfix to old releases [20:59] I guess the gist of daggyfixes is actually just 'fix it in the old branch first' [20:59] glyph: that is the basic idea [20:59] if that isn't practical [20:59] then do whatever makes the most sense [20:59] you also can layer the fix [21:00] using looms/etc [21:00] so you have a branch where you fix it [21:00] which then you merge into a newer branch that has the tests. [21:00] though that runs into "is it really fixed in the original branch? I don't have a test for it" [21:15] jam: In this case, the question was really about test infrastructure introduced on the older branch, but after the fix [21:16] so the answer is really 'okay, just start after the test infrastructure was introduced then' [21:16] there's another class of question though, which is 'what if the project policy is always "fix on the new branch first, then backport fixes"' [21:17] and there are a bunch of different formulations of that, but from what I can tell it's 'do a merge with a -r argument and then don't forget that you did that because if you do it again it will look awful and have tons of conflicts' === seiflotfy_ is now known as help === help is now known as Guest41209 === Guest41209 is now known as seiflotfy === spm` is now known as spm === Meths_ is now known as Meths === rockstar is now known as rockstar` === rockstar` is now known as rockstar