[14:27] <daveb_> hey
[14:28] <daveb_> has anyone done anything with inotify and bzr to have an automatic push system?
[14:36] <glyph> daveb_: bzr already has automatic pushing, I think you mean automatic committing?
[14:51] <thorwil> 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] <thorwil> 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] <daveb_> glyph: yes, thats what i mean
[15:25] <daveb_> has anyone done anything with inotify and bzr to have automatic commiting?
[15:30] <mgedmin> I wonder if you could use SparkleShare for that (if you convinced it to use bzr as a backed instead of git)
[15:32] <jam1> morning #bzr
[15:38] <jam> hey vila, are you still around? Just wanted to say happy new year
[15:55] <vila> jam: yeah ! Happy new year to you too !
[16:13] <daveb_> mgedmin: would there be an advantage to using git?
[16:14] <mgedmin> well, you could use unmodified sparkleshare, if you used git, I suppose
[16:14] <mgedmin> but I don't know if it fits your usecase
[16:14] <mgedmin> or if it's sufficiently functional in its current beta incarnation
[16:19] <daveb_> 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] <mgedmin> sounds like you're looking for something like Dropbox (or Ubuntu One)
[16:22] <daveb_> mgedmin: we like dropbox, we just want to be able to host it
[16:23] <daveb_> and, well, versioning would be nice
[16:23]  * mgedmin nods
[16:23] <mgedmin> sounds like SparkleShare is exactly that then
[16:24] <mgedmin> if you're not allergic to c#/mono/git
[16:24] <mgedmin> or software that's in beta
[16:24] <daveb_> yea, thanks for pointing me to it
[16:24]  * mgedmin is keeping an eye on it, but hasn't tried it yet
[16:24] <daveb_> it looks promising
[16:24] <daveb_> they say windows support is comming soon
[16:29] <chx> 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] <vila> chx: I think it's part of the upcoming 2.3b5, let me check
[16:34] <vila> chx: yup, 2.3b5
[16:35] <vila> chx: I don't remember the details, but the behaviour in b4 is... blurry...
[16:36] <vila> chx: but you can achieve the same effect with: cp c.t.OTHER c.t ; bzr resolve c.t
[16:42] <chx> sure
[17:45] <zyga> hi
[17:45] <zyga> should bzr be installable via pip on win32?
[17:45] <zyga> I installed visual studio express 2008
[17:46] <zyga> but the install script fails on ValueError in distuitls msvc9compiler.py
[17:48] <phil`> Anyone willing and able to help fix a messed-up install of bzr on debian?
[17:52] <zyga> phil`, how did you install?
[18:04] <phil`> sudo apt-get install bzr bzrtools
[18:04] <phil`> Here's the output:
[18:04] <phil`> The following packages have unmet dependencies:
[18:04] <phil`>  bzr : Depends: python (< 2.6) but 2.6.6-3+squeeze4 is to be installed
[18:04] <phil`>  
[18:04] <phil`> Had it installed and working for years
[18:05] <phil`> A while back, started getting 'packages held back' when doing apt-get update
[18:06] <phil`> Decided today to uninstall and re-install, but no go, same 'unmet deps' msg
[18:09] <phil`> AFAICT I have up-to-date python2.6 and python2.5 installed
[18:11] <maxb> phil`: This would tend to suggest the bzr package being seen is not the correct one for your distribution
[18:11] <maxb> Please pastebin your /etc/apt/sources.list
[18:12] <maxb> also the output of 'apt-cache policy bzr'
[18:12] <maxb> also say whether you have any files in /etc/apt/sources.list.d/
[18:12] <phil`> newb: ?pastebin? (sorry)
[18:13] <maxb> A website for sharing text more conveniently than long pastes directly in the channel
[18:13] <maxb> e.g. http://paste.ubuntu.com
[18:13] <phil`> Gotcha
[18:14] <phil`> apt-cache policy: http://paste.ubuntu.com/549918/
[18:16] <phil`> sources.list: http://paste.ubuntu.com/549921/
[18:16] <phil`> sources.list.d is empty
[18:18] <maxb> ah
[18:19] <maxb> You seem to be using Ubuntu hardy packages on your Debian system
[18:19] <phil`> D'oh
[18:20] <maxb> For a Debian squeeze machine, I'd say you have a better chance using Ubuntu lucid packages thatn Ubuntu hardy
[18:25] <phil`> Installing now! Thank you maxb, you're a hero.
[18:31] <maxb> It's a shame we don't have a better solution for Debian, but setting up a buildd system isn't easy
[18:31] <phil`> I hear that
[18:32] <phil`> All good now!
[18:50] <notmyname> 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] <beuno> notmyname, bzr missing ..//otherbranch
[18:51] <beuno> that;s ../otherbranch
[18:51] <beuno> or the path to it
[18:52] <notmyname> 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] <beuno> if nothin is missing, then you get nothing
[18:55] <beuno> id something is, it tells you which revisions
[18:58] <maxb> You probably want 'bzr missing --mine-only ../trunk' or 'bzr missing --theirs-only ../otherbranch'
[19:00] <notmyname> maxb: thanks. I was getting lots of output without those switches
[19:00] <notmyname> beuno: maxb: thanks for the help
[20:52] <glyph> so I'm reading the DaggyFixes page
[20:52] <glyph> and I think I finally managed to understand it
[20:53] <glyph> 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] <jam> glyph: then you use a later version of the branch
[20:56] <jam> the point of doing it early, is so it is easier to apply the fix in lots of scenarios
[20:57] <jam> if you need new test infrastructure, then that no longer applies
[20:57] <jam>   but it also clearly means that you won't be able to easily apply the new bugfix to old releases
[20:59] <glyph> I guess the gist of daggyfixes is actually just 'fix it in the old branch first'
[20:59] <jam> glyph: that is the basic idea
[20:59] <jam> if that isn't practical
[20:59] <jam> then do whatever makes the most sense
[20:59] <jam> you also can layer the fix
[21:00] <jam> using looms/etc
[21:00] <jam> so you have a branch where you fix it
[21:00] <jam> which then you merge into a newer branch that has the tests.
[21:00] <jam> though that runs into "is it really fixed in the original branch? I don't have a test for it"
[21:15] <glyph> jam: In this case, the question was really about test infrastructure introduced on the older branch, but after the fix
[21:16] <glyph> so the answer is really 'okay, just start after the test infrastructure was introduced then'
[21:16] <glyph> 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] <glyph> 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'