MapManhello! Im seeking help!00:02
MapManfrikazoyd: oh hai00:02
frikazoydbeat you to it00:02
VerterokMapMan: just ask00:04
MapManVerterok: my mate frikazoyd already asked00:04
Verterokok, then00:04
MapManmaybe you can help us though00:06
MapManwe have a problem with bzr00:06
MapManevery commit > push causes a lock00:06
MapManand everytime someone wants to push, he needs to break lock00:06
lifelesswell, I know where my disk space has gone00:11
lifelessevo -> 6.4g used00:11
lifelessfrikazoyd: the branch you are pushing to; is it on nfs/ftp/sftp/bzr+ssh ?00:12
lifelessfrikazoyd: and are the permissions set to allow both of you to create and delete common files?00:12
MapManits ftp mate00:13
MapMani dunno about the permissions, i havnt seen the cfg00:13
lifelesscheck in ~/.bzr.log for errors related to deleting00:13
lifeless(unless break-lock does work, in which case you clearly can delete)00:13
lifelessmight be a ftp server bug that you can't delete a file you created in the same session or something weird00:14
lifelessanyhow, its not usual, we do work on ftp; please file a bug and the devs can ask for details there to figure out whats wrong (if you can't figure out a config issue shortly)00:14
aa_hi everyone00:16
aa_I get this error trying to push: http://paste.pocoo.org/show/86007/00:17
aa_now I try what it suggested but unknown protocol00:17
aa_is it a launhcpad thing or a bzr thing?00:17
spivaa_: it's a bit of both00:20
spivaa_: use bzr break-lock with your usual URL.00:20
spivaa_: e.g. bzr break-lock lp:~name/proj/foo00:20
frikazoydLifeless:  The problem isn't that we can't delete, the problem is that a lock is automatically created if someone pushes00:22
frikazoydand it doesn't release00:22
frikazoydso if I commit a file in a local branch and then push, it puts a lock on the central repo I'm pushing to00:22
frikazoydso nobody else can push that file either (even if it is up to date before editing) unless they break my lock00:23
frikazoydWe don't want to have to break locks to commit and merge every time someone changes an existing file00:23
lifelessfrikazoyd: I'm talking about the technical details required to manage the transient locks bzr uses to ensure data consistency as it pushes00:24
lifelessfrikazoyd: please assume I understand exactly what you want and how it works and am trying to help you get it to work as it *should* for you.00:24
frikazoydthe .bzr.log file doesn't exist00:25
frikazoydalso breaking works fine00:26
lifelessbzr --version00:26
lifelesswill have a line like00:26
lifeless  Bazaar log file: /home/robertc/.bzr.log00:26
lifelesswith the full path to the local log file00:26
MapManwe use windows binaries00:26
frikazoydMap:  You can do it from command line :P00:26
MapManits in default user folder in windows00:26
MapManI hate that, it should be placed in apps folder00:27
aa_spiv: I did that and it returns without error, but it doesn't break the lock00:27
aa_spiv: doesn't break the lock == still has the cannot get lock error00:28
spivaa_: its https://bugs.edge.launchpad.net/bzr/+bug/255062, btw00:30
ubottuUbuntu bug 255062 in bzr "bzr: ERROR: Invalid url supplied to transport: "Host empty in" [High,Confirmed]00:30
spivaa_: That should break the lock.  You could try "bzr break-lock sftp://aafshar@bazaar.launchpad.net/~glashammer-devs/glashammer/glashammer-main" instead, but that shouldn't be any different.00:31
spivaa_: Hmm, by "returns without error", you mean it doesn't output anything, not even a prompt?00:31
aa_spiv: no just returns00:32
aa_I get the shell prompt afterwards00:32
aa_and return code is 000:32
spivOk, then there is no lock to break.00:33
aa_"locked 24 minutes, 59 seconds ago"00:33
spivWhat's cannot get lock error look like?00:33
aa_spiv: that thing I apsted00:33
spiv(and on what operation?)00:33
aa_on bzr push00:33
aa_its exactly the thing I pasted here http://paste.pocoo.org/show/86007/ except the time is creeping up00:34
=== Guest25912 is now known as jelmer
spivIs your launchpad user a member of glashammer-devs?00:36
spivHmm, it appears it is.00:36
spivWhat URL exactly is your local branch pushing to?00:37
aa_spiv: if I forget about it for a while is it likely to go away, or will it stay forever?00:37
spivIt isn't going to go away by itself unless the connection that created it is still connected.00:38
aa_bzr push bzr+ssh://aafshar@bazaar.launchpad.net/%7Eglashammer-devs/glashammer/glashammer-main/00:38
aa_locked 30 minutes, 44 seconds ago? [y/n]:00:39
aa_that's new00:39
aa_spiv: guess I was running break-lock on the wrong url00:39
aa_spiv: sorry for the bother00:40
spivThat's ok.00:40
spivGlad to hear that you're sorted.00:40
Odd_Blokepoolie: Did you get my email with bank details?  I never got an ACK.02:11
poolieOdd_Bloke: hi, yes, i passed it on to our finance guy02:13
Odd_Blokepoolie: Cool, thanks. :)02:13
pooliei wonder if gpg defeated him because i didn't hear anything myself :)02:13
pooliebut i did send an extra comment explaining it02:13
igcmorning all02:15
pooliehello igc, how are you going?02:16
igchi poolie - ok today02:16
Odd_Blokeigc: Hey, long time no see.02:20
igchi Odd_Bloke!02:20
=== sdboyer|oot is now known as sdboyer
pooliejam, the description of the change to log seems to make sense to me too02:54
poolieif you want me to look at it harder, just say so02:54
=== spiv_ is now known as spiv
pooliei'm trying to work out what's up with the oldest queued patch, "setlocale (bug 128496)"03:31
ubottuLaunchpad bug 128496 in bzr-svn "Unable to open native working tree with non-ascii filenames" [Medium,Fix released] https://launchpad.net/bugs/12849603:31
lifelessis it correct that opening a RemoteBranch always opens the underlying disk branch ?03:37
lifelessk, I'll do an isinstance in my branch hook open tests03:41
pooliehrm, ok03:41
poolielifeless: it's a bit hard to avoid it given the repository stacking must be configured when the branch is opened03:42
lifelesspoolie: yeah03:42
lifelesspoolie: its just to make the interface tests that say what the hook should do, pass03:42
poolieobviously you could just make a promise to do it later, but iirc people have argued errors with the repo must be detected then03:43
lifelessIf spiv knows that opening a remote branch generates remote + normal object03:43
spivI'm aware that the stacking stuff has caused that, yeah :(03:43
lifelesself.assertEqual([b], self.hook_calls)03:43
lifelessAssertionError: not equal:03:43
lifelessa = [RemoteBranch(bzr://]03:43
lifelessb = [RemoteBranch(bzr://,03:43
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:43
lifelessAssertionError: not equal:03:43
lifelessa = [RemoteBranch(bzr://]03:43
lifelessb = [RemoteBranch(bzr://,03:43
lifeless BzrBranch6('chroot-46912499497232:///')]03:43
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:43
lifelessAssertionError: not equal:03:43
lifelessa = [RemoteBranch(bzr://]03:43
lifelessb = [RemoteBranch(bzr://,03:43
lifeless BzrBranch6('chroot-46912499497232:///')]03:43
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:43
lifelessAssertionError: not equal:03:43
lifelessa = [RemoteBranch(bzr://]03:44
lifelessb = [RemoteBranch(bzr://,03:44
lifeless BzrBranch6('chroot-46912499497232:///')]03:44
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:44
lifelessAssertionError: not equal:03:44
lifelessa = [RemoteBranch(bzr://]03:44
lifelessb = [RemoteBranch(bzr://,03:44
lifeless BzrBranch6('chroot-46912499497232:///')]03:44
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:44
lifelessAssertionError: not equal:03:44
lifelessa = [RemoteBranch(bzr://]03:44
lifelessb = [RemoteBranch(bzr://,03:44
lifeless BzrBranch6('chroot-46912499497232:///')]03:44
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:44
lifelessAssertionError: not equal:03:44
lifelessa = [RemoteBranch(bzr://]03:44
lifelessb = [RemoteBranch(bzr://,03:44
lifeless BzrBranch6('chroot-46912499497232:///')]03:44
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:44
mwhudsonlifeless: oops03:44
lifelessAssertionError: not equal:03:44
lifelessa = [RemoteBranch(bzr://]03:44
lifelessb = [RemoteBranch(bzr://,03:44
lifeless BzrBranch6('chroot-46912499497232:///')]03:44
lifeless BzrBranch6('chroot-46912499497232:///')]self.assertEqual([b], self.hook_calls)03:44
lifelessAssertionError: not equal:03:44
lifelessa = [RemoteBranch(bzr://]03:44
lifelessb = [RemoteBranch(bzr://,03:44
lifelessno idea what caused that; wifi glitch I guess03:45
lifeless(it wasn't pasting, so I tried again..)03:45
spivlifeless: stop playing hopscotch on your middle mouse button ;)03:45
lifelessspiv: anyhow03:45
lifelessself.assertEqual([b], self.hook_calls)03:45
lifelessAssertionError: not equal:03:45
lifelessa = [RemoteBranch(bzr://]03:45
lifelessb = [RemoteBranch(bzr://,03:45
lifeless BzrBranch6('chroot-46912499497232:///')]03:45
lifelessthats the clear unmixed up assertion03:45
lifelessso I propose to isinstance it and changed the expect value appropriately.03:45
lifelessthat sound ok?03:48
spiv(sorry, lag on my end isn't helping)03:51
spivadjusting the test for the RemoteBranch scenario to assert that the hook observes the same remote branch get opened, plus a non-RemoteBranch, sounds good to me.03:53
spivGiven that's what (currently) happens.03:53
lifelesswell specifically, I'll use the real branch from the opened branch03:53
spivAh, ok.03:53
lifelesswe know what it is after all, no need for a hand-wave03:54
spivYeah, that makes sense. "if isinstance(b, RemoteBranch): expected.append(b._real_branch)", basically?03:54
spivSounds reasonable.03:54
lifelessis that bb:approve to this change ?03:54
lifelessoh, I see, it is a remote VFS call already04:03
lifelesstweaking more04:03
lifelesscan I ask though, why the current find_branch wasn't just extended to return the stacking url as well, to avoid additional round trips ?04:03
lifelessspiv: here?04:06
spivlifeless: intermittently, it seems.04:09
spiv"Lag: 51 (??)"04:09
* spiv restarts irssi04:10
spivWell, the "good" news is that restarting irssi didn't magically make IRC stop lagging.04:21
Spazdoes it still lag with other clients?04:23
* igc lunch04:28
nealmcbI just did a "bzr add" of some files I didn't really want to add.   I've been stung in the past because iirc immediately doing "bzr remove" actually removed the file.  how do I un-do the "add".  I haven't committed yet04:57
AfCnealmcb: use Bazaar's remove command, but add the --keep option04:57
=== samurai is now known as samiam
AfC$ bzr rm --keep path/to/file/I/added/by/mistake.txt04:58
=== samiam is now known as samurai
nealmcbAfC: thanks.  Last time I think I decided that --new  would do that (Remove newly-added files) but --keep looks much better  :)04:59
AfCAlthough as I read the help for remove in 1.7rc1 I see it say "--safe       Only delete files if they can be safely recovered (default)."04:59
Peng_What about "bzr revert"ing them? Would that work?04:59
AfCwhich would make me think that you would have been ok after all.04:59
=== sdboyer is now known as sdboyer|zzz
AfCPeng_: I imagine Bazaar would respond by complaining that the paths aren't versioned. (ie, "How can I revert a file to a state that I don't know about?"). But it might have special case logic. One way t find out.05:00
Peng_Yeah, "revert" works05:01
Peng_If "rm" deleted an unversioned file, that would be a bug.05:01
lifelessalso, I think bzr rm <added-file> should act like revert, IMO. I don't know if it *does*, but it seems like a sensible default to me.05:09
Peng_"bzr rm added-file" errors out with "bzr: ERROR: Can't safely remove modified or unknown files".05:17
Peng_"bzr rm --keep added-file" works fine, just like revert.05:17
Peng_Hmm, I should test "--new".05:18
lifelesspoolie: don't-sha-added-files is passing micro-tests, full run underway05:31
lifeless-> lunch05:31
poolielifeless, nice05:40
* fullermd ponders.05:54
fullermd1.7 isn't yet, right?05:54
fullermdHm.  Webiste doesn't like rc2 either.  Wacky.05:54
lifelessall tests pass. wahoo06:05
poolielifeless, i was thinking of changing the test runner so that if a test fails it shows the stacktrace rightaway06:34
poolierather than waiting til the suite has finished06:34
lifelesspoolie: as an option ?06:48
poolieif necessary06:53
pooliei find i'd often like to start looking at the first failure while it's running....06:53
lifelessI'm pretty sure I had a project once that output nothing at all, except error traces, and those as they happened06:54
lifelessweirded people out06:54
lifelessI'm personally pretty happy with the current behaviour, but then if I'm running either to get all the errors to filter, or with -1, as a general pattern06:55
pooliei can't parse that "either"06:55
vilahi all !06:58
spivvila: good afternoon06:58
lifelessI tend to run bzr selftest in one of a few modes06:58
lifelesswith -1, to find and debug a failure06:58
lifelesswithout -1 to find all the failures (and I want a compact manner of inspecting them06:58
lifelesswithout -1 on a small set of tests (found by the previous run)06:58
lifelessI've mentioned before wanting to do a machine parsable output to file to automate this more07:00
poolieok, same07:01
vilaI do the same. And when I get a small enough set of failing tests, I start putting some pdb.set_trace()07:01
lifelessI don't know if this is optimal, or an accomodation of sorts07:01
pooliethe main thing i want is to not have to wait until all of them run to find the rest07:01
lifelessother data point is I run from within vim07:01
lifelessso I'm always going to be waiting07:01
pooliepossibly it would be better to write them either to a separate file (maybe in a subdirectory)07:01
poolieor to use tribunal or something07:02
vilaBut sometimes, I wish I had the traceback for one of them. In that case I C-c and re-run only that tests with --starting-with07:02
poolieoh btw i have a vim tip07:02
pooliefor when switching to another branch07:02
pooliedo :1,9999bdel to remove everything already in memory07:02
poolieand avoid accidentally editing files from your old directory07:03
lifelesspoolie: heh, I don't need that07:03
lifelessI suspect I use vim rather...differently to you07:03
Odd_Blokevila: I used --starting-with when writing the `branch --standalone` stuff, and it's much faster.  Good job on that. :)07:03
vilaOdd_Bloke: you're welcome :)07:04
poolieto start with i use gvim07:05
pooliequitting and restarting is adequate but it's nice to know an alternative07:05
lifelesspoolie: yahh, I use text vim, and many concurrent sessions07:26
jmlspiv: ping07:31
spivjml: pong07:42
=== Ng_ is now known as Ng
a_c_manyone know any good (semi idiot) tutorials on setting up bzr with pqm (ie automated gatekeeper workflow)10:43
dereinehow can i get all changed files since the init10:50
dereineor all changed files between two revisions10:50
james_wa_c_m: I don't know of one, sorry10:51
a_c_mjames_w: yeah thats a shame... i'm googling for one now10:51
james_wdereine: "bzr status -r" may be what you want10:52
james_we.g. bzr status -r2..310:52
dereinehow do i get the latest revision?10:59
james_wwhat do you mean?10:59
lifelessthe pqm docs include setup info; file bugs please if its not enough11:00
lifelessdereine: '-1' refers to the tip revision11:00
siretartlifeless: maybe I didn't get what you mean with 'part of the target that pqm runs to run tests could update NEWS'11:23
lifelesssiretart: there is a Makefile11:48
lifelesssiretart: it has targets; one of those targets is dedicated to PQM, its the 'run this when doing a merge' target11:49
lifelesssiretart: I'm suggesting it can be extended to also update the NEWS file from the merge source (because its run in a tree with a pending merge, it can do $something to do this)11:49
siretartlifeless: okay. does this $something include the results of the testsuite?11:52
lifelesssiretart: no11:53
lifelesssiretart: I'm talking about the NEWS file11:53
lifelesssiretart: which is a problem for merges11:53
siretartokay. then I misunderstood you completely. ignore me then11:53
lifelesssiretart: I don't understand why you are talking about test suite output - its always all-pass because thats the policy for PQM11:53
lifelesssiretart: if it fails, we don't commit it11:53
lifelesssiretart: If Debian is packaging bzr with test failures, thats bad, and it should definitely stop doing that :P11:54
siretartlast upload contained some known pycurl failures that I was told were harmless11:56
lifelessthey happen consistently on recent pycurls, I'm not convinced they are harmless11:57
lifelessvisik7: ^11:57
lifelessvila: ^11:57
lifelesssorry visik711:57
lifelesssiretart: I am curious why you thought a thread about NEWS was related to Debian packaging ?11:59
lifelessoops, community council meeting time, back later11:59
siretartlifeless: I was under the impression you wanted to include results of the testsuite to NEWS12:02
lifelessI guess its context12:03
lifelessyou may not but NEWS is a continual merge headache12:03
lifelessbecause entries may merge ok but be in the wrong release etc12:04
vilasiretart: I'd be *very* interested about those pycurl failures, do you have some selftest output ?12:18
siretartnot anymore, I removed the output some days after my upload12:20
siretartlifeless: see, it might make sense to install the selftest output in the package after all ;)12:21
lifelesssiretart: sure, I wasn't saying it was a bad idea, just totally confusing for me in that tread12:22
siretartyes, I was confused as well. sorry12:22
lifelesssiretart: it was a non sequiter :)12:22
vilasiretart: mail me the next time you run the test suite then :)12:37
=== bac_afk is now known as bac
lifelessvila: there is a bug12:44
vilalifeless: only one ? Gosh, we're close :)12:45
vilalifeless: yes ? What bug ?12:47
lifelessvila: on the pycurl failures12:48
vilaYou can reproduce it ?12:49
lifelessspiv can12:52
spivI can't anymore; it got fixed AFAICT.12:53
vilathe poll/select one ?12:54
spivYep, that's the one I used to see.12:54
vilaa nightmare :)12:54
lifelesssiretart: how long ago was the upload?12:54
vilaOnce I upgraded to hardy it popped up everywhere :)12:54
siretartlifeless: that was the last upload to debian experimental12:55
lifelesssiretart: not what, when12:55
siretartsep 5, 200812:55
vilasiretart: does it looks like bug #225020 ?12:55
ubottuLaunchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/22502012:55
siretartI'm running the testsuite right now on my intrepid laptop12:55
siretartvila: yes, I think I've seen "select/poll returned error" back then12:56
vilasiretart: the bug is fixed in 1.7 but not in 1.6.1. I think intrepid uses the later12:57
vilalifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) >12:58
lifelessvila: arh, don't think so.12:59
vilalifeless: no urgency,  that should be done carefully...13:00
siretartvila: what is your email adress?13:01
vilav.ladeuil+lp at free.fr13:01
lifelessvila: is the bug fixed?13:02
vilalifeless: yes, it didn't dare reproduce anywhere AFAIK13:03
vilalifeless: but note that it's fixed in 1.7 and pqm uses 1.6.1 if I'm correct13:05
lifelessvila: errr13:06
lifelessvila: it was removed from the pqm chroot, not from the bzr pqm uses13:06
lifelessvila: two totally separate thing13:06
vilaI understand that13:07
vilaMy point was that running the tests should not fail anymore, but merging before running the tests may13:07
lifelessvila: my point is that the bzr doing the merging *still has pycurl* AFAIK13:08
lifelessvila: and never had trouble merging13:08
vilalifeless: then all is fine and I will cure my paranoia happily :)13:08
* vila will try to better understand what run under the chroot and what doesn't another day :)13:09
lifelessvila: 'make check' runs in teh chroot. Nothing else does13:12
vilaclear and simple, thanks13:13
lllamaHello all. Anyone got a good method for running the smart server as a service on a central ubuntu box?13:18
pysquaredDoes anyone know how to do garbage collection in a shared repository after deleting unwanted branches?13:22
lifelesspysquared: currently there isn't a simple answer; unless your branches are large I would say don't worry13:23
pysquaredThis post https://lists.ubuntu.com/archives/bazaar/2007q3/031099.html mentions a "garbage collection" plugin, but provides no link, and I cannot find one.13:23
lifelesspysquared: I don't think there is13:24
pysquaredI thought it would be nice to have a bzr2xyz (and back again) in a similar vein to http://msi2xml.sourceforge.net, to allow open-heart-surgery on a repo - anyone else thought this?13:25
=== Snaury is now known as Snaury[away]
lifelesspysquared: thats roughly what fast-import|fast-export is, though note that *any* modification makes your content appear like new branches to others (its a distributed DB)13:28
lifelesspysquared: rebase and similar tools are much more user friendly ways to make it hard for people to merge :P13:28
=== bac is now known as bac_breakfast
pysquaredFor a technically minded newbie to bzr, I would also appreciate a program which would give me a nice view of a shared repo, all branches using it, orphaned heads etc., and it could be extended to show possible actions like commit, branch etc.13:29
pysquaredlifeless: thanks. checking out fast-[import|export]13:29
a_c_mbranches rock !13:33
lifelesspysquared: qbzr|bzr-gtk|tbzr(windows)13:33
=== tro|| is now known as tro
pysquaredI'm on Ubuntu 8.04, so tbzr (TortoiseBZR?) is out.  Just tried qbzr, feels a bit clunky though, you have to wrestle with it to get information out.13:48
pysquaredI have been using bzr-gtk (olive-gtk yes?) for a while, and it's better than qbzr IMVHO so far.13:50
pysquaredThanks for the fast-import link, looks like a useful example of using bzrlib to disect a repo.13:55
=== bac_breakfast is now known as bac
lifelessgenerally speaking, I just use bzrlib to work with repo's :)14:00
=== dereine is now known as dereine[afk]
lamontcan I safely remove things in .bzr/repository/obsolete_packs (as the name would tend to imply)??14:31
=== bac is now known as bac_standup
james_wlamont: removing the directory is not a good idea, but the contents of the directory will be safe to delete if your system didn't die before things were synced to disk14:39
vilasiretart: got your mail, I can confirm that bug #225020 is *not* fixed in bzr-1.6 nor bzr-1.6.1 :-/14:39
ubottuLaunchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Fix released] https://launchpad.net/bugs/22502014:39
=== bac_standup is now known as bac
vilajam: when you'll come online, are you aware of bug #269770 ? 1.7 may still find its way into intrepid... (me? trying to push a time-based release trough a Freeze exception ? me ?)14:50
ubottuLaunchpad bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress] https://launchpad.net/bugs/26977014:50
lamontjames_w: thansk14:52
pysquaredWould a good method of cleaning out orphan revisions, i.e. garbage collecting (after deleting branch directories) be this: create a new shared repo, and branch every branch from old to new?15:00
james_wpysquared: yeah, that works15:00
james_wpysquared: it's obviously just a bit of a pain to do manually15:01
Takvila meant: lifeless: by the way, did pycurl get re-installed on pqm (you said you asked for it to be removed in the bug comments) ?15:08
vilaTak:  ?15:09
Takhell, sorry15:09
Takscript + scrollback = eek!15:10
=== Verterok is now known as Verterok|out
jamvila: I'll be packaging 1.7 "now-ish" I don't know whether that means it will get merged or not. Certainly I would hope they do 1.6.115:24
vilaThey mentioned 1.7, that's why I mentioned it to you, no pressure, at all, I swear :)15:25
ubottuUbuntu bug 269770 in bzr "bzr - New upstream versions released" [Undecided,In progress]15:27
Leonidaswhy do I need to --force for a multi-branch merge? is it considered a bad idea?16:04
james_wLeonidas: well, the first merge will mean that there are files modified in the working tree, and merging in that state can be a headache, I don't know if there is more to it than that16:06
Leonidasjames_w: ok, so it is just a human issue, not some technical problem. Thanks.16:07
fdvbzr-svn seems to have replaced an svn revision16:09
fdvis this normal?16:09
fdvnever done it before, but I haven't done this with the latest and greatest bzr-svn before16:10
jelmerfdv, see the FAQ16:10
fdvthat was.. unexpected16:11
fdvjelmer: I had a bound branch, and the operation was a commit16:12
fdvunsure how to interpret the faq on that point16:12
jelmerfdv, This happened after "bzr up" created pending merges I suspect?16:13
fdvjelmer: indeed'16:13
=== sdboyer|zzz is now known as sdboyer
jamguilhembi: ping, I'd like to chat with you sometime about the 'bzr log file' changes16:17
jamjust to get a feel of someone outside the bzr project itself16:17
guilhembijam: hi! good idea. We can IRC now.16:19
jamIs this channel fairly quiet?16:20
jamI haven't been watching16:20
guilhembiit is16:21
=== dereine[afk] is now known as dereine
jamguilhembi: so here is my standard example for the 'bzr log file' situation: http://paste.ubuntu.com/49712/16:24
jamYou have 3 branches, the one on the left (ABEG) is the mainline16:25
jamguilhembi: do you understand the graph, in general?16:25
Verterok|outsorry :p16:27
=== Verterok|out is now known as Verterok
guilhembijam: yes; to be sure: the only changed of 'foo' is C, right?16:29
jamguilhembi: right, that is the only *direct* change to the file.16:30
jamwell, and "A" for introducing it16:30
jamhowever, if you were to do "bzr diff" or E, or F, you would also see it "changing" C16:30
jambecause of the merge16:30
guilhembijam: right, makes sense; E changed 'foo' compared to ancestor B.16:32
guilhembidue to merge.16:32
jamand same for F16:32
jamso, there are 3 possible results from "bzr log foo"16:33
jamA C16:33
jamA C E F16:33
jamA C E16:33
jamMy 'file-log' plugin does the first16:33
jamonly reporting *direct* changes to the file16:33
guilhembijam: this is fine. But,16:34
jamsorry, I'm having side conversations so this is taking a while.16:35
guilhembiwhat if when the merge was done in E (pulling C into B), a conflict happened in 'foo',16:35
guilhembithen I'd like "bzr log" to how A C E.16:35
jamguilhembi: if a conflict happens then there is a new node16:35
jambecause B had to change the file16:35
jamAnd E is then resolving the changes between B and C16:35
guilhembijam: so would I see A B C E?16:35
jam*in fact*16:35
jamIf there are *no conflicts* you'll still see "ABCE" because E is merging the texts together to create a new text that has not been seen before.16:36
guilhembijam: this is fine too16:36
jamguilhembi: the existing "bzr log file" code shows "ACEF"16:36
jammy change would start to show "ACE"16:37
jam(though I have a change which solves the bulk of the problem, and still gives ACEF)16:37
jamSo back to the original example...16:37
jamthe reason to show "E" is because it is nice to know when that change was "landed"16:37
jamrather than just when it was created.16:37
jamdo you agree?16:38
guilhembiyes and no16:39
guilhembiit's nice, but it multiplies the output, creating some sort of noise;16:40
guilhembiin MySQL, we merge all the time, so we'd rather see what revision introduced a change for the first time,16:40
guilhembiand not the multiple merge revisions which propagated it all around,16:40
jamguilhembi: so, the idea with the *new* code, is to only see the changes as it propagates to *your branch mainline*16:41
jamso the changes as it propagates to *this* branch, rather than showing "F" which is propagating to some other branch.16:41
guilhembifrom MySQL 5.0-team to 5.0-main to 5.1-team to 5.1-main to 6.0-team to 6.0-main, that's a lot of noise merge revisions; I call them noise only if there were no conflicts.16:41
=== jkakar_ is now known as jkakar
jamguilhembi: knowing those branches, I have some guesses that you might see it anyway because of non-conflict resolutions...16:41
=== ja1 is now known as jam
jamguilhembi: sorry, network hiccup, did you respond to "knowing those branches ..." ?16:44
guilhembinot yet16:45
guilhembijam: what is a "non-conflict resolution" ?16:45
jamguilhembi: B & C both modified 'foo', just in a way that doesn't conflict16:45
jam(B changes the first line, C changes the last)16:45
guilhembijam: ah, then it's fine to see B and C and E.16:48
guilhembijam: let's put it this way:16:49
=== bac is now known as bac_lunch
guilhembiI believe we should see all revisions which introduced a change in the first place,16:49
guilhembiplus, if you wish, merges where the two ancestors changed 'foo'.16:50
guilhembiIt's "if you wish", because I don't see a need to see such merges if there were no conflicts.16:50
guilhembias then I consider they didn't really change something.16:50
jamwell, they did get a new text. Also, I don't think there is a way to figure out whether it was a conflicting or non-conflicting without explicitly recording that at commit time.16:51
jamAs it can even depend on the merge algorithm used16:52
jam(as you've seen for bzr merge --weave/lca/merge3)16:52
jamso, in the short-short term, I'll point you towards my "bzr file-log" plugin, which gives you the minimal revisions you requested, and I'll probably land the change to "bzr log file" which is a step along the way.16:53
guilhembijam: mmmmmm16:55
guilhembiI'd rather not tell people to switch to your plugin, it is a bit hell to make 100+ devs use a plugin,16:56
jamWith newest code in both, "bzr file-log sql/..yacc.yy" was 4-5s, and "bzr log file" was about 10s16:56
guilhembithen abandon it when the changes are in bzr.dev16:56
guilhembihow about "land the change to "bzr log file" which is a step along the way"16:56
guilhembi- which is easier to sell to my colleagues -16:56
guilhembido you see a problem with getting your change into bzr.dev?16:57
jamjust waiting on final approval, things seem positive16:57
guilhembijam: I believe that the person who reported that problem can accept waiting for a couple of weeks (but not a couple of months) and then just upgrade its bzr.16:57
guilhembijam: while I have you here, when finally will your lca_merge_multi reach bzr.dev ?16:58
jamI don't know what is happening here....17:00
jambad network17:00
jam10:58:02) guilhembi: jam: while I have you here, when finally will your lca_merge_multi reach bzr.dev ?17:00
jam(10:59:05) jam: a bit unclear17:00
jam(10:59:10) jam: it took a month to get anyone to review it17:00
jam(10:59:18) jam: and then they asked for some large changes17:00
guilhembijam: :((17:01
jamso I need to find some time to both discuss with him what has to happen17:01
jamand have time to make the changes.17:01
jam(we're also in the process of discussing our review process, as it seems to not be functioning as smoothly as it should)17:01
guilhembijam: then that patch needs higher prio, "angry customer" thing.17:02
guilhembipoolie: hello! please see above.17:03
jamguilhembi: well, poolie is in deep-sleep right now, but he'll wake up in about 6 hours17:08
jamanyway, I'm off to reboot and release 1.7 final, I'll be back in a second.17:09
Leonidaswhat is the dirrefence between lock_read and lock_write?17:42
jamLeonidas: "lock_read" indicates that you are going to not be modifying the object you are locking, "lock_write" says the opposite17:42
Leonidasjam: so other processes could access a lock_read locked tree also via lock_read, but that wouldn't be possible with a lock_write?17:44
jamLeonidas: ATM, I'm pretty sure you just can't take two lock_write at the same time. lock_write doesn't block a lock_read17:44
jamas our data model stays consistent for old data when adding new data.17:44
fdvjelmer: I now tried setting append-revisions-only on the repository I bind to an svn repo (where I update from and commit to), but this doesn't seem to make any difference17:45
fdvjelmer: is that expected?17:45
jelmerfdv, append-revisions-only has to be set on the master branch (the svn repository), e.g. in ~/.bazaar/subversion.conf17:45
Leonidasjam: ok. I'm asking because I need read access to a repo and locking&unlocking on every operation is quite slow17:46
fdvjelmer: is it possible to set it in svn itself?17:47
fdvso that no "clients" can do this17:47
jelmerfdv, not atm, no17:48
fdvwe just had a very hectic couple of hours here, it'd be nice to be able to aviod that :p17:48
Leonidasjam: anyway, this is cool; thanks.17:48
jelmerfdv: feel free to file a wishlist item about it17:48
fdvis this new behaviour or has it been like this for some time?17:48
jelmerfdv, it's always done this17:48
fdvok, guess I've just been lucky in the past17:49
fdvjelmer: will add it to the wishlist. thanks for your help17:49
Leonidasjam: but, uhm, of what use is the lock_read?17:49
=== bac_lunch is now known as bac
fdvjelmer: btw, you said 'e.g. ~/.bazaar/subversion.conf', does this mean that there are other options? Can I set it 'globally' for a user (across repos), for instance?17:54
jelmerfdv, the setting is append_revisions_only btw, not append-revisions-only - I'll update the FAQ17:56
fdvjelmer: I tested and found out :)17:56
jelmerfdv, I think you should be able to set it in ~/.bazaar/bazaar.conf17:59
fdvok, thanks, I'll test17:59
fdvjelmer: you don't think this could be considered a bug? I mean, in centralised thinking I think it's a bit counter-intuitive that the checkout should act as "master"..18:01
jelmerfdv: What should be considered a bug exactly?18:02
fdvjelmer: that append-revisions-only isn't default (against svn)18:03
jelmerthe fact that the mainline can be altered rather than only be appended to ?18:03
jelmerfdv: In that case, it would have to be the default against bzr itself too (for consistency)18:04
fdvwell, maybe18:04
fdvon the other hand, when you're working against svn you might be in a slightly different mindset18:04
fdvjelmer: not least that this sort of "breaks" svn18:05
fdvyou get an inadvertent copy, which might very well not be what you want18:06
fdv(or replace, that is)18:06
jelmerfdv: true, but you may not want a changing mainline for native bzr master branches either18:07
fdvquite possibly, I'm not sure how bazaar handles this18:07
jelmerfdv: I'm not opposed to making append_revisions_only the default, but only across bzr, not just for a particular master branch format.18:07
fdvI see, I don't think I'm sufficiently proficient to be strongly opinionated on the matter18:08
jelmerfdv: I could add a info message that points at the FAQ, would that help?18:08
fdvjelmer: in my case, indeed, but I can only speak for myself18:09
fdvmaybe bzr could implement a prompt in these cases, unless specifically turned off18:10
fdvjelmer: fyi, bazaar.conf seemed to work as well18:13
jelmerfdv, ah, cool18:18
=== andreas__ is now known as ahasenack
Kinnisonjelmer: Are you responsible for ctrlproxy?18:35
jelmerKinnison, yes18:36
Kinnisonjelmer: why is 3.0.x such a regression? is it still WiP ?18:36
* Kinnison accidentally upgraded, spent an hour trying to make it work, gave up and force downgraded again18:36
jelmerKinnison, it works fine here - what do you consider a regression exactly?18:36
Kinnisonjelmer: I couldn't get it to start an SSL listener which would actually transact any data18:37
Kinnisonjelmer: Also, startlistener and then saveconfig => no listeners saved18:37
Kinnisonat that point, I gave up trying to make it work18:38
jelmerthe second one is a known issue18:38
Kinnisonjelmer: it's also a showstopper with no config documentation :-)18:38
jelmerthe first one I'm not sure - what version exactly?18:38
Kinnisonwhatever is in hardy18:38
KinnisonI think18:38
jelmerah, ok - that's a known issue as well then but that's resolved now18:38
Kinnisonmmm 3.0.5-118:39
jelmerI do plan to fix the documentation for the next release18:39
Kinnisonthere was nothing in the NEWS which hinted at SSl fixing for incoming connections18:39
jelmerI'll give you a ping when that's out.18:39
Kinnisonso I didn't try trunk18:39
* Kinnison shrugs, I've downgraded the package and put it on hold18:39
Kinnisonalso, it asks you to run a script which doesn't exist18:39
Kinnison(although that might be the packager's fault)18:40
jelmeryeah, that's a package bug18:40
Verterokwould make sense to implement __str__ in bzrlib.inventory.Inventory?, mainly to avoid this http://rafb.net/p/yY76bI24.html18:45
=== BasicPRO is now known as BasicOSX
=== Verterok is now known as Verterok|out
=== bac is now known as bac_bbiab
LeoNerdGuys.. I have an idea...19:31
LeoNerdI would loveyoulongtime if you provided me a way to hook into bzr's local file reading, and mangle a string that contains a file's content before bzr looked at it19:32
LeoNerdI'd then use it to squash  $cvs: .*$  into   $cvs$   meaning that bzr ignores changes to CVS's keyword expansions19:32
LeoNerdCurrently, I have a dual CVS/bzr working directory (don't ask :P) and every single time I "cvs ci" I have to "bzr ci" as well because CVS has rewritten them19:32
LeoNerdI know it'd slow things down a bit, but hey.. bzr is about 5 times quicker on my workdir than CVS ever is anyway, so it has plenty of leeway ;)19:34
=== bac_bbiab is now known as bac
jamLeonidas: sorry, lunch came inbetween19:50
jamanyway, 1 caveat, "WT.lock_read()" does take out an OS shared lock on a file19:51
jamand *will* block a lock_write on a working tree19:51
jam(we are considering ways to avoid this)19:51
jamand 219:51
jamit gives a lifetime for cache objects19:51
LeoNerdHow confusing... someone else with the same initial 4 letters as me :P19:51
jamLeoNerd: there *is* a pre-commit hook19:51
jambut that would require modifying the file-on-disk19:52
jamyou could also monkey patch WT.get_file*19:52
LeoNerdWhat I want is a filter between the filesystem read() calls, and what bzr internally uses19:52
jamLeoNerd: well, igc was working on just that sort of thing recently19:52
jamit got a little side tracked when he got sick19:52
jamLeoNerd: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4880CF60.2080805%40canonical.com%3E19:53
jamIs part of his work on that19:53
jamalong with a plugin on his end19:53
jamLeonidas: back to the "cache lifetime". The idea is that we'll have a snapshot of how a branch/repository looks and cache certain things in memory. By using lock_read()/unlock() we define the boundary of when that cache is valid.19:53
jamLeonidas: so that if you have a long running process, it doesn't think a branch is always at the same point, nor does it have to re-query all information repeatedly.19:54
jamfor bzr, the cache lifetime is generally just the process lifetime19:54
a_c_mis anyone actually using PQM ?20:18
a_c_mfinding it really hard to find any useful doc's or tutorials on how to set it up20:18
=== mw is now known as mw|food
=== Verterok|out is now known as Verterok
abentleyjam: You wanted to talk with me about LCA merge stuffs.  Do you still want to do that?20:36
a_c_mPatch Queue Manager? is it abandoned?20:58
a_c_mno activity in the last month20:59
a_c_mno download (that i could see)20:59
=== mw|food is now known as mw
james_wa_c_m: bzr itself uses it21:01
james_wand there is work being done on it21:01
seb_kuzminskyhalp!  i'm using bzr to work with an svn repo, and it's backtracing on me21:02
seb_kuzminskyi'm on intrepid, fully apt-get updated, with bzr-svn from the 0.4 branch, also recently updated21:03
jelmerseb_kuzminsky, please pastebin the traceback somewhere21:03
seb_kuzminskyhere's the backtrace: http://pastebin.ca/120965321:03
jelmerseb_kuzminsky, please file a bug21:04
seb_kuzminskywill do21:04
a_c_mjames_w: right... but i would love to see if i can set it up for my purposes, seems like a really cool plugin/addon/thing even for trival stuff like checking committed code matches our coding standards... or would there be a better way to do that? perhaps with pre-commit hooks?21:05
james_wa_c_m: either would work I think, it's about where you want to check it really.21:05
a_c_mjames_w: as i cant find any released code for the PQM, i guess pre-commit hooks is where its at ;)21:06
seb_kuzminskyjelmer: thanks: https://bugs.launchpad.net/bzr-svn/+bug/27371621:08
ubottuUbuntu bug 273716 in bzr-svn "backtrace in a bzr branch of an svn repo" [Undecided,New]21:08
james_wa_c_m: you can grab it from bzr21:08
jelmerseb_kuzminsky, thanks21:08
seb_kuzminskyany suggestions on how i can work around this for now?  i'd really like to keep working with that sandbox!21:09
=== bac is now known as bac_afk
seb_kuzminskyjelmer: hm i think that bug is probably my fault21:20
strkhow do I drop a working tree from a branch once I forgot the --no-tree ?21:21
LarstiQstrk: `bzr remove-tree`21:22
seb_kuzminskyjelmer: it's my fault, sorry for wasting your time21:28
jelmerseb_kuzminsky, what's the problem exactly?21:28
seb_kuzminskyi'd been playing with a newer version of bzr (from lp:bzr)21:29
seb_kuzminskyi made a shared repo of format RepositoryFormatKnitPack5RichRoot (bzr 1.6.1)21:29
seb_kuzminskybut intrepid only has 1.6, i think that's what made it confused21:29
seb_kuzminskyi upgraded to lp:bzr-1.6 and now it's working21:30
=== thumper_laptop is now known as thumper
a_c_mjames_w: do you know of any good tutorials for doing hook based things?22:26
=== bpierre_ is now known as bpierre
=== beuno_ is now known as beuno
beunostatik, hi. Are you around?22:51
beunoa few of us have been using the bzr nightly PPA22:52
beunoand have a very very very very special request  :)22:52
beuno(add bzrtools to it as well)22:52
BasicOSXhow do I remove just the file ID? I have a fileName and filename and on osx native fs those are the same file22:53
james_wa_c_m: the documentation is a start, I don't know of any tutorials22:54
lifelessa_c_m: looking at an existing plugin - e.g. email - that uses hooks is a good way to see what they do23:12
lifelessBasicOSX: uhm23:12
BasicOSXI've had this "problem" before on osx, bzr remove "File" worksi23:13
lifelessBasicOSX: python -c "import bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open('path'); t.remove('exact_relpath')"23:14
=== jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.7 now available! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
=== fta_ is now known as fta

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!