#bzr 2008-05-05
<mwhudson> is there a ppa with a newer pqm in it somewhere?
<mwhudson_> hey guys
<mwhudson_> unlock really shouldn't raise an exception
<lifeless> details details details
<mwhudson_> also sftp sucks
<lifeless> mwhudson_: details please
<lifeless> mwhudson_: unlock should raise some exceptions
<mwhudson_> lifeless: the problem was that the unlock in a finally block was raising and obscuring the reason we ended up in the finally
<lifeless> mwhudson_: yes, that combination is annoying; OTOH its probably raising becuse the network is gone and an attempt to unlock failed
<spiv> Hmm, ISTR Martin was working on fixing that, based on a hack I did.
<mwhudson_> lifeless: well actually it's because of much more complicating things than that :)
<mwhudson_> i'll probably be complaining in here when we've worked out what the details are
<spiv> https://bugs.edge.launchpad.net/bzr/+bug/125784 is a bug report about that; I have an untested fix in the associated branch.
<ubottu> Launchpad bug 125784 in bzr "TooManyConcurrentRequests when using smart server over ssh" [High,Confirmed]
<mwhudson_> the problem appears to be that unix hates me
<lifeless> what did you do to unix?
<mwhudson__> lifeless: fail to understand symlinks
<lifeless> mwhudson: oops
<mwhudson> aka the famous 'not running the code you thought you were'
<Mez> Is there a way with bzr so that I can make it update revision numbers within the file?
<Mez> like svn's keywords things
<lifeless> its being developed at the moment
<Vadi> My bzr is hosted on launchpad, and for some reason after I've commited & pushed a new revision, and the launchpad page updated properly, when people do "bzr update" it says they're OK while they're at an older revision. But if they checkout from scratch, they get the latest one fine. What can be wrong?
<RAOF> Vadi: 'bzr update' doesn't do what you think it does.
<Vadi> Oops. But I read the help file and thought I was getting it right. What's the proper way to update then?
<RAOF> 'pull' (or possibly merge) is the complement of 'push'.
<RAOF> bzr update makes sure that the working tree matches the repository.  Since their working trees already match their (local) repository, it doesn't do anything.
<Vadi> Ohh
<Vadi> heh, I see. Thank you
<RAOF> _Unless_ they're using 'checkout' rather than 'branch'.
<Vadi> It's whatever launchpad says... moment
<RAOF> But checkout gives SVN-like behaviour, and is not what most people do with bzr branches.
<Vadi> ï»¿RAOF: Got it, thank you!
<lifeless> hmm, someone broke test reporting.
<lifeless> spiv: thanks
<lifeless> spiv: its on its way
<Vadi> Is there any way to download a file from a bzr branch without bzr? (like on a web server?)
<lifeless> if the web server is running loggerhead or bzr-webserve
<lifeless> then yes
<Vadi> It is running loggerhead.
<Vadi> Is it possible to get the file at it's latest revision though? The only links I could find on loggerhead are tied to a specific revision.
<spiv> You can use HEAD in the URL, IIRC.
<Vadi> Could you please give an example? Newbie here.
<lifeless> for instance: http://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/annotate/head:/HOWTO
<spiv> Or http://bazaar.launchpad.net/~bzr/bzr/trunk/download/head:/README-20050309040720-8f368abf9f346b9d/README
<lifeless> spiv: can we not avoid the file-id like I did
<lifeless> ?
<Vadi> Is the README-2005 and whatnot part of the filename?
<lifeless> no its a nasty url generation
<lifeless> coming from the internal database
<Vadi> hrm. So I turned http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/vadi%40ubuntu-laptop-20080505020006-hkitvfgtqoqiw2ry/imap-20080225191626-smuh5chmryg7edgm-1/IMap into http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/head:/IMap
<Vadi> But that gives a 500 error
<Vadi> And the annonate just takes forever, launchpad doesn't respond
<spiv> lifeless: for annotate URLs, yeah, but apparently not for download URLs.
<spiv> mwhudson: ^
 * mwhudson is not surprised
<mwhudson> but also not really paying attention
<spiv> Vadi: so you'd need http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/head:/imap-20080225191626-smuh5chmryg7edgm-1/IMap I think.
<spiv> Vadi: oh, and you can use "bzr cat http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/IMap" as well I think.
<Vad1> Sorry, I got disconnected. Are there logs available for this channel somewhere?
<poolie> Vad1: um, yes, i wonder where?
<poolie> http://irclogs.ubuntu.com/
<poolie> Vad1: ^^
<spiv> Vadi: so you'd need http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/download/head:/imap-20080225191626-smuh5chmryg7edgm-1/IMap I think.
<spiv> Vadi: oh, and you can use "bzr cat http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/IMap" as well I think.
<Vad1> Excellent, thank you
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr-1.4 out, May 2 | http://irclogs.ubuntu.com/
<bignose_> What does 'bzr cdiff' emulate?
<bignose_> I had the impression that it was implementing behaviour from some external diff tool
<spiv> bignose: colordiff, IIRC
<bignose> spiv: that's the one, thank you
<berto-> i'm trying to use the fast-import plugin to import a git repository using git-fast-export v1.5.4 and v1.5.5.1  I get a MemoryError at File "/Users/berto/.bazaar/plugins/fastimport/parser.py", line 225, in read_bytes.  Any ideas?
<jamesh> berto-: looks like https://bugs.edge.launchpad.net/bzr-fastimport/+bug/194572
<ubottu> Launchpad bug 194572 in bzr-fastimport "MemoryError while importing from git." [High,New]
<jamesh> berto-: the method in the last comment might help you
<lifeless> tchau, I'm done for the day
<berto-> jamesh: i tried dumping the info to a .cfg file, but that didn't work.  but, i read it worked on a linux box and just did it that way.
<berto-> jamesh: thanks!  i now have my git repo migrated.  :)
<berto-> my repo had two branches which were empty and I ran bzr update on them, now they have the files.  is there a way to empty them again?
<jamesh> berto-: "bzr remove-tree" will remove the working tree files, leaving the branch data behind
<berto-> jamesh: wonderful!  thanks.
<berto-> i'm liking this already, bzr makes branches directories and i can see more than one at a time!  :-D
<vila> lifeless: regarding pqm hanging, I've filled bug #226769 and sent a mail to the bzr ML, feedback welcome
<ubottu> Launchpad bug 226769 in bzr "strace test side-effect hangs selftest " [Medium,Confirmed] https://launchpad.net/bugs/226769
<berto-> i installed paramiko and python-crypto, but keep getting, "ERROR: Not a branch"
<berto-> any ideas?
<berto-> uhh, sorry, can't explain my problem tonight.  I'm using an sftp:// url
<berto-> ah, figured it out.  I had to fully path my repository rather than relative to my home dir.
<bob2> how sure are you that it is a branch?  ie does 'echo "ls /path/to/branch/.bzr" | sftp hostname' show it contains a 'branch' dir?
<spiv> berto-: you can use "sftp://host/~/path" for an sftp URL relative to your home dir.
<berto-> spiv: cool, i'll remember that.
<berto-> my sftp:// connection keeps on failing with a "server connection dropped".  is there anything I need to configure for sftp to work properly?
<berto-> odd.  i had to fully define user@<full hostname> instead of using the name setup in my .ssh/config file.
<Peng> (Why doesn't the ~ thing work for bzr+ssh? Would it be difficult to add?)
<berto-> what's the best way to import an svn repository?
<poolie> Peng: not sure why technically, it should be straightforward
<lifeless> Peng: just needs someone to do it
<Peng> After the path issues with bzr+http, I was afraid it would be really complicated somehow.
<Peng> Not that this means I'm going to volunteer..
<Peng> berto-: Probably bzr-svn.
<berto-> peng: i'm getting a maximum recursion error.  :(
<Peng> berto-: Latest version of bzr-svn? 0.4.9, I think.
<berto-> Peng: yep, just downloaded it.
<berto-> actually, it's 0.4.10exp0
<Peng> Heh, ok.
<Peng> That sounds like you're using a bzr branch of it directly. I didn't know that was in working order.
<berto-> hmm ..
<berto-> looks like svn2bzr is working.
 * mtaylor is away: I'm not here right now
<Peng> berto-: But bzr-svn is much cooler. And more powerful.
<berto-> peng: i'm sure it is, but it's broken [for me at least].  so it's not an option.
<berto-> peng: as long as i get the data migrated, i don't need two-way communication.
<Peng> berto-: Well, I still think you should see if you can get help from I-don't-want-to-highlight-him-again. Does this absolutely have to be finished right now?
<Peng> bzr-fastimport also looks nifty.
<Peng> Anyway, whatever.
<berto-> peng: yep, tried that one too, but svn2bzr actually worked better.
<berto-> Peng: i really appreciate you helping.
<berto-> Peng: and, no, it doesn't have to be finished right now.  i'm just researching.
<Peng> berto-: Ok.
<Peng> berto-: You should file a bug for the error you got with bzr-svn. https://bugs.launchpad.net/bzr-svn
<berto-> yeah, i will.  thanks.
<berto-> nite, all.
<berto-> peng: thanks again.
<Peng> What exactly is he thanking me for?
<poolie> for pointing him to the bug tracker i guess
<emgent> morning
<poolie> hello
<jelmer> dato, ping
<dato> haha, pong
<dato> ("haha", because I just arrived home after being from irc many many hours :P)
<jelmer> wow, that was quick :-)
<dato> being away I meant
<jelmer> heh
 * jelmer is psychic
<jelmer> dato, any chance you can sponsor an upload of bzr-gtk at some point?
<dato> sure
<dato> I can add D-U-A as well
<jelmer> dato, thanks, that'd be useful
 * dato thought it was already there
<jelmer> I added it yesterday in the bzr branch
<dato> ok
<dato> so, uhm, is the branch ready for an upload?
<jelmer> but nothing has been uploaded with it yet
<jelmer> yep
<dato> ok, noted in TODO
<dato> I'll need to catch up with other stuff first, though
<jelmer> no hurry :-) Thansk
<dato> jelmer: btw in debian/control you have to write "XS-DM-Upload-Allowed: yes", not just "DM-Upload-Allowed: yes"
<jelmer> dato: afaik DM-Upload-Allowed is in the properly defined control fields list now
<dato> ah
<dato> ok
<jelmer> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453400)
<ubottu> Debian bug 453400 in dpkg-dev "dpkg-source: please accept DM-Upload-Allowed field in control (and" [Normal,Closed]
<jelmer> ooh, ubottu supports debian bugs as well now?
<dato> for a long long time I think
<poolie> hello dato, jelmer
<jelmer> hey poolie
<poolie> night
<ChristopheT> Is there somewhere some documentation about the various formats as well as rationale for them?
<jam> good morning
<cr3> if I bzr removed a file and I can't remember the exact path and I don't remember the log message I used, how can I track which revision I need to recover?
<andrea-bs> cr3: do you know the revision number?
<andrea-bs> argh, no :D
<cr3> andrea-bs: heh, of course not :)
<andrea-bs> cr3: what do you know of this file?
<cr3> andrea-bs: the file name, and I can confirm the name is under the .bzr directory
 * fullermd shrugs
<fullermd> bzr log -v | less    [search for filename]
<cr3> fullermd: that worked! it just so happened I did not the path name of the file but bzr log only returned an error message: Path does not have any revision history:...
<cr3> fullermd: just in case I typoed, I pasted the path from bzr log -v and I still get the same error message
<cr3> is bzr log supposed to work with files which have been deleted?
<fullermd> Well, supposed to or not, it doesn't.  It uses the path to look up the file-id from the current tree, so on deleted files...
<fullermd> You may be able to `revert -r<revbeforeremoved> $FILE` and then `log $FILE`, I'm not sure.  You can do a lightweight checkout of the rev before it was removed, then log from that checkout.
<fullermd> See https://bugs.launchpad.net/bzr/+bug/175520  (which has nothing other than a "hey, this doesn't work", sadly, but it's filed anyway)
<ubottu> Launchpad bug 175520 in bzr "log can't see historic filenames" [Undecided,New]
<fullermd> I'm of the opinion that you should be able to pass a file-id into `log` so you can unambiguously refer to a specific file, regardless of renames or deletions, from any point.
<dato> jelmer: I uploaded bzrtools, also with d-u-a
<cr3> hm, I can appreciate the problem where a file may have been removed and then created again, at which point log perhaps should or should not encompass the previous file
<jelmer> dato, ah, awesome.
<jelmer> dato, I'm working on bzr-svn atm, I guess that just leaves bzr-builddeb outdated
<dato> jelmer: hm
<fullermd> cr3: Well, there are 2 distinct cases.  One is where a file exists, is removed, and another file with the same name (but a different file) is added.  The other is when a file exists, is removed, and is resurrected (e.g. by 'revert'), so it's the same file, it just didn't exist in some revs in the middle.
<dato> jelmer: I guess I forgot to add you as a bzrtools uploader
 * jelmer wonders where james_w went
<fullermd> cr3: 's where the file-id is useful to disambiguate.
<hsn_> its recommended to use bzr pack in production? does it any noticeable good
<fullermd> Hm.
<fullermd> % time HEAD http://bazaar-vcs.org/
<fullermd> [...]
<fullermd> 0.212u 0.141s 2:59.30 0.1%      1+583k 11+0io 0pf+0w
<fullermd> That's usually a bad sign...
<vila> phanatic: ping
<phanatic> vila: pong
<vila> phanatic: what is the status of the po/ directory in gtk ?
<vila> I had a look at genpot.sh but it seems rather out of date
<phanatic> vila: it can be translated via the olive product in rosetta.
<phanatic> yes, it is outdated :)
<phanatic> we should care more about translations
<vila> I've update it to include all .py files in all relevant directories
<vila> s/update/updated it/
<phanatic> oh, thank you :)
<vila> I was wondering if po/olive-gtk.pot was still the base for the translations...
<phanatic> it is the version that was last uploaded to rosetta
<vila> I don't know how this works, but as long as I left the msgid and msgstr untouched I can modify the rest ? The order ? Add new ones ?
<vila> I,m searching a way to check that renaming '_' to '_i18n' doesn't blow everything
<vila> nevermind, I found a way
<phanatic> vila: the pot file should be generated automatically
<vila> yes, but it appears that xgettext updates it a bit too smartly to allow me to use it as a check :)
<vila> i.e. if branch.py uses _("_Branch") and I change it to _i18n("_Branch") I can't know if xgettext updated it or not :)
<vila> I'll generate different pot files for that before and after my patch to check
<vila> phanatic: do you know the irc nick of daniel ?
<fullermd> vila: You mean Odd_Bloke?
<phanatic> vila: schierbeck?
<vila> lol, Odd_Bloke *is* daniel schierbeck ?
<vila> Odd_Bloke: ping
<Odd_Bloke> I'm Daniel Watkins.
<vila> haaa, hi Daniel :)
<Odd_Bloke> vila: o/
<vila> Sorry for the confusion, sometimes on IRC you receive bad advices :)
<vila> well, anyway, I was wondering why the other daniel was using '# -*- coding: encoding -*-' constructs which are obsolete in emacs.... and I realized  that it's still the recommanded way to instruct python about the source file encoding...
<vila> The nice thing about standards.... is when two communities use the same forgetting to inform the other one about the changes :)
<fullermd> Ah, well.  Obviously there are too many Daniels around   :p
<beuno> anyone know what this might be?  bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit.KnitGraphIndex object at 0x861860c> corrupt: attempt to add line-delta in non-delta knit
<vila> beuno: search the nailing list, I'm pretty sure there is a patch for that
<vila> s/nail/mail/ :-P
<beuno> vila, aaah, cool, thanks  (maybe the bug should be reported?)
<fullermd> I'm pretty sure it's fixed in .dev.
 * beuno tries
<beuno> vila, fullermd, it's fixed in .dev, thanks  :)
<vila> yv
<beuno> it's odd that got into 1.4
<jelmer> hmm. fetching from a remote subversion server to rich-root-pack is faster than from local pack-0.92-subtree to rich-root-pack !?
<Peng> * is faster than fetching from pack-0.92-subtree to rich-root-pack.
<Peng> Converting to git and back, recommitting each revision, ...
<sidnei> anyone can help me debug why bzr commit to a svn master branch (using bzr-svn plugin) seems to hang only with a certain repository?
<jelmer> sidnei: What version are you using?
<sidnei> of the plugin or bzr?
<jelmer> both
<sidnei> Bazaar (bzr) 1.3.1
<sidnei>   Python interpreter: C:\Program Files\Bazaar\python25.dll 2.5.2.final.0
<sidnei>   Python standard library: C:\Program Files\Bazaar\lib\library.zip
<sidnei>   bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
<sidnei>   Bazaar configuration: C:\Documents and Settings\Sidnei\Application Data\bazaar\2.0
<sidnei>   Bazaar log file: \\.PSF\.Home\Documents\.bzr.log
<sidnei> svn plugin is 0.4.9
<jelmer> can you try running with -Dtransport ?
<jelmer> It should tell you what it's doing in ~/.bzr.log
<sidnei> ok
<sidnei> jelmer:  i see lots of 'svn ls -r X <path>'
<sidnei> jelmer: where X is an incrementing number and <path> seems to be each project in that repository + tags/branches/trunk
<jelmer> sidnei, yeah, that's probably correct
<sidnei> jelmer: apparently its going throw revisions, the problem is that this is a large repo with 300 projects 60k+ revisions
<sidnei> s/throw/through
<sidnei> jelmer: why is it doing that? to discover the repo layout?
<jelmer> sidnei: it's going to do this once and will cache the results
<jelmer> 0.4.10 will be better in this regard
<sidnei> oh, ok.
<sidnei> at this speed its going to take about a day though :)
<sidnei> jelmer: there's no way to make it skip that?
<jelmer> sidnei: not in 0.4.9, no
<sidnei> jelmer: ok, i guess i will just let it finish then
<_paneb> a repository is where i can store many branches right?
<MattCampbell> Yes, if it's a shared repository created with "bzr init-repository".
<_paneb> i am looking at "Choosing a shared repository layout" but i am confused about how to actually create those layouts. it all starts by doing bzr init-repo MyRepo?
<_paneb> section 5.2 (Publishing a branch) is how to do it, right?
<MattCampbell> I wonder how easily one could port bzr to IronPython.  I was thinking that might be useful for the Visual Studio integration package, which is currently written in C#.
<Peng> MattCampbell: People have looked into this. Mainly, isn't IronPython startup horribly slow? Also, it's missing several modules from the stdlib that bzr uses.
<sidnei> look at fepy (ironpython + stdlib)
<sidnei> jelmer: seems like it finished with the svn ls thingie, 89 minutes :)
<sidnei> jelmer: now the process is at 90% and there's lots of io going on, i guess it's writing the cache?
<sidnei> (90% cpu that is)
<MattCampbell> Peng: One would need to measure the startup time of IronPython (or FePy) in an already running application that uses in .NET.  Also, consider that in a long-running app with a plug-in, such as Visual Studio, the startup overhead would only be incurred once per session, not once per action as with the command line.
<MattCampbell> Anyway, it was just a tought; I thought it would be useful to be able to write the Visual Studio integration in Python, with less glue code than the current C# implementation.
<wam> I'm using bzr all over and want to give my customers access to their bzr repository via www. Is loggerhead the best choice? At least I find it beautiful ;)
<jam> wam: if you just want them to have access, you only need plain Apache
<wam> jam: I want them to make diffs and see logs
<jam> if you want them to be able to browse the repository with a web browser, then yes, loggerhead is probably the best choice
<jam> It is the most actively maintained, IIRC
<wam> jam: is there active development? I see the last log is from 2007...
<jam> wam: I believe so, I'm not sure where the latest changes are
<wam> jam: ok, thanks
<jam> wam: according to: https://edge.launchpad.net/loggerhead/trunk
<jam> there was a release of 1.2.1 on 2008-03-06
<wam> jam: wow - I didn't know that url
<jam> And https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk says that there were 3 changes in the last month
<jam> wam: what url were you using?
<wam> jam: http://www.lag.net/loggerhead/
<jam> just to make sure we update a pointer
<jam> wam: right, robey has given over development to others
<wam> jam: i see
<jam> wam: where did you get the link to lag.net
<jam> wam:  I believe the latest version is running at: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes
<wam> jam: search "web" on http://bazaar-vcs.org/ and the 4th hit is http://bazaar-vcs.org/WebInterface?highlight=%28web%29
<wam> jam: alright, thanks. I'll try that
<lifeless> moin jam
<jam> lifeless: morning
<_paneb> how would i create the shared repository used for distributed development? like so? 1- on a server: bzr init-repo X; bzr init foo, and 2- on a workstation: bzr branch stfp://server-address/foo?
<Peng> _paneb: The sftp path is relative to the root of the server, but otherwise, yeah.
<Peng> _paneb: You'd also probably want/need to specify a user.
<_paneb> right right, i was just wondering about the commands
<_paneb> so when creating the main repository, there is not difference with creating the main repo. for centralized development?
<_paneb> it is just the way you work with the main repo which changes?
<Peng> _paneb: Yeah.
<_paneb> ok
<MattCampbell> Given that bzr-cvsps-import claims to only support local CVS repositories so far, is it possible to import the CVS repository of a project for which you're not an administrator?  I'm wondering specifically about SourceForge.net projects that never switched to svn.
<lifeless> MattCampbell: sf publish tarballs of the cvs repositories anonymously
<lifeless> jam: ping
<jam> lifeless: pong
<lifeless> jam: how do you feel about removing the C knit parser?
<jam> lifeless: Seems ok. As knits performance is sort of going down the tubes anyway, it probably won't help much soon.
<lifeless> (It doesn't feel like _load_data is relevant for packs, and for older code I weight maintenance clarity much more)
<jam> lifeless: well, ATM I feel like pack index performance is penalized by something other than the time to parse them
<jam> I don't know if when we fix it we will find we want something there as well
<poolie> hello jam
<jam> but certainly loading knit indexes isn't going to be a primary concern going forward
<jam> hi poolie
<poolie> hello lifeless
<poolie> lifeless: that would further increase my desire to give people a warning to upgrade
<lifeless> poolie: I thought we agreed on the list to do such a warning a couple weeks back :)
<poolie> someone should write it hey? :)
<lifeless> yup
<poolie> vila has a patch that disables some strace tests, is that ok with you in principle?
<lifeless> mmm
<lifeless> why?
<jam> lifeless: because it hangs the test suite when you have a thread lying around
<lifeless> jam: I remember we had issues with that; so why are we leaving a thread lying around?
<jam> lifeless: it is one of the bugs we have open
<jam> I think there is even a FIXME about it
<jam> if you look at vincent's recent posts he talks about it
<lifeless> I'd really rather not have disabled tests; if a separate bug is the core issue, can we not fix that?
<lifeless> can we check that there is only one thread in the process before the strace test, and fail the test in that case?
<MattCampbell> Is it even possible to count the threads in a process in Python?
<lifeless> MattCampbell: doesn't matter if it isn't possible
<lifeless> MattCampbell: we can at worst manually track them
<jam> I believe there is something in the threading package
<jam> lifeless: threading.activeCount()
<poolie> lifeless: the thing is that the strace functions are not even used at present
<lifeless> poolie: I use them from time to time
<lifeless> poolie: its like saying lsprof isn't even used. Its not used except when it is used.
<lifeless> Its really quite useful being able to strace a single function call
<MattCampbell> Given that bzr itself doesn't use the strace functions, and they're probably only intended as instrumentation for performance tuning anyway, I don't think it makes sense to run the strace tests by default.  But of course, I'm new here and just a bzr user, so what I say probably doesn't have much weight.
<lifeless> MattCampbell: untested code is broken code
<lifeless> MattCampbell: most code isn't run by most users most of the time, so by the same style of argument we shouldn't run tests for most of our code
<lifeless> vila: please don't merge it for a little bit
<lifeless> vila: I'm not going to veto, but I want time to suade people
<jam> lifeless: you should probably reply to the thread, since poolie has bb:tweak ed it
<lifeless> jam: I have replied
<jam> lifeless: just got it :)
<lifeless> anyhow, I think all tests should check for the activeCount at the start of the test, and assert its unchanged at the end
<lifeless> this will catch faulty tests and avoid the error condition breaking the strace test
<MattCampbell> Of course, this assumes that all threads in the process except the main thread are started via the threading module.
<jam> MattCampbell: sure, but I believe for the threads we care about, that is true
<lifeless> MattCampbell: given that we have complete control over the environment
<lifeless> MattCampbell: I think this is a fair assessment
<jam> i feel like there might be extra threads, but they should have been spawned by one of our own threads
<lifeless> the most likely one I can think of is sftp access threads
<lifeless> but AFAICT paramiko is pretty darn good at housekeeping
<poolie> lifeless: maybe we should change the strace function itself to assert there are no threads?
<poolie> well, no more than 1 thread
<poolie> :)
<MattCampbell> I think it would be better to check the count before and after each test; that should make it easier to find the culprit.
<poolie> MattCampbell: well, yes but very little code runs _between_ one test and the next
<MattCampbell> But how far away in the sequence of tests is the strace test from the test that's leaving a thread lying around?  Do we know?
<lifeless> poolie: between is not needed, just the last things done in tearDown()/cleanUp()
<lifeless> poolie: the first cleanup added can be a lambda to check the count
<poolie> lifeless: exactly
<poolie> ok, that sounds nice
#bzr 2008-05-06
<poolie> lifeless: i really think we need to work out what's happening with pqm runtimes?
<poolie> :s/?//
<mtaylor> hey all - I need some help with bzr internals...
<mtaylor> I'm working on a post_push hook to send mail similar to a post_commit email
<mtaylor> the problem I'm having is getting the approrpiate starting revision to send to log.show_log and show_diff_trees
<lifeless> mtaylor: why not adapt the email plugin ?
<mtaylor> lifeless: I did
<lifeless> mtaylor: I'd be happy to review patches to make it do both/be configurable
<mtaylor> lifeless: actually - I'd love to send in the patches... although I might have diverged a bit much at this point (need to go back and break things up into patches I can send in)
<lifeless> mtaylor: there is result.old_revid and old_revno, and result.new_revid and new_revno
<mtaylor> lifeless: if I remember correctly the problem I started out trying to solve, if I use result.old_revno, the log is one revision short
<lifeless> mtaylor: so x..y is half open
<lifeless> 0..1 includes 1 but not 0
<mtaylor> yes
<mtaylor> so that sent me down the trail of trying to find the -1 given 0
<lifeless> mtaylor: do you want to show 0 tho  ?
<mtaylor> yes
<mtaylor> since it's the first rev that is being pushed
<lifeless> mtaylor: no, its the first rev before what is being pushed
<lifeless> mtaylor: I think you might be seeing left-hand-history pivoting
<mtaylor> what's that?
<lifeless> say your current master branch is ABC
<lifeless> and your local branch is AD
<lifeless> (D is local work)
<lifeless> you can't push
<lifeless> so you merge, getting
<lifeless> ADE
<lifeless> E is a merge of BC
<lifeless> now when you push to the master branch the master becomes
<lifeless> ADE
<mtaylor> right
<lifeless> and the old_revno == 3
<lifeless> new_revno == 3
<lifeless> because the old_revno is not the old revision number of the old revid in *your branch*, its the old revno of the old revid in the untouched target
<mtaylor> ok. makes sense
<lifeless> this is one of the reasons that I recommend centralised branches be mutated via checkouts rather than pushing
<lifeless> because checkouts help manage the workflow to avoid this
<lifeless> there is also a branch flag you can set to tell bzr to error if this would happen
<lifeless> the left hand history is privileged in a number of ways, its what log --line shows
<lifeless> its usually the representative list of 'what a project has merged'
<mtaylor> so what I need in this case is really a pre-push hook that gathers info in the same way as bzr send does
<lifeless> well, if you *want* such pivots in your workflow, yes.
<lifeless> but anyhow - the first thing I would do is examine your test case to see if this is what is happening
<mtaylor> bzr push -r50 /tmp/mysqltest
<mtaylor>  bzr push -r52 /tmp/mysqltest
<mtaylor> (I was backwards in what I said earlier)
<mtaylor> that produced:
<mtaylor> bzr push into plugins tree (mtaylor:50 to 52)
<mtaylor> of course, what I was really pushing was 51 to 52
<mtaylor> and in the log, I get 50 as well
<mtaylor> doing log.show_log(self.branch, lf, verbose=True,direction='reverse',start_revision=self.old_revno,end_revision=self.new_revno)
<lifeless> so
<lifeless> sounds like something somewhere is not treating the interval as half_open correctly
<mtaylor> what I did to try to work around it was:
<mtaylor> new_graph = self.branch.repository.get_revision_graph(self.new_revid)
<mtaylor> start_rev = get_parent(self.old_revid,self.new_revid,new_graph)
<mtaylor> where get_parent was a recursive thing kept trying to walk the tree
<mtaylor> but it seems really wrong (and the function breaks on some merges)
<lifeless> mtaylor: just add one
<lifeless> mtaylor: the docstring says clearly that its not a half open interval
<mtaylor> wow. really?
 * mtaylor punches himself in the face
<lifeless> pydoc bzrlib.log.show_log
<lifeless>     start_revision
<lifeless>         If not None, only show revisions >= start_revision
<lifeless>     end_revision
<lifeless>         If not None, only show revisions <= end_revision
<mtaylor> lifeless: ok. I honestly don't know what crack I was originally smoking.
<mtaylor> lifeless: but just adding 1 rather than trying to walk the tree sure does work perfectly
<mtaylor> lifeless: so, have you seen the code that's in bzr-build for adding config info to the branch in a .bzr-builddeb/default.conf file?
<mtaylor> bzr-builddeb I mean
<poolie> hello mtaylor
<mtaylor> hi poolie
<poolie> lifeless: thanks for the RT request, i bumped it to joey
<lifeless> mtaylor: I haven't looked at it, no.
<AfC> A two week release cycle?
<lifeless> no, 1.4 was late
<AfC> {shrug}
<AfC> so, that doesn't change the fact that it only just come out.
<AfC> came*
 * igc lunch
<AfC> I wouldn't dream of quibbling with "ï»¿a good amount of code has landed" but you are jerking the chain of the people who do packaging
<poolie> AfC: so the closest way to keep a precise cycle would be to do the rc1 now and have a longer lag til the release
<poolie> is this an undue burden on packagers?
<Odd_Bloke> AfC: I think jerking the chain of packagers is preferable to jerking the chain of users in general.  Especially as a lot of bzr packagers are within the community (or are poolie), so are aware of what's going on.
<AfC> Odd_Bloke: true
<AfC> Odd_Bloke: and I should also concede that at the scale of third digit minor releases (in the sense of era.major.minor even though everyone insists on calling it major.minor.whatever) people are pretty used to doing bumps with no big deal
<AfC> poolie, Odd_Bloke: but I have noted an enormous amount of dismay expressed by people that people writing plugins (and thence packages for those plugins) across the Bazaar space as a whole have seemed to have a hard time staying abreast.
<fullermd> I don't feel jerked by the fairly fast release cycle.  I feel a little flailing-in-the-dark on delayed releases, though.
<AfC> Perhaps it would be less evident if the coupling between (say) {bzr-svn, bzr-gtk} and bzr was looser.
<jelmer> AfC: bzr-gtk isn't coupled with particular bzr releases
<AfC> jelmer: I'm glad to hear that
<AfC> jelmer: though I must say that I seem to have a fairly strong recollection of frequently battling "this version imcompatible with installed bzr" warnings|errors in the not too distant past
<jelmer> AfC, That was < 1.0
<AfC> Ah
<jelmer> bzr-svn still has version warnings in place and so does bzrtools
<lifeless> spiv: have you any immediate thoughts on:
<lifeless> ERROR: test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles)
<lifeless> vvvv[log from bzrlib.tests.test_versionedfile.TestVersionedFiles.test_add_lines_return(named-knit)]
<lifeless> bzr: ERROR: [Errno 2] No such file or directory: '/tmp/testbzrrIvkG0.log'
<spiv> lifeless: huh
<spiv> lifeless: just "that shouldn't happen",
<spiv> :)
<lifeless> I have two things of concern here
<spiv> lifeless: well, that and I would suspect the __dict__ clearing code that bit you yesterday might again be the culprit
<lifeless> one is is: "test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles)"
<lifeless> that id is the pyunit stock one, and wrong
<lifeless> the other is the mithing log
<spiv> Which is pretty worrying if true, it's meant to make testing faster and easier, not harder!
<spiv> Ideally, we'd only clear tests that fail (hmm, which might be part of the reason I put it in run, you can't figure that out from tearDown/cleanup that I know of)
<lifeless> well
<lifeless> I think the problem here is in the approach
<lifeless> reporting is done from objects to a stream
<lifeless> the size issue you were trying to address is due to keeping objects around
<lifeless> rather than cleaning up tests I suggest simply reporting to a stream at the time of failure
<lifeless> then delete the entire test object
<spiv> Right, but keeping the test cases around is potentially useful.
<spiv> e.g. with a graphical runner.
<lifeless> a graphical runner has different needs
<spiv> I don't want to fight for hypothetical cases very hard, of course.
<lifeless> well I'm just aying that the graphical runner can set a flag/fail to set a flag that controls this
<lifeless> and in fact doesn't need to do either
<lifeless> its conceptually simple:
<lifeless> addError reports immediate
<lifeless> thats in the Result object, which the runner provides
<lifeless> the suite object deletes tests after running them
<lifeless> so rather than for test in tests: run()
<lifeless> its run(); del
<spiv> Twisted has a suite that does that, IIRC.
<lifeless> a graphical test runner that wants to keep the objects just has addError keep a reference to the test object
<spiv> I suppose an alternative spelling more like what I tried is "test.run(); test.cleanThyself()"
<lifeless> indeed; thats what I'm saying doesn't fit that well
<spiv> (with smarts to only call cleanThyself on test objects that have that method, and only call it if the test passed...)
<lifeless> it makes the object interface more complex, because now you need a 'clean' concept added, rather than just 'you are not needed anymore'
<spiv> I guess I'm a bit reluctant to rely on the gc here.
<lifeless> One useful way to think about this
<jamesh> the twisted stuff also wants to do evil things like run a test multiple times
<lifeless> is to consider subunit
<spiv> jamesh: evil, but useful
<lifeless> you can instantiate the test twice to do that
<lifeless> thats simpler
<jamesh> spiv: a reload() type interface would be better for that
<spiv> jamesh: I've certainly wished for that feature in other runners when trying to debug intermittently failing tests
<lifeless> spiv: so imagine all tests run under subunit - report *everything relevant* at failure time, and the object goes away.
<spiv> I don't have any disagreement with instantiating a test twice to run it twice.
<lifeless> spiv: I really think this would be simpler and less prone to errors/race conditions
<spiv> The only reason I see for keeping a test object around after running it is for debugging and reporting (and the reporting really ought to be all done by the time run() returns)
<jamesh> lifeless: I know you're busy, but if you have a chance to look at my bzr-dbus patches at some point it'd be appreciated
<spiv> But it's relatively easy to accidentally hang on to objects, so rather than hoping that "del test" is releasing the last reference to the test case in the face of complicated test suite infrastructure, I thought that just resetting the test case object's state to the minimum possible would be more reliable.
<spiv> Twisted has certainly found that trying to release all references is hard to do.
<jamesh> weak references can help catch that sort of bug
<spiv> So, I'm completely happy to remove the reference, but it just seems prone to not actually having any effect unless we're always very careful.
<lifeless> jam: still around ?
<lifeless> spiv: so, can we tell how many references an object has ?
<spiv> sys.getrefcount in CPython
<lifeless> spiv: so we can write tests that the test framework is wellbehaved
<spiv> Although it's easy to get confused because you need a reference to it to ask how many references there are :)
<lifeless> for addCleanup etc
<lifeless> and if an individual test happens to leak; so beit - its much better than leaking 11111 tests
<lifeless> anyhow, late lunch for me
<jamesh> lifeless: it'd be clearer to do something like: ref = weakref.ref(test); del test; assert ref() is None
<jamesh> if you want to check for leaks
 * spiv wonders why lifeless is noticing bugs here all of a sudden
 * spiv -> food
<lifeless> spiv: well, the id() one had been annoying me for a bit, but I generally had only one variant failing, when I had 6 it become important
<lifeless> jamesh: re testing, yes, thats how to tell if its leaked; but you need to run the test framework in the middle there
<poolie> lifeless, a word in your shell-like ear?
<poolie> spiv and i are working on finishing the smart protocol changes
<poolie> if the server is too old to understand the new request, we'll drop the connection and restart
<poolie> unfortunately the previous logic for understanding the response to the 'hello' rpc is wrong; the client is upset if the server says it's newer
<poolie> as i recall you thought this was a good move when we had another similar situation
<poolie> so it looks like we will stop sending the explicit 'hello' from new clients, and instead just see what the server says about the first command
 * igc pick up kids - bbiab
<poolie> bye
<lifeless> poolie: uhm, I've never liked hello. If you are proposing to stop using hello's then great.
<lifeless> poolie: otherwise I think I don't understand your word
<poolie> so, basically: just send a call in the latest version
<poolie> if the server doesn't understand it, disconnect and try again
<poolie> i think the only contentious part of this is: is it ok to drop the connection and restart if the server doesn't understand?
<poolie> it's undesirable but avoiding it seems complex
<poolie> so i think it's acceptable
<poolie> hopefully this will be the last such transition
<lifeless> we already have the compromise of dropping the connection
<lifeless> so I think its fine
<poolie> right
<poolie> me too
<lifeless> I think it would be nice
<lifeless> if we could figure out the ssh magic to drop the ssh channel but keep the ssh session
<poolie> full stop?
<poolie> yes, spiv said that too
<lifeless> greats minds
<poolie> mm
<poolie> given all the different ssh situations i think that may be hard
<lifeless> without more ssh protocol knowledge I have no idea
<poolie> if we really want to avoid dropping it i think we'd do better to start by sending a command in an old encoding which old servers will understand, but give an error without losing the connection
<poolie> well, we use putty, paramiko, openssh and ssh.com ssh
<poolie> and i think there is no standard way to get it...
<poolie> it would probably be good to have some documentation about "hey you should turn this feature on" as it's generally useful
<lifeless> poolie: I'm not talking about master session stuff
<poolie> i know, but it's similar, is it not?
<lifeless> I think the underlying mechanism is reused
<lifeless> yay, add_lines -nearly- done
<lifeless> deep depdency:)
<lifeless> well, I'm past 8 hours now, so gnight!
 * igc dinner
<spiv> poolie: Hmm, I've hit a surprise bug, so I won't get this patch to the list until tomorrow morning.
<spiv> (it turns out I was forgetting to send the protocol version marker string on v3 responses!)
<Winterstream> I realize that this channel isn't exactly aimed at bzr-svn, but hopefully someone can help me. The problem is that bzr-svn changes SVN properties every time I do check-ins. SourceForge reports these changes and they seem to get longer every time. I don't ever do merging (I always rebase), so it seems as if bzr-svn doesn't really need the info it stores in the properties. Any idea whether bzr-svn can work without the property changes?
<james_w> Winterstream: I don't know if bzr-svn could possibly work without them, but I don't think there is currently a way to turn it off at least.
<jelmer> Winterstream: there's no way to do that at the moment, but please file a bug and I'll have a look at implementing it for the next release
<jelmer> Winterstream: Not setting the properties will have to consequence that you can no longer pull from svn into the branch you pushed to
<gabees> hello all, running Gutsy server, added the intrepid main to my sources, ran update, checked bzr and it is still showing the old version. Is any one able to give me some help with this please?
<RAOF> gabees: By 'update' you mean 'apt-get update' or 'apt-get upgrade', or both?  (1) You need both - update then upgrade (or dist-upgrade), and (2) I hope that gutsy server doesn't need to work.
<RAOF> gabees: Intrepid will break, and break hard, many times over the next month.
<Winterstream> jelmer - I figured as much. Thanks :)
<gabees> no look, I followed the instructions on the bzr site for upgrading it: https://launchpad.net/~bzr/+archive
<gabees> it says to added these intrepid repo
<gabees> but the repo only contains bzr and bzr-tools
<gabees> I did update, and then upgrade
<gabees> but it won't recognise the new version in the intrepid repo
<gabees> hehe
<gabees> i'm now trying to upgrade the entire server to hardy
<gabees> that include 1.3
<_paneb> is a repository usually created for each project?
<_paneb> or is there one repository for all projects (and their branches)?
<gabees> _paneb: one repo for all
<fullermd> Depends on who created it and what they wanted to do.
<_paneb> i will be creating it, and i just want to control several projects
<fullermd> I tend to not mix projects in one repo.
<_paneb> when working "solo" do i create my repositories with trees?
<_paneb> nevermind, i understand now what --no-trees is for
<fullermd> Well, again, it depends on what you need.  tree/no-trees is just a default; you can always create a tree on a branch without one, and remove a tree from a branch with one.
<_paneb> right
<fullermd> Some things I tend to create branches only to use right off, so they tend to be trees.  Others a lot of branches sit around a while, so they're no-trees.
<fullermd> And then there are the work styles where you use lightweight checkouts somewhere other than the repo, in which case you want no-trees.
<igc> night all
<gabees> upgraded to hardy heron now
<gabees> that's got a newer version of bzr
<fbond> lifeless: I'll be adding to that quilt/loom wiki page further when I can.
<fbond> lifeless: It must be emphasized more strongly that carrying live changes in the working tree across threads (up-thread, down-thread, etc.) can be rather terrible.
<fbond> lifeless: If conflicts occur, you are left in the unpleasant situation of having to extricate your valuable changes from a variety of potentially conflicting files.
<fbond> I guess if your instinct is correct (restore from backups), things can go okay.
<fbond> But my instinct in the past has been to quickly move back to the thread that I came from.
<fbond> Which creates more conflicts. :)
<fbond> Perhaps it would be good to refuse to switch threads when live changes are present?
<fbond> (Or at least if arriving at destination thread will result in merges or conflicts)
<fbond> s/merges/new merges requiring commits/
<bob2> live = uncommited?
<fbond> bob2: yep
<jam> fbond: it is a design goal to allow you to switch with uncommitted changes
<krow> statik: ?
<jam> so you can make a change that should be on a different thread
<jam> realize it
<jam> switch threads
<jam> and then commit
<fbond> jam: I'd like to believe that :)
<jam> fbond: conflicts are probably different
<fbond> jam: But the reality of the situation is that the user experience is a bit jarring.
<jam> lifeless: I'll need you to create the bzr-1.5 branch when you get some pqm time. i'll try sending an email in case you miss this
<fbond> jam: Both of those situations are an immediate headache (new merges, conflicts)
<fbond> The only good way I know to deal with it is `bzr shelve', `bzr switch', [resolve,commit,etc], `bzr unshelve', [carry on with life]
<fbond> But that requires some pretty good foresight.
<jam> fbond: I don't have much personal experience with the loom plugin, I just follow along :)
<jam> fbond: so what is causing the conflicts that you are trying to roll back to the earlier thread
<jam> I'm just trying to follow a little bit closer so I might give suggestions
<fbond> jam: I hope this is not too harsh: loom is to what it should be as git's UI is to bzr's.
<fbond> jam: There are a few different ways conflicts can happen.
<fbond> Each thread switch is an implicit merge.
<fbond> If I do:
<fbond> bzr commit ...
<fbond> bzr up-thread
<fbond> I get a new merge that now needs to be committed.
<fbond> (in the higher thread)
<fbond> This merge can conflict.
<fbond> Further, I can also have working tree conflicts.
<jam> How is "this merge can conflict" separate from "working tree conflicts"
<fbond> The merge can conflict with the branch.
<jam> I guess I'm not understanding how the merge can conflict
<fbond> So you get branch-branch conflicts as well as working tree-branch conflicts.
<fbond> Threads are nearly branches.
<fbond> I guess in the end the conflicts are all sitting in your WT, but they originate differently.
<jam> fbond: ok, so the files on disk get conflicted, but if you have live (uncommitted) changes they can also conflict
<jam> fbond: I was just confused by your terms
<fbond> jam: Sorry, I don't know bzr's internal concepts as well as you do.
<fbond> So I probably use bad language.
<jam> I wouldn't claim that
<fbond> jam: I would :)
<jam> fbond: so the issue is that switching trees might conflict
<fbond> Anyway, the end result is that switching threads can't be done as casually as you'd like.
<jam> and then after that you have an implicit merge
<jam> which might conflict *on top* of that
<fbond> Right, conflicts aren't the only issue, though.
<fbond> If I have uncommitted changes in the WT and I switch to a higher thread, causing an implicit merge (with no conflicts) my WT now contains my new changes, but it also contains a merge that needs to be committed.
<fbond> So I have to extricate the changes that I was carrying around in the WT from the merge itself.
<jam> fbond: sure, I think the "switch with uncommitted changes" is meant more for down-thread, not up-thread
<fbond> jam: Okay, possible.
<jam> and I see your point about difficulties
<jam> so.... what would be my resolution
<fbond> jam: Yeah, I like using loom, but when I forget to shelve before these critical thread switches, it's pretty frustrating.
<jam> fbond: would it be easier if up-thread refused with uncommitted changes
<jam> or if you could at least set a flag for that
<jam>  or require --force, etc
<fbond> jam: Right.  You could be a little more granular and say "up-thread refuses if the switch would result in uncommitted merges and/or working tree conflicts"
<jam> it would, unfortunately, make up-thread a bit slower, as it would have to check for changes before moving
<fbond> But that might not be as predictable.
<jam> fbond: doesn't up-thread always result in an uncommitted merge
<krow> Hi!  I just had bzr puke on commit on me:
<krow> http://pastie.caboo.se/192356
<jam> I thought that was part of the design
<fbond> jam: Nope.
<jam> well, I suppose it might already be merged
<fbond> Exactly.
<fbond> (And that is more often than not)
<jam> krow: have you been doing something interesting with the "plugin/daemon_example" directory?
<jam> It is at least claiming that you have a file inside it, but the actual directory is not present
<jam> krow: any chance you could paste "bzr log -r -10..-1 --short --verbose" ?
<jam> krow: this is bug #150438, btw
<ubottu> Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed] https://launchpad.net/bugs/150438
<krow> jam: Yeah... I did an rm without a bzr
<jam> hmm... sounds like an auto-detect error
<jam> we detect that the directory is removed
<jam> but don't propagate that to all the children properly.
<jam> krow: is this during "bzr commit "?
<krow> jam: Yes
<jam> krow: so you did something like
<jam> rm -rf plugin/daemon_example
<jam> bzr commit -m 'xxxx'
<jam> and it blows up like this?
<jam> or you did that a while ago
<jam> and now it is complaining
<krow> jam: Dd the rm and then did the commit
<krow> jam: Currently stuck at the commit... :*
<krow> jam: Currently stuck at the commit... :(
<krow> jam: http://pastie.caboo.se/192357  That is from the command you asked me to run
<jam> krow: you've been doing a lot of housekeeping :)
<krow> jam: Yes :)
<krow> jam: So thoughts on how to get out of this?
<jam> krow: well, there are certainly ways to reset things
<jam> I'm not sure what is best righ tnow
<jam> is the only change removing some directories
<jam> (aka easily redone)
<jam> or is there more complex stuff
<jam> krow: for example, you could do
<jam> cd ..
<jam> bzr checkout --lightweight plugin alt_plugin
<jam> rm plugin/.bzr/checkout
<jam> mv alt_plugin/.bzr/checkout plugin/checkout
<jam> krow: don't do it until we've sorted things out, though
<jam> that will reset bazaar into thinking you haven't done anything to your tree
<jam> So simple changes like removing directories should be fine
<krow> jam: Ok...
<jam> as should modified files, etc
<jam> renames will be lost
<jam> but you can use "bzr move --after"
<jam> krow: I would *really* like to understand how it got into this situation, thoguh
<krow> jam: All there is, is modified files and rm'ed stuff. No moving.
<krow> jam: I can save a copy of the tree.
<jam> krow: if you could, that would be nice
<jam> my concern is that it was the steps leading up to this that caused the problem
<jam> and a post-mortem isn't going to reveal the secrets
<jam> but it is better than nothing
<jam> fbond: it is pretty easy to detect if we would need to merge, would that UI suit you?
<jam> fbond: just to finish the conversation :)
<jsled> I'm trying to make sure I understand something about bzr history and merging.  In a situation with multiple developers having a centralized/remote shared repo (bzr+ssh access) and each having local shared repos with a branch from the remote trunk â¦ is <http://paste.lisp.org/display/60340> accurate?
<jsled> I might be wrong on the version numbering in the merge commit.  It probably makes more sense if the two developers both branch from (and "share") commit 1.
<beuno> jsled, looks exactly like what I'm using  :)
<krow> jam: Well, this thing is 596M tarred/compressed
<krow> jam: Is there a way to permanently snip history?
<beuno> jsled, is there a specific concern for this workflow, or are you just making sure?
<jam> krow: well, you could rm .bzr/repository/packs/...
<jam> I'm mostly interested in the WT
<jam> also, a 'make clean' or equivalent is usually good
<jsled> beuno:
<krow> jam: Problem:
<jam> so I'm not getting .o files
<krow> [brian@localhost plugin]$ bzr checkout --lightweight plugin alt_plugin
<krow> bzr: ERROR: Not a branch: "/home/brian/Other/mysql-6.0-brian/plugin/plugin/".
<jsled> er.  beuno: It's wicked confusing, as the revision numbers keep jumping around.
<jam> krow: did you miss the "cd .." ?
<jsled> As well, trying to use the revision number as a build number becomes impossible.
<jsled> It makes the history really hard to search for changes.
<jam> jsled: there is a recommended workflow which gets around that
<fbond> jam: Yes, I'd be happier with the UI if it didn't help me shoot myself in the foot.
<krow> jam: Is the command from the root of the repository, or from outside of it?
<jam> and a flag you can set so that the second 'bzr push' won't let the mainline revno jump around
<jam> krow: you have "$repo/plugin" right?
<jam> where "plugin" is the branch?
<jam> so you want to be above the branch
<jsled> jam: I've love to hear/read about it.  I've thought baout trying to encourage the use of "rebase", but the workflow is already pretty complicated.
<jam> so that you can do "bzr co --lightweight a_branch other_branch"
<jam> jsled: so, #1 is to use a checkout for your mainline, which people then merge into and "bzr commit" to update the tip
<jam> let me check #2 real quick
<jam> #2 "echo 'append_revisions_only = True' >> .bzr/branch/branch.conf
<vigneswari> hello all...
<beuno> jsled, rebase is stronly disencouraged as it breaks history, and leaves branches unmergeable
<vigneswari> we have one distro based on debian
<beuno> jam, do you know what adding appen_revisions_only does?
<vigneswari> planned to maintain source using bzr
<jam> beuno: if it would change your mainline revisions it refuses the push
<krow> jam: http://pastie.caboo.se/192366
<beuno> jam, does it force #1 or similar, or just create new revs instead of subrevs?
<vigneswari> currently we have the bzr repo in local machine and our team is using locally using ssh authentication
<beuno> jam, ah, that's what I thought, thanks  :)
<jsled> beuno: breaks history?  To be clear, by "rebase" I mean the process of moving a sequence of commits to the tip after each pull â¦ basically so there are no merge commits.
<vigneswari> but i dont know how to make it public
<jam> krow: interesting.... I think I know why, but trying to figure it out for a second
<vigneswari> bzr+ssh is better or ftp?
<jam> krow: I believe what is happening is that "bzr checkout" is trying to copy files from your source checkout, and failing
<vigneswari> want to know hoe to configure this
<jam> krow: so we need to tell it that there isn't actually a checkout there
<jam> krow: so do "mv mysql-6.0-brian/.bzr/checkout mysql-6.0-brian/.bzr/checkout-old"
<vigneswari> plz someone help me to do this
<jam> krow: and then try the same "checkout --lightweight"
<vigneswari> any suggestions?
<jam> krow: and then you should be able to mv 'alt/.bzr/checkout mysql-6.0-brian/.bzr/checkout'
<beuno> jsled, yes, I understand. But rebase removes many references, so it makes it impossible to use continuosly
<bob2> vigneswari: you can make it publically available just by letting anonymous users have read only access via ftp or http
<beuno> vigneswari, bzr+ssh is much faster as it uses the bzr smart server
<beuno> vigneswari, if you want to make it public, http is probably the best way to go
<bob2> really?  at least bzr:// was slower for some operations.
<vigneswari> bob2, beuno , readonly? if they want to edit the source and to contribute..
<beuno> vigneswari, well, bzr+ssh is fine then
<bob2> vigneswari: then give them ssh access so they can use bzr+ssh or sftp
<jsled> beuno: Just curious, what sort of references?   Or does it get into bzr internals?  I mean, abstractly, one could create a diff for each commit, uncommit+revert them, pull, then re-apply the merges + commits in sequence.  I'm not sure what references would be lost.
<vigneswari> bob2, any doc for using sftp?
<beuno> bob2, well, there are some things to fix with the smart server so it's faster in every operation. But i think in general, it's faster
<bob2> vigneswari: same way they would use sftp for anything else - it doesn't require any special bzr-specific configuration
<jam> fbond: bug #227339
<ubottu> Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339
<fbond> jam: thanks
<beuno> jsled, I really don't know many specifics. I believe mainly what was merged from where, thus, making it impossible for people merging in changes done in different points of the timeline
<vigneswari> bob2, is it adviceable to give write permission to others...
<jsled> fbond: hey. :)
<jam> beuno, bob2: bzr+ssh is generally much faster than sftp, atm it is on par with http, but getting better
<fbond> jsled: Hi :)
<bob2> vigneswari: sorry, I don't understand the question...
<fullermd> It's much slower than http for write operations.  Writes over http get done real quick   :p
<beuno> jam, I recall a few discussions during the sprint where the smart server was slower than http, was that solved?  I know it's always faster than sftp
<jam> jsled: the big difference with "rebase" is that you don't actually record that you merged the other person's changes
<beuno> fullermd, lol
<bob2> hey I think the http cgi write thing does work nowadays
<jam> beuno: I don't believe it has all been solved
<jam> it is something spiv is working on
<jsled> jam: those numbered points from earlier â¦ are they from a particular list (a FAQ that I should have searched for first, maybe? :)
<vigneswari> bob2, that means ssh authentication to whoever wants..
<jam> jsled: I don't think "append_revisions_only" is well documented, it only seems to be exposed via "bzr init"
<fbond> jsled: In bzr, revisions are a tree snapshot (although they may not be stored as such) and a parent revision.  Rebase rewrites history, thus destroying historical correlation with branches whose parent revision is in the rebased branch. (Somebody correct me if I'm wrong)
<jam> jsled: the workflow is: http://bazaar-vcs.org/Workflows?highlight=%28workflow%29#head-ca3ccf73574776b36453b2213789731549e54167
<jam> But that doc doesn't get into enough detail about *why* you would want that way
<krow> jam: Thanks! I believe that got me working again.
<bob2> vigneswari: don't give people ssh access unless you want them to be able to modify your bzr repository
<jam> It just says it exists
<bob2> vigneswari: you can make it available, read-only, via ftp, http, bzr://, etc
<beuno> vigneswari, you could use something like bundlebuggy if you want something intermediate
<beuno> and work with patches
<beuno> although it might be an overkill
<vigneswari> bob2, thanks
<jam> jsled: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#decentralized-with-shared-mainline
<Lo-lan-do> Hi there
<jam> is the same thing in a different document
<jam> and is the more "canonical" location for that documentation
<bob2> boomtish
<Lo-lan-do> Is there a simple way to know from a heavy checkout whether I'm missing some revisions from the master branch?
<bob2> bzr missing?
<jam> krow: also, bzr 1.4 has been released, any chance you could upgrade to it?
<Lo-lan-do> bob2: That will get me the revisions I'm missing from the parent branch, which is not necessarily the master branch.
<bob2> ah
<jam> Lo-lan-do: well 'bzr missing http://path/to/maste/branch" will
<jsled> jam: Is it me, but is there a `bzr push` missing from that workflow, though?  I mean, a) that's very similar to the workflow we have, and b) I don't see how one can issue a commit to a remote branch.
<jam> but certainly is a bit to type
<jam> jsled: the checkout
<Lo-lan-do> jam: Yeah, hence my request for a "simple" way :-)
<jam> does the push for you
<jsled> jam: What checkout?
<krow> jam: I tend to stick to whatever the distribution provides (though sometimes I will use the python (forget the name of it) tool to upgrade python bits)
<jam> krow: you are probably thinking "easy_setup/easy_install"
<jam> krow: what distribution are you on? Hardy or debian
<Lo-lan-do> jam: Could there be a new revisionspec for that?  Like "bzr missing -rmaster:"?
<jam> (since you have 1.3.1)
<krow> jam: FC :)
<jam> Lo-lan-do: I suppose it could, if 'missing' took a revision id
<Lo-lan-do> Ah, yeah, I'm confused.
<jam> krow: hm.... I wonder why they have an rc1 as their official version
<krow> jam: Who knows... RH has shipped alphas as well.
<Lo-lan-do> Maybe a "bzr update --mising" then?
<jam> Lo-lan-do: well, 'bzr status' could also check if this is a bound branch and if the remote tip == this tip
<jam> it already does it for normal checkouts
<Lo-lan-do> or --show-missing, or something
<jam> jsled: let me put up a patch to the document, which might help you understand a bit more
<jam> jsled: I might as well get it written down
<fbond> jam: #227339 doesn't cover the case where there are no new pending merges, but there are plain WT conflicts.
<fbond> Shall I create a new bug to cover that case?
<jam> bug #227339
<ubottu> Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339
<fbond> Or piggy back on that one?
<jsled> jam: That'd be awesome.  I just don't see a "bzr checkout" in that section, is all. :/
<jam> fbond: feel free to post that as well
<jam> they *might* be different issues
<jam> conflicts would be considered an uncommitted change
<fbond> jam: They are obviously related, but are different cases (although they can overlap).
<fbond> jam: I'll create a new bug.
<jam> fbond: you can always say "see also bug #227339" in your comment, so people can easily jump between them
<ubottu> Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339
<jam> jsled: does this clarify it a bit: http://pastie.caboo.se/192384
<jsled> jam: it does, for the example.
<fbond> jam: bug #227339
<ubottu> Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339
<fbond> jam: eh, I mean bug #227349
<ubottu> Launchpad bug 227349 in bzr-loom "Should refuse to switch threads if doing so would cause a WT conflict" [Undecided,New] https://launchpad.net/bugs/227349
<jam> fbond: I'm not sure that refusing to switch because of a conflict is the correct solution
<jam> because you will always get conflicts when people change similar parts of code
<fbond> jam: I guess I make a distinction between what I call "branch conflicts" and "working tree conflicts"
<jam> fbond: I'll clarify on the bug
<fbond> jam: thanks
<fbond> (to be clear: I say "WT conflict" when I mean "a conflict between an uncomitted change and the branch")
<fbond> jam: BTW, I'm open to suggestions WRT wording :)
<jam> fbond: wouldn't this be handled by bug #227339?
<ubottu> Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339
<jam> fbond: because you can't switch if it is going to merge and you have uncommitted changse
<jam> thus it can't conflict
<fbond> jam: No, I'm not talking about a situation where there are uncommitted merges.
<fbond> jam: Here's the scenario:
<fbond> I'm in thread A
<fbond> I make some changes to source files.
<fbond> I switch to thread B.
<fbond> My current WT can conflict with the previously committed state of thread B.
<fbond> Thus, a WT conflict arises.
<fbond> (And there are no pending merges)
<jam> fbond: ok, I think I follow
<_paneb> when working with the SVN-style repository layout (http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#choosing-a-shared-repository-layout), day-to-day work is performed on the feature branches, and then once a feature is ready to be commited, the feature-branch is merged with trunk?
<jam> fbond: ok, check the updated text on bug #227339, let me know if it captures your ide
<jam> idea
<ubottu> Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339
<jam> For the example I was able to put together
<jam> I have to say, you sort of have to handle that conflict in that situation
<jam> so i'd like to have another example that would make it more obvious that you don't want to switch
<jam> _paneb: the feature is merged *into* trunk
<_paneb> ok
<fbond> jam: Well, switching threads is typically done pretty casually.
<jam> _paneb: generally you only merge trunk => feature_branch if there is something potentially conflicting, etc being done by trunk
<_paneb> i used the wrong word :)
<_paneb> i meant branch => trunk
<fbond> jam: Sometimes, I pass through one thread on my way to another (I guess I could use bzr switch...)
<jam> fbond:  I think it still has to go through the intermediate threads
<_paneb> and while the feature is not quite complete yet, it is only committed to the feature-branch, right?
<jam> fbond: anyway, it would be nice to have a clearer example of why this is necessary
<jam> _paneb: correct
<jam> (for some values of incomplete)
<_paneb> non-working
<jam> _paneb: having worked on projects with distributed development, you still want to merge your changes in fairly often to avoid drift
<jam> _paneb: but yes, while your branch is not at a point it can be used, you leave it in the feature branch
<_paneb> right ok
<jam> my point is more about project management
<jam> having someone work for 2 years on their own branch before merging
<jam> is not recommended :)
<_paneb> heh indeed
<fbond> jam: Hmm.  Your example is correct, but you seem to be marginalizing the issue :)
<jam> fbond: I felt the example was marginal, which is why I asked for a better example
<fbond> jam: For me atleast, it is not uncommon to carry uncommitted changes around in my loom for a fair bit while I sort out which changes should be committed where.
<fbond> jam: In other words, I occasionally go wild implementing features/fixes and then sort out after the fact where those should actually be committed.
<jam> fbond: your organizational issues are up to you :)
<jam> I don't use looms, and instead rely on 200+ feature branches
<jam> so when I get an unrelated change
<jam> it tends to be
<jam> cd ..
<fbond> jam: Well, sometimes I start out looking at one thing and find other things that should be tweaked.
<jam> bzr branch feature_foo bugfix_bar
<jam> cd bugfix_bar
<fbond> jam: Yeah, I considered using many branches instead of loom.
<jam> bzr merge --uncommitted ../feature_foo
<fbond> jam: I guess this is why some people have pushed for faster git-style switch ...
<fbond> jam: Anyway, so assume that I might end up collecting several different changes in my WT simultaenously and then look for places to commit them afterwards.
<fbond> jam: Surely, you can see how I might carry a good size diff around the loom for a while, and in my frequent loom commands, every now and again I get an undesired WT conflict.
<fbond> jam: That conflict could have been avoided in some circumstances.
<fbond> jam: If loom says "won't merge as it would cause a WT conflict"
<fbond> I'll skip over that thread and switch directly to the thread where I want to merge the conflicting change.
<fbond> Then I only have to resolve necessary conflicts, and never have to resolve conflicts just to regain mobility on the loom.
<fbond> jam: Is my expectation unreasonable?
<jam> fbond: I think you are using "loom" as a replacement for git-style branches
<jam> which it is *not* intended fro
<jam> for
<jam> it is meant as building up a series of patches
<jam> I can't say we have a great answer for multiple non-related branches
<jam> in the same WT
<jam> I believe that was discussed at the last sprint
<_paneb> and when i first start working on a new feature, i create the new branch and push it to the central location?
<jam> _paneb: your choice as to whether you push it or not, depends on whether you want it visible to others
<jam> while you are working on it
<fbond> jam: Well, my intention is rarely to create a cluster-f****d working tree.  Rather, I set out to create a sane series of patches, but sometimes I end up with scattered changes that need homes.
<_paneb> jam, ok
<jam> fbond: and I think that is reasonable, I think an answer is to make it easier to do that sort of thing as unrelated branches with switch, etc.
<jam> I don't honestly know how switch works with looms
<jam> my understanding is that it would have to 'up-thread/down-thread' between all of them
<jam> but maybe it allows you to jump directly
<fbond> jam: it does
<fbond> jam: I'm editing the bug description to cover this situation.
<jam> fbond: see the followuup on #227349
<jam> fbond: you might look at it before you change the description
<colophon> Is there a way to have files ignored in some branches but not others which share the same repository. I have a project that includes some sample data that shouldn't be updated during the normal course of development but I would like to have it versioned
<jam> colophon: well, each branch has its own .bzrigore
<jam> though when you merge the changes to other files, it will pull along the .bzrignore files
<jam> *howeve8
<jam> *however*
<jam> if you have a file versioned, we don't pay attention to the ignore file
<jam> so you could have all branches claim that the files are ignored
<jam> and they just happen to be versioned in the one tree
<jam> colophon: though it sounds like you may be asking for them to be versioned, but changes ignored in the other branches
<jam> which isn't something we support yet
<colophon> OK, I'll try to figure out how to split everything into two then
<colophon> Thanks
<fbond> jam: oops :)
<fbond> jam: I'll fix it.
<fbond> jam: Foo, launchpad doesn't seem to track intermediate changes to the description...?
<fbond> Ah, I have it in an e-mail.
<jam> fbond: I think it might, but i'm don't believe it exposes it
<fbond> jam: bug #227349
<ubottu> Launchpad bug 227349 in bzr-loom "Should refuse to switch threads if doing so would cause a WT conflict" [Undecided,New] https://launchpad.net/bugs/227349
<fbond> My comment is mostly superfluous.
<jam> fbond: seems reasonable
<arj> hi
<arj> I have two branches, one which is head and one that is stable. Mostly stable is == head, unless in release mode, in which, stable cherry picks patches from head. Now a release I want to sync these two branches again, but merging in stable from head creates conflicts. Why doesn't this just work? There was no changes to stable, other than the cherry picked patches
<Vadi> How can I find out what revision is a branch at? I looked around the commands list but none report it
<LeoNerd> bzr revno
<Vadi> Thank you!
<fullermd> arj: Because of the cherrypicks.
<arj> fullermd: but that doesn't make sense
<fullermd> Sense?  This is the Internet!
<arj> say I have 10 revisions in head. Stable is rev 4. I cherry pick 6 and 7
<arj> then I do, merge with head later
<fullermd> Cherrypicks don't bring along any metadata; it's roughly equivalent to a diff | patch.  So bzr doesn't know you cherrypicked anything; it's indistinguishable from making the changes manually.
<arj> so it should just unroll 6 and 7 and do a full update
<arj> oh :(
<arj> that sucks, when will it be fixed? :)
<fullermd> Not soon, I expect.  It's a Moderately Hard Problem.
<fullermd> AFAIK, the only systems that properly handle it are those like darcs, which tracks sets of patches rather than series of states.
<arj> getting the full range of situations right might be moderately hard. But the case I just mentioned should be rather easy. And I don't this is a quite common case.
<arj> s/don't/think/
<arj> the problem is that I have already mirrored the stable branch somewhere. So what is the easiest way to fix my stable branch?
<fullermd> Well, if you have one small block of contiguous cherrypicks, it's not TOO hard.
<fullermd> You can merge up to the rev before the cherrypicks, commit, merge the revs you cherrypicked, revert [since you already have the changes] and commit (which records the revs in your history), then merge the rest.
<fullermd> (the same mechanism could work for bunches of noncontiguous cherrypicks, of course, but it gets REAL annoying quickly)
<fullermd> Or you could just manually resolve the conflicts.  If they're small, that can be quicker.
<arj> hmm
<arj> maybe a wrapper around bzr would be easier in the future
<fullermd> I guess a third option would be to merge all the changes, and use revert to force the files to the way they are in the last rev of head.
<fullermd> If you don't have any local changes in stable, that's probably the simplest.
<fullermd> (or you do have local changes, but don't want to keep them)
<arj> how do I do the last force thingy?
<fullermd> Look up the revid of that rev in head, do the merge, then `bzr revert -rrevid:whateveritwas .` (in the root dir of the branch)
<fullermd> You need the '.', otherwise revert will throw away the merge info.
<fullermd> This way it just forces all the files to how they are in that rev, and blows away conflict stuff.
<arj> hmm
<arj> it seems like it looks for the revid in stable
<arj> bzr: ERROR: Requested revision: u'revid:1608' does not exist in branch: BzrBranch5('file:///home/arj/bzr/mms-1.1.0-stable/')
<fullermd> No, you want the revid (em@ail.addr-2008046235lbzehl or whatever), not the revno.
<arj> 1608 is the revision of head I merged
<fullermd> See `bzr revision-info`, or `bzr log --show-ids`
<fullermd> The revision number will be different in stable than it is in head.  And it won't have any revno in stable until after you've committed.
<fullermd> But it should be accessible by the revid any time it's in the repo, which is is after you do the 'merge' even before you commit.
<arj> ah that works
<arj> thanks a lot!
<dacresni> hey, does the bzr smart server have permissions?
<MattCampbell> When using the bzr smart server over SSH (the only method I'm familiar with), it runs under whatever Unix account you tell bzr to log into via SSH.  So it's subject to Unix file permissions.
<dacresni> what about if windows users are loging into it?
<MattCampbell> Is the server itself running Unix or Windows?
<dacresni> windows
<MattCampbell> Hmm, I'll have to let someone else answer.
<dacresni> k
<fullermd> The system itself provides no permission management or control at all (excepting that it may be run in read-only or read-write mode).
<fullermd> So whatever limitations are provided by the OS environment around it are what you have.
<dacresni> so i must use http auth on that directory on IIS
<dacresni> ?
<dacresni> (i wonder if mercurial can do better)
<fullermd> Well, if you're working over ssh, http auth doesn't come into play.
<dacresni> but if I don't want to isntall ssh on the server,
<fullermd> But if you're using the HTTP smart server, yeah, whatever auth Apache provides is what you're running with.
<dacresni> IIS
<fullermd> And whatever permissions/restrictions are applied to CGI scripts are the limits of what you can do post-auth.
<dacresni> post-auth?
<fullermd> "Can I access this" vs. "What can I do once allowed to access"
<dacresni> ah
<fullermd> HTTP auth provides authentication.  OS permissions (unix perms, ACL's, chroot's, blah blah blah) determine authorization.
<dacresni> ah, ok that helps
<MattCampbell> My suggestion, if you must run the server on a Windows box, would be to set up Linux of some kind in a VM on that box, maybe using VMware Server (free of charge), and use bzr+ssh inside the VM.
<fullermd> Now, over a dumb server (plain HTTP), you can use the web server config to manage [some] authorization too.
<fullermd> But with the smart server, every request shows up as a POST to a specific URL, so you can't get any finer-grained.
<dacresni> AH, Neat
<nysin> I maintain a modification to a program which switched from svn to bzr and now I'm left with a near-copy of that repository (I have both bzr and svn forms around, since I did a repository conversion on my end too) with its own revision history. I could (1) sacrifice that history, start fresh with a bzr branch/get/etc clone of the main repository, generate a big patch (or multiple little patches corresponding to the history wi
<nysin> th synthetic timestamps? eh.) representing the entire delta, apply it to the new clone, and continue on and take advantage of bzr's merging abilities. Or (2) basically do bzr diff's on changes to remote repository and give up lots of good things, but keep revision history. Is this accurate and am I missing something?
<fullermd> You may be able to use rebase to automate doing (1) but keeping the individual commits/timestamps/etc.
<nysin> hm
 * fullermd wanders off.
<dacresni> fullermd: sweet! everyone here that writes for the web has windows domain access to the webserver
<Vadi> There's a typo in the bzr user guide (http://doc.bazaar-vcs.org/latest/en/user-guide/index.html), it says "Linix" near the bottom.
<_paneb> bzr merge the.main.branch: does this merge the.main.branch into my local branch?
<arj> yes
<_paneb> then i would do commit to update the.main.branch?
<arj> you merge
<luks> what do you mean by 'to update'?
<arj> and if you're happy with the merge, you commit in your local branch
<_paneb> ok, suppose there is a main branch somewhere. i created a checkout from it and added some changes. then i want to commit those changes to the main branch
<luks> then you just commit
<awilkins> Yes, checkouts are bound to their parent branch
<_paneb> ah yea right
<_paneb> now, if i weren't using a checkout, how would it go? i would have to merge the main branch into my local one and then push the local one?
<luks> commit and then push
<_paneb> ok
<luks> commit+push in a standalone branch is basically the same as commit in a checkout
<_paneb> ok
<luks> you only need to merge if the main branch has changed since you branched it
<luks> and in that case, 'bzr push' would complain
<_paneb> ah
<_paneb> thank you
<pbor> after a rebase, how can I turn all my locally committed changesets in a single changeset?
<MattCampbell> What's the recommended way to install a recent version of bzr on Debian Etch?
<MattCampbell> If I create branches from several existing directories, can I later combine those into a single branch containing those directories?
<fullermd> Yes.
<MattCampbell> So I suppose if I'm not sure about how to organize files and directories under version control, I should start off with several small branches and then combine later if that seems better.
<fullermd> Yeah.  Combining them is easier than splitting them up [without losing history].
<poolie> hello all
<beuno> mornin' poolie
<igc> morning all
<igc> morning beuno
<beuno> mornin' igc
<Peng> So it seems going to the bzr+http smart server in a browser, doing a GET, returns a 404. I wish I had known that before
<Peng> I spent ten minutes figuring out why it was broken, when I just wasn't accessing it right. :P
<Peng> How'd I hit Enter in the middle of that? Shift, I guess.
#bzr 2008-05-07
<ionel_mc> isn't bzr supposed to be easy_install-able ?
<beuno> igc, I was wondering, since you kinda nodded at the sprint when I asked if you could help with the IDE Integration team, do you think you might have some time these coming weeks to help me put together the basics for an integration guide?  Mainly the structure, I can fill the blanks and/or poke people to do so after that
<beuno> I can't really think of a good structure for it  :(
<igc> beuno: sure. I'd like to keep focus on 1.5 this week so how about bugging me about it again next week?
<beuno> igc, sure, sounds good. Thanks  :)
<lifeless> jam: poolie said you'd need the branch friday?
<jam> lifeless: yeah, by friday to do 1.5rc1
<lifeless> jam: if I make it early it misses merges
<lifeless> jam: its best to make it at th etime
<jam> lifeless: as long as it happens, I'm okay with that
<jam> I could always do a merge from bzr.dev as the first thing
<lifeless> no need, I'll make it late my friday
<lifeless> it will be there pristine when you get up
<lifeless> ionel_mc: I think we support that but not 100% sure
<lifeless> ionel_mc: however having folk run arbitrary scripts over the internet isn't really a great idea, so few of us are deeply interested in that install path
<ionel_mc> lifeless, i think you completely misunderstood easy_install
<lifeless> possibly
<lifeless> I realise that what I said above does not encompass the entire thing
<ionel_mc> rather silly regarding easy_install as "running arbitrary scripts over the internet"
<poolie> lifeless: can you have a quick look at my RemoteBranchLockableFiles mail, just saying "yes" to john would be enough
<ionel_mc> regardles, here's the problem (on win32): http://rafb.net/p/CQ4V9N22.html
<ionel_mc> should be fixed by providing a corect egg for win32
<lifeless> poolie: when are you arriving ?
<bob2> same problem on lunix
<lifeless> thats strange, I'm sure we include setup.py in the tarball
<ionel_mc> lifeless, ah yes, the download link is broken on the pypi entry, should be http://launchpad.net/bzr/+download instead of http://bazaar-vcs.org/Download
<lifeless> poolie: ^
<ionel_mc> lifeless, that tarball is for slackware only
<bob2> heh, it is downloading a slackware tarball
<poolie> !!!
<bob2> ionel_mc: which of the files on the launchpad page would be easy_installable?
<ionel_mc> bob2, depends on the platform
<poolie> lifeless: i think you misunderstood my text
<lifeless> poolie: ko
<lifeless> *ok*
<lifeless> I thought you were saying that the thing was intercepting the wrong api, and not allowing the server to provide the configuration, and that you proposed to make the method deprecated
<lifeless> -> caffiene, to avoid other misunderstandins
<MattCampbell> It occurred to me that section 4.2 of the user's guide should mention the bzr+ssh URL scheme instead of or in addition to sftp, because if you're pulling from another developer's machine via SSH, chances are that machine has bzr too, and bzr+ssh would work.
<lifeless> MattCampbell: good point
<MattCampbell> Plus bzr+ssh works without paramiko.
<MattCampbell> on Unix at least
<MattCampbell> On the other hand, I suppose you may wish to emphasize, especially in early chapters, that bzr requires no special server or protocol of its own.
<ionel_mc> lifeless, bob2, any resolution on the easy_install issue?
<lifeless> not sure what we can do
<lifeless> the first url on the page is the right one
<lifeless> pypi is pointing at the right page
<ionel_mc> not quite
<ionel_mc> hmmm
<ionel_mc> looks like easy_install -f http://launchpad.net/bzr/+download bzr doesn't help
<ionel_mc> looks like setuptools pick up the wrong package, either that slackware package is named wrong or there is some problem in seuptools's parsing
<Peng> bob2: Oh, hi.
<ionel_mc> lifeless, either way, you could just upload the packages to pypi for a quickfix
<Peng> Err.
<MattCampbell> It seems to me that chapter 7 of the user's guide, currently called "Best practices", should instead be called something like "Advanced features".
<Peng> Is branching a dirstate branch over bzr+http supposed to result in a traceback?
<Peng> Crap, may just be a corrupt branch.
<spiv> Peng: no, nothing is supposed to result in a traceback :)
<Peng> Haha.
<spiv> (And I don't know of any bugs open about bzr+http + dirstate)
<Peng> Ok.
<Peng> .bzr.log and info at http://paste.pocoo.org/show/48226/ . Want me to file a bug?
<spiv> Peng: interesting
<spiv> Peng: I wonder if reconciling the branch will fix it?
<Peng> spiv: Didn't try it.
<spiv> Peng: that probably is worth a bug report, although it *might* be a duplicate.
<Peng> Reconciling did not help.
<lifeless> poolie:  ?
<Peng> Oh, look, lots of developers are here now.
<Peng> Hint hint. :P
<lifeless> where? I want to meet one
<Peng> Ok, not http-specific. Also happens with bzr+ssh from Launchpad.
<AfC> I don't have anything earth-shattering to say to you today, but wanted to wave all the same.
<AfC> so,
 * AfC waves
<yminsky_> I have a question about how to use tailor with bzr.
<yminsky_> I have two related bzr repos that I would like to export to hg.  I'm not sure how to do this in a way that tailor preserves the fact that the repos are related.  Anyone know how to do this?
<MattCampbell> Have you looked at the bzr-hg plug-in? (I only know it exists.)
<MattCampbell> According to the description at Launchpad, it can transfer in both directions.
<yminsky_> I have not.  that sounds promising.
<Peng> Haha.
<Peng> I ran my VPS out of memory with bzr+http.
<lifeless> mmm, bzr-hg is not able to push to hg last I checked
<yminsky_> Anyone know how to use the plugin?  I downloaded and installed it, but I don't know how to invoke the plugin.
<MattCampbell> Oh, I guess I overlooked the word "eventually" in the Launchpad description. :(
<mneptok> yminsky_: i think the problem is that there just haven't been a lot of cases where people want to move from bzr to Hg  ;P
<yminsky_> Nice.
<mneptok> sorry, couldn't resist.
<yminsky_> Anyone else have thoughts on how to achieve this?
 * mneptok takes some getting used to.
<MattCampbell> Any particular reason you want to go from bzr to hg?
<mneptok> yminsky_: have you broached this subject with the Hg community? converts from bzr to Hg will be more readily found there, i would think.
<yminsky_> Nothing deep.  We use hg extensively at work, and so I am now VERY familiar with it, and I'd like to convert some old bzr repos that I have up to hg.
<mneptok> yminsky_: not trying to blow you off, but as an answer doesn't seem to be immediately forthcoming here ...
<mneptok> *shrug*
<yminsky_> I'm actually a little surprised that this isn't easier.  I feel like I've heard a lot of talk about how it doesn't matter that much which DVCS you use because you can transfer changesets from one to another....
<yminsky_> Fair enough.  I'll poke the mercurial folk.  I just thought there might be some experience here.
<mneptok> yminsky_: there may be. but i think "not at the moment" is a fair assumption. so start looking elsewhere in case that expertise never shows up here. make sense?
<yminsky_> yup.
<mneptok> good good. glad you don't feel unlove ... bah
<igc> yminsky_: we're working with the git guys to improve interoperability via fastexport/fastimport. You can use that approach as well for getting from Hg to Bzr. If and when the Hg guys support fastimport, you'll be able to get from Bzr to Hg that way too.
<igc> hg has an import extension but it doesn't support Bazaar to my knowledge
<igc> there just isn't the demand for people moving from bzr to hg :-)
<mneptok> igc: keep talking to yourself and Mark will buy you a dinner jacket like mine.
<mneptok> nice white coat, but the sleeves are much too long. ;)
<igc> speaking of food, lunch for me :-)
<mneptok> could you loosen my restraints a little on the way out?
<eMxyzptlk> hey guys, is there anything similar to darcs "push apply-as" feature? I'd like to give read/wrtie ability to users but not manually only with bzr
<bob2> you can give them ssh access such that they can only run bzr
<poolie> igc: thanks very much for the doc review
<igc> poolie: np
<igc> poolie: the real test will be jam using it on Friday, of course
<lifeless> mneptok: we love you just the way you are....
<eMxyzptlk> bob2, yea this is possible by specifying COMMAND before the ssh public key, but I'd like them to have ssh access but not enough to manually alter the repositories..
<Peng> Um.
<Peng> ubotu?
<rockstar_> eMxyzptlk, so, no write access?
<MattCampbell> Peng: Looks like it's ubottu now, if that matters.
<eMxyzptlk> rockstar_, no they have right access, but I'd like it to be using sudo to another user who has write access, this way they'd have write access but not using the shell... it's similar to how darcs --apply-as works
<bob2> that doesn't sound any different to ssh command= keys
<eMxyzptlk> bob2, it does, coz if I specify command= keys then the user won't have normal SSH access
<rockstar_> eMxyzptlk, well, you'd probably need two different accounts.
<eMxyzptlk> rockstar_, hmmmm adding the commad= keys to that account ? sounds about right, except the users won't be able to update the public ssh key by themself... sounds like I need to write a wrapper to emulate apply-as behaviour
<eMxyzptlk> rockstar_, how launhpad do it? they create a specific unix group for each project and add the allowed users to it ?
<MattCampbell> Launchpad apparently has a custom SSH server (based on Twisted I think).
<eMxyzptlk> Oh ok
 * rockstar_ nods
<eMxyzptlk> ok thx guys, I'll see what can I do, one last thing, is there any objective comparisation between Darcs and bazaar ? I'm currently using darcs and considering switching to bazaar just checking it out
<Peng> ubottu: ping
<ubottu> pong
<Peng> I don't think it's announcing bugs though.
<MattCampbell> I wonder why it was renamed, anyway.  Were people confused about how to pronounce ubotu?
<nick125> u-bot-u...I don
<nick125> 't see how it would be hard to pronouce
<MattCampbell> Maybe a text-to-speech user got tired of hearing "u-bo-tu".  Since my job consists mostly of developing software for blind users (thus I use TTS a lot), that was actually my first guess.
<Peng> I'm assuming it's a temporary nick. Like, if "ubotu" is already being used.
<MattCampbell> nah, there's no ubotu online.
<MattCampbell> Anyway, it's not important; I was just curious.
<Peng> ubotu may have been online when ubottu connected, and it may not change its nick back when it becomes available.
<poolie> i believe the original admin/owner of ubotu took it down and this is a different service as a replacement
<MattCampbell> Ah, I figured a bot like that would have to be developed and run by Canonical, to integrate with Launchpad.
<mneptok> bug 1
<mneptok> ubottu?
<ubottu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
<mneptok> thank you, you clanking pile of clattering bolts.
<mneptok> </dr_smith>
<Peng> Augh, that bug has 658 comments.
 * Peng apologizes to Firefox.
<mwhudson> i get mail every time someone comments on that bug :(
<sili> hello. one of my employees borked a branch. he was in /devel and issued "bzr branch bzr://localhost/bug/10". it was supposed to be "bzr branch bzr://localhost/devel bzr://localhost/bug/10". how can I remove or otherwise fix this? I have no idea what happened, but I can't bzr remove or remove-branch that directory or anything. if I do a checkout and try to merge /devel into it, it tells me that my tree is out of date.
<sili> bzr update just removes all the files I merged
<sili> it's strange and I just want to kill that directory to start over. any suggestions?
<lifeless> rm -rf 10 ?
<sili> lifeless: is it that simple/
<lifeless> ' bzr branch URL' creates basename(URL) locally
<lifeless> so it should be, yes.
<sili> there is some kind of "10" directory in the repository though
<lifeless> what does bzr info 10 show ?
<sili> from from the working dir?
<lifeless> well, wherever your 10 is
<sili> from the repo dir: Shared repository (format: pack-0.92) Location: shared repository: /....
<lifeless> does it list the branch root as 10 ?
<sili> oh, it also shows "respository branch: 10"
<lifeless> sounds like 10 is a branch
<lifeless> ls -l 10 will list a .bzr directory if it is
<lifeless> andyou can just rm -rf branches to remove them; use bzr log 10 to see whats in it
<sili> it does, but there's no files. trying to merge /devel into it makes crazy things happen
<sili> I see
<sili> I'll try to move it out of the way in case I need to put it back
<sili> lifeless: seems to work. thanks
<vila> lifeless: reagrding strace tests, what about running them in their own process (i.e. spawing a python process that will then invoke strace on itself) ? This a bit ugly but we can use that as an *interim* solution until either strace is fixed or all the other conflicting tests are :-/
<lifeless> uhm
<lifeless> how many conflicting tests are there (have you tried my 2-liner suggestion ?)
<vila> see my mail, 1089 tests are leaking threads
<vila> the mail includes the simplest patch I could think of so you can try for yourself for more details
<LaserJock> is there a way to like compress or compact a .bzr?
<bob2> there's 'bzr pack', but it happens every now and then automatically
<bob2> and is only for pack formats
<LaserJock> argg
<LaserJock> bzr pack almost doubled the size of my .bzr :/
<LaserJock> why on earth would it do that?
<bob2> .bzr/repository/obsolete_packs
<LaserJock> ah
<LaserJock> what are those?
<lifeless> insurance
<lifeless> against NFS particularly, but any file system in general
<lifeless> future commits will clean them out automatically
<vila> lifeless: I forgot to mention in my mail: AIUI, the problem is that strace is not cleaning up properly when receiving SIGQUIT (and neither when receiving SIGINT or SIGTERM, so we're doomed so far), that's why I consider it the real culprit.
<lifeless> (as will pull)
<lifeless> vila: if we can file a genuine bug on strace that would be a good thing
<vila> #103133
<vila> bug #103133
<ubottu> Launchpad bug 103133 in strace "strace leaves process SIGSTOPped after detaching" [Medium,Confirmed] https://launchpad.net/bugs/103133
<LaserJock> lifeless: do you know of anybody who's tried to do benchmarking on using bzr on the linux tree?
<vila> lifeless: we were bitten by a slight variation of that bug (since we don't use -f anymore), but I'm pretty sure it's the same root cause
<lifeless> LaserJock: yes
<lifeless> LaserJock: I am pretty sure ian does, and I have during various performance work
<berto-> i'm running bzr push sftp://[...] and it's taking *forever* on a new branch that only has 10 revisions.  is there any way to speed it up?
<spiv> berto-: are you using the current branch & repository format (pack-0.92)?
<berto-> spiv: yes.
<spiv> berto-: older formats could be very slow with pushing/pulling branches that contain many files (even if there were few revisions)
<spiv> berto-: hmm.  And the remote side is in that format too?  How big is the repository?
<berto-> spiv: i just downloaded bzr two days ago, then made a branch of the dev tree, then ran make to compile stuff.  I presume i'm running the fastest bzr available.
<berto-> spiv: it's a standalone tree weighing in at 1.2M
<berto-> spiv: as reported by du -sh .bzr
<spiv> Ok.  ("bzr info -v" can tell you the size too, btw.)
<spiv> That does seem unusually slow.
<berto-> spiv: i decided to try out bzr by versioning my dotfiles (.bashrc, .bash_profile, .emacs, etc.)  by any chance is it doing a directory listing of the entire contents of my home directory before doing a push?
<spiv> No, I don't think so.
<spiv> You could try doing "bzr -Dhpss push bzr+ssh://[...]"
<berto-> Repository:
<berto->         10 revisions
<berto->        905 KiB
<spiv> And then looking in the ~/.bzr.log file to see where it's spending its time.
<spiv> Right, that's pretty small.  With packs, pushing that over the network shouldn't take long.
<spiv> (unless you're on dialup!)
<spiv> So something strange is going on here.
<james_w> hi spiv
<berto-> bzr command not found on the other end.  is there a way i can specify the full path to bzr ?
<james_w> does autopacking kick in on push?
<james_w> berto-: BZR_REMOTE_PATH I think
<bob2> (set that env var on the local side)
<spiv> james_w: yes
<berto-> bzrlib not in PYTHONPATH ... i thought bzr was able to autodetermine where that thing was based on its install location?
<spiv> But even autopacking 1M of data over the network shouldn't take "forever".
<james_w> berto-: if it is co-located yes, but not if it is a system-wide install
<berto-> "forever" quantified was on the order of ~1.5 minutes.  that really seems way too slow.
<james_w> spiv: yeah, but would it be uploading all the data, then downloading it all, repacking, and pushing it back? Is there a fast-path for this?
<spiv> i.e. you can make a checkout of bzr.dev, and point "BZR_REMOTE_PATH" to that, and it will work
<berto-> running bzr -Dhpss push bzr+ssh://[...] on a tree that didn't have to push anything took 7.2 seconds.
<spiv> james_w: not yet, that's on the "make push fast" hit list.
<james_w> berto-: ~/.bzr.log may have something interesting
<berto-> spiv: that's exactly what i did.  ;)
<spiv> james_w: it really ought to a) happen entirely server-side when using smart protocols, b) let the user known what's going on otherwise
<spiv> My best guess atm is that an autopack happened, which happens from time to time.
<berto-> spiv: is a "smart" protocol one that can run bzr on the "other end" ?  seems like that is what bzr+ssh does.
<spiv> berto-: right
<berto-> i'll stick to that as it seems "smarter"  ;)
<spiv> But ~1.5 minutes still seems a bit slow to me, even when autopacking.
<berto-> i'm going to see if i can make a couple more revs and try pushing with bzr+ssh
<berto-> i want to see the speed difference.
<spiv> berto-: if you don't mind, please keep using -Dhpss for a little while, so if you do see the slowdown the logs will have lots of details about the network conversation
<berto-> spiv: will do.
<berto-> i'm adding an alias so i don't forget.
<spiv> I'm currently doing some infrastructural work on the smart protocol stuff, but once that's out of the way I'll be specifically working on speeding up push with the smart protocol.
<spiv> There's lots of stuff we can do to make it faster :)
<berto-> oh, is there some way to add "auto paging" to bzr commands, e.g. "bzr log" automatically uses "less" ?
<jamesh> spiv: you could buy everyone faster internet connections
<jamesh> that'd help
<spiv> jamesh: if I could buy a faster speed of light, to reduce intercontinental network latency, that'd definitely help
<jamesh> spiv: we could always switch to least-distance cabling
<jamesh> there are shorter paths from australia to england than a great circle
<spiv> jamesh: dig holes to China, that sort of thing?
<jamesh> just use a straight line
<RAOF> jamesh: Do you suggest burrowing directly through the mantle?
<RAOF> You could build a tube system from the Thursday Next novels while you're at it!
<jamesh> spiv: well, a hole to china would only get you part of the way there
<berto-> pushing up a new 12k file using bzr+ssh took ~11 seconds.  still a bit slow, but much better.  as a comparison, using scp to copy the file took 4.8 seconds.
<spiv> berto-: well, bzr has to do more work to determine exactly which data needs to be transferred, and it needs to transfer metadata as well as just the file contents
<spiv> berto-: so it's not a totally fair fight :)
<berto-> spiv: i totally understand.  i should have cleared things up.  i wanted to "normalize" the time, i.e. subtract 4.8 to get the "bzr working time"
<spiv> berto-: take a look in ~/.bzr.log for some idea of what bzr currently does
<berto-> so, roughly speaking, bzr took ~6 seconds to do its job.  is that "fast enough" ... dunno.
<berto-> spiv: i'm actually looking at it as we speak.  :)
<berto-> is it okay to paste a few lines here or is there a pastebin?
<spiv> pastebins preferred.
<spiv> pastebin.com or rafb.net/paste
<berto-> http://dpaste.com/48642/
<berto-> bzr is fast figuring out its setup (i.e. i'm going to be transporting over ssh).  i suppose it took up to 6.2 seconds to transfer the file, then 5 to do its housekeeping (merge + other stuff)?
<spiv> berto-: if you use "bzr -Dhpss ..." the log file will contain more details than that
<berto-> spiv: on which end?  [berto@70-12-91-0][530]$ alias bzr
<berto-> alias bzr='bzr -Dhpss'
<berto-> hmm, wonder if the time command doesn't use my alias ... doh!
<spiv> berto-: d'oh
<lifeless> spiv: that error with the log - an exception in a cleanup trigers it I think
<spiv> lifeless: huh, interesting
<lifeless> yay, down to 3 failing tests
<lifeless> thats all folks
 * igc dinner
<berto-> nite, all.
<renton> hello
<renton> does anyone know plans for tortoisebzr? it seems to have been idle for several months now
<hmeland> There has been some mailing list traffic on design considerations.
<hmeland> I haven't followed it too closely, but I think there is a merge request for a design document (possibly already merged).
<renton> okay, thanks
<renton> btw, couldn't a lot be shared between tortoisehg and tortoisebzr
<jam> morning all
<beuno> mornin' jam
<jam> morning beuno
<igc> night all
<Winterstream> I'd like my repo to forget some recent commits. Am I right that revert doesn't rewind the repo history? If so, how can I do it?
<LeoNerd> revert just modifies the working copy
<jamesh> Winterstream: "bzr uncommit" will undo commits
<fullermd> You can also use pull.
<LeoNerd> Will only remove the top one(s) though... you can't remove something from the middle by doing that
<jamesh> it won't make everyone else's computers forget about them if you've published them though.
<fullermd> (of course, neither will make the _repo_ forget.  They just make the branch forget that those revs are its.)
<Winterstream> Ah. I'm blind. Thanks jamesh & fullermd.
<Vadi> Where can I find documentation on the python get_config() method? Best place I found is here (http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.remote.RemoteBranch.html#get_config), but it's not exactly helpful. I need to see what options besides user_email() can I get out of it :/
<beuno> Vadi, I think looking at the code in that specific bit should be fairly straight forward
<Vadi> Sorry, where can I find the code?
<Vadi> I was having enough trouble navigating to that link hehe
<beuno> Vadi, you can get the lastest with: bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
<Vadi> ï»¿beuno: This is a bit beyond me, but would ".get_config().get_nickname()" return the commiters name? (instead of user_email() which returns their email)
<beuno> Vadi, I believe it's .username()
<Vadi> Thank you
<beuno> you're welcome
<statik> dumb question, how do I garbage collect old revisions from a shared repo, say after I do a bunch of uncommits?
<beuno> shouldn't uncommit remove them from the shared repo?   (I have no idea how it works though)
<fullermd> No, uncommit doesn't remove anything, it just moves the branch head.
<fullermd> There isn't a gc command.  Closest is making a new repo, branching everything into it, and blowing away the old one.
<statik> fullermd: ta
<statik> that is good enough
<beuno> hrm, that doesn't sound like a very long-term usage plan
<beuno> s/very/very good
<gnomefreak> is there docs on bzr-svn?
<beuno> gnomefreak, I found these: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn#id24 and  http://samba.org/~jelmer/bzr-svn/FAQ.html
<gnomefreak> beuno: thanks
<beuno> gnomefreak, np, sorry to make you bounce over here  :p
<gnomefreak> beuno: its ok i have this channel on alias its just a hectic day
<demod> hi
<acemo> hey demod
<mw> is there an easy way to make "bzr status" not show all the files that bzr doesn't know about (Makefiles, etc)
<bob2> -V
<mw> yeah, just worked it out :)
<bob2> or 'bzr ignore Makefile' etc to add them to .bzrignore
<ferringb> any trac-bzr users around by chance?
<mw> yeah, i know about ignore, but it's sort of a nuclear option
 * ferringb is wondering about their experience/opinions on it
<mw> some big projects mostly have generated makefiles, but a few hardcoded ones from other packages imported into their tree
<acemo> bob2: great idea :)
<bob2> mw: ah, right (but note you can still add the ones you specifically want)
<mw> bob2: too many to do that
<mw> bob2: i'm working with firefox source, and there are 900 of them in my working directory
<acemo> bzr ignore Thumbs.db would ignore all Thumbs.db files in all folders or only in the current folder?
<bob2> all
<mw> hmmm, is there a way to get a result analogous to bzr status -V with bzr commit?  bzr commit --show-diffs results in a pretty unwieldy buffer
<acemo> yay no more ugly microsoft Thumbs.db files
<bob2> --show-diffs will only show diffs for files listed by status -V (that is, versioned files)
<mw> bob2: right.  but the buffer i get shows two changed files, almost 1400 files bzr doesn't know about, and then the actual diffs
<mw> bob2: well... plus space above that where i'll write my commit msg
<fullermd> Well, see?  If you'd quit writing commit messages...
<bob2> ah, --show-diffs does list unknown files, that is annoying
<mw> and it's --show-diff
<mw> i always screw that up ;)
<Peng> ubottu: bug 83039
<ubottu> Launchpad bug 83039 in bzr "renaming file in combination with partial commit breaks in some	cases" [Medium,Fix released] https://launchpad.net/bugs/83039
<poolie> hello
<igc> morning
<poolie> hello igc
<lifeless> hi poolie
#bzr 2008-05-08
<lifeless> down to two failing tests
<lifeless> one failing test
<bob2> stacking?
<poolie> jam, if you're still around, and spiv
<poolie> in jam's review of the protocol version patch
<lifeless> bob2: VersionedFiles; pluralised VersionedFile for stacking performance
<lifeless> bob2: needs a better name
<poolie> he said "my concern with this is the problem we had with call_with_body_bytes
<bob2> spiffy
<poolie> lifeless: i think we talked about this the other day but i want to confirm
<poolie> andrew's current v3 patch will make it drop the connection and restart if the remote server is too old
<poolie> in doing so we eliminate the initial hello command
<poolie> do you think this is reasonable?
<lifeless> I think so
<lifeless> hello was bad
<lifeless> getting stateless is very beneficial
<lifeless> yay
<lifeless> all tests passing for initial add_lines
<spiv> poolie: I don't think it's the same problem at all
<spiv> poolie: because a remote bzr server that sees "bzr message 3 (bzr 1.5)\n..." as the first bytes will either know how to handle it or immediately know it can't.
<spiv> And if it can't, it'll stop reading, send back an error (in whatever version it likes), and drop the connection.
<spiv> Even v1 servers will do that, because they'll see "bzr message 3 (bzr 1.5)\n" as a unrecognised verb.
<spiv> All later versions by design check the bytes up to the first newline for a protocol marker precisely to make it possible to reliably tell if a message is in an understood encoding or not.
<spiv> poolie, jam: btw, I just sent my reply to that review to the list
<MattCampbell> Has there been any work on TortoiseBZR lately?  When I looked last night, there was a significant to-do list, including switching from GTK to native Win32 dialogs (BTW, that's needed for accessibility as well as native look and feel).
<MattCampbell> I can't help much with the TortoiseBZR UI; though I'm pretty good at low-level Win32 API and COM stuff, I'm terrible at native Win32 dialog design.
<MattCampbell> TortoiseBZR also doesn't seem like a very good name.  I know it's carried over from TortoiseCVS and TortoiseSVN.  But "tortoise" seems to be a derogatory characterization of the UI preferred by Windows GUI users.  How about WinBzr?
<Odd_Bloke> MattCampbell: This discussion has already happened on the list, though without much of a conclusion (as regards the name).
<i386> MattCampbell: they should hack it in .NET then
<i386> you can do shell extensions really easy with a bit of pinvoke
<MattCampbell> Another option would be wxPython, though wxPython is kinda big (some would say bloated).
<Odd_Bloke> Hacking it in .NET wouldn't be that great, as it would require ugly callouts to Python...
<MattCampbell> Agreed.
<poolie> spiv: yeah that was what i thought too
<poolie> spiv, i think his point with _default_headers is that your code (at least on Tuesday) looked like a caller could also override it for particular calls
<poolie> which might be consistent with how some http toolkits work
<spiv> Well, we have a lack of use cases driving the API here.
<poolie> right
<poolie> i don't think we need to add that until we need it, but i think that explains john's comment
<poolie> um
<spiv> If we do find we want _SmartClient.call(..., extra_headers={}) or similar, then we can rename private variables appropriately then.
<poolie> fwiw i think foo.copy() is clearer abount intention, but i suppose less clear that you get a dict :)
<poolie> sure
<poolie> i'm going out to the shops, biab
<spiv> At the moment there's only "headers", so talking about "default headers" would just muddy the picture for no benefit.
<lifeless> poolie: gnip
<lifeless> poolie: I'd like to hallway test an idea
 * igc lunch
<poolie> lifeless: poing?
<lifeless> hi
<lifeless> igc: I just called a spade a spade; sorry!.
<igc> lifeless: np - thanks for the feedback
<lifeless> igc: I hope my explanation of the confusing aspects is clear enough to help find replacements for them
<lifeless> igc: (if you can see why they are confusing; if you can't I can attempt to describe it differently)
<igc> lifeless: let me digest your input ...
<lifeless> k, I'll grab a bite to eat
<igc> much of the intent is to stop git/hg users trying to use bzr exactly the way they do now
<lifeless> so hg's pull and push are fundamentally different to bzr's
<lifeless> describing how something might look with 'push' when you mean 'hg push' -> havoc
<igc> in particular, the git model of there's ONE true DAG just doesn't translate to bzr
<lifeless> eh? bzr has one true dag
<lifeless> revision X always has the same content and parents, or chaos ensues
<igc> yes, but ...
<Odd_Bloke> lifeless: But we favour one path through the DAG.
<Odd_Bloke> Potentially per user.
<Odd_Bloke> (IIUC)
<lifeless> Odd_Bloke: I think you'll find that git also chooses a particular search path consistently
<igc> our branches provide views - they aren't simply a tag for a revision
<lifeless> igc: do you know how git log orders its output?
<igc> and two developers syncing each other operates differently in bzr to how git users expect
<lifeless> igc: in what way?
<Odd_Bloke> git's search path is by date of commit, so long as it's reachable from the tip (as far as my limited use of git suggests).  bzr's has the concept of a mainline.
<igc> git merge can become a fast forward; for us, fast forward is pull
<lifeless> Odd_Bloke: git-log suggests its topological ordering to me
<lifeless> Odd_Bloke: ah, found the details:
<lifeless>    Commit Ordering
<lifeless>        By default, the commits are shown in reverse chronological order.
<lifeless>        --topo-order
<lifeless>            This option makes them appear in topological order (i.e. descendant commits are shown before their parents).
<lifeless>        --date-order
<lifeless>            This option is similar to --topo-order in the sense that no parent comes before all of its children, but otherwise things are still ordered in the commit timestamp order.
<lifeless> --topo-order will have the same behaviour our log does, though the oredering could be different (there are many topological sorts)
<igc> lifeless: see https://lists.ubuntu.com/archives/bazaar/2008q1/039738.html. the goal of this patch is to capture the gist of that thread
<lifeless> --date-order will, when the topological sort has multiple parallel options apparently choose based on datestamp
<igc> I clearly haven't succeeded though if you found it confusing
<lifeless> igc: So concretely; I think you must *only* use terms that are well defined; if by 'merge' you mean 'how git does it' or 'how hg does it' it will cause confusion
<lifeless> A lot of my issues are in the examples of how one 'might' do it
<lifeless> because:
<lifeless>  - you can do precisely that in bzr
<Odd_Bloke> lifeless: Ah right, that'll explain it. :)
<lifeless>  - bzr's underlying model works completely fine there
<lifeless>  - the english description resonates badly with the semantics of the bzr commands
<lifeless> from memory I think the description of merge collapsing was ok, and without the interferance from the contra examples above probably useul
<lifeless> *useful*
<lifeless> I need food, back soon
<igc> lifeless: hmm. I find it hard to write this particular section.
<igc> I feel it needs to come early in the manual so I haven't explained any bzr commands yet, just the high level concepts
<igc> getting the point across without going into details of bzr (let alone hg and git) is ... tricky to say the least
<cbarrett> How do bzr revision numbers and cherry picking work?
<igc> I'll take a fresh look at the wording and see what I can tweak
<igc> time to fix the fastimport out of memory issue now though
<cbarrett> My branch's tip: 100.1.3. Mainline tip: 200. I want: 150. So, 150 becomes 100.1.4. What happens when I merge back?
<lifeless> abentley: how big a memory buffer did you find good for iter_file_byutes?
<igc> cbarrett: as it happens, I'm in the process of trying to explain that in a patch I'm putting up to the User Guide
<cbarrett> igc: Interesting :)
<abentley> lifeless: 1M  seemed to work nicely.
<igc> cbarrett: we're just decided my explanation isn't good enough though :-)
<cbarrett> :)
<poolie> hm on reflection having the assertion patch finished and not merging it seems wasteful
<cbarrett> Another question is what happens if: Alice Bob Carol & Dave all branch from 100. Alice merges Bob, creating 100.1.x in her repository. Dave merges Carol, creating 100.1.x in his repository. What happens if Alice tries to merge with Dave?
<igc> cbarrett: here's my proposed text fwiw: http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html#bazaar-zen
<igc> cbarrett: it's still a work in progress but hopefully it helps answer your questions
<igc> let me know either way
<cbarrett> igc: Thanks.
<cbarrett> igc: I don't think it answers my question.
<cbarrett> My second one anyway.
<cbarrett> And it doesn't seem to talk about cherry picking (taking a revision out of context of its ancestors and children)
<cbarrett> It is definitely a good idea and an improvement over the old bzr numbering scheme.
<igc> cbarrett: cherrypicks aren't currently tracked in bzr
<cbarrett> igc: Ahh, that's unfortunate -- it's a really common operation for a lot of folks.
<igc> you can *do* them - they just aren't recorded (so you'll get more merge conflicts than you ideally would)
<cbarrett> Just like using svn (bleh)
<igc> cbarrett: so extending my example in 2.7.4, Alice merging Dave will show ...
<igc> Carol's changes are 100.2.x
<igc> Dave's changes as 100.3.x
<igc> or perhaps vice versa depending on whether Dave did anything before merging from Carol
<cbarrett> Hmm, I see.
<cbarrett> igc: So what happens Dave merges with Alice later?
<igc> I'd expect Alice's changes to be numbered 100.x.y in Dave's branch ...
<igc> the key point is that the numbering is local to each branch and ...
<cbarrett> So she would see her own revisions numbered as 100.x.y?
<cbarrett> Oh, interesting.
<igc> they all start with 100 because they all originally branch from that revision
<cbarrett> right
<cbarrett> There's a global revID though right?
<cbarrett> Some SHA-1 hash of some sort?
<igc> yes - it doesn't change
<bob2> uuid rather than a hash
<igc> revision-ids are global
<igc> revision-numbers are local per branch
<bob2> and not stable
<LaserJock> sorry, I've been watching. so how do people refer to each other's revisions? do they say "100.x.y in Alice's branch"?
<cbarrett> Seems like it could get annoying to figure out from "Well, the bug is in r67 in my branch" which revision that is in YOUR history, so you can go back in time. I guess you'd need to send the UUID in that case.
<igc> they're stable across branches in a limited way
<cbarrett> Or worse, "the bug is in 67.5.2338 in my branch"
<cbarrett> Oi.
<bob2> LaserJock: in practice it seems people usually refer to branches or mainline revisions
<igc> yes, as http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html#bazaar-zen explains, revision numbers need to be given in the context of a branch
<igc> if no branch is given, developers typically mean "the trunk"
<bob2> they're not even stable in a branch
<cbarrett> One thing that I like about mercurial is that it isn't hard to give the short hash of a revision if you need to "6ab6a519692d" is not that many characters, and while it isn't pretty to look at, it's easy to figure out where that is in your own history.
<cbarrett> but I'm intrigued by the dotted notation.
 * cbarrett ponders
<spiv> Mostly I don't even use the dotted revnos.
<spiv> A lot of the time I'm only really interested in the mainline of a branch.
 * cbarrett nodes
<cbarrett> *nods
<spiv> It depends on why you want to know, of course.
<lifeless> abentley: thanks; did you profile over sftp or anything like that?
<abentley> lifeless: no, that was based on local testing.
<igc> cbarrett: following on from spiv's comment, I never say "the bug is in 67.x.y of my branch"
<abentley> Actually, 100 K seemed fine for local, but I multiplied it for remote.
<lifeless> abentley: cool
<cbarrett> igc: Ah, you'd say "the bug in 78 of steve's branch"
<lifeless> abentley: I'm going to implement get_text(key) as self.get_record_stream([key], 'unordered', delta_closure=True).next().get_bytes_as('fulltext')
<igc> from the view of my branch, the interesting point is when I merged steve's branch and got the 67.x.y. revision as a result
<lifeless> abentley: to avoid needing multiple code paths to extract texts
<igc> that might be version 80 of my branch say
<cbarrett> igc: Ah, interesting.
<cbarrett> So you kind of collapse history there a bit.
<igc> Now, if I merged the trunk ...
<lifeless> note that hg has teh same thing with its revnos
<igc> I might be seeing a bug in 67.x.y. as a result
<lifeless> its linear numbers are *only* valid in a single repository
<cbarrett> lifeless: *nod*
<cbarrett> A little simpler.
<igc> but for external communication, that version 75 (say) of the trunk
<igc> and I'd find that easily by running log --short' on my trunk mirror and matching on the commit message (if not the revision-id)
<lifeless> cbarrett: I'm not sure its simpler - its quite possible to have revno X in a hg repository not be present in a given branch
<lifeless> I've seen that cause frequent confusion in #hg :)
<cbarrett> Hm?
<lifeless> cbarrett: hg's revno's are the index in the revision revlog
<cbarrett> Right.
 * cbarrett is familiar with mercurial
<lifeless> cbarrett: multiple branches can share a revlog though various means
<cbarrett> Right.
<lifeless> cbarrett: if you have two heads, then there is at least 1 revision which is reachable from head A and not from head B
<cbarrett> By definition, yes.
<lifeless> cbarrett: (trivially - B is not reachable from A or it wouldn't be a head :))
<lifeless> so if A has revno 100
<lifeless> and B has revno 80
<lifeless> revno 80 isn'tpart of branch A
<cbarrett> Yes.
<LaserJock> lifeless: btw, I found an interesting blog post from 2006 doing some performance comparisions between git and bzr on the linux tree (http://blog.jozilla.net/2006/03/03/bzr-versus-git/)
<LaserJock> lifeless: so last night I duplicated it but with present versions of git and bzr
<lifeless> this is confusing for people that don't know the implementation details - what a revlog is and broadly what it does and how revisions are managed
<LaserJock> gave some interesting results
<cbarrett> lifeless: *nod*
<cbarrett> lifeless: Usually when I want to tell someone about a revision and they're not using my repository, I use a hash.
<lifeless> cbarrett: I was challenging that hg's revnos are simpler, because to me, when you have to know implemetnation details that far down the stack, there is something funky going on.
<lifeless> LaserJock: oh?
<cbarrett> lifeless: I don't see them as something to share with others though
<cbarrett> just a shortcut to refer to things in that repo
<cbarrett> but I might be wrong about intent
 * cbarrett is not mpm
<cbarrett> :P
<lifeless> well, clearly they aren't sharable; because they are not reproducible without physical access to the repo
<LaserJock> lifeless: I guess I'll probably blog it since that's the thing to do
<LaserJock> lifeless: but bzr has gotten a lot better
<lifeless> good :)
<LaserJock> *but* bzr diff got a whole lot slower in comparision
<LaserJock> or rather git-diff got a ton faster
<LaserJock> in the original one bzr diff was roughly twice as fast as git
<LaserJock> but in mine git was about twice as fast as bzr
<lifeless> damn!
<LaserJock> but the areas where bzr was waaaaay slower it's now pretty reasonable
<LaserJock> bzr diff on an unchanged tree was dramatic
<LaserJock> anyway, it was an interesting experiment
<LaserJock> doing a commit after a minor change has improved significantly
<LaserJock> took this other guy over 2min. to do a commit
<LaserJock> for me it only took 9s
<Odd_Bloke> poolie: I probably wouldn't use forums, I'd forget even if I intended to.  It seems to me that this is the sort of thing that Launchpad should cater for (given that we as a Free Software Project want it or something like it).
<mneptok> cbarrett!
<mneptok> holycrap
<cbarrett> mneptok: Ahoy there.
<cbarrett> What's new, Peggy Sue?
<mneptok> 'allo sah. how goes?
<cbarrett> Pretty good. Still in the Bay Area. No longer at Moz, though.
<mneptok> poking at d/vcs'eseses again? :)
<cbarrett> Doing contracting (currently working on iPhone stuff)
<cbarrett> mneptok: Yup.
<mneptok> ok, nosy time. /m
<Verterok> moin
<Odd_Bloke> Verterok: Morning.  What timezone are you in ATM?
<Verterok> Odd_Bloke: Hi, GMT-3
<Verterok> Odd_Bloke: 2:15 here, and heading to bed
<Odd_Bloke> Verterok: Fair enough.
<Odd_Bloke> 6:15 here and I should have head to bed. Â¬.Â¬
<Verterok> Odd_Bloke: indeed (but depends on your plans for the day) :)
<Odd_Bloke> Well, I have a deadline at noon, but then got distracted by the baseball.  And now I'm kinda too tired to risk doing any work. :p
<Verterok> Ouh, deadlines! :P
<poolie> Odd_Bloke: so there's a kind of chicken and egg project
<poolie> if projects want forums, lp ought to provide them
 * Verterok reading this Â¿new? DVCS comparsion: http://www.infoq.com/articles/dvcs-guide
<Odd_Bloke> I didn't strictly mean forums, but a solution to the class of problems that forums are designed to solve.  I unhelpfully have no useful ideas on what that might look like, but I think that Questions could be it with some tweaking...
<poolie> Questions is pretty close to it
<Odd_Bloke> I also wonder if there's a better way of keeping the mailing list and the (bug tracker|Questions) better sync'd, which would reduce the need for _another_ 'easier' forum for users to ask questions.
<Odd_Bloke> Also, to continue spewing out ideas, a forum-esque frontend onto the mailing list might disguise it enough to make people feel comfortable.
<Odd_Bloke> Sort of like what Gmane does, but themed and closer to a forum. :p
<poolie> yeah, all those things would be interestig
<poolie> hopefully some of them will even exist in the future
<Odd_Bloke> :D
<poolie> lp integration of teams and lists is meant to be just a start
<poolie> i think BB is really interesting in the way it fuses mail and web interfaces too
<poolie> spiv: ping
<spiv> poolie: pong
<poolie> spiv, i'm trying to pull your loom and get bzr: ERROR: The revision andrew.bennetts@canonical.com-20080508013609-jk12992zhs18nlp0 is not recorded in the loom LoomBranch('http://people.ubuntu.com/%7Eandrew/bzr/protocol-v3-loom/').
<spiv> Hmm.
 * spiv makes sure he has the latest loom plugin and that the loom is recorded
<spiv> poolie: try now, maybe?
<spiv> poolie: I can push the current tip to a non-loom if necessary
<poolie> trying
<poolie> got it
<poolie> that was odd
<poolie> and is that branch current with your work?
<spiv> Some combination of upgrading my loom plugin, running "bzr record" and doing another push must have sorted it out.
<spiv> Yep.
<poolie> spiv, i'm going to read through the overall diff from trunk
<poolie> should i give feedback here or in mail?
<poolie> or maybe i should just send an update patch
<spiv> poolie: mail is probably best, on the assumption that with a diff that large you're sure to have a non-trivial number of comments :)
<poolie> i see RemoteBzrDirFormat.probe_
<poolie> * probe_transport
<poolie> is still doing protocol_version, we're going to remove that right?
<spiv> Right.
<poolie> kk
<spiv> Although we'll still need it for HTTP.
<poolie> i was just going to say that!
<spiv> (Because HTTP transports are only sometimes smart, RemoteBzrDirFormat needs to actually try an RPC to find out if smart is possible for any given HTTP transport)
<spiv> I have some changes almost ready to commit to that implement that.
<spiv> I'm just chasing a regression I just found interactively :)
<poolie> spiv: how were you going to handle it?
<spiv> poolie: add a 'should_probe' method to SmartClientMedium.  It'll return False, except for the HTTP implementation.
<spiv> probe_transport will use that to decide if it should do the current logic (issue a test RPC) or just assume smart is ok.
<poolie> ok
<poolie> hm, maybe that code should be inside get_smart_medium, or something called on the medium?
<spiv> Hm, maybe.
<poolie> rather than just exposing a boolean that means "call me back to check" why not just have a method that does the check if necessary?
<poolie> just an idea
<spiv> There's some overlap with what we've made _SmartClient responsible for too.
<spiv> Keep in mind that the check itself is cached, though.
<spiv> i.e. medium.protocol_version(); medium.protocol_version() already issues just one RPC.
<poolie> i don't have a strong opinino
<poolie> it just seems this is not really the job of BzrDir
<spiv> So the practical difference would be fairly small at the moment.
<spiv> I agree there's something here that needs cleaning up.
<spiv> There's also a bit of tension bugging me in that everything shares the medium, but I think perhaps we want things to share the _SmartClient instead.
<spiv> But I'm pretty comfortable that tidying that up is a lower priority than other work.
<poolie> ok
<poolie> i found one bug we should fix before merging
<poolie> there may be a few occurences
<poolie> will send mail soon
<spiv> Excellent.
<poolie> btw does a bare 'raise' preserve the original stack in the exception?
<poolie> i think it does
<spiv> It does.
<poolie> this is a big diff!
<spiv> Yeah :/
<poolie> this MessageHandler is nice
<poolie> spiv, i thought we were going to allow requests to have streamed body too
<poolie> i guess i don't understand why ConvRequestHandler is different to ConvResponseHandler
<spiv> Partly it's different because they have a different interface.
<spiv> A request handler has no use for read_response_tuple, for instance.
<poolie> right, i can see the client needs to call into the response handler
<poolie> but isn't the protocol symmetrical?
<spiv> There's nothing about ConventionalRequestHandler that disallows streamed bodies.
<spiv> It just doesn't support them, if you see what I mean.
<poolie> if it gets a streamed body, won't bytes_part_received be called multiple times?
<spiv> When we decide to write a request that wants a streamed body, we can either extend ConvRequestHandler to cope with that, or make it a different type of request.
<spiv> Right.
<spiv> I've been a bit indecisive about what to do on this part, I'm happy to make this more symmetrical with ConvResponseHandler.
<poolie> so it seems like if you send a streamed request to a server running this version of the code
<spiv> An earlier revision of this code had an XXX in ConvRequestHandler.bytes_received_part about this.
<poolie> it will break, because it assume the body finishes after the first part
<spiv> Well, it will break anyway.
<spiv> Because the server won't know the verb :)
<poolie> but what if we want to make a currently active verb stream?
<spiv> (But the server will still be able to consume the entire request so that it can read the next one)
<poolie> s/active/supported
<spiv> I don't think that's a good idea.
<poolie> or, for example, make everything stream
<spiv> I think we should just make a new verb for that.
<poolie> that might be a good idea in practice
<spiv> (semantically, I see a streamed body as being a series of chunks, rather than just as a single string that is delivered more efficiently)
<poolie> i guess i was hoping that when we landed this, we would have all the mechanisms supported on both ends
<poolie> so that in future we would only need to think about whether particular verbs are supported
<spiv> Well, the important mechanisms are; the ones that allow graceful fallback.
<spiv> I'm looking forward to filling in this little gap in the puzzle.  If you have a strong opinion about what should go there, I'm happy to do that :)
<poolie> i think i see a small change for it
<poolie> hm only 20% through...
<lifeless> poolie: its not really symmetrical though, in that while we can decide to send less data we can't decide to recieve less data (without dropping the connection)
<poolie> well, sure, not symmetrical in the way it's used but in structure
<lifeless> later all
<poolie> night
<poolie> have a good trip!
<poolie> spiv, comments on the first 1/3rd sent
 * igc dinner
<vila> hi all
<james_w> Bonjour vila
<vila> lifeless, poolie : pqm is refusing my submission saying "Sender not authorised to commit", could that be related to my launchpad id change ?
<vila> james_w: hi !
<Le-Chuck_ITA> Hi there
<Le-Chuck_ITA> there's one thing I can't grasp of bzr
<Le-Chuck_ITA> can it host two branches efficiently in the same directory/local repository/local branch whatsoever?
<vila> jam: ping, any idea about the next episode in my pqm submissions :) ?
<titusg> hi, how do I pull a particular revision number?
<titusg> what I want to do is revert a file to the version from a different revision, and I don't know how...
<james_w> titusg: "bzr pull -r revno"
<james_w> titusg: ah, that sounds like you want revert
<james_w> "bzr revert -r revno filename"
<titusg> james_w: thankyou!
<LeoNerd> Hrm.. it's annoying how bzr picks a file ID based on the filename... I want to rename a file, but I don't like the unneatness in my head that would cause :P
<vila> jam, poolie lifeless : sorry for the noise, it appears I can't submit for http://bazaar-vcs.org/bzr/bzr.dev/ , but if I delete the trailing '/' all is fine. I added it myself while hand-editing the branch.conf file, so no need to search for a bug there ;-)
<awilkins> jelmer: Is there a branch of bzr-svn that works with 1.4 yet?
<jelmer> awilkins: the 0.4 one does
<awilkins> jelmer: I'll speak to you tomorrow ; train time
<ignas> hi, how do I make an existing shared repo have --no-trees set?
<LeoNerd> touch .bzr/repository/no-working-trees
<LeoNerd> Seems to be a 0byte file I have present in mine
<ignas> LeoNerd: thanks
<Vantage> hi.  Somewhat off topic question.  What was used to make the diagrams in http://bazaar-vcs.org/Workflows ?
<james_w> Vantage: hi, I think that was igc's work.
<Vantage> james_w: any idea what program/icon set was used?
<james_w> nope, sorry.
<igc> Vantage, james_w: the workflow diagrams were borrowed and tweaked from http://gigo-ice.org/scm/bazaar/index.html with permission
<igc> there's a contact email address on that web site if you have any questions about the details
<lifeless> morning igc
<lifeless> sick child?
<igc> morning lifeless
<igc> kids are good but wife working today so I'm squeezing in email before breakfast/morning-rush
<igc> which starts about now ...
<fullermd> Wanna borrow my bullwhip?
<igc> fullermd: can it make breakfast and lunches?
<igc> time to go - bbl
#bzr 2008-05-09
<igc> morning
<jam> morning igc
<jam> lifeless: you're going to make the bzr.1.5 branch today, right?
<lifeless> http://laserjock.wordpress.com/2008/05/08/git-and-bzr-historical-performance-comparison/
<mlh> found it  .. http://svn.blastwave.org/trac
<mlh> oops
 * igc food
<lamalex> Hi everyone, how do I commit only a single file so that bzr send will generate a patch for only 1 file
<lifeless> bzr commit FILENAME
<lamalex> bzr: ERROR: Selected-file commit of merges is not supported yet: files Do.Addins/src/Do.Universe/ApplicationItem.c
<RAOF> lamalex: Yup, this was where I was about to suggest ;)
<lifeless> this smeans you have done a merge, but not committed the result
<lamalex> so solution?
<lamalex> commit
<lamalex> :P
<RAOF> The shelf plugin can be your friend here.
<lifeless> do the commit
<lifeless> if the branch you are merging is your upstream send won't include changes from the upstream in the sent content anyway
<lamalex> thanks guys
<lamalex> oh jeeze! So I did a commit on just the one file after, and bzr send still generated a patch for /all/ changed files
<lamalex> any idea how to only generate the patch for the 1 file?
<jamesh> "bzr diff" will give you a diff for one file
<jamesh> but if you want "bzr send" to give you a bundle for one file, then the bundled revisions need to have changed just the one file
<jamesh> (relative to the submission branch)
<lamalex> so I'm SOL for bzr send, and should just diff it
<lamalex> and advantage of using bzr diff over gnu diff?
<jamesh> well, you can always prepare the change in a new branch
<lamalex> ignore my previous question
<lifeless> lamalex: bzr send -r x..y will probably do what you want
<lifeless> lamalex: it sounds like you want to send in one commit, not all of your work
<lamalex> yeah
<lifeless> lamalex: this is the usual confusion that I have seen
<lamalex> I've had the problem a few times :P
<lamalex> I always forget how to do it
<lamalex> wrote it down this time
<lifeless> lamalex: the name for doing this, irrespective of transport (branch/bundle/patch) is 'cherrypicking'
<lamalex> thanks
<lamalex> lifeless: still no luck, I'll just do a diff
<jsled> lamalex: What's wrong with `bzr diff path/to/file`?
<lamalex> I was under the impression that bundles were better
<jsled> nevermind; didn't read enough scrollback.
<lamalex> :)
<lifeless> lamalex: you probably have more than just one file changed; or are nto using the correct arguments - the list had a good discussion about bzr send just this week
<lamalex> I'll check it out, thanks for your help
<lifeless> I'm happy to debug futher if you like; remember though that send's finest granularity is a single commit
<lamalex> I have to go to bed soon, I have a sociology final in the morning
<lifeless> go then !
<lamalex> :) I've still got 9 hours!
<lamalex> well, I guess 6:30 of sleep, but that's plenty. Thanks for the help.
<ferringb> curious, for a bzr-svn branch, is there way to effectively convert that into a standalone bzr branch- specifically, converting it to a knit repository?
<lifeless> bzr-svn branches are native bzr branches
<lifeless> bzr info will tell yo the current format
<ferringb> lifeless: branched from the svn branch to a "Standalone tree (format: rich-root)"
<ferringb> from there, trying to branch from the standalone into a shared repository (pack-0.92), but getting no love; error msg is essentially "knit pack repository is not compatible with knit repository"
<ferringb> so... something there isn't right. :)
<ferringb> (attempts to upgrade the svn branch fail also)
<Peng> You can't go from a rich-root format (rich-root, rich-root-pack) to a non-rich-root format like pack-0.92.
<Peng> If you want to upgrade to packs, "bzr upgrade --rich-root-pack".
<ferringb> bingo
<ferringb> Peng: that's working for the svn branch; from there, probably will fly for pulling it into my shared repo
<ferringb> what is a 'rich root pack' anyways?  just a new format, or
<Peng> ferringb: rich-root-pack is like pack-0.92, only it has rich roots, meaning it stores slightly more meta data.
<Peng> ferringb: rich-root is like dirstate-tags, only it has rich roots.
<lifeless> ferringb: as peng says, rich-root stores more data; you can't go back to a plain repo from there
<lifeless> ferringb: we will very shortly (probably 1.6 I think) be making rich root our default format
<lifeless> abentley: around ?
<abentley> lifeless: Hi.
<lifeless> any chance of a brief skype call?
<abentley> Sure.  I'm just finishing up something with thumper.
<lifeless> 5 minutes?
<abentley> Sure.
<abentley> I couldn't hear you.
<lifeless> k, thats my work day done; later all
<lifeless> thanks abentley
<abentley> lifeless: np
<jamesh> the "if self.new_inventory_root is None" branch in CommitBuilder.finish_inventory() (bzrlib/repository.py) looks broken
<jamesh> AssertionError doesn't take a "stacklevel" keyword argument
<docgnome> I'm running bzr 1.4 under cygwin. Every time I try to do a checkout it spits back bzr: ERROR: [Errno 0] Error
<docgnome> any ideas?
<Peng> docgnome: You could pastebin the traceback and .bzr.log section. But I dunno how much the developers care about supporting Cygwin.
<Le-Chuck_ITA> Hi there, I don't understand one thing of bzr: is it possible to manage more than one branch in the same local repository?
<Le-Chuck_ITA> or should I always copy the current directory to a new one?
<igc> night all - have a good weekend
<ignas> hi
<ignas> anyone has any ideas why i could be getting "bzr: ERROR: exceptions.AssertionError: 2412 != 2413" ?
<ignas> when trying to commit
<ignas> "assert len(history) == revno, '%d != %d' % (len(history), revno)" to be more accurate
<Peng> ignas: Your revnos are a little off. There's info on either the mailing list or bug tracker, if you can find it.
<ignas> is it fixable?
<Peng> ignas: Yes, but I don't remember the details.
<ignas> emm i don't think the fix is in hardy though :/
<ignas> the "production ready" part of bzr is sometimes giving me doubts...
<ignas> bzr check is stuck in [                                                             ] checking versionedfile     0/12726 for like 30 minutes
<ignas> should i be worried?
<jam> vila: your patches are going to the wrong mailing list
<vila> huh ?
<jam> vila: you are sending to "bazaar-commits@" not "bazaar@"
<vila> aaargh
<jam> your merge requests
<vila> thanks for the heads-up :)
<vila> hmmm, on another project I took the habit to use 'bzr send', get bitten there :)
<vila> 'bzr send' with no params I meant
<jam> vila: well, send should do the right thing, but you have to set your 'mail_to'
<jam> as opposed to you "post_commit_to"
<vila> only post_commit_to seems to be defined...
<vila> hehe, no, submit_to was defined (with a wrong value), and it's really submit_to, not mail_to
<jam> spiv: are you still around?
<jam> vila: anything you want to try to sneak into the 1.5rc1 release today?
<vila> --starting-with ftw :)
<vila> bug fixes can wait next week isn't it ?
<spiv> jam: not really ;)
<spiv> jam: I think my big patch should miss 1.5
<jam> spiv: k, I was checking in
<jam> I would have liked to have it
<jam> but it seemed a bit large for a last-day approval
<jam> anything else in the queue?
<spiv> jam: happy releasing!
 * spiv -> sleep
<vila> spiv: good night
<jam> igc: ping, for great justice, and things you want in 1.5rc1
<jam> poolie: I know you're not here, but just in case
<jam> lifeless: Anything you need me to merge for 1.5rc1?
<james_w> jam: thanks for the weekly report, I think it's a good thing to have.
<jam> james_w: well, thank statik as it was his idea, but I agree that it is a good one
<james_w> statik: thanks!
<jam> vila: this is 1.5rc1, so not really
<jam> vila: we forgot todo a feature freeze bugfix release
<statik> james_w: glad you liked it!
<jam> vila: martin is wanting to get back on schedule, rather than having them all keep slipping
<igc> hi jam
<jam> igc: you know, I'm always shocked to see you guys awake and online at this time
<igc> me too :-)
<statik> jam: igc is an unstoppable code machine, he only closes his eyes to make everyone else feel normal
<cody-somerville> :)
<igc> statik: just finished watching a movie actually ...
<vila> jam: good, I'm always bad at sync with the releases schedule anyway :) My remark still stands, I'd be happy to have --starting-with (really only the doc tweak requested by martin needs review), the bug fixes I'm issuing today are not urgent, if you don't have the time to handle them, no worries
<igc> and checking on the Out Of Memory bug that has me intrigued
<jam> igc: the change you made in fast-import is because it isn't double-buffering
<jam> Maybe also the lines variable isn't getting GC correctly
<jam> but doing line.append().... ''.join() has to allocate 2x memory
<jam> now, line += '' has to re-allocate as well
<jam> but IIRC, CPython is able to re-use the memory (using realloc instead of a new malloc/free)
<jam> but that is a "don't expect this to always work" feature of CPython
<vila> igc: you're coding while watching a movie ! Wow, I'm impressed :)
<spiv> StringIO is arguably more likely to use memory better than +=
<igc> vila: nah - movie over 30 minutes ago
<jam> igc: Though I'm mostly guessing, anyway anything pressing for 1.5rc1?
<vila> and spiv talks while sleeping, those australian guys....
<jam> I can take a look at your doc patches
<spiv> Probably even better is probably not combining string objects at all.
<jam> while we *can* bring them in later, I'd really like to respect the spirit of a "release candidate"
<igc> jam: np. I'd really like the plugins+integration doc patch in if it's ok
<jam> igc: reviewing now
<igc> the other one is getting closer ...
<igc> I'll see if it's worth resending it tonight (or not)
<jam> igc: does the "part2_intro.txt" belong in the "A brief tour" chapter?
<igc> jam: yes
<jam> It seems like you are starting a whole new chapter/book/etc and that paragraph is "above" that section
<igc> jam: if we split the chapters into parts, that would be true
<igc> we don't have partsa so it's at the start of the first chapter in that part
<igc> in the current guide, similar text intros "Best practices" fwiw
<jam> igc: overall bb:approve
<jam> igc: can you get it sent in now, so it is queued up for me?
<igc> jam: cool, thanks
<igc> sure
<vila> jam: I sent 3 patches, you catch up on the second one (but the third was already send), I re-send the three to the right address
<jam> I saw a couple of them come in, reviewing now
<vila> jam: thks
<ignas> hmm, if I have a checkout from a remote bzr shared repository, and run bzr reconcile in the checkout
<ignas> will that fix - my local checkout, the revisions from that branch in the remote repository, the whole remote repository?
<davidge> hi all
<ignas> hi
<jam> vila: reviews are in
<vila> jam: thks, what about --starting-with then ;-)
<davidge> what should i do to convert my dir-with-subtree repository to a non subtree one? the only format i can convert without errors is pack-0.92-subtree
<jam> vila: can I get a --starting-without ?
<ignas> jam: are you the same person who worked on https://bugs.launchpad.net/bzr/+bug/177855 ?
<ubottu> Launchpad bug 177855 in bzr "assertionerror trips on pull --overwrite in dirstate branch with non-canonical history" [High,Fix committed]
<jam> ignas: I am, though today is release day, so I might not have a lot of time
<jam> ignas: "reconcile" fixes the local repository
<ignas> jam: how do i fix the remote one then?
<jam> ignas: bzr reconcile sftp://url/to/repository
<jam> though I might recommend
<jam> ssh host
<jam> bzr reconcile /repository
<vila> jam: If there is a joke, I miss it 8-/
<ignas> i think the fix is not in ubuntu yet
<ignas> or is it?
<jam> vila: you added --starting-with, I'm asking for -without
<jam> ignas: bug #177855 is not in ubuntu yet
<ubottu> Launchpad bug 177855 in bzr "assertionerror trips on pull --overwrite in dirstate branch with non-canonical history" [High,Fix committed] https://launchpad.net/bugs/177855
<jam> well, the fix
<vila> what will that means ?
<jam> ignas: I think it is in bzr.dev, and if so, it will be in 1.5rc1 which I am releasing today
<ignas> if it's not then I would have to get a bzr checkout working on the remote server somehow, then run it there and take care so it would not mess up permissions on the central repository ...
<ignas> jam: i see
<jam> vila: I have no idea, it is just the "opposite" of whatever you were trying to do
<ignas> jam: thanks for fixing it
<vila> jam: ha ! A joke then ;-) Sorry, a bit slow today
<jam> vila: well, it wasn't a very good joke, either
<fullermd> A good joke needs puns, and dancing sheep.
<jam> vila: could you make it --starting-without-dancing-sheep then?
<fullermd> Yeah.  They're better when they don't come in 'till the second act.
<jam> vila: so you didn't do the 'auto-prefix' right?
<vila> no, I think defining aliases is my prefered solution, we could add an auto-prefix for 'bzrlib.' later, I' always very cautious when it comes to UI tweaks a-priori ;-)
<jam> vila: I don't think you can do it with an alias, just because it won't stack
<jam> but yeah, I'm okay with bringing this in first
<jam> as I think it is something we can add later
<jam> I was also thinking something like
<jam> bzr selftest -s B.T.aoeuaoeu
<jam> and have B.T always expand to bzrlib.tests
<jam> and maybe B.P to bzrlib.plugins, etc
<jam> but that is for discussion
<jam> certainly not for your review right now
<vila> jam: exactly, you just came up with someting better than a raw bzrlib. , let's get more people playing a bit and I'm sure a better scheme will emerge
<vila> another idea was to find a way to enable some completion mechanisms for shell users
<jam> vila: autocomplete seems hard to do, since you would need to load the tests to figure out how to complete them
<jam> though I guess if you had bzrlib.tests/plugins/etc autocomplete it might be a start
<vila> jam: *I* will settle for something updated one a day...
<vila> s/one/once/
<jam> vila: ahh, but how do you handle that I have 20 different branches with different tests available?
<jam> B.T works fine for me :)
<jam> I don't have tab completion for bzr turned on yet anyway
<vila> jam: I just ignore the differences between the 20 branches, that why I said '*I*'ll settle for a good enough solution', but the truth is that, as an emacs user, I already have some completion available ;-)
<vila> and my experience is that in most of the cases I will use the option for some test that has failed and for which the ID is one copy/paste away...
<igc> jam: "Zen" User Guide patch updated and sent to the list
<jam> vila: I would tend to run "--starts-with bzrlib.tests.test_module_I_am_working_on"
<igc> jam: I'm off to sleep so please merge it if you think it's now worthy of being approved.
<igc> night all
<jam> igc: well, robert and I seem to be debating
<jam> so I'll look at it
<jam> but won't guarantee anything
<jam> I'm pretty loose about merging docs, though
<jam> something better than nothing, and all
<igc> jam: sure. What I meant was, if you think robert would no longer think it was confusing
<jam> igc: I'll try to channel my inner lifeless
<jam> vila: do you have your patches sent to the PQM ?
<jam> I don't see them showing up
<jam> and I have to wait for them to get in before I can finish working on 1.5rc1
<fullermd> jam: Is bug 211661 still likely to be handled for 1.5?
<ubottu> Launchpad bug 211661 in bzr "bzr.dev smart client fails on log" [Critical,Confirmed] https://launchpad.net/bugs/211661
<vila> jam: hold on a sec, I'm working on sending them
<jam> fullermd: it works for me
<jam> fullermd: You can still see it failing?
<fullermd> Yah.  Logging my local bzr.dev over bzr+ssh://localhost/ still dies every time.
<fullermd> (with system-wide 1.4 or local bzr.dev, any combo client/server)
<jam> fullermd: it works with "--short"
<jam> that was my problem
<jam> --long fails
<jam> ugh
<fullermd> Hm.
<fullermd> Well, --short fails too, in a different way.
<jam> fullermd: can you confirm on your side?
<fullermd> ObjectNotLocked: KnitPackRepository('bzr+ssh://localhost/home/fullermd/src/bzr/.bzr/repository/') is not locked
<jam> fullermd: do you have a weird plugin installed?
<fullermd> bzrtools, gtk, heads, cvsps.
<fullermd> (well, and lp of course)
<jam> fullermd: try '--no-plugins' and '--no-aliases'
<jam> fullermd: ahh, you know what, my public bzr.dev repo is knits
<jam> which don't give that error
<fullermd> % env BZR_REMOTE_PATH="dbzr --no-plugins --no-aliases" dbzr --no-plugins --no-aliases log --short bzr+ssh://localhost/home/fullermd/src/bzr/bzr.dev/
<fullermd> Password:
<fullermd> bzr: ERROR: bzrlib.errors.ObjectNotLocked: KnitPackRepository('bzr+ssh://localhost/home/fullermd/src/bzr/.bzr/repository/') is not locked
<jam> fullermd: unfortunately, I don't know if anyone would be around to review a patch for 1.5rc1
<jam> but maybe a 1.5rc2 or something
<jam> I'll check into it for a bit
<fullermd> Oh, well.  It's been around a month or so; a few days won't hurt more.
<fullermd> Just making sure it's at least on a list somewhere   :)
<jam> fullermd: confirmed both ways
<jam> The ObjectNotLocked
<jam> and the ValueError
<fullermd> Well, as long as you're safe from being bored, my work here is done   ;>
<jam> fullermd: I seem to be missing the patch in my bzr.dev
<jam> weird
<jam> fullermd: what do you see in log.py line 526
<jam> I think there might be something wrong with the merge back into bzr.dev
<jam> because of how we handled the transaction cache stuff
<fullermd>         graph.iter_ancestry(mainline_revs) if value is not None))
<jam> basically, we wanted to pull most of the 1.4 branch back in, but not that patch
<jam> fullermd: yeah, that should be 'mainline_revs[1:]'
<jam> according to my patch
<fullermd> I have that in 515
<fullermd> (on)
<jam> fullermd: you need it in *both*
<jam> 515 is --short
<jam> 526 is --long
<fullermd> Ah, but that sets revision_ids, which is used....
<jam> fullermd: and then returns right away
<fullermd> ...  ah, IC.
<jam> fullermd: so does the bzr 1.4 client work for you?
<fullermd> One sec, testing that sub.  Server is spinning, but hasn't output anything yet.
<fullermd> Mmph.  Passing a minute of CPU time with no output yet...   I guess it's working, but wow that needs some work...
<jam> fullermd: hmm.. I don't see it in 1.4 either
<jam> fullermd: you can do "bzr log --long -r ..10"
<jam> so it doesn't have to do the whole thing
<fullermd> 2 minutes...
<fullermd> Now I just gotta wait it out and see how long it takes to say anything...
<jam> fullermd: ok, this is weird
<jam> I see the patch show up in 3360.1.7
<jam> but the final merge 3363 doesn't have it
<jam> fullermd: ahhhhhh..... different code paths
<jam> there is one at 526
<jam> and another one at 467
<fullermd> OK, up to 4.5 minutes of CPU time...  the client-side python process is finally starting to eat some CPU, but still no output   :|
<jam> The fix that made it in only fixed 467
<fullermd> 'k, screw it.  6 minutes of CPU burned with no output is Too Damn Long.
 * fullermd kills it.
<fullermd> --limit 10 passed a minute before I killed it...
<jam> fullermd: it is important to log the first revision
<jam> --limit 10 might not
<fullermd> On bzr.dev it won't   :p
<jam> fullermd: which is why I recommend -r ..10
<fullermd> Grabbing ..10 worked, and fairly fast.  But there weren't any merges that early in the history, so...
<jam> just to log the first 10
<fullermd> Now I'm prepping another bug report about the time issue...
<jam> fullermd: ok, in my patch I clean up all implementations to refuse to handle None
<jam> and I can see that we are still doing the wrong thing here
<jam> fullermd: if the object isn't locked at the right point
<jam> that could certainly effect performance
<fullermd> log --limit 10 locally runs in about 9 seconds.  I'm over 2 minutes of CPU time on the server doing it over bzr+ssh://localhost/ now.  So, there's sure something beating it down.
<fullermd> (not that 9 seconds is busting any records, but in comparison...)
<jam> fullermd: that is --long format, right?
<fullermd> Yah, I don't have any aliases affecting 'log'.
<jam> 'time bzr log --limit 10' is 1.3s here
<jam> well, that is --short
<jam> --no-aliases is 2.5s, though
<fullermd> You probably have a somewhat faster machine than I.
<jam> fullermd: can you do "grep -a len .bzr/repository/pack-names"
<jam> just curious
<fullermd> 8
<jam> fullermd: not terrible, then
<jam> I've had it up closer to 20
<fullermd> --short --limit 10 runs on 0.6.
<jam> vila: any chance you would feel comfortable reviewing by bug fix for 211661 ?
<fullermd> (in)
<fullermd> --line is essentially indistinguishable.  --long runs 8.5-9.
<vila> jam: I don't think so, I still have to be more familiar with the smart server :-/ And gf is has already thrown a priority interrupt currently masked while I finish sending submissions to pqm...
<vila> s/is//
<jam> vila: it isn't really smart server code
<jam> it is log.py code
<jam> the fix is pretty trivial
<jam> but I understand about priority interrupts
<jam> vila: and your second submission won't work
<jam> you have it set as "bzr+ssh:///"
<jam> vila: Merge bzr+ssh://bazaar.launchpad.net/~vila/bzr/199440-auth-ssh-user-no-pass http://bazaar-vcs.org/bzr/bzr.dev
<jam> vila: however, I'll submit something for you
<vila> jam: rats, I usually do a single submission using the same branch :-/
<fullermd> Filed bug 228740 for log speed.
<ubottu> Launchpad bug 228740 in bzr "log over smart server is *SLOW*" [Undecided,New] https://launchpad.net/bugs/228740
<fullermd> Sad.  8 seconds vs. 7.5 minutes.
<jam> vila: the other advantage of me submitting it
<jam> is that if it fails
<jam> I can resubmit, etc
<jam> while you go sleep
<jam> or GF time, whatever
<fullermd> Locking sounds like a good candidate source for the problem.
<vila> ok, that'be better, I will then tweak 183705 as per your review and let you submit then, I'm a bit worried about NEWS conflicts while doing several submissions like that
<jam> vila: just send me something I can submit
<jam> I'll try to work out NEWS
<jam> fullermd: even weirder is that show_log() calls lock_read() and then hands off to _show_log
<jam> so everything should be locked
<jam> ok, weird
<jam> branch.is_locked() == True, branch.repository.is_locked() == False
<vila> jam: fix for 183705 mergeable from http://bazaar.launchpad.net/~vila/bzr/183705-auth-doc-unclear
<jam> vila: thanks
<jam> vila:  I'm glad you have the bandwidth/latency to push stuff up to lp.net
<vila> That surely helps a lot...
<jam> vila: submitted
<jam> vila: as an aside, I prefer if you use "#BUGNUM" rather than just "NUM"
<jam> just because it makes it possible to grep for bug numbers
<vila> damn it, I wrote bug NUM ? Endless typos today :-/
<jam> though the numbers are big enough now that it is pretty unlikely to have a false positive if you are looking for a specific bug
<jam> '(vila) Fix 199440 by taking allowing no password in a section'
<jam> vila: and then I, of course, just copied your message and did the same
<fullermd> It was corrupted by being transfered over hhtps.
<vila> grr, sure, same here :-/
<vila> hehe, typed hhtp yesterday but caught it before it was too late ;)
<jam> vila: have a great weekend, by the way
<vila> gf re-raising interrupt, thanks jam, can you also submit --starting-with from http://bazaar.launchpad.net/~vila/bzr/faster-selftest/ ?
<vila> It may be a loom, but that's the last thread so it should be easy to find the relevant patch
<vila> thanks a lot for your work on 1.5rc1, all the reviews, being a good guy, have a nice week-end too, say hi to your son ;-)
<jam> vila: of course, that means I need to install looms here :)
<jam> vila: checking out "lp:~vila/bzr/faster-selftest" gives me a non-loom branch which is already merged into bzr.dev
<vila> jam: first priority handled, 5 minutes freed, you don't have looms installed ?
<vila> hmmm, I thought that branch was a checkout, it wasn't, pushing right now
<vila> ok, lp:~vila/bzr/faster-selftest should be good to merge now
<vila> jam: sorry for the mess :)
<vila> on to interrupt #2 now, this one will take longer :)
<jam> vila: nothing in NEWS?
<vila> jam: regarding --starting-with ? It should in TESTSING section
<jam> bzr diff -r ancestor:../../bzr.dev NEWS
<jam> is empty
<vila> gee, It should be in TESTING section
<jam> vila: you might have put it in another doc
<vila> ancestor on a loom branch (or son of a loom), I'm not sure it does what you think it does...
<vila> or may be push from a loom branch doesn't do what I thought it should be doing...
<vila> >-/
<vila> Ok, I forgot the 'bzr record' before pushing, re-pushing a bunch of revisions
<vila> jam: the correct revno is 3345
<jam> vila: when I branched from you, the local one is *not* loom
<vila> the remote one is not either (I think) but anyway, the current tip on that branch should now be at 3345 and ok for you to branch even without loom
<jam> vila: 3345: merge bzr.dev, fixing simple conflicts
<jam> vila: and the change is in NEWS
<jam> looks good
<vila> I really appreciated loom for that branch, but I lack the deep understanding when it comes to sharing a loom,
<jam> vila: well, AIUI there have been some bugs about pushing stuff out of a loom
<vila> yeah, I saw  a patch about that, may be I've just been lucky that bzr record allowed to push the right revisions a few minutes ago :)
<nysin> When trying to rebase, I see "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified." (this is accurate as far as bzr knows but they in fact roughly do. If necessary I can try to supply an exact analog-revision but hopefully it's not.)
<nysin> I've tried using --onto but without success - so, can one specify 'I, the user, am stating that revision X from branch Y and revision Z from branch W are the same'?
<james_w> nysin: specifying a merge base means to give a start to the range in the -r argument
<james_w> if you say "merge -r 20" it will merge in revision 20 of the other branch
<james_w> and all of it's ancestors
<james_w> if you say "merge -r 10..20" it will merge in revisions 10 to 20 of the other branch
<nysin> Hm. The error message I get from -r suggests that it's looking at the current branch
<james_w> if you say "merge -r0..-1" then it will merge the two branches, whether or not they have a common ancestor.
<davidge> Hi all
<nysin> "$ bzr rebase --dry-run -v -r1021 ../dp/" is the command but when then I see "does not exist in branch: BzrBranch6('file:///home/nysin/mod/')"
<davidge> Is there a way to convert a dir-with-subtree repository to another (no subtree) format?
<james_w> nysin: sorry, completely missed you were using rebase
<james_w> davidge: I'm not sure, it's theoretically possible to convert it to a rich-root repository if you have not used any subtree features.
<nysin> james, ah, okay.
<james_w> nysin: in that case I'm not sure what the answer is I'm afraid.
<davidge> james_w: it's a plain repository without subtree features. But in practice, all 'bzr upgrade' commands fail with an error :(
<james_w> davidge: what's the error for bzr upgrade --rich-root-pack?
<davidge> james_w: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>.  Does not support nested trees
<james_w> davidge: ok, it seems that it's not possible then.
<james_w> davidge: hopefully soon upgrading between formats in this way will become a lot smoother.
<davidge> davidge: you mean there is work in bazaar upcoming releases for that?
<davidge> james_w i mena :D
<james_w> heh
<james_w> I'm not sure it's exactly this case, but there has been a plan to make the converters much more friendly to this sort of thing.
<james_w> I'm not sure whether it's in 1.5
<davidge> james_w: i'm glad to hear that there is some of kind work for that...
<davidge> james_w: maybe i'll give a try to 1.5rc1
<jam> james_w:  the way to go from -subtree => rich-root is via 'bzr init && bzr pull'
<james_w> ah, thanks jam
<jam> it isn't *supposed* to work, but it does, and is the current workaround
<fullermd> Well, that's encouraging   :p
<james_w> jam: are you at UDS by any chance?
<davidge> jam: hmm, thanks, i'll try that...
<jam> james_w: nope
<jam> where is it this time?
<james_w> ah, shame.
<james_w> Prague.
<jam> lifeless, poolie: The PQM seems to be unhappy with me. When I do 'pqm-submit' nothing shows up on https://pqm.bazaar-vcs.org/
<jam> And I don't get an email about failure, either.
<rick_h_> anyone know how to use this now that the bug is fixed? https://bugs.edge.launchpad.net/bzr-svn/+bug/120768
<ubottu> Launchpad bug 120768 in bzr-svn "Should prompt for passwords" [Low,Fix released]
<rick_h_> I'm not seeing any docs on how to force the password on first push
<james_w> hi ricardokirkner
<james_w> hi rick_h_
<rick_h_> hey james_w
<ricardokirkner> hi james_w
<james_w> rick_h_: do you have subversion 1.5 installed?
<vadi2> Is it possible to get an output similar to "bzr log" on a web server not hosting the bzr repository? The server that is hosting has loggerhead installed, but that only gives a web interface to it.
<rick_h_> james_w: oops, got me. I assumed hardy had 1.5
<rick_h_> shoot, ok thanks
<james_w> rick_h_: nope, I don't think 1.5 is out yet.
<james_w> vadi2: bzr log will work against remote branches, is that what you want?
<jam> rick_h_: hardy has 1.3.1, IIRC
<jam> I'm putting together 1.5rc1 today
<jam> 1.4 final was just released last thursday
<vadi2> ï»¿james_w: i'm afraid the server doesn't have and can't have bzr on it
<rick_h_> james_w: well I'm just getting started with bzr and trying to demo bzr-svn for a lightning talk
<jam> It is available in the launchpad ppa
<rick_h_> I checked out a public svn repo, but wanted to demo push, which required auth
<rick_h_> hmm, dpkg -l lists 1.4.6 for svn
<rick_h_> in default hardy
<james_w> jam: svn 1.5, it has bzr 1.3.1, yes.
<jam> ah, wrong version, you are talking svn. sorry for the noise
<rick_h_> in my normal work case the branch required auth so it worked fine, but didn't want to demo with the work's stuff
<james_w> rick_h_: I believe the old way to do it was to make the svn client auth, as this was cached and bzr-svn could use it, did you try that?
<LaserJock> what do you call the .bzr/ directory? I'm trying to refer to that as opposed to the entire branch/working tree
<jam> james_w: dpkg -l lists 1.4.6dfsg1-2ub here
<james_w> vadi2: I'm not sure then, sorry.
<jam> LaserJock: the Bazaar control directory
<rick_h_> james_w: not sure how to set up the svn client to auth since there's no .svn there.
<rick_h_> it was a straight branch from the svn repo
<LaserJock> jam: would that work as a DVCS generic term?
<LaserJock> "control directory" I mean
<vadi2> ï»¿james_w: alright no problem.
<james_w> rick_h_: an "svn ls http://wherever" doesn't require authentication
<james_w> ?
<jam> LaserJock: well other ones would generally call it something different, but IMO it is still a control directory
<jam> a lot of them call it a "repository" which doesn't match Bazaar/SVN/CVS terminology
<LaserJock> I'll just use control directory, I think people will get it
<rick_h_> james_w: no, ls does not require auth.
<rick_h_> public access to pull, need perms to commit
<james_w> rick_h_: I'm not sure then, sorry. I don't know where the auth is cached, so another svn checkout to commit may do it.
<rick_h_> cool, no problem. just for a demo so no worries
<james_w> rick_h_: or if you have one lying around you could perhaps try and find the credentials.
<rick_h_> it's coming is the asnwer I can give for now
<jam> lifeless, poolie: unping, it is probably PEBKAC, I think I was leaving --dry-run on ...
<jelmer> rick_h_: hi
#bzr 2008-05-10
<rick_h_> hey jelmer
<LaserJock> lifeless: btw, I did a new linux benchmark with hg now too.
<jelmer> rick_h_: did you manage to figure out the authentication bits in bzr-svn?
<lamalex> has anyone used the bzr addin for monodevelop?
<eMxyzptlk> hey guys, is there something similar to svn:externals in bzr?
<eMxyzptlk> I've heard of it but donno if it's for real
<rick_h__> I use bzr-svn with a project with svn:externals. I just ended up checking out each external locally and ln -s to the externals dir
 * Peng branches from a server and is told that the working tree format used on the server is old.
* jam changed the topic of #bzr to: ï»¿Bazaar version control system | http://bazaar-vcs.org/ | bzr-1.5rc1, May 9 | http://irclogs.ubuntu.com
<jam> poolie: I'm having some trouble building the source packages for bzr-1.5rc1
<jam> I'm following your instructions
<jam> though I had to "apt-get install fakeroot" which wasn't mentioned
<jam> Anyway, I'll email you, but 1.5rc1 is released, but isn't uploaded to the ppa yet
<jam> man, having to create a release for each supported version is a PITA
<jam> not to mention multiplying that by the extra packages (bzrtools, etc)
<LaserJock> jam: I think the LP guys have a tool to automatically do the the changelog munging, etc. to do multiple release at once
<jam> LaserJock: not according to: http://doc.bazaar-vcs.org/bzr.dev/developers/releasing.html#publishing-the-release
<jam> anyway, I need to go to sleep now
<LaserJock> jam: I mean, I think one of the Canonical guys built a script
<beuno> jam, can I help with the packaging?
<beuno> jam, I'd happy to work it out and upload
<beuno> jam, uploading hardy now
<gabees> hello all
<gabees> is anyone able tell me why i keep getting errors like this when i try to revert single files, please?
<gabees> $ bzr revert -r 51 tasks/views.py
<gabees> bzr: ERROR: Permission denied: "/home/gabriel/studiomaker/tasks/views.py/.bzr/branch-format": [Errno 13] Permission denied: u'/home/gabriel/studiomaker/tasks/views.py/.bzr/branch-format'
<pygi> file permissions? :D
<gabees> nah not at all
<gabees> i can just do: bzr revert
<gabees> and that will revert loads of files without a problem, only if i single out a file
<gabees> see:
<gabees> r$ bzr revert
<gabees>  M  tasks/models.py
<gabees>  M  tasks/templates/task_list.html
<gabees>  M  tasks/tests.py
<gabees>  M  tasks/views.py
<gabees>  M  urls.py
<gabees> sorry, shouldn't paste here
<gabees> is that because i have version 1.3.1-1?
<james_w> gabees: could you please pastebin the output of "bzr -Derror revert tasks/views.py"?
<gabees> james_w: sure, just a sec
<gabees> james_w: here you are http://dpaste.com/49204/
<gabees> quite a lot of stuff in there
<james_w> gabees: that does look like a bug, can you please run "bzr info" and tell me what the formats you have are?
<gabees> Checkout (format: pack-0.92)
<gabees> repository: Packs containing knits without subtree support
<gabees> i upgraded from 0.9 to 1.3
<gabees> bzr upgrade
<gabees> then
<gabees> bzr reconcile
<gabees> but the reason i upgraded was because i was getting these errors in the first place
<james_w> hmm, I can't reproduce in a simple test.
<gabees> wih 1.3.1?
<gabees> with
<Peng> Bazaar 0.9?
<Peng> Not 0.90?
<gabees> yeah prob 0.90
<gabees> it was in gutsy gibbon
<gabees> now on hardy heron
<Peng> Yeah, 0.90 then.
<gabees> and all of a sudden started seeing these errors
<gabees> so i thought i'd upgrade bzr
<gabees> but ended up upgrading the entire system to hardy just to get bzr 1.3.1 :)
<Peng> Haha.
<Peng> Well, it's good to upgrade anyway.
<Peng> And bzr is totally worth the effort, right? ;)
<gabees> yup
<gabees> bzr has been so good
<gabees> i've got tens of project's source code in bzr
<gabees> if you want I can zip up my small branch and send it to you
<gabees> then you can test and see what is wrong?
<james_w> gabees: if you can do that it would be great. I should just need the .bzr/
<james_w> is the code open source?
<gabees> well not really
<gabees> it's for my work
<gabees> but i've hardly started
<gabees> if it helps to make bzr better then i don't see any problem :)
<gabees> just be a couple of mins, just uploading to our server
<james_w> sure, just wondering if I could make it available in a bug report if need be. I should be able to make a small test case out of it, so it shouldn't be an issue.
<gabees> mm
<gabees> should be ok
<gabees> here is the url
<gabees> http://dev.pixeco.com?file=bzr-error.tar.bz2
<gabees> james_w: did you get that file ok?
<james_w> sorry, was in the shower
<james_w> echo a >> tasks/views.py && bzr revert tasks/views.py works fine for me here.
<james_w> both 1.3.1 and trunk sometime before 1.5
<james_w> are you familiar with the python debugger?
<james_w> If you set BZR_PDB=1 in your environment you get a debugger at any exceptions, so you could poke around and see if anything is amiss.
<gabees> james_w: how come i was getting errors then?
<james_w> gabees: I'm not sure, sorry.
<gabees> james_w: what OS are you on?
<james_w> ah, maybe I do. I was assuming it should'nt probe for that file, but it should
<james_w> hardy.
<gabees> i just tried your code
<gabees> get the same error
<gabees> echo a to views.py
<gabees> then revert
<gabees> however
<james_w> is there anything weird about your filesystem? NFS etc?
<gabees> a plain old: bzr revert
<gabees> works just fine and returns views.py to normal
<gabees> james_w: ahhh
<gabees> it might just be that
<gabees> i'm on HFSPlus
<gabees> i have another hardy box on ext3 so i'll try that...
<james_w> I think the problem is that it is returning permission denied, rather than ENOENT
<gabees> yeah i think so
<gabees> i just tried it on the ext3 box
<gabees> worked no problems
<gabees> although... $ echo a >> tasks/views.py && bzr revert tasks/views.py works fine for me here.
<gabees> bzr: ERROR: Path(s) are not versioned: works fine for me here.
<gabees> ah yeah
<gabees> dumbass me
<gabees> r$ echo a >> tasks/views.py && bzr revert tasks/views.py
<gabees>  M  tasks/views.py
<gabees> james_w: thanks for your help earlier
<gabees> I've now reformatted the filesystem from HFSPlus to ext3 and bzr is fine again
<gabees> I'm not sure what I will do if I need to boot OS X but I'll cross that bridge when I get to it
<james_w> gabees: it's probably a good idea to file a bug, there may be something that can be done to fix it.
<james_w> at least it would be documented for others then.
<pickscrape> Hi, I'm trying to use bzr send, but when the email pops up there is no diff or bundle attached. Any tips?
<pickscrape> I've got one local commit to send (it's for the extmerge plugin)
<pickscrape> A thunderbird mail window pops up with the subject set correctly, but that's it. Dunno what I'm missing.
<sebp> I want to checkout a repo over http that contains '~' in the url and I get "Connection reset by peer" when using bzr, but opening the site in the browser works fine. Any idea?
<trepca> hey
<trepca> anyone here uses bzr with emacs ?
<trepca> sebp:  show the exact command that you typed
<sebp> trepca: bzr branch http://www.gnome.org/~sebp/bzr/python-dvb
<trepca> interesting
<sebp> is it a bug?
<beuno> pickscrape, does: bzr send -o test.patch
<beuno> create a patch with the diff?
<trepca> looks like or maybe bzr establishes too many connections which server doesn't like
<pickscrape> beuno: It creates a file, but there is nothing between #Begin patch and # Begin bundle (though there is data after #Begin bundle)
<trepca> in both cases ... probably a bug
<pickscrape> Oh, intersting. I just pulled my branch to a different machine, and on there the test patch looks a lot more like it.
<beuno> pickscrape, you have to have a branch to compare it against to generate the patch
<beuno> so, it would be something like:  bzr branch original_branch; bzr branch original_branch hackish_branch; hack hack; bzr send
<pickscrape> Should it not just pick up where I originally branched from, or do you always have to specify that explicitly the first time?
<beuno> pickscrape, it should pick up where you branched originally
<beuno> but, in case it doesn't, you can specify it manually
<sebp> trepca: okay, I file one, thanks
<pickscrape> Looks like on the other machine it's doing the right thing with -o
<pickscrape> But not when omitting that and bring up the compose email window...
<beuno> pickscrape, odd. What version of bzr are you using?
<beuno> jam, btw, sorry about overstepping you with the packaging and screwing up...  :/
<pickscrape> On this new machine it's 1.5rc1
<pickscrape> On the machine which -o doesn't work for it's running 1.4
<beuno> pickscrape, can the other machine still access where you branched from?
<pickscrape> Not long back I contributed a small change to bzr-svn and send worked brilliantly: it even filled in the To: part for me.
<pickscrape> Yes, it's on launchpad (lp:bzr-extmerge)
<beuno> pickscrape, and bzr output the URL correctly when you do send "Using saved location:..."?
<beuno> have you committed your changes?
<pickscrape> Yes, I see my changes at the top of bzr log.
<beuno> bzr send -o should be very straight forward, so if it's outputting a blank patch, bzr isn't seeing any changes for some reason...
<pickscrape> And when running send I get "Using saved location: lp:bzr-extmerge"
<pickscrape> On the 1.5rc1 machine -o *is* producing a sensible patch.
<pickscrape> On the other one I think its memorised branches are a bit messed up.
<jelmer> pickscrape: maybe send in 1.3 didn't do directory service url expansion yet?
<beuno> pickscrape, you might want to try and use an absolute URL instead of the lp: shortcut, just as a test
<pickscrape> 1.4
<pickscrape> ok
<pickscrape> What is meant by 'submit branch' in the bzr info output?
<jelmer> the branch bzr send will work against
<pickscrape> That explains why -io on my 1.4 machine is producing an empty patch. It's currently set to '.'
<pickscrape> Yep, that sorted that problem. So it's just the attachment to email that isn't working now.
<lamalex> how do you change what branch bzr submit is set to?
<pickscrape> I did bzr send -o test.patch --remember <URL>
<lamalex> cool
<pickscrape> There's probably a more elegant way though
<pickscrape> Oh, I've got it. The problem is xdg-email.
<pickscrape> If I put thunderbird into bazaar.conf explicitly it works.
<beuno> pickscrape, hrm, that ight be a bug
<pickscrape> In the docs I see mention of this helping with thunderbird 1.5, but I'm running 2.
<pickscrape> Anything I can do to help debug it?
<beuno> you have xdg set to use thunderbird, and it doesn't attach the patch unless you specify it in bazaar.conf>
<beuno> ?
<beuno> brb
<pickscrape> It only works if I specify thunderbird in bazaar.conf. If I explicitly set ï»¿xdg-email in bazaar.conf it still doesn't work.
<pickscrape> Confirmed that this workaround works on both machines.
<pickscrape> They're not even the same distro either (1.4 is on gentoo, 1.5 is on Hardy)
<alecwh> I just created a patch using bzr: bzr diff. How do I apply the diff/patch to another bzr branch?
#bzr 2008-05-11
<Tsmith__> test
<Tsmith> Alright.  I have set up a bzr repository via bzr+ssh:// on a remote server.  On my local box, I have grabbed a branch of that via $ bzr get.  I have made a lot of changes to this branch locally and now want to update the remote repository.  How do I do this?
<LeoNerd> bzr push   to the same URL
<Tsmith> u know... that's actually pretty damn nice
<Tsmith> i can have revision control and have my local dev box be totally fucked and not affect the root but still get updates
<Tsmith> i've used CVS/SVN for 10 years now, but let me tell you, two days of using bzr has totally rocked my world
<Tsmith> is there a way to do bzr diff on the remote repository banch?
<Tsmith> ALRIGHT! so bzr push on local and bzr update on remote
<Tsmith> LeoNerd, thank you very much
<Peng> Tsmith: Generally, the repo on the server shouldn't have a working tree.
<Tsmith> whats that mean?
<Tsmith> > confused <
<Tsmith> i come from the SVN world
<Peng> Tsmith: You shouldn't keep a working tree on the remote side. (Bazaar branches can operate with or without one.)
<Tsmith> woah
<Peng> Tsmith: (Y'know, the working copy.)
<LeoNerd> A branch stores history.
<LeoNerd> A working copy is a checkout of some point in that history, possibly with local modifications, likely because you want to commit that as a new point in history
<Peng> Tsmith: Push to e.g. /srv/bzr/foo on the server, then if you need a working copy on the server, "bzr branch" or "bzr checkout" that location.
<Tsmith> so i think i have a "working copy" on the server in /var/bzr/sbconsultants; and i access this *remotely* via $ bzr get bzr+ssh://hopeseekr@server/var/bzr/sbconsultants
<LeoNerd> A repository on a server generally only needs the former.. Though nothing stops it having the latter as well
<Tsmith> is that right?
<Peng> Tsmith: If you really need a working copy there, you can install the push-and-update plugin.
<Tsmith> i dont want a working copy
<Tsmith> i guess i installed it really wrong
<Peng> Tsmith: No. Bazaar uses three things: the repository, which is a big bag of revision data; the branch, which is basically just a list of revisions, and the working tree.
<Peng> Tsmith: You should read the user guide or something.
<Tsmith> i started the repository on my local dev box, tar gzipped up the entire damn thing, uploaded and uncompressed on the remote server in /var/bzr, deleted my own local copy, and ran the bzr get bzr+ssh:// thing
<Tsmith> lol it seems to work tho ;)
<Peng> Tsmith: You could've just pushed instead of tarred it.
<Tsmith> are the only files on the remote server that are needed in /var/bzr/sbconsultants/.bzr?
<Tsmith> it seems there's a .bzr in every branch
<Peng> Tsmith: Anyway, to remove the working tree from a branch, run "bzr remove-tree". From the shared repo, also do "touch .bzr/repository/no-working-trees" so that new branches won't be created with working trees.
<Tsmith> alright
<Tsmith> now i have a db.php.~1~
<Tsmith> ; is that some internal backup or important?
<Peng> Tsmith: It's a backup, made when bzr would be overwriting/deleting a file you've modified.
<Peng> Tsmith: E.g. when you run "bzr revert some-file.txt".
<Tsmith> ahhhhh
<bob2> wonder why --no-trees osn't the default
<Odd_Bloke> bob2: Because then whenever you branched while doing normal development, you'd also have to checkout.
<Odd_Bloke> Which would be inconvenient and unnecessary.
<bob2> hm, I just meant changing the default for the init-repo command
<bob2> would that still have that effect?
<jelmer> bob2: repositories are meant to be "just a storage optimization". having the behaviour of creating a working tree when creating a new branch depend on whether you are in a repository is inconsistent with that
<bob2> ahh, right
<Odd_Bloke> bob2: If you wanted to make that the default behaviour, you could use an alias.
<bob2> oh, I have
<hgr> have a feature-request for qbzr, is this the rigth place? :)
<bob2> prbably better to file a nug so it doesn/t get forgotten
<bob2> er, bug
<Warddr> What makes bazaar better then SVN?
<jelmer> Warddr, you may want to have a look at http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html
<Warddr> And how can I save a location for bazaar? Now I get this error:
<Warddr> warddr@warddr-laptop:~/ludem-ward-test$ bzr merge
<Warddr> bzr: ERROR: No location specified or remembered
<bob2> "bzr merge --remember someurl" will remember someurl
<Warddr> ty bob2, sounds logical
<Warddr> bob2, ty, it's working
<LaserJock> anybody know how to flush the disk cache from CLI?
<jelmer> LaserJock, 'sync'
<LaserJock> jelmer: ah, thanks. seems simple enough :-)
<LaserJock> seems I need to redo all my performanc tests
<nysin> I've been trying to use bzr gconflicts and it's nice and all except that it seems to save things back into foo.{BASE,THIS,OTHER} without touching the actual file in which the conflict is to be resolved. Is this the case?
<nysin> (since that's how it launches the 3rd party merge/diff viewer)
<LaserJock> so I'm thinking of an easy way to time a big merge on the linux tree
<LaserJock> if I put 2.6.0 into a repo, then import 2.6.25.1
<LaserJock> then branch that, import 2.6.25.2 into the branch
<LaserJock> then finally merge that back to the main branch
<LaserJock> does that sound like a reasonable test?
<fullermd> Depends what you're testing.
<fullermd> It would merge a fair numbe of files, to be sure.  But only one revision.  And only on a 2-rev history.
<LaserJock> fullermd: yeah, that's for sure the weakness of my test
<fullermd> The emacs switchover is a good demonstration that vhast improvements in scaling with tree size generally don't bleed over into scaling with history size   :|
<LaserJock> but I don't really want to completely convert the entire git repo into bzr and hg
<nysin> So if bzr-gtk launches its diff3 program with only the {OTHER,BASE,THIS} filenames, is the intended workflow to perform whatever merges are desired to an arbitrarily chosen file and then copy that file over to the one actually under revision control?
<swegner> ï»¿Hi all.  I'm starting a new project that I'd like to have hosted on Launchpad, so I'm trying to get used to the bzr version control.  When I have a group of contributors making commits, will they each need their own "branch", or is there a way to register one global "trunk" for the project's developers?
<beuno> swegner, you can have a global trunk
<beuno> just create a team
<beuno> upload the trunk to the team
<beuno> and add all the members you want to have access to that team
<swegner> that makes sense
<swegner> ok, I'm going to get started on that-- thanks for the tip  :)
<beuno> swegner, np, and welcome  :)
#bzr 2009-05-04
<mwhudson> i'm thinking the linux kernel is probably a little ambitious for the moment...
<RAOF> mwhudson: Banshee would work.  That's ~20Mb or so of git.  Or is that not medium enough?
<mwhudson> RAOF: let's try it
<mwhudson> RAOF: url me up?
<RAOF> Also has the advantage that I know bzr-git successfully branches it.
<RAOF> git://git.gnome.org/banshee
<mwhudson> oh right, all the gnome imports
<RAOF> There's _lots_ of them available :).  You don't want one of them?
<RAOF> libdrm would be another one.
<mwhudson> RAOF: no, i'd just forgotten
<lifeless> mwhudson: linux should work well with dev6
<mwhudson> lifeless: until --default-rich-root is dev6 or similar...
<mwhudson> (actually i think it will import into 1.9-rich-root now)
<lifeless> spiv: I'm a little worn on repeated 'cut a round trip off' day days
<lifeless> spiv: I had wanted to pair today, but my desktop blew a sprocket on saturday
<lifeless> spiv: so perhaps tomorrow?
<spiv> lifeless: sure, tomorrow sounds good to me.
<jonnydee1> hi :) I recently stumbled over the following bug and reported it: https://bugs.launchpad.net/bzr/+bug/370551  Is there a chance that a fix will make it in a 1.14 maintenance release, or in 1.15, at least?
<ubottu> Launchpad bug 370551 in bzr ""bzr mv --auto" provokes traceback when auto detecting files that were moved to unversioned directories" [Medium,Confirmed]
<jonnydee1> bazaar cannot handle files that were moved to unversioned directories. but this makes the auto-detect feature more or less useless (for me, at least)
<lifeless> jonnydee1: thats a dupe actually
<lifeless> jonnydee1: no, 1.14 won't get a fix; its not a regression. You can just 'bzr add' the new directory before you move files into it, to avoid the bug.
<lifeless> bug 367628
<ubottu> Launchpad bug 367628 in bzr "bzr mv <stuff> unversioneddir/ fails" [High,New] https://launchpad.net/bugs/367628
<lifeless> thats the root cause
<jonnydee1> lifeless: I know I can add the directory. But I need auto-detection when I refactor code using an ide. and there it happens often enough that files are moved to newly created directories....
<lifeless> jonnydee1: in your example you manually move a file to the unversioned dir first
<jonnydee1> lifeless: and how do I recover from the stack trace if I occasionally got trapped by this bug? Will it suffice to 'bzr add' the unversioned directory, afterwards?
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/367628 is the main bug for 'bzr mv foo unversioned/'
<ubottu> Launchpad bug 367628 in bzr "bzr mv <stuff> unversioneddir/ fails" [High,New]
<jonnydee1> The problem is that 'bzr st' does not work anymore, which makes it hard to figure out what directories are needed to be versioned...
<jonnydee1> lifeless: ok, should I mark the other bug report as a duplicate?
<lifeless> no
<lifeless> it may be slightly different
<lifeless> I'm going to note that in the bugs
<lifeless> my browser just stopped working for a minute, doing that now
<jonnydee1> ok, thank you, lifeless, for your help :)
<lifeless> no problem
<lifeless> poolie: http://igotgenes.blogspot.com/2009/04/how-symbolic-on-removing-symlinks-in.html
<poolie> hm that's good i guess
<poolie> wbn if somebody fixed the bugs though :)
<pygi> lifeless, poolie : will be nice to see you at UDS :)
<poolie> you too
<mwhudson> spiv: wow, bug 250451 gets nastier and nastier
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed] https://launchpad.net/bugs/250451
<spiv> mwhudson: yeah
<spiv> mwhudson: I suppose LP could monkeypatch sys.stdout to autocorrect that message ;)
<mwhudson> spiv: we _should_ translate paths in some exceptions
<mwhudson> but i don't think that will help here
<rocky> ugh, how many times do i merge stuff from another branch, forget to commit, do a bunch of work, and realize now i have my merge changes all messed up with my new work
<rocky> is there an easy way to fix that ? ^^
<thumper> shelve?
<rocky> i've done a bunch of work, shelve will take me all night :(
<mwhudson> shelve, redo the merge, commit, unshelve
<mwhudson> ?
<rocky> oh you mean shelve everything ?
<AfC> What's with the alternating '>' and '<' in the pretty display when communicating with a remote server?
<spiv> AfC: traffic direction
<mwhudson> rocky: right
<mwhudson> rocky: you'll might have to fix some conflicts when you unmerge, but hopefully not too bad
<mwhudson> s/unmerge/unshelve/
<AfC> spiv: oh
<AfC> Is there a way to turn off the progress bar and just have the textual information?
<rocky> mwhudson: wow, conflicts are huge (like whole files)
<spiv> AfC: not that I know of.
<mwhudson> rocky: :(
<rocky> actually it wasn't so bad
<rocky> it was just one file like that and the fix was easy enough
<rocky> so yeah i'm all set now. .. thanks mwhudson! :)
<AfC> spiv: I recall we talked about that here a while back - I guess I need to file a bug for that.
<mwhudson> rocky: np
<rocky> mwhudson: although for what it's worth, after shelving my stuff i had to "revert" the bzr merge that wasn't being committed before i could start over
<mwhudson> rocky: hm, that makes sense
 * mwhudson wouldn't know how shelve interacts with pending merges, i guess it just ignores them
<rocky> well, bzr doesn't know that something special has happened with shelve so bzr stat still shows the pending merge, just with no changes
<rocky> and you can still commit the pending merge with no changes
<rocky> but obviously you don't want to, so just rever it
<exeoeoe> http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck
<mwhudson> jelmer: are you going to be at uds?
<vila> hi all
<lifeless> signing off
<lifeless> gnight
<poolie> hello vila!
<vila> good bight lifeless, hi poolie
<vila> err night
<poolie> vila, what are you working on next?
<vila> bug #366107
<ubottu> Launchpad bug 366107 in bzr "Bazaar should attempt Basic authentication if HTTP server offers NTLM" [Undecided,Confirmed] https://launchpad.net/bugs/366107
<vila> surprisingly, we can't handle servers which propose several auth schemes :-/
<vila> then I'd like to refactor log tests and dig there, several bugs are hanging around since last Ian optimisations
<vila> I'm also waiting for a review related to bug #355454 to finish fixing it
<ubottu> Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [High,Fix released] https://launchpad.net/bugs/355454
<poolie> hm ok
<poolie> 366107 sounds like a good thing to fix but i'm not so sure it's high priority
<poolie> is it easy or already something you want to fix?
<vila> poolie: should be easy once I enhance the related test servers and I'd like to fix it as not being able to handle server with multiple auth schemes is a bit embarassing :-}
<poolie> ok
<poolie> you probably know best
<poolie> do you have an order of magnitude guess how long the log tests and fixes would take? like a week?
<vila> surely less, it's first: refactoring existing ones that checks for particular revisions to avoid depend of the actual output format, then add new ones for the bugs I know of (mostly wrong selection of revisions)
<vila> meh --coverage fails to recognize code run in threads :-/
<spiv> vila: that's probably not too hard to fix
<spiv> vila: add a call to threading.settrace in apply_coveraged in bzrlib/commands.py, probably
<vila> spiv: works, great, thanks :)
<mwhudson> vila: just in case you're curious, i'm adding support for multiple byte ranges to twisted's http server currently :)
<vila> mwhudson: good, feel free to canibalize our http_server, there are some subtleties in parsing and validating the ranges requested
<mwhudson> vila: no kidding
<vila> :)
<mwhudson> vila: twisted already had a pretty anal parser and handled the single-range case
<vila> mwhudson: you may also want to have a look at lp:~vila/bzr/local-test-server for a quick way to validate your server against bzr
<bialix> hi guys! anybody home?
<bialix> I have a little question about English word "control" from "version control system". When you say "control" there you mean "management" or "check" or "watching"?
<luks> I'd say management
<bialix> hi luks
<luks> hey
<bialix> how are you?
<luks> fine, thanks. you?
<bialix> more or less
<bialix> thanks for explanation
<luks> well, that's just my opinion
<bialix> my question raised because we have incorrect translation in Russian of this term
<luks> and how I'd translate it to another language
<bialix> I understand
<bialix> translation in Russian is wrong because we have the word "control" here too, but it's false friend of translator
<bialix> Russian control it's closer to "check"
<luks> same here in slovak
<bialix> :-)
<bialix> I've started heavily using "daggy fixes" in my work
<bialix> this very heavily influencing my style of work with VCS
<luks> I don't think I could strictly follow that
<luks> maybe for recent branches
<luks> but definitely not for something old
<bialix> well, in my case I need to maintain several branches in parallel, so it's work OK
<bialix> and for old branches too
<bialix> my mileage is different I suppose
<luks> well, I'm a lazy person :)
<bialix> me too, but daggy fixes make my life easier
<bialix> because cherrypick in bzr sometimes painful
<luks> the only feature I like in svn better
<bialix> cherrypick?
<luks> yep
<bialix> IIUC this is inevitable downside of DAG-based systems
<luks> exactly
<jml> bialix: I'd say that the "control" part of VCS isn't terribly significant.
<bialix> hi jml
<bialix> jml: why not?
<jml> bialix: "management" is close enough, I guess.
<bialix> thanks
<jml> bialix: but when I hear the phrase, I think "version $GENERIC_VERB $GENERIC_ABSTRACT_NOUN"
<jml> version handler thing
<bialix> :-)
<bialix> ok, one more question: when you say "version" and "revision" -- what's difference?
<bialix> VCS vs RCS
<jml> not much.
<jml> "version" has a connotation of "released version", I guess
<bialix> version is more genric term?
<jml> yeah.
<jml> "revision" almost always refers to the result of a commit (in IT, anyway.)
<bialix> I read "revision" as in "document revision"
<jml> right, that's the broader sense
<bialix> it's about editing the text, is not?
<jml> a revision is what you get after you have revised something, usually a text.
<bialix> i.e. when I fix some errors in the text?
<jml> yeah.
<bialix> or improve something?
<bialix> thanks
<bialix> the things much clearer now
<bialix> it's so hard to translate VCS terms adequately
<jml> I'll bet!
<luks> doesn't russian have a commonly used equivalent?
<bialix> that's the problem
<bialix> we have some de0facto equivalent
<bialix> de-facto
<bialix> but sometimes they are represent svn-centric point of view
<bialix> i.e. you have no pull/push in svn
<davidstrauss> Revision is a bad term for VCS because it's colloquially used to mean a diff and the result of applying a diff.
<luks> I think the the term applies to any vcs
<bialix> davidstrauss: what will be better?
<davidstrauss> bialix: commits should be called snapshots
<luks> so if there were some manuals for csv or something, I'd use the term from there
<luks> *cvs
<davidstrauss> bialix: commits/revisions used to not be atomic, so you couldn't call them snapshots
<bialix> luks: well, there is semi-official translation of svn
<bialix> "svn book"
<davidstrauss> bialix: but any modern vcs has atomic commits, so we ought to call them snapshots
<luks> davidstrauss: but we don't :)
<bialix> is not "commit" is the action
<bialix> ?
<bialix> but snapsot is the object
<davidstrauss> bialix: See, that's another troublesome term
<luks> depends, git uses it as the result of the action
<davidstrauss> bialix: "Commit" can be the action of committing or the snapshot produced by committing
<bialix> nice
<davidstrauss> bialix: "Snapshot" is so unambiguous, I can even use it to define the confusing VCS terms.
<bialix> I agree here
<davidstrauss> bialix: It's a nice metaphor, too
<luks> but it's not very translatable, I guess
<davidstrauss> bialix: git could not call it a snapshot, though, because they have the staging area
<luks> I can't think of a slovak translation for shapshot
<bialix> for those who like photography?
<davidstrauss> luks: What is the translation used for file system snapshotS?
<bialix> for me snapshot is more about photo
<luks> davidstrauss: I don't think there is one
<davidstrauss> http://en.wikipedia.org/wiki/Snapshot_(computer_storage)
<luks> we just use an expression to explain it
<luks> can't think of a direct translation
<davidstrauss> There are a few translations there in the inter-language links
<luks> three words for russian :)
<davidstrauss> It's pretty much impossible to find terms that work across languages. Computer terms are either metaphorical or made up
<luks> so the same problem, I guess
<luks> ah, no
<davidstrauss> luks: I'm sure "commit
<bialix> luks: in russian it's called "phot of file system"
<davidstrauss> luks: I'm sure "commit" and "revision" are at least as bad
<luks> davidstrauss: definitely
<luks> I always laugh at the translation of commit in svn manuals
<bialix> push is bad too
<davidstrauss> luks: At least "snapshot" is unambiguous and tangible to English speakers
<bialix> luks: in russian svn book "revision" called an "editing"
<bialix> it's so crazy
<bialix> davidstrauss: "git could not call it a snapshot, though, because they have the staging area" -- I disagree
<bialix> their staging area is also "snapshotting"
<davidstrauss> bialix: git isn't snapshotting anything
<bialix> really?
<davidstrauss> bialix: http://fourkitchens.com/blog/2009/02/03/importance-atomicity-or-why-git-staging-area-bad
<bialix> looking into .git directory I see they're store actual state of the files
<luks> davidstrauss: they are just applying a filter before they take the snapshot
<davidstrauss> luks: no
<luks> but I think it still is a shanpshot
<davidstrauss> luks: nope
<davidstrauss> luks: "Along these lines, one of the most atomicity-busting aspects of gitâs staging area is that it doesnât just mark code that needs to go into the next commit; it actually saves the hunk into the staging index. So, a developer could add code to the staging area, modify her working copy, and end up with a commit containing code thatâs neither in her working copy nor in her stash."
<davidstrauss> luks: Something can be in the git staging area but not in your working copy.
<luks> hm, I didn't know that
<davidstrauss> luks: It's uncommon for someone to stage a change, revert it, and then commit the staged change, but it's quite possible.
<bialix> davidstrauss: roughly the same happens in interactive darcs commit
<davidstrauss> luks: So, I think that violates the snapshot metaphor.
<luks> davidstrauss: if you define it as a tree-level snapshot, yes
<bialix> you mean the staging area is virtual, but real files are real?
<davidstrauss> bialix: I mean a snapshot should be of your working tree
<bialix> I understand
<bialix> but...
<luks> but the same thing applies to svn then
<davidstrauss> bialix: A data structure that you stage changes into doesn't translate well to the snapshot metaphor
<davidstrauss> luks: no
<bialix> see! even in English you can use snapshot differently
<davidstrauss> luks: svn allows selective commit, but the commit must be of files as they are in your working tree
<luks> davidstrauss: they might be out of date
<luks> davidstrauss: svn will automatically merge, if possible
<davidstrauss> luks: svn requires you to update prior to commit if you're committing to changed files
<luks> you can commit a revision that doesn't represent your working tree
<luks> sure, but it doesn't have to be the modified files
<luks> source code files usually depend on each other
<davidstrauss> luks: if you mean "merge" different directories, then yes, svn sort of violates it. but the problem is more that svn doesn't distinguish between branches and directories.
<davidstrauss> luks: svn takes snapshots from the directory you're in and below.
<davidstrauss> anyway, it's way past my bedtime
<davidstrauss> luks: I rag plenty on svn/git in that blog post, anyway
<davidstrauss> luks: And I do bring up that very issue
<Jemsquash> I think I'm missing something about bzr add.  I have a clearcase view where I do updates to. I have created a bzr repo here and I do an bzr move --auto, bzr add then I was hoping to do a commit. However I do a bzr status and it shows a lot of files and directories as unkown with a ?. I expected the bzr add to add these files. What am i missing?
<lifeless> Jemsquash: have you done 'bzr init' at any point? if not I'd be expecting bzr mv and bzr add to be erroring
<lifeless> Jemsquash: if they aren't erroring, perhaps you are invoking 'bzr add' in a strange way?
<Jemsquash> I am just typing bzr add.
<lifeless> what does it report?
<Jemsquash> I have 3 revisions in the branch so it is definitely initialised.
<Jemsquash> nothing.
<Jemsquash> I do bzr add. The command completes with no response. I then do bzr status and it lists a load of files as unknown.
<Jemsquash> I initially did an add and it seemed to add a bunch of files, but seemed to leave a whole lot out.
<lifeless> would it be possible to pastebin?
<lifeless> bzr st
<lifeless> bzr add
<lifeless> bzr st
<lifeless> oh, actually
<lifeless> I think I know
<lifeless> if the things that are not getting added are all bzr trees themselves, that is why
<lifeless> what does 'bzr info <somethingthatisn'tgettingadded>' report?
<Jemsquash> I can't do it here, it was at work today and I don't have access to irc from there. Corporate firewalls :(
<lifeless> I bet that the things you are adding are bzr trees,or perhaps svn or some other vcs that you have a bzr plugin for installed
<Jemsquash> I'm a bit lost when you say that things not being added are all bzr trees themselves.
<Jemsquash> Ok - perhaps.
<Jemsquash> I'll have an investigation into looking for .svn folders or .cvs folders. It is a possibility although I will be surprised.
<lifeless> to demo now
<lifeless> cd /tmp
<lifeless> bzr init foo
<lifeless> cd foo
<lifeless> bzr init bar
<lifeless> bzr add
<lifeless> bzr st
<lifeless> you should see that bar hasn't been added
<Jemsquash> yep. That sort of makes sense.
<Jemsquash> Is that due to the shared repo containing branches etc?
<lifeless> no, its because we haven't finished the nested trees support
<Jemsquash> ah ok
<lifeless> if it were to add bar, it would be versioning a link to bar, like a svn external
<Jemsquash> I'm not sure I want to understand this concept of nested trees.
<lifeless> heh
<Jemsquash> it sounds scary :)
<lifeless> its pretty straight forward; you have a bzr tree for a library or something that you want to embed in a larger tree
<Jemsquash> so the tree in effect is a project with subprojects in a way.
<lifeless> yes
<Jemsquash> If you created a branch from a branch that contained a nested branch would it copy that nested branch with its revisions across too?
<Jemsquash> I'm confusing myself with recursion when I reread my own post.
<Jemsquash> I guess I'm asking what the relevance of the link is vs the actual full blown nested repository. The link is versioned not the nested repo.
<Jemsquash> If I commit a change to the nested tree will it change the revno of the containing branch?
<bialix> anybody knows approx timeframe for 1.15 release?
<lifeless> the relevance is that you can continue working on the subproject separately [in an entirely different machine, without the parent project, for instance], then pull across into the subproject dir where you are nesting it
<lifeless> if it was a new project, you've have to be doing merges, and it would be less conveninet
<lifeless> bialix: sorry, not offhand
<bialix> well, when UDS then?
<Jemsquash> OK I think I understand. I would have to try it out to figure out how to use it. It sounds promising provided the overall project is structured correctly to cope with subprojects.
<Jemsquash> Thanks for your suggestion on checking to see if the unadded files & directories are themselves under revision control.
<bialix> UDS will be 25-29 May. So I suppose 1.15 will be before or after. right?
<lifeless> bialix: I'm not exactly sure; I'd ask the list if you need to know
<bialix> ok
<phanatic> hi, i need to upgrade my branch to "rich-root-pack" to use split, right?
<jelmer_> phanatic: yes
<jelmer_> mwhudson: yes
<phanatic> jelmer_: thanks. bzr upgrade --rich-root-packs should do the trick, right?
<jelmer_> phanatic: if you're restricted to bzr <= 1.0, yes
<jelmer_> phanatic: (1.9-rich-roots also exists, for example)
<phanatic> jelmer_: any ideas why i get this: http://pastebin.com/d37856392 ?
<jelmer_> phanatic: you must upgrade the repo, not the branch
<phanatic> ah, thanks :)
<Jemsquash> I'm trying to find an easy way of migrating from clearcase to bazaar. I've come across a tool that will migrate from clearcase to subversion. I could then import into bazaar from there. The tool that I found can be found at http://community.polarion.com/index.php?page=download&project=svnimporter Does anyone have any better suggestions in migrating to bazaar?
<NfNitLoop> Jemsquash: I don't know about clearcase->svn, but svn->bzr is pretty easy.
<NfNitLoop> The only thing I can think of is that you might lose some metadata in the clearcase->svn migration.
<NfNitLoop> SVN doesn't do non-linear history.
<limor> hi
<limor> I have a question? any german people?
<limor> the informations of an branch like history.. are they stored in the branch or in the repository folder?
<Peng_> limor: The history is stored in the repository.
<Peng_> limor: All .bzr/branch contains is some meta data and a pointer to the branch's tip revision, which can be used to reconstruct the history from the repository.
<limor> ah ok so the branch .bzr folder only store the metadata an the .bzr in the repository filder stores the history where the branch points to
<mrooney> I'm attempting to use loggerhead to view a remote svn branch, does anyone know if this should work?
<mrooney> I am trying for example ./serve_branches svn+http://svnserver/repos/trunk
<Peng_> mrooney: That's an interesting idea.
<james_w> mrooney: does serve-branches load plugins?
<Peng_> james_w: Yeah.
<Peng_> It tells me "... is not a directory" though.
<mrooney> do I need some switch to tell loggerhead it is a remote branch? maybe it has nothing to do with bzr-svn?
<Peng_> From the file/class names, it seems filesystem-centric.
<james_w> mrooney: serve-branches serves all branches under a directory, so that's probably not going to work
<mrooney> oh darn and the repository doesn't work either
<mrooney> I already have a full svn import of the repository, maybe I should add a commit hook to update it and then I can just use the local bzr thing
<mrooney> although I bet it would be useful to others as well if it could work the aforementioned way
<james_w> yep
<james_w> loggerhead can do it fine
<james_w> just serve-branches can't set it up in the right way it seems
<james_w> is the other launch script still there?
<james_w> start-loggerhead I think it was
<james_w> or does serve-branches say anything about a config file in the source?
<NEBAP> hi guys
<beuno> no config file for serve-branches (yet)
<mrooney> oh okay it works fine on my import
<mrooney> but it doesn't have the fancy ajax expanding of changes or the unified diff / side by side toggle
<mrooney> does LP have its own version or do I need trunk?
<beuno> mrooney, trunk has those
<mrooney> ah ok let me grab that
<beuno> LP uses trunk
<mrooney> fancy :)
<beuno> we like cutting edges  :)
<vxnick_> could I ask for your (collective) advise on something?
<NEBAP> is it possible to use bazaar in the following way: I have a container folder which represents the complete project. Within this folder there are container subfolders representing a part (e. g. a DLL) of the project. Does bazaar recognise this project layout in the way that it knows that the subfolders are parts of the project container?
<mrooney> hmm it looks the same to me
<mrooney> I will take a look later
<jelmer_> mrooney: I think I know
<jelmer_> mrooney: loggerhead tries to store a cache in the branch
<jelmer_> mrooney: and that might rely on local file access
<jelmer_> beuno: ^
<beuno> jelmer_, it does
<beuno> well
<beuno> not *in* the branch
<beuno> in a /tmp dir
<jelmer_> beuno: oh, ok
<beuno> although, tbh, I don't know what it would do with remote branches
<jelmer_> beuno: so that doesn't explain why ./serve-branches <svn-url> doesn't work
<beuno> lifeless and I tried it on SVN branches locally, and it owrked
<beuno> jelmer_, right. Other than "I have never tried that"  :)
<beuno> it theory, it *should* work
<vxnick_> what's the best way to deploy an app to a server with bzr? At the moment I'm using bzr-upload from my dev machine to the server itself, but I'm now wanting to centralise things so I can have a repository view on my project management system.
<jelmer_> beuno: serve-branches:47 has a check that the specified path is a directory :-)
<beuno> jelmer_, ah. There you go
<beuno> because we do directory navigation
<beuno> as well as branches
<beuno> I guess we need a different path when it's already a branch
<jelmer_> beuno: directory navigation could be done using Transport though
<jelmer_> beuno: Transport.list_dir works on svn transports
<beuno> jelmer_, interesting. May work better.
<beuno> I guess that would be a bug
<beuno> vxnick_, you could use push-and-update
<beuno> and block .bzr dir from being served
<vxnick_> beuno: thanks - does that push to the central server and then update the remote production server?
<beuno> vxnick_, pushes and updates the working tree in the remote location
<beuno> you need ssh
<vxnick_> thanks, I'll take a look at its docs
<beuno> welcome'
<Peng_> Would using transports hurt Loggerhead's performance on local branches?
<jelmer_> Peng_: it would have a very slight overhead
<Peng_> BTW, Loggerhead does support remote branch references.
<jelmer_> Peng_: not a noticable impact
<Peng_> You can't pass a remote location to serve-branches, but if you have a branch reference locally, it works.
<Peng_> Bit slow, though.
<Peng_> beuno: It seems to build the caches correctly on remote branches.
<jelmer_> bug 371787
<ubottu> Launchpad bug 371787 in loggerhead "should use transports rather than local file access" [Undecided,New] https://launchpad.net/bugs/371787
<Peng_> beuno: (Well, references, but that still loads the remtoe branch.)
<beuno> ah
<beuno> thanks herb
<beuno> er
<beuno> and jelmer_
<mdz> I have a bzr repository which seems to fail to convert using bzr upgrade --1.9-rich-root
<mdz> it runs for a very long time and never terminates
<jelmer_> beuno, peng_: hmm, that was actually pretty easy
<beuno> mdz, is .bzr.log helpful at all?
<mdz> 66.413  Using fetch logic to copy between KnitPackRepository('file:///home/mdz/s
<mdz> rc/.bzr/repository.backup/')(<RepositoryFormatKnitPack1>) and KnitPackRepository
<mdz> ('file:///home/mdz/src/.bzr/repository/')(<RepositoryFormatKnitPack6RichRoot>)
<mdz> 66.413  fetch up to rev {None}
<mdz> 2654.157  Traceback (most recent call last):
<mdz> [traceback from where I interrupted it]
<mdz> so that's about 45 minutes with no indication of progress for most of it
<beuno> mdz, if it's a big repo, I think it could actually take ages as it recompresses all it's deltas, etc
<beuno> but it should be eating CPU like crazy
<mdz> beuno: it did eat CPU, but the progress indicator didn't update
<beuno> mdz, that's "normal"
<beuno> how big is the repo?
<beuno> I've heard big repos take up 18 hours in this kind of jump  :)
<mdz> the repo is about 1.2G
<Peng_> jelmer_: What was?
<beuno> mdz, sounds normal then. Probably one of those things to do before you go to bed  :)
<mdz> beuno: I will give it another try.  if it doesn't complete by this time tomorrow, I will renew my suspicions
<jelmer_> Peng_: switching to transports
<beuno> mdz, you should also be aware that all remote branches will need to be rich-root as well
<beuno> or you won't be able to interact with them
<mdz> beuno: that's what has actually triggered the upgrade for me; one of the branches I work with has converted and I could no longer branch from it
<Peng_> jelmer_: Wait, did you actually do it, or just see how?
<mdz> beuno: does this mean it's impossible to share a repository between branches unless they're all upgraded?
<beuno> mdz, yes. It sucks.
<mdz> beuno: or will upgrading the repository fetch massive amounts of data from remote branches?
<mdz> hmm
<beuno> mdz, they won't work if they aren't rich-root on the other end
<beuno> but
<mdz> sounds like I should quit using a repository
<beuno> there's light at the end of the tunnel
<beuno> 2.0 format will be rich-root
<mdz> rather than spending days converting it
<beuno> and there won't be any non-rich-root anymore
<beuno> mdz, yeah, I keep them in shared repos between projects
<vxnick_> is there anything like push-and-update but for commits?
<beuno> vxnick_, well, checkouts accomplish that to some extent
<beuno> but I don't know if push-and-update plugin works with it
<vxnick_> beuno: I just want to avoid having to login to the production machine to update
<jelmer_> Peng_: I actually fixed it
<vxnick_> I want to do: local dev --> commit to central repo --> update remote production machine
<Peng_> jelmer_: Oh, cool. :)
<mdz> beuno: I just use one big repo for checking out everything
<beuno> vxnick_, ah, two separate machines
<vxnick_> beuno:  yup :)
<beuno> mdz, yes, I used to do that. Had to move to per-project  :)
<beuno> mdz, after 2.0, the madness should stop, and we can all finally be happy
<beuno> vxnick_, I don't think there's anything in bzr that will let you do that
<vxnick_> beuno: hmm. I think you're right but thought I'd ask
<beuno> vxnick_, you can put together a plugin if you're good with python
<beuno> vxnick_, or a cronjob  :)
<vxnick_> beuno: I'm a complete noob :)
<vxnick_> beuno: a cron is an option but it'd be nice to have it automated
<mdz> beuno: if I just blow away my repo, will that break all of my local branches, or will they continue to work?
<vxnick_> beuno: on second thoughts, it's probably best to manually run bzr update just in case there are any conflicts
<beuno> mdz, break completely and loose all your data
<mdz> beuno: sweet!
<beuno> mdz, I'd recommend you branch from the repo for big branches so it's local and fast
<mdz> so I guess I 1) make sure all my changes are pushed to LP, 2) blow away my repo, 3) re-download all my branches
<beuno> and then bring in the rest remotely on a need-to-use basis
<beuno> mdz, you can branch them locally instead, outside of the shared repo
<mdz> beuno: oh, good idea
<beuno> mdz, but then again, you're so close to the tubes, not sure it would make a dramatic difference
<mdz> beuno: I'm at home, narrower tubes
<beuno> right, avoid plumbing all together then
<vxnick_> do you know of any bzr plugins to allow shell-type files to be run?
<jelmer_> beuno, Peng_: how do I run the loggerhead testsuite?
<beuno> jelmer_, nosetests
<beuno> vxnick_, shell hooks. let me find some documentation for you..
<jelmer_> beuno: is there some way to enter a debugger in case of tracebacks, like BZR_PDB=1 ?
<vxnick_> beuno: thank you kindly :)
<beuno> jelmer_, I... don't know   :)
<jelmer_> beuno: thanks
<vxnick_> beuno: I'm thinking that perhaps bzr upload would work if I called it from a shell script on the post_commit hook
<vxnick_> from central server --> deployment server
<mrooney> beuno: I checked out lp:loggerhead/trunk now and am running that, but I still don't see any of the new stuff LP has, do I need to do anything special?
<beuno> mrooney, nope, you sould see all of it
 * Peng_ has never run Loggerhead's test suite. Coughcough.
<mrooney> beuno: hmph, I'm stuck then
<beuno> vxnick, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks
<beuno> http://bazaar-vcs.org/BzrHooks
<vxnick> beuno:  cheers!
<beuno> mrooney, did you install loggerhead from a package?
<mrooney> beuno: no I checkout out lp:loggerhead/trunk and ran serve_branches
<beuno> mrooney, do you didn't have it installed previously?
<mrooney> beuno: well I had run 1.10 in the same way previously
<beuno> mrooney, can you try getting lp:loggerhead instead?
<mrooney> yeah that is what I originally used
<mrooney> then I tried trunk and it looked the same
<beuno> well, it's all there is  :)
<mrooney> beuno: what is all there is?
<beuno> mrooney, you don't have serve-branches in /usr/bin?
<beuno> mrooney, lp:loggerhead
<mrooney> beuno: nope I don't have it except in the 1.10 and trunk checkout
<beuno> mrooney, so
<beuno> you're doing:  bzr branch lp:loggerhead; cd loggerhead; ./serve-branches
<mrooney> beuno: well, bzr co lp:loggerhead/trunk loggerhead-trunk; cd loggerhead-trunk; ./server-branches path
<mrooney> well except for that typo in the last command
<mrooney> is anyone able to attempt to reproduce it? as long as you have a local repository it should take about a minute
<beuno> and when you hit localhost:8080
<beuno> you get the old version?
<mrooney> beuno: well I assume, I don't have the ajax expansions or side by side vs unified diff options
<mrooney> if I kill the trunk process it stops working so I am fairly sure it is being served from the process I think it is
<Peng_> Could it be importing the wrong "loggerhead" somehow? Does that even work anymore? I broke it for UserBranches, but I'm not sure about regular Branches.
<mrooney> I would say it could have something to do with me first using the 1.10, but in retrospect I see lp:loggerhead goes to trunk anyway
<mrooney> so I never actually had 1.10
<mrooney> Peng_: do you have a repos to test with?
<Peng_> mrooney: Test what?
<mrooney> to see if someone else serving from trunk gets what I expect, the LP interface
<mrooney> maybe they don't!
<jelmer_> beuno, Peng_: loggerhead works on svn and git branches now :-)
<beuno> jelmer_, you're unstoppable
<beuno> have you files a merge proposal for the tweaks?
<mrooney> jelmer_: so I can grab your branch and use a remote svn branch?
<BasicOSX> just a /poke for input regarding 1.15rc1. My initial post had 1 follow-up and I've responded to that. Looking for general feel on the state of the code and bug fixes so a 1.15rc1 can be created.
<jelmer_> mrooney: yeah, the last two branches I submitted for merging into loggerhead
<jelmer_> mrooney: as well as the latest bzr-svn and subvertpy
<jelmer_> beuno: and mercurial :-)
<mrooney> ah okay I'll merge those locally
<beuno> jelmer_, really?  bzr works with hg?
<jelmer_> beuno: well enough for the history
<jelmer_> beuno: I haven't tried looking at the diffs yet
<beuno> amazing
<jelmer_> mrooney: there's one caveat, you'll have to disable the caching in bzr-svn because loggerhead uses threads
<beuno> jelmer_, if you point me at the MP, I'll review/merge
<beuno> ah
<beuno> Peng_ got to it  :)
<beuno> he can merge
<Peng_> beuno: OK.
<jelmer_> beuno: https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179, https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179
<jelmer_> I mean https://code.edge.launchpad.net/~jelmer/loggerhead/fix-nick/+merge/6180
<Peng_> Huh, I haven't seen any code review emails. I'm still getting other LP mail...
<LarstiQ> jelmer_: dude! asom!
<Peng_> BTW: I don't want to review fix-nick, since I'm not qualified to comment on branch._get_nick.
<Peng_> Ahh, here the emails are; they're just a bit late.
<beuno> jelmer_, I had to change the nick bit so it didn't try and grab it remotely for checkouts
<beuno> I think this will revert back to that behaviour?
<beuno> or does the local=true prevent it?
<jelmer_> beuno: local=True prevents it
<beuno> jelmer_, thanks. Will merge it
<Peng_> I could fix my review comments on transport and merge it. OK?
<beuno> Peng_, go for it!
<Peng_> OK.
<jelmer_> Peng_: thanks!
<mwhudson> jelmer_: what was i asking? :)
<jelmer_> mwhudson: :-)
<jelmer_> mwhudson: Where I would be at UDS
<jelmer_> s/Where/Whether/
<mwhudson> jelmer_: oh right
<mwhudson> jelmer_: good!
<jelmer_> mwhudson: more bzr-git issues to work on ?
<beuno> jelmer_, you're going?
<jelmer_> beuno: yep
<beuno> yay
 * beuno will be there
<mwhudson> jelmer_: i can't quite remember why i was asking now :)
<jelmer_> beuno: Cool :-)
<beuno> Peng_, how about you?
<mwhudson> jelmer_: testing git imports got stalled by having our staging code import machine stolen by IS
<jelmer_> IS?
<jelmer_> mwhudson: oh btw, I fixed another excessive memory usage issue in dulwich
<mwhudson> information services
<mwhudson> jelmer_: can i cope with the kernel yet? :)
<beuno> aka, sysadmins
<jelmer_> mwhudson: maybe
<jelmer_> mwhudson: samba works pretty well now
<mwhudson> jelmer_: cool
<jelmer_> it's still a bit slow though, takes a couple of hours
<mwhudson> jelmer_: importing into what?  --1.9-rich-root
<mwhudson> jelmer_: hours!?! we have had cscvs imports take _days_
<jelmer_> mwhudson: development6
<mwhudson> o
<mwhudson> k
<jelmer_> mwhudson: the fact that creating an inventory in 1.9-rich-root is O(tree) makes it really slow
<LarstiQ> slower than several hours you mean?
<jelmer_> LarstiQ: yeah
<jelmer_> you spent most of the time serializing and deserializing inventories
<mwhudson> jelmer_: i can believe that
<jelmer_> s/spent/spend/
<Peng_> beuno: Me what?
<beuno> Peng_, are you going to UDS?
<Peng_> beuno: No.
<Peng_> beuno & jelmer_: I merged the transport branch.
<jelmer_> Peng_: Cool, thanks!
<beuno> Peng_, you couldn't come?  or didn't get an offer to be sponsored?
<jelmer_> mwhudson: what's the best way to get those OOo / samba branches updating again
<jelmer_> mwhudson: ?
<mwhudson> jelmer_: again?
<Peng_> beuno: Um, let's say both. I don't even know anything about UDS.
<jelmer_> mwhudson: Well, last time you asked tbm (?) to trigger an update
<jelmer_> mwhudson: but doing it that way seems a bit labor-intensive :-)
<beuno> Peng_, we should get you to one of them and hack  :)
<mwhudson> jelmer_: spm
<mwhudson> jelmer_: they've got stuck again?
<Peng_> beuno: I dunno. I'm shy. And I dunno how useful I'd be. I still haven't done any major work. Plus I should've started eating dinner 20 minutes ago, and I'll go do that now. See you later, everyone. :) (Which is convenient for getting out of this conversation, but also true.)
<beuno> Peng_, enjoy  :)
<jelmer_> mwhudson: yeah
<Peng_> Quick question: does transport.stat() follow symlinks?
<jelmer_> mwhudson: but seem stuck even for smaller stuff, so it's impossible to use launchpad with reasonably large (>= 10k or something) development6 branches
<mwhudson> jelmer_: two points i guess: 1) we should be able to make changes soon that allow us to up the timeout
<mwhudson> 2) this means 15 minutes with no activity report -- that much be a bug somewhere
<mwhudson> must
<jelmer_> mwhudson: when does that timeout happen, during pull ?
<mwhudson> jelmer_: yes
<vxnick> what's the best way to move my repository including the ignored list?
<mwhudson> jelmer_: also branch outside a shared repo is really slow for dev6, i guess this is an indication of the same problem
<mwhudson> jelmer_: have you been having problems with mirrored branches too, or just hosted?
<jelmer_> mwhudson: both
<mwhudson> :(
<LarstiQ> jelmer_: tbm is Martin Michlmayer :)
<LarstiQ> vxnick: do you mean branch? Repositories don't have ignore lists.
<vxnick> LarstiQ: sorry, that's correct
<LarstiQ> vxnick: assuming the ignore list is nicely committed and everything, `bzr push` would be the operation of choice.
<vxnick> LarstiQ: push doesn't move the files though does it, just the history?
<jelmer_> LarstiQ: ahh
<jelmer_> LarstiQ: Too many TLA's >-)
<LarstiQ> jelmer_: there is only one tbm! ;)
<LarstiQ> vxnick: the history is the important bit :)
<LarstiQ> vxnick: a working tree can always be constructed if you have the history
<LarstiQ> vxnick: where do you want to move it from, and whereto?
<vxnick> LarstiQ: how so? I'm looking to shift the entire branch from my local machine to a remote server
<LarstiQ> vxnick: does it even need a working tree then? Usually the answer is no.
<vxnick> LarstiQ: but ideally I want to move the entire shared-repo
<vxnick> LarstiQ: it does in this case as I want to have the files viewable through a system similar to trac
<LarstiQ> vxnick: then you do not need a working tree.
<LarstiQ> vxnick: the system like trac will provide it.
<LarstiQ> vxnick: like, Loggerhead mwhudson, Peng_ and jelmer have been talking about.
<vxnick> LarstiQ: thanks I'll have a read :)
<LarstiQ> vxnick: for pushing an entire repo there is a repo-push plugin iirc (http://bazaar-vcs.org/BzrPlugins)
<vxnick> LarstiQ: that looks ideal, many thanks!
<LarstiQ> vxnick: np, let me know how it went
<vxnick> will do
<fullermd> q
 * fullermd slaps his mouse.
<vxnick> LarstiQ: worked a treat, thanks again :)
<LarstiQ> vxnick: good :)
<jfroy> jelmer: I just read a message you wrong on the mailing list where you mention push_merged_revisions. I'm not familiar with that setting, is it new?
<jfroy> *you wrote
<jelmer_> jfroy: no, it's been there for a while but never has been announced very publicly
<jfroy> Am I guessing correctly that it pushes RHS revisions as separate svn commits when pushing a merge revision?
<jfroy> *as separate svn revisions
<jelmer_> jfroy: yes, onto a separate branch
<jelmer_> or rather, separate branches
<jfroy> I'm not sure I
<jfroy> *I'm following completely.
<jfroy> Are you saying it creates a new "branch" in svn?
<jelmer_> jfroy: yes
<jelmer_> and uses the bzr branch nick for the branch name in svn
<jfroy> And I assume it guesses the bath based on its guess of the repository layout?
<jelmer_> so if you did a commit in a bzr branch called "feature-a" and then merged it into trunk
<jfroy> *the path
<jelmer_> bzr-svn would push the commits in feature-a into branches/feature-a in subversion
<jelmer_> and the merge commit onto trunk
<jfroy> gotcha
<jfroy> what happens if you pushed feature-a to svn yourself
<jfroy> then merge feature-a into trunk (locally) and push trunk
<jfroy> I assume, like any other bzr-svn push, that it will read the bzr-svn revprop and do the right thing?
<jelmer_> jfroy: yes
<jfroy> e.g. it will see it has no revisions to push, then move on to the merge revision in trunk
<jfroy> I like it :)
<jfroy> So where do I sign up for this goodness.
<jfroy> bazaar.conf?
<jelmer_> jfroy: yeah
<jelmer_> or locations.conf / subversion.conf for individual repo's
<jfroy> right, it's defined on BranchConfig which inherits from Config
<jfroy> so it should pick up the usual behaviors of bzr's config machinery
<jfroy> I think you should advertise it more.
<jfroy> It's pretty nifty :p
<jelmer_> I haven't used it much myself so it may still have some rough edges
<jelmer_> I agree it's pretty nifty though :-)
<jfroy> mmm
<jfroy> Well if I hit any snags I'll file bugs, as usual.
<jelmer_> thanks
<flacoste> hi there
<flacoste> i want to open a branch and look at the commit messages from a specific revision onward
<flacoste> any pointers on how to use bzrlib to achieve this?
<flacoste> i'm looking at log.py (but my head spins)
<lifeless> moin
<thumper> hmm...
<mwhudson> log.py is pretty much brain-pain
<thumper> merge sorted ?
<flacoste> thumper: i don't know what this means
<mwhudson> flacoste: all revisions, or just mainline?
<thumper> flacoste: it wasn't for you :)
<flacoste> just mainline
<flacoste> lol
<thumper> just mainline is easy
<lifeless> flacoste: b = bzrlib.branch.Branch.open(url)
<flacoste> yeah, i assumed so
<lifeless> b.lock_read()
<lifeless> revid = b.revno2revid(revno)
<lifeless> for revid in b.iter_revision_history(revid):
<lifeless>     print b.repository.revision(revid).message
<lifeless> or ~ that anyhow
<lifeless> iter_revisions or whatever its called is faster than getting inidividual revisions
<flacoste> ok and this will return revision from revno and more recent?
<flacoste> actually, excluding revno
<flacoste> i assume
<lifeless> oh, you want more recent
<lifeless> iter_revision_history(b.last_revision)
<lifeless> and then test for the exit point
<flacoste> makes sense
<flacoste> thanks a lot!
<flacoste> how do i release the lock?
<mwhudson> b.unlock()
<ronny> LarstiQ: sup on the easy_install issues?
<igc> morning
<jelmer_> hi ian
<flacoste> the only iter_ i find on branch is iter_merge_sorted_revisions
<igc> hi jelmer_
<thumper> igc: composite trees?
<igc> thumper: back to reviewing them today
<thumper> igc: cool
<igc> thumper: sorry for the delay - just not well enough last week
<thumper> ok
<abentley> igc: IIRC, the big sticking point is the text filtering.
<igc> abentley: hi. Right
<igc> abentley: a parameter exists in the WT API but not the Tree one
<abentley> igc: CompositeTree can contain RevisionTrees and WorkingTrees, but only the WorkingTree version supports text filtering.
<abentley> igc: Why isn't that already causing problems?
<igc> abentley: I'll think hard about it today. What problems would you expect?
<abentley> igc: I would expect bzr cat -r -1 to raise an exception because an unknown parameter was passed into it.
<abentley> igc: Where is text filtering actually used?
<poolie> igc, i like your three/four wishes, but they're a bit big to be used there
<poolie> by which i mean, i suppose, that "adoption blockers banished" could be just the only item on the roadmap for the whole duration of the project :)
<poolie> but i suppose it's fine
<igc> abentley: it's used implicitly most of the time
<igc> abentley: and explicitly in some cases like cat and export
<abentley> igc: So it defaults to True.  That's pretty gutsy.
<igc> abentley: for WorkingTree's, it really needs to
<igc> abentley: otherwise, every plugin needs to remember to switch it on
<igc> and command
<igc> abentley: IIRC, it used to live on the Tree API and default to True there too
<abentley> igc: Not every plugin and command, just those that want the filtered form.
<igc> abentley: but we backed out the change for .bzrrules, taking away historical storage of rules
<abentley> igc: it's still a subtle enough behavior change that bugs it introduces might not be caught by our existing tests.
<igc> abentley: in a sense, bzr has always used the internal form only
<abentley> igc: I think that the parameter should exist on Tree, but should only affect Trees which have a filtered form.
<igc> abentley: content filtering just means that what's in the tree is something else convenient for the user
<igc> abentley: that sounds ok to me
<igc> abentley: I'm pretty sure the text filtering issue was the only blocker wasn't it?
<mwhudson> jelmer_: do you have a list of other branches that are failing to pull correctly?
<abentley> igc: You gave me a tweak, and I upgraded it to resubmit because of that.
<igc> abentley: I almost suggested last week that you land your change and we work together on the text filtering as a follow-up/known issue
<jelmer_> mwhudson: lp:~jelmer/samba/trunk, lp:~jelmer/openoffice/trunk and lp:~jelmer/openoffice/hosted
<igc> abentley: given how little the text filtering is currently used
<jelmer_> mwhudson: beware of the last two though, they're both around 4.5Gb
<igc> (and that's because we don't have branch-specific rules yet)
<mwhudson> jelmer_: ah, the other two are mirrored branches
<mwhudson> jelmer_: it's a bit crap that the openoffice/hosted got stuck again
<mwhudson> jelmer_: did you push a lot of new revisions?
<jelmer_> mwhudson: about 100k
<abentley> igc: I'd be happy to do that.
<mwhudson> jelmer_: ok, i guess that qualifies as a yes
<jelmer_> mwhudson: :-)
<igc> abentley: cool. Let's do that then because I don't think anything else I've seen in your patches so far will be affected
<abentley> igc: I'm looking at the implementation of cmd_cat, and it doesn't pass filtered as a parameter to get_file_text.
<igc> abentley: it's using the Tree API from memry, where that parameter doesn't exist
<igc> abentley: RevisionTree API even
<abentley> igc: It seems to be using revision trees everywhere, and in that case, it makes no sense to filter, because the file is already in the internal form.
<igc> abentley: right, though the user can explicitly ask to see the output post-filtered
<abentley> igc: Post filtered meaning the internal form?
<igc> abentley: though, filtered then means "using configured filters", not historical filters
<igc> abentley: the filtering can go 2 ways
<igc> internal <-> external
<igc> get_file_text() filters external -> internal
<igc> abentley: in the case of cat, the filtering is the opposite way
<abentley> igc: If "filtered" can mean two different states, do you think it would be clearer to refer to the desired state instead?
<igc> abentley: perhaps
<igc> abentley: the text at the top of bzrlib/filters/__init__.py might be of interest btw
<abentley> igc: So this explains why no tests break even though CompositeTree doesn't support "filtered".  Nothing which uses CompositeTree is also providing that parameter.
<lifeless> abentley: we're going to need CT everywhere right?
<abentley> lifeless: No.
<lifeless> where won't we?
<lifeless> RevisionTree's for instance, shouldn't they be returned as CT's now?
<igc> abentley: probably because nothing wants the external form, only the internal
<Peng_> Possibly-dumb question: can branch references use relative paths?
<lifeless> Peng_: not currently
<mwhudson> Peng_: no
<Peng_> Darn. Thanks.
<abentley> lifeless: Most cases where we're writing to the tree, and cases where we handle nesting directly for read operations.
<Peng_> That'd explain why I wasn't using a relative path already. :D
<mwhudson> there was a thread about this on the bzr list semi-recently
<lifeless> abentley: I'd have thought that e.g. 'bzr ls -R lp:twisted' should recurse.
<abentley> lifeless: It probably should, but it's not on the list of commands I've committed to support.
<lifeless> abentley: this comes back to my strong feeling we should be putting the support inside regular trees rather than an optional external construct which people need to remember to use
<abentley> lifeless: I don't think that's practical.
<lifeless> abentley: why not?
<abentley> it makes everyone pay the cost of the feature, it makes recursion mandatory, it hides what's really going on, it makes the code trickier to debug.
<abentley> It's an all-or-nothing sort of solution.  We need an incremental one.
<abentley> If we can't start somewhere, we'll never get finished.
#bzr 2009-05-05
<lifeless> I think we could do it internally incrementally if we want to; I can answer the points you've put up, but debate-in-detail is often unfruitful for this sort of discussion
<abentley> lifeless: I know about your strong feelings.  The time to voice them was when I put CompositeTree up for review.
<lifeless> abentley: I did
<abentley> lifeless: Either veto my patch, or stop casting aspersions on it.
<lifeless> abentley: I'll shut up then; I've been hoping to change your mind, not to insult your patch
<lifeless> vetoing would block you and unilaterally impose my opinion
<lifeless> I don't want to do that
<abentley> lifeless: that could actually be productive, because at least we would resolve this.
<abentley> lifeless: Right now, your objections are functioning as FUD.
<lifeless> argh. ok.
<lifeless> ok, I'll veto and we can discuss
<abentley> thumper: I no longer have any idea how long Nested Trees will take to land.
<thumper> :(
<thumper> what's the issue?
<abentley> thumper: see above.  lifeless is vetoing CompositeTree.
<thumper> poolie: ping
<jelmer_> jonnydee2: hi
<jelmer_> jonnydee2: is bzr-config-cli still alive?
<jml> which format should I be dogfooding?
<jml> bzr: ERROR: ambiguous option: --development (--development-rich-root, --development-subtree, --development6-rich-root?)
<mwhudson> jml: the one with '6' in
<lifeless> jml: --development-rich-root,
<lifeless> jml: note its a rich-root upgrade, so safe for bzr-svn imports and little else at this point
<jml> well, this is a new branch
<jml> designed to carry one emacs lisp file
<lifeless> go for it
<jml> if it's not safe for that, there should probably be brighter, flashier, redder lights around the help text
<lifeless> its supported release by release, be sure to upgrade each release of bzr.
<jml> *nod*
<poolie> thumper: hi
<thumper> poolie: can we have a quick call?
<poolie> sure give me 5m? then just call if you want
<lifeless> if its re nested trees, mail is composed
<lifeless> ok, sent
<jml> lifeless: aws-status says I have 6 instances running
<jml> lifeless: amazon says I have one.
<jml> (I thought I had zero)
<lifeless> jml: it refreshes every 60 seconds
<lifeless> jml: could this be a 60-second out window?
<jml> lifeless: the instances shut down yesterday.
<lifeless> all but one :P
<jml> lifeless: it's more likely a network reliability issue.
<lifeless> did you run it from a console?
<jml> yeah, I just saw the stacktrace
<jml> pasting now
<jml> http://paste.ubuntu.com/164555/
<lifeless> ok, please turn that into a bug
<lifeless> I'll fix after work
<lifeless> beuno: I think you're exaggerating more than a little
<jml> spiv: ping
<lifeless> spiv: ping
<lifeless> jam: ping
<lifeless> spiv: I'd like to get together middayish, my place if possible, to plan out the rest of the week.
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> abentley: I have a question about root renames
<lifeless> I'm testing the issue with upgrade to rich roots you found
<lifeless> would you expect tree.rename_one('', 'child') to work ?
<abentley> lifeless: No.
<lifeless> ok
<lifeless> I'll do an unversion, add, add dance then
<lifeless> (I'm using branchbuilder)
<abentley> lifeless: You could apply an inventory delta, one that added a new root.
<lifeless> I don't think branchbuilder takes inv deltas
<lifeless> anyhow, unversion, add, add has worked - lovely test failures
<abentley> lifeless: Okay.
<lifeless> this fix should be done today
<lifeless> I had one other question, which is - have I missed any cases
<lifeless> I have:
<lifeless> No parents rev -> No parents
<lifeless>  1 parent rev -> 1 parent
<lifeless>  1 ghost parent -> No parents
<lifeless> 2 parents both heads -> 2 parents
<lifeless> 2 parents one head -> 1 parent
<lifeless> 1 parent different fileid, ours missing -> no parents
<lifeless>  1 parent different fileid, ours moved -> 1 parent
<lifeless>  2 parents, 1 different fileid, our second missing -> 1 parent
<lifeless>  2 parents, 1 different fileid, our second moved -> 2 parent
<lifeless> fin
<lifeless> abentley: ^
<abentley> lifeless: This is re: syntheizing a root history?
<lifeless> yes
<lifeless> the InterDifferingSerializer wasn't doing the same thing as the reconcile code looks for
<lifeless> fetch may be doing something subtley different again
<lifeless> I want to squash it solidly and permanently
<lifeless> so if you can think of other dimensions I should be testing across, or other values in the current space I should be checking, that would be grand
<beuno> lifeless, you should try and hang out during european working hours with developers
<beuno> working with bzr for the past month or two has been an enourmous pain in the ass
<beuno> I branch about a dozen branches a day
<beuno> maybe in one of them I can use the smart server
<beuno> the rest, sftp
<beuno> so basically it now takes about 7 times more to get something to review
<lifeless> beuno: yes, I really appreciate that. Note the difference between unreleased and released!
<beuno> lifeless, 1.13?  1.14?
<lifeless> 1.13 doesn't suffer bugs pulling
<lifeless> I need to grab some food, back in 15
<beuno> no, it creates broken branches
<beuno> if all of Canonical is going to be dogfooding bzr, we need more responsivness
<beuno> and that includes in a big part, better communication
<emmajane> beuno, you're so radical! :)
<beuno> :)
<beuno> hi emmajane
 * emmajane smiles and waves
 * beuno is grumpy
 * emmajane grins.
<emmajane> I'm *shocked*
<lifeless> beuno: so does 1.12
<emmajane> You may find humour in this: http://twitter.com/mmurray/status/1698763594
<lifeless> beuno: and 1.11
<lifeless> beuno: etc
<lifeless> beuno: once lp gets the hotfix, 1.13 pushing to bzr+ssh won't create broken branches
<lifeless> mwhudson: which reminds me, ^
<emmajane> beuno, apparently I'm getting a little soft in my old age. :)
<beuno> lifeless, right, and no good communication with all the teams as to how to avoid this has been made
<lifeless> beuno: what has been unclear; the bugs in question have good summaries, they've been the primary focus to fix, but they are not simple things to fix
<beuno> lifeless, as well as not deploying the script to fix this
<thumper> is 1.13.2 in jaunty-updates?
<beuno> as well as not cherrypicking a version that warns people when creating the broken branches
<lifeless> beuno: ?!?!?!
<lifeless> beuno: such a version would equally well not create broken branches
<lifeless> beuno: and we have - 1.13.2 is such a version
<beuno> lifeless, and the people who don't have 1.13.2?
<beuno> they continue to create broken branches
<lifeless> beuno: will, like the people who have 1.12 upload branches with insufficient data; the code team are looking at how to fixup those branches post-push at the moment
<lifeless> beuno: there are 6 separate releases *all of which* will create the ACF situation
<beuno> lifeless, I understand
<beuno> now
<beuno> you have to understand
<beuno> that the end result
<beuno> is that it's a pain in the ass to work on a daily basis
<lifeless> why didn' you downgrade to 1.13, the current release at the time?
<beuno> we *could* have told everyone STOP USING 1.13 NOW
<thumper> lifeless: the code treatment is likely to be "upgrade"
<beuno> because I wanted to actually help fix the problem
<beuno> and, as it proved
<lifeless> beuno: once we know the bug, suffering doesn't help fix it - once a fix is prepared testing the fix is good and helpful
<beuno> being on bzr.dev helped bubble up the NoRevisionPresent problem
<beuno> we have a policy of using bzr nightlies in most teams
<beuno> to help development
<beuno> replying "you should be using releases" is really not good for anyone
<lifeless> beuno: right, which is good. But when there is an issue in trunk you have to be willing to revert to stable, which has been QA'd. Bugs take time to fix.
<beuno> lifeless, no, telling people how to avoid making it worst, and making sure a stop-gap measure is in place ASAP is the way to go
<lifeless> beuno: I'm not saying 'change your policy to be 'use stable'', I'm saying 'when a nightly breaks, report a bug and switch to stable until its fixed'
<beuno> you have a script that fixes broken branches
<lifeless> beuno: yes, which is on the bug
<beuno> lifeless, right, which is basically as if it didn't exist for most people not following bzr development
<beuno> that script should be deployed already
<lifeless> beuno: you're really confusing me, you're jumping all over the place with different, largely unrelated things
<beuno> and/or in a plugin
<beuno> lifeless, maybe. I'm just saying, almost 2 months of brokeness, no matter what the reasons are, is very bad
<lifeless> beuno: see above, the code team are looking at running the script, harass thumper :)
<thumper> lifeless: we may run the script of the existing ones, and reject old clients, but we are not going to run the script post push on everything
<lifeless> beuno: we try to keep trunk as solid as possible, but sometimes this will happen. Running trunk *has risks*. We certainly appreciate people doing that and giving feedback, but don't be masoschists when there is a problem.
<beuno> lifeless, you guys need to coordinate
<beuno> not me
<lifeless> beuno: when edge breaks, people use production
<beuno> make sure the code team runs it
<lifeless> beuno: we *are coordinating*, but you're the one going critical here
<beuno> because users don't care on who's plate it is
<beuno> lifeless, yes. Almost 2 months, and still broken. Sounds pretty critical to me.
<lifeless> beuno: when a user chooses to run crack of the day, they need to be making an informed choice
<lifeless> beuno: go get some sleep or something.
<lifeless> beuno: we didn't have the fix script 2 months ago
<beuno> lifeless, I'm just saying something in the process needs to be improved
<lifeless> beuno: what precisely? We landed the code on the 17 march, in the 1.14 cycle
<lifeless> 1.14 released with the bug fixed.
<lifeless> lp is running 1.14 and putting together stuff to fix up existing branches
<beuno> lifeless, step zero is to communicate better
<beuno> when something like this happens
<lifeless> beuno: I asked about that before and got told about nightlies instead
<beuno> go in, and tell everyone what to do
<beuno> otherwise, you have half the people in 1.13, creating broken branches
<lifeless> beuno: they should stay on 1.13 during that period
<beuno> and the otgher half suffering with 1.14
<lifeless> beuno: because 1.13 1.12 1.11 1.10 1.9 1.8 1.7 1.6 all create broken branches
<beuno> lifeless, don't tell me
<lifeless> we put it in the bug
<beuno> tell the 70-ish developers cursing every time they have to review someone's branch
<beuno> lifeless, it turns out, not everyone reads all bugs in Launchpad
<lifeless> beuno: they don't lookup the symptoms when they encounter a problem ?
<beuno> lifeless, no, they ask around until someone unblocks their work
<beuno> people get fed random recipies
<beuno> which make problems worst
<lifeless> please be a little more concrete. Are you saying blog? mail bzr-announce? mail bzr-dev ? (which we did, I think)
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed]
<lifeless> that bug was *reported* april 3rd
<lifeless> one month
<beuno> lifeless, I think this merits a blog post with the details + email to warthogs
<lifeless> I get your frustration, but you're not actually helping much right now. Better communication - *how*. What forum is there for 'users of unreleased code' that will get 'everyone' which seems to be your gold standard for better communication
<SamB> lifeless: hitting them upside the head with a ... hmm ... copy of the Linux Kernel, on paper?
<beuno> lifeless, for Canonical folks, warthogs
<lifeless> SamB: that would certain get their attention, if they remember the incident through the retrograde amnesia that will ensue
<SamB> lifeless: could use just a small fraction of it, then
<beuno> lifeless, and a blog post on planet
<lifeless> beuno: It seems to me like we have a bunch of people running trunk that aren't tracking the project; this is like running Ubuntu's devel version without being on Ubuntu-devel - its not that good an idea.
<lifeless> *things happen* during development.
<beuno> lifeless, it isn't when it's a company policy
<lifeless> beuno: policy doesn't change risk
<lifeless> beuno: are you on ubuntu-devel? I certainly am
<beuno> lifeless, I'm everywhere
<beuno> but that's not the point  :)
 * SamB only runs bzr.dev because jelmer is always telling him to pull it ;-P
<lifeless> beuno: I think it rather is
<beuno> lifeless, you don't really expect all developers to track bzr's development?
<lifeless> we can certainly mail warthogs about the current status of this, now and in future.
<beuno> I understand how hard this is
<lifeless> beuno: I don't expect people to track *trunk* and not be at least following something [perhap bzr-announce?] to ensure they can be communicated with
<lifeless> we have a group for launchpad beta users
<SamB> beuno: who made a policy like that?
<lifeless> I assume everyone in the company is in that group
<lifeless> SamB: Canonical has a general dogfood policy - where we create something, we use it ourselves
<beuno> lifeless, sure, we may have to adjust things
<SamB> lifeless: oh, is he in canonical?
<lifeless> SamB: (use it in beta and release at minimum), to improve quality
<lifeless> SamB: we hired beuno, yes
<SamB> ah.
<SamB> must have missed that
<lifeless> beuno: you need to communicate better :P
<SamB> maybe you should have a company-wide email list or something
 * beuno grins
<beuno> SamB, we have like 60 mailing lists
<lifeless> SamB: we do, but this issue is equally applicable to folk outside the company tracking trunk
<SamB> lifeless: yeah.
<jelmer_> maybe you need to do more cross-posting >-)
<SamB> maybe!
<SamB> okay, so what's this list I should be on but aren't?
<lifeless> beuno: So I think two things; one is the policy should be more clear about what to do when there is an issue - ensure there is a bug, downgrade to release, get on with your work.
<lifeless> SamB: bazaar@lists.canonical.com is the current list that issues with trunk are discussed on
<beuno> lifeless, if bzr breaks something so critical, I expect the team to actively engage it's major users, no matter who they are
<beuno> lifeless, yes, a big part of it is policy
<SamB> hmm.
<beuno> which we need to coordinate better
<beuno> I'm sorry to jump out of this one, but I *really* need food
<SamB> lifeless: that's way too high-traffic for me to actually follow
<lifeless> beuno: secondly, perhaps we should have another list/lp team/whatever where people that are tracking trunk to contribute, but not interested in discussing bzr at all, should subscribe to
 * emmajane offers beuno some birthday cake.
<lifeless> SamB: yes, and even if it was just regular users I think it would be too
<lifeless> SamB: bzr is actually fairly popular :P
<poolie> lifeless: spiv is away sick today
<emmajane> SamB, did you know you can ignore a lot of the messages? There are subscription options that make the list a lot more manageable.
<lifeless> poolie: ah
<emmajane> SamB, I also sort by thread and *ahem* delete a lot of the stuff that's over my head.
<emmajane> SamB, Filters help too. I only look in my "bazaar" folder when I've got extra energy.
<poolie> lifeless: since andrew is away and since beuno reports it's hurting people a lot, would it make sense for you to work on bug 360791 ? do you have enough of the state?
<ubottu> Launchpad bug 360791 in bzr/1.14 "get_stream on stacked branch causes "Error received from smart server: ('NoSuchRevision',)"" [Critical,In progress] https://launchpad.net/bugs/360791
<lifeless> poolie: I can acquire that state; do you know if spiv has stuff in-flight that I should get off him?
<lifeless> poolie: I want to finish the current patch first, as its nearly done.
<poolie> he was still working on it yesterday
<poolie> he's apparently still somewhat alive so you could perhaps call him briefly
<lifeless> poolie: and is also quite critical, given it blocks people upgrading accurately to rich roots - its critical path for bbc transition
<poolie> right, i know
<lifeless> I propose that I finish the current patch to avoid thrashing; and ring him when I'm done to ensure I have his in-progress work.
<abentley> lifeless: I don't know what "moved" means.
<lifeless> abentley: old tree: '' is ROOT_ID, 'child' is 'my-root'. new tree: '' is 'my-root'
<lifeless> abentley: so 'my-root' has moved from 'child' to ''.
<SamB> emmajane: I do subscribe to the list, but I never really look at it unless either someone tells me to or ... well, I can't think of another reason ;-)
<emmajane> SamB, do you have the list filters on so that you don't get the code-y things?
<emmajane> SamB, MERGE and something else can be filtered out IIRC
<abentley> lifeless: I can't think of any more cases.
<SamB> hmm, yeah, merge would be easy to filter out
<lifeless> abentley: cool, thanks.
<emmajane> SamB, check the mailman page. There are some built-in options for the list.
<SamB> but shouldn't there be a list for really important issues to be announced on?
<lifeless> we have bazaar-announce
<emmajane> SamB, it's version control. Everything is important. :)
<lifeless> but I would expect packagers and release-only users to perhaps be unhappy about issues with unreleased code going there
<SamB> I'm thinking bugs where your data gets messed up but you don't know until way later
<SamB> lifeless: it also doesn't sound dangery enough
<SamB> bazaar-warn, maybe?
<lifeless> I'd really rather not call a list that ;)
<emmajane> bazaar-omgwtfbbq?
<SamB> bazaar-bleed?
<lifeless> emmajane: :)
<emmajane> bazaar-yourerunningtrunkyoushouldknowbetter?
<SamB> bazaar-oh-great
<emmajane> bazaar-SRLSY?
 * emmajane goes back to her bazaar-scotch. :)
 * SamB wonders what the easiest way to run a program in a Linux kernel under a debugger is ...
<SamB> (that is, the kernel is under the debugger ...)
<lifeless> hmmm, I have load 11
<lifeless> but no disk and the system is snappy... anyone else seeing this on jaunty?
<SamB> what is this load thing?
<SamB> is it possibly a highly-bogus figure?
<AfC> SamB: load := number of processes in the runable state
<SamB> that sounds pretty bogus to me
<SamB> (once it starts to average more than 1)
<fullermd> All metrics are bogus   :p
<SamB> yeah, but that sounds more bogus than bogomips!
<fullermd> As a measure of contention for CPU, load average is often a decent rule of thumb check.
<fullermd> Mind, by the time it hits 3000 or so, it starts getting too expensive to calculate to be worthwhile...
<SamB> it doesn't account for niceness or anything though
<lifeless> AfC: linux also includes procs waiting on IO
<AfC> lifeless: I didn't know that. Huh. Thanks!
<fullermd> Nor for network or disk IO, or memory pressure, or any number of other things.  But then, defining something that broad that distills to a single number is somewhat more difficult.
<lifeless> http://en.wikipedia.org/wiki/Load_(computing)
 * SamB wishes top showed IO utilization ...
<lifeless> SamB: iotop
 * fullermd looks at his top which DOES have an IO showing mode...
<fullermd> (of course, assigning IO to a particular process isn't a faultless process either)
<SamB> fullermd: I meant in each row
<SamB> or did you also?
<fullermd> Yah.
<fullermd>   PID USERNAME      VCSW  IVCSW   READ  WRITE  FAULT  TOTAL PERCENT COMMAND
<SamB> what top is that?
<SamB> or, er, how do you get that?
<lifeless> bsd :)
<SamB> oh
<SamB> pooh
<SamB> anyway, I know it's not faultless, but it's nice to know *A* process that needs the IO done ;-)
 * igc food
<lifeless> SamB: try iotop out
<wgrant> Why would I be getting a mismatched rich-root support error when attempting to reconfigure --standalone?
<lifeless> bug something or other
<lifeless> reconfigure doesn't preserve format
<mwhudson> jelmer_: so you fixed a memory usage issue you say?
<mwhudson> oh nm
<mwhudson> https://code.edge.launchpad.net/~jelmer/openoffice/hosted now has over 250k revisions :)
<lifeless> nice
<mwhudson> and codebrowse continues to somewhat work
<Peng_> It somewhat works? That's somewhat good to know. :P
 * mwhudson reads planet bazaar, becomes hungry
<vila> hi all
<vila> Argh, no wonder nobody reviewed my payches.... mail don't go out since last saturday :-(
<poolie> hello vila
<poolie> igc, what's the reasoning behind copying HACKING.txt around when building the docs?
<igc> poolie: the doc gets built & copied as a full tree, e.g. http://doc.bazaar-vcs.org/latest/developers/index.html
<poolie> i guess what i meant is
<poolie> the rest source lives in doc/developers/HACKING
<poolie> but the html output is sent to doc/en/developer-guide/HACKING.html
<poolie> i guess this is just for historical reasons
<igc> poolie: I'm happy for the rest source to move
<poolie> done
<poolie> thanks
<igc> poolie: it location is historical
<poolie> i thought so
<igc> poolie: once upon a time before we had the nice catalogs we do now, I guess the source location was more important
<igc> poolie: now I'd expect most developers to find the html easily enough
<poolie> i've just moved the source to be in the same location as the html to avoid minor confusion
<poolie> i think i once started editing the wrong copy of the text file
<igc> poolie: cool. Thanks.
<poolie> it's all fine now though, thanks
<lifeless> hi vila
<vila> lifeless: hi
 * igc dinner
<Lo-lan-do> Hi all
<Lo-lan-do> Is there a way to get bzr to "forget" the submit or parent branch?
<Lo-lan-do> (Apart from editing the .bzr/branch.conf, that is)
<lifeless> Lo-lan-do: remember a new one
<poolie1> night all
<Lo-lan-do> Hm.  Yes, that would work, of course.
<Lo-lan-do> Except it needs some non-transparent operation to happen, doesn't it?
<Lo-lan-do> Such as merging (for the submit branch) or... I don't even know how to remember a new parent branch.
<intellectronica> hi, trying to branch from an LP-hosted branch using bzr from the nightlies PPA, i get "Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")". any ideas?
<lifeless> intellectronica: use nosmart+ before the url or an sftp url
<lifeless> intellectronica: there is a bug in older bzr's that causes branches to individually generate that message
<intellectronica> oh right, so if i re-upload the branch with a new bzr it will be ok?
<lifeless> intellectronica: or you can run te fix script
<lifeless> https://bugs.edge.launchpad.net/bugs/354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed]
<lifeless> there are a couple of bugs related to streaming at the moment; in general ifyou can't get a brnach use nosmart:+ or a http or sftp url.
<maxriskfactor> i have been trying to use bzrlib to list the files under a working directory, can someone help me in this reguard
<awilkins> jelmer: Did bzr-gtk get upgraded to rich-root?
<jelmer> awilkins: yep
<awilkins> aha.
<awilkins> jelmer: 1.9 or 1.14?
<awilkins> Hmmph, info says "unnamed". V.unhelpful.
<jelmer> awilkins: either should work
<jelmer> awilkins: I upgraded to 1.9-rich-root
<awilkins> I'll stick to 1.9, my users are still on 1.13
<jelmer> lifeless: ping
<jelmer> awilkins: I think 1.14 only matters for the working tree format anyway
<awilkins> I only really use bzr-gtk for gconflicts now
<awilkins> And a local patch of it, at that
<jelmer> awilkins: no viz?
<awilkins> I use qlog for that
<awilkins> How's viz now?
<jelmer> ah
<jelmer> viz is still the same
<jelmer> what's better about qlog?
<awilkins> Let me try viz again for a mo and I'll think about it
<awilkins> Ok  (silly) : qlog looks more native on win32 and has font smoothing, etc
<jelmer> ah, of course. I'd forgotten you were on win32
<awilkins> (practical) qlog has a "files that changed" pane from which you can trigger a file diff
<awilkins> It also has expansion of merge points
<awilkins> Over half the width is consumed with the DAG on viz, on qlog you only get this if you expand a few nodes
<james_w> double click a revision to see the changes
<awilkins> qlog could do with a heck of a lot more context options (which viz seems to have in menus)
<awilkins> Both of them need to be able to be configured to use external diff utils
<awilkins> When considering this sort of thing I think TortoiseSVN is a great place to start
<awilkins> You can't go too far wrong just ripping off their feature sheet
<awilkins> Maybe I should post some thoughts on the list when I have time ; I've used TSVN a hell of a lot, I admin our in-house SVN repositories.
<awilkins> There are things like the filter box - needs a path filter option (even if it would be slow although I'm not sure how slow it is on the newer branch formats now)
<lifeless> jelmer: pong; just fixing raid controller software, so you'll only get a little bit of attention
<jelmer> lifeless: does PQM ignore duplicate submissions?
<lifeless> jelmer: GPG dups yes, others no, but if no changes are found it bounces the second
<jelmer> lifeless: ok, then it'll bounce - thanks
<ronny> moin
<jelmer> hey ronny
<ronny> sup
<ronny> older bzr versions still arent easy_install-able
<zyga> hello, I wrote a simple plugin that allows for filtering by changeset author
<jelmer> ronny: I think LarstiQ was looking into that
<jelmer> LarstiQ: ^
<zyga> I did it in a pretty hacky way because I could not find any better APIs to do it
<zyga> I removed log._make_search_filter from available log adapters
<zyga> and then added my own _make_author_filter function that understands author: prefix of the search argument
<zyga> I was wondering if there is a better way to do it
<jelmer> igc: you might want to talk to igc when he's around, I think he did a lot of work on log recently
<zyga> basically I'd like to have "bzr log | grep author" that is smarter
<zyga> can anyone please point me to some API's/people that could show the way?
<Lo-lan-do> zyga: I think jelmer's last message was for you :-)
<jelmer> zyga: one way is to just register a new log formatter that only shows revisions by a particular author
<zyga> Lo-lan-do: oh, thanks - I'll look for igc then
<zyga> hmm
<zyga> hmm :-)
<zyga> I'll look into that, maybe it's easier than I though
<Lo-lan-do> jelmer: Does the current lp:bzr-git depend on some dulwich version newer than 0.2.0?
<zyga> that's bad in one way though: you loose all the --long --short, etc options
<zyga> I really thought that the search filter was a good idea except for lack of sensible API for adding new search terms (I had to hijack the whole search to do it)
<igc> zyga: An improved search filter is the right general approach
<igc> zyga: see http://bazaar-vcs.org/Roadmap/Log as well
<igc> zyga: basically, we need:
<igc> 1. some agreed search language
<zyga> igc: hi,
<igc> 2. a parser that converts it into a compiled query object
<igc> 3. a search filter that takes that query object and returns matching results
<jelmer> Lo-lan-do: yeah, it depends on dulwich trunk
<zyga> igc: right
<igc> #3 can probably be done first
<jelmer> Lo-lan-do: bzr-git 0.2.0 and dulwich 0.2.0 should work together
<zyga> igc: maybe 3 can be done now as a plugin
<Lo-lan-do> jelmer: I see.  I just found out that I could bzr branch git://something (I didn't manage to branch a local repo), I'll experiment with that before trying to upgrade.
<zyga> along with a new log command that uses it
<zyga> (logging is pretty complex though)
<zyga> as for 1 and 2 that can be simplified for now as long as we keep api for 3 stable and keep it off the bzr.dev
<zyga> (this way nobody has expectations on stability of the UI)
<zyga> and a sensible thing can be though out later
<igc> zyga: hmm - I'd like #3 to be core code; then plugins can experiment with various languages for building the queries
<igc> zyga: a plugin to try out #3 is fine though
<jelmer> Lo-lan-do: local repositories should also work
<zyga> igc: yes that's sensible - I was thinking about devloping the whole thing as a plugin (it's easier for me) and then keeping 1 and 2 unstable until some brainstorm decides about them since they are UI features
<Lo-lan-do> jelmer: Maybe I'm doing something wrong then, but I get an AttributeError: 'Repo' object has no attribute 'open_index'
<jelmer> Lo-lan-do: that means you need a newer dulwich
<jml> lifeless: is the presence of a '.' in an hpss method name a necessary and sufficient indicator that that method is *not* a VFS call
<jml> ?
<igc> zyga: sure
<Lo-lan-do> jelmer: Right.  So I'll keep trying out what I currently have and upgrade dulwich when I find myself familiar with how things work.
<jml> actually, I'll throw that question to the whole channel
<zyga> igc: I'll hack on a copy of cmd_log and craft a simple search support on that
<zyga> when author search works again I'll publish the code so that someone can have a look at it
<zyga> thanks for the insight and help
<igc> zyga: why do you think you need a custom cmd_log?
<zyga> how would you add new features to cmd_log?
<igc> zyga: we're just extending the -s option with a smarter string, yes?
<igc> zyga: take a look at the bzr-search plugin
<zyga> igc: ok wait
<igc> zyga: from memory, it provides a custom implementation of the search filter just like you need to
<zyga> yeah I just noticed it's mentioned in cmd_log docstring
<jml> Answer: no
<zyga> igc: argh, it requires a built index
<zyga> igc: that's bad - but I'll look at the API
<igc> zyga: you don't need to do anything as complex as bzr-search, just reuse the pattern it uses to patch in it's own search filter
 * jml runs a full selftest
<jml> how long does it take these days?
<bob2> FOREVER
<zyga> igc: hmm, it's doing something similar as I did but with additional trick :-()
<zyga> igc: it removes the original log adapters but instead of totally loosing them it calls them in their own adapter as a fallback
<jml> hmm.
<jml> I don't have forever.
<zyga> igc: but I still don't get something
<zyga> igc: how do I extend log to add search without new cmd_log2?
<igc> zyga: cmd_log should be calling into the log adapter "pipeline" ...
<igc> zyga: changing the pipeline ought to be enough IIUIC
<zyga> It already does
<zyga> but how to add new options (search query)
<igc> zyga: ah
<igc> I don't think you want a new option
<igc> just extend the meaning of the -s value
<igc> e.g. ...
<zyga> -s ? where is it defined
<igc> bzr log -s "author:me" ...
<zyga> (I'm based on 1.14.1
 * jml just sent a simple patch to the list.
<lifeless> jml: --parallel=fork
<lifeless> jml: also, no, its not in principle, but it may be enough for now, and please file a bug that you want to be able to know reliably.
<jml> lifeless: I figured something else out instead.
<jml> lifeless: see the patch I just sent to the list
<jml> but maybe not now, since I'm going to prepare a hot chocolate and retire for the evening.
<lifeless> jml: remind me tomorrow and it will get my full attention
<igc> zyga: sorry - I meant --message or -m
<jml> lifeless: will do.
<zyga> ah
<zyga> that's sensible
<zyga> I'll look into it
<igc> zyga: we can always alias --message to --search later
<zyga> right
<lifeless> zyga: bzr-search uses -m too
<zyga> yeah I'm on to it - just wait for a moment
<lifeless> zyga: I'd love to change the meaning of -m to be a nicer language than regex, it limits bzr-search a lot
<zyga> what is the python version all bzr code should run on?
<zyga> 2.4?
<jelmer> zyga: yep
<lifeless> zyga: for bzr core, 2.4. plugins can choose to support only newer versions if they want, but we like it when they support 2.4 and up.
<igc> night all
<lifeless> gnight igc
<vxnick> has anyone any experience integrating bzr with redmine (http://redmine.org)
<jelmer> igc: thanks for the reviews
<jelmer> 'night igc, lifeless
<jelmer> beuno: ping
<beuno> jelmer, hi
<jelmer> beuno: What happened to your plugin management code?
<lifeless> jelmer: I wrote bzr-plugin-info which is meant to seed a plugin db
<beuno> jelmer, I never finished it, unfortunetely. Code is out there (or I could push it), but it's diverged by maybe a year by now  :)
<jelmer> beuno: :-/
<jelmer> lifeless: it's a bit of a chicken-egg problem I guess
<zyga> wooyt
<zyga> igc: it works :-)
<zyga> igc: the API is not perfect yet because it hardcodes all(...) but it's not far away from full-blown logic tree
<zyga> igc: search terms are pluggable
<zyga> igc: simple searching for properties like author is trivial to add
<zyga> igc: I'd love to have a python-like logical expression parser:
<zyga> something that could parse:
<zyga> EXPR: EXPR and EXPR | EXPR or EXPR | not EXPR
<zyga> EXPR: property
<zyga> EXPR: property=value
<zyga> right now I can do: bzr log -m author:someone
<zyga> which works rather well :-)
<liw> do you think it would be acceptable for "bzr add", when it walks the directory tree, to go through subdirectories in alphabetical order? this would make it easier to have a clue about how far it's gotten, for very large trees
<james_w> liw: does "bzr add -v" print info about what is being added?
<james_w> or you already have the info and you just want to know what is coming next?
<liw> james_w, it prints the names it adds already, yes
<liw> what I mainly want is to know how much longer this is going to take, of course
<james_w> it may be that adding a sorted() call is easy
<james_w> or it may be that it would not perform at all well
<james_w> having full progress info is difficult though, as it requires two full tree walks, and the assumption that nothing changes between the two
<liw> yeah, that's why I thought just sorting the list of directories would be good enough (for me)
<jelmer> Is there some easy way to import an arbitrary file as a module in Python?
<liw> jelmer, I think so
<liw> jelmer, the imp module, I think
<jelmer> liw: Ah, thanks
<liw> hm, it's as if it is doing the directory tree twice anyway (I'm sure I've seen those directory names before)
<Lo-lan-do> jelmer: My git.db is acurrently 152M, and I'm only "fetching revisions 4962/6104".  Does that sound right?
<lifeless> zyga: I rather like googles search syntax; it sounds like you are doing something similar - +1 to that :)
 * ronny pokes LarstiQ 
<jelmer> Lo-lan-do: Yeah, it can become pretty large
<Lo-lan-do> The "bzr branch" seems to be slowing down pretty drastically, too.
<liw> does 5+ gigabytes of RSS memory count as a big bzr process?
<jelmer> liw: YES
<jelmer> I mean, yes
<jelmer> Didn't mean to shout :-)
<jelmer> Lo-lan-do: For better performance try newer dulwich/bzr-git
<liw> at least it's still running
<jelmer> liw: what are you trying to do exactly?
<liw> jelmer, I have a fever and a cold, so I am not able to do anything that requires a brain... so I'm being silly and torturing bzr
<liw> by importing jaunty's unpacked source packages
<liw> bzr has stopped printing out pathnames, I wonder if that means it's about to be done?
<Lo-lan-do> bzr branch lp:dulwich says bzr: ERROR: bzrlib.errors.SHA1KnitCorrupt: Knit <bzrlib.knit._VFContentMapGenerator object at 0x9202fec> corrupt: sha-1 of reconstructed text does not match expected sha-1
<zyga> lifeless: I can do simple boolean logic over expressions but I'd like to hear some kind of agreement over what is really wanted
<zyga> lifeless: I can publish my plugin soon (corporate env)
<jelmer> Lo-lan-do: You've probably hit a bug in bzr-git
<jelmer> vila: ping
<vila> jelmer: pong
<jelmer> vila: can you include a copy of the GPL in bzr-webdav?
<jelmer> vila: (required for inclusion in Ubuntu)
<Lo-lan-do> jelmer: "bzr --no-plugins branch http://people.samba.org/bzr/jelmer/dulwich/trunk/" fails similarly
<jelmer> Lo-lan-do: Ah, this must be a bug I fixed recently
<jelmer> Lo-lan-do: (dulwich is maintained in git but developed using bzr)
<Lo-lan-do> Nice to know such a setup already works :-)
<vila> jelmer: done and committed on lp
<jelmer> vila: thanks
<Lo-lan-do> jelmer: Is the reverse already possible (bzr repo accessed through git)?
<Lo-lan-do> I guess it's the bzr-*-pack stuff, but I have no idea if/how it works :-)
<Lo-lan-do> Also, in your setup, can you handle several branches?
<jelmer> Lo-lan-do: you mean a git-compatible smart server that accesses bzr branches?
<jelmer> Lo-lan-do: jc2k has done some work on that, I'm not sure what the current state of it is
<jelmer> Lo-lan-do: I do have multiple branches, but can't access anything other than HEAD in git repositories (since bzr doens't support colocated branches yet)
<liw> success!
<liw> I did "bzr add" on the unpacked ubuntu jaunty source tree
<liw> now let's see if commit works
<jelmer> whoa :-)
<Lo-lan-do> jelmer: Thanks.
<liw> the add required about 8 gigabytes of RAM
<Lo-lan-do> Jc2k: Ping (status of bzr-{send,receive}-pack?)
<Lo-lan-do> liw: You're crazy.  But it had to be tried :-)
<Lo-lan-do> liw: Next step: try the same on Debian.
<liw> Lo-lan-do, I've tried it on etch sources before, years ago, and bzr failed
<Lo-lan-do> If bzr can handle that, it'll handle anything :-)
<liw> ubuntu and debian should be on the order of magnitude the same size, shouldn't they?
<Lo-lan-do> Possibly.  I was under the impression that we had lots more crap^W"fringe packages" in Debian.
<lifeless> liw: --development-rich-root?
<liw> lifeless, yes
<LarstiQ> ronny: hey, I still want to read the easy_install code to see if it can handle multiple indirections. I'm going to do that tomorrow (wednesday is my day off)
<LarstiQ> ronny: if that fails, I'll take one of the other outlined measures
<LarstiQ> ronny: so expect easy_installability tomorrow
<exarkun> So I'm curious about how the revision data associated with a revision number in a particular branch can change over time
<exarkun> Is there something I should read?
<Lo-lan-do> exarkun: Revision numbers are just a convenience.  What matters is the revision id.
<Lo-lan-do> If a branch is overwritten, the revision numbers will overlap, but not the revids.
<exarkun> But even if you don't overwrite a branch, then you still can't treat revision numbers as stable, right?
<exarkun> Or is resolving divergence equivalent to overwriting a branch?
<Lo-lan-do> You're right.  If you pull from another branch, even if you only add revisions, you might change your numbers.
<james_w> exarkun: if you only "merge" other branches then numbers will only be added
<james_w> any numbers you currently have will not change
<exarkun> thanks
<ronny> LarstiQ: dont try to read easy_install, its a fucked up pain
<dahoste> I have a bzr 'admin newb' question.  I want to manage authentication for a shared repo similar to how I've done it with svn, namely via DAV in a <Location> block in apache, which lets me use things like either basic apache auth, or defer to LDAP, etc..  All of the bzr examples I'm seeing are using sftp, and I don't want to give full shell accounts just to grant write access to a bzr repo.   I'm not seeing documentation for bzr that talks about how
<dahoste>  to administer auth for a repo.  Can anyone point me to some relevant howto or something.  Apologies if it's someplace obvious and I missed it.
<liw> dahoste, you can a) use the bzr server mode ("bzr serve" I think, though I haven't done that myself); b) set up a "patch queue mananger" (PQM); or c) configure ssh for the accounts to only allow sftp
<liw> dahoste, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server might be useful
<liw> dahoste, there may be other ways, too, but I'm too ignorant
<dahoste> liw, roger that.  (a) isn't appealing, I want to get this working through apache.  (b) probably will come into play - I like the PQM model.  (c) doesn't work for me, since I don't want to muddy my user's auth with YetAnotherLogin - I want to get bzr access working alongside existing svn repos, and I have users with long-standing auth credentials used for svn (and other stuff -- some of it's LDAP).
<dahoste> liw, I think I need to get smarter about the bzr writing via the http-webdav plugin.  That might be the ticket.
<dahoste> liw, this just struck me as a common 'migration from svn' issue, since a shared svn+http/s repo with users auth'd through apache is par for the course for svn.  Figured surely there'd be an easy way to get the same usage working for bzr.
<pygi> dahoste, what's wrong with using clue-bzrserver?
<dahoste> pygi, possibly nothing.  I'm not aware of it.  Or wasn't...
<a_c_m1> can you clear the slate (so to speak) with anything thats not yet commited
<a_c_m1> e.g. i bzr add by mistake
<Lo-lan-do> a_c_m1: bzr revert
<pygi> dahoste, its bzr+http, but oh well :)
<pygi> dahoste, I mean it still isn't perfect, but it works
<a_c_m1> Lo-lan-do: thanks :)
<Lo-lan-do> a_c_m1: You can even use it on one particular file if you just want to revert that one.
<dahoste> pygi, well... anything that lets me auth without having to hand out full shell accounts is a candidate as far as I'm concerned.
<pygi> dahoste, ok, clue-bzrserver works then
<pygi> did you already google it or?
<dahoste> pygi, reading now...
<Peng_> jelmer: ping
<Lo-lan-do> $ bzr help dpush
<Lo-lan-do> Purpose: Push diffs into a foreign version control system without any
<Lo-lan-do> Usage:   bzr dpush [LOCATION]
<Lo-lan-do> Without any what?
<Lo-lan-do> Purpose?
<jelmer> Peng_: pong
<Peng_> Heh.
<jelmer> Lo-lan-do: that's fixed in 1.14 IIRC
<Peng_> jelmer: I thought so too, but it doesn't seem to be.
<Lo-lan-do> Oh.  I guess it's the "Bazaar-specific metadata." later on.
<Peng_> Lo-lan-do: Yeah.
<Lo-lan-do> 1.14-2 here
<Peng_> Lo-lan-do: It doesn't push any of the metadata. This way your svn repo won't have tons of "bzr:" properties, but OTOH when you pull again bzr won't recognize it as a bzr revision.
<Peng_> jelmer: With lp:~jelmer/loggerhead/transport, why did you move the stat() in directory_ui?
<Lo-lan-do> Thanks to jelmer, I have ceased doing dpush on SVN (bound branches work so much better).
<Lo-lan-do> I was reading on dpush for git.
<jelmer> Lo-lan-do: yeah, dpush works quite well for git atm
<Lo-lan-do> Good to know, but since I collaborate with git users on several branches, I guess I'll have to either wait for the colocated branches or (my favourite) the git-{receive,upload}-pack stuff to work.
<Lo-lan-do> In the meantime, we keep SVN as a pivot.
<jelmer> Jc2k: ping
<Lo-lan-do> No hurry... I'm about to go out for drinks.
<Lo-lan-do> But I'll read the backlog when back :-)
<jelmer> Peng_: Which stat?
<Peng_> jelmer: The one over the directory listing to make sure they're all directories. It used to be done to filter the list, but you moved it to only be done if Branch.open failed. Then I moved it back.
<Peng_> jelmer: Was it just to get rid of the list comprehension or to reduce the number of stat()s done or something else?
<jelmer> Peng_: to reduce the number of stats, as we'd only do it in case something is not a branch now
<Peng_> jelmer: OK, I'll put it back, then.
<Peng_> Sorry. :\
<Jc2k> jelmer: pong
<TDT> Hey all,  I'm running into a weird issue that just came up today - I'm receiving this error: bzr: ERROR: Server sent an unexpected error: ('error', 'No module named bz2') -- I googled for this information, and didn't find anything.  Does this have to do with compression when sending chunks over the net?
<jelmer> Jc2k: hi
<jelmer> Jc2k: we were just wondering what the status of bzr-*pack in bzr-git is atm, does it work?
<jelmer> Jc2k: also, did you see my msg about hg-git picking up dulwich?
<jelmer> vila: bzr-webdav is now in karmic
<jelmer> vila: your http multi-auth patch is huge :-/
<LarstiQ> TDT: ehm, it is a bit surprising the standard bz2 module is missing from your python install?
<Jc2k> jelmer: i saw your message and blogged it :)
<Jc2k> jelmer: i dont know about the state of bzr-*-pack - it might have bit rot
<Jc2k> jelmer: when i last played with it, it worked for git-only stuff
<jelmer> Jc2k: ah, nice, haven't seen that yet
<TDT> LarstiQ: Very surprising actually, especially since 3 machines, two if which I'm sure worked, suddenly don't...recompiling to see what happened.
<LarstiQ> TDT: did they get upgraded?
 * LarstiQ catches the tram
<TDT> LarstiQ: Fixed it, was a horribly stupid reason this was happening...didn't expect it to be a problem, but meh
<orsonj> does bzr determine that a number of different files are identical and store them compactly in the repo?
<Peng_> orsonj: No. Well, the new disk format (development6-rich-root) does, IIRC.
<orsonj> I might have to play with that. I have one situation where I have a bunch of files that are hard linked several times each
<orsonj> The repo ended up taking up a lot more space than the actual files.
<orsonj> Is there a way to remove files from the version history without bothering other versioned files?
<orsonj> (aka to save space, this has been a space hogging experiment)
<GaryvdM> No - by design - you can
<GaryvdM> 't modify any old revisions
<GaryvdM> sorry - enter instead of '
<orsonj> I only have a few revisions, so I'll just extract and rebuild without the large files.
<AmanicA> you may be able to filter them out with bzr-fastimport , but I don't really know how
<AmanicA> orsonj: if you installed the bzr-fastimport plugin, see bzr help fast-import-filter
<AmanicA> it seems to be able to do what you want
<LarstiQ> or maybe just `bzr uncommit`, if it's recent history
<Lo-lan-do> Jc2k: I think bzr-upload-pack does indeed suffer from bitrot or something: http://pastebin.com/d4b66f616
<Lo-lan-do> Um.  I'm wondering why it's using the system-wide git plugin rather than the up-to-date one in ~/.bazaar
<Lo-lan-do> Uninstalling the system-wide git plugin gives me a "ImportError: No module named git.server"
<Lo-lan-do> Seems to me the local server.py isn't properly registered.
<Lo-lan-do> jelmer: Any idea about that?
<jelmer> Lo-lan-do: not off the top of my head
<jelmer> Lo-lan-do: I'd have to look into it deeper, but I think there will be more issues like that atm
<Lo-lan-do> Does "import bzrlib" suffice to load all plugins?
<Lo-lan-do> An strace seems to indicate that the git plugin isn't loaded when bzr-upload-pack tries to import part of it.
<jelmer> Lo-lan-do: you need 'from bzrlib.plugin import load_plugins; load_plugins()' to make sure all plugins are loaded
<Lo-lan-do> I'm sending a patch your way
<Lo-lan-do> It's not fixing the problem I pasted into the pastebin, but at least the version of server.py that gets used is the proper one.
<jelmer> Lo-lan-do: ENOPATCH ? :-)
<Lo-lan-do> bzr send failed to attach it?
<Lo-lan-do> http://pastebin.com/f4ab696b5 it is then
<jelmer> yeah, apparently
<Lo-lan-do> This guest account isn't properly configured.  It's reset at each reboot, and I don't open sessions with it, only su.
<jelmer> Lo-lan-do: thanks, merged
<Lo-lan-do> jelmer: How about http://pastebin.com/f69a8b139 ?
<jelmer> Lo-lan-do: Yeah, that looks like a good idea :-)
<jelmer> Lo-lan-do: pushed
<Lo-lan-do> And before I go to sleep: http://pastebin.com/f1c569a76 is the current state I get and not a patch, but maybe it's an obvious problem to you?
<jelmer> Lo-lan-do: we changed what some of the arguments / return values look like
<jelmer> Lo-lan-do: something must've made us return a tuple
<vila> jelmer: huge ???
<jelmer> vila: well, pretty large at least
<mwhudson> jelmer: let me try that again: hi
<jelmer> mwhudson: hey
<mwhudson> (damn routers/isps)
<mwhudson> jelmer: so a bzr-git question: how much ram/time would you expect an import of banshee into 1.9-rich-root to take?
<poolie> hi all
<vila> the main part (in auth_required) is due to reindenting a block... Anyway, I don't think it's large :)
<vila> jelmer: a bit hackish, yes, but large, it's just an added loop and one more if :)
<vila> jelmer: and thanks for webdav :)
<jelmer> vila: I guess I should do more careful reading then :-) I skimmed over it only
<jelmer> mwhudson: 200Mb RAM, < 30min I would say
 * jelmer gives it a shot
<mwhudson> jelmer: i was seeing 1.8 gigs and >1 hour :)
<mwhudson> but i may not have been using the updated code
<jelmer> mwhudson: are you running dulwich trunk though?
<vila> jelmer: haaa, that explains it then :) Unfortunately that part of the http implementation (auth) is the most obscure due to the urllib2 underlying design which requires resending the same request with the added header and *that* makes it really hard to follow
<mwhudson> jelmer: well 0.2.1 or whatever it was
<mwhudson> i hope :)
<jelmer> yeah, that doesn't have a particular fix yet (iterobjects remembering *all* undeltified objects while walking a pack)
<mwhudson> jelmer: it's possible i stuffed up and was using the old dulwich, i'll try agai
<mwhudson> jelmer: oh
<jelmer> mwhudson: I also just fixed a bug in the offset handling in dulwich/bzr-git
<jelmer> mwhudson: which may corrupt repositories if you're not in UTC
<mwhudson> a
<mwhudson> h
<jelmer> mwhudson: mainly matters for dpush though
<mwhudson> jelmer: ok, pretty sure launchpad won't be doing that :)
<thumper> mwhudson: but our users might :)
<jelmer> one of the side effects is that some of the commits in dulwich are now in timezone "+0020"
<mwhudson> jelmer: so is there a new dulwich/bzr-git combo that will work with python2.4 and bzr 1.14 ?
<jelmer> mwhudson: I don't think I've made any 2.4-incompatible changes but let me check..
<jelmer> mwhudson: yeah, 1.14/2.4 should be fine with both trunks
<mwhudson> jelmer: have you rebased dulwich trunk again?
<jelmer> mwhudson: yes, that's this offset bug I was talking about
<mwhudson> argh
<jelmer> sorry :-/
<jelmer> it's dogfooding dpush that finds these bugs though
<mwhudson> i guess :)
<jelmer> mwhudson: banshee import: RAM usage seems to vary somewhere between 120Mb and 60Mb, takes about 1000s wall clock time on my thinkpad
<mwhudson> jelmer: dulwich r295, bzr-git r442
<mwhudson> jelmer: ok
<mwhudson> jelmer: can you check my revnos ^
<jelmer> mwhudson: ack
<jelmer> mwhudson: they match what I have here
<mwhudson> jelmer: cool
<poolie> i'm just catching up on the 1.4rc date thread from when i was away
<poolie> so long
<poolie> some useful ideas though
<awmcclain> Is there a way I can move a branch into a subfolder of another branch while retaining my version history?
<mwhudson> awmcclain: i think the merge-into plugin can do this
<awmcclain> thank you
<jelmer> lifeless: are there any plans for upgrading bzr.dev to rich-roots yet ?
<lifeless> jelmer: yes
<lifeless> jelmer: I've been posting to the list regularly about that ;P
<jelmer> lifeless: oh, oops
<jelmer> lifeless: I must've missed that, or do you mean the rich root upgrade bugfixes you've been posting?
<lifeless> jelmer: I posted saying we should upgrade, and lets test on smaller projects
<jelmer> lifeless: yeah, I saw that bit and the upgrade of bzrtools
<lifeless> so the plan is to fix those bugs then try again
<jelmer> ah, cool
<jam> lifeless: something recently in bzr.dev is now not letting me branch the launchpad conversion. My guess is ghosts, possibly in the mainline history (since the failure is on an Arch- revision)
<jam> I'm trying to investigate now
<jml> lifeless: so, I was going to remind you about "[MERGE] Report the number of VFS calls in -Dhpss output"
<lifeless> jam: thanks
<jam> I'm trying a reconcile right now (which of course spends a huge amount of time in "Finding text references"...)
<jam> it would seem that bzr.1.14.1 also fails to branch
<jam> so it might not be something new
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/368418
<ubottu> Ubuntu bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress]
<lifeless> jam: is  https://bugs.edge.launchpad.net/bzr/+bug/182715 fixed?
<ubottu> Ubuntu bug 182715 in bzr "Graph.heads() gives false heads sometimes" [Medium,Confirmed]
<lifeless> jam: bug 368418 has a branch that should fix it for yoy
<ubottu> Launchpad bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] https://launchpad.net/bugs/368418
<jam> lifeless: for bug 182715, afaik ghosts still confuse things
<ubottu> Launchpad bug 182715 in bzr "Graph.heads() gives false heads sometimes" [Medium,Confirmed] https://launchpad.net/bugs/182715
<lifeless> yah, just had to read it again to figure that out
<jam> Other than changing the api (or raising an exception) I don't think there is a lot to do for ghosts
<jelmer> mwhudson: crap, I think I think the timezone handling still might not be correct
<jelmer> mwhudson: you might want to hold off for a bit, I'm writing some extra unit tests to make sure it's really right this time
<mwhudson> jelmer: will this mean you need to rebase dulwich again?
<jam> lifeless: branching that gives 'AbsentContentFactory' .... :(
<lifeless> jam: hilarity ensues
<jelmer> mwhudson: probably, unfortunately
<mwhudson> jelmer: spm finished the dance to get the new dulwich in seconds before you typed that :)
<lifeless> spiv: if you're well enough, please fix-branch your fix for bug 368418
<ubottu> Launchpad bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] https://launchpad.net/bugs/368418
<lifeless> jam: you can probably get the patch via loggerhead
<jam> I'm trying via nosmart+
<jam> which seems to do just fine
<lifeless> that too
<mwhudson> jelmer: is bzr-git reasonably good at progress reporting?
<jam> lifeless: with patch applied, same failure
<jelmer> mwhudson: it should be doing either activity reporting or progress bars
<mwhudson> ok
<jml> poolie: I've updated that patch, btw
<poolie> for dhpss
<mwhudson> hmm, i need to look into activity reporting actually
<poolie> i saw, thanks
<mwhudson> might help https://bugs.launchpad.net/bugs/370491
<ubottu> Ubuntu bug 370491 in launchpad-code "Unable to handle reasonably sized development6 branches" [High,Triaged]
<poolie> spiv was sick yesterday, i don't know about today
<poolie> jml: if you're impatient i'll just merge it
<poolie> it definitely sounds like useful data
<poolie> jml: do you have pqm access?
<jml> I am a little impatient, yes :)
<mwhudson> poolie: very quick UI factory question, should/could a call to report_transport_activity be seen as a sign of activity?
<jml> no I don't.
<lifeless> mwhudson: it means something is networking
<mwhudson> good enough for me
<poolie> mwhudson: well, yes, but maybe i misunderstand the qn
<poolie> as opposed to what?
<lifeless> mwhudson: it doesn't mean its not in an infinite loop; but then no activity doesn't mean anything either way either
<mwhudson> poolie: good question
<mwhudson> poolie: it wouldn't be called if the network connection stalled?
<mwhudson> lifeless: we've not had anything do that to us yet, touch wood
<poolie> mwhudson: no, it doesn't
<mwhudson> poolie: i can't imagine why it would be, i'm just feeling paranoid
<lifeless> mwhudson: its called when bytes are read or written; a stall where we can write, get no error, and keep doing that would fool you
<poolie> typically (for the text ui) if it stalls it will just stay stuck on the last activity rate
<poolie> which is not ideal
<lifeless> I think thats an unikely scenario
<lifeless> poolie: this is for the robot ui
<mwhudson> lifeless: that hasn't been a problem in practice (yet, touch wood again)
<mwhudson> i want a "commit the change in this tree to a new branch" command :/
<mwhudson> i guess that's not so hard, just a bit shell scripty
<lifeless> its easy with ric
<lifeless> we just have to finish adjusting iter_changes so ric can be always used
<mwhudson> ric?
<lifeless> jam: ^ are you likely to get to that soon? / not in your pipeline?
<lifeless> mwhudson: record_iter_changes, the fast path commit code
<mwhudson> oh right
<mwhudson> well it's not so hard in a shell script really, bzr branch, bzr merge --uncommitted, bzr ci
<lifeless> mwhudson: I mean 'bzr commit --to ../newbranch'
<mwhudson> yeah
<poolie> yes i realize it's for the robot
<poolie> mwhudson: if you'refeeling paranoid i suggest you check the 'action' or whatever it's called is 'read'/'write'
<mwhudson> merge --uncommitted seems broken :(
<mwhudson> oh oops
<mwhudson> pebkac
<mwhudson> but still
<poolie> if we add a soft timeout like 'no io for two seconds' then we'd make a new action
<mwhudson> "bzr merge --uncomm ." explodes
<mwhudson> poolie: ah, ok, that makes sese
<mwhudson> poolie: the parameter seems to be called "direction" currently?
<mwhudson> tbh
<mwhudson> if we have a network write in the puller, something's gone a bit funky :)
<mwhudson> i wonder how to test this
<jelmer> mwhudson: ok, I have finally fixed it now *and* added tests
<jelmer> mwhudson: pushing dulwich again now, should be there soon
<mwhudson> jelmer: did you have to rebase?
<mwhudson> ok
<jelmer> mwhudson: yes, a bit
<mwhudson> jelmer: how do you rebase a bit? :)
<jelmer> mwhudson: only the identity of the last few revisions has changed, the first few are still as they were before
<mwhudson> jelmer: oh ok
#bzr 2009-05-06
<lifeless> mwhudson: the puller has to write to submit requests :)
<mwhudson> oh truw
<mwhudson> i was thinking on the wrong level
<poolie> mwhudson: that's it
<poolie> i think i can safely promise that if the direction is read or write it will only mean that we're actually reading or writing
<mwhudson> jelmer: is that new dulwich branch pushed yet?
<jelmer> mwhudson: dankje
<lifeless> poolie: you can? do you mean reading or writing to a socket?
<jelmer> mwhudson: argh, wrong channel
<mwhudson> :)
<jelmer> mwhudson: I meant yes
<mwhudson> wrong language too
<mwhudson> ok
<poolie> lifeless: can't I? yes.
<lifeless> fun and games with hardware:
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/dmraid/+bug/372170
<ubottu> Ubuntu bug 372170 in dmraid "intel isw raid metadata at odd offset" [Undecided,In progress]
<lifeless> my new machine :(
<mwhudson> jelmer: r296 is good now?
<jelmer> mwhudson: yep
<mwhudson> jelmer: thanks
<kingos> lifeless: ping
<lifeless> kingos: hi
<kingos> lifeless: hi. sorry to keep bugging you ...
<kingos> lifeless: any update on that bug of mine? I have some colleagues who would massively appreciate an increase in performance of our bzr setup!
<lifeless> kingos: no - swamped with network issues - three critical bugs
<lifeless> kingos: I do want to get to it
<poolie> lifeless, igc, jml, others: spiv is still away today
<kingos> lifeless: ah ok thanks. are you the only person who could help?
<jml> poolie: thanks.
<lifeless> kingos: I don't think I am
<lifeless> kingos: vila might be in a position to help sooner though
<kingos> lifeless: I imagine it will be quite tricky, something to do with *ghosts* I imagine from my infrequent reading of email lists (not that I know what they are)!
<kingos> I would have a go myself if I had the first idea where to start.
<jelmer> which bug is this?
<kingos> bug #356028
<ubottu> Launchpad bug 356028 in bzr "bzr check fails with KeyError" [Undecided,New] https://launchpad.net/bugs/356028
<kingos> we have a problem with our repository that is stopping us from upgrading.
<lifeless> jelmer: I mailed you a consistency issue the other day
<lifeless> jelmer: is it the same one as inkscape triggers?
<jelmer> lifeless: no, I'm not sure what that one is exactly
<jelmer> lifeless: did you see my reply?
<lifeless> no
 * lifeless looks
<lifeless> how do we move the inkscape one forward
<jelmer> lifeless: somebody with enough knowledge of the internals needs to have a look at why bzr thinks it needs the lhs parent even if that's not necessary for the delta
<lifeless> jelmer: can I help you learn that knowledge?
<jelmer> lifeless: lhs parent of a text
<jelmer> lifeless: I'd rather focus on bzr-git for now, not sure I want to dive into pack internals
<lifeless> brb, fooding
<igc> morning
<igc> abentley: is BB down?
<poolie> hello igc
<igc> hi poolie
<lifeless> poolie: I can't skype yet on this new machine
<lifeless> poolie: and as we haven't stood up; let me say I'm working on https://bugs.edge.launchpad.net/bzr/+bug/360791, and after that I plan to go and redo check; check is part of the upgrade process and its way to slow
<ubottu> Ubuntu bug 360791 in bzr/1.14 "get_stream on stacked branch causes "Error received from smart server: ('NoSuchRevision',)"" [Critical,In progress]
<lifeless> I don't know that I can make it hugely faster, but I want to stab at it
<poolie> that makes sense
<poolie> last time i looked it was very inefficient, reading things several times
<poolie> it's pretty old code
<poolie> so i think you'll find some tasty fruit
<poolie> i'm reading the subtree related threads
<poolie> i mean nested tree
<abentley> igc: restarted.
<igc> abentley: thanks
<lifeless> poolie: did I tell you, my new machine is 4-core on die?
<poolie> yes
<lifeless> still buzzing about that bit :)
<lifeless> hyperthreading on top of that
<spm> lifeless: *8* cpu whatsists!?!?
<lifeless> spm: yup
<spm> *awesome*!
<lifeless> spm: i7 920
<lifeless> now I just need to get eucalpytus up locally, then I can use ec2test @ home :P
<spm> ha!
<lifeless> BasicOSX: uhm
<lifeless> BasicOSX: 1.13.2 is looking rather close to bzr.dev ?
<lifeless> BasicOSX: rev 4113 looks to me like you merged _all_ of bzr.dev, or bzr1.14 or something
 * poolie tries to avoid being distracted to read about i7s
<lifeless> :>
<lifeless> I have a fix for bug 360971
<ubottu> Launchpad bug 360971 in gnome-app-install "gnome-app-install crashed with ValueError in _refilter() (dup-of: 339148)" [Undecided,New] https://launchpad.net/bugs/360971
<ubottu> Launchpad bug 339148 in gnome-app-install "gnome-app-install crashed with ValueError in _refilter()" [High,Incomplete] https://launchpad.net/bugs/339148
<lifeless> erm
<lifeless> not that
<lifeless> I have a fix for bug 360791
<ubottu> Launchpad bug 360791 in bzr/1.14 "get_stream on stacked branch causes "Error received from smart server: ('NoSuchRevision',)"" [Critical,In progress] https://launchpad.net/bugs/360791
<lifeless> yes, that
<poolie> yay way to go
<poolie> lifeless: i got approval for the patch recommending use of lp reviews so if you don't yell i'm going to merge it
<poolie> if there are questions or problems we can improve it later on
<poolie> thumper: ^^
<thumper> dogfood tastes good
<lifeless> poolie: I saw the patch :)
<lifeless> poolie: I would like more docs myself; its fine to say we shouldn't document it in that file, but we _should_ link to appropriate docs
<poolie> well, i did link to 2 or 3 existing docs
<lifeless> poolie: oh, I may have missed that
<poolie> if there are more that should be linked, or written and linked, let's do it
<poolie> i also filed a bug asking for more detail,
<poolie> bug 372057
<ubottu> Launchpad bug 372057 in launchpad-code "code review help doesn't mention making proposals by mail" [Undecided,New] https://launchpad.net/bugs/372057
<poolie> np
<lifeless> jml: is there a 'reviews I need to do' page in lp?
<jml> lifeless: not cross-project.
<lifeless> a) is there a bug asking for one? Is there one per-project that lists 'reviews I need to do' then?
<jml> lifeless: there's https://code.launchpad.net/bzr/+active-reviews, for example
<jml> (maybe without the hyphen)
<jml> lifeless: yes, there's definitely a bug asking for one.
<mwhudson> rockstar was working on it
<jml> I might well have filed it :)
<jml> lifeless: https://code.edge.launchpad.net/bzr/+activereviews
<lifeless> ok
<lifeless> jml: if you could toss me the bug asking for it, I'll me-too it
<rockstar> mwhudson, I'm working on it right now.  :)
<jml> lifeless: https://bugs.edge.launchpad.net/launchpad-code/+bug/325985
<ubottu> Ubuntu bug 325985 in launchpad-code "Page that shows reviews I *must* do and reviews I *can* do" [Medium,Triaged]
<lifeless> lunchish stuff then check()
 * igc lunch
<SamB> how can there get to be reviews one *must* do ???
 * SamB wonders if this involves a phb:employer-of RDF relation
 * SamB wonders why you people eat lunch at such odd times
<mwhudson> SamB: reviews someone has specifically asked *you* to do, as opposed to asked a team you are in to do
<SamB> mwhudson: OHHH
<SamB> I see
<SamB> that sounds an awful lot simpler to implement than what I was thinking ;-)
<mwhudson> heh
<mwhudson> "if you haven't done this review by the end of next week we will kidnap your first born child" ?
<SamB> so it's "reviews wanted of *me*" vs "reviews where I'll *do*"
<lifeless> push vs pull
<mwhudson> yar
<poolie> igc, hi?
<igc> hi poolie
<igc> lifeless, mwhudson: lp-needs is ok by me
<poolie> igc, can we have a chat?
<igc> poolie: of course
<lifeless> poolie: http://paste.ubuntu.com/165270/
<igc> poolie: just call me on pots or skype when you're ready
<lifeless> poolie: could you very quickly eyeball that
<poolie> ok
<lifeless> poolie: I'm seeking a 'sounds plausible' or 'eww'
<poolie> lifeless, others: btw [rfc] how about deleting the very old pre-brisbane-core performance documents from the tree?
<lifeless> poolie: many are still relevant; I do agree we should houseclean a little
<poolie> yes, of course keeping the relevant ones
<poolie> that pastebin seems plausible
<poolie> the other things i have in mind are:
<poolie> there are some checks that may be format-specific, some that may be done more efficiently in a format-specific way, but some should be done regardless of format (this is vague)
<poolie> and also that it may be useful for it to not abort on the first error if possible but rather tell us if there's more than one
<poolie> as far as ui i'd like it to be more clear by default if everything is ok
<poolie> at the moment normal output sometimes disturbs people
<poolie> so something like "checked %d revisions in %d branches; everything's ok"
<poolie> and then otoh if there is a problem giving data that will help with a bug report with few roundtrips wbn
<lifeless> naturally ;)
<lifeless> i have all those things in mind
<lifeless> at the moment I'm trying to architect a flow that will be easy to code and debug, but scale well etc
<lifeless> which is what that doc trys to get at
<lifeless> I will add those other things to the doc though, because explicit better than implicit
<igc> lifeless: should check become an alias for reconcile --dry-run one day?
<lifeless> igc: maybe; reconcile was written with the idea that there are 'small issues' and 'big issues' and reconcile is the 'big issue hammer'
<lifeless> but perhaps this is wrong
<igc> poolie: I believe http://code.aaronbentley.com/bzr/bzrrepo/nested-trees-loom is the public branch for nested trees
<lifeless> poolie: you seem to be repeatedly mailng the same mail
<lifeless> poolie: I'm up to 4 copies, letting you know now ;P
<poolie> sorry
<poolie> i kept getting "failed to send the message"
<igc> poolie: when you get a chance, can you land http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480903232138n34d2e189w71e7e8ee1f7e255a%40mail.gmail.com%3E please?
<eferraiuolo> How do you people have the user accounts on their server configured for a central bzr repo accessible via ssh?
<eferraiuolo> I'm curious how file permissions work in this case
<eferraiuolo> My goal is to setup an AWS EC2 machine with an EBS to house a central repo for my company's code. There is just two of us with SSH access to the EC2 machine and we want to setup central (master) bzr branches there
<poolie> igc, oh thanks
<vila> hi all
<vila> lifeless: 3 things
<lifeless> vila: yo!
<lifeless> eferraiuolo: hi; uhm I use lp :)
<vila> 1) Most important first: have fun with your new i7 :-)
<lifeless> vila: 6 minutes for parallel test
<lifeless> vila: I suspect your machine is faster or something
<vila> lifeless: 3 here :) i7 965 @3.2 GHz
<lifeless> ah, i got the 920
<lifeless> 2.6G
<vila> hmm, doesn't explain the whole difference then, may be the SSD helps too
<lifeless> oh, if youhave an ssd that is likely it
<poolie> eferraiuolo: what he said; otherwise add accounts for all the other people, make a group-owned directory for the repository and off you go
<lifeless> I'll try on a tmpfs
<vila> and 12GB RAM...
<vila> but 4 should be far enough :)
<vila> lifeless: 2) Testing and lock noise stipple, can you give a bit of feedback ?
<vila> 3) PQM and unicode
<lifeless> vila: I got 3GB, for trichannel mode
<lifeless> for 2- what you and john said sounds fine
<lifeless> I'm fine with a method to tell the test suite we're about to get rid of a lock
<lifeless> as for break-lock, I think it should fire a release hook event
<vila> lifeless: it seems that pqm gives ANSI_X3.4-1968 as fs encoding, that means all UnicodeFilenameFeature depending tests are skipped, I thought you filed an RT ticket about that ?
<vila> lifeless: ok
<lifeless> firing a release hook event in break-lock would make tests that do a break-lock line up, I think?
<lifeless> vila: I did, let me check
<vila> I should look into that but, a priori, we don't try to balance lock/unlocks precisely (as in cheking the actual locks), we just count the locks
<lifeless> * * * * * LANG=en_GB.utf8 PQM_CONFIG=/home/pqm/pqm-config/bzr-pqm.conf USER=pqm HOME=/home/pqm PYTHONPATH=/home/pqm/pqm:/home/pqm/source/bzr.dev:/home/pqm/lib/python /home/pqm/pqm/bin/pqm --run --cron
<lifeless> vila: counting is a rough approximation
<lifeless> vila: its hard to have the count line up and the physical locks not match
<vila> lifeless: I understand that, on the other hand.. yeah, what you said :)
<lifeless> specifically, to get a release we have to have locked it first
<vila> lifeless: break lock firing a release sounds appealing, I'll try that first
<lifeless> so all the releases can be trusted to have had to have a matching acquire; the question then becomes can we have an acquire that doesn't hook properly; or similar
<vila> lifeless: setting LANG doesn't seem to be enough or is not taken into account then:
<lifeless> yeah
<lifeless> I suspect dchroot-run or something is mangling it
<vila> Unable to represent path u'\u05e9\u05dc\u05d5\u05dd' in filesystem encoding "ANSI_X3.4-1968"
<vila> ...non_ascii.TestNonAscii.test_ignored(iso-8859-1) SKIP                   1ms
<lifeless> spm: ^
<vila> and that's from the "normal" run, not the ascii one
<lifeless> yah
<spm> whee. fun.
<lifeless> spm: there was a ticket about this, so I'm just going to ask ;)
<vila> I'll tend to consider that encoding problem rather critical as it means we can have some serious regressions go unnoticed
<spm> lifeless: :-) So... what's the problem per-se? as I'm coming a bit cold at this. I gather is a LANG/dchroot issue?
<lifeless> spm: we set lang around pqm
<lifeless> it doesn't seem to propogate down to the running tests
<vila> spiv: ... and python think the file system encoding is ANSI_X3.4-1968 (similar to ascii AIUI)
<lifeless> spm: what we need is LANG set to something present in the chroot, when make is invoked in the chroot
<vila> eerk, s/spiv/spm/
<spm> vila: is cool - we're used to it - well I am, can't speak for Andrew :-)
<spm> lifeless: hmmmm.....
<spm> lifeless: how about modifying the "precommit_hook=/home/pqm/bin/kill-chroot-processes.sh /srv/pqm.ubuntu.com/chroot-amd64 && /home/pqm/bin/dchroot-run make check" to add the LANG ==> dchroot-run LANG=blah make check ???
<lifeless> spm: lets do that
<lifeless> spm: but please do it with vila
<lifeless> so that he can send a patch through immediately; cause if it fails it will need to be rolled back
<spm> lifeless: sounds like a plan.
<spm> vila: still around? and able to submit a patch on demand? :-)
<vila> spiv: what kind of patch ?
<vila> AAArgh
<spm> vila: whatever it was that caused the UTF fail earlier. I'll just modify the pqm submit
<vila> spiv: what kind of patch ?
<spm> I wasn't going to say anything :-)
<vila> shudder 'sp' still matches both 'spiv' and 'spm' vila....
<spm> :-D
<fullermd> Obviously, the alphabet is conspiring against you.
<spm> vila: you're submitting to pqm against bzr trunk?
<vila> right, so a patch that fails if the fs encoding doesn't support unicode
<vila> I can submit against anything, if you can set up a test branch I can submit against that (but it needs some public access>)
 * vila tries rewiring visual control *before* press-enter control
<spm> vila: cool. ok have modifed for sftp://escudero.canonical.com/srv/www.bazaar-ng.org/rsync/bzr/bzr.dev - so submit to pqm against that whenever you're ready?
<lifeless> vila: anything really; just want to check that trunk isn't *already* broken
<lifeless> vila: because if it is it will reject all merges until its fixed.
<vila> lifeless: Oh, I see, I was able to reproduce the problem locally (at least I hope so) and fixed 3 failures where pqm failed on the first, so I'm pretty sure we are safe
<lifeless> vila: pretty sure != safe :)
<vila> lifeless: indeed
<BasicOSX> lifeless:  Just wanted to let you know I received your irc message and yes, I was working 1.13.2 and 1.14.1 at the same time so I could have messed something up. I had to work late tonight, just got home (2:22am) and have to be back at work at 8am so I won't be able to look at it until to night.
<lifeless> BasicOSX: thanks; thats fine. I'm not sure it is safe to do anything anyway.
<vila> spm: submission sent with commit message 'testing pqm unicode support'
<lifeless> BasicOSX: but it might be something we want to add a step to into the guide ;P
<BasicOSX> 1. Do not work on 2 releases at the same time, BasicOSX  did this is borked the 1.13.2 release.
<BasicOSX> That seems direct and short-n-sweet
<spm> vila: ta
<BasicOSX> What I hate about commercial develop, product goes out the door when marketing says it's time to go. /blah... off to bed
<vila> BasicOSX: s/commercial// and s/marketing/sponsor/ :-) This is not always a bad thing but the consequences are rarely well understood
<vila> spm: pqm.bazaar-vcs.org says: Coming up
<vila>    1.
<vila>       Wed May 6 08:24:24 2009 UTC: Vincent Ladeuil <v.ladeuil+lp@free.fr>, Request for non-PQM managed branch.
<vila> spm: if it's simpler I can send the patch against bzr.dev, it's a one-liner, if it fails, your solution is wrong, if it succeeds, your solution is right and I'll send a submission to revert my patch
<spm> vila: that sounds fair. I can easily remove items in the queue...
<vila> spm: ok, resubmitted
<spm> vila: and old submission removed
<spm> vila: how long does pqm take to test bzr these days?
<vila> pfew, no idea, it's fire and forget for me :)
<spm> heh
<spm> oki we'll it's dinner for me. I'll keep checking. if it really breaks and I don't respond soon - ring me via the staff directory or something :-)
<vila> spm: enjoy your dinner
<zyga> hello
<zyga> I'd like to share my logsearch plugin (in early infancy)
<zyga> for some review and suggestions for better API
<vila> zyga: send a annoucement to bazaar@lists.canonical.com and may be bazaar-announce@lists.canonical.com
<vila> zarq: you'll get a wider audience :)
<zarq> vila, i will?
<zyga> Ok, I'll push the code to a launchpad branch first
<vila> zarq: ghaa, sorry, that was for zyga of course :-/
<zarq> heh ok
 * vila kills a chicken or two
<Magneus> Hey gang
<limor> hi the tip of a revision are e.g. the 2 revisions which were merged together to one?
<vila> limor: the tip is the  most recent revision in a branch, a revision can have several parents, one for usual commits, at least two for merges
<limor> ah  ok
<LarstiQ> zarq: ocean's wide!
<LarstiQ> without the apostrophe even
<vila> spm: pqm is now running the ascii part so your fix seems good
<spm> vila: oh sweet!
<spm> vila: I suspect you killed the correct type of chickens.
<vila> LOL
<lifeless> spm: 40 minutes or so
<spm> lifeless: ta
<Magneus> hey gang, quick question: I'm a python and bzr noob, so bear with me:
<Magneus> bzr-svn isn't working for me, so I'm running "bzr selftest svn"
<Magneus> But it complains "bzr: ERROR: No module named tests
<Magneus> Is this a Python module or a bzr module?
<Magneus> ah ha "bzr: ERROR: No module named tests
<Magneus> pardon me
<Magneus> found it: bzrlib.tests module
<spm> vila: that appears to have finished - all good at your end?
<igc> vila: sorry I didn't get to review your http auth patch today
<igc> vila: I'll do it tomorrow if no-one beats me to it
 * igc dinner
<vila> spm: yup, I'll submit a patch to revert
<vila> igc: np, enjoy your dinner
<igc> vila: thanks!
<vila> Magneus: you'd better try 'bzr selftest' or only 'bzr selftest -s bp.svn'
<vila> spm: reverting patch sent
<vila> lifeless: now pretty sure == safe ;-P
<Magneus> Will do, thanks vila. It seems that bzr can't find my selftest module, however.
<Magneus> Is there an environmental variable I need to set?
<vila> Magneus: oh, I misread, what does bzr version says ?
<vila> Oh, wait, you're on windows ?
<Magneus> Gentoo
<Magneus> 1.14
<Magneus> bzr 1.14.1 on python 2.6.1 (linux2)
<LarstiQ> Magneus: if that is a gentoo bzr, maybe they've stripped the tests out
<vila> ok, 'bzr version' should tell you where bzrlib is installed, there you should find a test directory unless the tests.. what LarstiQ said :)(
<Magneus> well, I ls'ed the bzrlib folder
<Magneus> and found that there is a healthy-looking tests folder
<Magneus> full of .py files
<LarstiQ> Magneus: good, good :)
<Magneus> which is what has me thinking it's something like an env variable
<LarstiQ> Magneus: there usually aren't any env variables involved with running the tests
<vila> Magneus: nope, nothing needs to be set 'selftest' is a first-class command :)
<Magneus> blah
<LarstiQ> Magneus: your ~/.bzr.log might have some clues as to what is going on
<Magneus> I wonder why it's not finding it, then
<Magneus> Ah! log files. good stuff
<Magneus> ty
<Magneus> ah ha, looks like it's wanting pycurl
<Magneus> is that requisite for tests?
<LarstiQ> Magneus: only for https, it is not strictly required
<LarstiQ> or well, not even then per se
<LarstiQ> Magneus: so no
<Magneus> understood
<Magneus> also getting an error "ImportError: cannot import name ForeignBranch
<LarstiQ> Magneus: that sounds like bzr-svn
<cornucopic> hello folks..
<cornucopic> is there any way to avoid giving the pass in plain text in bazaar.conf when using 'smtplib' ?
<cornucopic> best, can I make it to prompt me ?
<Magneus> LarstiQ: right you are. I realize I had left the .6 version in my plugins folder just now ><
<Magneus> much better. back to "no module named tests"
<LarstiQ> Magneus: is that now bzr-svn complaining it can't find its tests?
<Magneus> Nah. simply a "bzr selftest" call
<Magneus> Let me know if you want to see the traceback
<LarstiQ> pastebin it please :)
<Magneus> http://pastebin.com/d123100bf
<LarstiQ> ok, so it's the xmloutput plugin
<Magneus> ah
<Magneus> I can axe it if need be
<Magneus> so xmloutput is trying to import its own tests folder?
<zyga> my branch is now online with the exception of exposing some launchpad bug/feature
<Magneus> Looks like removing xmloutput did the trick
<Magneus> bzr selftest is running now
<zyga> igc: https://code.launchpad.net/~zkrynicki/+junk/bzr-logsearch (if you remember yesterday's chat)
<LarstiQ> Magneus: good. If that is the most recent version of xmloutput, it might need filing a bug about that
<Magneus> Got it. Thanks, LarstiQ. Another question:
<Magneus> Selftest is finding a lot of little errors, 'str' object has no attribute 'get' - etc etc
<Magneus> cause for concern?
<LarstiQ> Magneus: there aren't supposed to be any errors, I wouldn't get concerned just yet though.
<Magneus> alrighty. I'll poke around at bzr-svn, then
<Magneus> I appreciate the help!
<Magneus> Ha. Segfault on 'bzr selftest svn'
<spm> vila: cool. I'll leave that LANG fix on bzr.dev (only) overnight. I've emailed the other losas so they know of it's existance if you do need a reversion. G'night! :-)
<vila> spm: I think it's fine to deploy it, unless lifeless objects, I see no reason to *not* have it everywhere
<spm> vila: blame it on me being a paranoid sysadmin - doing a "major" change and then buggering off is... not good :-)
<vila> spm: no pb, take your time and enjoy your night :)
<limor> question: If I use a shared repository the revisions of the branches inside the shared repository will be found in the shared repository .bzr and not in the .bzr of the branche as it would be normally?
<vila> limor: yes
<cornucopic> folks: is there any way to avoid giving the pass in plain text in bazaar.conf when using 'smtplib' ?
<liw> the "bzr commit" I started yesterday, committing all of jaunty's source code in one operation, is still running: it's not using much CPU, it's not doing system calls, and it's virtual memory size is 9+ gigabytes, which is more than the physical RAM of the machine
<liw> it doesn't show any obvious progress going on, either
<luks> why would you do that?
<liw> luks, for fun, to see if bzr can handle it
<luks> well, if you wait a day, it obviously can't
<liw> but I don't think I want to wait much longer
<luks> you could find a smaller project to commit to find that out :)
<liw> any bzr devs want me to do something to see if they can learn something useful from this?
<james_w> liw: is that with the development format?
<liw> james_w, --development-rich-root
<cornucopic> does this code look good for a post commit hook: http://pastebin.com/d366a9b34 ?
<lifeless> liw: I suspect its thrashing
<luks> cornucopic: branch.Branch.hooks.install_named_hook should not be indented
<cornucopic> luks, you mean outside the function ?
<Lo-lan-do> Can one define bzr aliases that involve pipes to external programs?
<Lo-lan-do> (diffstat comes to mind)
<luks> cornucopic: yes, it should be executed when the code is imported
<luks> Lo-lan-do: using the bzr-extcommand plugin
<cornucopic> ok. trying..
<lifeless> liw: iotop
<Lo-lan-do> luks: Trying that, thanks
<luks> Lo-lan-do: http://bzr.oxygene.sk/bzr-plugins/extcommand/__init__.py
<luks> there are also some examples
<cornucopic> luks, Thanks it works. Here is what I want to do: Since, I don't want my SMTP password in a plain text file, what I want to do is, post commit, I want to call my own code to send me the commit message using the smtp_connection.py.. Is that a good line of thinking?
<luks> cornucopic: is the plain text password in your plugin a better solution?
<luks> I don't see how are you going to avoid storing the password in plain text
<lifeless> cornucopic: I send mail via a local mta, then it has [root accessible only] the password for forwarding it outwards
<cornucopic> luks, I can prompt the user for the password and have it stored in smtp_password.
<Lo-lan-do> luks: Yay, it works :-)
<luks> cornucopic: you could just set right file permissions on the config file, it will be accessible only by root or you
<luks> unless you are on windows
<luks> Lo-lan-do: of course it does :P
<cornucopic> luks, No I am on Ubuntu :) file permissions is a easy/indirect solution..
<cornucopic> luks, however I have another idea now..
<cornucopic> luks, the file which parses the contents of the smtp credentials..if it comes across a smtp_password, field, then it prompts the user for the password?
<cornucopic> luks, i.e. if the smtp_password field is blank.
<cornucopic> luks, Does it sound reasonable?
<luks> cornucopic: I don't know much about hooking into the config system
<luks> cornucopic: definitely should be possible though
<cornucopic> luks, cool! its a post-commit email hook !
<cornucopic> have to get the bzr sources now!
<luks> bzr get lp:bzr :)
<cornucopic> yep !
<limor> does it take longer to get the hiostory or a checkout of an branch if I work with an large shared repostiory?
<luks> checkout gets the history too
<limor> yes
<luks> and if you work in a shared repository, it doesn't matter
<limor> hm are there no disadvantage of shared repositorys?
<luks> I don't there is any for a single user
<Lo-lan-do> You can't have different permissions on different branches.
<luks> if you use a single repository on a server where multiple users commit to it, you might find some problems
<luks> locking, permissions, etc.
<cornucopic> is there any IO wrapper used in bzr ?
<lifeless> what do you mean?
<cornucopic> For eg. Should I use input() for Input or is there a bzr specific wrapper?
<LarstiQ> cornucopic: you might want to look into the credential stores in bzr
<liw> lifeless, iotop tells me it's reading a fair big (500-1500 kilobytes per second)
<liw> lifeless, however, strace shows no syscalls, so I agree that virtual memory thrashing is going on
<liw> top does not indicate VIRT size grows much, though
<lifeless> liw: in and out, in and out:P
<liw> conclusion: if I wait long enough, this will actually finish, but only I'm really patient
<liw> (I'd be more patient with a progress reporter ;-)
<liw> still, I'm glad to see bzr is getting much further now than earlier
 * LarstiQ giggles at larz/johm
<liw> LarstiQ, :-)
<LarstiQ> liw: how is your cold?
<liw> LarstiQ, worse than yesterday, so I'll be heading for yet another nap
<cornucopic> I have made a change to smtp_connection.py so that it prompts for a password (masked) when it doesn;t find it in bazaar.conf
<cornucopic> this saves us from keeping our password in a plain text file..
<cornucopic> Can this be committed a patch?
<LarstiQ> cornucopic: the functionality sounds good. If you push a branch to launchpad and propose it for merging into bzr it can get reviewed.
<cornucopic> LarstiQ, awesome ! Should I use the dev branch ?
<LarstiQ> cornucopic: yup
<cornucopic> Cool.
<LarstiQ> liw: I know 'ole hyvÃ¤' is not the right idiom, but I do wish you to be well.
<awilkins> bwr
<awilkins> oops
<cornucopic|afk> how do I go about proposing my patch to be merged?
<cornucopic> Should I directly mail bazaar@lists.canonical.com with my patch ?
<cornucopic> LarstiQ, ping
<liw> LarstiQ, thanks
<igc> zyga: thanks for the link. It sounds like you had some success which is awesome! I'll take a look tomorrow.
<k4y> hi
<k4y> does anyone here have experience importing a darcs2 repo into a bzr repo?
<k4y> i'm trying to use darcs-fast-export and bzr fast-import but things just don't seem to pan out
<k4y> if i attempt to pipe the results of darcs-fast-export into bzr fast-import i get an error from darcs-fast-export about a broken pipe
<igc> k4y: the latest fast-import may not work with darc2 repos yet
<k4y> if i redirect the results of darcs-fast-export (darcs-fast-export > exp) to a file and pass that to bzr fast-import (bzr fast-import exp) i get:
<k4y> AttributeError: 'RevisionStore1' object has no attribute '_load_texts_for_file_rev_ids'
<k4y> igc: mmm
<igc> k4y: try bzr fast-import --classic exp and see if that works better
<k4y> i thought the point was to emit something in an intermediate format
<igc> k4y: it is. darc-fast-export should generate that format
<igc> k4y: and bzr fast-import *should* import it
<igc> k4y: but ...
<k4y> igc: "RevisionStore1" has to attribute "_..." seems like an issue separate from the file format
<k4y> specifying --classic doesn't seem to change anything
<igc> darc-fast-export uses a construct, IIRC, that most other fast-export tools don't, namely 'deleteall'
<igc> and I haven't got that fully working/tested in the latest fast-import
<igc> k4y: however, I did leave the old fast-import algorithm available via an option
<igc> which is called --classic from memory
<k4y> well, unfortunately it seems that there is a bug in that code
<igc> k4y: so the bug appears whether you use --classic or not?
<k4y> correct
<k4y> i'm using bzr-fastimport 0.8.0~bzr181-1 on Debian sid
<k4y> not sure whether that's old or not
<k4y> igc: i can pastebin the complete traceback, if you'd like
<igc> damn. Can you raise a bug please with a small fast-export stream reproducing it?
<igc> k4y: I'm not going to be able to look at it now (just before midnight here)
<k4y> hrm
<k4y> okay, i'll see if i can find the smallest reproducable stream
<igc> k4y: thanks
<igc> if the stream is large, compressing it is a good idea before attaching it to the bug report btw
<igc> k4y: rev 181 is pretty recent as well
<k4y> igc: how does the plugin decide whether to use revision_store.RevisionStore1 or RevisionStore2?
<igc> k4y: I'd have to look at the code
<igc> night all
<cornucopic> Bye all!
<ronny> LarstiQ: sup?
<LarstiQ> ronny: being a bit stuck on proving psi(s) > g(t) on an interval and reverse outside it.
<LarstiQ> ronny: that is, been doing math first today.
<LarstiQ> and now I need a break
<LarstiQ> what better break than inflicting easy_install on myself? ;)
<Lo-lan-do> psi() is... quantum?
<LarstiQ> Lo-lan-do: no, defined in terms of linear interpolation between phi(t, h) and g(t), where g is a concave function
<LarstiQ> it shouldn't be hard, just need to flex my muscles more
<ronny> LarstiQ: i belive easy_install is supposed to die at some point tho
<ronny> LarstiQ: and pip is supposed to work, too
<LarstiQ> ronny: yeah, I agree. And you're probably right that it is very painful to read.
<LarstiQ> Lo-lan-do: (chapter on non-parametric statistical models using kernel density estimators)
<ronny> LarstiQ: the best fix would be to just upload to pypi
<LarstiQ> ronny: if you have an automated way of doing that?
<LarstiQ> and well, from our point of view also not the best
<ronny> LarstiQ: why is that not the best, it creates the least indirections, and is a extra mirror
<LarstiQ> ronny: ideally, humans would go to the Downloads page
<LarstiQ> ronny: or hmm
<ronny> LarstiQ: and they would
<ronny> but scripts will go to pypi
<LarstiQ> ronny: maybe making the pypi page the same as the Download one would work
<LarstiQ> ronny: right. I promised you a fix for today, and you will get it.
<ronny> im currently trying to get an idea how to teach py.test to run tests in slave virtualenvs
<LarstiQ> ronny: do you have machinery to go through a large set of packages on pypi and check their setup.py/.cfg in an automated way?
<ronny> LarstiQ: not really a good one - my current scripts dont check the sucess
<ronny> virtualenv + pip could help
<LarstiQ> ronny: how about getting a package listing?
<ronny> all i do is 2 for loops and invoking virtualenv + easy_install
<LarstiQ> hah :)
<ronny> http://paste.pocoo.org/show/116024
<Lo-lan-do> jelmer: Hi, does http://pastebin.com/f4eb7e154 make sense to you?
<Lo-lan-do> I still can't do a git clone through bzr-upload-pack, but at least this patch seems to get me further on the path :-)
<jelmer> Lo-lan-do: no, that seems wrong - the parent_lookup function that's passed in is incorrect
<Odd_Bloke> When using --merge, how does bzr-buildpackage unpack the tarball?
<Lo-lan-do> Ah.  I'll go back to investigating then.
<jelmer> Lo-lan-do: the parent_lookup function should basically receive a bzr revid and return a matchiing git sha1
<cornucopic|away> vila, ping. Amit Saha h
<james_w> Odd_Bloke: tar recently
<cornucopic|away> vila, I am the one who is talking to you about the smtp patch..
<Odd_Bloke> james_w: I'm seeing a pax_global_header file created at some point.
<vila> no you aren't, your nick says you're away, I'm just hearing voices :)
<james_w> Odd_Bloke: then you have the old buggy version
<cornucopic|away> vila, Voices it is then :)
<Lo-lan-do> jelmer: I see.
<jelmer> abentley: ping
<Odd_Bloke> james_w: Ah, OK.
<vila> cornucopic: haaa, does it work now ?
<cornucopic> vila, No. Getting SMTP auth error
<vila> interesting, you reverted your patch right ?
<jelmer> abentley: I'm looking at providing a patch that moves Branch.update_references() -> InterBranch.update_references(). Do you think there is any value in keeping a Branch.update_references() ?
<cornucopic> vila, yes, yes. I have commented out the lines..
<abentley> jelmer: Sounds good.  I think we don't normally use Inter objects directly.  Do you want to change that.
<abentley> ?
<vila> cornucopic: so, what error do you get exactly ?
<jelmer> abentley: No, I think using Branch.update_references() is preferable over using InterBranch.update_references() for API users
<Odd_Bloke> I have a version string like '0+git20090506-1985f32-1', and bzr-buildpackage is giving me 'bzr: ERROR: Unable to find the needed upstream tarball: python-django-formfieldset_0+git20090506.orig.tar.gz.'  Bug?
<cornucopic> vila, 'SMTP error: 530 5.7.0 No AUTH command has been given'
<abentley> jelmer: So, keeping Branch.update_references as just a call into InterBranch.update_references seems fine to me.
<Odd_Bloke> james_w: ^
<james_w> Odd_Bloke: that's wrong then
<james_w> Odd_Bloke: public branch?
<Odd_Bloke> james_w: svn://svn.debian.org/svn/python-modules/packages/python-django-formfieldset/trunk
<Odd_Bloke> I think that's the public address.
<cornucopic> vila, nothinig much in .bzr.log with -Dauth
<cornucopic> vila, only the earlier error message exists
<vila> that means we don't match anything there, try to set a breakpoint and look at what auth.get_user() and auth.get_password() return
<vila> cornucopic: that means we don't match anything there, try to set a breakpoint and look at what auth.get_user() and auth.get_password() return
<james_w> Odd_Bloke: thanks, that's a stupid bug
<cornucopic> vila, without the :25 it works!
<cornucopic> vila, it asks for the password!
<vila> cornucopic: ok, that's a nasty bug, can you file it at launchpad ?
<cornucopic> vila, But however, is that really 'clean' ? I will file it- can you help me with the contents? and I would also like to fix it :)
<vila> cornucopic: well, no, it's not clean, but python support specifying the port in the host for smtp, whereas in bzr there ar separated far earlier
<vila> cornucopic: for the content, just explain what you expected, what you did, what you got, and mention the work around we just found
<cornucopic> vila, so ideally, it should be able to take it from bazaar.conf? or is the :25 the ideal behavior?
<vila> smtp_connection should be able to split the server variable into host and port
<vila> once that is done, auth.get_user() and auth.get_password() will need to be updated to add that port parameter too
<vila> and certainly other uses of _smtp_server should be updated accordingly
<Odd_Bloke> james_w: No worries, thanks for looking at it. :)
<Odd_Bloke> What're the odds it'll be in a Debian repo by tomorrow morning? ;)
<vila> cornucopic: hmmm, that sounds a bit to invasive... may be splitting host, port before calling get_user() /get_password() will be enough
<james_w> Odd_Bloke: slim, it will be in a branch in about 2 minutes though
<vila> cornucopic: you'll need to add proper tests for that too :) Look into bzrlib/tests/test_smtp_connection.py
<rellis> Anyone know where loggerhead looks for the config file by default?
<rellis> or if theres a way to control that in 1.10?
<beuno> rellis, what command are you using to start?
<beuno> serve-branches or start-loggerhead?
<rellis> beuno: serve-branches
<beuno> rellis, it doesn't have a config file  :)
<rellis> !? :)
<rellis> okay just a sec
<beuno> (it will in the near future)
<rellis> beuno: I just want to define that server.webpath
<cornucopic> vila, filed the bug: https://bugs.launchpad.net/bzr/+bug/372800
<ubottu> Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication when port is specified" [Undecided,New]
<rellis> beuno: I'm proxying through apache and need to force url's to read http://bzr.myorg.com
<beuno> rellis, and you've installed python-pastedeploy?
<beuno> rellis, there's some information on the README on how to do that
<rellis> beuno: python paste yes
<rellis> beuno: okay fair enough
<rellis> beuno: i see this bit about --prefix.. but that only allow to append /something.. was that what you meant?
<beuno> rellis, yeah.
<beuno> rellis, how about sending an email to the list?
<beuno> I know it's been solved before
<beuno> by thumper, mwhudson and lifeless
<rellis> beuno: okay thanks
<beuno> but they're all sleeping now
<rellis> gotcha
<rellis> beuno: your first guess was actually correct
<rellis> beuno: i had paste but no PasteDeploy
<beuno> rellis, needing pastedeploy?  :)
<rellis> yep
<rellis> thanks for thep ointer :)
<beuno> no worries
<beuno> any ideas on how we could of improved documentation to make that more obvious?
<LarstiQ> make it a mandatory dependency?
<rellis> beuno: Your docs actually seem spot on to me, it just didn't quite connect for me Paste and PasteDeploy beign different.. im a unix admin and a bit of a python novice
<beuno> LarstiQ, even when it's just used for specific cases?
<beuno> I don't necessarily think it's bad
<LarstiQ> beuno: I know some people need it and miss it. I don't know how large the group of people not needing it is.
<LarstiQ> beuno: afaik, it is hard to detect when you will need it?
<beuno> LarstiQ, it is
<beuno> well
<beuno> it's a very small dependency
<beuno> so it can't hurt to add it I guess
<beuno> will make the experience better for some users, without making it worst for others
<beuno> sounds like a good balance
<LarstiQ> beuno: that is something for you-the-loggerhead-team to judge :)
 * beuno is about to realease a new version any moment now
<Peng_> beuno: That reminds me, I have a branch adding a several things to NEWS, though I'm not done. https://code.edge.launchpad.net/~mnordhoff/loggerhead/more-news
<rellis> Does loggerhead support multiple repos in one instance?
<beuno> Peng_, just slap it straight through if it's just adding stuff to NEWS
<beuno> rellis, what do you mean multiple repos?
<elmo> is there anyway to tell what a bzr pull did after the fact?
<elmo> .bzr.log doesn't seem to record the version we were before the pull
<elmo> s/version/revno/
<Peng_> elmo: No. You could use "bzr pull -v" though.
<elmo> peng: well sure, if I had a time machine :-p
<Peng_> Git sets local tags, OLD_HEAD and HEAD or something like that.
<Peng_> elmo: Right.
<Peng_> Sorry. :\
<LarstiQ> elmo: you could ls -t on the repo maybe, but nothing convenient after the fact.
 * SamB wonders how to prevent aptitude from preferring package versions from PPAs
<rellis> beuno: ummm.. that's probably the wrong bzr term... we have seperate projects
<LarstiQ> elmo: that is, it says 'Now on revision 4340.' but not from where.
<LarstiQ> elmo: I think it would be good to have that though.
<LarstiQ> SamB: /etc/apt/preferences
<LarstiQ> rellis: loggerhead works with a directory hierarchy
<SamB> LarstiQ: figured
<LarstiQ> rellis: so give it /srv/bzr for example, and it will serve up every branch under there, doesn't care about the repositories they are in
<SamB> LarstiQ: oh, preferences huh?
<SamB> I have apt.conf ...
<SamB> Apt {
<SamB>   Default-Release "testing";
<SamB> }
<rellis> LastiQ: Ah, gotcha. Thanks.
<LarstiQ> SamB: man apt_preferences
<LarstiQ> SamB: and look for Pin
<SamB> LarstiQ: oh, I was really looking for something a bit more automatic than that ;-)
<SamB> oh, hmm, nevermind
<SamB> it's more than it sounds
<rellis> LarstiQ: When I give loggerhead /opt/bzr as the root it says no revisions in the one tab and I get a 500 eror when visiting the file tab.
<rellis> LarstiQ: I don't quite get how to navigate down into my projects which are directly under /opt/bzr i.e. /opt/bzr/Main
<LarstiQ> rellis: using serve-branches?
<rellis> yes
<rellis> 1.10
 * LarstiQ blinks
<LarstiQ> beuno: ^^?
<rellis> oh i think might be a perms issue
<rellis> LarstiQ: Ya I don't get it.
<LarstiQ> ronny: the whitespace in easy_install :(
<LarstiQ> made me think pkg_resources.py was almost empty
<LarstiQ> but then grep told me it _did_ have the class definition for Environment
<james_w> Odd_Bloke: oh, I forgot to say that the fix is in lp:bzr-builddeb/2.1 if you want it
<Odd_Bloke> james_w: Thanks again. :)
<eferraiuolo> once a rich-root repo always a rich-root repo?
<eferraiuolo> I'm trying to get a branch off of rich-root, is that possible?
<Peng_> eferraiuolo: Once a rich-root, always a rich-root, like you said.
<eferraiuolo> Peng_: is it recommended to use rich-root as a default?
<Peng_> beuno: FWIW, I've finished up and merged my NEWS stuff.
<beuno> Peng_, awesome, thanks
<Peng_> eferraiuolo: Well...yes, more or less.
<RainCT> Hi
<RainCT> If I have commits ...502, 503, 502.1.1 (a merge done after 503) and 504, how can I revert only the changes done in revision 503?
<LarstiQ> eferraiuolo: bzr is moving in that direction
<LarstiQ> eferraiuolo: but at the moment, it will mean everyone that interacts with that branch/repo will need rich-root too, and you may not want to force that yet.
<LarstiQ> eferraiuolo: since non-rich root -> richroot is possible, but the other way around is not.
<Peng_> RainCT: "bzr merge . -r 503..502" or something like that.
<RainCT> Peng_: thanks!
<eferraiuolo> LarstiQ: Is it best practice to use the latest repo format 1.14, or the default 0.92? Therefore use 1.14-rich-root by default?
<LarstiQ> eferraiuolo: best practice is to interoperate with older clients, 1.14 is too new. If you don't care about that, 1.14-rich-root sounds good.
<LarstiQ> (there is a limit to old clients of course, yesterday someone tried a 0.11 client. That's too far :)
<Peng_> beuno: And I just added 1.15 to require_any_api.
<beuno> Peng_, we will require bzr 1.15
<beuno> ?
<eferraiuolo> LarstiQ: me, my business partner, and our server all have 1.14 on them; I'm thinking that we don't care about the older clients, we also are running the latest one.
<eferraiuolo> LarstiQ: Thanks for the insight.
<Peng_> beuno: I just added 1.15; I didn't remove 1.11 or 1.13. I think that's okay, right?
<beuno> Peng_, I think it is
<beuno> 1.14 as well?
<beuno> maybe?
<Peng_> beuno: I think they skipped 1.14.
<beuno> maybe
<LarstiQ> Peng_, beuno: qua minimum api versions, there is 1.13 and 1.15
<LarstiQ> 1.14 exists in 1.14.0, but got fixed to be 1.13 in 1.14.1
<LarstiQ> since it's a minimum, having 1.13 works fine
<LarstiQ> eferraiuolo: then you're good to go
<Peng_> Ah, okay.
<Peng_> Wow, URLs like "nosmart+:parent" actually work too. That's awesome.
<LarstiQ> ronny: ahem, it seems our moin doesn't do the comments parser. But at least easy_install can find 1.12 now ;)
<LarstiQ> Peng_: nosmart+:parent/../sibling!
<LarstiQ> ronny: next problem might be that setup.py alone is potentially not enough (on Windows)
<Peng_> Ah, right, I forgot about URLs like that. Even better! :)
<LarstiQ> beuno: do you know what version of moin bazaar-vcs.org is running?
 * beuno looks it up
<beuno> LarstiQ,  Moin 1.5.7
<LarstiQ> beuno: thanks
<LarstiQ> ronny, beuno: it seems the moinmoin wiki parser comment option got added in 1.6.0, 2 versions after what we're currently using.
<beuno> LarstiQ, ah. I'll ask IS about upgrading
<cody-somerville> bzr: ERROR: exceptions.TypeError: a float is required
<cody-somerville> When I did bzr break-lock
<LarstiQ> cody-somerville: there are bugs about that
<cody-somerville> okay
<cody-somerville> How do I break the lock?
 * LarstiQ looks that up and then goes to bed
<LarstiQ> cody-somerville: bug #365891 it seems
<ubottu> Launchpad bug 365891 in bzr "bzr break-lock lp:foo fails with TypeError: a float is required" [High,Fix released] https://launchpad.net/bugs/365891
 * LarstiQ is too tired to discern what to do
<LarstiQ> ronny: things are in motion, but now I'm going to sleep.
<LarstiQ> good night!
<Peng_> I think the answer to the break-lock thing is "upgrade!".
<phinze> is there an easy way to pull just a single file out of bzr?
<phinze> got a case with a large branch and don't need the whole repo
<beuno_> phinze, you could use loggerhead  ;)
<phinze> beuno_: true, but i'm looking to pull something from source control in a script
<phinze> specifically a crontab i'd like to install which is installed in our main project codebase
<beuno_> phinze, ah, then you can do that with bzrlib
<beuno_> a python script that grabs it
<beuno_> you can look at how loggerhead does it
<Peng_> phinze: You could use "bzr cat", but I dunno how much of the repo it'd wind up downloading.
<thumper> what format should I use for brisbane core with 1.15dev?
<Peng_> thumper: You mean development6-rich-root?
<thumper> cool, 'cause I used --development-rich-root and got --development6-rich-root
<beuno> phinze, not at the moment, no
<thumper> I just wanted to be sure I had the right one
<phinze> Peng_: well that worked... 2146KB downloaded
<phinze> not terrible
<Peng_> thumper: Yeah, --development-rich-root is an alias for the latest, well, rich-root development format, which is currently development6-righ-root.
<thumper> I wish python had better multi core support
<thumper> branching into a new brisbane core is slow, but only using one of my four cores
<phinze> beuno: Peng_: thx much
<cody-somerville> Is there any way to see how many commits a branch has had? Include those included in merges?
<jam> cody-somerville: bzr ancestry | wc -l, bzr log -n0 | grep revno | wc -l
<cody-somerville> neat, I didn't know about that command
<cody-somerville> hmm
<cody-somerville> didn't work
<cody-somerville> wc: invalid option -- ','
<cody-somerville> oh
<cody-somerville> doh
<rellis> Anyone know if the loggerhead root directory to serve needs to be a "bazaar directory"?
<mwhudson> rellis: it definitely doesn't
<rellis> okay
<rellis> hmm.. can't figure out why i get a 500 on the files tab when i set it to my parent directory containing my bazaar projects
<mwhudson> rellis: are you using serve-branches or start-loggerhead ?
<rellis> http://www.pastebin.ca/1414760
<rellis> i'm using serve-branches
<rellis> that's the error i receive
<rellis> i verified the permissions are correct on the repo as well
<mwhudson> rellis: there isn't a files tab on non-bazaar directories
<rellis> oh weird mwhudson
<rellis> the parenty directory i'm pointing serve-branches at has a .bzr and .bzr.log
<rellis> i'm going to try and delete them
<rellis> mwhudson: Thanks, all is working now :)
<rellis> all praise be to #bzr!
<mwhudson> rellis: ah, k
<mwhudson> glad it's working
<Peng_> rellis: You don't have to delete .bzr.log.
<rellis> Peng: It's already gone, and good ridance I say :)
<rellis> but thanks for the tip
<lifeless> igc: ping [when you get here]
<spiv> Good morning.
<jelmer> moin spiv
#bzr 2009-05-07
<lifeless> spiv: hi!
<lifeless> spiv: you back?
<spiv> lifeless: yeah, I hope so :)
<spiv> With the help of cold & flu tablets.
<lifeless> ok cool
<lifeless> I was going to pickup the 'detect ghost inventories' patch
<lifeless> if you're back, and it was next on your todo, perhaps you'd like to just follow through on it ?
<jelmer> mwhudson: moin
<jelmer> mwhudson: any more luck with bzr-git now?
<mwhudson> jelmer: haven't tried with the latest versions yet
<spiv> lifeless: sure
<Peng_> So, um, what's the right branch of Dulwich to use?
<mwhudson> jelmer: judging by the first two minutes, it seems much saner in terms of memory usage
<igc> morning all
<igc> lifeless: pong
<lifeless> igc: hi
<lifeless> igc: you mentioned that filter config has hit a wall; where should I read to read up on that
<igc> lifeless: thanks for your email btw
<lifeless> anytime
<igc> lifeless: I'll email the list soon with an update
<lifeless> literally apparently, it was what, 11? :P
<igc> lifeless: see Alexander's latest email for the brief problem
<igc> i.e. using an arbitrary file doesn't allow storage of that file in the tree
<igc> because of various ordering issues w.r.t. tree building and filter application
<lifeless> e: [MERGE] [BUG 363837] Catch _win32_delete_readonly failure to remove file or directory and try to recove ?
<ubottu> Launchpad bug 363837 in bzr "diff --using does not give Windows enough time to remove temp files" [Medium,In progress] https://launchpad.net/bugs/363837
<AmanicA> jelmer: sorry if the mail I just sent about your patch is confusing, but I'm tired and going to bed now
<poolie> spiv: still sick today?
<poolie> oh i see
<spiv> poolie: no (well, not enough to stop me working)
<igc> hi spiv. welcome back
<spiv> I wouldn't recommend getting too close to me, though :)
<spiv> Between this cold and the vaccinations last week my immune system should be very well exercised for Barcelona...
<mwhudson> jelmer: is there any way of telling how a bzr-git pull is doing by looking at the .bzr directory?
<lifeless> spiv: could you please eyeball my updated descriptions on https://bugs.edge.launchpad.net/launchpad-code/+bug/354036 and https://bugs.edge.launchpad.net/bzr/+bug/360791
<ubottu> Ubuntu bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed]
<lifeless> spiv: I've tried to make them very approachable for users
<luke-jr> How can I get a list of all revids?
<lifeless> cat /dev/urandom ?
<lifeless> more seriously, a little context is needed - do you mean the revisions in a branch, or the contents of a repository, or some concordance of what people have used anywhere....
<spiv> luke-jr: in a branch's mainline history?  in a branch's full ancestry?  in a repository?
<lifeless> also do you want it in python, or shell scripting
<luke-jr> spiv: a future revision
<luke-jr> I did a bunch of bzr uncommit ;)
<spiv> lifeless: the descriptions look very good, thanks!
<spiv> luke-jr: you mean you want to know the revids of the uncommitted revs?
<lifeless> bzr heads --dead
<lifeless> will list all the heads
<lifeless> uhm, log -r revid:ADEADHEAD  --show-ids will let you get at the ancestors of the dead head
 * fullermd still wishes log -r..revid:FOO would give a log as if FOO were the head of a branch...
<lifeless> fullermd: make it happen!
<lifeless> fullermd: [is there a bug too]
<spiv> And "bzr uncommit" in recent releases will display the revid of the revision you are uncommitting
<luke-jr> lifeless: 'bzr heads' doesn't exist..?
<fullermd> I tried, but my magic wand just sorta looks at me and says 'blert'...
<luke-jr> spiv: it did, long off my scroll history
<fullermd> Not sure.  I don't remember filing one.
<lifeless> fullermd: you need to pay it more attention
<luke-jr> bzr 1.14rc1 has no 'heads' cmd
<fullermd> luke-jr: It's in bzrtools
<lifeless> luke-jr: the revids may be in your bzr.log too
<luke-jr> ty
<lifeless> jml: when you do a web review, its annoying that you can't see what you are reviewing
<lifeless> e.g. https://code.edge.launchpad.net/%7Embp/bzr/340352-rename-lock/+merge/4334/+review
<lifeless> the bug style inline forms are _much_ more convenient
<jml> lifeless: yeah, poolie filed a bug about this.
<lifeless> ok cool
<lifeless> I can't see it
<mwhudson> mmm
 * mwhudson still finds the distribution of concerns in progress reporting a little odd
<mwhudson> mmm
<mwhudson> maybe it's not bad actually
<jml> https://bugs.edge.launchpad.net/launchpad-code/+bug/372059
<ubottu> Ubuntu bug 372059 in launchpad-code "show the merge diff when proposing a merge" [Undecided,New]
<jml> I haven't had the chance to triage it yet.
<poolie> mwhudson: it's not fully baked yet i agree
<lifeless> jml: thats when proposing a merge
<lifeless> jml: I'm talking when doing a review
<jml> lifeless: oh ok.
<lifeless> jml: https://code.edge.launchpad.net/%7Embp/bzr/340352-rename-lock/+merge/4334/+review is an example url
<mwhudson> poolie: concretely right now i wish TextProgressView._format_task was somewhere else :)
<poolie> patches welcome :)
<lifeless> jml: let me know, bug or feature:P
<jml> lifeless: what do you think?
<mwhudson> i guess i need to figure out what i want here
<mwhudson> poolie: i'm just going to blabber requirements for a while, feel free to either ignore or read as you like
<lifeless> jml: I think it would be better if it was like the bug discussion pages
<mwhudson> this is for git code imports
<mwhudson> we have a monitor process that considers a process stuck if it produces no output for an hour
<jml> lifeless: me too.
<mwhudson> so i'd like to have a progress reporter that prints some kind of progress indication
<mwhudson> i think printing a line on every progress report would get a bit spammy
<mwhudson> so i was thinking of printing a progress report on _progress_updated if nothing had been printed for, say 10 minutes
<mwhudson> i guess i'll subclass clifactory
<lifeless> mwhudson: don't you have this already
<lifeless> mwhudson: I *sounds* like code you wrote in the past.
<mwhudson> lifeless: it sounds a bit like something ddaa wrote
<mwhudson> i think
<lifeless> mwhudson: I'm pretty sure you already have a UI factory in your code base that does this
<mwhudson> lifeless: i'm pretty sure we do not, any more
<lifeless> oh, ok.
<lifeless> 'bzr revert -r wheredidthatcodego'
<lifeless> bug 373038
<ubottu> Launchpad bug 373038 in launchpad-code "inline editing for reviews please" [Undecided,New] https://launchpad.net/bugs/373038
<jml> thanks.
<thumper> lifeless: yes, I know
<lifeless> thumper: ?
<thumper> lifeless: I've been planning to work on it with beuno but both of us have long lists :(
<thumper> lifeless: bug 373038
<ubottu> Launchpad bug 373038 in launchpad-code "inline editing for reviews please" [Undecided,New] https://launchpad.net/bugs/373038
<lifeless> thumper: thats a new bug I just filed as the result of the discussion with jml
<thumper> lifeless: yes, but we've known about it for ages :)
<thumper> just bugless
<lifeless> thumper: I'm honouring a promise I made to jml to be active about documenting my experiences with code
<thumper> that's good
<thumper> thanks
<thumper> I do appreciate it
<thumper> I just want you to know that we know about it and have been thinking about it
<lifeless> ok, cool.
<spm> lifeless: btw that pqm-config fix for the LANG (/home/pqm/bin/dchroot-run LANG=en_GB.utf8 make check) worked nicely for vila last night. Shall we roll to all the bzr config entries, or revert?
<lifeless> spm: bzr.dev and new releases only
<lifeless> spm: e.g. 'no'
<spm> lifeless: new releases being 1.14+ ?
<lifeless> the state of existing branches is unknown
<lifeless> spm: 1.15
<spm> oh yes of course. will do.
<lifeless> thanks
<lifeless> spiv: how goes it?
<lifeless> spiv: I ask because AIUI you had a patch, but I don't recall seeing it up for review; I'm keen to put these bugs behind us and want to help :)
<spiv> lifeless: just caught up on the worst of my mail and administrivia backlog
<spiv> lifeless: the work-in-progress is lp:~spiv/bzr/all-referenced-texts-check
<spiv> lifeless: I'm currently working on adding more test coverage
<lifeless> ok
<lifeless> the conceptual approach makes sense, and I browsed the patch yeseterday
<spiv> lifeless: cool, that's good to know :)
<jelmer> mwhudson: not really
<spiv> The code feels overly complex, but I think that's hard to avoid.
<mwhudson> jelmer: ok
<spiv> We don't have particularly convenient APIs for working with the dependencies that are implicit in our graphs.
<jelmer> mwhudson: it should give you a progress bar though
<mwhudson> jelmer: yeah, if you install a ui factory at all :)
<mwhudson> where does the ui_factory get set when you run bzr from the command line?
<mwhudson> oh, main()
<spiv> mwhudson: with the small exception of cmd_serve which unconditionally uses SilentUIFactory
<mwhudson> spiv: ta
<mwhudson> oh wow, i can actually pull bzr.dev over http now
<mwhudson> i wonder if my isp has fixed their proxy at last...
<thumper> jam/igc: any ETA on bbc stacking?
<igc> thumper: no idea sorry - I'm not working on that
<thumper> igc: hmm, lifeless just said it was with you and jam
<lifeless> thumper: igc and jam are working on the bbc format and related things, spiv and I are working on networking - thats the split across the two major goals set for the bazaar team
<thumper> ok
<lifeless> thumper: it doesn't mean that everything we do is strictly in those buckets, nor that everything that needs to be done to move bbc from beta to release is actively being coded right now :)
<poolie> mwhudson: so you're running bzr in a subprocess with a pipe on stderr/stdout?
<poolie> and you just want it to mumble stuff, not draw a progress bar as such?
<mwhudson> poolie: yes
<mwhudson> right
<mwhudson> hmm
<mwhudson> can i use a plugin to override the default ui factory?
<lifeless> mwhudson: yes
<lifeless> mwhudson: it may be a little esoteric; I will put one together for you after I finish a little roadmap cleanup
<mwhudson> lifeless: don't worry about it, i'll just hack for now
<thumper> poolie: http://bazaar-vcs.org/Roadmap/BrisbaneCore seems to completely miss that bbc can't stack right now
<lifeless> thumper: I'm editing it at the moment
<lifeless> thumper: done
<lifeless> mwhudson: ok
<lifeless> mwhudson: hook into Command.hooks 'extend_command'
<lifeless> mwhudson: bzr help hooks has the docs for this
<lifeless> mwhudson: that will get called before any command is executed, and after the ui factory is set
<mwhudson> lifeless: ta
<lifeless> its a little hacky, and you may be invoked multiple times etc
<lifeless> but it will work
<mwhudson> lifeless: so will editing main() which is what i'm doing now >:)
<lifeless> mwhudson: well you asked about a plugin to do it
<mwhudson> yeah, sorry
<lifeless> its about 4 lines in a plugin, including imports
<SamB> and how many lines to install ?
<lifeless> SamB: thats the lot
<SamB> I meant, how many lines do you need to type in the shell ;-P
<lifeless> SamB: oh heh
 * spiv -> lunch
<SamB> spiv: I maintain that you people are CRAZY!
 * igc lunch
<SamB> igc: yes, you too!
<igc> SamB: :-)
 * SamB <- dessert
 * fullermd isn't edible.
<SamB> (the dessert goes into me ;-)
<poolie> igc, i'm trying to merge the doctools patch you mentioned yesterday
<poolie> it has small failures on python2.4
<igc> poolie: did jam suggest some workarounds in the review thread? It's a while ago now but I recall something like that
<poolie> he had a small fix but i think not for that
<lifeless> its the win32 installer it fixes I think
<lifeless> spiv: http://bazaar-vcs.org/Roadmap/SmartServer I've tweaked; let me know if I used too big a cleaver
<poolie> thanks for all the roadmap updates!
<lifeless> poolie: as we were discussing, there is a balance here
<mwhudson> poolie: this is the ui factory i've come up with so far, if you're curious: http://pastebin.ubuntu.com/165831/
<lifeless> mwhudson: seems more complex than desirable
<lifeless> mwhudson: but if it works great
<mwhudson> lifeless: it's not _just_ for progress monitoring, it's also visible in the ui
<mwhudson> so i put a bit of effort into making it useful too
<lifeless> mwhudson: sure; by complex I mean its a shame you can't use existing code more
<mwhudson> lifeless: ah right\
<mwhudson> yes
<lifeless> I mean, ideally you'd just override the render call and instead of doing [======] do 'status change, x->y', and also change the clamp threshold from 1/10th of a second to 30 seconds
<lifeless> or wahtever
<lifeless> actually thats a good, serious question
<lifeless> why didn't you do that?
<mwhudson> hmm, i guess that would have been somewhat easier
<mwhudson> would need to copy-paste-change some methods (and presumably submit changes to bazaar that would make that less relevant)
<lifeless> naturally
<lifeless> otoh it would be more obvious and likely easier to maintain
<poolie> mwhudson: i like the time_source thing
<mwhudson> poolie: deterministic tests ftw
<poolie> i'd like to merge something like this into bzr
<poolie> if you need to provide the stack stuff here that's a bug
<mwhudson> poolie: i think as lifeless said, i'm somewhat operating at the wrong level
<mwhudson> poolie: but operating at the right level nicely requires a bzr patch
<mwhudson> poolie: i'll try to write that patch later
<poolie> ok
<poolie> i also want to keep improving this
<eelik> Are there instructions anywhere for actually creating the repository layouts mentioned in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#advanced-shared-repository-layouts
<spiv> eelik: there's no special commands needed beyond the "bzr init-repo" to create the shared repository
<eelik> but how about "container directories"? Are they versioned somehow?
<spiv> eelik: no, just create an ordinary directory on your filesystem.
<eelik> then I'm out of luck, because sourceforge doesn't make it possible
<eelik> basically, it allows only using bzr command
<lifeless> eelik: you can just use bzr commands
<lifeless> eelik: bzr init-repo URL
<eelik> yes, that's the easy one
<eelik> it has to be done in a special ssh shell environment
<lifeless> eelik: and then bzr push URL/foo to push a branch up
<mwhudson> poolie: http://pastebin.ubuntu.com/165869/ <- version that uses more from bzrlib
<mwhudson> poolie: it's a bit ugly, but a bzrlib patch will sort that out
<eelik> that I can do also, but what if I want to create a branch in a nonversioned subdirectory or subsubdirectory
<eelik> does bzr create them automatically
<lifeless> eelik: bzr push URL/foo/bar --create-prefix
<eelik> (well, I'm new to bzr as you can see)
<eelik> ok, I have to try that
<eelik> But I managed already to create a nonversioned directory into the sf server and it can't be removed
<lifeless> eelik: bzr push --use-existing-dir URL if you want it to be a branch
<eelik> their system may be unmature
<lifeless> eelik: or if you wanted it to be a repository, bzr init-repo URL
<eelik> ok, I have been reading the docs for couple of days but it's just too much :)
<lifeless> eelik: could be :)
<lifeless> sf have only recently added sf support, its true
<eelik> and they don't offer any site specific documentation except for the very scarce intro
<eelik> but thanks, I keep learning
<the-erm> I have a security question.
<the-erm> I notice that bzr has an ssh key
<the-erm> if someone gets a hold of my ssh id_rsa.pub key from launchpad does that mean they can ssh into my computer?
<lifeless> no
<the-erm> Ok.
<lifeless> ssh keys work in two parts
<lifeless> the public part is like the lock
<vila> hi all
<lifeless> the private part, the bit you keep on your computer, is the actual key
<the-erm> I realized the error of my question...after I asked it.
<lifeless> the public key can be used to give you permission to login to machines, thats all
<lifeless> hi vila
<the-erm> I guess it didn't hurt to ask.  I'm pretty paranoid about letting people have access to my machine.
<lifeless> thats healthy
<lifeless> jelmer: ping
<poolie> lifeless: +1 to your updates and thanks for writing it
<poolie> updates to the advice
<luke-jr> the-erm: I used to have an 'anonymous' account on mine, without a password
<luke-jr> curiously, the botnets never noticed it
<lifeless> poolie: I've finished for the day; feel free to let the announcement go free if you want :)
<lifeless> poolie: otherwise I'll do it tomorrow
<luke-jr> lifeless: announcement? âº
<lifeless> luke-jr: see the list, 'draft announcement..'
<poolie> lifeless: let it go from teh moderation queue?
<lifeless> poolie: I haven't mailed it anywhere
<poolie> ok let it go by sending it?
<poolie> sure
 * jml really really wants an SQL-like frontend to Bazaar
<jml> (except not enough to actually design and build one)
<mwhudson> jml: select from revision where author like ... ?
<jml> yeah
<jml> or, a thing I wanted to refute a particular accusation
<jml> select from revision where message.startswith('release-critical') and author in (...)
<jml> except because of PQM you need the author of the second-to-left parent of the mainline revision.
<jml> which is a pita
<jml> also counts and averages and better time awareness
<lifeless> jml: bzr log -m '\brelease\b' :P
<lifeless> also bzr-search aims at this space, I'd be delighted to have a readline interface to it
<jml> lifeless: that log command is obviously not good enough
<jml> lifeless: because it doesn't restrict the set of authors.
<lifeless> jml: yes, thats true
<lifeless> igc and I and others want a query language we can make standard and reuse
<lifeless> ETIME
<jml> right
<lifeless> jml: are there ppa package branches?
<lifeless> [I have a piece of software; I'm going to upload it to a ppa; it would be nice if the branch I upload was clearly packaging]
<jml> lifeless: there aren't ppa package branches, per se.
<jml> lifeless: you can push to ~lifeless/ubuntu/karmic/software/branch though
<lifeless> or jaunty presumably?
<jml> or jaunty
<jml> or lenny
<lifeless> now, if the package hasn't been in ubuntu yet, will that fail?
<jml> (or whatever they call it)
<jml> lifeless: very good question. my guess is "yes"
<jml> lifeless: but I haven't tried.
<jml> let me know if I'm wrong :)
<lifeless> software is 'package' ?
<lifeless> jml: apparently subunit has been uploaded before, or the answer is 'no'
<awilkins> Hmm, bzr just isn't good at whacking-great-enormous files.
<awilkins> Is there any way that bzr support for large sized files could improve? I know it's not the core use case, but a lot of people check large files into e.g. SVN, which copes well with them, and this can make interoperating with those repositories with bzr something of a trial.
<lifeless> awilkins: it will improve when jam lands a patch he has, but only by a factor of 3 or so; files that are large fractions of your memory require more radical changes
<awilkins> What kind of fraction?
<awilkins> My problem here is I think this repo has a single revision with about 600MB of data in it.
<awilkins> It's sitting at around 2.1GB in top and swapping around every so often.. :-)
<lifeless> to merge a file wit 600MB of content we need 1.8GB in memory, minimum.
<lifeless> (three copies)
<awilkins> Dammit, the server just dropped
 * awilkins bites the edge of his shield
<awilkins> I think it's split into several 150MB files
<awilkins> I'll check it out the traditional way and see
<awilkins> Would it be a valid approach to write a class that merges using disk as an intermediary, and "mutate" the memory based operation into a disk based operation if it was consuming a lot of memory?
<bob2> or just give up and conflict out
<lifeless> each 150MB file should be getting processed separately
<bob2> 600MB files probably aren't text
<lifeless> awilkins: yes, that is a valid approach [with costs, but yadayadayada].
<awilkins> Ah, ok, even better(ish) it's more like 25-40MB files
<awilkins> They are text files, they are just big ones
<awilkins> They're CSV tables
<lifeless> awilkins: ok, if *that* is giving headaches its not the 'big file' bug
<lifeless> awilkins: what bzr version?
<awilkins> This is bzr 1.14.1 plus whatever bzr-svn it ships with
<lifeless> ok
<lifeless> please file a bug
<lifeless> with plenty of data about reproducing if possible
<awilkins> It's probably bzr-svn
<lifeless> it could be bzr-svn
<lifeless> if you can simulate (e.g. fast-export fast-import, reproduce) it without bzr svn that would be good; if you can't it probably is bzr-svn :P
<awilkins> I suspect that most of this data was committed in a single revision in the source SVN repo
<poolie> night all
<awilkins> Looks like 7 folder containing 150MB apiece of text files (60/60/25 MB) were committed in the same revision
<awilkins> Which is the revision it was choking on
<lifeless> awilkins: were you doing a pull from svn?
<awilkins> lifeless: Yes
<awilkins> lifeless: I just added a comment to the bzr-svn "Memory problems" bug
<awilkins> I suspect it's trying to process an entire revision in memory in one step
 * igc dinner
<lifeless> awilkins: that makes sense to me
<awilkins> I don't think svn even breaks a sweat - it doesn't even consume enough memory to hold one of the files as far as I can see
<awilkins> But it doesn't have to do any "transcoding" or however you want to term it
<lifeless> bzr itself won't either
<lifeless> its likely a interface mismatch
<Solarion> is there a way to change the parent and push information for a branch without actually pushing/pulling?
<Solarion> I changed servers, and would like to point the projects at the right place in a one-off batch job
<bob2> hack .bzr/branch/branch.conf
<Solarion> that sounds like it's inviting breakage
<bob2> how so?
<bob2> it's just an ini file
<Solarion> so no breakage?
<lifeless> a little bit of sed should be fine
<lifeless> or you could use the python API to set them
<Solarion> sed sounds easier for a one-off project like this. :)
 * Solarion is leery of poking around in .bzr
<Solarion> thanks!
<vadi2> Any work on when bzr-gtk will be updated in the ppa?
<vadi2> *word
<jelmer__> vadi2: what's broken about it?
<vadi2> if I upgrade my bzr to ppa version, bzr-gtk stops working - I was told it needs an update in the ppa.
<jelmer__> what bzr version does the ppa have?
<vadi2> I think 14 something and bzr-gtk is 13
<vadi2> 1.14.1 for bzr in the ppa
<jelmer__> vadi2: that should be sufficient, bzr 1.14.1 didn't change the API since bzr 1.13
<vadi2> "0.95.0+bzr629-1ubuntu1" for my bzr-gtk package... but it complains when I install the bzr ppa
<vadi2> well, I tried it before, let me try again
<vadi2> magic! works now :)
<vadi2> here's what I had before for some reason:
<vadi2> (08:36:26 AM) vadi2: Hi. I upgraded my bzr from the ubuntu ppa, and all of the g* commands broke - it says gtk+ wants an api version of 1, 13, 0 while only 1, 14, 0 is available. But there are no upgrades available.
<jelmer__> vadi2: you had bzr 1.14.0 which incorrectly claimed it broke compatibility with bzr 1.13
<vadi2> ohh
<lifeless> jelmer: I'm a check committer now :P
<Jemsquash> I'm getting a run() got an unexpected keyword argument 'location' when I type in bzr.exe xmllog --limit=200 build.xml. I'm using xmloutput 0.8.3 and Bazaar (bzr) 1.14. Does anyone know what the cause is & how to fix it?
<beuno> verterok, ^
<verterok> Jemsquash: do you have the traceback?
<verterok> beuno: hi, thanks!
<beuno> verterok, hi  :)
<Jemsquash> 0.233  Traceback (most recent call last):
<Jemsquash>   File "C:/tools/bazaar/plugins\xmloutput\xml_errors.py", line 61, in xml_error_handling
<Jemsquash>   File "C:/tools/bazaar/plugins\xmloutput\__init__.py", line 356, in run
<Jemsquash>   File "bzrlib\commands.pyo", line 937, in ignore_pipe
<Jemsquash> TypeError: run() got an unexpected keyword argument 'location'
<verterok> Jemsquash: it shouldl be fixed in trunk (vila's magic patches :)
<verterok> *should
<verterok> I'll do a new point release tonight
<Jemsquash> Ok Thanks. Do I pick it up from http://verterok.com.ar/bzr-eclipse/update-site/ ?
<verterok> Jemsquash: sorry, in bzr-xmloutput trunk :)
<Jemsquash> ah ok.
<Jemsquash> thanks
<verterok> Jemsquash: also there is a new build of bzr-eclipse with the new and shiny send dialog (courtesy of Javier)
<verterok> Jemsquash: btw, I'm working on bundling xmloutput in bzr-eclipse builds, so the only external dependecy is bzr itself ;)
<verterok> hopefully I'll have it ready in a few days
<Jemsquash> send looks good. First time I tried it was from the context of a file & it told me 'send is not enabled in this context'. I was a bit confused at first until I thought about what it was about. It worked from the project level.
<verterok> great!
<verterok> Jemsquash: yeah, that is a generic context handling error, it might be good that some commands override the default message
<Jemsquash> yeah. Could it be disabled for that context?
<Jemsquash> Am I misunderstanding something? I see that the project menu has a lot more enabled than the file context menu. Is there a reason the send menu item is here?
<verterok> Jemsquash: sure, check the performance preference page, there is a checkbox: action availability
<Jemsquash> ah ok.
<verterok> Jemsquash: but you'r right, it shouldn't be in the file/folder menu, and that's just a config issue in the plugin xml
<verterok> Jemsquash: could you file a bug about it?
<Jemsquash> Can do if you want. What's the performance penalty?
<Jemsquash> I'm assuming there is a performance penalty since the preference is in the performance preference panel.
<verterok> Jemsquash: the filtering by file/folder/project is "free", the performance issue is related to bzr specific checks, like: only enable Switch in a checkou, or unbind in a boudn branch, etc
<Jemsquash> Does that mean you want me to raise a bug that the default for that value should be on? Or change the message so that it mentions the preference or just the fact that menus should be disabled based on context?
<verterok> Jemsquash: no, that Send should only be present in the Project context menu
<verterok> e.g: like Branch
<Jemsquash> OK. I'll raise the bug now.
<verterok> Jemsquash: thanks!
<Jemsquash> np
<SamB> hmm ... that's annoying
<SamB> I can't use M-x dvc-diff from the editor bzr commit opens for me to write the commit message in :-(
<SamB> also ... shouldn't "bzr pull -d foo" give an error if it can't resolve "foo" to a branch to pull into?
<Jemsquash> At work we use clearcase and when we do a merge and there are multiple conflict the merge tool is quite nice. You can do the 3 way merge and once complete you save and exit. The tool the automatically moves onto the next conflict. Is there any equivalent process when merging lots of conflicts in bzr?
<verterok> Jemsquash: I use the extmerge plugin for the, bzr extmerge --all :)
<Peng_> What's the best way to run the test suite nowadays? Install testtools and subunut and whatever and use the parallel version?
<Peng_> Although then I have to remember how to spell "parallel".
 * SamB wishes there was a tool designed simply to help VCS's call 3-way-merge tools
<Jemsquash> Thanks verterok. Do you use kdiff3 are the any that play nicer than others with bzr? Especially with the .THIS .OTHER .BASE files. On Windows that is.
<jam> SamB, Jemsquash: for conflict in `bzr conflicts --text`; do kdiff3 $conflict.BASE $conflict.OTHER $conflict; done
<SamB> jam: well, I was actually thinking of how it would make using external merge tools with darcs easier ;-)
<verterok> Jemsquash: don't know in windows, I use gvimdiff or meld
<Mez> does anyone know what these damed ~1~ files are? ?
<beuno> Mez, yes, when you revert, you get those
<beuno> in case you didn't mean to  :)
<Jemsquash> Thanks verterok & jam. You've been very helpful. I'm off to bed.
<Mez> :'(
<Mez> bzr clean-tree doesn't clean them up
<Lo-lan-do> bzr ignored | xargs rm
<Lo-lan-do> Be sure to run "bzr ignored" first :-)
<jam> Mez: bzr clean-tree --ignored
<jam> actually, bzr clean-tree --detritus is what you want
<Mez> :P I just found that
<Mez> Lo-lan-do: cd $(bzr root); bzr ignored | awk '{print $1}' | xargs rm
<Mez> :P
<Lo-lan-do> "bzr ls --ignored" will save you the awk process
<Mez> :P
<Lo-lan-do> Hmm.  bzr root.  I've been hoping for that for quite some time.
<Mez> Lo-lan-do: it's been there for ages
<Lo-lan-do> Maybe I've just been missing it for quite some time :-)
<Lo-lan-do> Is there a similar command for getting to the root of the branch (in case of a lightweight checkout)?
<Mez> it's the same, I'm pretty sure
<Lo-lan-do> Apparently not.
<Lo-lan-do> I could of course parse the output of bzr info, but yuk.
<Lo-lan-do> Maybe I could hack that.
<awilkins> Isn't there an --xml for that?
<awilkins> Aha, `bzr xmlinfo`
<awilkins> (in the xmloutput plugin)
 * awilkins loves the Jaunty installer bit that resizes your windows partition and inserts an Ubuntu one
<Peng_> Cool, my VPS can run "bzr selftest --parallel subprocess" in 8m8s. :)
<Peng_> My PC has been going for...10.5 minutes and is only done with 13k tests.
<igc> jelmer: I haven't got those benchmark results yet sorry - still converting emacs to --development7-rich-root so I have a large dataset to benchmark against
<igc> night all
<Peng_> igc: Good night. :)
<awilkins> ]/join ubuntu
<Lo-lan-do> Anyone interested in a --branch-root option for bzr root?
<Lo-lan-do> It basically returns the directory where the branch.conf is to be looked for.
<Lo-lan-do> An implementation is at http://pastebin.com/f37535a4f (inspired by cmd_info)
<Lo-lan-do> Works for standalones, branches in repositories, and lightweight checkouts.  Not sure what more it should do.
<rockstar> abentley, if I wanted to initialize a shared repo in brisane-core, how do I do that?
<Peng_> rockstar: "bzr init-repo --development6-rich-root", I guess?
<abentley> Peng_: or --development-rich-root, which is an alias of that.
<Lo-lan-do> development6 != 1.14?
<abentley> Lo-lan-do: I believe 1.14 was a working tree format change.
<abentley> Lo-lan-do: brisbane-core is still a development format, not a fully-supported format.
<Lo-lan-do> I see.
<cornucopic> vila, ping. Hello.. 'authentication.conf' is looked into ONLY when the user/pass is not given in 'bazaar.conf'. right?
<vila> cornucopic: right
<cornucopic> vila, Cool. I am updating the bug report with clear description and how to reproduce. will ping you here once done.
<Peng_> Right. Lo-lan-do: 1.14 is the same as 1.9, except with a new working tree format that supports content filters.
<vila> cornucopic: it's even better if you write the *test* that reproduces the bug :)
<james_w> do I have to add things to possible_transports myself?
<james_w> i.e. if I do branch.Branch.open(location, possible_transports=possible_transports)
<james_w> to I have to add a transport from the resulting branch to possible transports before opening the next branch, or is that done for me?
<james_w> f not None, created
<james_w>         transports will be added to the list.
<james_w> great
<cornucopic> vila, yes. I have had a look at the test file..need to understand it a bit more to code up the test.
<vila> cornucopic: you may want to use 'bzr selftest -s bt.test_smtp_connection' to avoid running the whole test suite (but always run a bare 'bzr selftest' before submitting)
<vila> cornucopic: 'bzr selftest -s bt.test_smtp_connection --list' may be useful too
<jam> abentley: I added some comments to NestedTreesDesign
<amit_> vila, I lost my 'cornucopic' nick for sometime..I have updated the description. Its clearer now.
<Lo-lan-do> Bzr hackers: is there any way my "bzr root --branch-root" could be reviewed/merged, or should I turn it into a new command in a local plugin?
<beuno> Lo-lan-do, submit it for review!
<beuno> push up a branch, and file a merge proposal
<cornucopic> vila, ah. got it back. :)
<cornucopic> cornucopic, now I have to figure how to write the test case to produce the bug :)
<Lo-lan-do> beuno: Doing that.
<vila> cornucopic: again, look at bzrlib/tests/test_stmp_connection.py for example of smtp connection tests and also in bzrlib/tests/test_config.py for example of configuration files tests
<cornucopic> vila, Ok. Please take a look the bug description and let me know if you find anything ambiguous
<vila> cornucopic: that's fine, we never had so precise bug descriptions :-)
<abentley> jam: Thanks!
<Lo-lan-do> Um.  bzr branch lp:bzr is at 270 MB and still not done.  Should I worry?
<Lo-lan-do> (Downloaded, that is)
<Lo-lan-do> [/                   ] 283113kB @  766kB/s | Transferring:Walking content. 24646/24646
<beuno> Lo-lan-do, not at 766Kb/s   :)
<Lo-lan-do> That's just a peak
<Lo-lan-do> Anyway, the progress bar being where it is after probably 15 minutes leaves me worried.
<abentley> jam: You ask "Does ``bzr commit foobar`` commit just the subtree foobar?" but foobar is a tree, not a subtree.
<jam> abentley: so I probably misunderstood that exact statement, but what *does* "bzr commit subtree" do, and how do you get the various permutations of what you might *want* it to mean
<javierder> Hello. I'm having a persistent " Sorry, there was a problem connecting to the Launchpad server. "
<javierder> All day long =(
<beuno> javierder, production servers are having problems. You can use edge
<abentley> jam: I would expect it means "commit all the changes in the subtree, commit changes to the tree-reference".
<javierder> beuno, ok, thanks!
<abentley> jam: I don't have any particular answers for the others, but I presume we can add options.
<beuno> javierder, there, you should be automatically redirected to edge now
<javierder> beuno, magic!(?)
<javierder> beuno, thanks again!
<Lo-lan-do> beuno: Patch sent, without an URL for a public branch.  I grew impatient after 410 MB downloaded.
<Lo-lan-do> Now back to trying to understand bzr-upload-pack and get it to work.
<amit_> vila, Can I discuss the 'test_smtp_password_from_auth_config' with you
<amit_> ?
<vila> cornucopic: shoot :)
<cornucopic> vila, In 'self.get_connection' it is creating the authentication.conf contents right?
<cornucopic> vila, or the bazaar.conf?
<vila> cornucopic: bazaar.conf (you should have a look at bzrlib/config.oy if only to know the classes declared there and their associated files)
<cornucopic> vila, Ok!
<james_w> from the streaming pull bugs mail:
<james_w> If you are using stacked branches, then using bzr versions before
<james_w> 1.13.2, 1.14.2 or 1.14 and above may create repositories that cannot be
<james_w> streamed from.
<james_w> A fix for this issue will be included in bzr 1.15rc1, to be released
<james_w> on or about the 15th of May.
<james_w> "before ... 1.14.2 or 1.14" looks odd
<james_w> and does the "fix" in the second 'graph refer to a fix that will mean the server can stream from affected branches without the fix script?
<james_w> rather than being a fix for the problem of creating such branches in the first place
<cornucopic> vila, please take a look at http://pastebin.com/d4b9e5bce.
<vila> cornucopic: 1) don't modify an existing test, add a new one instead
<cornucopic> vila, you mean a separate file?
<vila> 2) Create the AuthenticationConfig from a text file, you can use triple quotes to create multi-lines strings without embedding the \n
<vila> cornucopic: no, a separate method whose name begins with 'test_'
<cornucopic> vila, the one you see is create by me!
<vila> Ho sorry, good then
<cornucopic> cool.
<vila> my eyes didn't catch the /password/server/
<vila> 3) you want to test that the correct user/password is selected, testing the _smtp_server is not relevant
<vila> 4) that means you should the auth configurations before calling get_connection()
<vila> s/should/should create/
<vila> 5) you can then test _smtp_username, _smtp_password
<vila> 6) you add an additional test to check that if the password is not specified the user is prompted (remember that it was *your* use case :)
<vila> no wait, we already have the test prompting for the password, instead we want to cross tests server with and without port
<vila> cornucopic: ^
<amit_> vila, we can continue here,,,
<vila> amit_: ouch what is the last message you got ?
<amit_> vila, 4) that means you should the auth configurations before calling get_connection()
<amit_> vila, (my Linux kernel confgs have been tossed up, so I keep getting disconnected by my PPPD)
<LarstiQ> 21:42:41 < vila> s/should/should create/
<LarstiQ> 21:43:09 < vila> 5) you can then test _smtp_username, _smtp_password
<LarstiQ> 21:43:52 < vila> 6) you add an additional test to check that if the password is not specified the user is prompted (remember that it was *your* use case :)
<LarstiQ> 21:45:50 < vila> no wait, we already have the test prompting for the password, instead we want to cross tests server with and without port
<vila> amit_: stop messing around with kernels :) Use a stable distribution !
<vila> LarstiQ: thanks :)
<amit_> vila, I have sobered down quite a bit and have stopped living on the bleeding eldge :)
<amit_> vila, just that 'apt-get' makes it so easy :)
<amit_> vila, but it prompts the password, which is just the way it should behave. Why do we test it? (My usecase didn't know about authentication.conf' )
<amit_> vila, If you see in the description of the bug, its the 'host:port' issue, the earlier modification that I proposed is not required at all
<vila> amit_: did you update the test ? Can you pastebin it again ?
<amit_> vila, I interchanged the last two lines, as you suggested.
<amit_> vila, nothing else..
<vila> the last two lines are:
<vila> #
<vila>          #conn._connect()
<vila> #
<vila>          self.assertEqual('mail.com:25', conn._smtp_server)
<vila> #
<amit_> vila, I have interchanged them and uncommented out conn._connect()
<vila> amit_: but you use the same object to connect twice, since the test uses a fake smtp server, it's better to connect only once
<vila> amit_: in fact you shoudn't use _connect() here, only get_connection()
<amit_> vila, twice? the connection is done only in conn._connect() right ? I don't understand...:(
<amit_> vila, get_connection actually connects? ah..why so?
<vila> amit_: ghaa, no, sorry, let me concentrate on that
<Lo-lan-do> Am I right in understanding there's currently no API to unset an arbitrary value from a configuration file?
<amit_> vila, Okay !
<amit_> vila, from what I see, it returns a connection object..
<vila> amit_: I'm re-reading the other tests, so, you still need to test that, if smtp_server embeds the port we still can match auth.conf (ports should never be embedded there, they *can* be specified explicitly though)
<helebek> Hi guys, I have a question.
<Peng_> helebek: That's cool, since someone probably has an answer. :)
<helebek> When I try to do "bzr init" in a folder (in dos prompt in windows), I get an error saying, "bzr: ERROR: [Errno 2] Can't create tunnel: The system cannot find the file specified."
<helebek> It seems a little under described to me, or maybe I am not understanding it.
<helebek> The folder is on a mapped network drive.
<helebek> However, I can do the same operation on another folder in the same drive.
<amit_> you mean to say, even him smtp_server embeds port, there can always be a explicit 'port'  declared?
<amit_> vila, ^
<amit_> vila, s/him/if
<vila> in authentication.conf, you use 'host=example.com, port=12', not 'host=example.com:12'
<amit_> vila, That case will probably work, but the bug is in the case in which the port is embedded in 'host'. So, shouldn't the test only test that ? (I could make one addition to see that 'port' is 'None' ). What do you say?
<vila> amit_: embedding the port in 'host' *is* a different bug (you're welcome to file it too :-), let's concentrat on that one
<helebek> Never mind, my question. The problem is solved when I deleted the ".svn" directory from the target folder. I think it had weird permissions.
<vila> it's legal to use smtp_server=example.com:1234
<helebek> Thanks any way.
<vila> amit_: we need to fill the gap between smtp_server allowing the port and authentication.conf not allowing it
<vila> amit_: if only the host is speficied in authentication.conf it should still match
<vila> amit_: that's the actual bug so your test should fail because we can't get the password from auth.conf with only host specified
<amit_> vila, I think I am confused about which bug to squash :(
<vila> amit_: then you can fix the code so that get_user() is called with host and port splitted which will allow auth.conf to match
<amit_> vila, could you please modify the bug desc. https://bugs.launchpad.net/bzr/+bug/372800 ? That will help me.
<ubottu> Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication during post commit email" [Undecided,In progress]
<vila> amit_: the bug is to call get_user() with a host embedding a port instead of separate parameters for host and port
<vila> https://bugs.edge.launchpad.net/bzr/+bug/372800/comments/3
<ubottu> Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication during post commit email" [Undecided,In progress]
<vila> amit_: The simplest approach seems to be to extract the port in smtp_connection.py just before calling auth.get_user() (auth.get_password() can reuse that).
<amit_> vila, what about the test case that I just produced to reproduce the bug?   Which bug is it reproducing anyway? (Isn't the bug filed yet? :)
<amit_> vila, Is it reproducing this: >> amit_: embedding the port in 'host' *is* a different bug (you're welcome to file it too :-), let's concentrat on that one<<
<vila> I meant let's concentrate on #372800
<amit_> vila, Yes. So, my test case is reproducing the  bug with 'host:pair' ?
<mwhudson> jelmer: hello
<mwhudson> jelmer: bzr-git seems to be working fairly nicely now
<mwhudson> jelmer: seems very cpu dominated, but i guess that's mainly down to not using a chk format yet?
<vila> amit_: your test use mail.conf in bazaar.conf and mail.com:25 in the auth.conf, that's not what you described in #372800, that's the opposite
<Peng_> mwhudson: Which branch do you get dulwich from?
<mwhudson> Peng_: trunk, i think
<amit_> vila, Its one of the 2 cases described there.
<amit_> vila, the vice-versa is also true
<mwhudson> Peng_: http://people.samba.org/bzr/jelmer/dulwich/trunk/ r296
<vila> amit_: no the vice-versa is another bug, host:port is not *valid* in auth.conf
<Peng_> mwhudson: Oh, thanks. I tried that yesterday but it didn't exist or something.
<amit_> vila, I see. But it works? that's the bug ?
<vila> What works ?
<mwhudson> Peng_: well, it existed the day before that i think
<vila> oh, using host=mail.com:25 is not recognized as an error in auth.conf, yes, that's the other bug
<amit_> vila, fine. I will file it with the test case :)
<Peng_> mwhudson: Yeah. it exists again right now.
<vila> amit_: you'll need another test for that, in test_config.py
<vila> amit_: but let's fix the first first :)
<amit_> vila, to check whether host is host:port ?
<amit_> vila, Yes :)
<amit_> vila, so, test case for the first bug..
<eferraiuolo> I'm having an issue setting up a bzr server which two people have ssh accounts on. We can't get the file permissions right. After going through a lot of work to get a root repos dir group-owned by a user group both of us belong to with sticky group permissions, and setting our umask to include group write permissions by default. Even with this when we run bzr+ssh:// commands group-writable isn't being applied
<eferraiuolo> It appears that bzr+ssh:// isn't using our ssh .profile umask setting
<eferraiuolo> There basically appears to be no straight forward way to have a server with bzr repos and branches be shared among two different user accounts that are being accessed via ssh.
<AmanicA> eferraiuolo: I also gave up at some point, and made a cron job that fixes everything every hour
<jelmer> mwhudson: hey
<jelmer> mwhudson: cool
<jelmer> mwhudson: yeah, that's indeed most likely related to not using a chk format
<AmanicA> eferraiuolo: something that has worked out better for me is bzr+https
<jelmer> mwhudson: and CPU is always going to be the problem for bzr-git
<AmanicA> eferraiuolo: through apache I think its possible to setup proper user permissions
<jelmer> mwhudson: as it has to convert between git and bzr serialization
<eferraiuolo> AmanicA: bzr+https, is that webdav that would allow writes?
<jelmer> mwhudson: network usage is bandwidth bound and memory usage should be O(delta)
<AmanicA> eferraiuolo: no just fastcgi
<AmanicA> it allows writes
<AmanicA> eferraiuolo: though maybe you can use webdav, but I don't really know
<AmanicA> what webdav is and what it does
<AmanicA> eferraiuolo: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
<james_w> jelmer: subvertpy and bzr-svn in the daily PPA, but the jaunty ppa branch failed with ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'"), so that's missing currently
<poolie> hello all
<james_w> hi poolie
<thumper> hi poolie
<jelmer> james_w: somebody else was maintaining the jaunty ppa branch I think, and created it from scratch (no relation to bzr-svn itself)
<jelmer> moin poolie
<thumper> poolie: I'd like to talk to you about stacking and brisbane-core at some stage
<james_w> jelmer: ah, ok. I'll take a look another time when I get fed up of the failures and probably work of the Debian branch or something
<poolie> hi thumper
<poolie> jam, are you still around? want to chat?
<poolie> hi jelmer
<james_w> development-rich-root doesn't support stacking?
<poolie> emmajane: the thing about fonts is interesting but it's not really a bug...
<thumper> james_w: nope, not at the moment
<james_w> damn damn damn
<emmajane> poolie, I did say feature request.
<thumper> james_w: yes
<thumper> james_w: want to fix it?
<thumper> heh
<james_w> thumper: I wasn't aware of that when we were in London
<poolie> james_w, lifeless is working on that soon i think...
<thumper> james_w: neither was I
<james_w> that means I can either push up large branches that stack, or smaller ones that don't
<james_w> smaller ones was better for other reasons as well, but I very much doubt they are small enough to not explode the disk space usage
<james_w> I should probably work in the latest non-development rich root format I guess?
<poolie> james_w incidentally you have bzr pqm access now, not sure if you knew
<james_w> poolie: you mean jml?
<james_w> I've had mine for a while :-)
<james_w> I should be doing a few more reviews though
<jam> hey poolie, yeah I'm around for a bit
<jam> (Guess I had my volume muted)
<poolie> no i meant you james_w, i was just updating the RT list as wasn't sure if you knew
<james_w> ah, I do, thanks
<lifeless> hi
<lifeless> poolie: what am I working on soon ?
<poolie> let me check if it's actually true :-) i was referring to b-c stacking, but i only remember you mentioning it
<lifeless> It came up yesterday when I was talking with thumper about some of the implications of moving a trunk to bbc today
<lifeless> Its not in my personal pipeline at all
<lifeless> Its a disk format capabilities thing; I think its in the vila/jam/igc grouping
<lifeless> igc seems to agree, but noone seems to have it targeted to do
<james_w> are there in-efficiencies in bbc->older format transfer?
<lifeless> james_w: stacking is done at the serialisation layer, so we can't [yet] stack cross serialisers
<james_w> I remember being partially upgraded over one format change was terribly inefficient
<lifeless> james_w: secondly, stacking is disabled in bbc itself and it needs to be enabled, fixed and tested
<james_w> what's your estimate for that work?
<lifeless> bbc-> older may be slow, it generates full xml on the way
<james_w> ok
<lifeless> james_w: I don't have an estimate for it at the moment
<lifeless> spiv and I have a branch that is aiming at fixing bbc<->other formats to be more efficient over the wire
<james_w> ok
<james_w> we had decided to go with bbc for all package branches, but I don't think we can do that currently
<jml> james_w: yeah, we were just talking about
<james_w> I'd like to understand the various implications so that we can make a sensible decision of how to proceed
<jml> james_w: no stacking is a deal-breaker.
<james_w> hey jml
<jml> (oh look, package branches auto highlights)
<james_w> jml: I agree
<james_w> heh :-)
<jml> james_w: so, I'd suggest 1.9-rich-root
<james_w> that's what I am thinking
<jml> lifeless, poolie: any thoughts?
<james_w> that means a couple of things:
<james_w> 1. an upgrade step once bbc is stable
<james_w> we will have needed development6 -> 2.0 upgrade, but that is less work I assume
<james_w> and would have fewer issues about inefficiencies in a partial upgrade situation
<lifeless> starting with rich roots is good
<lifeless> it will mean you don't have a million little root changes
<james_w> 2. I've forgotten 2
<lifeless> [I mean fresh imports into rr]
<james_w> it's not as good :-)
<james_w> we don't get to help you dogfood on a massive scale
<lifeless> jam: ping
<lifeless> poolie: if you want skype let me know ;P
<james_w> lifeless: do you agree on 1.9-rich-root then?
<lifeless> james_w: in the absence of vila/igc/jam standing up and saying hallelujah I will have stacking working by tuesday.
<james_w> ok, thanks
<thumper> lifeless: will that be in time for 1.15?
<thumper> is the 15th the date for 1.15rc1?
<poolie> thumper, lifeless, i filed bug 373455 as a handle
<ubottu> Launchpad bug 373455 in bzr "brisbane-core doesn't support stacking but should" [Undecided,New] https://launchpad.net/bugs/373455
<lifeless> poolie: perhaps these items are key enough we should use bugs to track them all
<lifeless> poolie: the 'before release items' I mean
<poolie> yes, i think so
<poolie> except i dislike bugs like "think about X"
<poolie> how do you know when it's done
<AmanicA> when your done thinking:)
<lifeless> poolie: I do to
<lifeless> poolie: so we shouldn't have ones for thinking about
<poolie> lifeless: jam said he'll pass `log DIR` back to ian with some thoughts and look at stacking
<lifeless> if the thinkng would result in an importance decision, make the bug critical
<poolie> probably not tonight though
<lifeless> and we can then think about it; if its not critical we drop the importance
<lifeless> how does that sound?
<poolie> sure, i didn't want to get too meta
<poolie> i think as long as there is a predicate like "decide whether or not to do XX" then it's actionable
<emmajane> poolie, you're far too practical. :)
<awmcclain> I have a branch that I haven't wroked on in a while, but that has significant changes from trunk. I'm about to start work again on the branch, but I want to merge in the changes from trunk since I created the branch. The problem is, when I merge from trunk, all the new files that I've created in the branch get removed. What are my options?
<poolie> awmcclain: really?
<awmcclain> poolie: Yup.
<poolie> that shouldn't happen, without them being conflicted or something
<poolie> are these plain bzr branches
<awmcclain> poolie: trunk is a bound branch (it's a checkout)
<poolie> but no foreign branches?
<awmcclain> poolie: From another VCS? No.
<poolie> awmcclain: so, unless there's a bug in bzr, those files shouldn't be removed unless your changes have already been merged into trunk and then removed there..
#bzr 2009-05-08
<awmcclain> poolie: Ahhh... that's it. I merged to trunk, found a significant bug, shelved the barnch for a while. I must not have reverted that merge in trunk.
<awmcclain> Oh, what a headache.
<poolie> awmcclain: so um
<poolie> try doing something like this:
<poolie> run log on the feature branch, to find the revisions with changes you want to keep
<poolie> then do a cherrypick merge of them into trunk
<poolie> this should bring the files back into existance
<awmcclain> then merge back into feature branch?
<awmcclain> Or, what if I create a new feature branch, and just cherrypick merge from my old branch into that?
<poolie> spiv: alive?
<poolie> spiv: did you already fix a dupe of bug 356699 perhaps?
<ubottu> Launchpad bug 356699 in bzr "not stacking when source branch doesn't support stacking, even though it states it will do" [Undecided,New] https://launchpad.net/bugs/356699
<poolie> awmcclain: oh sorry you're trying to merge trunk in, i see
<poolie> how about
<poolie> merge trunk, then do
<poolie> 'bzr merge -r 10..20 .'
<poolie> ie replay those changes from this branch
<awmcclain> oh, smart.
<awmcclain> where 10 is the feature revision where trunk and feature diverge, and 20 is the feature revision just before i merge trunk back in
<kenichi_> hello, a dev here just committed a change to a branch, somehow it included a remove and add of the same file, even though his 'bzr st' and 'bzr diff' before commit didn't show this change, and he claims he didn't touch that file.
<kenichi_> now a checkout of that branch fails with "bzr: ERROR: Revision {.......} not present in "....."
<poolie> kenichi_: using plain bzr or bzr-svn?
<kenichi_> i didn't set up this branch, but i believe the trunk it came from was initially set up with bzr-svn
<spiv> poolie: I'm alive, I don't remember fixing that bug, although anything is possible...
 * spiv quickly checks the recent changes
<poolie> it just sounded like something you changed
<spiv> lifeless has touched that code recently as part of cutting out more roundtrips from push.
<kenichi_> poolie: does bzr-svn cause  this?  is there somewhere you could point me to read up on issues like this?
<spiv> He may have accidentally fixed that at the same time, I'm not sure.
<poolie> kenichi_: i've seen some bug reports similar to this, i don't know specifically what's happening sorry
<poolie> jelmer might, or you can ask on the bazaar list
<kenichi_> ok, thanks
<jelmer> kenichi_: what's the bug # exactly?
<kenichi_> jelmer: i haven't filed a bug report, just the abridged paste above.
<jelmer> kenichi_: It's hard to say anything specifically related to the error class, can you perhaps pastebin the traceback?
<kenichi_> jelmer: i'm not actually getting a traceback, just the error, and a non-working checkout.  is there a arg i can pass to get more info?  (tried -v)
<kenichi_> jelmer: here's as much info as i have to give http://pastebin.com/d176d4a49
<lifeless> poolie: we have bugs remaining in autostacking
<lifeless> poolie: its possible I fixed the most recently opened one, but I haven't explicitly checked
<lifeless> spiv: how goes the ghost inventory tests?
<igc> morning all
<AmanicA> morning
<lifeless> hi igc
<igc> hi lifeless
<vxnick> hi guys - is there any way I can remove a "pending merge", as it's not showing up in my repository viewer for some reason :S
<lifeless> vxnick: bzr revert
<lifeless> vxnick: a pending merge is one that has been done to your working tree but not committed to the repository
<vxnick> lifeless: I see, thanks
<vxnick> lifeless: any way I can "undo" that revert? I didn't realise it'd remove everything I've just done :)
<lifeless> vxnick: uhm heh. It will have backed up to files with ~ in their name anything you had edited
<igc> poolie: fyi, my top tasks today are admin-related: hr, expenses, etc. I'll then try to get an email out re branch specific rules status & options going forward
<poolie> igc, thanks
<poolie> thanks for the user documentation
<lifeless> vxnick: things changed by the merge that you had not edited are recoverable by repeating the merge
<poolie> mine are too, specifically expenses, report and reviews
<vxnick> lifeless: sorry to bother you - how can I merge these back?
<lifeless> vxnick: can you rephrase, I don't quite follow the question
<vxnick> lifeless: well, I've reverted as you suggested - I see the ~ files; how do I put my changes back into the main files? Not sure how else to explain it I'm afraid
<lifeless> vxnick: first, repeat the merge
<vxnick> lifeless: bzr merge?
<lifeless> yeah, however you did it before
<vxnick> lifeless: well I didn't do it specifically last time; it just kinda happened :P
<vxnick> I'll give it a go
<vxnick> argh
<lifeless> ok, so once you've got the merge done, you can copy the ~ files back over
<vxnick> no idea
<lifeless> ok
<lifeless> what commands had you run leading up to this
<vxnick> right - initially I made a single-file commit; I then went on to work on some other files, and committed those as a newer revision. This stated that it would merge r127 (the single commit) into r128
<vxnick> the problem then being that r127 doesn't show up in my repo viewer
<vxnick> so I have since uncommited back to r126
<vxnick> then reverted as you suggested
<lifeless> interesting
<vxnick> in a bad way? :P
<lifeless> I'm trying to imagine why you would get told a merge is happening when you haven't apparently being doing merges
<lifeless> is this a checkout of a branch other people commit to as well?
<vxnick> I'm using bzr as a centralised system in this case
<vxnick> just myself
<vxnick> it made me bzr update before I could commit r127 (the single file)
<lifeless> ok!
<lifeless> bzr update is a form of merge
<vxnick> I see
<lifeless> ok
<lifeless> now, 127 is probably 126.1.1 now, because of the merge
<lifeless> but because you uncommitted its all rather invisible
<vxnick> right
<lifeless> have you got bzrtools installed? there is a command in there 'bzr heads' that may be useful
<vxnick> I believe so - I'll run it...
<lifeless> bzr heads --dead
<vxnick> just going to install it
<vxnick> I appreciate your help btw :)
<lifeless> anytime
<vxnick> bah bzrtools isn't working for me
<vxnick> probably because it's not compatible bzr 1.5 by the looks of it
<lifeless> you'd need bzrtools 1.5
<vxnick> ah yes, just trying it
<vxnick> lifeless: unknown command "head"
<lifeless> heads
<lifeless> its a plural ;)
<vxnick> returns nothing
<lifeless> bzr heads --dead ?
<vxnick> yeah a load of stuff
<vxnick> anything in particular I'm looking for?
<lifeless> well, it will let us undo the uncommit, if you want to
<lifeless> I'm not quite sure what the best way out of this is
<vxnick> hmm
<lifeless> anything you have committed is recoverable
<vxnick> so a revert only affects my working copy, not the repo?
<lifeless> and the backup files will contain any edits you'd made and not committed
<lifeless> right
<igc> poolie: if you get a chance, I'd like you feedback on the user doc as well, though that can wait til early next week
<vxnick> so if I wanted to, I could delete my working copy and do a fresh checkout?
<lifeless> a revert puts your local tree back to the state of the branch
<lifeless> it gets rid of edits and of pending merges
<vxnick> I see
<vxnick> not quite sure where to go from here to be honest
<lifeless> so, whats your current state? if I understand correctly you have
<lifeless>  - some stuff you uncommitted
<lifeless>  - some stuff we reverted
<lifeless> what would you like to have?
<vxnick> ultimately, I'd like to separate this merged r127 so I can commit it seperate to r128; but short-term I'd like to get back to where I was, which was without reverting :P
<vxnick> before reverting, even
<lifeless> so before reverting you had the content of the thing you'd uncommitted
<vxnick> let me just have a quick scroll up
<lifeless> I'm just gonig to reboot; I'll be back in a few minutes
<AmanicA> I keep on getting the following with bzr.dev (even after trying make clean; make  and I don't see old bzrlibs lying around in my pythonpath)
<AmanicA> bzr: ERROR: The API for "<module 'bzrlib' from '/stuph/projects/bzr/bzr.repo/bzr.dev/bzrlib/__init__.pyc'>" is not compatible with "(1, 14, 0)". It supports versions "(1, 15, 0)" to "(1, 15, 0)".
<vxnick> lifeless: thanks for letting me know
<AmanicA> (andrew) Bump api_minimum_version to 0.15.0 because of the removal of
<AmanicA>         InstallFailed.
<AmanicA> ^^^ that seems to be the culprit (pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m)
<lifeless> back
<vxnick> hi
<vxnick> right, I've checked my history
<vxnick> I uncommitted 128 and 127, so I'm currently at 126
<lifeless> ok
<lifeless> you should be able to just 'bzrpull -r revid:<whatever128was> .'
<vxnick> and all my changed files are at r126
<vxnick> I'll give that a try
<lifeless> (and bzr heads can give you the revid for what you had at 128)
<vxnick> it doesn't unfrotunately
<vxnick> heads --dead doesn't anyway
<lifeless> thats odd
<lifeless> well it will be in your  ~/.bzr.log
<vxnick> can I grep for 128 in that log?
<vxnick> it's pretty packed
<lifeless> yah
<lifeless> or at least  less, then /128
<lifeless> you're looking for a revid, which looks like email-date-random
<vxnick> righto
<vxnick> I've grep'ed for 20090508 and have one result, which I'm presuming is 128
<AmanicA> anyways, I'm surprised that nobody else is getting that problem, must be on my setup then.   have to sleep now. goodnight.
<lifeless> AmanicA: are you running nightlies?
<AmanicA> :)
<AmanicA> 3am
<lifeless> AmanicA: if you're running bzr.dev or a nightly package, you will get skew like this from time to time
<AmanicA> not sure what nighties are
<AmanicA> ah
<AmanicA> no bzr.dev
<lifeless> it means a plugin (e.g. bzrtools, or bzr-svn) hasn't updated.
<AmanicA> ok thx. I thought so but it seemed to be in __init__.pyc so I thought it a core issue
<vxnick> lifeless: is the revid the full me@domain-datetime-random string?
<vxnick> or just part of it
<lifeless> the full thing
<vxnick> thanks
<lifeless> to give it to the ui, prefix it with revid:
<vxnick> trying now
<lifeless> AmanicA: __init__ has 1,15,0, whatever is asking is asking for 1,14,0
<AmanicA> but that may just be wher bzr complains
<vxnick> lifeless: do I need the < > around it?
<AmanicA> ok thx
<lifeless> vxnick: no
<lifeless> for instances, revid:pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m
<vxnick> bah, gotta install bzrpull too by the looks of it :)
<lifeless> vxnick: 'bzr pull ...'
<lifeless> vxnick: you missing a space: )
<vxnick> woops
<vxnick> I was copying you literally
<lifeless> *I* missed a space ;)
<AmanicA> lifeless: thanks a lot for responging, I thought I was losing it for a while. Would have been nice if it said what wanted the new version, will look into it another night. anyways goodnight.
<vxnick> lifeless: I think you may possibly be a genius :)
<vxnick> lifeless: it says I'm on r128 now so I just need to resolve some conflicts
<lifeless> vxnick: ok, cool
<vxnick> are the .moved files the newer ones (r128) or the r126 ones?
<lifeless> older I would expect
<vxnick> many thanks for your help - I'll try to do it from here :)
<vxnick> really appreciate it
<lifeless> igc: responding to your doc is on my todo as well
<lifeless> however today is already quite full :)
<lifeless> spiv: reping, see above
<vxnick> I'm afraid I need some help merging these .moved files :(
<vxnick> not really sure how to do it
<lifeless> well
<lifeless> the easiest way is just to mv them over the non .moved files; if the non .moved files are unchanged (don't show up in bzr st or bzr diff)
<lifeless> then you can do 'bzr diff' and see the difference
<vxnick> I also have these ~1~ files left
<lifeless> similar/same process for them
<vxnick> these .moved files look identical - you're saying delete them basically?
<vxnick> or delete the originals
<lifeless> if they are identical delete them
<vxnick> question - are they conflicting because they're identical? bzr auto-resolves conflicts usually doesn't it?
<lifeless> they're conflicting because they were existing files where bzr wanted to put files
<vxnick> gotcha
<lifeless> bzr resolve can be used to tell bzr that you have resolved a conflict
<vxnick> thanks
<vxnick> ok, I've removed the duplicates however bzr resolve is still showing the conflicts
<vxnick> my mistake
<vxnick> I didn't do --all
<vxnick> lifeless: any chance we could attempt separating the merged r127 from r128?
<vxnick> or isn't that possible
<lifeless> vxnick: I'm reasonably sure they are separate in bzr's internals
<lifeless> vxnick: what does 'bzr log' show?
<vxnick> lifeless: it'd just be nice to view the changes in my repo viewer
<vxnick> lifeless: bzr log shows all revs up to 128
<vxnick> including 127
<vxnick> ah - it has 126.1.1
<lifeless> what happened is that you had two things happen at once
<lifeless> and you needed to merge to combine them - the 126.1.1 shows the thing that happened outside the 'trunk'
<vxnick> so is there anyway I can go back and do that?
<vxnick> the reason I'm so keen to view r127 is that it was a massive commit
<igc> bbiab
<lifeless> vxnick: well your repository view should be able to show it
<lifeless> just look at 126.1.1
<vxnick> 126.1.1 is the commit prior to the big one though
<vxnick> 126.1.1 was a single file commit
<jam> hey lifeless, I'm around for a bi
<jam> bit
<lifeless> jam: hi; just keen to get bbc->production readiness planned
<lifeless> I'm worried about iter_changes and stacking
<lifeless> jam: also we need to write our talks
<lifeless> for next week
<lifeless> s/for/during/
<jam> dang, its friday already ...
<lifeless> yup
<vxnick> lifeless: slight problem - I've checked-out the repo in a different place and bzr revno is showing as r126 :S
<vxnick> rather than 128
<vxnick> I tried bzr co -r revno:128 (not sure of the syntax) but it said no such revision
<lifeless> vxnick: that sounds like they are in your checkout only.
<lifeless> vxnick: if you are happy with how it looks now, do 'bzr push repo'
<lifeless> where repo is the url you checkout from
<vxnick> lifeless: any chance we can sort the 126.1.1 or is it stuck like that?
<vxnick> i.e. get it into its own rev no
<lifeless> vxnick: its basically stuck like that
<vxnick> lifeless: ok no probs - i'll push
<lifeless> it can be rewritten but its getting kinda complex
<vxnick> lifeless: "pushed up to revision 128" :-)
<vxnick> anything else or should I be good now?
<lifeless> should be good
<lifeless> go to your other checkout and do 'bzr update' to see
<vxnick> yeah am currently runnig
<vxnick> works fine
<vxnick> thanks loads
<vxnick> I'm glad there's a decent community around here
<lifeless> no problem
<jam> lifeless: did you just get a new gpg key?
<jam> I guess it is now "(My Canonical long address)"  :)
<lifeless> jam: I added a new signing subkey for a machine
<igc> jam: so 'log DIR' is slow in dev6rr because ...
<jam> so igc, 'log DIR'... I think we are fundamentally approaching it from the wrong direction, simply because that was the easiest for XML formats
<lifeless> jam: my laptop has it, but that new machine has only it.
<igc> Inventory.filter() is slow
<jam> igc: 'log DIR' is slow because the algorithm is structured to hit every item in the directory each time
<jam> rather than starting with changes
<igc> and it's slow because children is slow
<jam> 'log -v' on 1k revs of mysql is 3s
<jam> log DIR is 1m30s
<jam> O(tree) algorithms are *bad*
<igc> jam: so post-processing the delta will probably work *much* quicker
<jam> igc: From what I can tell, part of the issue is handling 'recursion'
<igc> jam: precisely
<jam> in that if someone gives "DIR" we need to figure out if "some-random-delta-file-id" is part of that DIR
<jam> there are a few ways we can do it
<jam> 1) Change Inventory.filter() for CHKInventory
<igc> jam: I couldn't see how to that faster down at the inventory layer (i.e. iter_entries(dir=X))
<jam> the size of specific_fileids() is always going to be much smaller and define a smaller subset of the set
<jam> iter_entries_by_dir(dir=X for X in specific_fileids)
<lifeless> jam: s/always/usually/. Pathological users abound.
<jam> but that still scales poorly
<jam> lifeless: this is a case where optimizing for the common case is probably going to give the best wins, as long as we aren't terribly pathological
<jam> 2) Do 'changes' first, and then filter that after the fact
<jam> technically the path filter can be computed from the parent_id_basename =>file_id map
<lifeless> jam: oh agreed; I'm just making sure we don't forget that silly things happen
<jam> and can be 'cached' between trees that have the same root hash
<jam> however, that still scales as O(entries_in_dir)
<jam> when O(num_changes) is often ~5-10
<jam> (on average)
<lifeless> also!
<lifeless> remember we're about to change iter_changes
<jam> So I was thinking that if we do a smart inversion of
<lifeless> this will impact chk delta stuff
<lifeless> and it may do so helpfully
<jam> for ..., file_id, ... in iter_changes():
<jam>   parents = get_id_path(file_id)
<jam> if file_id or parents in specifice_fileids:
<jam>  add
<jam> lifeless: right, because we are looking to include parents of changes, right?
<jam> igc: so I would inline the get_id_path part
<jam> because
<jam> a) You can keep a set of "known_uninteresting" directories
<lifeless> jam: yes, in an as-yet-un-pinned-down-way
<jam> as well as a set of "known_interesting" ones
<jam> so that you only have to recurse to the root sometimes
<jam> and as changes are likely to be grouped by dirs
<jam> you'll likely get fast culling
<igc> jam: sounds promising
<jam> igc: I *think* you could push some of that down into iter_changes, except you lose any chance to cache info between trees
<jam> as the *tree_shape* information could be cached between trees
<jam> as long as parent_id_basename_root_id (sha1) didn't change
<lifeless> jam: we could pass a cache in
<lifeless> lunchtime
<jam> however, by my numbers that only gives... 5:1 hits
<jam> so *something* but unless we added 'delta' support to the cache maintenance, I'm not convinced it saves a whole lot
<jam> (you could have the delta look at the parent_id_basename map changes, and determine what could be kept/discarded, but that takes more thinking.)
<jam> igc: do you feel like that is enough info for you to work on it?
<igc> jam: yes thank-you
<lifeless> I have a couple of thoughts too
<jam> lifeless: If I'm still here when you get back, I'd be interested in chatting a bit about stacking requirements and GC+CHK
<jam> GC makes stacking 'easy' because it doesn't have deltas
<lifeless> have you guys considered using the per-file graph to jump back in log DIR?
<jam> but CHK is doubly difficult
<lifeless> jam: stacking is currently serialiser-locked, I don't see how CHK impacts it
<jam> lifeless: as in finding the recursive set of possible file ids, and then grabbing all of their graphs
<jam> etc
<lifeless> jam: [recursive set] - no
<jam> lifeless: CHK 'externals' are not easily deduced from just the index
<jam> and they are potentially "deep"
<jam> in that the direct referenced one will reference more
<lifeless> I mean, in rev Y, under DIR, 5-10 files are changed
<lifeless> consider only their per-file graphs, and you get 5-10 possible revs to jump to
<jam> lifeless: I don't think you know that in Y-1 another 3 files disjoint were modified
<lifeless> jam: oh bother
<lifeless> jam: I really wish we'd had time to do the recursive-change field in inventories; it would solve this trivially
<jam> lifeless: right
<jam> though at the expense of a bit more data churn
<igc> lifeless: and another minor issue: the per-file graphs don't contain delete info yet & log needs to report that
<jam> lifeless: so if your smart fetch requires the complete inventory for a given revision in order to determine the file-ids to fetch
<jam> we only know the chk pages by *walking* them
<lifeless> igc: indeed
<jam> we can get some of that by the first pass as we transmit data
<jam> but that only gives us a single depth of referenced pages
<lifeless> igc: we can fix that by including a node at deletes
<jam> so we may need to walk *those* as well, in case of > depth-2 trees
<lifeless> jam: smart fetch requires a delta, not a inventory
<lifeless> jam: [once we have the delta patch finished]. CUrrently your 'make xml' hack is in place
<jam> lifeless: ouchie
<jam> lifeless: so GCVF already supports fallback versioned files
<jam> and passes the VF test suite for that
<jam> So the *only* whole I can think of for stacking support
<jam> is how we handle CHK pages
<lifeless> jam: I'd approach this by a) turning it on and reenabling it, see how it goes
<lifeless> b) look closely at whether we're going to have showstopper design issues, or things we can tweak to improve
<lifeless> hole?
<lifeless> today, I'd say we want the entire CHK tree for edge-revisions in the stacking branch, as this philosophically matches our current 'can get full inventory' rule for them.
<jam> lifeless: well, 99% of all current trees we work in are only going to be depth 2
<jam> (one root, then leaves, or at most 1 root + 1 internal + 1 leaf)
<jam> but the design is that they can be much deeper
<jam> I'm somewhat concerned that we won't have problems because depth 2 won't trigger bugs
<lifeless> ideally we can drop that back to 'all CHK page needed to generate a delta of any revision present against its parents'
<lifeless> jam: I'm really not quite understanding the concern; are you saying fetch won't copy the right data?
<jam> ATM, fetch has 2 passes, right?
<lifeless> or can't be made to copy it? or will be slow if it does?
<jam> The first pass could inspect the data it wants to transmit
<jam> to determine the data it needs to transmit
<lifeless> jam: StreamSource can do as many passes as it wants
<jam> except for CHK pages, that might need yet-another pass to get to the actual end
<lifeless> it generates 1 stream
<lifeless> StreamSink can, after insertion, say 'I need more data'
<lifeless> and that will result in a second stream
<jam> It only gets to say that 1 time, right?
<jam> but I guess you're right about stream sending a multi-pass stream
<jam> since we already do that now
<lifeless> the CHK pages introduced in the revs being pushed should all be included in the first stream, always.
<lifeless> if the revs are at the edge of the stacking repository, it will ask for the inventories of the adjacent-absent revisions
<lifeless> StreamSource in that case should provide all the CHK pages of those inventories
<jam> lifeless: so the 'pages introduced' should always be included, I'm wondering if the 'pages referenced' should always be included
<jam> as well as the inventories for adjacent
<jam> though I suppose that should overlap
<jam> I'm not sure it is 100% overlap
<jam> (might be)
<lifeless> pages referenced-and-not-introduced should be included in adjacent-inventories-full-page-set
<lifeless> a future improvement would be to have the second stream be 'pages-required-to-delta-against-this-but-not-the-full-closure' - and thats where it gets tricky and is why you are concerned.
<lifeless> that should be done after basic support is up
<jam> lifeless: right, especially because it depends on the delta algorithm
<lifeless> I think for fetch we should be only deltaing adjacently
<lifeless> or within the set being sent
<lifeless> really lunching now
<jam> lifeless: btw, I think dev6rr fetch just picks 'an' adjacent revision, not *all* adjacent revisions. Though it could certainly do so.
<lifeless> jam: if we can consolidate the two similar code paths it would do all
<lifeless> :)
<lifeless> hmm, regression in ignore:(
<lifeless> bzr ignore foo, where foo is a versioned directory, and contents of foo showing as unknown
<jml> a revision object has no reference to its repository
<jml> is this deliberate?
<lifeless> is it something we care deeply about? I don't think so
<lifeless> deliberate is harder to answer
<mwhudson> i can't say i've ever found that surprising
<mwhudson> revisions have always seemed pretty atomic in some sense to me, not that much more structured than strings in some sense
<mwhudson> huh, nice repetition hudson
<lifeless> in some sense
<jml> what's the difference between supports_delta and supports_diff in a log formatter?
<mwhudson> jml: delta is like bzr st, diff is like bzr diff
<mwhudson> (i think)
<jml> ok. that makes sense.
<jml> mwhudson: so, what you were saying earlier about revisions not being more than structured strings
<jml> mwhudson: I get that, but it can go either way wrt having a reference to a repository
<mwhudson> jml: yes
<mwhudson> well,
<mwhudson> no
<mwhudson> jml: i guess what i mean is that you don't go directly from a string to something else
<jml> sure
<jml> the string is often a key into a real object
<mwhudson> you might look up something under a string to find something else
<mwhudson> but you don't go string.object_with_key
<mwhudson> revisions are like that
<jml> *nod*
<jml> but maybe they could also be such that revision.get_parents() worked.
<mwhudson> yeah
<jml> I'm just noticing that I can't use a log formatter to show the author of the second-to-left parent revision of mainline as the author of the mainline revision.
<mwhudson> ah
<mwhudson> the log formatter doesn't get the branch or repo or anything?
<mwhudson> well, i guess there may not be a branch
<jml> mwhudson: no.
<mwhudson> ugh
<jml> mwhudson: I mean, you subclass the log formatter, so you can pass it one yourself
<mwhudson> yeah, but that's pretty icky
<mwhudson> will work for what i guess you're doing :)
<jml> and in the canonical use case, there is a branch
<spiv> lifeless: late pong
<lifeless> spiv: its all there in history ;P
<lifeless> how is it going basically
<spiv> lifeless: I've been taken a little by surprise by fileids_altered_by_revision_ids, when a (stacked, no fallbacks set) repo has say rev-2 but not rev-1, and rev-2 doesn't change any files from rev-1, fileids_altered_by_revision_ids(['rev-2']) still reports rev-1.
<lifeless> right
<lifeless> thats the root of the bug in fact
<lifeless> heres why it occurs:
<lifeless> without rev-1's inventory, we can't calculate the delta
<lifeless> so we get everything that is referenced
<lifeless> not new references
<lifeless> its why we want rev-1's inventory in the stacking repo
<spiv> Yeah, it makes sense (the fulltext inventory clearly says "this file is at version rev-1"), but for some reason I was expecting fileids_al... to incorrectly deduce rev-2 there.
<lifeless> ah
<lifeless> :)
<lifeless> it used to return nothing
<lifeless> this lead to bugs in fetch where incorrect inventories caused stuff to be dropped
<lifeless> so we fixed that
<spiv> It doesn't really matter which version it reports, so long as it reports something and I can check that it's present.
<spiv> i.e. this doesn't break my fix, but it's caused me grief when designing tests.
<lifeless> if rev1's inventory is there it will report nothing
<lifeless> if its not there it will report rev1's version, because rev2 doesn't have a version
<lifeless> ok
<spiv> (Also, there are no explicit unit tests for this corner of fileids_al...'s behaviour)
<lifeless> what do you want to test
<lifeless> spiv: uhm, there are actually, its just that those tests are pretty much inpenetrable
<spiv> That the fix works ;)
<lifeless> ok
<spiv> More specifically,
<lifeless> less broads
<spiv> [re: fileids_al...'s tests, grep didn't find any other than test_fileid_involved.py, and it has no tests that show a revision in the result that wasn't passed as an arg to fileids_al...)
<lifeless> hmmm, you may be right
<lifeless> I know I wrote tests when I changed it
<lifeless> it may be layered
<lifeless> so - what behaviours do you want to ensure
<lifeless> 'it works'
<lifeless> that can be expanded
<lifeless> are there things that shouldn't happen
<spiv> Anyway, I'm testing: simple linear history where [parent inv missing + all texts present -> ok], [parent invs present + new texts present -> ok], [parent inv missing + text missing -> not ok]
<lifeless> and things that should
<lifeless> ok
<spiv> Also, ghost rev that does not cause missing texts -> ok
<lifeless> that shouldn't interact badly with fileids_altered
<lifeless> branchbuilder supports ghosts now
<spiv> Ah, handy, I didn't know that.
<lifeless> I added it for a test
<lifeless> look at record_snapshot's docstring
<spiv> Also, I found I needed to use add_inventory directly on the target repo rather than get/insert_record_stream, because ensuring that I get a single fulltext inventory record was too fiddly with the stream API.
<lifeless> thats surprising
<lifeless> I would have expected roughly insert_record_stream(FullTextRecord(get_record_stream(foo, 'topological', True).next())) to Just Work
<spiv> Right, I could probably manually assemble a FullTextContentFactory, but that's considerably more complicated than just calling add_inventory.
<lifeless> true
<lifeless> add_inventory is fine too
<spiv> Yeah.  I was a bit reluctant too at first, because it takes the test slightly further away from the way streaming fetch works, but I made peace with the idea fairly quickly :)
<spiv> s/too/to/
<spiv> Anyway, I feel that I do understand all the dark corners now, so it's going rapidly now.  But right now it's lunch time!
 * spiv -> food
<lifeless> excellent
<lifeless> I'm doing pdr stuff
<lifeless> so just ping if you are able to save me from it at any point
<lifeless> oh yeah
<lifeless> jml: https://code.edge.launchpad.net/~lifeless/subunit/autoconf/+merge/6328 is textually large, but code wise tiny
<lifeless> jml: I'd love a review :)
<jml> lifeless: I might not get around to it for a week or so
<jml> lifeless: but I'll put it on my todo list -- who knows what will happen!
<lifeless> jml: I'lll nag other people then
<lifeless> jml: as it will block me
<jml> lifeless: ok.
<lifeless> jml: or you can opt and and I'll land it as is
<jml> lifeless: I'm basically talks talks talks until next weekend :)
<lifeless> beamer where art thou?
<lifeless> jml: basically it moves subunit to use autoconf; this gives the library a good soname and makes it packagable
<jml> ok.
<lifeless> jml: no python code changes at all; minor changes to the shell tests to support VPATH builds
<lifeless> spiv: I've checked, build_snapshot in bzr.dev has support for ghosts
<krisfremen> hello there, i'm gettign "Cannot build extension "bzrlib._btree_serializer_c"."
<krisfremen> anyone knows a little bit of insight as to what is wrong?
<lifeless> there should be more output than that
<krisfremen> it's quite long
<lifeless> if you can pastebin it somewhere I will look at it
<krisfremen> http://pastebin.com/d2a36e92d
<lifeless> #
<lifeless> bzrlib/_btree_serializer_c.c:4:20: error: Python.h: No such file or directory
<lifeless> #
<lifeless> that suggests you don't have the python library header files on your system
<lifeless> you might prefer to use a prebuilt bzr, but if you do want to build bzr yourself you need 'python-dev' or whatever the package is called on your operating system
<lifeless> or you can run bzr without building the extensions (it can run as pure python)
<krisfremen> i do have that package
<lifeless> can you do
<lifeless> ls /usr/include/python2.5/Python.h
<krisfremen> hmm
<krisfremen> not there
<lifeless> are you running jaunty ?
<krisfremen> debian lenny
<lifeless> hmm, I think that has 2.5 as defalt
<lifeless> *default*
<lifeless> anyhow, you need /usr/include/python2.5/Python.h
<lifeless> I think its normally in python2.5-dev, which is pulled in by python-dev usually
<krisfremen> sudoed it and it worked
<krisfremen> weird, maybe some permissions are messed up
<krisfremen> thanks!
<lifeless> no probs
<jam> spiv, lifeless: btw, if you add a FulltextContentFactory, I believe it goes down to '.add_lines()' which can create a delta
<jam> you have to insert a KnitFulltext record if you want to force it to be a full text
<jam> though I believe add_inventory() can also generate a delta
<lifeless> jam: it won't create a delta if the target repo is missing the parent
<lifeless> jam: which is the scenario
<lifeless> jam: the point is to avoid dragging the parent content around by mistake
<lifeless> -> pdr stuff done
<lifeless> deep hacking time on check; if anyone wants me SMS or ring
<lifeless> abentley: if you're around; we used to have code for determining left-hand-distance-to-null; do you happen to recall what we did with it?
<lifeless> (I'm refactoring Branch.check to take a precalulated graph rather than every branch doing the same thing)
<jml> does bzrlib have a standard way of taking an optional location and turning it into a branch?
<jml> should it?
<lifeless> EPARSE
<lifeless> [what talk are you writing btw, and if you're all talk at the moment, consider  mailing jam and I]
<jml> lifeless: I think the cost of explaining what I mean is greater than or equal to the cost of figuring it out myself :)
<lifeless> jml: if you mean 'open_or_init' or something like that, uhm no, And I don't think so
<lifeless> if you mean something else, maybe, who knows.
<jml> lifeless: I mean more like a command-level thing for saying "just default to the branch that's in the current directory."
<jml> lifeless: but I think that's just if location is None: location = '.'
<jml> talks I'm doing are: Introduction to Twisted; Tour of Launchpad Code; Teach Me Packaging; "Your Code Sucks and I Hate You"
<jml> lifeless: and whatever help I can spare for your & jam's talk
<lifeless> jml: we're doing two :P
<lifeless> so please pluralise :)
<lifeless> jml: anyhoo, thats Branch.open_containing
<jml> lifeless: the one I submitted the proposal for :)
<lifeless> and yes, if location is None: location='.'
<lifeless> jml: la-la-la-la
 * igc celebrates completing his just-in-time hr paperwork by starting his many-weeks-late expenses paperwork
<spiv> igc: :)
<spiv> igc: I know the feeling!
<igc> spiv: does that mean you've remembered my "review me" invitiation? :-)
<spiv> igc: yes :)
<spiv> igc: (doing those now, in fact)
<bialix> luks: ping
<luks> pong
<bialix> luks: I'd like to make Gary admin of qbzr google group. He's most active these weeks
<luks> sure, no objections to that
<bialix> ok
 * igc packs it in for the day
<igc> have a good weekend all
<abentley> lifeless: It's on Graph.
<abentley> lifeless: Graph.find_distance_to_null
<lifeless> abentley: thanks
<Mez> how do I create a working tree for something that doesnt have one ?
<beuno> Mez, bzr co .
<ricardokirkner> hi. is there any way to have a bzr repo be pushed to svn, and keep each commit author? (I mean, every team member commits to a central bzr repo, and from there one person pushes to a svn repo... each individual commit.. retains authorship, or are all commits re-owned by the person who effectively pushes to svn?)
<lifeless> jelmer: I've packaged subunit
<lifeless> jelmer: if you want to change the maintainer field and do the upload to close your bug in debian, that would be fine
<lifeless> ricardokirkner: bzr will add metadata saying the original author, but I'm not sure whether svn looks ast that or not; I suspect it doesn't.
<ricardokirkner> lifeless, it uses svn properties for that right?
<ricardokirkner> I had some issues with that... its not very nice from the svn point of view to have a lot of properties set/reset on each commit
<jelmer> ricardokirkner: it uses revision properties if you have a new enough version of svn (svn >= 1.5)
<jelmer> lifeless: ah, nice
<jelmer> lifeless: care to be co-maintainer ?
<lifeless> jelmer: sure
<ricardokirkner> jelmer, and if you have a lesser version? what does it use?
<jelmer> ricardokirkner: file properties
<ricardokirkner> jelmer, sorry I am missing something here..
<ricardokirkner> svn:ignore is a svn property... this is a revision property?
<ricardokirkner> if so, what is a file property?
<jelmer> ricardokirkner: svn:ignore is a file property
<jelmer> ricardokirkner: revision properties are generally not visible for the user
<lifeless> jelmer: https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases revno 70
<savvas> does bzr require repackaging like git if it gets big?
<lifeless> savvas: bzr automatically packs as needed
<lifeless> you can manually trigger a pack if you have reason to, but its not something we recommend
<jelmer> lifeless: whu
<jelmer> lifeless: what sort of fancy branch is that?
<lifeless> jelmer: package branch
<savvas> it's ok, I like "automagic" :)
<lifeless> halt()
<lifeless> gnight
<Odd_Bloke> How can I list the files changes in a commit?
<Odd_Bloke> *changed
<beuno> Odd_Bloke, -v
<lifeless> Odd_Bloke: bzr st -c revno
<lifeless> Odd_Bloke: log -v -c revno
<lifeless> bzr diff -c revno | diffstat
<lifeless> (really gone now)
<jelmer> lifeless: ah, interesting
<jelmer> lifeless: 'night
<lifeless> jelmer: oh
<lifeless> one more thing
<lifeless> there is a tarball
<jelmer> lifeless: and appropriately set debian/watch ? :-)
<lifeless> no
<lifeless> watch can't do bzr well
<lifeless> https://edge.launchpad.net/~subunit/+archive/ppa
<jelmer> lifeless: it can deal with tarballs though :-)
<lifeless> grab the -65 tarball from there
<jelmer> lifeless: btw, how do I register new package branches?
<lifeless> jelmer: yes, but I'm not making official release tarballs at this point
<lifeless> jelmer: usual way, push to em
<jelmer> lifeless: ah, k
<jelmer> lifeless: but mirrorred branches? There's no register link
<lifeless> the tarball of -65 is a snapshot, you could make your own but nicer to reuse
<lifeless> jelmer: I don't know that you can, or that it has even been considered
<james_w> jelmer: not currently possible to have a mirrored package branch
<lifeless> jelmer: anyhow, lp is fast now
<jelmer> lifeless: Yeah, but I'd like to register the branches on bzr.debian.org
<lifeless> good use case
<lifeless> jelmer: ^
<jelmer> as packaging branches seem to be supported for debian in lp too
<lifeless> james_w: ^
<lifeless> ciao
<james_w> they are
<james_w> I think the immediate problem is that the form for registering just has a space for "Project:"
<james_w> so it can't be used
<james_w> I don't know if there are more fundamental issues
<Kamping_Kaiser> Is any special work required for a bzr 'head' branch?
<Kamping_Kaiser> (in a configuration sense)
<jelmer> james_w: should I file a bug?
<james_w> Kamping_Kaiser: you might like to set "append_revisions_only", but other than that there isn't much
<james_w> that's not required, it just enforces something that most people expect for a "head" branch
<james_w> jelmer: bug 347755 I think
<ubottu> Launchpad bug 347755 in launchpad-code "No UI for registering package branches" [Medium,Triaged] https://launchpad.net/bugs/347755
<Kamping_Kaiser> james_w, thanks.
<LarstiQ> whatever is a head branch?
<jelmer> james_w: thanks
<Kamping_Kaiser> LarstiQ, something I link to on a public site as a 'known working' rcs snapshot
<LarstiQ> Kamping_Kaiser: ah ok, so not trunk if that isn't guaranteed to be known working
<Kamping_Kaiser> LarstiQ, true, the wording on my part was bad.
<gcerquant> I have a noob question: I just did a merge and have some conflicts. I understand the .OTHER files are the one from the branch I am merging into the branch I am working on. Could someone clarify what is the .BASE and .THIS?
<awilkins> Can anyone tell me how to get the Nautilus integration going in bzr-gtk?
 * awilkins installs the GNOME-python binding
 * awilkins discovers they are already there
<james_w> gcerquant: THIS is from the tree you merged in to
<james_w> gcerquant: BASE is the common ancestor
<gcerquant> But I branched a copy, worked on it, and then merged it back
<gcerquant> shouldn't THIS and BASE be the same ?
<awilkins> They won't be because if THIS and BASE were the same, there would be no conflict
<awilkins> Which OS are you using?
<gcerquant> Mac
<gcerquant> ok, I get it
 * awilkins doesn't know much about 3-way merge editors for Mac
<vxnick> gcerquant: changesapp.com is good
<gcerquant> I forgot I did a revert on the main branch
<awilkins> I was going to suggest it might be easier if you open it in meld / TortoiseMerge / stuff
<gcerquant> Changes.app is awesome, yes
<gcerquant> thanks for your help
<vxnick> gcerquant: you can also integrate it with bzr if you haven't already :)
<gcerquant> I did :)
<gcerquant> with this alias: diff = diff --using=chdiff
<gcerquant> anything more efficient?
<vxnick> gcerquant: add it your .bashrc file
<vxnick> sorry
<vxnick> ignore that
<gcerquant> np
<vxnick> gcerquant: ALIASES]
<vxnick> chdiff = diff --using chdiff --diff-options --wait
<vxnick> gcerquant: in ~/.bazaar/bazaar.conf
<vxnick> [ALIASES] on the line above it
<gcerquant> yep, that's what I have
<gcerquant> except for the --wait options
<gcerquant> what does it change?
<james_w> --diff-options isn't passed to chdiff in that case is it?
<vxnick> gcerquant: http://pastie.org/472261
<vxnick> gcerquant: it means you can use "bzr chdiff"
<vxnick> gcerquant: --wait means bzr halts until changes.app is quit
<gcerquant> but unless I miss something, I prefer it without the wait
<vxnick> fair enough :)
<gcerquant> so I can open a diff, look at it in Changes, maybe do an other commands in my term (bzr conflicts, or just ls...)
<vxnick> yeah
<vxnick> I see your point
<vxnick> I think I just copied/pasted the whole thing from the changes website
<vxnick> it wasn't a conscious decision
<gcerquant> :)
<gcerquant> I had done a script for Changes in svn to edit the files in place, with the right name. So I could edit and save within Changes, and be done
<gcerquant> might adapt it for bzr
<gcerquant> vxnick, what do you develop for Mac?
<vxnick> gcerquant: I just do web stuff - LAMP type stuff
<awilkins> Here's a thought - could we use an "ignored" status change kind ; e.g. - you've got a file that you want to stop tracking, the only way being to `bzr rm --keep foo` and then `bzr ignore foo` ; unfortunately when others pull your revision this will delete their local copy of the file instead of just ignoring it.
<awilkins> In other words, would tracking the use of `rm` vs `rm --keep` as separate types of change be useful (for me, yes).
<vxnick> awilkins: I think that sounds sensible
<vxnick> prevention is better than the cure ;)
<awilkins> Specific example, using Maven with the eclipse plugin ; it generates .project files ; someone has added these to version control in error.
<awilkins> I want to remove and ignore them without spoiling his day.
<awilkins> Ok, he can just regenerate them :-)
<gcerquant> http://paste.lisp.org/display/79905
<gcerquant> It looks like my merge produce a conflict because I removed a new line.
<gcerquant> Is this possible?
<gcerquant> Is there an option for that?
<gcerquant> I. Just. Love. Bazaar.
<LeoNerd> .oO( "Get a roooom!" )   ;)
<gcerquant> :-p
<vxnick> I love it too - can't bring myself to use anything else :P
<gcerquant> I have check other system, but bzr has the right approach for so many things it's a no-brainer decision
<vxnick> yeah
<vxnick> I *love* bzr uncommit ;)
<gcerquant> can you unrevert as well?
<gcerquant> I was once burned by this with svn (used an newly alias the wrong way. alias was deleted just after I finished crying)
<LeoNerd> revert saves a backup copy of the modified files in the local checkout. I don't know if it has an automatic "unrevert" command, but you can just  mv foo.c.~1~ foo.c
<LeoNerd> Though usually I use vimdiff between them
<james_w> there is no unrevert
<james_w> one day...
<bialix> jelmer: are you around?
<james_w> hi bialix
<bialix> hi james_w
<bialix> there is question about conversion from svn: http://stackoverflow.com/questions/839683/how-to-migrate-from-a-complicated-subversion-repository-to-a-distributed-version
<bialix> jelmer: ^^
<jelmer> bialix: answered
<bialix> thx
<Peng_> Haha, subunit switched from scons to autoconf *one day* after i installed scons specifically for it. :P
<LarstiQ> make it switch back!
<Peng_> Since I'm just using it for Python, I don't even need to compile it though.
<LarstiQ> ronny: try again. I note http://paste.pocoo.org/show/116024/ doesn't include releases like 1.14.1
<ronny> LarstiQ: yes, its a bit incomplete, its just a pretty generic guess
 * LarstiQ nods
<LarstiQ> ronny: you could try parsing http://pypi.python.org/simple/bzr or something like that
<ronny> LarstiQ: i will probably put dealing with that in an actual py.test extension using the xmlrpc api or some code i worte for the pida plugin updates
 * LarstiQ might want some code like that too
<LarstiQ> ronny: anyway, for the releases in that script, they should now work :)
<ronny> LarstiQ: i just wrote a scanner for the simple http pypi
<ronny> its pretty nasty and just has some regex
<ronny> it works semilar to things like easy_install and pip
<ronny> #its just less smart
<LarstiQ> right
 * LarstiQ has read the easy_install code
<LarstiQ> that's actually how I got to know about /simple/
<ronny> i hope you didnt cry in tears of blood
<LarstiQ> only a little bit
<ronny> reading code by pje is a #1 health danger
<ronny> well, luckyly hes now a self-refactoring guru and wont fuck up python any more
<LarstiQ> he has had some good ideas tough
<LarstiQ> mainly thinking of wsgi here
<yam> quick ? - I want to look at a file from December in my bzr repo, and then go back to today's version
<yam> possible?
<jam> yam: bzr cat -r XXX file
<jam> or bzr revert -r XXX file; bzr revert file
 * LarstiQ thought yam was talking to himself
<LarstiQ> jam: how are you doing?
<jam> LarstiQ: I'm doing pretty good. how about you?
<yam> Sorry, not talking to myself, trying it out - works!
<LarstiQ> yam: I meant you and jam's nicks being very similar
<yam> thank you kindly - I knew that IRC would be the answer I needed
<LarstiQ> jam: feeling a bit ground by work and studying, but otherwise not unhappy
<yam> LarstiQ: yam jam sounds pretty good, actually
<andriijas> how do i remove a pending merge tips?
<jelmer> andriijas: bzr revert --forget-merges
<andriijas> thx
<rellis_> HI everyone. I am seeing this bug https://bugs.launchpad.net/bzr-svn/+bug/373726. Has anyone else seen this, is there a nifty workaround?
<ubottu> Ubuntu bug 373726 in bzr-svn "Error importing svn repository" [Undecided,New]
<LarstiQ> rellis_: I haven't seen that before, but it violates an invariant of bzr, I wonder how you got to that point.
<LarstiQ> hmm, I can think of one way to do that.
<psykidellic> Hi, I guess I am missing something very stupid in the docs. But how do you init a branch with an existing branch info?
<jelmer> rellis_: hi
<psykidellic> *init a new
<jelmer> rellis_: I think this might be a bug that's fixed in 0.5.4, is there any chance you can try with that?
<jelmer> rellis_: Is this repo publicly accessible?
<LarstiQ> psykidellic: do you want a copy of the other branch? `bzr branch old new`
<LarstiQ> psykidellic: if not, it is unclear to me what effect you're after
<psykidellic> LarstiQ: We have a branch at: /bzr/project/branch..... . I created a new repo using: init-repo. I want to import project/brnach with all its history to the new repo.
<psykidellic> *branch
<LarstiQ> psykidellic: if it's one branch, just `bzr branch` it.
<psykidellic> LarstiQ: Alright. And it will be added to repository when I push it first time.
<LarstiQ> psykidellic: if I understand you correctly as having added a repository after deciding a standalone branch wasn't the way to go, `bzr reconfigure` might be handy.
<psykidellic> LarstiQ: Exactly :)
<LarstiQ> psykidellic: that's fine too
<psykidellic> LarstiQ: You read my mind!
<LarstiQ> psykidellic: specifically, `bzr reconfigure --use-shared` would have been of help to you
<psykidellic> I have not yet branched to new one. I will look into reconfigure now.
<psykidellic> Thanks.
 * psykidellic goes back to docs.
<lifeless> jelmer: bah, packaging fail. I'm fixing
<lifeless> jelmer: all fixed now
<lifeless> missing pkg-config build-dep
<lifeless> Peng_: its packaged now
<lifeless> launchpad.net/~subunit/+archive/ppa
<xlax> Can anyone explain why I can't push any repo? I constantly get "Target directory xx already exists [...]" or "Generic path error"
<xlax> Or permission denied errors are common too.
<lifeless> xlax: are you pushing to launchpad?
<xlax> lifeless: no, I'm trying my own (s)ftp solution.
<xlax> Because I need the project to be private, and I didn't see any option for that in launchpad.
<FurnaceBoy> hi all. is there a pure CLI way to achieve per-file commit messages? I'm using bzr on a headless box
<lifeless> launchpad cann host private projects, but its for a fee.
<lifeless> anyhow - Target directory xx already exists - means you've made a directory rather than having bzr push to a  new directory.
<lifeless> either pass --use-existing-dir to push, or don't make the branch directories by hand
<lifeless> the GPE I'd need to see a backtrace of - there will be one in ~/.bzr.log
<xlax> lifeless: using --use-existing-dir will get me the GPE ^^
<lifeless> FurnaceBoy: I don't think so
<FurnaceBoy> lifeless, hm ok, thanks. just on a project whose policy encourages them.
<Peng_> lifeless: Oh, nice. I've already set up running it from source, so I'm not sure I'll bother with the PPA though. Plus I don't run Jaunty.
<lifeless> FurnaceBoy: you could use the python interface, or write aplugin to support it.
<lifeless> FurnaceBoy: mainly a UI problem, its a lot easier to write that sort of thing in a gui
<FurnaceBoy> lifeless, interesting!
<FurnaceBoy> lifeless, I'll think about that. thankyou
<lifeless> FurnaceBoy: feel free to file a bug saying you'd like it in the CLI
<lifeless> Peng_: lenny?
<FurnaceBoy> lifeless, is the main Bzr on lp?
<Peng_> lifeless: Hardy. Plus Gutsy. :X
<Peng_> (I'll upgrade soon i swear!)
<lifeless> FurnaceBoy: http://launchpad.net/bzr
<lifeless> Peng_: :)
<FurnaceBoy> lifeless, ok, so if i wanted to write such a plugin, would i branch to do it? (sorry i'm new to bzr/lp)
<lifeless> Peng_: hopefully jkakar will do the autoppa magic and I can upload gutsy and hardy too
<lifeless> FurnaceBoy: well a plugin is a new separate project; so you'd start a new project, which would be a bzr plugin
<Peng_> lifeless: Is creating gutsy packages even allowed anymore? It's not supported...
<lifeless> FurnaceBoy: or you could just patch bzr itself; it might be easier in this particular case:- for that you would branch bzr, yes.
<lifeless> Peng_: not sure.
<lifeless> hardy is
<xlax> Hmm. It seems my host has an odd way of calling its directories...
<jkakar> lifeless: AutoPPA magic for Bazaar?
<lifeless> jkakar: subunit
<lifeless> jkakar: (hi)
<jkakar> lifeless: Ah, okay, yeah, I should finish that since it's already half done.  Hi! :)
<lifeless> jkakar: I've done C/python/tools/C-dev packages
<jkakar> lifeless: I noticed that.  I'll see if I can review/integrate your changes sometime this weekend.
<lifeless> jkakar: they're built https://edge.launchpad.net/~subunit/+archive/ppa and code is https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases
<jelmer> lifeless: btw, the last entry in changelog is by robertc@lifelessdesktop
<lifeless> debian/changelog?
<lifeless> meh, I haven't set DEBFULLNAME and DEBEMAIL yet on that machine
<jelmer> lifeless: ah
<lifeless> my desktop went bang
<lifeless> I have a new i7 920 :)
<jelmer> lifeless: also, any chance you can use 0.0.1~bzr65 for the upstream version? That way bzr-builddeb can Do The Right thing at some point
<jelmer> lifeless: what's an i7 ?
<lifeless> 4-core, 8 hyperthreadedvcpu's goodness
<jelmer> lifeless: nice
<lifeless> intels current gamer/workstation cpu
<lifeless> jelmer: I used - deliberately
<jelmer> lifeless: why the - ?
<lifeless> jelmer: its an upstream release
<lifeless> not on the path to 0.0.1, after 0.0.1
<lifeless> we could use 0.0.2~bzr65 if we wanted
<jelmer> lifeless: so it's actually 0.0.1 ? or just a snapshot after 0.0.1 ?
<lifeless> the latter
<jelmer> lifeless: what about 0.0.1+bzr65 ?
<jelmer> I guess we could also get bzr-builddeb to support something like 0.0.1-bzr65 though
<lifeless> bzr-builddeb should support it
<lifeless> in terms of parsing etc, its legit
<jelmer> lifeless: it might be confusing for native packages though
<lifeless> no, if foo-x-y, -y is debian revision, -x is part of upstream version
<lifeless> jkakar: overview is 'used autoconf to get a soname, and after that its stock debhelper magic mostly'
<lifeless> jkakar: the thing that you could do that would be nice is get it working with autoppa for future release builds
<jelmer> lifeless: what I mean is that it makes parsing the version string harder for bzr-builddeb
<lifeless> jelmer: it should be getting parsed by python-dpkg anyhow ;)
<lifeless> jelmer: which DTRT
<lifeless> if it does make it harder, well I'm not married to this
<james_w> python-apt, but yeah
<lifeless> hi :)
<lifeless> james_w: I went with -f on autoreconf
<james_w> it should work with two -, but is currently broken, fixed in the 2.1 branch
<lifeless> datestamps and patches, eww.
<james_w> lifeless: cool
<james_w> plus, it doesn't care if you create a native package with - in it
<jkakar> lifeless: Cool, that shouldn't be hard.
<james_w> hi jkakar
<jkakar> Heya james_w! :)
<james_w> jkakar: did you know that launchpad will soon support uploads with a target of "hardy intrepid jaunty"?
<lifeless> jkakar: I'd like to keep two packaging branches. One 'official' this-is-packaged-for-$distro [debian with flow-down to ubuntu for now], and one 'upstream' this-is-ppa-magic.
<lifeless> jkakar: the ppa one should descend from the official one
<jkakar> lifeless: Cool, that makes sense.
<lifeless> james_w: awesome
<jkakar> james_w: I didn't, no.  That sounds pretty awesome.
<james_w> yeah, it removes the simple case that autoppa solves
<james_w> then you should just write your package so the same source works on multiple distributions :-)
<jelmer> james_w: that's awesome
<jkakar> james_w: Well, sort of.  That's only half of the case AutoPPA solves--the other half is providing some simple templating so that slightly different control files and such can be used for each build.
<james_w> also, you two may be interested in https://launchpad.net/bzr-builder that I wrote
<james_w> jkakar: yeah, but that's rarely required, though can often be nice to have
<jkakar> james_w: Really?  I probably just don't know enough about packaging, but that seems to be required for every single project I've packaged (which is like 4 things).
<lifeless> james_w: you've reinvented config-manager ;)
<jkakar> james_w: For example, on dapper my Python libraries need to Build-Depends on python-support, whereas on newer releases they need to Build-Depends on python-central.
<jkakar> james_w: The same kind of problem crops up when you need to depend on version 1.1 of libfoo on dapper and 1.2 on hardy.
<james_w> lifeless: yeah
<jkakar> james_w: Anyway, I really hope it is rarely needed... it'd be great for AutoPPA to be killable.
<james_w> jkakar: yeah, Build-Depends is the main case. Depends you can do from within the package
<james_w> python-central isn't something you can do with an "|" though, unless you are really sneaky
<Peng_> Would it make sense for the SMP test stuff to use the multiprocessing module? Nose does, Or So I Heard.
<james_w> Build-Depends: package-that-only-exists-in-dapper | python-central
<lifeless> Peng_: no
<lifeless> Peng_: we want full isolation ;)
<james_w> so http://bazaar.launchpad.net/~dailydebs-team/bzr-builder/cookbook/annotate/head%3A/bzr/jaunty.recipe is what controls what is uploaded to the jaunty nightly PPA now
<james_w> lifeless: the plan is apparently to integrate this with launchpad
<lifeless> back in a bit
<jelmer> james_w: what's advantage of bzr-builder and nested trees (when they land..)
<jelmer> james_w: ?
<Peng_> lifeless: I don't know what that means, but okay. :D
 * Peng_ doesn't know a thing about multiprocessing.
<james_w> jelmer: I don't know how it will work with nested trees, it will probably do a join there I guess
<james_w> jelmer: I just throw away the created tree at the moment, so I don't really care
<james_w> it does mean that it can't use bzr-builddeb currently, which nested trees would allow us to do
<james_w> lifeless: oh, I also tested a larger package earlier. A chunk of nautilus was 2 minutes to branch, 30 seconds to apt-get
<lifeless> james_w: not a great ratio
<lifeless> james_w: but better than the past
#bzr 2009-05-09
<[tpd]> Question : Can bzr-upload be visible in the windows right click menu?
<lifeless> so jelmer, upload to debian? kgo
<lifeless> [tpd]: I'm not sure, it could be added I imagine - you might like to file a bug asking for that.
<james_w> lifeless: indeed
<[tpd]> ok lifeless, just wanted to ask as it's not a core feature
<[tpd]> So I'm not sure if it'll be added
<lifeless> james_w: lets get a breakdown of the time-spent
<lifeless> james_w: Ideally with one for apt-get source too
<lifeless> james_w: turn that into a bug on bzr :)
<james_w> you mean -Dhpss trace and some hacking to get a breakdown of downloading vs. unpacking for apt-get source
<james_w> "bzr branch not as fast as apt-get source"?
<lifeless> I think as s title thats a bit inflammatory ;) but yes
<lifeless> also perhaps strace
<lifeless> as things may happen outside of hpss - like the lp branch resolution lookup
<[tpd]> One more question, is bzr-upload supposed to work on windows?
<james_w> sure, I'll work on that
<lifeless> [tpd]: I think so
<james_w> I was very pleased to see the times comparable for small branches though, that's great
<[tpd]> I'm having some trouble, see here : http://www.imgdash.com/uploads/b0d0d_Capture.png
<lifeless> beuno: ^ your public awaits
 * beuno looks
<beuno> lifeless, that looks like bzr-svn breaking?
 * beuno passes the ball to jelmer
<james_w> I saw a bug like that the other day I think
<james_w> I think it's fixed in a bzr-svn branch
<beuno> [tpd], try disabling the bzr-svn plugin and trying again
<james_w> bzr --no-plugins upload
<lifeless> james_w: that will disable upload too :P
<james_w> oh
 * james_w gives up suggestions
<vxnick> moving bzr-svn out of the plugins dir will work won't it?
<james_w> yeah
<[tpd]> gimme a sec
<[tpd]> That worked great, cheers
<ub3rst4r> does anyone know how to link a revision to a newly created release series?
<ub3rst4r> in launchpad
<bob2> if no one here pipes up, try #launchpad
<lifeless> ub3rst4r: you link branches not revisions, to series
<ub3rst4r> so i would have to create seperate branches then
<lifeless> ub3rst4r: for what
<ub3rst4r> for old releases
<lifeless> ub3rst4r: you haven't said what you are trying to do
<lifeless> ah, releases, not series. Different things ; )
<lifeless> let me have a look-see
<ub3rst4r> cus i release my source code to sf
<ub3rst4r> theres no reason to have a different branch for every new version that comes out
<lifeless> releases are tar files in launchpad
<ub3rst4r> https://launchpad.net/lilregcleaner
<lifeless> I don't think they have a revision field
<lifeless> I've checked; at the moment you can't specify a revision in a release
<lifeless> I'm filing a bug
<ub3rst4r> a bug?
<ub3rst4r> ok
<lifeless> a bug about this
<lifeless> its a reasonable thing to want to do, and you can't do it
<ub3rst4r> k
<ub3rst4r> thanks
<lifeless> jelmer_: r543 of https://check.svn.sourceforge.net/svnroot/check/trunk may interest you
<jelmer_> lifeless: Nice, congrats on finally landing it!
<lifeless> thanks
<lifeless> jelmer_: anything you want done in check, I can now commit
<lifeless> long as it passes review yada yada yada
<lifeless> jelmer_: final packaging update for a while, dev depends on lib now
<lifeless> jelmer_: also, please upload to debian :)
<jelmer_> lifeless: did you see my merge request for your packaging branch?
<lifeless> no
<lifeless> let me see
<jelmer_> hmm, the web ui doesn't list it
<jelmer_> lifeless: is launchpad supposed to accept merge requests for packaging branches yet?
<lifeless> jelmer_: new feature, not released.
<lifeless> its not supposed to ignore them
<lifeless> but that doesn't mean it will honour them :)
<lifeless> I can't see mail
<lifeless> looking on web
<jelmer_> lifeless:
<jelmer_> lp:~jelmer/subunit/releases-revno
<jelmer_> hmm, something is seriously wrong here: ganieda:~/git% bzr.foreign tags
<jelmer_> bzr: ERROR: Cycle in graph [...]
<lifeless> *blink*
<lifeless> jelmer_: sure, land that in the releases tree; please also adjust it though to use a new dch entry and don't alter the successfully built-and-installed versions in changelog
<jelmer_> lifeless: ah, right
<jelmer_> lifeless: this has landed in karmic yet or just ppa for now?
<lifeless> just ppa
<lifeless> but its trivial to do right
<lifeless> it will get into karmic from debian
<jelmer_> lifeless: Any particular reason for the python2.6 dependency, or just that that's the default in jaunty?
<lifeless> current default version
<lifeless> as per the python policy
<lifeless> [debian python policy at that :P]
<jelmer_> hmm? sid still has 2.5 as default
<lifeless> not the version, the explictness
<lifeless> oh bugger, -dev now uinstallable
<lifeless> remind me why I write libraries
<lifeless> jelmer_: merge proposals web ui rejects the path for the packaging branch
<lifeless> so yeah, its a fail
<lifeless> filing a bug
<lifeless> jelmer_: so arguably lp:~jelmer/subunit/releases-revno should be lp:~jelmer/ubuntu/jaunty/subunit/releases-revno
<lifeless> jelmer_: as its not something to merge to upstream. But nevertheless ;)
<jelmer_> I need to fix my personal bzr plugin to deal with them properly
<lifeless> I've filed a bug on lp-code
<jelmer_> thanks
<lifeless> its probably something relatively simple
<lifeless> bug 373952
<ubottu> Launchpad bug 373952 in launchpad-code "merge proposal for a regular branch doesn't permit selecting a packing branch" [Undecided,New] https://launchpad.net/bugs/373952
<madin60> hello
<madin60> I want to use tu bzr-git plugin
<madin60> but I don't understand how can I install Dulwich
<madin60> module
<xlax> Pff weird. I managed to "push" a repo to my ftp server, but there's no files there... Is that normal? :P (I only see .bzr)
<bob2> yes
<xlax> :o
<xlax> And I was trying to fix that... -.-"
<xlax> Thx
<bob2> if you want it to create a checkout, too, there's a update-after-push plugin
<bob2> but I don't think it works over ftp
<xlax> But is it required if I just want that to be a backup.
<bob2> no
<bob2> all the revision data is in .bzr, there's just no checkout
<bob2> (you can test - cd /tmp ; bzr branch ftp://.../)
<xlax> I was just about to try that :P
<xlax> Lookin' slick :P
<xlax> Thanks.
<balachmar> Hi, what is the easiest way to make a bzr branch available to other users. Without giving them further access to the system? I want the users to be able to read/write to the bzr branches but they should not be able to look at the rest of the system.
<SamB> balachmar: publish via HTTP or push to launchpad
<SamB> oh, read/write
<SamB> that's trickier
<SamB> well ... you could publish to launchpad and add them to a team which has read/write access ...
<james_w> forced command ssh will get you part way there
<balachmar> SamB: Well, the code will be of a website and I am not quite sure if I want to share that with everyone. So I guess launchpad is a nogo.
<SamB> balachmar: hmm.
<balachmar> james_w: forced command ssh?
<SamB> balachmar: and why don't you want to let them have full SSH access to the machine ???
<james_w> you give them ssh access, but only to run a single command
<SamB> it might be useful if they have code to test, anyway ...
<balachmar> SamB: Well, there is other stuff on the same server, which they don't need access to.
<balachmar> Samb: They can log into the server, but just only look at stuff in their home.
<SamB> balachmar: and unix groups aren't enough for that?
<SamB> I think you should just allow them read/write access to the bzr repository for the website, and either set up a plugin to update the website when they push to the repository, or set up automatic pull
<balachmar> I fear I might need to read up on that. I am not a sysadmin or anything. Basically just an Ubuntu user. And I have some knowledge, but not really on the administrative side of things.
<SamB> balachmar: create a unix group, set the repository directory (and contents) to be owned by www.thegroup, and set the permissions to allow writing by the group ...
<balachmar> SamB: But then they would still be able to read contents of the other directories. In a normal ubuntu installation.
<balachmar> maybe just giving the user rbash will be enough. I don't expect them to try hacking the server.
<balachmar> but ok, that is another issue. So sftp it is... :) Now just figuring out how to get it working :)
<pygi> SamB: can I suggest something?
<pygi> ups
<pygi> that was for balachmar :)
<balachmar> of course you may suggest something :)
<balachmar> I think I will use rssh
<cornucopic> vila, ping. I have filed the bug report for the second issue. Please check: https://bugs.launchpad.net/bzr/+bug/374139
<ubottu> Ubuntu bug 374139 in bzr "'authentication.conf' accepts a server name of the form 'server:port'" [Undecided,New]
<pygi> balachmar: nah
<pygi> ClueBzr-server
<pygi> you need to highlight me :P
<pygi> balachmar: rather simple thing, writing/reading over bzr+http, no ssh access
<balachmar> pygi: Will do :P
<jelmer_> pygi: what's up with ClueBzr-server these days?
<cornucopic> vila, with reference to your https://bugs.launchpad.net/bzr/+bug/372800/comments/1, the SMTP server is running on a default port. Is your reasoning still valid?
<ubottu> Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication during post commit email" [Undecided,In progress]
<pygi> jelmer_: what do you mean?
<balachmar> pygi: Got it set up already using rssh works perfectly as well
<pygi> balachmar: oh well, oki :p
<balachmar> pygi: but thansk anyway!
<balachmar> thanks
<pygi> jelmer: its in ok state, but it could be way better
<pygi> I've hacked up some improvements to it, but I'd like the design improved in certain places
<pygi> tho rocky is the chief, I'm just a random user :)
<jelmer_> ah :-) what's the homepage?
<cornucopic> vila, according to the manual, 'port' should be used only when "the server uses a port different than the scheme standard port,"
<pygi> jelmer_: http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer
<pygi> jelmer_: I have no idea if he'll be at UDS so we could discuss the changes, but I don't think he'd mind patches :p
<jelmer_> pygi: are you going to be at UDS?
<pygi> jelmer_: yes
<jelmer_> cool, me too
<pygi> hehe, fantastic!
<pygi> first time that I am actually attending xD
<jelmer_> it's somewhat the first time for me, I attended one afternoon/evening of UDU
<cornucopic> !seen vila
<ubottu> I have no seen command
<jelmer_> cornucopic: probably enjoying his well-earned weekend
<cornucopic> jelmer, okay :) No problem! thanks!
<cornucopic> all: Does the 'smtp_server' given in bazaar.conf 'percolate' down to 'host' in 'authentication.conf' ?
<Noya> hello everyone
<Noya> I seem not to be able to get bzr-email to run
<Noya> if anyone has bzr-email running: in what config file do I have to add the post_commit_to = a@b.c ?
<Noya> I tried .bazaar/bazaar.conf
<Noya> and BRANCH/.bzr/branch/branch.conf
<cornucopic> Noya, .bazaar/bazaar.conf does it for me
<cornucopic> Noya, I am using smtplib
<Noya> cornucopic: so you added it on the server side and everytime you push it'll send a email, right?
<cornucopic> cornucopic, Okay. I am sorry. You are refering to the post_commit email recipient? That would be the later option
<cornucopic> Noya, ^^
<Noya> cornucopic: what do you mean by "later option"? ;)
<cornucopic> Noya, in branch.conf.
<Noya> okay
<Noya> let me describe the setup that I have in my mind, just to be sure we talk about the same ;)
<Noya> I have a server (foobar.org) and am working at home (home)
<Noya> there is a user on my server called "bzr" and at home I am "noya"
<Noya> noya@home$ bzr push bzr+ssh://foobar.org/somebranch
<Noya> I want my foobar.org to send a mail to a mailinglist
<Noya> when I push like described above :)
<Noya> cornucopic: so I thought I would have to edit /home/bzr/.bazaar/bazaar.conf on foobar.org and put all the email-configuration in there
<cornucopic> Noya, I have set up my commit emails properly, but I haven't tried push yet. And for my commit emails, I have set it up in 'branch.conf'. So, I am not going to be able to help in your scenario :)
<cornucopic> Noya, In a week's time, may be, but that would probably be of no use to you :
<Noya> cornucopic: ;)
<Noya> cornucopic: thanks anyway :)
<cornucopic> Noya, :)
<asabil> Noya: hey dude
<Noya> asabil: hey there ;)
<asabil> Noya: you can check this plugin: https://code.launchpad.net/~johncarr/+junk/bzr-watcher
<asabil> I never used it, but it sort of does what you want I think
<asabil> there is also the bzr-email plugin iirc
<Noya> asabil: right now I am trying to setup the bzr-email plugin
<Noya> but I fail terribly ;)
<asabil> let me check it out
<asabil> Noya: are you using bzr+ssh when pushing ?
<asabil> or bzr:// ?
<Noya> asabil: yes
<Noya> asabil: bzr+ssh
<asabil> oki
<Noya> tro:
<Noya> whoops, sorry
<asabil> Noya: do you have any specific error ?
<Noya> asabil: sorry no, just nothing happens
<Noya> the same as I wouldn't have installed the plugin
<asabil> Noya: I don't think it is a plugin
<asabil> but actually a separate program that you need to run
<Noya> asabil: bzr-email is installed in bzrlib/plugins
<Noya> and the doc says it is a simple post_commit_hook that gets called
<asabil> Noya: ah we are not talking about the same one it seems
<asabil> there is bzr-email-notifier
<Noya> asabil: oh right
<Noya> asabil: that doesn't look too bad
<asabil> I think it is better to have the email notification stuff out of the bzr serve process
<asabil> so I would go for the bzr-email-notifier solution instead
<Noya> asabil: in the readme it says it is intended to be used on a server unlike the bzr-email plugin
<Noya> asabil: nice :)
<asabil> Noya: otherwise, I think you need to have post_commit_push_pull = True
<asabil> in your bazaar.conf for bzr-email
<Noya> asabil: did that, but didn't work either
<Noya> asabil: I guess you are right and I'll take the bzr-email-notifier tool :)
<asabil> ok, good luck with that
<LarstiQ> Noya: also, you need to have the branch you're pushing to configured to email
 * LarstiQ scrolls up a bit
<LarstiQ> Noya: I'd pick locations.conf or .bzr/branch/branch.conf
<LarstiQ> Noya: if locations.conf, and on the server as the user you're pushing at, over a smart protocol (so far so good), the branch location should be that as what you access it with remotely
<LarstiQ> Noya: ie, it should be [bzr+ssh://server/srv/bzr/branch] and not [/srv/bzr/branch]
<Noya> LarstiQ: so does every user have to configure it locally?
<Noya> + on the server
<Noya> or should it work if the branch on the server is configured?
<Noya> only the branch on the server
<LarstiQ> Noya: this is with bzr-email. If you use bzr-watcher/bzr-hookless-email/bzr-email-notifier, then it doesn't run from the bzr push, so users don't need to confiure
<LarstiQ> Noya: but if you're using bzr-email, either all the ~user/.bazaar/locations.conf need to be configured so, or all the branch.conf's need to be.
<LarstiQ> Noya: do note that you can get cascading with locations.conf, so if all the branches below a certain directory have the same configuration, you can just use [bzr+ssh://server/certain/directory]
<LarstiQ> if you're not using bzr-email, then all this is moot :)
<asabil> jelmer: ping ?
<Noya> LarstiQ: thanks for the info
<Noya> as I don't want the users to configure anything I'll stick with bzr-email-notifier
<Noya> let's see how this works out :)
 * LarstiQ nods
<Noya> okay people, thank you for your help
<Noya> you've been very kind :)
<Noya> gotta hop now
<Noya> see you
<[-TPD-]> I've just installed bazaar on ubuntu 9.04, where are the plugins stored when installing via aptitude?
<jelmer_> [-TPD-]: see the output of `dpkg -L <name>`
<[-TPD-]> I've got this result, but I'm not sure it's correct
<[-TPD-]> ok
<jelmer_> [-TPD-]: or `bzr plugins -v`
<[-TPD-]> ah, cheers
<[-TPD-]> One more question, does bzr-upload integrate with eclipse?
<LarstiQ> [-TPD-]: not by itself, no clue if the eclipse plugins do something with it.
<[-TPD-]> hmm, because the bazaar extension has plugins path, so it must be doing something
<[-TPD-]> I'm having a problem with upload when using the eclipse plugin
<[-TPD-]> Seems to be caused when using the --auto switch
<[-TPD-]> on commit via eclipse I get the following error.
<[-TPD-]> 'cStringIO.StringO' object has no attribute 'encoding'
<[-TPD-]> 'cStringIO.StringO' object has no attribute 'encoding'
 * LarstiQ would need to see a (pastebinned) traceback to know more
<[-TPD-]> How would I do that? I will happy to provide
<LarstiQ> [-TPD-]: if it doesn't show you a traceback, you can get it from ~/.bzr.log. http://rafb.net/paste/ or any other for the binning
<[-TPD-]> LarstiQ, http://bzr.pastebin.com/m40ebebd5
<AmanicA> [-TPD-]: normally with bzr-eclipse I check if I have the latest updates and also the latest xmloutput plugin
<[-TPD-]> I already updated xmlout, 0.8.3 was the latest
<madin60> bonjour, je cherche de l'aide pour installer le plugin bzr-git
<LarstiQ> hmm, [-TPD-]'s .bzr.log did not include a backtraxe
<[tpd]> back
<LarstiQ> [tpd]: your .bzr.log doesn't seem to include a traceback, weirdly enough
<LarstiQ> [tpd]: different user maybe?
<[tpd]> No idea, I've given up for now, waste too much time on it
<LarstiQ> ok
<[tpd]> No, don't think so LarstiQ
 * LarstiQ goes to bed then
<LarstiQ> madin60: if you ask your question, someone might know the answer
<LarstiQ> night
<[tpd]> night
<madin60> Sorry
<madin60> I can i install the dulwich module? It's in order to use the bzr-git plugin
<madin60> How can I install...
<jfroy> jelmer: hit that missing revision bug again on another branch
<jfroy> :)
<jfroy> * :(
<jfroy> Same project, they're all branches derived from the same trunk branch.
<jfroy> mmm, interesting!
<jfroy> I just solved it by packing the shared repository storing the branches.
<jfroy> I think I upgrade that repository or branch from 1.9 to 1.14
<jfroy> Seems like you *must* pack after doing that or you'll run into problems. This suggests upgrade should automatically run a pack after it completes...
<Peng_> 1.14 is exactly the same repository and branch format as 1.9.
<jfroy> Peng_: might have been some other format then....
#bzr 2009-05-10
<lifeless> jfroy: pack doesn't alter what data is visible or how its indexed
<lifeless> jfroy: all it does is shuffle it around on disk so that fewer I/O operations are needed to get at related data
<jfroy> well it definitely fixed my problem
<jfroy> I was able to pull the remote svn branch after packing my local repository
<jfroy> whereas before the pack it would die on a missing revision exception.
<lifeless> how confident are you that no other operations were done in between the failure and the pack
<lifeless> include updates to svn/bzr-svn/bzr
<lifeless> if pack does fixit there is a critical bug in bzr's repository code
<SamB> lifeless: and not bzr-svn's ?
<lifeless> SamB: bzr-svn implementation a repository proxy around libsvn
<lifeless> SamB: it doesn't, as far as I know, rummage around through bzr's repository implementation internals
<SamB> true
<SamB> it doesn't mess with access to a native repository ...
<lifeless> so if packaging a repository you're pulling into stops a bzr-svn bug happening, packing has changed the behaviour of [some] public interface || bzr-svn is poking under the hood badly
<lifeless> I think the latter is unlikely and that leaves the former, assuming that jfroy has gathered the evidence accurately
<lifeless> jfroy: next time this happens, can you take a backup of your bzr repo and your ~/.bazaar/bzr-svn cache die
<lifeless> *dir*
<lifeless> jfroy: then, try the pull again, if it fails again, pack and pull
<lifeless> if that works, backup your backups and then put them back in place
<lifeless> jfroy: and try the pull again, if it fails once more, we'll have a reproducable dataset to work with
<lifeless> if the repo is private we'll write code for you to test
<lifeless> if its not private you can schlep it to us
<SamB> is schlepnet fast?
<lifeless> it can be
<jfroy> lifeless: will do
<lifeless> thanks
<Peng_> Is there an equivalent to "bzr revno" that shows the revid?
<jelmer_> jfroy: hi
<Peng_> Well, bzr lookup-revision $(bzr revno)
<jelmer_> yeah, bzr only uses public interfaces
<jelmer_> jfroy: which bug was it exactly that seemed to be fixed by a 'bzr pack' ?
<jfroy> jelmer_: hey
<jfroy> Sorry just checked IRC
<jfroy> jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/364416
<ubottu> Ubuntu bug 364416 in bzr-svn "bzr branch fails with "ERROR: The branch <url> has no revision. None" with bzr foreign + bzr-svn 0.6d" [Low,Triaged]
<lifeless> Peng_: bzr revision-info
<Peng_> lifeless: Oh, nice.
<jelmer_> jfroy: any chance you can comment on what seems to fix it in the bug report?
<jfroy> sure
<jfroy> but I don't know much
<jfroy> I simply packed to "try see if it does anything", and it unexpectedly did.
<jfroy> I didn't make a backup of the repository before packing, unfortunately.
<jfroy> although...
<jfroy> we may be in luck, actually.
<jfroy> I backup my documents automatically
<jfroy> I most likely can revert the repository to its state prior to packing
<jfroy> and try the sequence all over again
<jelmer_> jfroy: which repository format are you using?
<jfroy> 1.14
<jfroy> (-rich-root of course)
<lifeless> jfroy: really? bzr info and paste the format details please
<jfroy> lifeless: 1.14-rich-root or 1.9-rich-root
<lifeless> ah actually nvm
<lifeless> its 1.9 repo
<jfroy> anyways, restoring from backup and trying again
<lifeless> a new tree format is in 1.14 is all, it supports filters [yay]
<jfroy> see if I can reproduce
<jfroy> ahhh, backups :)
<jfroy> Is there any flags I can use to spit out more info in the bzr.log?
<jfroy> the repo is confidential, I won't be able to share it
<lifeless> jfroy: for this operation, nothing offhand
<jfroy> Although I can certainly paste logs and what not
<lifeless> we may write some custom patches to debug
<jfroy> jelmer_: I'll be using your bzr foreign branch and bzr-svn for this
<jfroy> it's what I usually use
<jfroy> eh this time it's still dying after the pack
<jfroy> this is very odd
<jfroy> mmmm
<jfroy> interesting
<jfroy> so after the pack, I still got the missing revision exception
<jfroy> I then pulled the trunk branch (which was already in the repository)
<jfroy> repacked
<jelmer_> jfroy: at this point my bzr-foreign branch is basically bzr.dev with bzr+http removed
<jfroy> and the the branch command worked
<jfroy> so it may be the trunk pull that fixed it, not the pack
<jfroy> let me try this again starting at the beginning...
<jelmer_> k
<jfroy> jelmer_: I think it does a few more things, no?
<jelmer_> jfroy: no, the other things have been merged now
<jfroy> push working to create new branches and printing the svn revno when pulling
<jfroy> I see
<jfroy> gotcha
<jfroy> good to know
<jelmer_> jfroy: it used to be more
<jfroy> yeah
<jfroy> was the fallback credential store stuff merged in too?
<jfroy> I adopted the protocol in my keychain store and it's working great
<lifeless> jfroy: the trunk pull is likely it
<jfroy> It makes a lot more sense, yes
<lifeless> yes, yes it does :)
<jfroy> pack should not fundamentally change the content of the history
<lifeless> right
<jfroy> it just makes it tidier
<jfroy> confirmed
<jfroy> the trunk pull fixes the branch command
<jfroy> I also confirmed I cannot pull the branch in a new repository without having trunk in it
<jfroy> if trunk is not there, it always dies with a no such revision exception
<jfroy> so it's unlikely that the svn cache is involved here either
<lifeless> jfroy: are you pulling from svn
<lifeless> or from bzr
<lifeless> there is a bugfix in bzr (server side) for 'NoSuchRevision' pulling from a stacked branch
<jfroy> pulling from svn
<jfroy> in all cases
<jfroy> jelmer_: confirmed, I just made a brand new repository
<jfroy> tried to pull the svn branch in it, died with the usual error
<jfroy> I then pulled the svn trunk in that repository and then pulled the svn branch again
<jfroy> and that worked
<jfroy> so it seems bzr-svn is failing to pull certain revisions it needs
<jfroy> I've updated the bug with that finding.
<jelmer_> thanks
<jfroy> if you need revprop / file props to debug this when you get around to it, let me know
<jelmer_> will do, thanks
<jelmer_> lifeless: btw, did I mention dpush to remote git branches works now?
<jelmer_> the only thing remaining now is 'proper' push
<lifeless> ye
<jelmer_> it would be nice if somebody could fix up hg support at some point
<jelmer_> I think the API changed or something but it can't do much else than view revision history atm
<pzico> hola, I have a stupid question that I couldn't figure out from "Bazaar in 5 minutes".. If I want to force checkout the latest revision of file abc.py in current folder, what is the command?
<bob2> if you want the one corresponding to the currently checkout'd revision, bzr revert abc.py
<bob2> (ie it will undo all uncommited local changes)
<LarstiQ> pzico: Bazaar considers the entire tree 1 object. If you are using a checkout `bzr update` will make it up to date with the master location. If you're using a branch, `bzr pull` will pull in all the new revisions from your parent location.
<LarstiQ> pzico: or possibly what bob2 said, from your wording it isn't clear to me what effect you're looking for
<pzico> Well, I haven't yet learned to think "bazaar" way. So I just made simple project and used bzr init, add and commits.. now I just want to revert back to previous committed version..
<pzico> and only for one of the files I have edited
<LarstiQ> pzico: ah ok, if the most recent commit is the one you want to go back to `bzr revert abc.py`
<pzico> It seems that the revert command did the job. Thanks.
<LarstiQ> pzico: or if you would like to bring it to an arbitrary revision, `bzr revert -r 123 abc.py`
<LarstiQ> cool
<awilcox> Does anybody know of an Xcode plugin for Bazaar?
<ronny> hmm
<ronny> anyone aware of an api that kind of combiness Workingtrees iter_changes and list_files ?
<ronny> i need renames and unknown files at once if possible
<luks> ronny: TreeDelta?
<luks> of working tree against the basis tree
<ronny> currently im using wt.iter_changes(wt.basis_tree())
<james_w> ronny: can't you ask for unknown in iter_changes?
<james_w> want_unversioned=True
<ronny> ah,
<ronny> hmm
<ronny> i have that, yet its still somehow missing something
 * ronny rechecks his test helpers
<ronny> hmm, i have include_unchanged and want_unversioned
<ronny> do i have to invalidate a workingtree after a commit?
<lifeless> ronny: how do you mean
<ronny> hmm, i think im confusing something about the api here
<ronny> ok, i think i found my error
<ronny> lifeless: i didnt notice i had a broken test
<vxnick> hi guys - a question: is there much difference between push/pull and commit/checkout when working on a remote repo with others?
<ronny> oh darn
<LeoNerd> vxnick: Not really.. they're basically the same... A "bound" branch is just one that pushes after it commits. etc...
<vxnick> LeoNerd: thanks, I thought it might've been something like that
<vxnick> guys - I think I'm going crazy here. I've created a shared repo and a trunk on a remote server, but can't checkout locally - I get the "bzr error not a branch" error
<jelmer_> vxnick: are you checking out the branch location?
<jelmer_> I mean, the location of trunk
<vxnick> jelmer: I am indeed
<vxnick> jelmer: I 'bzr init-repo project_name' and then 'bzr init trunk" within  that dir
<jelmer_> vxnick: so the url ends in /trunk?
<vxnick> jelmer: that's right
<jelmer_> does bzr info work on the URL?
<vxnick> nope
<vxnick> not a branch
<vxnick> oh dear
<vxnick> the path was wrong
<vxnick> *embarrassed*
<vxnick> thanks for your help
<jelmer_> np
<vxnick> bzr-upload stores the remote location by default, but is there a way that I can switch between locations, perhaps by using some form of alias? I think I might have read about this somewhere but can't find anyhting
<jkakar> Sometimes I wonder if 'bzr update' should automatically fall back to 'bzr pull' when the branch isn't bound.
<cdecarlo> hi, I'm new to bzr and distributed vcs all together, I've created my first bzr repo with a friend an we are using the decentralized workflow, we wanted to use PQM as our gate keeper but I'm having trouble even getting started, is there a good how to available, I can't find one
<james_w> vxnick: have a look at bzr-bookmarks, it allows you to refer to different locations by short names
<vxnick> james_w: thanks
<james_w> cdecarlo: I don't know of one I'm afraid
<Laney> is --fixes lp:xxx just supposed to link the branch?
<james_w> that's all it does currently
<james_w> there are plans to be a bit more useful I believe
<Laney> ok, I thought it would set fix committed too
 * Laney does so
<ronny> jelmer: ping?
<dirkD> is it possible to manage permissions/access rights with a bazaar smart server?
<LarstiQ> dirkD: yes
<dirkD> LarstiQ: :O
<dirkD> how?
<dirkD> just with unix permissions?
<dirkD> (i can't find it in the user guide)
<luks> LarstiQ: I'd say "yes" is a kind of cheating, until the smart server still has VFS calls
<dirkD> luks: i'm using bzr 1.14
<dirkD> so... RPC calls?
<luks> dirkD: you can ignore me, that was purely technical :)
<luks> what kind of access rights do you want to setup?
<dirkD> i want to give some users access to a branch, and some users not
<dirkD> or groups...
<luks> the easiest way is probably to use contrib/bzr_access
<luks> assuming you want to use bzr+ssh
<dirkD> indeed
<dirkD> is there any documentation on bzr_access?
<dirkD> (it's a plugin i assume? or a patch?)
<luks> there are some examples in the file itself
<luks> you basically give users ssh access and restrict the commands they can execute
<dirkD> ah
<luks> it's in the source code tarball
<dirkD> luks: looks fine :)
<dirkD> but they're talking about .ssh/authorized_key
<dirkD> is that about ~/.ssh
<dirkD> + ?
<dirkD> so i do have to edit authorized_keys for every user?
<dirkD> (or create a symlink to a system-wide one of course
<dirkD> + )
<luks> sorry, I don't know more about that
<luks> maybe there is a global way, I don't know
<dirkD> ok, thanks for your help
<bluszcz> hello, how can i create plugin on the bzr server?
<bluszcz> i've got bzr+ssh server - on the client side pre_commit works as expected, but i cannot make it run on server on (bzr co, bzr up, bzr ci -m "" flow)
<bluszcz> is this possible?
<CardinalFang> bluszcz: Plugins don't do that.  Consider the SFTP transport -- it *couldn't*.
<luks> I think there is a post push hook
<luks> hm, no, that's not the one
<CardinalFang> On the client, maybe.
<LarstiQ> luks: I see what you mean, and what I was thinking of is also not directly helpful (Launchpad/ClueBzr style smartserver)
<bluszcz> hmmmm...
<LarstiQ> luks: post_branch_tip_change or something like that
<luks> yeah, that one
<bluszcz> CardinalFang: plugin's don't do what? sorry, but i didn't understand
<LarstiQ> bluszcz: `bzr help hooks` should mention which ones get run on the server
<bluszcz> ok
<luks> strange, I can see post_tip_change mentioned in tests, but not the code
<bluszcz> i was reading BranchHook.__init__ ;)
<LarstiQ> let me fish up how I run bzr-email on the server
<bluszcz> ok, i read help hooks but still have no idea how to install server side hook
<LarstiQ> bluszcz: in all ~user/.bazaar/locations.conf I have: [chroot-*:///srv/bzr/]\npost_commit_push_pull = True\npost_commit_url = bzr+ssh://server/srv/bzr\npost_commit_url:policy = appendpath\npost_commit_to = commits@
<LarstiQ> etc
<LarstiQ> bluszcz: the plugin you execute must be loaded by the bzr your users execute
<LarstiQ> (on the server)
<LarstiQ> bluszcz: other than that, that should be it
<bluszcz> reading
<bluszcz> hm, bit complicated
<LarstiQ> true.
<LarstiQ> some of that is due to how bzr-email works
<LarstiQ> bluszcz: if you write your own plugin, the key thing is to make sure your plugin code gets loaded, and that you configure for the right branch
<LarstiQ> if you do it for all branches, that last bit doesn't matter.
<bluszcz> hm
<bluszcz> my configuration is:
<bluszcz> i've got ssh acount on my server
<bluszcz> my user
<bluszcz> ;)
<bluszcz> there are branches
<bluszcz> which are checkout locally and using it as i write above (locally make commit for remote branches)
<bluszcz> generally at this time, i am not interested in any wide system/multi user solution, only "wide" in my needs is that i want to run some plugins on the server during commiting to that branches, all branches.
<bluszcz> (reading http://bazaar-vcs.org/ConfiguringBz)
<bluszcz> i found also this:
<bluszcz> https://lists.canonical.com/archives/bazaar/2008q3/044390.html
<bluszcz> pre_change_branch_tip (Branch)
<LarstiQ> bluszcz: does that get run on the smartserver?
<mwhudson> jelmer: so what's new and sexy about bzr-git 0.3.0 ?
<bluszcz> yeah
<lifeless> moin
<bluszcz> bzr: ERROR: Received bad protocol version marker: 'sage 3 (bzr 1.6)\n\x00\x00\x00\x1dd16:Sof'
<bluszcz> lol
<bluszcz> server: Bazaar (bzr) 1.14.1
<bluszcz> local: $ bzr version
<bluszcz> Bazaar (bzr) 1.14.1
<bluszcz> so, wtf?
<lifeless> bluszcz: its been mangled
<lifeless> bluszcz: you have something outputting to stdout while you login to your machine, if you're using bzr+ssh
<lifeless> that will also break sftp
<bluszcz> stdout from my local?
<lifeless> the server
<lifeless> what protocol are you using?
<bluszcz> yes, pluging is talking to me
<bluszcz> bzr+ssh, ssh2
<lifeless> ok, if you do "ssh host: echo"
<lifeless> do you get anything shown ?
<lifeless> sorry, get rid of the : there
<bluszcz> bluszcz@atomic [(nie maj 10) 22:39]:~/projekty/blogi
<bluszcz> $ ssh bzr-bluszcz echo
<bluszcz> bluszcz@atomic [(nie maj 10) 22:39]:~/projekty/blogi
<bluszcz> $
<bluszcz> only \n
<lifeless> ok that looks fnie
<lifeless> *fine*
<lifeless> must be something else
<bluszcz> yes, i now
<bluszcz> how can i pass -vvv for ssh in bzr+shs?
<bluszcz> ssh
<lifeless> if you have a plugin, which execs something and that writes to stdout, it can also interrupt a bzr session
<lifeless> because the bzr protocol is writing to stdout
<bluszcz> hm
<bluszcz> so, i should use stderr?
<lifeless> oh yes
<bluszcz> to write information about "your commit message is empty?"
<lifeless> in a plugin on the server?
<bluszcz> btw, lifeless  - nice nick ;)
<bluszcz> lifeless: yes, on the server
<lifeless> one sec I'm looking up a bug for you
<bluszcz> ok
<bluszcz> it looks like working now
<bluszcz> :)
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/364908
<ubottu> Ubuntu bug 364908 in bzr "server side 'progress'" [High,New]
<lifeless> thats a closely related issue
<lifeless> however, if your plugin is actually stopping the commit/push, you should probably just raise an exception -  except that won't get formatted well. hm time for another bug
<bluszcz> yea
<bluszcz> raise "You should check first you *py files, or die"
<lifeless> if this is a pre-tip-change hook
<lifeless> there is a specific exception for that you can raise
<lifeless> which I think gets formatted nicely
<lifeless> errors.TipChangeRejected
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/374605
<lifeless> just filed that for you
<ubottu> Ubuntu bug 374605 in bzr "way for plugins to present non InternalError from hpss" [High,Confirmed]
<bluszcz> :)
<bluszcz> Robert Collins 2 minutes ago Changed in bzr:
<bluszcz> importance: 	Undecided â High
<bluszcz> status: 	New â Confirmed
<bluszcz> things really goes fast
<bluszcz> ok, now i have to read how to read file liste
<bluszcz> ech, it has only:         # (params) where params is a ChangeBranchTipParams with the members # (branch, old_revno, new_revno, old_revid, new_revid)
<bluszcz> no way i suppose to check the commited files
<mwhudson> is it possible that getting a dev6 branch over http would use very large amounts of RAM?
<bluszcz> dev6?
<bluszcz> user ram on which element? client or server?
<mwhudson> bluszcz: the development6 format
<bluszcz> "uses"
<lifeless> mwhudson: if it is file a bug
<lifeless> mwhudson: it might if transcoding
<mwhudson> lifeless: ok, finding out now
<mwhudson> lifeless: it really really shouldn't be doing that
<mwhudson> but i guess i can find out
<[tpd]> Hey folks, does anyone here use bazaar for website deployment?
<mwhudson> [tpd]: some people do, and they find the bzr-upload plugin useful
<[tpd]> Ah, is that a standard way of doing it? I'm new to vcs.
<mwhudson> [tpd]: it's what the plugin is for
<[tpd]> I understand that, but is this how it "should be done"?
<mwhudson> i don't know of any better way
<bluszcz> how is the best way to gest list of modified files using bzrlib.?
<lifeless> in a commit?
<bluszcz> si
<lifeless> bzr st -c rev
<lifeless> oh, bzrlib
<bluszcz> si
<lifeless> tree1, tree2 = bzrlib.repository.revision_trees([rev1, rev2])
<lifeless> changes = tree2.iter_changes(tree1)
<bluszcz> checking, thanx
<bluszcz> no such revision_trees hm
<lifeless> sorry
<lifeless> I meant 'repository.revision_trees'
<lifeless> where repository is a bzrlib.repository.Repository object
<lifeless> if you have a branch its branch.repository
<lifeless> if y ou have a working tree its wt.branch.repository
<bluszcz> working tree is easiest i think
#bzr 2010-05-10
<GungaDin> How do I check a branch to a checkout after I've pushed it to a remote location?
<mtaylor> GungaDin: do you mean you've pushed to a remote location and now you want to get new changes that might be in that remote location?
<mtaylor> GungaDin: or are you trying to modify your local branch to be a lightweight checkout of the remote location
<mtaylor> ?
<GungaDin> I'm trying to modify my local branch to be a checkout of the remote branch
<GungaDin> which I think I've managed to do
<mtaylor> GungaDin: awesome
<lifeless> \o/
<poolie> http://summit.ubuntu.com/uds-m/2010-05-11/
<lifeless> abentley: http://www.huffingtonpost.com/2009/12/07/google-ceo-on-privacy-if_n_383105.html
<thumper> poolie: if you are fixing things, there is the config locking problem that is biting us in the code import arena
<poolie> hi there thumper
<thumper> hi poolie
<jelmer_> 'morning thumper
<thumper> hi jelmer_
<lifeless> jam: https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux/+bug/543617
<ubottu> Launchpad bug 543617 in linux "Unmount of an fs with dirty cache buffers causes pathological slowdown" [High,Fix released]
<lifeless> spiv: do we ahve something that waits for that part of the thread startup to have completed, in the 'main' thread ?
<spiv> lifeless: as best I can tell, when the bind+listen happens, there should be no threads started yet
<lifeless> spiv: theory: the thread starting the socketlistener which is itself a thread, is getting the timeslice before the new thread has started
<spiv> The bind+listen happens in SocketListener.__init__
<lifeless> yes
<lifeless> I thought that is in the child thread though
<lifeless> its a Threading.thread, right ?
<spiv> SocketListener is a threading.Thread, yes
<spiv> But it isn't started until after its __init__ returns
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila  (not)| bzr 2.1.1 is out
<thumper> how do branches with symlinks work with windows?\
<spiv> thumper: short answer is they don't
<spiv> There's a plugin, though
<thumper> spiv: which does what?
<spiv> https://edge.launchpad.net/bzr-win32symlinks
<thumper> nm
<thumper> found a different way around it
<Peng_> Good.
<thumper> I'd like simple windows support without worrying about that
<Peng_> Does bzr-win32symlinks even work? I'd heard that there were issues...
<spiv> Peng_: the description on its LP page does pointedly say it isn't maintained anymore, so maybe not
<Peng_> Whee.
<uier> hi
<uier> I need an uninstaller for Mac
<uier> the one linked on the site doesnt work with snow leopard
<uier> hrm
<uier> anyone alive?
<GaryvdM> Hi uier
<uier> GaryvdM: hi!
<GaryvdM> Not many people know much about the Mac installer.
<uier> I installed Bazaar on Snow Leopard, but need to remove the bundle and everything it ever installed
<uier> Oh no :(
<GaryvdM> The person who does know in Gordan. He is not here.
<GaryvdM> *is
<uier> GaryvdM: What is his nickname
<GaryvdM> uier: According to his lunchpad page, dOxxx
<uier> It's kinda pointless offering an installer without a set in stone method of how to get it off your computer :|
<uier> It should be bundled with an uninstaller
<lifeless> -> food
<kfogel> lifeless, jam: care to play Captain Obvious in helping me debug "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist." ?  I've done the googling and stuff, and tried writing a log.  No luck so far.  privchat if have time to chat
<beuno> kfogel, try running that with -Dhpss
<kfogel> beuno: srsly?
<kfogel> beuno: ok, thanks
<kfogel> beuno: on the server side, I assume you mean?
<beuno> kfogel, it will give you more information
<kfogel> beuno: aaaaaah
<kfogel> got it
<kfogel> -D for debug
<beuno> kfogel, clientside
<kfogel> beuno: thanks
<kfogel> beuno: Hah!  Brilliant.  It told me "HPSS calls: 1 (0 vfs) SmartSSHClientMedium(bzr+ssh://None@hostname.I'm.trying.to.reach/)", and when I saw the "None" I realized I probably needed a different username than "kfogel".  Putting one there got me to my next error, and I am on my merry way.
<beuno> kfogel, awesome
<beuno> kfogel, I have Dhpss enabled all the time
<beuno> you can be cool as well by adding it to ~/bazaar/bazaar.conf
<beuno> debug_flags = hpss
<kfogel> beuno: done, in DEFAULT section
<beuno> welcome to the club
<kfogel> beuno: my next error is http://paste.ubuntu.com/431250/, which looks eminently googleable
<beuno> wa
<beuno> that's new to me
<beuno> so
<beuno> I assume the server has an old version of bzr
<kfogel> beuno: except I just built the server myself from bzr 2.1 sources...
<beuno> kfogel, both server and client on 2.1?
<kfogel> beuno: hmmm, except locally I seem to be running 2.2dev, which I didn't realize
<kfogel> beuno: though you'd think that wouldn't be a problem
<beuno> I wouldn't
<beuno> kfogel, did the server have another version of bzr installed?
<beuno> the smart server may be invoking a different bzr on the server
<beuno> this looks like a bug for spiv though
<beuno> I would absolutely report it
<kfogel> beuno: yes, the server has a much older version of bzr installed in /usr/bin/bzr, and (in theory) that's not supposed to infect the 2.1 build that I'm using.  But it could be, somehow.
<TresEquis> kfogel: when the client sets up the session, it may not find your preferred bzr
<kfogel> TresEquis: could be.  I'm trying to puzzle out how; on this machine, there is a restricted shell that (in theory) should be fired up, and then it should exec a particular bzr that I have configured it to exec.
<kfogel> TresEquis: regarding your nick: I've often wanted to brew and sell a brand of beer called "Regal XXX Lager" (the world's first palindromic beer).
<kfogel> Not that that has anything to do with Bazaar, of course :-).
<TresEquis> Such a brew might help get coding done faster ;)
<TresEquis> Elat Ale would be shorter
<TresEquis> or Elan
<kfogel> TresEquis: nice!  I think we've got the makings of a fine brewing company here...
<jam> kfogel, beuno: known bug of bzr talking to an older server
<jam> I would check your path
<jam> and remember that it probably doesn't include any user customizations
<jam> because it is only what 'ssh' gets before launching bash
<kfogel> jam: thanks.  I think (from other debugging just now) that the bzr I want to be invoked is not the one being invoked, on the server side; checking...
<jam> kfogel: you probably only have /usr/bin and /usr/local/bin
<jam> you should be able to set
<jam> BZR_REMOTE_PATH=/the/one/I/really/want/bzr bzr FOO
<jam> and that should work
<jam> which hints you want to fix the system path, or something
<kfogel> jam: well, the "other" one is ~root/kfogel/bzr-2.1.0/bzr, but yeah
<kfogel> jam: hunh, that BZR_REMOTE_PATH is something you can set on the client side??
<jam> kfogel: yes
<jam> you can also set something bazaar.conf/locations.conf
<jam> kfogel: bzr_remote_path=XXX
<jam> so you could put
<jam> [bzr+ssh://myhost]
<jam> bzr_remote_path=/home/root/kfogel/...
<jam> bzr_remote_path:policy = recurse
<kfogel> jam: thanks
<kfogel> jam: when doing it on the command line, there's no need for that "policy = recurse", though, because I'm naming the branch address explicitly anyway, right?
<jam> kfogel: right, the env_var overrides config, etc
<jam> the config is so you can set up a specific site to be different from all others
<jam> certainly you don't want that env var when pushing to LP, for example
<kfogel> jam: certainly not :-).  And in general not -- in this case, the end goal is a situation where the remote side's restricted shell DTRT and people can just use bzr+ssh:// without any special config or env vars.  So I'm going to just do it on the cmdline; that way I know I won't let it continue too long
<kfogel> .
<jam> kfogel: did you get it workinG?
<kfogel> jam: not yet, but problem now is not in bzr, it's in existence of user accounts on the remote box, so I'm working on that
<kfogel> jam: this is for the GNU Emacs bzr+ssh:// thang, btw
<kfogel> davidstrauss: hey, your branch delay problem all solved, right?  (from last week)
<davidstrauss_> kfogel: yes, thanks
<Socket_77> Hello
<Socket_77> Is there anyway to get bzr to preserve the timestamp on an add/commit?
<Socket_77> and subsequently on a checkout?
#bzr 2010-05-11
<GungaDin> How can I branch into a remote location without having to branch, push & reconfigure?
<Peng_> GungaDin: What? "bzr push"?
<GungaDin> no, I want to immediately branch from a remote place to a remote place.
<GungaDin> I think I managed simply by specifying both urls.
<Peng_> Oh.
<mkanat> spm: I don't know if you saw, but we pushed an actual fix for one of the bugs lately, so you might want to update codebrowse to loggerhead trunk if you haven't in the last two days or so.
<spm> mkanat: excellent! ta; will do!
<thumper> mkanat: an actual fix?
<thumper> as opposed to a fake fix?
<mkanat> thumper: I checked in a fix that didn't fix it, at first.
<thumper> ah
<thumper> mkanat: which bug?
<mkanat> thumper: https://bugs.launchpad.net/loggerhead/+bug/420738
<ubottu> Launchpad bug 420738 in loggerhead "LRUCache.cleanup raises KeyError" [Critical,Confirmed]
<jam> wgrant: didn't you recently post an lsprof of 'bzr branch' to a bug? Do you know what bug that was?
<mwhudson> jam: probably https://bugs.edge.launchpad.net/bzr/+bug/562666
<ubottu> Launchpad bug 562666 in bzr "2a fetch is very cpu intensive" [High,Confirmed]
<spiv> jam: 562666
<wgrant> Yeah, that's the one.
<wgrant> lifeless: 13 minutes to locally branch devel.
<lifeless> wgrant: ok
<lifeless> wgrant: we have some results
<ziminq> hi all, how can I commit part of a file's changes? something like 'git add -p'?
<spiv> ziminq: 'bzr shelve'
<ziminq> spiv: thanks, i'll take a look at this :-)
<spiv> ziminq: e.g. use bzr shelve to temporarily set aside the changes you don't want to commit yet, then you can commit, and then you can unshelve again.
<ziminq> spiv: yeah, just what I want. similar to idea of git stash.
<wgrant> lifeless: Aha. Panic panic?
<awilkins> Someone remind an idiot how to push a new branch into an empty SVN repository?
<jelmer> awilkins: hey
<jelmer> awilkins: bzr push <repo>/trunk
<awilkins> Hello Jelmer
<lifeless> wgrant: a 12% improvement about to be put up for review
<awilkins> jelmer, I'm getting "http does not support mkdir()"
<awilkins> jelmer, And I'm an idiot because I don't have bzr-svn installed   :-S
<awilkins> Thaaat works better
<jelmer> awilkins: that'd explain it :-)
<wgrant> lifeless: Ah, great!
<wgrant> Not so great, however, is that my lp:linux checkout is about to reach 2.5GiB.
<jelmer> wgrant: `have you tried repacking it
<jelmer> ?
<wgrant> jelmer: Well, it's still downloading..
<jelmer> wgrant: hmm, that's odd - I think it was only around 300Mb here..
<jelmer> wgrant: you're not accidentally fetching into a 1.9 repo?
<wgrant> jelmer: Yes, it was just a few undred megabytes when I tried it a few weeks ago.
<wgrant> jelmer: No, fresh checkout into /tmp, which is not a shared repo.
<jelmer> wgrant: hmm
<mwhudson> i guess it would be interesting to get a losa to run du a couple of times
<lifeless> wgrant: srsly?
<wgrant> lifeless: Yeah, 2.5GiBwas shown in the progress indicator thingy, but .bzr ended up at only 475MiB.
<awilkins> Does it transfer compression groups or does it stream their content?
<awilkins> e.g. - if pulling and you ask for a revision stream that's in a compression group does it just send the group so you can hit that later on?
<Tak> does bzr-git support dpush?
<jelmer> Tak: yes
<Tak> but not regular push yet, correct?
<jelmer> Tak: right, though it might not be too long before it supports regular push
<Tak> dpush works for me for now
<Tak> is there a known good way to dpush to github?
<jelmer> bzr dpush git+ssh://git@github.com/tak/repo
<cbz> What's the difference?
<Tak> http://paste2.org/p/822944
<jelmer> cbz: between what?
<cbz> Oh - it strips the metadata
<cbz> In working with git i presume the model isn';t one of rebase and then push - but that one pushes all one's revisions upstream
<jelmer> cbz: not sure I follow, in git rebase seems to be used a lot
<Tak> that's with branch, commit, dpush
<cbz> I just meant that when working with subversion one has to rebase ontop of the latest chanegs in the remote repository before pushing upstream
<jelmer> tak: that's a known issue in trunk at the moment
<Tak> oh, ok, is there a known good rev?
<jelmer> Tak: I'd use a release
<Tak> oh, hmm, so it actually pushed my revision
<lifeless> awilkins: neitherish
<cbz> I'm getting this error when doing a bzr pull: bzr: ERROR: sqlite3.OperationalError: database is locked
<cbz> is there a way of cleaning up the lock?
<jelmer> cbz: you have two bzr processes accessing the same svn repo
<jelmer> cbz: you can install python-tdb to work around that issue (it allows concurrent access)
<cbz> jelmer: something must have left the lock behind. The only other thing running is a tbzrcache process
<mwhudson> and then you can mangle the subversion.conf file :)
<jelmer> cbz: I wouldn't be surprised if that's what accessing the database..
<cbz> Is the lock a per user or per repository setting?
<cbz> i've exitted tbzrcache and stil get the same error - any way of cleaning up?
<jelmer> cbz: it's per repository
<jelmer> cbz: It shouldn't give that exception if there aren't any processes using that cache
<jelmer> I guess you could remove the cache, if windows will allow you
<cbz> Hmm - only a reboot fixed it in the end
<hersonls> Hi, im new in layout of cvs and how is the best way to create a branche from a trunk in the same repo?
<Kamping_Kaiser> cvs?
<hersonls> yeah, layout like svn, trunk/ tags/ branches/ - before i never use this, only one directory
<hersonls> i see a svn tutorial to use a svn cp trunk/ branches/0.1 - for exemple
<hersonls> how the best way into bzr
<Peng_> "bzr branch"?
<hersonls> i dont know about that, i dont understand how this work fully... but bzr branch creat a copy of a branch, is the correct way? branch inside branch?
<Peng_> I think you should read the tutorial or something.
<Peng_> "bzr branch" creates a branch.
<Peng_> Which starts out as a copy of the branch you're branching from, yes.
<hersonls> this i understand
<hersonls> my question i how to work with this layou branches/ trunk/ tags/
<hersonls> i read in same blog's, the trunk is a production branch and when i make a modifications i make a copy from trunk to branches/
<hersonls> right?
<Peng_> Why do you want to work with that layout?
<Peng_> I've never uinderstood the point of consigning non-trunk branches to some "branches" directory.
<Peng_> And in Bazaar, tags are dcreated with "bzr tag".
<hersonls> so, i can make a tags so easy?
<hersonls> so the best way is making a tags?
<Peng_> The "best way" for what? When you need a tag, make a tag. When you need a branch, make a branch.
<hersonls> =)
<awilkins> hersonls appears to be used to SVN
<awilkins> SVN implements tags and branches by convention only using the ability to copy a SVNFS inode
<hersonls> awilkins, haha, i'm reading a good article about this
<hersonls> and i like that
<hersonls> http://www.scribd.com/doc/10965126/ccbazaar
<awilkins> I liked SVN a lot ; I converted 3 shops to it, I still administer SVN repositories, but I'm a born-again DVCS convert
<hersonls> the only problems i have with bzr is a permission in repo, when one user make a push when anothe make too make a access denided using sftp
<hersonls> =(
<beuno> hersonls, you need to have them both in the same unix group
<hersonls> yeah, i see in this - chmod 770 /bazaar/bzr; chmod +s /bazaar/bzr
<Peng_> Does the sticky bit work over SFTP?
<maxb> The sticky bit is +t, not +s
<Peng_> Oh. :P
<poolie> Peng_: do you mean sticky or setgid? in any case
<maxb> +s/+t work at the filesystem layer, so it doesn't care how you're accessing it
<poolie> some servers filter out setuid/gid
<Peng_> I remember OpenSSH having issues with something, but IIRC it was just the umask?
 * Peng_ has never used any of the unusual bits, so he doesn't know them well.
<maxb> The problem with using setgid directories and a common group is it requires that users' umasks do not mask group permissions
<Lor> Hi, is there any documentation on how plugins are supposed to handle locking?
<lifeless> jam: https://code.edge.launchpad.net/~lifeless/bzr/command-help-bug-177500/+merge/25055
<jelmer> bzr send not defaulting to --strict anymore is great :-)
<jam> lifeless: i believe I already reviewed
<lifeless> jam: ok
<lifeless> ah yes
<lifeless> stale webby pagy
<Lor> So, are plugins supposed to call tree.lock_read(), or are lock operations considered to be internal to bzrlib?
<lifeless> only the highest level functions take locks automatically
<Lor> Are the locks recursive?
<lifeless> any non-trivial plugin will be likely taking locks explicitly
<lifeless> reentrant? yes
<Lor> All right, then it shouldn't be too hairy.
<Lor> Incidentally, how long is the bzr codebase supposed to be python 2.4 -compatible? The with-statements introduced in 2.5 would make writing critical sections much easier.
<lifeless> we were talking about this earlier
<lifeless> I'm not sure, is the short answer ;)
<lifeless> but we can add glue for with to bzr without being 2.4 incompatible
<Lor> You mean, make it easier for plugin writers to use with-statements (and lose 2.4-compatibility) if they choose, but refrain from using them in the core?
<Lor> Of course, the glue itself is pretty trivial: http://pastebin.com/nmfpHHsb
<Lor> By the way, here are some plugins I intend to write. Please tell if you are aware of something similar already underway.
<Lor> bzr-mtime: store mtimes of added and modified files under .bzrmeta/mtimes. Add a merge hook for that file to select the newest mtime.
<Lor> bzr-snapshot: allow making "snapshot" commits, so that the latest non-snapshot revision is tagged as such. A "real" commit is then actually a final snapshot, plus a merge into the latest non-snapshot revision.
<Lor> (This allows storing an intermediate, ugly state of the tree, but since it ultimately happens in a branch that gets merged back, the final history will look cleaner)
<Lor> Finally, a plugin that traverses through the working tree and interactively asks the user what to do with each unknown file: delete, add or ignore henceforth.
<lifeless> I'm not aware of anything underway for those things
<Lor> All righ.t
<Lor> (I do think that the mtimes should be stored by the core in the inventory, though.)
<lifeless> well we have the time of the commit
<lifeless> which is more accurate in many ways (consider e.g. revert, touch, etc)
<Lor> I don't mean that the mtimes should be utimed to the working tree during checkout.
<Lor> But they are useful information.
<Lor> Suppose I edit a file in the working tree but forget to commit, and after some weeks edit some more and then commit.
<Lor> Then it's nice to retain the information about the earlier editing.
<jelmer> lifeless: ping
<lifeless> pon
<jelmer> lifeless: When would be a good time to look at colocated branches / foreign branches this week?
<lifeless> tomorrow perhaps ?
<jelmer> lifeless: there's quite a few session I have to attend tomorrow, thursday or friday would work better for me
<lifeless> sure
<Lor> Is there some specification for file-ids?
<Lor> I think it would be good to have a fixed, custom file-id for the mtime file, but I'm not quite sure if there is some convention for choosing the id.
<poolie> jam, do you mind if i put you down as PP next week?
<jelmer> Lor: I don't think there's any hard-coded file ids other than the now deprecated TREE-ROOT
<Lor> But per-tree metadata files that are managed by plugins probably ought to have hard-coded file-ids, since otherwise bad things will happen if two unrelated repositories get merged.
<Lor> s/repositories/branches
<Lor> On the other hand, _really_ bad things will happen if two distinct plugins choose to use the same file-id.
<Lor> A namespace convention would be useful for preventing collisions.
<lifeless> Lor: the path is sufficient, I think. the plugin can handle merging appropriately
<Lor> Uh, how can it be handled appropriately if two mtime files have been created in two unrelated branches, with different file-ids, and then those get merged (joined, in practice)?
<Lor> Hm. Doesn't the .bzrmeta directory (which, I gather, is the officially recommended place for data stored by plugins) also have a fixed file-id?
<Lor> Or shouldn't it?
<spiv> No, it doesn't have a fixed file-id.
<spiv> It might be nice if it did.
<spiv> But even the tree root doesn't...
<Lor> Oh, that has changed?
<Lor> How then are two unrelated branches merged?
<Lor> Ah, it's an error nowadays.
<spiv> Hmm, not sure how different tree roots affect it, but I'm fairly sure "bzr merge -r 0..-1 $unrelated" manages to do something useful.
<Lor> I always thought that it's really pretty that every branch has a common ancestor.
<Lor> But obviously that wouldn't work with nested trees.
<Lor> So, um, with nested trees, file-ids have to be unique throughout the hierarchy?
<lifeless> yes
<Lor> Then, obviously, all subtree-specific metadata files also have to have unique ids.
<lifeless> yes
<Lor> Well, that decides it.
<Lor> So then I need a hook to be run during a join operation, one that migrates the metadata from subtree/.bzrmeta/mtimes to .bzrmeta/mtimes
<Lor> Except that no hooks are currently run during WorkingTree.subsume...
<spiv>   
<dwt> Hi all, I've got a project that is a checkout of a google code repository, but that I also publish to my another repo on my homepage
<dwt> now I always need to type 'bzr push && bzr push bm:upstream' to push it to these locations (the bookmarks plugin already helps a ton)
<dwt> BUT
<dwt> I'm sure there is an even better way to push to these two locations
<dwt> (as I always want that)
<dwt> but I couldn't find anything in the plugins section or with gui
<dwt> sorry, in the wiki
<dwt> or with google
<dwt> so thats why I'm asking here
<Lor> I'm actually also interested in this.
<dwt> So please help, how to spare typing those extra characters?
<dwt> Lor: Yay, now we're two! :)
<IslandUsurper> dwt and Lor, make an alias for, say, "push-all"
<Lor> If your entire problem is typing more, then... echo.
<Lor> I have (or will have) a slightly more complicated situation, though.
<dwt> IslandUsurper: alias means that it is global and not local to one repository, right?
<IslandUsurper> dwt, I think you can have both
<IslandUsurper> I'm not sure about it now, though. I may have been thinking of git :-/
<dwt> IslandUsurper: Those seem to be defined in ~/.bazaar/bazaar.conf
<dwt> can I have one of those per project too?
<IslandUsurper> there's a branch.conf
<IslandUsurper> in .bzr/branch/branch.conf
<dwt> http://wiki.bazaar-vcs.org/ConfiguringBzr Aliases cannot be specified in locations.conf or branch.conf
<dwt> :-(
<dwt> Other ideas?
<Lor> Why does this need to be branch-specific?
<dwt> Well, repository specific would be fine for me
<dwt> but as far as I understand that means it has to be in locations.conf or branch.conf
<dwt> right?
<Lor> There are all kinds of kludges (or non-kludgy Real Solutions) you could do, but I'm not sure if they're worth the effort.
<dwt> Hrmâ¦., well, I can always resort to makefiles / scripts as a last resort
<dwt> I'd rather hoped to avoid that though
<Lor> It's pretty simple to write a plugin that modifies the push command so that multiple push_locations are supported.
<Lor> Frankly, the api is a bit messy, though.
<Lor> Too much of the logic of ordinary commands is in the actual command classes.
<Lor> Doing an ordinary push from python code should preferably just be a single method call without parameters.
<dwt> Yeahâ¦. Well, maybe if the internal implementation is simplified I might give it a go
<dwt> :-)
<Lor> Wait a sec... a commit hook only gets access to the branch, not the working tree?
<dwt> uhm, yes/no/maybe?
<dwt> Sorry, I have no knowledge of bzrs internals. :)
<Lor> Ah, I was looking at pre_commit when I really should have used start_commit.
<Lor> If the current working tree is in a state of an uncommitted merge, is there a way to find out which of the currently modified/added files came from the merge without conflicts?
<Lor> Also, what's a ghost revision?
<Lor> Why doesn't Tree.changes_from() support specific file_ids?
<Lor> It seems funny that an api supports specifying an argument as a path (which is then converted into an id) but not directly as an id.
<jelmer> moinmoin
#bzr 2010-05-12
<MTecknology> how can I make a patch file for binary changes?
<Peng_> MTecknology: You can't with bzr, but "bzr send" does include binary data in a base64-encoded block at the end (along with other stuff).
<MTecknology> Peng_: oh, I have a source_A and a source_B which is source_A + changed; I want to apply the changes from the two onto source_C
<Peng_> MTecknology: ......"bzr merge"?
<MTecknology> I don't know what the actual changes are though :P
<Peng_> OK, I'm way to sleepy to understand this conversation, sorry.
<MTecknology> Peng_: aight - I should head that way too
<radoe> How do I get rid of the remembered locations from pull/push --remember?
<lifeless> you can edit .bzr/branch/branch.conf
<lifeless> or just --remember a better url
 * mtaylor pokes lifeless 
<Lor> Still continuing about the uniqueness of file-ids: a special metadata file should have a file-id that is uniquely determined by the id of the tree root.
<jelmer> Lor: I'm not sure if that's necesarily a good idea
<Lor> So we want the metadata files to have distinct ids when they are in unrelated branches (to avoid collisions in joins), but if the same metadata file is created two times in related branches, they should have the same id.
<jelmer> what would happen in the case of nested trees, in which case multiple versions of this file could exist in different trees?
<jelmer> (file ids need to be unique)_
<Lor> Those different trees must have distinct tree root ids anyway.
<Lor> That's the whole point of rich-root, iiuc.
<jelmer> Lor: Sure, but all of the files in those trees also must have unique file ids
<jelmer> Lor: So if e.g. .bzrmeta always had the same file id then it would make it impossible for nested trees to contain .bzrmeta
<Lor> No, .bzrmeta will have an id that is in one-to-one relation with the id of the tree root.
<Lor> So each distinct subtree (with a distinct id) will also have a distinct id for .bzrmeta
<jelmer> Lor: in that case, what's the point of having a constant file id?
<Lor> The point is that if a plugin creates the metadata file in two related branches, then there won't be a path collision (only a text collision, which can be handled) when the branches are merged.
<jelmer> Lor: That's a problem with all sorts of parallel imports, not really specific to the issue you're raising.
<jelmer> I think we should just handle that situation better in general
<Lor> Yes, true.
<Lor> But metadata files have clearer identities than random imported stuff.
<Lor> It's better to avoid assigning two file-ids to what is known to be a single logical file identity, when that is possible.
<jelmer> Lor: You should be able to already specify a manual file id if you know how to generate it though
<Lor> Yes, obviously it is possible.
<Lor> I'm talking about what should be the convention for plugin authors when they create metadata files.
<Lor> Especially if .bzrmeta is to be used by everyone, then it would be good that whoever first creates .bzrmeta gives it the "right" file-id.
<jelmer> Lor: I think if it's considered a good idea to have a common file id for that directory, we should add a convenience method to bazaar that creates that directory for you
<jelmer> it can then also take care of assigning the right file id, etc
<Lor> Right.
<clbr> i'm looking for a way to only merge certain revisions from branch A into branch B (or excluding some). I'm wondering if this is conceptually possible?
<jelmer> clbr: hi
<clbr> hi
<jelmer> clbr: yep, you can specify individual revisions to merge using -c or -rR1..R2 to merge a range of revisions
<clbr> thx, this was easy :-)
<clbr> I'll try if I get the results I expect
<Lor> Incidentally, is there some rationale available for bzr's handling of clean ambiguous merges?
<Lor> hg decides to treat them as conflicts, whereas bzr sees no problem
<Lor> bzr's approach is certainly more practical, but hg seems to Do The Right Thing
<mwhudson> Lor: what do you mean by "clean ambiguous merge" ?
<Lor> The same change being done in two distinct branches, which then get merged.
<mwhudson> bzr's default merger is based on a majority voting three way merge i think
<Lor> Yes, but _why_ do it this way?
<Lor> hg docs provide a rationale for their choice
<Lor> I'd like to see something similar for bzr
<mwhudson> dunno really
<mkanat> Lor: Personally, I'd be extremely annoyed if identical changes showed up as a conflict.
<Lor> I can't find the rationale from ht docs right now, but here's how it went:
<Lor> Suppose that in the original you have:
<Lor> #define NUM_THINGIES 3
<Lor> enum { FOO, BAR, BAZ } Thingy;
<Lor> (Those lines might be in completely different places)
<Lor> In THIS you have:
<Lor> #define NUM_THINGIES 4
<Lor> enum { FOO, BAR, BAZ, QUUX } Thingy;
<Lor> and in OTHER you have:
<Lor> #define NUM_THINGIES 4
<Lor> enum { FOO, BAR, BAZ, FNORD } Thingy;
<Lor> After the merge, we _don't_ want to have #define NUM_THINGIES 4
<mkanat> Lor: That will conflict anyway, though.
<mkanat> Lor: Because the enum line isn't the same.
<mkanat> Lor: Oh, I see what you mean, though.
<Lor> I'm talking about the #define line.
<Lor> It might be far away from the enum.
<mwhudson> Lor: but there are always going to be cases where a clean merge doesn't mean working code
<Lor> Also, the items of the enum line might be listed one per line. Then an automatic merge could handle it.
<Lor> True enough.
<mkanat> Lor: Yeah, I think that case is uncommon enough that I'd rather have it merge for me.
<mkanat> Lor: Given that otherwise, in some branches I'd be getting literally hundreds of conflicts on merge.
<Lor> But that's because your changes do have a common origin that the version control system just can't track?
<Lor> If you just apply a patch to two branches, then bzr won't have any way of knowing that the changes are really the "same" change.
<mkanat> Lor: Yes, I actually had a discussion about this the other day with folks here.
<Lor> Did darcs come up? :)
<mkanat> Lor: Ha. No, DaggyFixes did.
<mkanat> Lor: But I think DaggyFixes is a bad, hackish solution.
<mkanat> And also one that isn't broadly-applicable enough to development processes to work.
<Lor> Darcs tries very hard to Do The Right Thing.
<mwhudson> Lor: have you seen http://github.com/droundy/iolaus ?
<mkanat> Lor: Actually, though, bzr doesn't worry about *identical* patches.
<mkanat> Lor: It handles those fine, now. So that's why those merges are good for me.
<Lor> Yes, well, obviously it is impossible for a non-semantics-aware tool to guarantee that the result of a merge makes any sense.
<Lor> It's just a question of what level of imperfection to strive for.
<mkanat> Lor: Well, I think it's more of a matter of what's the most practical for the majority of users.
<mkanat> Lor: That is, if it's a question that can't be solved for 100% of them in all cases.
<Lor> iolaus seems pretty neat
<Lor> The semantics of darcs with the performance of git would be a sweet combo.
<Lor> (Still, I'm not very fond of git.)
<mwhudson> you could do something similar for bzr i think, the model is similar enough
<Lor> loom and pipeline are the first steps in that direction
<mwhudson> well
<mwhudson> a similar direction i guess
<Lor> Those require you to specify the dependencies explicitly, and with coarser granularity, and the dependencies form a list and not a full graph. But anyway.
<spiv> Lor: the rationale for clean merges when both sides make the same change is:
<spiv> a) if both sides agree then it's probably what you want, and
<spiv> b) it makes coping with cherrypicks much more pleasant
<spiv> e.g. the scenario of backporting a particular fix from trunk to a stable release branch, but then later merging that release branch back into trunk.
<Lor> Yes, but that seems like a symptom of the fact that the history of cherry-picks isn't tracked.
<spiv> Sure.
<spiv> If you want it'd probably be not too hard to provide a plugin to trigger conflicts in this case.
<Lor> True enough.
<spiv> Oddly enough users most don't ask for more conflicts ;)
<spiv> Kind of related: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/hooks.html#example-a-merge-plugin
<Lor> Yes, I just wrote one.
<Lor> A trivial one, though: the metadata file is recreated during commit, so the merge hook doesn't need to do anything except notify that there is no conflict.
<spiv> *nod*
<Lor> Anyway, there should also be subsume- and extract-hooks.
<Lor> Or, preferably, versioned per-entry metadata, so it gets moved automatically during a join or split.
<wgrant> With bzr 2.1.1 and bzr-git 0.4.3 on Lucid, attempting to branch from a git://... URL crashes like http://paste.ubuntu.com/432198/
<wgrant> Any hints?
<parthm> jam: https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483
<Lor> Is it a policy that every distinct plugin hosted by launchpad should have its own project?
<Lor> Even if it's just a single file?
<jelmer> wgrant: that's the bug I was talking about earlier with upstream python changing behaviour
<jelmer> wgrant: doing an SRU for that is on my todo list for this week
<Lor> Also, what's the preferred way to share code between plugins?
<maxb> Lor: The way Launchpad, especially its automatic stacked branches, works, makes it very much preferable for there to be 1 project per group of branches sharing history.
<maxb> That pretty much implies 1 project per plugin
<Lor> Not really.
<Lor> I could develop several plugins in a single branch.
<Lor> And have a project that covers all those plugins.
<jelmer> Lor: that makes it hard to check out those plugins though
<Lor> It seems a bit ugly, but it would allow straightforward code sharing.
<Lor> Hard to check out? How?
<jelmer> Lor: you can't just run "bzr branch lp:foo ~/.bazaar/plugins/foo" anymore
<Lor> Well, I never do that anyway, I create explicit symlinks.
<Lor> I think it's bad style to have any real content in dot-directories.
<Lor> Well then, it is also possible to just develop a single plugin (a single directory, that is), that provides lots of unrelated functionality.
<Lor> Like bzrtools.
<Lor> Is that considered bad style?
<jelmer> Lor: it depends on the tools I guess
<jelmer> Lor: the stuff in bzrtools is all quite small so the maintainance overhead probably doesn't make it worth having separate plugins
<Lor> I just wrote a plugin that is 143 lines.
<Lor> It doesn't quite seem worth its own project.
<jelmer> Lor: what does it do?
<Lor> It records mtimes of modified files in .bzrmeta/mtimes
<jelmer> Lor: I think that probably deserves its own file
<jelmer> *plugin
<Lor> I find myself defining lots of general-purpose auxiliary functions that bzrlib doesn't provide. I'd like to use those in other plugins, too.
<spiv> Lor: projects are cheap ;)
<Lor> What do I do?
<jelmer> Lor: can you give examples of those auxiliary functions?
<jelmer> I haven't noticed that so far
<spiv> Lor: submit patches to bzrlib!
<jelmer> or not anymore, rather :-)
<Lor> http://pastebin.com/pi1Fw2YV
<dickelbeck> Need help on a command line formulation.  The built in help is not cutting it....
<dickelbeck> I want to get the diff between the latest rev in a branch and the previous version.  How?
<dickelbeck> A single file.
<Lor> Previous version of the file or previous revision of the tree?
<spiv> dickelbeck: bzr diff -c -1 FILE
<spiv> Hmm, or perhaps bzr diff -r -1..-2 FILE depending on the direction you want.
<dickelbeck> spiv: thanks, but that is outputting nothing.
<dickelbeck> is there a way to show the last changes, regardless when they occurred?
<jelmer> Lor: the first one seems like it could be in bzrlib somewhere
<jelmer> Lor: the second one doesn't seem generic enough to me
<dickelbeck> Lor: previous version of the file
<Lor> jelmer, I would expect that something like the second one is needed by any plugin that creates metadata files.
<Lor> Oops, default_path shouldn't be optional.
<spiv> dickelbeck: oh, I see, I thought you meant the file as it was in the previous revision of the entire tree
<jelmer> Lor: it encourages the use of hardcoded file ids though, and they are a bad idea
<spiv> dickelbeck: I don't think we have a good shortcut for that :/
<jelmer> Lor: it should be possible for the user to create such files as well
<Lor> Didn't we just talk about this?
<jelmer> Lor: yes, but we concluded that constant file ids were bad right?
<spiv> dickelbeck: although if I want to explore changes in old versions of a file I usually go straight to using something like 'bzr qannotate'
<Lor> Not globally fixed but determined by the root id.
<jelmer> Lor: file ids based somehow on the root id are a less bad idea
<Lor> That's what's supposed to be given as an argument.
<Lor> Sure, the above function could be given an "id template" which it would then mangle with the root id to create the actual file id of the created file.
<jelmer> Lor: I'd rather see something more specific for that situation
<jelmer> i.e. something that also makes sure .bzrmeta exists with a particular file id and takes a file-id postfix
<Lor> Well, the function is underscored for a reason. :)
<jelmer> Lor: it's also a bad idea to require that a path has a specific file id
<spiv> Yeah, we should provide some facilities to help plugins use .bzrmeta
<jelmer> Lor: it should be possible for the user to create these files manually
<Lor> Not in this particular case.
<Lor> The user isn't supposed to even see the file, much less alter it.
<jelmer> always
<jelmer> Lor: if the user isn't supposed to see the file it shouldn't be in .bzrmeta
<Lor> Where, then?
<Lor> I want the file to be versioned.
<jelmer> .bzr/
<spiv> .bzr is the place for "No user serviceable parts inside"
<Lor> Yes, but it isn't versioned.
<jelmer> Lor: supporting this properly would require a format change
<Lor> What should I do in the interim?
<spiv> Hold your nose and use .bzrmeta, probably.
<Lor> Currently the idea is that .bzrmeta/mtimes is recreated from scratch during commit.
<Lor> Only the versions from the parent trees are read, not the one in the working tree.
<jelmer> alternatively this sort of thing could supported by the luggage proposal when it is implemented
<jelmer> *baggage
<mwhudson> jam: you there?
<jam> mwhudson: I'm here now
<jam> downstairs in Pomegranate
<mwhudson> jam: a good time to come down now?
<jam> mwhudson: yeah, should be
<mwhudson> cool
<mwhudson> be there in a bit
<dickelbeck> spiv: thanks, bye.
<Lor> Is it recommended that even single-file plugins are implemented as myplugin/__init__.py instead of myplugin.py?
<spiv> Lor: I think so; it gives you a place to put a README etc, and also means .pyc files are out of the way
<Lor> Okie.
<Lor> Still, code sharing seems tricky.
<Lor> Well, nested trees would in theory be the solution...
<Lor> (For development, not for distribution)
<jelmer> Lor: How much code is there to share though?
<Lor> In my case, probably not much.
<jelmer> Lor: Ideally code that's generic enough should be in bzrlib
<Lor> You can't expect a plugin author's workflow to be contingent on bzrlib development.
<Lor> But yes, ultimately code can of course migrate from plugins to bzrlib.
<jelmer> Lor: It's hard to answer this without a concrete example
<Lor> How come?
<jelmer> Lor: As far as I know (and have experienced, I've written > 10 plugins) bzrlib provides sufficient functionality
<jelmer> Lor: You can always copy code between plugins if nothing else is possible and I've done that on occasion
<Lor> Yeah, I'd like to avoid that.
<jelmer> Lor: Ultimately that code has all gone upstream
<jelmer> Lor: I guess you could maintain a library with utility code that more than one plugin can use
<Lor> Yes, but distribution of plugins would be difficult.
<Lor> Well, this is not a very critical problem.
<jelmer> Lor: this is a problem with all sorts of library code and packaging
<Lor> Yeah.
<jelmer> Lor: the solution is called apt :-)
<Lor> I wouldn't mind if launchpad automatically generated deb packages for the plugins.
<jelmer> Lor: it doesn't have enough information to do that
<jelmer> Lor: it could be possible with some extra metadata I guess
<yurii> Hi anyone around who uses Bazaar on Snow Leopard?
<dash> i do
<yurii> Any way I can uninstall the bundle? The uninstaller doesn't work on Snow Leopard
<mwhudson> jam: the session just got cancelled :)
<mwhudson> back soon
<spiv> vila: https://bugs.edge.launchpad.net/paramiko/+bug/579530 is the bug for that failure
<ubottu> Launchpad bug 579530 in bzr "paramiko does not try all available address families" [Medium,Confirmed]
<vila> spiv: thanks !
<vila> poolie: PING (note the caps), have a look at https://code.edge.launchpad.net/~mbp/bzr/491763-transform-rename-failed/+merge/24474 ! And land it quickly :-)
<ciss_> hi
<bendj> How do I 'reset' a repo's history to start at a given commit?  E.g., if I've got many months' of revisions tracked, but don't need/want anything kep anymore before a recent commit labelled "blah blah".
<ciss_> i was wondering if someone can suggest a tutorial or tool on how to create patches from a revision and applying them via ssh?
<dash> bendj: create a new branch using 'bzr init'
<dash> bendj: copy files into it
<dash> bendj: add them, commit.
<bendj> dash: a bit confused ... that seems like it'd work just fine to create a 'reset' repo starting with the _current_ state.  But I just want to 'prune' the repo of info/data before a given, prior commit.  I.e., I _do_ want to have/track all the revisions _cince_ that prior commt.  Possible?
<dash> bendj: i guess the 'rebase' plugin is supposed to do this
<bendj> dash aha ... looking
<bendj> dash: bzr_rewrite looks to be the ticket (http://wiki.bazaar.canonical.com/Rewrite).  Thanks!
<dash> 'bzr memory_hole'
<bendj> :-)
<Lor> bendj, tailor can do that too
<bendj> Lor another new one for me, thanks!
<mathrick> jelmer: hi
<mathrick> bzr-git doesn't want to download git repos when served URLs like http://common-lisp.net/project/parenscript/git/parenscript/
<mathrick> ie. that directory already contains what .git normally holds
<mathrick> git itself has no problems with operating off that
<GaryvdM> mathrick: Do you get a error.
<mathrick> bzr: ERROR: Not a branch: "http://common-lisp.net/project/parenscript/git/parenscript/".
<GaryvdM> mathrick:  I think it is a known error due to a change in python.
<mathrick> oh?
<GaryvdM> mathrick: What OS an bzr-git version?
 * GaryvdM looks for bug
<mathrick> lucid and, lemme see
<mathrick> bzr-git 0.4.3
<mathrick> out of some debs
<GaryvdM> mathrick: I was think about Bug 556968, but that gives an error message.
<ubottu> Launchpad bug 556968 in bzr-git "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository (needs upstream cherrypick/backport)" [Critical,Confirmed] https://launchpad.net/bugs/556968
<GaryvdM> mathrick: But that affects your version.
<mathrick> GaryvdM: for me it seems likely that bzr-git is merely not expecting the git repo to be at the top level and not under .git
<mathrick> it's too orderly to be that error :)
<GaryvdM> mathrick: Ok - best look for Jelmer then.
<ciss_> is there a convenient way to remove all files from versioning that are matched by the patterns in .bzrignore?
 * GaryvdM looks arround the lobby at uds for Jelmer, no, he is not here - sorry
<ciss_> or are those automatically removed on the next commit?
<mathrick> GaryvdM: ok, thanks
<Lor> .bzrignore only applies to unknown files
<Lor> As is good and proper.
<Lor> I'm not sure that .bzrignore really belongs in the inventory.
<Lor> It's just a user interface configuration, and no other configuration information is versioned.
<ciss_> Lor, usually my .bzrignore file needs some tweaking until i get all the rules right, putting several unwanted files into versioning in the process. i was wondering how to get them out of versioning without removing each pattern match one by one
<Lor> Ordinary shell expansion ought to help a lot.
<Lor> But really, you have been quite careless if you have added unwanted files and committed before checking what exactly is going to get in.
<ciss_> checking 11K files is a little time consuming
<ciss_> anyway, thanks for the hint
<Lor> It's probably pretty simple to write a plugin to remove all files that match the ignore rules.
<Kobaz> how do i undo a merge... i deleted new files, and revered modified files, but bzr st is still reporting a pending merge
<Kobaz> i guess i can commit and then uncommit
<beuno> Kobaz, --forget-merges I think
<beuno> revert --forget-merges that is
<beuno> I do think, though
<Kobaz> nifty
<Kobaz> that worked
<beuno> that plain "bzr revert" should leave everything in a default state again
<Kobaz> is there a changelog for the new stuff in 2.1.1
<Kobaz> i'm still on 1.18
<beuno> that's super old!
<Kobaz> heh
<Kobaz> but it works
<beuno> 2.x has the new format
<beuno> 2a
<Kobaz> i upgraded to 1.20 at one point, and it kind of broke everything
<beuno> which is a trillion times faster
<Kobaz> so i stayed with 1.18
<Kobaz> mmm, it does seem faster
<Kobaz> playing with a copy of my repo with 2.1.1
<kojiro> argh
<bendj> my bzr is working ok.  just installed bzr-git/dulwich.  when i try to branch a git repo, i get an 'internal error' -> http://pastebin.com/kd2BsmDa
<bendj> is it my bad, or a prob with bzr or bzr-git?
<Peng_> Prob'ly not your fault.
<jelmer> bendj: bzr just changed its api and that broke bzr-git
<jelmer> if you use a bzr from a couple of days back it should work ok
<bendj> jelmer: Sounds like it's "known" ... still needs reporting?  I've not (yet) found a bug abt it ...
<jbowtie> jelmer: Any details on this API change?  I've a got a foreign VCS plugin I might be releasing soon (waiting for approval from lawyers)
<jelmer> jbowtie: basically lock_write / lock_read need to return an object with a unlock method now
<jelmer> bendj: I don't think it's reported yet
<jelmer> jbowtie: just curious, what foreign VCS does this plugin add support for or can you not say yet?
<bendj> jelmer: offhand, know which revision triggered it?  i've dropped back to r5218, from 5/7 -- same problem
<Lor> Is it guaranteed that a merge with an ancestor will have no conflicts?
<Peng_> Look for "lock" in the log?
<jelmer> Lor: I think so, it would be a no-op
<jelmer> bendj: less than 10 revisions on mainline back
<Lor> No, it creates a new revision.
<Lor> Which is good, because I need that feature.
<jelmer> Lor: merge never creates a new revision
<Lor> I mean, it creates changes.
<bendj> Peng_: sure, i did ... last 'lock' @ r5223
<Lor> And after the merge a commit won't complain that there are no changes to commit.
<Peng_> Lor: Not if you merge an ancestor, since it's a no-op. It does nothing whatsoever.
<Lor> I mean, I merge the head _into_ the ancestor.
<Peng_> Oh.
<Peng_> Lor: in that case you could pull.
<Lor> No, I want a merge.
<Lor> It seems to work just right, I just want to know if there is some obscure corner case that could create conflicts.
<jelmer> Lor: you're merging a single revision, not a range or something?
<Lor> A range.
<Lor> The idea is to make a bunch of revisions look like a single merge, so there will only be a single log entry shown by default.
#bzr 2010-05-13
<Lor> So it's a way of grouping a bunch of recent changes together in a way that can be seen in the revision history.
<bendj> Hm.  Trying to pull just a single revision of bzr.dev to another box, "bzr pull bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev -r 5218" gives me "bzr: ERROR: Not a branch: "/build/"."
<bendj> Can't I do that?
<jelmer> bendj: /build is what you're pulling into?
<bendj> jelmer: nope.  dunno where that's coming from.  i'm simply in my ~/ dir.
<Peng_> bendj: Your homedir is a copy of bzr.dev?
<bendj> Peng no I'm trying to pull the rev into a dir into it.  I've tried to branch a single repo, but it seems to retrieve entire history ... all I want to do is pull the source for ONE revision.
<Peng_> bendj: Are you trying to create a new branch?
<Peng_> Ah.
<Peng_> bendj: pull does not create a new branch.
<bendj> Peng_: Nope, just pull source for ONE revision.
<bendj> yep, i know.  so how do I get ONLY one rev -- not the whole history?
<Peng_> bendj: The thing is, it may suck that "bzr branch" pulls down the entire history, but it's also the best-optimized path. "bzr checkout --lightweight" or "bzr branch --stacked" or even "bzr export -d" might actually be less efficient.
<bendj> Peng_: Iiuc, then, i *can't* pull just one revision's source?
<Lor> bendj, you can do a lightweight checkout
<Lor> or bzr export
<bendj> Lor Ok, I'm confused.  If those are single revision retrievals, then how could they conceivably be "less efficient" than retrieving the entire history ?
<Peng_> bendj: Because a lot of time and effort has been put into optimizing retrieving the entire history.
<Peng_> bendj: Anyway, I gave you three examples of how to do them. Unless you're on dial-up, even branching the entire history would have finished by now.
<Lor> Once you have the history locally, it's presumably more efficient to operate on it to e.g. retrieve a past revision.
<Lor> But yeah, speed is not a good reason for lightweight checkouts. Disk space might be.
<Lor> But not really on desktop machines, nowadays.
<bendj> Lor counterintuitive, but ok.  thx.
<Lor> I don't think the choice between these has any practical significance, if all you want is a snapshot.
<bendj> jelmer fwiw, 5218 is 'good enuf' to avoiid the issue ... thx.
<bendj> Lor fair nuf
<fabiokr> hi there
<fabiokr> is there a command to export just the files that have changed between revisions?
<dash> fabiokr: bzr log -v tells you
<dash> so you can either call whatever python api it calls
<dash> or use xmloutput and parse it out of the xml form of the log :)
<Peng_> bzr st -c 123
<dash> aha.
<jbowtie> I want to set up a cron job to push to bzr+ssh with specific credentials (on Windows). Since it ignores passwords in the authorisation.conf, is there a way to do this?
<dash> jbowtie: use key auth instead
<jbowtie> dash: Can I specify the key in the auth.conf?
<dash> jbowtie: you specify it in the setup for your ssh client, presumably
<jbowtie> dash: Ah, but I'm running the cron job as a specific user without a profile.
<dash> jbowtie: okay
<dash> well, you gotta have your ssh client configured somehow :)
<jbowtie> dash: Normally I use the --password parameter, but bzr doesn't give me a way to pass this.
<dash> beats me
<dash> didn't even know cron would run on windows
<jbowtie> dash: Well it can but I'm actually using the equivalent "Scheduled Tasks" feature under Windows.
<dash> jbowtie: aah.
<dash> well, i'm primarily familiar with using pageant
<dash> apparently that can run without having to be logged in?
<jbowtie> dash: Hmmm...I'll have a look, see if bzr interacts with that at all.
<dash> jbowtie: if you're using plink, then it does.
<dash> http://wiki.bazaar-vcs.org/Bzr_and_SSH
<jbowtie> dash: OK, thanks for that, will have a read.
<jbowtie> dash: Looks like it will work, just need the scheduled task to launch pageant before running bzr.
<jbowtie> So now I can pull the latest code from Team Foundation Server and push it to our bazaar mirror.
<dash> i know some guys who will love you forever if you can make bzr pull from TFS.
<jbowtie> dash: I've already done that, just waiting on the lawyers to approve releasing the plugin.
<jbowtie> dash: Right now I'm working on getting push to work as well.
<jbowtie> Hint for anyone who wants to try it themselves: it's just SOAP messages, look at opentf source for details.
<jbowtie> Which I had no hand in, I just looked at bzr-svn and opentf to figure out how to make it work. Just a couple hundred lines of code.
<Lor> Funny that there is Tree.iter_entries_by_dir (with a funny traversal order), but no plain depth-first iter_entries
<Lor> (which the inventory has, there's just no wrapper in the tree)
<Lor> Bah. iter_changes uses the funny order, whereas I'd like depth-first.
<jbowtie> First successful bzr push to Team Foundation Server. Now to get round-tripping details squared away.
<Peng_> Congrats.
<jbowtie> Yes, I'm very happy. Only thing that will be sweeter is getting the Legal stamp of approval so I can push to Launchpad.
<jbowtie> But at least I am no longer shackled to TFS.
<bendj> I think I've hosed my bzr install ... when I, now, 'bzr commit -m "whatever"', i get: "bzr: ERROR: Unable to determine your name.  Please, set your name with the 'whoami' command.".  *Was* working a few hours ago :-/
<bendj> Where do I look to fix what?
<jbowtie> bendj: I'd start by looking at the ~/.bzr directory (or Windows equivalent)
<jbowtie> bendj: Sorry, I mean .bazaart
<jbowtie> bendj: Curse my fat fingers!  That's ~/.bazaar on Linux/Mac
<jbowtie> Usually the info is in the ~/.bazaar/bazaar.conf file.
<bendj> jbowtie: sure.  it's (a) there, and (b)  bazaar.conf & authentication.conf are as they've been since 3/25/2010 -- untouched.
<jbowtie> bendj: Does the output of "bzr whoami" match the contents of bazaar.conf?
<jbowtie> bendj: The other place where details can be stored is in the branch itself, the .bzr/branch/branch.conf
<bendj> jbowtie: --> bzr: ERROR: Unable to determine your name., as well.  looking in the branch files ...
<fullermd_> Well, if it's giving that, it means it's not set   :p
<bendj> fullermd_: sure, trying to figure out "what changes" in the last four hours ...
<fullermd_> Update bzr?
<jbowtie> bendj: If your bazaar.conf hasn't changed *and* it doesn't contain whoami information, then the details were probably in the branch.conf file.
<jbowtie> bendj: If your bazaar.conf contains whoami information, then something's wrong with your bzr install.
<bendj> branch.conf is unchanged since 4-29 -- and contains only "parent_location = ../../repos/pf6/trunk/"
<fullermd> (anyway, less 4 hours, more a week)
<bendj> jbowtie: and, bazaar.conf contains:
<bendj> [DEFAULT]
<bendj> launchpad_username =
<bendj> bendj
<thumper> bendj: you want a line like: email = Tim Penhey <tim.penhey@canonical.com>
<thumper> bendj: that comes from whoami
<fullermd> I hate having a VCS that makes me change my name, though   :(
<bendj> thumper: yup.  and with that, i'm back in business.  no *$*^ clue what changed, or why.  thx!
<fullermd> You updated your bzr.
<brylie> Is there a way to append to a commit rather than creating a new revision?
<fullermd> Not as such.
<fullermd> You can _replace_ the commit with a new one.
<fullermd> (though that's decidedly unfriendly when somebody else might have already seen the existing one)
<brylie> OK, well I'm the only one working on it right now.
<tsp> How can I bzr revert on a lightweight checkout? It keeps saying readonly transport
<fullermd> brylie: Well, that saves you the worry   :)
<fullermd> tsp: That may be a bug...
<tsp> What can I do to work around it?
<brylie> fullermd, so I would say 'bzr replace'? Would 'bzr uncommit' be a reasonable choice since I will just re-commit directly afterwords?
<fullermd> brylie: Yes, that's what 'uncommit' is for.  It backs you up to your state before the last commit (e.g., mv's and add's and file edits are all sitting waiting to be committed)
<fullermd> tsp: Seems like it may be fixed in newer versions...  what are you running?
<tsp> 2.1.1
<fullermd> Hm, probably not in a release yet, though.
<tsp> am I a bit too old?
<fullermd> Well...   sorta.  Too old to get the bugfix.  But all releases are at the moment.
<tsp> Is bzr branch that much different? do I just bzr pull instead of bzr up?
<fullermd> You could grab bzr.dev or the 2.1 branch (or 2.0, but that's a step backward) and use that.  I don't know if there are snapshot tars/packages made...
<fullermd> Well, if you had a local branch, you wouldn't hit that bug, since it's about locking the branch (which it shouldn't do, but you don't notice locally)
<GungaDin> what happens when you specify you'd like to merge just a directory?
<GungaDin> will that show in the history?
<GungaDin> any limitations on that?
<tsp> Can I convert a lightweight checkout to a branch checkout?
<fullermd> GungaDin: No (to your middle question)
<fullermd> tsp: "branch checkout" is kinda nonsensical.  I think 'reconfigure --tree' will turn it into an independent branch in place.
<tsp> Testing now. I didn't really want to go the checkout route again if I didn't have to
<fullermd> Why not?
<fullermd> If it's a question of time or network bits, reconfigure isn't going to use any less than a fresh 'branch', since it has to do all the same work.
<fullermd> Well, it'll probably use a smidge less time, since it doesn't have to build a new WT, but that's noise unless it's a HUGE tree.  And even then, it's probably noise relative to the history that implies.
<tsp> I've got a pile of changes I've made to what I think are ignored files/directories that are required for this thing to build. Wuld reconfigure work here?
<fullermd> I think it should leave all the WT stuff alone, yes.
<fullermd> There are Stupid Manual Tricks you could do to have those waiting in a fresh branch, but reconfig is a lot easier and less fidgety than trying.
<eagles0513875> hey guys im having issues trying to check out from a bzr branch on launchpad
<eagles0513875> :( i loged in with my lp id yet im not commiting anythign to the bzr repo i get the following
<eagles0513875> jonathan@Eagle1:~/mixxx$ bzr co lp:mixxx
<eagles0513875> Permission denied (publickey).
<eagles0513875> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<eagles0513875> any idea why im getting that for a simple check out?
<spiv> eagles0513875: for some reason your SSH key isn't working
<spiv> eagles0513875: what's your LP id?
<tsp> if I just do bzr reconfigure --tree, I get an error about network object and a traceback. I can't copy/paste it right now
<eagles0513875> spiv: for a simple check out i need an ssh key
<Peng_> eagles0513875: To use SSH you do.
<eagles0513875> spiv: need to get it back on this computer :( have it backed up on a cd
<eagles0513875> Peng_: is there a way i can checkout without needing ssh or once im logged in with my lp id it is required that i use ssh
<spiv> eagles0513875: you could create a new one
<Peng_> eagles0513875: For a simple checkout you can use HTTP if you want to, but since you ran launchpad-login, Bazaar will use SSH by default.
<Peng_> eagles0513875: Sure, go to Launchpad, find the project, username and name of hte branch, then do "bzr co http://bazaar.launchpad.net/~user/project/name".
<eagles0513875> Peng_: there a way to logout
<Peng_> eagles0513875: $EDITOR ~/.bazaar/bazaar.conf and remove the launchpad_username line.
<fullermd> tsp: Mmm.  Dunno there.
<GaryvdM> poolie:http://imagebin.org/96665
<mwhudson> jelmer: did a bzr-git upgrade get CPed?
<jelmer> mwhudson: not yet
<mwhudson> jelmer: so how did the dulwich import start working again?
<jelmer> abentley: hey
<abentley> Hi.
<jelmer> abentley: Is there a better way of figuring out the revisions to push than using iter_ancestry ?
<jelmer> (with only a graph object for the source repo available and a way to check if the revid is present in the target)
<abentley> I'm not sure the context.  Graph.find_difference might be appropriate.
<jelmer> abentley: I'm trying to figure out the set of revisions I need to push to a remote git repo while knowing the remote heads
<abentley> jelmer, iter_ancestry seems perfect, then.  Why do you want something else?
<spiv> jelmer: native fetch uses a breadth first searcher
<spiv> jelmer: see _walk_to_common_revisions.  It's basically just iter_ancestry
<spiv> Well, it's like iter_ancestry plus some bits to avoid iterating bits of the graph related to the heads we know we have, I guess.
<jelmer> abentley: I have multiple stop revisions at the moment and am browsing back all the way to null: atm
<jelmer> spiv: thanks
<abentley> jelmer, yes, spiv's suggestion sounds good then.
<jelmer> abentley: great, thanks
<jam> mwhudson: what's your schedule look like today?
<mwhudson> jam: fairly open
<mwhudson> jam: tbh, i could probably spend all afternoon with you guys
<mwhudson> jam: do you have any more discussion time scheduled?  i didn't really have much to add to this morning's
<jam> mwhudson: we don't have anything explicit that i know about
<jam> usually we only do a little bit per day :)
<poolie> i might make a core-team mailing list
<jml> how do I get an SSH-based transport to look for its private key in a particular place?
<jml> the two answers I have now are terrible
<jbowtie> jml: If you get a good answer, let me know.
<jml> jbowtie, well, the good answer is "patch bzr"
<jml> jbowtie, but that's not an option for me right now.
<mwhudson> jml: for a start, use paramiko
<mwhudson> paramiko looks in $HOME/.ssh
<mwhudson> so you can override $HOME and life is good
<jml> mwhudson, yeah, that's what we are doing
<jbowtie> jml: On Windows, I use  "pageant.exe my.private.key -c bzr xxx"
<jml> mwhudson, that's one of the two terrible answers :)
<mwhudson> jml: openssh looks in .ssh in the user's home directory and finds the home directory by calling getpwent
<jml> mwhudson, the other is monkey-patching bzrlib.transport.ssh._try_pkey_auth
<mwhudson> (!!!)
<jml> mwhudson, good to know.
<mwhudson> jml: ah yes, i guess you'd looking at the codehosting acceptance tests?
<mwhudson> i was extremely unhappy when i found this out about openssh
<mwhudson> jml: you might be able to register a particular ssh vendor
<jbowtie> jml: I need to write a patch for adding NTLM auth to HTTP transport; I can look into the SSH transport while I'm at it.
<jml> jbowtie, that'd be great.
<jbowtie> jml: Do we know what the behaviour should be? Is that defined in a bug or patch somewhere?
<jml> no, sorry
<jbowtie> jml: No worries. I'll work something up and propose it.
<jbowtie> jml: Probably propose something like "key=file.key" in the auth.conf file.
<jml> jbowtie, well, I want to do this in a computer program, so I want parameters, not configs
<mwhudson> jml: environment variables are almost as good as parameters!
<mwhudson> (not really, obviously)
<jbowtie> jml: I hear you, I'll have a play this weekend.
<jbowtie> Speaking of NTLM, is there anyone around who knows the HTTP transport code around?
<mwhudson> vila should be around
<mwhudson> although it's nearly lunchtime here
<jbowtie> mwhudson: Well, it's nearly midnight here so I'll probably miss vila.
<jbowtie> But that's all right, I can always write a patch for offline review. I just wanted to avoid breaking it in obvious ways.
<vila> jbowtie: I'm here
<vila> jbowtie: let me re-read the log
<vila> jbowtie: so, there is some code related to NTLM in urllib-based http client, you want to look in to bzrlib/transport/http/_urllib2_wrappers.py
<vila> jbowtie: and search for the NegotiateAuthHandler
<vila> jbowtie: the corresponding tests are in bzrlib/tests/test_http.py
<jbowtie> vila: I was looking to integrate the python-nltm auth handler.
<vila> jbowtie: that won't work, different designs
<jbowtie> vila: So I'm better off patching the NegotiateAuthHandler to work properly then?
<vila> jbowtie: (if that's the one I looked into months ago), i.e. some code may be reused, but you can't just plug it into ours
<vila> jbowtie: certainly
<jbowtie> vila: That's a shame if it can't be plugged in, works really well in my custom transport.
<vila> jbowtie: custom transport ? As in bzr transport ?
<vila> jbowtie: my knowledge may be obsolete, I'd be very happy to be wrong here !
<jbowtie> vila: Yes, I implemented a tfs+http transport for using Team Foundation Server as a foreign VCS.
<vila> jbowtie: hmm, is there a branch I can look at ?
<jbowtie> vila: No, not cleared by legal yet (which is why I haven't released plugin)
<jbowtie> vila: But all I did was create a custom opener with the python-ntlm auth handler.
<vila> jbowtie: ok, so *from memory* the problem was doing that wasn't allowing keeping the connection alive or something
<vila> jbowtie: which could have a dramatic impact on performance, but I may be wrong
<jbowtie> vila: Well my transport isn't bothering with keeping the connection alive, so might still be an issue.
<jbowtie> vila: But it gives me an angle to look into. I'll also look at what python-ntlm is doing differently than the Negotiate auth handler.
<jam> vila: , what's up?
<vila> jbowtie: it's handled transparently so the transport itself shouldn't have to care, but so is the auth.conf stuff etc
<jbowtie> vila: Yes, I made my own calls to the auth.conf stuff as well. So I think (hope?) it will integrate pretty cleanly.
<jbowtie> vila: But it sounds like there is probably a way forward either way.
<vila> vila
<vila> jbowtie: yes, this certainly sounds good
<vila> jbowtie: you can have a look at the existing tests to plug your auth handler there
<vila> jbowtie: I'm not sure there are enough tests here (especially since you'll need a dedicated auth handler in your case), but that should help
<vila> err, auth *server*
 * vila needs lunch ;)
<jbowtie> vila: That's the problem with MS stuff, hard to write a test suite when the other end of connection is an expensive server.
<mathbr> Hi. Is it possible to retrieve the argument of a CLI option within a hook?
<mathbr> Particularly --fixes in my case.
<mwhudson> mathbr: not in general
<mwhudson> which kind of hook are you writing?
<mathbr> For commit_message_template; Iâd like to add (Fixes #N) automatically if the --fixes CLI option is provided.
<spiv> mathbr: you should be able to see the revprops on the commit object
<mathbr> spiv: Exactly as you said. Itâs in there as 'bugs'. Thanks a lot. :-)
<mathbr> Got it working, thanks.
<bialix> vila: ring a bell
<parthm_> jam: i experimented with the smart server source (as in source-sink). there doesn't seem to be a good way to do estimation and show progress. the server just hands over the streams.
<parthm_> jam, lifeless: the current patch looks like https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483
<parthm_> seems to work fairly accurately.
<vila> bialix: :-P
<lifeless> kfogel: hey
<lifeless> kfogel: did you see my ping ?
<kfogel> lifeless: no, machine was fscking
<kfogel> lifeless: what's up?
<lifeless> rob savoye is pinging me
<lifeless> would like a progress report on savannah, I think :)
<LeoNerd> Does anyone have any hints/suggestions/etc... for how to build debian packages from source/control/etc... stored in bzr..?
<LeoNerd> Ideally I'd love to just be able to grab a checkout, run .. something... and have it Just Know it's trying to build version, say, 0.01~bzr123
<dash> there's bzr-builddeb
 * LeoNerd reads
<lifeless> LeoNerd: bzr build-deb is your answer
<LeoNerd> Hrrmmm.. This is almost looking a little too fancy..
<LeoNerd> My source dir. is a CPAN module distribution, so that already has its own set of metadata and so on..
<LeoNerd> dh-make-perl can already cope with that, to build src/bin .deb files..
<cbz> hmm
<cbz> is there any way of changing the diff algorithm used by the qbzr plugin?
<GaryvdM> cbz: unfortunately not
<GaryvdM> cbz: You can configure it to launch a external diff.
<cbz> does it use the same algorithm bram cohen outlines?
<cbz> on his blog
<GaryvdM> cbz: run qconfig, and see diff section
<cbz> okay
<cbz> it just seems rather worse than the diff used elsehwere
<cbz> in terms of not ignoring whitespace and such
<lifeless> kfogel: sorry for running; missed any reply ;)
 * LeoNerd further considers if bzr-builddeb is best...
<LeoNerd> Anyone much experience on it who could answer questions?
<lifeless> LeoNerd: if you're buildding deb packages, yes.
<GaryvdM> cbz: qdiff uses the same algorithm that bzr diff, and according to jam, we do do what bram cohen suggests.
<cbz> hmm
<LeoNerd> lifeless: OK.. And is it going to put the  ~bzr123  on the version number?
<LeoNerd> That's -the primary- feature I was looking for
<LeoNerd> To the point that I was considering just   $(shell bzr revno) 'ing in the Makefile somehow
<LeoNerd> The bzr branch stores the native upstream source (possibly as well as the debian/ dir)
<LeoNerd> the branch should be releaseable at any time, into a debian source/binary package, even without declaring a new official upstream release
<LeoNerd> I want to do that therefore, by building $VER~bzr$REV as the debian package version
<kfogel> lifeless: no substantive reply -- I was just answering your ping
<lifeless> LeoNerd: you could use bzr-builder for that
<lifeless> LeoNerd: however it generates native packages
<lifeless> get-upstream-source is the official way for doing what you're doing
<LeoNerd> Well.. the bzr branch does.. sortof.. contain the official upstream source.
<LeoNerd> at least, it contains all the files.
<LeoNerd> The tarball is the one that perl's "./Build dist" makes though; for .orig.tar.gz
<LeoNerd> lifeless: So.. Is this doable..? I want some kind of setup that the bzr branch can always be built into .debs, possibly indirectly via CPAN, but doesn't have to...
<LeoNerd> but I specifically don't want ot have to declare new upstream version all the time..
<LeoNerd> .oO( Ideally if it understood my 'RELEASED ver' bzr tags that would be awesome)
<lifeless> LeoNerd: bzr-builder and/or bzr-builddeb should be able to brin this all together for you
<LeoNerd> Righty
<poolie> vila: sent to pqm
<vila> poolie: YES !
<vila> poolie: thanks :)
<deviantintegral> hi; is it possible to define an alias of a repository string? I'd like to alias bzr+ssh://.../ into something shorter
<poolie> deviantintegral: there's a plugin for that; i think called aliases or bookmarks
<deviantintegral> poolie: thanks! bookmarks was the word I needed
<rbriggsatuiowa> how can I find all the commits for a particular user in a log?
<Kobaz> is there an equivalent to svn externals
<TresEquis> Kobaz: http://wiki.bazaar-vcs.org/NestedTrees
<TresEquis> which is kind of stalled
<mathbr> Hi again. Iâm no exactly sure but is there a way to modify revprops of a commit based on the commit messageâs content? Kind of what commit_message_template allows for, but inversed.
<Phoenixz> I have 2 diferent project that both use the same libraries. Both projects are in BZR and I want that when libraries are updated in one projects, that I can send the changes to the other, and vice versa. Problem is, these projects also have programs which changes I DON'T want to mix. How can I do this?
<Phoenixz> is it possible to do a merge with a certain part of the tree masked with DONT MERGE or something?
#bzr 2010-05-14
<igc> morning all
 * fullermd waves at igc.
<Peng_> Good morning.
<igc> hi fullermd!
<fullermd> It's so peaceful 'round here while everyone else is off summitting  ;)
<jbowtie> What does an uncommit actually do?  I had a pull get aborted last night and repository is in inconsistent state.
<jbowtie> Returns true for has_revision(X) but doesn't actually contain that revision.
<jbowtie> I'm wondering if I should try and salvage the repository or not.
<Peng_> uncommit doesn't do anything to the repo, just the branch.
<jbowtie> Peng_: Unfortunate for me. Maybe I can cheat and try to add the revision again, it's not in a consistent state so it might work.
<Tim-7967> hi, can somebody help me figure out whats wrong with my copy of Bazaar?
<thumper> Tim-7967: what's up?
<Tim-7967> when I type bzr init I get this: http://pastebin.com/HVtDw2aZ
<Tim-7967> obviously its a problem with Python on OSX
<Tim-7967> but I've tried installing Bazaar through the DMG and MacPorts... and neither seem to work and produce the same error
<thumper> ok, so you are using OSX?
<Tim-7967> yes, 10.6 Snow Leopard
<thumper> and how did you install bzr?
<Tim-7967> originally through the Disk Image available at the website
<Tim-7967> then I tried it through MacPorts after that error showed up and had the same results
 * thumper knows nothing about OSX
<thumper> ok
<thumper> those errors are saying that some plugins aren't working
<Tim-7967> think of screwed up BSD, and then you have something to reference too :P
<thumper> but that won't stop bzr working
<thumper> I'll just be noisy
<thumper> the plugins should be installed in ~/.bazaar/plugins
<thumper> if they are local
<thumper> are they local or system plugins?
<Tim-7967> lemme check
<Peng_> jbowtie: What format repo is this? It should not be possible for it to become inconsistent.
<thumper> bzr plugins -v
<Peng_> jbowtie: Hey, could you take a backup before you do anything to it, in case someone wants to debug it?
<Tim-7967> I would think it would be system as its refering to the Library folder
<Tim-7967> Yes, they are system plugins
<thumper> which version of bzr are you using?
<Tim-7967> bzr 2.1.1
<thumper> hmm...
<thumper> did you install the pipeline and rebase plugins separately?
<Tim-7967> no
<Tim-7967> they *should* have been installed automatically
<Tim-7967> I selected install all when i was installing Bazaar
<jbowtie> Peng_: Will see, might have too much internal data in it to pass around though.
<thumper> it looks then like there is a bug in the installer as the versions it is installing aren't compatable
<thumper> an email to the bazaar mailing list may be in order
<thumper> I don't know who looks after the OSX bits
<thumper> or a bug in Launchpad
<jbowtie> Peng_: It's a 2a repo, but it was converting from a TFS repo; probably a bug in my TFS code caused the abort. But would have thought revision would not have committed in that case.
<Tim-7967> ok, trying out the beta one and seeing if it makes any differance
<thumper> ok
<Tim-7967> "*** Bazaar has encountered an internal error.  This probably indicates a
<Tim-7967>     bug in Bazaar.  You can help us fix it by filing a bug report at
<Tim-7967>         https://bugs.launchpad.net/bzr/+filebug
<Tim-7967>     including this traceback and a description of the problem."
<Tim-7967> maybe not :P
 * Tim-7967 casually ignores the additional warnings and downgrades to stable release branch
<Tim-7967> -_-
<Tim-7967> I've had more problems with bzr then git, cvs, svn and several other package managers combined :P
<Peng_> jbowtie: OK, import bugs could create a wildly invalid repo, so that could be it..
<Tim-7967> I'll wait a little while for some bugs with bzr and OSX 10.6 to be fixed before using it
<Tim-7967> :/
<Tim-7967> did somebody just bring the launchpad site offline?
<Tim-7967> "Firefox can't find the server at launchpad.net."
<Peng_> Tim-7967: WFM
<Tim-7967> WFM?
<Peng_> Works For Me
<Tim-7967> it must have been my DNS
<Tim-7967> I just flushed it and it was fine :P
 * Tim-7967 curses OpenNIC and its tendancy to screw up DNS every 3 hours
<Peng_> Then why use it?
<Tim-7967> because its awesome
 * Tim-7967 also points to cloak
<Peng_> Heh.
 * Tim-7967 exclaims!
<Tim-7967> I've had my project for ~1day... working on uploading stuffs
<Tim-7967> and somebody already forked it 0_o
<Tim-7967> https://launchpad.net/nyx
<thumper> what do you mean someone forked it?
<thumper> Tim-7967: oh you have startcommander-x?
<Tim-7967> *StarCommanderX :P
<Tim-7967> I need a new name for it anyways
<Tim-7967> I used to call it starbot
<Tim-7967> and did it in PHP
<Tim-7967> it always screwed up though
<rockstar> Holy crap.  The user experience for bazaar in Windows is terrible...
<jbowtie> rockstar: Really? I've had excellent experiences with it.
<jbowtie> rockstar: Anything specifically bothering you?
<fullermd> Well, it IS on Windows...
<rockstar> jbowtie, lots of things.  I'll file bugs and whinge to jam in the morning.
<parthm> jam: http://pastebin.com/CZBzX4Lq
<jam> parthm: http://pastebin.com/eLuhbYR2
<Peng_> "bzr info nosmart+lp:bzr" is shorter
<Peng_> parthm: 2a MySQL? :D
<parthm> Peng_: Yeah :) ... I wanted one for testing
<parthm> Peng_: I couldn't upgrade it locally so I push it into +junk and launchpad did it nicely.
<Peng_> Pah, kids these days. I did it locally before LP supported that.
<Peng_> Not literally locally. I got a VPS with 8 gigs of RAM...
<parthm> Peng_: Nice :)
<Peng_> branch/pull themselves weren't that bad, but "bzr check" used like 5 gigs.
<Peng_> Fun times.
<jelmer> Peng_: yeah, check definitely needs some work..
<jelmer> lifeless: let me know when you have time to look at foreign stuff :-)
<lifeless> jelmer: come on by, the waters warm
<Peng_> Version control slash fics?
<jelmer> lifeless: *nod*
<fullermd> Peng_: Isn't that what rebase is for?   :p
<spiv> lifeless: https://code.edge.launchpad.net/~spiv/ubuntu/lucid/paramiko/address-families-579530-lucid/+merge/25297 :P
<lifeless> spiv: your next step is to ping james_w or another main committer
<spiv> lifeless: ta
<mwhudson> jam: ooh, we can delete loggerhead.apps.config now i think
<mwhudson> this makes me happy, because that is _horrible_ code
<jam> mwhudson: because it was used only in start-loggerhead?
<mwhudson> jam: right
<jam> It is  still in the test suite, but we can fix that :)
<mwhudson> oh
<mwhudson> well yeah
<jam> I'm trying to clean it up now, because there were a lot of places that weren't passing 'cachepath' which is no longer optional
<jam> and its being a little bit tricky
<jam> but I'll get there
<jam> (we have a temp dir to put the work in, just having some difficulty cleaning up after each test)
<jam> mwhudson: but yes, only one reference to Root is in the test suite that I can find
<jam> mwhudson: oh, and that ref actually isn't ... referenced :)
<jam> 'loggerhead.tests.test_simple.test_config_root" doesn't seem connected to anything
<jam> \o/ for delete paths
<Peng_> jam: BTW, I haven't looked into this much at all, but I occasionally see a KeyError in get_revno.
<Peng_> Haven't pulled the latest code -- maybe it changes things.
<jam> the *latest* code is currently broken, but I'm finishing up some edges
<Peng_> Heh.
<jam> I've been working on it with mwhudson this week
<jam> I just merged history-db code into loggerhead so it isn't an external dependency
<jam> and some other stuff like that
<Peng_> I'm without email at the moment, which makes it hard to keep up with things, but ping me on IRC when you have something.
<jam> k
<Peng_> Thanks. :)
<Peng_> Haha, I just noticed this on the line above the KeyError: # TODO: Should probably handle KeyError?
<lifeless> jelmer: https://lists.canonical.com/archives/bazaar/2009q2/059263.html
<fstxx> imported from CVS, how to add more changes? We use cvs2svn to import a project from CVS. Unfortunately, som people continued in CVS, and others used bazaar.
<amanica> abently I get the following when running `bzr help commands` today : ValueError: No help message set for <bzrlib.plugins.pipeline.commands.cmd_store object at
<lifeless> amanica: interesting; it means a proactive code check is catching a plugin without help on a command
<lifeless> please file a bug on bzr-pipeline
<lifeless> preferrably with a patch :)
 * fullermd filed that on -keywords last night.
<hopeseekr> Hi.  I have a post-commit.sh designed for svn.  It uses svnlook (e.g. svnlook log -r2 only returns the commit message). Is there a plugin for BZR that provides the same functionality?
<mkanat> hopeseekr: What is your post-commit script actually doing?
<hopeseekr> it's only 3 lines
<hopeseekr> http://pastie.org/960073
<hopeseekr> i guess the format i want it in is Author RevNo "Commit Message" "changed files"
<hopeseekr> actually, i have no idea how to make a bzr post-commit hook, so this may all be moot
<lifeless> its done via python
<lifeless> you write it as a small script in ~/.bazaar/plugins
<lifeless> there are some examples
<hopeseekr> o great; i absolutely suck @ python
<hopeseekr> i remember tyring to fix a *simple* bug in bzrweb; no go
<jam> Peng_: so lp:~jameinel/loggerhead/history_db should be usable, and no longer depend on having bzr-history-db installed. I still have some more cleanup, and I know at least one view is broken. But I'm getting there.
<hopeseekr> OK!
<parthm> jam: https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483
<fstxx> imported from CVS, how to add more changes? We use cvs2svn to import a project from CVS. Unfortunately, som people continued in CVS, and others used bazaar.
<fullermd> cvs2svn doesn't support incremental conversion.
<fullermd> I s'pose it's possible that it will output stuff similar enough that bzr fast-import can do incremental updates; I think it has some level of support for that.
<fullermd> But I wouldn't count on it.
<fstxx> fullermd: I was thinking I could do another import to new branch in bzr, and then copy changesets from the old one
<fullermd> Well, the new branch would be unrelated.  Maybe rewrite could do something with that; I don't know.
<James7> Hi does anyone use Bazaar on Mac Snow Leopard?
<James7> and if so, how can I uninstall it if the uninstaller doesn't work on Snow Leopard?
<fstxx> fullermd: yes, metadata-wise it would be unrelated. I thought I could generate patches in one branch, and then apply them in the other
<fstxx> something like what a gatekeeper would do
<fullermd> Yeah.  It's possible something in the rewrite plugin can help automate that.
<James7> Erm, no one?
<bialix> abentley: re problem with encoding of diff header again. from DiffText.diff_text method can launch either internal_diff or external_diff function. but external one has no path_encoding argument, so new code to pass the encoding down the layer is failing with external differ. will it be ok to just add path_encoding argument to external_diff function, although not really use it?
<poolie> lifeless: re your blog post
<lifeless> poolie: yes ?
<poolie> hi
<poolie> just thinking about your useFixture thing
<poolie> to me 'fixture' is the whole environment where a test runs
<poolie> so it's a bit strange if you can assemble some of them
<poolie> i don't know if this is the orthodox meaning
<bialix> poolie: where are you right now?
<poolie> bialix: cocobolo 3 on the ground floor
<bialix> k
<poolie> will be back abotu 5pm
<poolie> lifeless: you should +1 my blog comments
<dwt> Hi, I'm trying to see what changes a remote repository has
<dwt> I seem to remember that 'bzr incomming location' was it
<dwt> but that seems not to work
<dwt> and searching the docs doesn't seem to give enything?
<fullermd> missing
<dwt> ha
<fullermd> 'incoming' is hg I think.
<dwt> confused by differences again
<dwt> thanks fullermd
<dwt> on a related question, is there a fast way to find the bzr branch root?
<dwt> I'm currently using bzr info and then parse out the branch root:
<dwt> but that is way too _slow_ to be in my prompt
<fullermd> Well, there's 'bzr root'.
<fullermd> But I suspect pretty much anything will be too slow to be in a prompt.
<fullermd> Well, unless you load bzrlib into your shell so there's no startup overhead  ;)
<dwt> fullermd: yeah, pretty much
<dwt> and on osx I don't have bzr-service which loads it in the ram for me.
<dwt> Or I'm missing something
 * dwt thinks I could try storing the bzr source on a ramdisk
<fullermd> Well, I'd think that after running it once or twice, it would all be in cache anyway.
<fullermd> It's the python startup overhead that gets you.
<dwt> yeah, I pretty much think so
<dwt> I wonder how the mercurial guys get this
<dwt> they must be bitten by the python startup overhead too
<dwt> but somehow it's much less of an issue there
<dwt> my prompt pretty much takes a second to build (bzr) and about one order of magnitude less time in mercurial
<fullermd> Well...  a quick bit of find'ing and wc'ing says that my installed hg has around 17k lines of .py files, and bzrlib is 101k.
<fullermd> bzr's all in cache here, and 'bzr rocks' consistently takes ~110ms (and I don't exactly have a pokey box)
<fullermd> bzr help is about the same; 110-120.  hg help is 30.
<idnar> fullermd: they both take around 300ms here
<idnar> (hg help and bzr help, that is)
<idnar> Python startup pretty much sucks
<idnar> I'm guessing my local python configuration is adding some overhead that you don't have, dwarfing the actual differences between bzr and hg
<chx_> hi. i would like to do  bzr merge -c 15525,15526,15528,15532,15535 ../feature_pref_edition_block/ but it does not like me doing that :)
<chx_> or is there an interactive merge tool where i pick hunk by hunk maybe?
<dash> chx_: you can only do one rev or range of revs at a time
<TresEquis> chx_: use a bash for loop?
#bzr 2010-05-15
<chx_> see the problem is that there are conflicts in earlier which go away later
<chx_> but dont worry
<chx_> i can do a few manually
<dash> chx_: wanting to pull in a bunch of random revisions like that is a sign you're going to suffer no matter what :)
 * chx_ suffers.
<dash> how did this happen?
<chx> dont ask.,
<dash> oh well too late
<chx> i have exceptionally talented co-workers
<dash> Heh
<dash> so do the people in my office... ;)
<chx> they got their pink slips already worry not
<chx> i am just cleaning up the mess
<chx> this is what happens when you hire so many people for a huge project in such a short tim
<chx> you get good people... and some only good in destruction
<bialix> lol
<chx> some ppl managed to play so nice tricks with a combination of switch, bind and unbind that if you just merge in their branch then trunk changes get reverted
<chx> so i need to cherrypick the revisions that actually make progress
<chx> mmmm merge -i
<chx> is it going to tell me that applying something would end up in a conflict?
<chx> oh it DOES
 * chx hugs merge -i
 * TresEquis wishes he could give pink slips to a couple of OSS community members
<Peng_> jam: Which view is broken?
<Peng_> jam: FWIW, I just merged history_db into your integration branch, fixed some conflicts, and pushed it to lp:~mnordhoff/loggerhead/jam-integration
 * Peng_ dies of conflictitis
<deviantintegral> anyone here using bzr-svn on OS X? It doesn't look to be saving SVN credentials, so it asks for a password for every HTTPS operation.
<deviantintegral> anyone have a good link to an explanation of why you need bzr join/split?
<maxb> Because sometimes you want merge two projects into one, or split one project into two?
<deviantintegral> maxb: ok. so right now I'm dealing with a vendor branch. With SVN, an svn cp is enough, but a bzr branch within an existing branch is more like an svn:external?
<maxb> A bzr branch within a bzr branch is most like checking one unrelated svn working copy out within another
<deviantintegral> maxb: awesome, thanks, exactly what I was looking for
<maxb> it is? That's a cumbersome way to work
<maxb> Mainly because it means each person has to branch all the branches and arrange them locally manually
<deviantintegral> perhaps I'm not explaining it properly - the directions I have are http://pastebin.com/9zCPAHhx
<deviantintegral> but if there's a better way to do it, I'd be curious to know
<fullermd> 'join' is just a little syntactic sugar around 'merge'.
<deviantintegral> so I could do the same thing by doing a bzr merge into my tree
<deviantintegral> that makes sense
<fullermd> Plus a little extra work to move the 'root' of that new tree off to where you want it, yes.
<fullermd> You'll use merge to get later updates.
<deviantintegral> nice
<mathrick> jelmer: hi
<mathrick> mathrick@hatsumi:~/elisp/dist$ bzr get http://github.com/remvee/android-mode.git
<mathrick> bzr: ERROR: HTTP Error 406: Not Acceptable
<mathrick> what gives?
<mathrick> also I got a crasher when I try to get the same via git+ssh://
<mathrick> woah there: http://pastebin.com/7h1rLN6q
<mathrick> that looks bad
<mathrick> bah, it's my ~/Dev/ shared repo acting up again
<mathrick> I hate it
<fullermd> Oh yeah?!  Well, it hates you too!
<mathrick> heh
<mathrick> well, I don't make its life miserable, so it has no reason to
<fullermd> Did you remember its birthday?
<mathrick> :)
<TresEquis> mathrick: send it some flowers
<TresEquis> or maybe chocolates
<jelmer> mathrick: hi
<mathrick> jelmer: hey
<mathrick> I updated bzr-git, and the difference is that now it stalls and does nothing instead of erroring out
<jelmer> mathrick: which repo are you trying to fetch?
<mathrick> http://github.com/remvee/android-mode.git
<jelmer> bzr.dev branch git://github.com/remvee/android-mode.git
<jelmer> works fine here
<mathrick> hmm
<mathrick> well, I'll assume it's something wrong with 2.1 then
<jelmer> mathrick: are you fetching over git:// or http://
<mathrick> jelmer: http://
<mathrick> with git:// it works fine
<jelmer> mathrick: http:// is really really slow for git
<mathrick> jelmer: I just used it because that was what github gave me by default
<jelmer> mathrick:  this is a github issue I think, e.g. try accessing http://github.com/remvee/android-mode.git/info/refs.
<mathrick> jelmer: loads OK in the browser
<lifeless> hai
<mathrick> jelmer: btw, did you have the time to look into that bug with bzr-git getting confused if it's pointed at a URL with .git's content at the toplevel?
<jelmer> lifeless: hey
<mathrick> that is, bzr: ERROR: Not a branch: "http://common-lisp.net/project/parenscript/git/parenscript/"
<jelmer> mathrick: doesn't work here..
<mathrick> jelmer: interesting
<mathrick> then it's probably github being at fauly
<mathrick> *fault
<jelmer> mathrick: Is there a bug about that?
<mathrick> nope, I just poked you in here, but then got distracted and forgot to file it
<mathrick> at least I don't think there is one
<jelmer> mathrick: please file one, I don't remember everything people say to me on irc :-)
<mathrick> you should :)
<mathrick> but ok, will do
 * digitalz Discounts!! Our Special Limited Time Offers Up To May,22!!!New BranD!! Notebooks,Plasma and LCD TV's.Buy your electronic needs at our unique prices. Laptop Sony VAIOÂ® VGN-FW590FFD-575,57$!!!Apple MacBookÂ® Air MC234LL/A-695,27$!!! http://www.elplace.com/
<knittl> hi. is there an easy way to inspect bazaar's storage format?
<Peng_> Inspect how?
<Peng_> And...which one?
<knittl> all of them. but good point, bazaar has changed its format several times
<knittl> git has object with hashes as names, hg has debug*, i'm looking for the bzr counterpart
<Peng_> knittl: dump-btree is nice for the btree-format indexes.
<knittl> what path does it expect?
<knittl> because . makes it crash :D
<Peng_> knittl: A btree index file. Such as .bzr/repository/pack-names
<knittl> i'll look into it. it's a good starting point. thank you
<Peng_> LUNCH! /me vanishes in puff of smoke
#bzr 2010-05-16
<BlindWolf8> Hello?
<Peng_> yo
<BlindWolf8> Hi Peng, how are you?
<Peng_> Awesome! At least I think so. The sleep deprivation may have driven me insane!
<BlindWolf8> Hahaha, that's always fun.
<BlindWolf8> Do you think that your lack of sleep would hinder your Bazaar knowledge? :-P
<fullermd> Sleep deprivation helps you cobble the muskrat more clearly.
<Peng_> BlindWolf8: Not yet. Much.
<BlindWolf8> Hahaha, I guess it depends on how many days you've been awake.
<BlindWolf8> OK, I've been working with Bazaar trying to get it setup with my webserver.
<fullermd> Oh, heck, if you can measure it in DAYS, it barely qualifies as deep sleprivation yet...
<BlindWolf8> I was using it this morning when *I* was sleep deprived, and later today when I was rested.
<Peng_> Not very long, actually. Umm, 29 hours.
<BlindWolf8> I think the most I've been up is close to 48
<BlindWolf8> I know between hours 22-24, I start to get sleepy.
<Peng_> I did exactly 47 hours a few months ago, but I got bored. And hungry.
<BlindWolf8> If I can get over that hump, I shoudl be good to go for a bit more
<BlindWolf8> *should
<Peng_> I usually stay up longest when I didn't sleep enough the previous night.
<BlindWolf8> Yeah, I hear ya.
<BlindWolf8> Anyway, do you guys have any suggestions as to how to setup Bazaar with a webserver? I got SSH and everything, but Bazaar just doesn't like what I'm doing for some reason. Also, I can't install Bazaar on the server (Shared)
<Peng_> BlindWolf8: You can just use dumb HTTP. Point Apache to a directory and tell it to serve away.
<Peng_> BlindWolf8: You've got SSH even though bzr isn't installed? You're using sftp?
<BlindWolf8> I've owned a full-blown server in the past, and I don't have the money/need right nowt o pay for a dedicated box
<Peng_> ....VPS? :D
<BlindWolf8> It's a HostGator Shared box...not a VPS
<BlindWolf8> they give us FTP/SFTP/SSH
<BlindWolf8> but not root :-P
<fullermd> It's about the 5th day that things really start getting interesting...
<Peng_> I mean, get a VPS. :D
<BlindWolf8> Yeah, I had a professor in my undergrad in college...he was in the army
<BlindWolf8> they had him sleep deprived...the guy thought the officer's shoes were rabbits
<BlindWolf8> :P
<Peng_> Some days, I think it might be interesting to try severe sleep deprivation. Other days, I think intentionally hurting myself is a bad idea...
<BlindWolf8> yeah, losing your mind is normally a Bad Thing.
<Peng_> And I'm already a little off.
<fullermd> Eh.  I don't think I'd really miss it...
<Peng_> BlindWolf8: Does SSH give you access to Python and GCC?
<BlindWolf8> lemme check...it should...
<Peng_> BlindWolf8: If so, with some work, you could install Bazaar in your homedir, but it's probably not worth it. Dumb HTTP and SFTP work fine; they're just slow.
<BlindWolf8> whoa, wait...gcc? nah
<Peng_> BlindWolf8: GCC is optional. Without it, performance will be suckier, though.
<Peng_> THe shared host I use gives access to GCC.
<BlindWolf8> Yeah, I was whoaing because I knew that they wouldn't and they did not...just confirmeded
<BlindWolf8> python, I have access to
<Peng_> Mostly use my VPS now...I have like bzr 1.0 on the old shared host...
<BlindWolf8> From what I've read, if I just want to work with another person on some files and use the server as the repo, I can just use the Shared repo method, right?
<Peng_> BlindWolf8: Shared repos are a storage optimization, not a concept.
<Peng_> Granted they can cause file permission issues when multiple people are working together.
<Peng_> Oh, no, it's 1.4. Well, bzr.dev around 1.4.
<Peng_> But my Python install got busted... Anyway, not the point!
<BlindWolf8> hahaha...you're getting sleeeeeeeeeeeeepy.........
<BlindWolf8> Hmmmm...
<BlindWolf8> Tried to connect via good ol' FTP, and Bazaar Explorer crashed
<Peng_> Ew, FTP. Please, use SFTP.
<BlindWolf8> I most def. would, but I will be sharing the code with one other person, and since I'm on a shared server, my only option would be to generate SSH keys instead of using passwords, as the Shared server only allows one SSH password for the user
<BlindWolf8> but, I am shying away from SSH keys sicne I am trying to make the setup of Bazaar as painless as possible
<Peng_> FTP is wrought of pain.
<BlindWolf8> Yeah...but does Bazaar Explorer support private/public keys?
<Peng_> No clue. Why wouldn't it?
<BlindWolf8> I don't see anything like it in the interface...I may have to go searching around for a plugin
<Peng_> Is this Windows? I avoid thinking about SSH on Windows.
<BlindWolf8> Yeah, the person I'll be working with are on Windows boxes...the server's Linux.
<thumper> sometimes I really hate line endings :(
<lifeless> ouch?
<thumper> lifeless: hi
<thumper> my cunning conflict detection of '>>>>>>>\n' in lines
<thumper> is failing due ot \r\n
<thumper> s/ot/to/
<thumper> lifeless: where are you?
<lifeless> bangkok
<lifeless> thumper: I think bzrlib has routines for that
<lifeless> thumper: follow the 'auto resolve' code paths.
<lifeless> boarding in a sec
<thumper> hmm...
<thumper> I'm thinking I should handle changing the http post param line endings to whatever the current file is using
<lifeless> yes
<lifeless> or rather
<lifeless> define a normalised canonical form
<lifeless> for all your files
<lifeless> use that, always.
<lifeless> bzrlib filters can help with that
<thumper> hmm...
<lifeless> I'll be in chch from ~1 tomorrow
<lifeless> if you want more involved discussion after work or whatever
<thumper> no point commenting now
<steffan> hi. installed the Bazaar bundle on 10.6 Snow Leopard but the uninstaller script fails - aparently this is already known but does someone have another script that can be used?
<steffan> hi. installed the Bazaar bundle on 10.6 Snow Leopard but the uninstaller script fails - aparently this is already known but does someone have another script that can be used?
<GaryvdM> Hi jelmer.
<GaryvdM> How much have you looked into rabitvcs
<GaryvdM> *rabbitvcs
<GaryvdM> jelmer: E.g. Do you know if they plan to implement neutral dialogs, or plan to reuse existing vcs specific dialogs?
<GaryvdM> jelmer: I'm interested in having a rabbit-bzr-qbzr, but there is no reason why not to also have a rabbit-bzr-gtk.
<GaryvdM> jelmer: I'm going to send a mail to their mailing list.
<bialix> hi GaryvdM , how's your trip?
<bialix> luks: so sad you did not made it :-(
<steffan> hi. installed the Bazaar bundle on 10.6 Snow Leopard but the uninstaller script fails - aparently this is already known but does someone have another script that can be used?
<GaryvdM> bialix: Hi. Back at home. Quite tired.
<GaryvdM> bialix: So good to meet you.
 * bialix tired too, slept all day
<lifeless> morning
<AdamDV> afternoon
<steffan> anyone using Snow Leopard with Bazaar?
<cbz> i didn't realise that bzr by default downloads the remote repository in the same repository format it is stored on the remote side
<cbz> is there a reason for this?
<steffan> anyone using Bazaar on Snow Leopard?
<Peng_> cbz: Converting is slooow.
<Peng_> cbz: And leads to interoperability problems.
<bialix> ~~~
<cbz> i didnt realise the repository format was exposed over the wire
<cbz> i assumed that whatever went over the wire was generic concepts only (branches/tags ec)
<spiv> cbz: we'd like to get the smart protocol to that point, although it hasn't been a top priority because the practical benefits are fairly small compared to other things we've been working on
<spiv> cbz: regarding your earlier question, defaulting to using the format as the source has the advantage that you can be sure there's minimal friction getting your work merged back into the source
<spiv> i.e. it avoids assuming that everyone is using the latest bzr.
<mkanat> spiv: The practical benefits would have been nice for read-only backwards compatibility across on-disk formats.
<mkanat> But yeah, like Peng_ said, that would involve a conversion, which would be slow.
<spiv> mkanat: yes, and also the rich-root transition would have thwarted that :/
<mkanat> Yes. Well, hopefully 2a will be the stable format for a while....
#bzr 2011-05-09
* spiv changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv
<poolie> hi all
<poolie> hi spiv
<aurora|shower> i figured out my problem if its reveleant
<aurora|shower> turns out it was using a ssh.exe using my PATH on windows, which was one that was used by git (irony?) and for some reason git's copy didnt work with it, so i uninstalled git and it works ifne
<vila> helllo !
<jelmer> hi jam, vila
<jam> hi jelmer
<jelmer> jam: is there an easy way to trigger regenerating a particular index?
 * jelmer is looking at bug 413430
<ubot5> Launchpad bug 413430 in Bazaar "ShortReadvError on index file" [High,Confirmed] https://launchpad.net/bugs/413430
<jam> jelmer: no
<vila> hey jelmer !
<jam> indexes can contain data that is not stored in the .pack file
<jam> such as the file_id, revision_id associated with the content
<vila> jelmer: I use a script that deletes a .pack and its indices here
<vila> jelmer: there are complications in same cases though (especially if you have uncommitted changes)
<jelmer> jam: ah
<vila> jelmer, jam: We should fix that in the next format...
<jam> vila: we looked into it with the last format, but it bloated the size of .pack by about 10-15%
<jam> file_ids and revision_ids are not very compressible
<jam> so if we could shrink the indexes by ~ as much as we bloat the .packs then maybe
<vila> jelmer: lp:~vila/bzr/697815-repair-repo was my last attempt
<vila> jelmer: may be out-of-date as a proposal but I think the script is still the same as the one I use
<jam> vila, jelmer: I need to get some feedback about WT and TreeReference implementations
<jelmer> jam: Hi
<jam> jelmer: so the source of the issues
<jam> 1) I wanted to change the tree.iter_changes() code
<jam> so that revert would do wt.iter_changes(wt.basis_tree()) instead of wt.basis_tree().iter_changes(wt)
<jam> that turned out to reveal a bug wrt TreeReference
<jam> specifically, WT.iter_changes(wt.basis_tree()) (used by 'bzr status') auto-detects when a file becomes a TreeReference
<jam> sorry, when a *directory*
<jam> becomes a TreeReference
<jam> however, WT.inventory does not
<jam> so WT.inventory.iter_changes(WT.basis_tree().inventory) was failing on tests about TreeReference
<jam> 2) I did a simple fix, to change WT._generate_inventory()
<jam> so that it would see new TreeReferences
<jam> 3) There was some fallout for code paths that assumed this didn't happen
<jam> mostly around the split code
<jam> For example, WT.extract() was grabbing self.inventory[subdir_id] and passing that into a the new Inventory for the created subtree
<vila> jam: well, AIUI, TreeReference implementation has never been completed, so I'm not surprised there are bugs there
<jam> I can fairly easily move the Inventory creation logic before the new subtree is created
<jam> vila: sure, I'm just trying to figure out how to fix it enough
<jam> to land my revert improvements
<vila> ok
<jam> without leaving things as horribly kludges when I'm done
<jam> (horribly kludged or horrible kludges, take your pick :)
<vila> jam: target less horrible kludges ;)
<jam> What is happening now
<jam> is that I create the new subtree inventory ok
<jam> I create a parent tree that doesn't have the subdir in it anymore (which suprised me, but ok)
<jam> (it was how the code did it)
<jam> But when it goes to update the working inventory it breaks
<jam> this is because the dirstate blocks themselves still have the old directory *and its children* recorded
<jam> WT._generate_inventory just skips subdir blocks that didn't have a parent *directory* read
<jam> and TreeReference isn't a directory
<jam> so that mostly worked
<jam> I think now I have to go back and when I see a directory become a TreeReference (in _generate_inventory), I have to update the dirstate to let it know
<jam> I'm hesitant, because it loses track of child identities
<jam> but I think that is what 'bzr status' does today
<vila> hmm
<vila> I'd start by adding tests myself :-/
<jam> vila: except you can't really add a test if you don't know the *desired* behavior
<vila> To at least demonstrate your diagnosis is correct (the added benefit will be to quickly get failing tests when you start changing the behavior)
<vila> jam: I meant, starting from a pristine bzr trunk, add tests about the cases you're unclear about
<jelmer> jam: what do you mean with "it loses child identities" ?
<jam> jelmer: A TreeReference has no .children attribute
<jam> so the recursive subtree that used to be versioned under the Directory all disappears
<jelmer> jam: Ah, I see.
<jam> consider Tree/A/B/C
<jam> if A becomes a subtree
<jam> B and C were versioned, but now are missing
<jam> so "bzr init A; bzr status; rm -rf A/.bzr/; bzr status"
<jam> what *should* that do?
<jam> at the moment, it actually treats the final 'bzr status' as not modified
<jam> because while it detects a TreeReference, that is never written back to disk
<vila> first status says nothing, second one says unknown for A ?
<vila> hmm, no
<jam> vila: bzr init A says "unknown: a/.bzr/"
<jam> second says nothing
<jam> neither talk about A/B or A/B/C
<jam> I'm pretty sure it is a bit borked
<jam> but as I said, I don't want to fix all of TreeReference today
<jelmer> yeah, that seems wrong
<jam> just get my revert landed
<vila> right, first says A unknown (while more or less realizing it's a TR not a dir), second one... should also says unkown, realizing A is a dir
<jam> jelmer: so in the Extract case, it deletes the "A" from the parent inventory, and then calls self._write_inventory(new_inv)
<jam> which then tries to build a TreeDelta
<jam> which then sees that we now have a TreeReference there (it calls _generate_inventory again)
<jam> and builds an inventory delta saying "delete the tree-reference at A"
<vila> jam: you don't have to fix all the TR bugs, but landing a change in their behaviour withoutknowing whether or not you introduce new bugs.... >-/
<jam> however, the dirstate file says, ok, I'll delete A, but not all of its children, because it doesn't have any
<jam> and then "oops, you asked to delete a directory but not its children"
<jam> vila: I don't really care
<jam> we don't support them now
<jam> my changes won't make them any more supported than the existing tests
<vila> but they could make them less supported, that's the point
<jam> I don't have to make things better for TR, and I feel comfortable making it slightly worse
<jam> people are welcome to file bugs which we can respond to with regular priority
<jelmer> We're not sure the way tree references work in working trees are necessarily the right way, are we?
<jam> *right now* it has taken me 3+weeks to land a simple "bzr revert" takes 5s instead of 5min
<jam> jelmer: *I'm* certainly not thinking the current behaviour is "right"
<jam> vila: my original fix is *quite simply* a 1 line I' know it is correct change
<jam> change basis_tree.iter_changes(tree) to
<jam> tree.iter_changes(basis_tree)
<jam> and swap the parameters in the next lines
<jelmer> jam: me neither - I certainly don't think the working tree support for nested trees is complete enough
<jam> very straightforward, with *tons* of fallout
<jam> vila: if there is that much fallout from just this, TreeReferences are just plain broken
<jam> so I don't mind a little regression there
<vila> jam: my point is that you're at least in a position to write expected failures or file bugs, if you don't that knowledge is wasted
<jam> vila: anyone who is serious about implementing TreeReference is going to run into everything I've run into quite quickly
<jam> and will be at a point to make decisions on it
<jam> IMO
<jam> filing a "this is broken" is not a helpful bug
<jelmer> jam: how much treereference-specific code is actually in working trees? I wonder if rather than having the current level of support it makes sense to just rip it out for the moment rather than having something known broken in there.
<jam> jelmer: there is about 30+ occurences of "tree-reference" in workingtree* dirstate*
<jam> it isn't particularly trivial
<jelmer> ah, hmm
<jam> hmm.. maybe one change is to revert my change to WT.inventory
<jam> and instead make Inventory.iter_changes(Inventory) (the generic logic) try to do the lookups
<jam> then at least WT.inventory would be a direct match for WT.dirstate._dirblocks
<jam> that's probably better
<poolie> hi jam, vila
<jam> hi poolie
<vila> poolie: hey
<poolie> vila, jam, you should join us in #ubuntu-uds-arany
<ovnicraft> hello i merge with a branch my repo was updated but i need keep the commiter name in my tree
<ovnicraft> how can i keep this ?
<ovnicraft> how commit and keep the user in my tree?
<maxb> ovnicraft: I'm afraid you're not making much sense. Can you try to describe what you want more clearly?
<lifeless> jelmer: hi
<lifeless> bu
<lifeless> h
<ovnicraft> maxb, i merge my branch with another
<ovnicraft> when i commit i cant see the changes with user who did it
<ovnicraft> they are applied with my user
<jdobrien> ovnicraft, with bzr merge?
<ovnicraft> yes
<ovnicraft> i use 2.3.1
<maxb> You should look at "bzr log -n0"
<maxb> It is quite correct that the merge revision is attributed to you - you did it
#bzr 2011-05-10
<dcoles> Hello again. Here's an interesting issue - if I have svn cache.tdb files in my .cache/bazaar/svn directory I can't use bzr-git.
<dcoles> The quick fix is to just blow away the .cache/bazaar/svn directory, but I'm still trying to work out why bzr-git was the thing affected (since bzr-svn and normal svn work fine)
<lifeless> thats odd :)
<dcoles> I'm wondering if it's some sort of auto-probe like the transports do. My work has a weird certificate config that means I can only use svn+https because https straight will explode.
<dcoles> "Initialising Subversion metadata cache in /home/dcoles/.cache/bazaar/svn/a64d3506-044a-4e67-9bab-d6d69bd6860d."
<dcoles> Hm. It's a git checkout...
<dcoles> Though ffmpeg was being dual-hosted with svn.
<lifeless> heh
<spiv> dcoles: I suppose as a workaround you could set BZR_DISABLE_PLUGINS=svn when working with that location
<dcoles> spiv: Well the weird thing is that if I do a new checkout of the ffmpeg trunk with git then it works
<dcoles> Looks like for some reason it the first repo was missing .git/branches and thus caused bzr-git to assume it was not a repository
<dcoles> (Which then caused a whole bunch of other behavior in bzr-svn like trying to look at all the svn repos it had cached)
 * jelmer waves
<jam> morning jelmer, you're up early :)
<poolie> hi jam, jelmer, vila
 * jelmer waves
<jam> hi poolie
<poolie> hi jelmer
<poolie> i'm out in the atrium space
<rom1> hi all
<rom1> Is there somethong to configure in qbzr so that the user defined bugtrackers are displayed in qlog tree tags ?
<luks> rom1: unfortunatelly, no
<luks> rom1: there is a currently a hard-coded list of URL pattenrs in the source
<luks> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/view/head:/lib/bugs.py
<spiv> luks: huh
<spiv> luks: seems like that should be using bzrlib.bugtracker.tracker_registry somehow
<spiv> luks: (maybe some helper APIs need to be added to bzrlib?)
<luks> spiv: that doesn't really work
<luks> spiv: because bzr stores only the full URL
<luks> spiv: but not a way to get the ID from it
<Kamping_Kaiser> can bzr be made to print out the current revno before updating if i involve 'bzr pull'?
<spiv> luks: right, so we probably should extend the APIs there to allow that.
<spiv> luks: it would be useful for more than just qbzr :)
<luks> spiv: well, it's not possible without changing the format
<luks> spiv: because bug tracker configuration is stored in the user's configuration file
<luks> so I get an arbitrary URL, I don't know what the user that committed it had configured as a bug tracker
<luks> this would be a nice use case for versioned properties, IMO
<spiv> luks: sure, but you can use the current user's config as a likely reasonable approximation
<spiv> (I agree we could store more structured data in the properties)
<mbp_> o/ spiv
<mbp_> thanks for all the reviews
<spiv> Hi mbp, just having a quick bike shed before dinner :)
<mbp_> heh
<mbp_> i bet people can really bikeshed on your dinner too
<mbp_> hm
<poolie> that's better
<poolie> that's good news fram maritza
<rom1> Thx luks
<poolie> jam, vila, hi?
<jam> hi poolie
<poolie> can you join #ubuntu-uds-arany
<poolie> we're just going to talk about bfbip
<santagada> why does bzr diff tries to go to launchpad to search for differences? I would like to do a local diff only
<jam> santagada: if you are using a lightweight checkout, the data isn't stored locally to diff against
<jam> if you're not, then I don't see why it would be connecting to launchpad
<santagada> jam: stacked means lightweight?
<jam> santagada: no
<santagada> then no
<jam> but stacked may-or-may-not have the data locally
<santagada> I have huge checkouts
<jam> since stacked inherently stores some comment remotely
<jam> content
<santagada> at least the latest version should be here
<santagada> I'm doing a simple bzr diff <file>
<santagada> without any parameters, so I can't think of any for that it would have to look on the internet to do it
<santagada> s/for/form
<santagada> because it should at least have the revision I'm on
<maxb> Not if you are using a lightweight checkout
<santagada> why would I want such a lightweight checkout? I'm going to find the command I did to checkout stuff, but I remember it was huge and slow
<maxb> Run 'bzr info' and tell us the first line
<santagada> bzr info is kinda slow also
<maxb> Actually, pastebin all of 'bzr info's output
<santagada> https://gist.github.com/6440ba487ad80f038ece
<maxb> Oh, OK, your local branch is stacked on the remote launchpad branch
<maxb> i.e. bzr is configured to not store locally any revisions which are present in the remote branch
<jam> maxb: he's using "bzr branch --stacked" which may or may not have local content. I'm guessing at the least, we are always opening the stacked-on location just as part of opening the branch.
<maxb> Seems likely
<jam> by default we *don't* have the tip revision at the time of branching, because that is in the stacked location (and by default we have nothing in a stacked branch that is in the stacked-on location)
<jam> after a commit, we *should* have some of the data locally
<jam> (the newly committed stuff)
<santagada> "bzr branch --stacked" was what I used
<jam> but I'm guessing we would still connect to the stacked-on location (because Branch.open() opens fallbacks)
<santagada> there is no point of downloading the whole repo at x revision and not keep at least the tip
<santagada> so I downloaded tons of megabytes from launchpad, suffered thru it and I don't have the tip to do a diff :)
<santagada> I'm not mad, but it doesn't make much sense to me
<santagada> is there a way to get at least the tip?
<jam> santagada: its something we want to support (bzr branch --shallow), but it isn't in the immediate plans. It is something that is rated moderately high for stuff like UDD development
<jam> so I would guess it would be implemented in the next few months.
<jam> it isn't trivial to create in the current model, since as I said, we default to not storing data that is already present
<jam> mostly because '--stacked' was an answer for pushing stuff up to Launchpad, where you *don't* upload a whole set of contents.
<poolie> hey jam, thanks for joining in
<santagada> jam: so I should just download the whole repo
#bzr 2011-05-11
<BlindWolf8> Hello all
<spiv> Hi BlindWolf8
<BlindWolf8> I have a Bazaar for a team and they need to access the main branch. I know it's possible becaue I set this up a longt ime ago, but how can I make it so that the address they type is shorter?
<BlindWolf8> e.g., bzr+ssh://me@host/ vs bzr+ssh://me@host/.bzr/branches/trunk/
<spiv> You can use bzr_ssh_path_limiter from the contrib/ directory in bzr's source
<BlindWolf8> oh yeah, that rings a bell
<spiv> See also http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html
<spiv> Er, http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/simple-setups.html#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories
<spiv> (Although the bzr-bookmarks plugin is another approach to solving this problem)
<BlindWolf8> I'm going to login via SSH and look for bzr_ssh_path_limiter
<spiv> http://bazaar.launchpad.net/+branch/bzr/view/head:/contrib/bzr_ssh_path_limiter
<BlindWolf8> Is there anything in the manual about bzr_ssh_path_limiter?
<BlindWolf8> I can't seem to find much
<BlindWolf8> oh, lemme take a look at that link
<spiv> It's not in the manual yet :/
<spiv> It would be in the admin-guide link I pasted except the instructions on how to copy it out of the contrib/ directory to somewhere accessible to the command= directive in .ssh/authorized_keys was just a bit too complex compared to the advice that's currently there
<BlindWolf8> also, can you clarify soermthing for me? am I correct in assuming tha you can nly edit files via ftp, sftp and bzr+ssh protocols?
<BlindWolf8> it seems bzr only is just read only
<spiv> (Which is to do something fairly similar, but with longer directives in the authorized_keys file)
<spiv> I can, but first you'll have to clarify what you mean by "edit files" in this context :)
<BlindWolf8> edit = upload new/modified files
<BlindWolf8> (and delete files)
<spiv> Which files are you referring to?  Files in a working tree?
<BlindWolf8> files in a colocated branch
<spiv> But that colocated branch is on a network file server rather than somewhere on your filesystem?
<BlindWolf8> that is correct. the colocated branch is on a server
<BlindWolf8> as far as I have researched, colocated branches are best for just one folder being versioned without the need for multiple branches
<spiv> So, having a working tree on a server for a branch is uncommon.
<BlindWolf8> what is more common?
<spiv> Because generally the workflow as a developer is "get a local branch, edit files and commit locally, push" (or "get a local checkout, edit files locally, and commit")
<spiv> So in that scenario there's no reason to have a working tree on the server
<BlindWolf8> well, we only needed one branch, and it had to be on a server for sharing purposes
<BlindWolf8> so I thought colocated branch would be best
<spiv> But if you're also using this as a mechanism to deploy changes to a website or something, then that can be done with plugins like bzr-upload or bzr-push-and-update.
<spiv> (Or even just a cronjob that runs "bzr update" in that directory every 5 minutes or whatever)
<BlindWolf8> aren't those plugins not neded if you bind the branch?
<BlindWolf8> that is what I told my teammates to do
<spiv> I think perhaps you're confused by the distinction between a "branch" and "working tree"
<BlindWolf8> most likely :-)
<bignose> BlindWolf8: the working tree is the files that you actually care about. the branch is the revision history and other metadata.
<spiv> A branch is a thing you make other branches and checkouts from.
<bignose> then there's the repository, which is where the revision data is stored.
<spiv> Or, just see what bignose is saying :)
<BlindWolf8> have you guys consdiering updating the documentation?
<BlindWolf8> *considered
<bignose> BlindWolf8: patches welcome :-)
<BlindWolf8> :-P
<spiv> We do (that admin-guide section I linked to is fairly new for instance)
<bignose> only half-joking. âyou guysî are way too close to the technical details to see what might be confusing to newbies.
<BlindWolf8> so...hmmm....
<BlindWolf8> If i'm following you...the only thing I really want on the server is the repo
<BlindWolf8> ...right?
<bignose> s/î/â/
<spiv> BlindWolf8: and the branch :)
<spiv> BlindWolf8: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html#team-collaboration-central-style
<BlindWolf8> yeah, since that has the files
<bignose> BlindWolf8: if you don't want the working tree files in one location. configure that location with â--no-treesâ
<BlindWolf8> that's what I did with colocated branches
<BlindWolf8> I just made that on the server and told everytone to make them on their machines as well in a directory that they would work in
<BlindWolf8> then, they Pulled the info from the server and bound the branch
<BlindWolf8> and just commited like normal
<spiv> BlindWolf8: Sounds good so far :)
<BlindWolf8> oh!
<BlindWolf8> guess I did everything right then
<BlindWolf8> :-)
<BlindWolf8> dunnoo...guess it just felt wrong to make a colocated branch on the server due to the name itself
<BlindWolf8> a server, to me, should be a shared repository
<BlindWolf8> sicne shared is in the name
<spiv> Well, I probably would use regular branches in a shared repository rather than colocated branches on the server myself.
<spiv> But I don't think there's any problem with using colocated branches like that.
<BlindWolf8> by regular, do you mean feature?
<spiv> (And really that's just because that's what I'm used to.)
<bignose> BlindWolf8: don't over-read the names of these things :-)
<spiv> Um, I mean "not made with the bzr-colo plugin"
<spiv> What do you mean by "colocated branch"? :)
<bignose> the âsharedâ in âshared repositoryâ refers *only* to sharing data between branches.
<bignose> not between projects, not between users, not between anything else.
<BlindWolf8> yeah, I read about that on the site
<BlindWolf8> btw, I had an odd issue when I was working with Bazaar and my team
<BlindWolf8> they were all using Bazaar v2.3.1 Standalone
<BlindWolf8> and all on Windows machines, sans the Linux server
<BlindWolf8> I could not commit a file to the server larger than 37ish MB.
<BlindWolf8> the server has 512MB of RAM, and I threw Linux Mint on there
<poolie> hi all
 * jelmer waves
<vila> hey poolie
<poolie> hi there
<poolie> there's a meeting about lp bug states now in #ubunt-uds-mikszath
<poolie> you know what i mean
<poolie> hi vila, are you back?
<poolie> oh ye
<vila> yes
<vila> no network available yesterday so I couldn't tell :)
<vila> I was too busy to search for a net access anyway ;)
<poolie> no problem
<poolie> was it good?
<vila> yes, on many counts
<poolie> nijaba was just saying he saw you and raphael there
<poolie> you looked busy :)
<vila> wearing a new hat and speaking native revealed... too many details to summarize :)
<poolie> :)
<vila> but roughly, after a slow start searching my words (doh !) I had a lot of very interesting discussions on topics I'm not used to talk about anymore
<vila> There were far more high-in-hierarchy people that I suspected and clearly things are moving in the right direction for FOSS
<vila> Interesting feedback from the Gendarmerie Nationale too (~35.000 PC using Ubuntu/Open Office, tagetting ~80.000)
<vila> (imbw on the numbers but the scale is correct)
<vila> ..and some fun confidential details on *how* this all started :)
<vila> let's just say that techies get their revenge against politicians :D
<vila> I indeed say raphael and nijaba but was just able to say hi to nijaba (and couldn't even say bye ;)
<vila> I talked a bit with raphael though (about hamster among other things  which he said he's very happy with ;)
<fullermd> 's good for people to get on Open Office just in time for it to fade away   :p
<vila> fullermd: hehe, but didn't Oracle say the light there ?
<vila> s/say/saw/
<vila> worst typos make sense...
<fullermd> The light of what?  The Sun?   :p
<vila> hehe, got some weird stories about sunnies in Oracle too...
<fullermd> 'see' would be the right conjugation there.
<fullermd> I figure anything that happens in Oracle has to be weird...
<vila> bbiab
<poolie> mup poke warner
<poolie> bah
<poolie> jelmer, jam, vila, do you see any point in further discussion about python2.4?
<poolie> i think we should just go to 2.6
<poolie> and start getting ready for 3
<vila> poolie: right, I re-read the thread yesterday as I thought there was some pending issues, but
<vila> as long as we keep bzr-2.3 python-2.4 compatible, I think we're fine
<vila> maxb: we already dropped hardy in the beta ppa right ?
<vila> hmm, no :)
<poolie> i think it's not going to be updated though
<poolie> i think we will need python3 support well before the eol of rhel5 and lucid
<poolie> and there seems a reasonable chance we cannot support both of them at the same time
<poolie> vial, do you think we could set up a babune helper that runs with python2.6 -3?
<poolie> or 2.7
<poolie> also, like we talked about a while ago, i'd really like to get some subset of builders that are reliably blue
<vila> AIUI, people on rhel should be able to find a suitable python
<vila> poolie: yeah, I was thinking about working on babune a bit again
<vila> There is an open bug on jenkins for the 'fail to delete tmp file' that is the cause of most of the noisy failures these days
<vila> I think they made a change in how the track the connection status between master and slave. This bug is the most obvious fallout and I hope it will make the other issues I had more obvious
<vila> but they just released 1.411 without fixing it :-/
<poolie> :/
<poolie> is everyone using jenkins experiencing this, or is it something we're doing?
<maxb> poolie/vila: There's been no discussion about ceasing hardy support in the PPAs
<maxb> I startd a thread, but there was little reaction
<maxb> We recently got a bug report from someone using the beta ppa on hardy
<vila> poolie: I made a comment on an existing bug but ISTR that lp has also been experiencing it
<vila> maxb: ha. So we have an issue then
<maxb> We're only stepping to py2.5 for now, right?
<vila> maxb: unless you intend to backport python-2.6 there ? :)
<maxb> oh
<maxb> apparently not
<vila> maxb: yeah, that's why I re-read the thread, at first I thought we wanted to target 2.5 only too
<maxb> Hmm. What would be really useful, is PPA download counts that exclude hits from the PPA buildds
<vila> maxb: do you have the bug # for that hardy user ?
<maxb> No bug, email on bazaar@, John Szakmeister
<vila> maxb: I thought your thread about hardy in PPAs ended with: no SRUs so stick with 2.3
<vila> obviously I was wrong, but that still seem to be the most adequate plan no ?
<maxb> The thread mysteriously conflated PPAs with SRUs for no apparent reason, and fizzled
<vila> maxb: wow, just found this mail John Szakmeister, didn't realize he was still using hardy...
<maxb> Hardy is already in limited support, which ends April 2013
<maxb> The only reason to keep it would be stubborn people still on LTS-1
<vila> hmm
<vila> the stable ppa still carries 2.3.1, so we can decide to leave it at that when 2.4.0 is released,
<ScottK> Even Dapper is still supported in Ubuntu (for another month)
<vila> that leaves only people using the beta ppa for hardy in a weird state but if we stop at 2.4b2 for hardy there, they will just have to.... to what...
<vila> ScottK: right, but people still using it *and* wanting recent versions of bzr are a bit schizophrenic no ?
<poolie> maxb, ah, i did reply
<ScottK> vila: Agreed.
<ScottK> OTOH, I do have one server that there's no hardware support for past Hardy, so it will never run a later release.
<poolie> maxb, nobody replied to say they want 2.4betas
<ScottK> That is a narrow case however.
<maxb> True
<poolie> _my_ point about srus is that i think you (or we) would please more people by doing the 2.2 lucid sru
<maxb> If we ditch hardy, we'll also ditch jaunty, which will mean we no longer have to support series that don't support debian source format 3.0, which is nice
 * vila nods
<vila> maxb: for >= 2.4, we'll still support hardy and jaunty for 2.3 right ?
<vila> by the way, I should cut 2.3.2 tomorrow and probably 2.1.4 next week
<vila> s/I should/I planned but this may be revisited/
<maxb> Well, jaunty's already way past EOL
<maxb> we're only supporting it still because the PPA buildfarm still does, and it's no extra effort so long as we support hardy
<vila> maxb: no objection from me to drop jaunty
<vila> err, I mean, whatever cost less, but the idea is to keep 2.3 supported where it's supported today while dropping hardy [jaunty] for 2.4
<maxb> that seems reasonable
<vila> even karmic can be dropped for 2.4 if we want to clean things up
<fullermd> Hm, cython thread.  Maybe I need to try that again.
<poolie> hi jam
<poolie> are you coming next week?
<vila> poolie: drizzle hits the same jenkins problem, just found back your email about it
<poolie> oh really
<poolie> is it specific to building things from bzr?
<vila> I don't think so
<vila> I can't think of a reason why it should even be remotely connected :)
<poolie> hm
<poolie> do you know why http://babune.ladeuil.net:24842/job/selftest-hardy/470/ failed for example?
<vila> poolie: precisely this reason: http://babune.ladeuil.net:24842/job/selftest-hardy/470/console scroll down to the bottom
<vila> hudson.util.IOException2: remote file operation failed: /tmp/hudson6106588248283886773.sh at hudson.remoting.Channel@1030a0f8:hardy32.local
<poolie> right that's what i wondered
<poolie> i wonder if we should do more stuff out of the recipe nightly builds
<poolie> which will only help on ubuntu of course
<poolie> but will reliably tell us if we break say lucid
<poolie> of course there are some noise failures there too, but generally they seem to be real packaging failures, if not upstream bugs
<vila> well, the recipes are intended to *build* something, running selftest there is a side-effect, nice one, but still a side-effect
<vila> and without the ability to parametrize the selftest run
<vila> I share the frustration about jenkins adding a lot of noise (especially lately) but I still think these jenkins bugs will be fixed and that spending time debugging them is not the best use of my time :-}
<poolie> i agree with that
<poolie> as long as we know they're upstream bugs not something about our deployment or bzr itself
<poolie> then we can just ignore them
<poolie> i guess better if we can all get an idea of what kind of pattern likely indicates a spurious faliure
<vila> poolie: you just did :)
<poolie> haha
<poolie> i guess the lesson is just ask you
<poolie> if it's not clear
<vila> well, what I do is look at the failures, there are not a gazillion of failures that produces no test results
<vila> the fact that *I* can delete these helps keep babune blue and if I was giving such access more liberally more people will learn
<vila> I spotted the ability to use openID providers for authentification and I thought that would be a good idea for babune (less admin hassle for me too)
<vila> but... I need to find a free slot in my schedule ;)
<poolie> oh, you remove the build record?
<poolie> that's an interesting idea
<vila> when it's due to a jenkins bug ? Yes, otherwise the job history itself becomes noisy
<vila> and that would be even worse
<vila> but doing that is ~5mins/day at *most* (so no hamster for it ;) and roughly the only work I do on babune
<jelmer> jam: hi
<jam> hi jelmer
<jelmer> jam: I'm looking at bug 146165 but wondering which of the WorkingTree APIs to actually use
<ubot5> Launchpad bug 146165 in Bazaar "smart_add uses _get_inventory, _write_inventory, but should not" [Medium,In progress] https://launchpad.net/bugs/146165
<jelmer> I originally started out calling WorkingTree.add(), but that doesn't work when there are e.g. files that have been converted to directories
<jam> jelmer: ideally it would build up an inventory delta, and pass that in
<jam> I don't know if all the apis are available
<jelmer> jam: That'd make sense, I'll look into it
<jelmer> thanks
<poolie> vila, i was just forwarding that mail from someone at drizzle
<poolie> can you reply to them
<poolie> i'd like them to know it's now bzr's fault, if it's not
<poolie> s/if/as
<vila> poolie: you forwarded the body, no emails there :-.
<exarkun> I wonder if anyone can help me understand what the author of bzr+ssh://bazaar.launchpad.net/~morgan-s-reed/pyopenssl/mr-RSAadditions/ did (with respect to lp:pyopenssl) and if there's anything special I should do if I want to merge that branch.
 * maxb fetches the branches
<maxb> exarkun: Looks like he just started a long time ago, did some work, then came back to it, and then gradually merged newer versions of trunk to get up to date
<maxb> then did a little more work
<maxb> So, there's nothing particularly special going on here.
<spiv> exarkun: have you tried "bzr merge --preview $URL" in your local copy of lp:pyopenssl ?
<exarkun> spiv: apart from the "--preview" part, yes
<spiv> Or just s/--preview// and examine what what it does before you commit, yeah.
<exarkun> I did that and 'bzr qlog' and the picture qlog drew confused me
<spiv> Ok, so if the diff is fine I'd just commit it.
<exarkun> well, there's also a ton of conflicts in every changed file, but that part I understand :)
<maxb> exarkun: Well, given the branch last merged trunk two releases ago, that's not unexpected, is it?  :-)
<exarkun> maxb: nope
<poolie> jam, spiv, vila, discussion of udd in #ubuntu-uds-kond
<jam> poolie: that is an empty room
<vila> jam: s/kond/ond/
<poolie> i think it is 'kond'
<jam> poolie: kond is empty, and ond is talking about color schemes and the color picker
<jam> poolie: maybe I typod it, I'm there now
<poolie> jam, i think i did work on that
<poolie> but quite a while ago
<jam> poolie: https://bugs.launchpad.net/bzr/+bug/781168
<ubot5> Ubuntu bug 781168 in Bazaar "WT.update_basis_by_delta checks the current tree state to determine InvalidDelta" [High,Confirmed]
<vila> jam: ok, for osutils, didn't remember sha_strings et al.
<jam> vila: Mr. Config Man, I have a config question for you.
<jam> I'm looking into setting a config var for how our Pack code works
<vila> hehe, shout
<jam> something that sets max size, max pointer, something like that
<jam> so people can tweak it to lower peak memory (in theory)
<jam> however, VersionedFiles have no config available
<jam> much less the GroupCompressor object
<jam> where I really want the data
<jam> (the value to be set)
<jam> Even if I back up one higher, I end up at Repository, which at best can get LocationConfig(self.user_url)
<jam> (which would then pass it down to the next levels)
<jam> I *could* just put it in GlobalConfig
<jam> and then access it at a very low level (ugly, but doable)
<jam> vila: thoughts?
<vila> you get it right :)
<vila> today, I'd say just go with GlobalConfig
<vila> ideally we probably want to provide the repo config down
<jam> vila: but who checks GlobalConfig, the GCVersionedFile ?
<jam> or the Repository?
<vila> jam: the actual "style" is to build a GlobalConfig() when you need it
<jam> vila: I don't really want to re-create a GlobalConfig each time I get a new block to create.
<jam> I can do it per stream, but that's also a bit of overhead
<jam> and there is a special case where we take an existing block and break it up into smaller blocks.
<vila> jam: otp, but that's the actual design didn't help for that, bbiab
<jam> I don't quite understand what you wrote there
<jam> (and the object that does that isn't always created from a Repository, as it has a direct instantiation function from NetworkRecordStream)
<poolie> hi vila, jam
<poolie> two interesting ideas from the udd session
<poolie> one by jelmer which is maybe having a merge helper that fixes up quilt metadata
<poolie> rather than importing to looms, which seesm to have a long dependency chain
<poolie> oh the other was, perhaps having a staging packgae importer would make us feel more comfortable changing it
<jam> poolie: you can import_package --no-push I think
<jam> which is meant to be "do the import, but throw away the results"
<jam> not quite the same as staging, thoug
<poolie> mm
<poolie> perhaps it's enough
<poolie> i guess you can test locally too
<poolie> thinking about small fixes or investigations i did before, i would have found it reassuring to have a realistic but safe test
 * vila back
<maxb> poolie: There's also the --local-branches option which allows for testing tweakage which requires the result branches actually get kept locally, and re-used on a second invocation
<vila> jam: the actual design doesn't help with config sharing so we create config objects when we need them
<poolie> py26 then hey
<jam> poolie: yep, py2.6. All we really needed was a "JFDI" and we DI :)
<poolie> glad i could help
<gholms> I tried fast-importing a git repository, but got a bunch of complaints about how it "Cannot import items of kind 'tree-reference' yet" and it tore my directory structure to shreds.  Do I have any hope of making it work?
<TrentonDAdams> I'm confused by the bzr svn document in section "Merging trunk to your feature branch".  It says that you shouldn't merge the trunk to your feature branch, but then it says to use merge later on.
<TrentonDAdams> Is it simply saying that merging trunk should be avoided because of the risk of accidentally using push to get the branch back into trunk?  If so, the wording should really be changed, because it sounds like it's saying don't do merging between trunk/branch, but then it says to go ahead and do that.
<BjornW> Quick question: I want to write a PHP lib for using Bzr, probably similar to PEAR VersionControl_Git and VersionControl_Svn and would like to discuss this with the bzr developers. Should this become a Blueprint or can I submit a mail to the developers mailinglist?
<BjornW> Answering my own question: I will send an email :)
#bzr 2011-05-12
<vila> hello jelmer , hello all
<fullermd> Shoot, I'm demoted to 'all'?   :(
<vila> hehe, you were part of all in 'hi all' already :) Since you ask me to introduce some variety I do my best at a time where my caffeine / blood ratio is still low...
<fullermd> There are many problems in the world caused by having too much blood in one's coffeestream...
<fullermd> Still, it's not THAT hard to rig up an IV, really.
<vila> 4 ?
<fullermd> As in 'intravenous'.
<vila> ha, IntraVenous ?
<vila> :)
<jam> morning vila
<vila> hey jam !
<vila> jam: so, about your config need,
<vila> nothing forbids getting the option value once and pass it down to your objects
<jelmer_> 'morning vila :)
<vila> (if you're still worried about accessing the *file*)
<jelmer_> hi fullermd, Riddell_
<vila> jelmer_: nice shot, the avatar (Ridell no _) died ;)
<jelmer_> :)
<jam> vila: so I don't know if you noticed what I said, which is that one of the ways GroupCompress objects are created is from _LazyContentManager, which can be instantiated by a NetworkRecordStream. None of which is directly coupled to a Repository.
<jam> anyway, I think I can make it work
<jam> Right now, I'm working on actually implementing the functionality *based* on the config item, so I have some time to think about it still
<vila> jam: there are two cases there I think
<vila> if it's connected to the repo, get it from there
<vila> if it's not there are again two cases :)
<vila> if it should end up in a repo, you probably know it ahead, so connect it
<vila> otherwise, either fallback to the global config or use a default value
<poolie> hi everyone
<vila> fullermd: he really meant fullermd *and* everyone ;)
<vila> hey poolie
<fullermd> Oh good.  My ego was in danger of shrinking for a minute there.  And then what would hold up the clouds?
<vila> Herakles ?
<fullermd> Pfft.  Pretender.
<jam> vila: I'm pretty sure Atlas was the one holding up the world, Herakles was just a strong-man
<vila> jam: indeed, but Atlas asked Herakles to replace him for a while (and went party-ing for an unreasonable period and then Herakles wasn't wery happy about that...)
<jam> was he a waskaly wabbit?
<jam> :)
<fullermd> Well, Atlas managed to get whole lines of gym equipment named after him, so by some measures he come out ahead, anyway...
<bignose> and some pretty awesome books.
<bignose> and a now-defunct rocket launcher program.
<fullermd> Yeah.  And what did Heracles get?  A crappy TV show...
<fullermd> It just doesn't pay to hold planets for your friends.
<bignose> sage advice, I'm sure that will save people some time.
<fullermd> 's why I share my genius like this.  I'm a giver.
<vila> yeah, once again competition is bitten by collaboration ;)
<fullermd> Good choice for a Greek day, as I'm already sitting here listening to _Atalanta_   :p
<vila> :)
<vila> jam: quick check about our locking model:
<vila> branches/wt are write-locked for the duration of the whole operation but repos are only write-locked around the pack-names modifications
<vila> correct ?
<vila> operation == bzr command
<vila> well ~=, you see what I mean or feel free to be more precise ;)
<jam> vila: physically locked, yes
<vila> is there some hidden meaning to physically I may be missing ?
<jam> so when you do Object.lock_write(), Branches and WT change the state on disk
<jam> Repository does not
<vila> yup
<jam> Repository only holds the on-disk lock for the time to update pack-names
<vila> my question was: only one operation can get the lock
<jam> vila: right. It doesn't make sense to allow 2 people to push to a branch concurrently, since both would want to change the branch poitner.
<vila> sure
<jam> arguably some branch operations could be done in parallel, but it was never worth doing
<jam> (like setting a branch.conf entry vs updating branch's tip pointer)
<vila> what I'm after is: can I rely on the object lock to assume that the corresponding config file doesn't need an additional lock
<vila> this works for branch/wt but is still unclear for repos
<jam> vila: doesn't work for repos, but they don't currently have a config
<vila> indeed ;)
<jam> also, we don't *want* to block Repo for config settings (most likely)
 * vila nods
<jam> we *want* repo to be multi-writer as much as possible
 * vila nods
<jam> so that you can have 100 branches that get updates without blocking the repository
<jam> I don't know how that works with config
<vila> well
<vila> there is no repo option today
<vila> so there is no repo option that a bzr operation want to set
<vila> but we can imagine repo options that could be set directly via bzr config or by editing the file
<vila> so as long as the config file is never left in an inconsistent state by bzr itself, we always get a valid config file leaving only the issue that bzr can get an out-of-date option value (which is acceptable)
<vila> neglecting user errors while editing the file that is (which is addressed differently anyway)
<jelmer> spiv, hi
<spiv> jelmer: hola
<jelmer> spiv: I'm looking at adding a limit argument to Branch.fetch but I'm wondering what the most appropriate way is to do so
<jelmer> spiv, in particular, would it be better to pass the limit argument down as part of the fetch_spec or rather as a separate argument down to InterRepository.fetch() ?
<spiv> Hmm, limit meaning what here?
<spiv> If it means "no more than N ancestors of these tips", then I think that's a kind of fetch_spec.
<jelmer> yep, just a rough way of limiting the data transferred
<jam> hey spiv, on late?
<spiv> (If you don't mind walking the history up front you can already do that via an appropriate SearchResult fetch_spec)
<spiv> jam: yeah, a bit.  V just went to bed.
<spiv> Snoring like a proverbial baby :)
<jelmer> :)
<jelmer> spiv, that makes sense, I'll add it to the fetch_spec. Thanks :)
<spiv> jelmer: so basically yes, I think this is something fetch_spec ought to do
<spiv> I have a ugly patch atm that adds a new fetch spec (to make "bzr branch --stacked" from remote when it's about to build a working tree) much better.
<spiv> Transfers 1/3 the bytes in 1/2 the round-trips.
<spiv> So I'm definitely in favour of adding fetch_specs :)
<jelmer> that sounds nice :)
<spiv> Basically it's a fetch spec for "the whole revision, i.e. inventory and all referenced texts (and chks)", which is the data that has to be retrieved to build a working tree if you have no data to start with.
<spiv> We really should make get_stream_for_missing_keys not need VFS calls though
<spiv> (Possibly in part by sending more of those keys in the stream in the first place!)
<chriscauser> Hello everyone
<chriscauser> I'm having a spot of bother with my bzr-svn
<chriscauser> I'm 2.4 daily on ubuntu and when I push I get this
<chriscauser> http://paste.ubuntu.com/606456/
<jelmer> chriscauser, hi
<chriscauser> It worked yesterday so I suspect it may have something to do with the update I installed this morning
<jelmer> chriscauser, what sort of bzr / bzr-svn are you running?
<chriscauser> jelmer: Sorry, I thought it was in the crash report. bzr is 2.4.0dev3
<chriscauser> bzr-svn is 1.1.0~bzr3688~ppa376~lucid1
<jelmer> chriscauser, you need a newer version of bzr-svn too if you're running a bzr snapshot
<jelmer> are you running both from the daily PPA?
<chriscauser> yes
<chriscauser> As far as I'm aware, there's nothing out of the ordinary on this box
<chriscauser> (other than a daily PPA ;) )
<jelmer> looks like the bzr-svn package in the PPA needs fixing
<chriscauser> jelmer: Thanks
<jelmer> chriscauser, should be fixed now, but it'll take up to 24 hours for the package to rebuilt
<jelmer> *rebuild
<chriscauser> jelmer: Thanks a lot. What would you recommend I do in the meantime (
<chriscauser> pin the version or download the tar?)
<chriscauser> or just sit and wait :)
<chriscauser> ?
<jelmer> chriscauser: there is no tarball to download, as you're running a nightly build :)
<jelmer> chriscauser: you can grab lp:bzr-svn though
<chriscauser> jelmer: Duh, now why didn't I think of that!
<jelmer> spiv: still there?
<jelmer> spiv: I'm trying to figure out how to integrate this with SearchResult
<spiv> jelmer: I probably wouldn't change SearchResult.  This sounds like it'd be a new search or search result.
<jelmer> spiv: Where would you put it instead, FetchSpecFactory.make_fetch_spec() ?
<jam> jelmer: the other thing to consider between you and spiv, is how "wide" the result should be
<chriscauser> jelmer: Thank you so much. The latest revision works absolutely fine now.
<jam> specifically, for "shallow" branches, you want to have all texts, even if they aren't part of the delta for a given rev
<jelmer> chriscauser: np, thanks for making me aware it's broken
<jam> however, for regular fetch + some ancestors, do you want all texts or not?
<jelmer> jam: The use case for this is the incremental fetches that Launchpad does for imports (but would also apply for mirrors)
<jam> jelmer: how is that different from just requesting a fetch at N and reporting back that you have N-1000 ?
<jam> (though it sounds like you don't want the 'fully-wide' content)
<jelmer> jam: we want more than just the mainline so N-1000 is too rough
<jam> jelmer: but don't you have text discovery already?
<jelmer> jam: also, it's imposibble to determine what N-1000 is for e.g. Git or Mercurial repositories
<jam> _walk_to_to_common_revisions
<jam> sort of thing
<jelmer> jam: that's server driven
<jam> jelmer: I don't understand why you want N - (100 old ancestors) without wanting evertyhing you don't have
<jelmer> jam: I do want everything I don't have, I just don't want all of it now
<jam> jelmer: but surely you want older stuff first
<jelmer> jam: ah, yes
<jelmer> jam: of course
<jam> jelmer: the search you were proposing was "give me the newest 100 revisions" not "give me the oldest 100 revisions that I don't have"
<jam> I understand why you want the latter, but that isn't easily constructed from a tip
<jam> also, how would you pass that to something like git ?
<jam> I thought it could only fetch everything from the tips it has
<jam> (it reports to you)
<spiv> jelmer: Perhaps make_fetch_spec() would sometimes use this new fetch spec, but that seems like a largely orthogonal issue
<jelmer> jam: yes, it can only give you everything but bzr-git can limit the amount it fetches to the bzr repository
<jam> jelmer: by staging it?
<jelmer> jam: importing the git pack file to bzr is fairly slow (getting better, but not ideal yet)
<jelmer> jam: refetching the pack each time at the moment
<jam> jelmer: so it gets the full ancestry stream, and then strips it?
<jelmer> yeah
<spiv> jelmer: AIUI the issue you're tackling is you have some code that would like to call "source.fetch(fetch_spec=<something>)", and needs to be able to have a <something> that means "limited to <some limit>"
<jelmer> jam: It's not ideal, but this is what already happens on the Launchpad importds atm
<spiv> jelmer: so the questions are a) what object is <something>, and b) how do you make one?
<jam> jelmer: what *I* would like to see, even for bzr-core, is the ability for a fetch stream to say "you should have a complete snapshot up to rev X, feel free to commit it"
<jam> we can already interleave Revisions then inventories, then texts, then send more revisions (IIRC)
<jam> it would be nice to have revs, invs, texts, COMMIT, revs, invs, texts
<jam> that would also allow resumable "bzr branch"
<jelmer> jam: that'd be nice
<jam> and possibly make it cheaper to compute fetch streams
<spiv> jelmer: one approach is "class MostRecentNRevsNotAlreadyInTarget(AbstractSearch): def __init__(self, n, target_repo): â¦" that just does a regular breadth-first walk in its .execute() and so returns a regular SearchResult
<jam> in that the streaming code could find what needs to be sent, but then break it up to commitable chunks
<jam> and then it doesn't have to look at all 5Million chk pages across all 100k revisions
<jelmer> jam: it's different from this though - the fetch limit goal is mainly there to avoid resource issues
<spiv> jelmer: another approach is define a new SearchResult (rather than a new Search), along the lines of PendingAncestryResult
<jam> spiv: jelmer and I just realized that he wants OldestNRevsNotAlreadyInTarget()
<jam> which is quite different
<jelmer> spiv: Sorry for being vague - I'm after the oldest revs rather than the newest
<jelmer> or what jam said :)
<spiv> jelmer: ah, interesting.
<spiv> I could imagine something like OldestNRevsOfPendingAncestryResult
<spiv> Where you specify not just the heads you want, but the heads you've already got
<spiv> Normally we don't like calculating heads for the target because it's not cheap
<spiv> But if you've just grabbed a OldestNRevsOfPendingAncestryResult stream you can keep track of the heads so far as you receive them.
<jelmer> spiv, ah, hmm
<jam> spiv: true, and you could also use an existing branch target as a Head to seed
<spiv> It's a bit rough on the stream source (i.e. the server), it will have to keep walking back from the current tip all the way back to your heads each round.
<jam> right now fetch is missing Branch <=> Branch info
<jam> as it tends to just be done at the Repo level. I would *like* to at least hint at target heads.
<spiv> But that's perhaps just the price someone has to pay for breaking the work up into chunks.
<jam> Though we'de need to do something with that.
<spiv> Yeah, having more info about the target heads available there would be good.
<jelmer> lunchtime here, I'll have a closer look at it this afternoon
<mrevell> Hello/nick mrevell-lunch
<mrevell> Oops
<bugreporter> hi everybody
<bugreporter> any experts here ?
<bugreporter> qor non-experts ?
<bugreporter> wel ...
<bugreporter> i'd like to know what "pending merge tips" are
<bugreporter> i believe the reason why they are in my directory is that .......
<bugreporter> the directory is a checkout from a local branch which is a "branch" of a public branch
<bugreporter> and i wanted to merge the branch updates with my local changes but accidentally did a pull
<bugreporter> now my locally commited changes disappeared from the log but they are still in the files
<bugreporter> bzr diff shows all of them in one diff ...
<bugreporter> ... bzr status -v shows all the commit messages
<bugreporter> now another more important question:
<vila> ...
<vila> his commits are still there but he is not anymore so he can't know...
<vila> bugreport: were you called bugreporter a few minutes ago
<vila> ?
<bugreport> ... all   ...    dÃ¤dÃ¤dÃ¤  ...
<bugreport> yes
<bugreport> .... merge tips
<bugreport> sorry
<bugreport> do you know anything about merge tips, villa
<bugreport> ?
<vila> (more personalized nicks are available and easier to recognize ;)
<vila> yes
<vila> when you do a merge, 'bzr status' reports the tip of the branch you merged so you can keep track of where you are
<vila> you triggered a merge when you did the pull in your checkout
<bugreport> "the tip of the branch I merged " ... yes ...
<bugreport> what i fail to understand is why my commits are not in bzr log output
<vila> so your previous commits were merged, you still need to commit to finish the merge
<vila> because they are pending
<bugreport> aaaah ... ok ... but ...
<vila> they will appear after you commit
<vila> well,
<bugreport> now when i do a merge, they will be "condensed" ...
<vila> no
<vila> or
<bugreport> no ? .....
<vila> well, really no
<vila> but by default bzr log will only report the merge
<vila> do 'bzr log --include-merges' to see them
<bugreport> and where will the commit message of the merge commit show up and where the others ...
<bugreport> thanks
<bugreport> ok ... think i just got the answer from you
<vila> there all there, one level down
<vila> they are all...
<bugreport> have to read about include-merges ...
<vila> yeah, try 'bzr log --help'
<bugreport> ~ shows all revisions, also those not in the mainline ...
<bugreport> which means bzr pull also made the "remote" the mainline ...
<bugreport> sort of
<bugreport> can i make my local changes "mainline" again ?
<bugreport> (and how ?)
<vila> if you're sharing the remote branch with others, you don't want to do that
<bugreport> i don't have  write access to remote
<vila> well, unless you can convince them that's you're the boss and they just have to listen ;)
<bugreport> am just trying to get my local branch ready to publish on launchpad
<bugreport> remote is on savannah.gnu.org
<bugreport> i think i could publish my stuff on launchpad ... ? can i ?
<vila> sure
<bugreport> :-) you have any suggestions on how i should proceed with that from here ...
<vila> hmm
<bugreport> i would finally do something like "bzr push lp:~bugreport-mailinator/grub/sector-ranges" ... or can i just publish to "+junk" ??
<vila> better to publish in the project namespace
<vila> if only because you will be able to do a merge proposal against the project trunk
<vila> hmm
<bugreport> do have write access there (default / without any further actions ...
<vila> as long as savannah and lp agree about what the trunk is
<bugreport> i thought it's savannah but am not sure ...
<bugreport> they differ quiet a bit ... anyway ... in terms of bzr commands ... how to get my local changes branch to be "mainline" again here on my laptop ?
<vila> https://code.launchpad.net/~vcs-imports/grub/main seems to say that it's a mirror from gnu.org so that should be in sync
<vila> back to your goal:
<vila> you can:
<bugreport> (by "differ" i mean, there are commits inn launchpad/ubuntu which are not in the trunk on savannah )
<vila> if you commit now, that will create a revisions whose parents will be (savanah tip, your last commit)
<vila> what you want is (your last commit, savannah tip)
<bugreport> exactly ....  got me
<vila> hmm,
<bugreport> :-) difficult enough ?
<vila> the shortest way that comes to mind is to recreate a branch with a tip at your last commit
<vila> and merge savannah branch there, commit and you'll get the right pattern
<vila> now, to get back your tip...
<vila> you can just commit and see what revno you get there :)
<vila> there are other ways but this one is the simplest for you I think
<bugreport> hmm...
<bugreport> lets commit ...
<bugreport> it's +1 from before ...
<bugreport> so savannah-trunk+1
<vila> look at 'bzr log --include-merges' now
<bugreport> +10 from my old tip
<vila> yup, commit always create a +1 revno by definition
<vila> forget about the numbering of your old tip, you broke it
<bugreport> old tip commitsss all have the same revno
<bugreport> :-)
<vila> they shouldn't, are you sure you used --include-merges ?
<vila> if in doubt, just pastebin the output
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<bugreport> all right ... but i can switch branches and have the old commits seperate ... ? (if not it doesn matter much ... nothing interresting in the commit messages ... all just "wip" but out of interrest ...
<bugreport> http://paste.ubuntu.com/606520/
<vila> yes you can (unless I totally misunderstood what happened)
<vila> right, so they don't have the same revno: 3245.1.1 is different from 3245.1.2
<bugreport> :-) didn't read the output before ...
<vila> to get back your old branch just do:
<vila> bzr branch . -r3245.1.27 ../my-dear-old-branch
<vila> and, yeah, I'm sure the people you'll share this branch with will be more than happy to find commit messages providing a bit more info than wip ;-D
<bugreport> cool ... wroked
<bugreport> i have to write some ... and condense some commits ... make around 5-10 out of those ...
<bugreport> :-) ... you helped me a lot already ! thank you! ..
<bugreport> .. anyway if you know how to write nice commit messages onto those changes and reorganize them ... ??
<bugreport> "git rebase -i" ...
<vila> haaaaa... that's why it's so popular !
<bugreport> very likely
<vila> there is 'bzr shelve --interactive' I think
<bugreport> ok ... sounds good
<bugreport> not in my version though ...
<bugreport> (natty 2.3.1)
<vila> but shelve works for uncommitted changes, so you'll have to get them back first
<bugreport> (at leas not in help output ...
<vila> err, wth
<bugreport> :-) pull ?
<vila> hmm, no cherry pick instead probably
<vila> i.e. start with a branch from savannah and there do:
<bugreport> googling for "git rebase bzr" leads me to a plugin ... bzr-rewrite"
<vila> yup, but I don't think there is an --interactive option there, does it ?
<bugreport> http://marcin.juszkiewicz.com.pl/2010/10/06/bazaar-what-is-wrong-with-it/
<bugreport> no idea ...
<jelmer> --interactive is imho not really appropriate on the rebase command, as it's a general way to reshape the revision graph
<vila> bzr merge ../my-dear-old-branch -r<first-rev>..<last-interesting-rev>
<bugreport> go ahead with the cherry-pick solution ... sounds reasonable
<jelmer> I'm happy to have another command in bzr-rewrite that does a similar thing though
<vila> jelmer: Did I dream the shelve --interactive ?
<awilkins> vila, shelve is interactive by default, no?
<vila> bugreport: bzr diff will show your changes, bzr st will allow you to verify that there is no pending merges, you're just getting the changes without tracking the history
<vila> awilkins: dunno, I always use --all
<vila> awilkins: because I can't use the interactive mode under emacs (where I have alternative workflows that work better for me)
<vila> bugreport: so once you have the uncommitted changes, try 'bzr shelve' and follow the prompts ;)
<jelmer> vila: there is a bzr-interactive plugin that allows interactive shelving I think
<bugreport> i was about to check out ("merge") a fresh savannah trunk and the do "bzr merge ../my-dear-old-branch -r<first-rev>..<last-interesting-rev>" repetingly ... ??
<vila> jelmer: haaaa, thanks, bugreport ^
<vila> bugreport: you create a branch once, you repeat the merge ; hack;shelve;commit;unshelve;
<bugreport> ups --- i meant ("branch") of course ...
<jelmer> vila: it does a completely different thing from "git rebase -i" though
<vila> bugreport: branch and checkout are two different things but if the checkout led you to the trap, you may prefer branch and come back to checkout later (bzr reconfigure can help switch from one to the other)
<bugreport> well ... i will approach the task later on  ....
<bugreport> i branched / not chekout actually ...
<bugreport> i was just not aware that pull would do a different kind of merge then merge ...
<vila> bugreport: or you may just push your branch to lp, not everybody cares about the intermediate commits
<vila> bugreport: pull should warn you to use merge if it can't pull in a branch
<bugreport> yea ...
<vila> bugreport: checkouts are different
<bugreport> ok - have to go - see you ...
<bugreport> and thanks again
<vila> bugreport: they are targeted at people used to the centralized workflow where the local changes don't show up on the mainline
<bugreport> hmmmm ....
<bugreport> i kind of dont like that "compatibility" in bzr
<vila> bugreport: just use plain branches then
 * awilkins likes "lightweight" checkouts used to approximate gits co-located branches thing
<vila> bugreport: I suspect you *did* use a checkout to end up in this "mess"
<vila> awilkins: please :) Don't add confusion ;)
<bugreport> distriibuted is a new paradigm which is not really hard to get and you should switch when using a dscm
<vila> bugreport: not everybody has the luxury to do that
<vila> bugreport: *I* never use checkouts, but I don't forbid others to ;)
<bugreport> i have a shared repo on top and "savanna-trunk" and "my-branch" inside ...
<vila> bugreport: perfect setup :0
<bugreport> shared repo created with "bzr init-something ..."
<vila> init-repo
<bugreport> :-) good to know it's approved
<vila> hehe
<bugreport> cu then ... bye
<vila> we want to make it easier to get it as the default one
<vila> cu
<chriscauser_> Hello all again. Sorry to pester (and I hope this is a quick one) but I don't know how to use bzr+svn with keyring auth for http simple. Is there a verbose flag that would tell me what it's trying on the auth front?
<jelmer> chriscauser_, hi
<jelmer> chriscauser_, GNOME keyring?>
<chriscauser_> jelmer: yes indeed.
<jelmer> chriscauser_, bzr can only use existing keyring credentials, it won't add new credentials to keyrings at the moment
<chriscauser_> jelmer: Ah, this might be it. It seems to checkout the repo just fine in svn though.
<chriscauser_> (as in I have put the credentials in the keyring already by doing an svn checkout)
<jelmer> chriscauser_: it should in any case prompt you, even if it can't already find the crednetials
<jelmer> also, I can't spell
<chriscauser_> jelmer: don't worry. I'm explaining it very badly. My problem is more of an annoyance than anything else. Any remote  operation requires me to enter a password. svn checkout works fine because the pw is cached in the keyring. Is there a way of getting the same behaviour?
<chriscauser_> jelmer: It used to work when I had the pw stored in plaintext in ~/.subversion (obviously not ideal)
<jelmer> chriscauser_: I'm not sure
<jelmer> chriscauser_: If you can use svn with the keyring credentials then that obviously means that the credentials are there and valid
<jelmer> so I'm not sure why the keyring integration in bzr-gtk is not working properly
<chriscauser_> jelmer: Is there a debug that I can run?
<jelmer> chriscauser_, it's been a while since I've worked on the keyring stuff
<jelmer> chriscauser_, I'd recommend adding some pdb statements in the code in bzr-gtk to see what entry it is looking at
<jelmer> and then comparing that with what the gnome-keyring-manager thinks is present
<chriscauser_> jelmer: OK. I'll get back to you on this.
<chriscauser_> jelmer: I think I have it. svn seems to be storing the credentials in the keychain differently to how bzr-svn is expecting to read it.
<chriscauser_> I have got it working, and can give you a patch if you want
<chriscauser_> The only problem is I don't know if it is because subversion has changed the way it stores things (I'm on Lucid) so I may break things for other people
<Buttons840> i have *.pyc in my ignore file, but pyc files still show in subdirectories?
<Buttons840> do i do */*.pyc or something?
<jelmer> chriscauser_: I don't think it has - a patch would be great :)
<Buttons840> is bzr written entirely in python?
<chriscauser_> jelmer: I'm forking bzr-svn and will create a merge proposal for you if that's OK with you.
<jelmer> chriscauser_: You mean bzr-gtk?
<jelmer> Buttons840: Do you mean whether "bzr status" shows them?
<chriscauser_> jelmer: Yes, you're clearly psychic because you understand what I mean, not what I write :)
<jelmer> chriscauser_: :)
<Buttons840> jelmer: yes, but i solved it, i put "**/*.pyc" in .bzrignore
<vila> Buttons840: that;s weird because  I have '*.py[co]' in my ~/.bazaar/ignore and I *never* see any .pyc...
<chriscauser_> Buttons840: I may be corrected on this but if these pyc files are already versioned, they will continue to be after the .bzrignore file has them included. Are these files versioned?
<jelmer> chriscauser_: yeah, that's correct
<chriscauser_> jelmer: I'm hitting a brick road with this patch. I think the problem is that the changes I make will stop auth for bzr over https. As I can tell, there is no way that bzr-gtk can see if the auth request is for an svn repo or a bzr one :$
<chriscauser_> cd
<chriscauser_> Duh, wrong window
<jelmer> chriscauser_: should it have to know whether it is for a svn or a bzr repository?
<jelmer> chriscauser_: Can you perhaps show the patch so far?
<chriscauser_> jelmer: No, I think that's the problem. bzr (I assume because I have no way of testing it) stores creds in a particular format. svn stores it in another.
<jelmer> chriscauser_: In what way are they different?
<jelmer> I think it might be reasonable to adjust the way in which bzr-gtk retrieves the credentials if that matches something that is more commonly used
<jelmer> I doubt there are a lot of people actually using it yet (since we don't actively store credentials), and the bug you've hit is something that more people have complained about
<chriscauser_> lp:~chy-causer/bzr-gtk/fix-svn-keyring
<jelmer> hmm, it stores domain as realm?
<jelmer> the other way around I mean
<chriscauser_> indeed
<jelmer> I wonder what things like epiphany use
<chriscauser_> jelmer: That would be interesting.
<jelmer> chriscauser_: http://live.gnome.org/GnomeKeyring/StoringPasswords
<jelmer> chriscauser_: So, according to the documentation "domain" is actually the appropriate thing to use
<jelmer> chriscauser_: So we should probably be setting that unconditionally, rather than special casing http/https
<chriscauser_> jelmer: Very interesting!
<chriscauser_> jelmer: So you would have to check if the scheme were http(s) though to remove the protocol and server attributes (which aren't in the keyring)
<chriscauser_> jelmer: Hmm. grepping the codebase makes me think there is no way of setting keyring keys, so a merge proposal wouldn't be too disastrous
<chriscauser_> jelmer: I've updated the code so now all requests will have the 'domain' key
<jelmer> chriscauser_: cool, I'll have a look
<jelmer> chriscauser_: Does it still work if you also set protocol and server?
<chriscauser_> jelmer: Unfortunately not. I got a gnomekeyring.NoMatchError, because those keys aren't specified by svn
<jelmer> Hmm, that's a bit annoying
<chriscauser_> This was what was making me uneasy: there's potential here to stomp all over people who are using bzr over http
<chriscauser_> without svn
<jelmer> chriscauser_, I don't think there are a lot of those to be honest
<jelmer> chriscauser_: either way, perhaps we should consider trying multiple combinations
<chriscauser_> jelmer: I think you may be right.
<chriscauser_> jelmer: yes, I don't think this code is in any way thoroughly tested. The only problem is that my testbed is a little limited.
<chriscauser_> jelmer: especially since almost everything I do uses ssh keys
<chriscauser_> Right, I'm off now. jelmer: thank you for all your help.
<jelmer> chriscauser_: Any chance you can create a MP for your branch?
<jelmer> chriscauser_: Even if it's not perfect (yet), it should help us remember to get this code in.
<chriscauser_> jelmer: Absolutely.
<jelmer> chriscauser_: Thanks :)
<chriscauser_> jelmer: https://code.launchpad.net/~chy-causer/bzr-gtk/fix-svn-keyring/+merge/60817
<chriscauser_> jelmer: Well, anyway hope that helps. See you!
<screen-dsuch> Hm, whom to let know that http://wiki.bazaar.canonical.com/BzrPlugins links to http://doc.bazaar.canonical.com/plugins/en/rebase-plugin.html which 404s?
<screen-dsuch> ah alright http://wiki.bazaar.canonical.com/JelmerVernooij
<hfitzgerald> hey, sorry if this question has been asked to death. I've got a bunch of configuration files that I dont want to track the changes to, but that I do want to be included in checkouts/uploads. Whats the best way to accomplish this?
<jam> hfitzgerald: the method I've seen work the best is to version a template version, and ignore the real version
<jam> so foo.conf.template gets version controlled
<jam> and people do cp foo.conf.template foo.conf to actually use it.
<hfitzgerald> ahhh
<hfitzgerald> thanks jam, that makes sense
<fullermd> (and ignore foo.conf)
<fullermd> A common setup in my projects is that my code tries to load something like foo.conf, and if it's not there, falls back to foo.conf.default.  Then I can version control .default, and most of the time that's fine.  But if I ever need local changes, I can make the foo.conf in that particular copy.
<idnar> so I'm busy making some changes in a feature branch, and I decide that some changes I just made really belong in their own branch; what's the easiest way to "extract" them?
<idnar> something with bzr shelve?
<fullermd> Just made as in "haven't committed yet"?
<LeoNerd> shelve is for saving-and-reverting changes, so they no longer appear for now.
<LeoNerd> So you can unshelve them again later
<idnar> fullermd: I have committed them
<fullermd> Ah.  Well, I'd try cherrypicking the rev then.
<idnar> the branch hasn't been published anywhere, though, so I don't mind a solution that involves revision surgery or whatever
<fullermd> (then either uncomitt'ing it away and merging the new 'authoritative' version in, or just ignoring it and letting the merge at the end deal with it)
<idnar> what I was thinking of doing is branching a copy of the branch, uncommitting everything, shelving the changes I want, reverting the rest, unshelve/commit, and then replaying the original branch on top of the new one
<idnar> er, I think I mean rebasing, not replaying
<fullermd> If you've got multiple revs on both sides, it may be worth investigating the rewrite plugin.
 * fullermd doesn't really know any details on that side of things.
<idnar> bleh, shelve can't split hunks
 * vila split hunks in diff-mode
<fullermd> Well, that doesn't mean you have to talk about it in public...   ew.
<vila> but I'm ~80% sure someone said it was able to split hunks with <insert the plugin I can't remember here>
<vila> s/it was/*he* was/ grr
<vila> fullermd: yeah, I almost used the . o O () syntax
<vila> fullermd: I'm still allowed to *think* in public right ?
<fullermd> I'm not sure you're even allowed to think in private   :p
<vila> hmpf
<lifeless> vila: vimdiff thingy
<vila> idnar: looks like I wasn't mad after all: https://code.launchpad.net/~abentley/bzr/shelve-editor/+merge/13819
<abentley> vila: that functionality's part of bzr nowadays.
<vila> abentley: exactly :)
<vila> abentley: how come it's not mentioned in the help ?
<idnar> not in the bzr I have here, apparently :/
<abentley> idnar: have you configured a change_editor?
<vila> abentley: and does it require a special setup to become apparent ?
<idnar> oh, right; probably not
<abentley> vila: yes, it does.  'e' isn't provided if you haven't configured a change_editor.
<idnar> bingo
<vila> abentley: thanks, I vaguely remembered something. Now I won't forget (hopefully).
<idnar> oh, but that's rather confusing; if you push "?" at the interactive prompt, there's no mention of the e and f commands
<idnar> *of the e command
<idnar> anyhow, cool, that should do the trick
<idnar> I see it's mentioned in the help for "bzr shelve", I guess I should pay more attention to what I'm reading
<vila> idnar: file a bug, this should at least be better documented
<vila> AAAARGH, I can't read !!!
<idnar> heh heh
<idnar> at least I'm not the only one ;)
<vila> I searched for it right there a couple of hours ago :-(
<abentley> vila, idnar: we could list 'e' all the time, and then error when no change_editor is configured.
<vila> abentley: that may have helped idnar , I can't be cured ;)
<idnar> yeah, that would be nice
<idnar> the "?" display should also be fixed
<idnar> (I would file a bug, but I'm currently on an extremely thin internet pipe)
<vila> bug #781871
<ubot5> Launchpad bug 781871 in Bazaar "change_editor for bzr shelve is still not documented enough" [Medium,Confirmed] https://launchpad.net/bugs/781871
<vila> Argh, test suite broken for 2.3.2 :-(
<vila> FAILED (errors=1093, skipped=2312, expected failures=35)
<vila> poolie: ping
<vila> bug #760435 needs to be backported
<ubot5> Launchpad bug 760435 in BzrTools "failUnless & co cause PendingDeprecationWarning" [Low,Fix committed] https://launchpad.net/bugs/760435
<vila> to the 2.3 series
<abentley> idnar: You can file bugs by email: https://help.launchpad.net/Bugs/EmailInterface
<idnar> abentley: gpg-signing mail from gmail is tedious :(
<idnar> (and it's not an @gmail.com address, so DKIM doesn't work either)
<abentley> idnar: surprised gmail is tolerable over a thin pipe.
<vila> gmail provides pop3/imap access and forwarding no ?
<idnar> it's surprisingly workable as long as you don't have to actually load all the UI elements over the thin pipe, and I already had it open in my browser...
<idnar> but I'm mostly reading my email at the moment via the Android client, which is pretty light on bandwidth
<abentley> vila: why does that bug need to be backported?
<vila> abentley: our SRU process requires the test suite to succeed
<idnar> vila: yeah, and SMTP, but I don't actually have any of that set up in a mail client
<abentley> vila: So you're saying that bzrtools 2.3 fails the test suite with bzr 2.3?
<vila> abentley: no idea, I'm cutting 2.3.2 and testing bzr only
<idnar> vila: I'm currently limping along on the trickle of 3G/HSDPA bandwidth I can get on my phone, since my fixed-line connection is down, so this isn't the normal situation for me
<vila> idnar: np, I filed the bug already anyway ;)
<vila> abentley: and of course pqm happily succeeded since it's python2.6 there :-(
<idnar> vila: :)
<vila> idnar: bug #781871
<ubot5> Launchpad bug 781871 in Bazaar "change_editor for bzr shelve is still not documented enough" [Medium,Confirmed] https://launchpad.net/bugs/781871
#bzr 2011-05-13
<arcfide> Hey, is there anyone here who can point me in the right direction on BZR?
<arcfide> Basically, I was tracking some code through BZR, but I have not done so in some time.
<arcfide> It appears that they have changed names and the like on me, and I also have a number of changes of my own that I want to track and possibly send upstream.
<arcfide> What is the way to change branches inside of a workspace?
<bignose> arcfide: each branch has its own working tree.
<arcfide> bignose: Um, so, what does that mean?
<bignose> arcfide: if you want a different branch, use âbzr branchâ which will create that branch's working tree.
<bignose> arcfide: multiple branches without switching directories is not the normal Bazaar mode of working.
<arcfide> How do I get my changes from this current tree into that one?
<bignose> arcfide: they're distinct branches, right? you want the branches to continue to have their own line of history?
<arcfide> bignose: Well, no, so, the project I was tracking changes their name and the branches and URLs and the like, I just want to figure out how to get all of my changes in line with their changes while still playing nice with my own version history, which I actually keep in Monotone.
<arcfide> I do my development in Monotone, but then I want to package something up so that I can send my changes upstream uzing Bazaar, which is what they use.
<bignose> arcfide: it sounds like you want to merge from their branch into yours.
<arcfide> Thus far I have committed no changes to the tree using Bazaar.
<arcfide> Well, I don't want to have my own branch.
<bignose> arcfide: that will bring the revision data in, merge (possibly leaving you to fix conflicts), then leave the working tree in a state for you to test
<bignose> once you're happy the merge is as you want it, you commit that and continue.
<bignose> arcfide: âplaying nice with my own version historyî seems to necessitate you having your own branch.
<arcfide> Well, so, I want to take my changes and merge them into their branch, not the other way around.
<bignose> arcfide: you can't merge into someone else's branch; they do that.
<arcfide> bignose: Sorry, my own version history is kept outside of Bazaar in Monotone (another VCS), I only want to put into the Bazaar history those things that I need to send upstream.
<bignose> you don't have write permission to their branch, right?
<arcfide> I will probably be getting it.
<arcfide> Maybe I don't know how to word it correctly, I'm basically a BZR newb.
<bignose> arcfide: so how are you going to get the Monotone VCS data into Bazaar?
<arcfide> I'm not.
<arcfide> I'm going to roll up single patches to push up, but I don't want the history to move over.
<arcfide> So LIke this:
<arcfide> 1. Grab their source; 2. Make lot's of little changes tracked in Monotone; 3. When things are ready, make a patch/commit into the Bazaar system and push upstream.
<bignose> arcfide: between the latter two steps is an implied âget my Monotone VCS data into Bazaar VCS dataâ. how will you do that?
<arcfide> I don't need or want them to see all the intermediate commits and things that I track in Monotone, and indeed, there are some changes that I don't want to push upstream to them, but I do want to be able to create or generate a patch or push the changes that I want up to their branch.
<arcfide> I'm in the same working tree.
<arcfide> So, I have a folder SRFI/ that is simultaneously a Monotone Workspace and a Bazaar working tree.
<arcfide> I make changes in that tree, and track those changes in different ways in the two systems.
<arcfide> Up until now I haven't been using Bazaar at all, and I'm way out of date.
<arcfide> So I have a working tree with a bunch of changes that I have made to it, uncommitted (to BZR's knowledge), but now I want to take my changes and send them upstream, and to do that I need to merge in their changes and figure out what conflicts.
<arcfide> Am I doing things the wrong way?
<arcfide> The branch that I was tracking before was called http://bazaar.launchpad.net/%7Eikarus-libraries-team/ikarus-libraries/srfi/, but now it seems to be lp:~scheme-libraries-team/scheme-libraries/srfi. It's the same project, though.
<bignose> arcfide: sorry, was AFK
<bignose> arcfide: one huge advantage of Bazaar is that, though a merge preserves all the revisions, the default log view doesn't show them.
<bignose> arcfide: so there's no need to modify history for mere visibility reasons
<bignose> arcfide: just merge all your stuff, and give the merge commit a useful summary
<bignose> arcfide: then the user of that branch will see your merge commit with its useful message
<bignose> arcfide: and, if they care, can choose to see the individual revisions merged
<arcfide> Hm, I'm still not sure what you mean, but thanks!
<bignose> arcfide: it means the ârebaseî common in other VCSen is virtually unnecessary in Bazaar
<bignose> args
 * bignose typing special characters badly
<arcfide> Actually, I found something that works. If I do a bzr branch on the new branch, creating a fresh copy, and then move my Monotone settings into that working tree, Monotone will tell me everything that is missing or changed since I was working on it, and I can just merge from Bazaar that way, so everything seems cool.
<arcfide> Rebase? I'm not familiar with that.
<arcfide> I don't think we do that in Monotone land either.
<bignose> arcfide: forget rebase then :-)
<bignose> what is âbzr branch on the new branchâ?
<bignose> can you give these different things names so we can refer to them?
<arcfide> Literally bzr branch <repo_url>.
<arcfide> So, basically, the whole problem was that the upstream changed names.
<bignose> I don't see how that's a problem.
<arcfide> In Monotone, if you change branch names somewhere down the road, if you simply tell Monotone to grab the newer branch, it will following the changes through to the new branch and let you shift over to that new branch inside of the same workspace. I was trying to get the same effect in Bazaar, but it appears that branches are more disjoint things.
<bignose> are you just looking for the command to tell Bazaar the new parent branch location?
<arcfide> Basically, they switched to a new branch everything, and I couldn't just pull or merge anymore. It was giving me an error that the old branch didn't exist.
<bignose> arcfide: okay, so you just specify the branch location
<arcfide> I tried that, and it wouldn't work.
<arcfide> You mean specify the new branch location, right?
<bignose> arcfide: please, let's use names for these
<bignose> make some arbitrary names and tell me which is which
<arcfide> Using saved parent location: http://bazaar.launchpad.net/~scheme-libraries-team/scheme-libraries/srfi/
<arcfide> bzr: ERROR: Unable to connect to target of bound branch BzrBranch6(file:///home/arcfide/code/srfi/) => http://bazaar.launchpad.net/%7Eikarus-libraries-team/ikarus-libraries/srfi/: Not a branch: "http://bazaar.launchpad.net/~ikarus-libraries-team/ikarus-libraries/srfi/".
<arcfide> That's what BZR was giving me, I gave you the repo names above.
<bignose> that's when you type what command?
<lifeless> probably any
<arcfide> bzr pull or merge.
<lifeless> or at least update, commit, push and pull
<arcfide> I think it was probably pull.
 * arcfide searches his command history.
<arcfide> Yes, pull.
<lifeless> arcfide: bzr unbind
<lifeless> arcfide: then bzr bind with the new upstream url
<arcfide> Aaah.
<arcfide> Okay, cool, thanks, I've learned something about BZR now. Thanks for your patience bignose.
<bignose> arcfide: yes, I was going to modify your command to get it to remember the new location
<bignose> as lifeless says, it's just a matter of telling Bazaar to update its remembered location to the new location
<arcfide> I figured it was something simple like that.
<bignose> okay :-)
<bignose> glad to have helped.
<arcfide> Um, so, when I try to commit, if my commit message has an "Unknown" in it, does that mean it is going to commit that file or just that it will ignore it?
<spiv> arcfide: it will not include the unknown file in the commit (and will fail if you try "commit --strict")
<arcfide> Aaah, okay.
<arcfide> Thanks a bunch!
<vila> poolie: "We can possibly have dallas between the commands." Dallas ??? Is that a typo or am I missing a joke ?
<fullermd> Hope it's not a joke.  It's so Belgium.
<vila> fullermd: it appears that poolie was under attack by its spell-checker ;)
<poolie> hi vila
<poolie> there'sa session now about upcoming launchpad features in #ubuntu-uds
<poolie> there'sa session now about upcoming launchpad features in #ubuntu-uds-tas
<poolie> vila, jam, spiv, ^^
<vila> poolie: ok, could we discuss 2.3.2/2.3.3 after that ?
<poolie> "calving branching" too hey :)
<poolie> you and me, or people here at uds?
<vila> poolie: you and/or jelmer, the main point is to get feedback about the SRU and the failUnless, failIf deprecation fix diff size
 * jelmer hears his name and wakes up
<jelmer> vila: which issue is this?
<poolie> vila, there's a session about lptools following this
<vila> jelmer: see my mail on ML "bzr-2.3.2, SRU and conflicting tags"
<vila> jelmer: roughly 2.3.2 fail the test suite with > 1000 errors
<maxb> poolie: Btw, has there been any "Where to go and when to show up" info sent out for next week's bzr sprint? I've not seen any
<poolie> ah, marianna probably missed you because (afaik) you don't need accommodation
<poolie> basically turn up at the millbank tower before 9am monday
<poolie> (or later if you want)
<poolie> you will be expected
<poolie> vila, i'm disappointed (not with you) that babune didn't catch this
<poolie> i did actually look at it while you were away and found it down
<vila> poolie: that's because it was *down* :)
<poolie> i know
<poolie> i know last time you said you turned off the hardware
<vila> V. wasn't at ease leaving computers running without anybody to check for fire
<poolie> :)
<poolie> perhaps we can move it out of your house
<vila> poolie: but the issue AIUI is that a python upgrade raised the issue so the slave needed to be upgraded to catch it anyway
<vila> (or another job added on the master itself which is upgraded more regularly)
<vila> but anyway, no vila at home, no upgrades
<maxb> Thanks poolie - and yes, I'm only a tube journey away
<vila> maxb: great, cu there ;)
<bialix> hi
 * bialix is looking for vila, the master of configs
<bialix> hey vila
<vila> bialix: busy now, I'll try to answer but expect some lag
<bialix> np
<bialix> vila: ok
<vila> bialix: hey, ask your question anyway ! :0
<bialix> vila: I need to talk with somebody about qbzr.conf problems (bug #761535).
<ubot5> Launchpad bug 761535 in QBzr "bzr-explorer forgets external diff tool" [High,Confirmed] https://launchpad.net/bugs/761535
<poolie> vila, 2.3.3 sounds fine to me
<vila> poolie: ok, I'll do that
<vila> http://pad.lv/657550
<ubot5> Launchpad bug 657550 in Launchpad itself "perform bzr merge in the UI" [Medium,Triaged]
<vila> pad.lv/657550
<thumper> vila: isn't hard
<vila> hmm, so bug 657550 is still shorter
<ubot5> Launchpad bug 657550 in Launchpad itself "perform bzr merge in the UI" [Medium,Triaged] https://launchpad.net/bugs/657550
<vila> thumper: sorry, was just using a random bug to test the ubuntu bot
<thumper> vila: :)
<vila> thumper: argh, not implying the bug is random :-/
<thumper> vila: and here I was thinking you'd fix it :)
<vila> hehe
<vila> poolie: if you could paste the channel where the next sessions is happening that would be great (makes it sooo easy to join including getting the audio)
<poolie> it's on summit.ubuntu.com
<jelmer> vila, it's in elod
<vila> epic fail
<poolie> yeah, elod
<bialix> what is elod?
<vila> #ubuntu-uds-elog
<jelmer> bialix, it's the name of one of the rooms here at UDS
<bialix> ah, great
<vila> #ubuntu-uds-elod
<vila> poolie, jelmer: I meant the channel *name* so I can click on it :)
 * bialix has installed msvc2008 express russian version, it can compile bzr c extensions for py2.6
<vila> bialix: \o/
<bialix> compiling in russain is a lot of fun. ms did a very good job about printing russian messages to the console regardless of codepage
<bialix> poor python
<vila> bialix: so, I think you got a good handle on the problem, if you cache the whole file locally multiple times, incoherence is guaranteed
<vila> bialix: that's why the bzrlib implementation re-read the config file before setting a single value
<bialix> vila: yes, I want to talk about how to fix this mess now
<vila> bialix: use the bzrlib implementation
<vila> bialix: and while you're there, stop using embedded sections ;)
<bialix> some parts of qbzr expects this caching behavior :-(
<vila> bialix: why ?
<vila> to avoid reading the file ?
<bialix> vila: no way! only by mey dead corpse
<vila> it's in the cache, it shouldn't make such a difference
<vila> err, I meant the OS cache
<bialix> vila: I've talked about embedded sections
<bialix> wait! we don't have embedded sections yet! haha
<bialix> we have just sections
 * bialix has to teach himself to put smilie after each joke
<bialix> vila: there was intent to write all changes to config file at once
<bialix> should I keep that or should just write ever time the options changed... that's the question
<vila> use the bzrlib implementation and it will write at each change
<bialix> I think I should just go this way
<vila> bialix: be also aware that new stuff I'm working on will *also* require some changes in your code anyway
<bialix> oh, no! :-)
<vila> I'll try to make this painless and provide some migration path but there are cases I just can't automate anyway so I'm now ~convinced that the most effective way to address the issues is to provide helpers instead of trying to automate all cases
<bialix> sorry, I have no idea what are you talking about
<bialix> I haven't followed your merge proposals
<poolie> vila, jam, spiv, starting soon in elod
<poolie> hi bialix
<bialix> hi poolie
<vila> poolie: already there
<vila> bialix: how would you know then ! :D
<jam> hi poolie
<bialix> vila: know what? I'm subscribed to merge proposals but have no time to follow all of them
<bialix> also I receive a lot of notifications about daily-ppa builds, they're a bit noisy
<vila> bialix: know where we're heading so you can anticipate ;) Like... embedded sections are not needed to guarantee atomic changes (which AIUI is your main motivation)
<bialix> sorry, I'm too dumb today. I just don't understand, perhaps I've missed something important
<bialix> yesterday I had mid-term test in my English class. I have much worse result than I thought. My english skill is not good these days perhaps
<vila> embedded sections are Evil: if you use one in the no-name section (i.e. branch.conf is just a no-name section) and call it 'qbzr' (for the sake of the example), then you can't have a section named 'qbzr' where you specify options that should apply to a 'qbzr' path
<bialix> maybe we should just say that configobj is evil? joke joke joke
<vila> bialix: hehe, don't get discouraged, it may just mean you're progressing by getting aware of your errors (as opposed to making errors without realizing it ;)
<vila> bialix: well, almost, the problem is we din't clearly specified which parts we wanted to use and people went directly to configobj to use features that now conflict
<vila> bialix: busy again, expect lag again
<bialix> vila: about embedded sections: we don't use no-name sections in qbzr.conf
<bialix> 12 tenses of english just kill me
<vila> bialix: but you use one in branch.conf, that's the one that is the trouble for me
<bialix> vila: oh, we have already talked about commit_data and have reached agreement I will remove it... sometimes soon
<bialix> qbzr.conf is my headache now
<vila> oh, I forgot about that, great !
<poolie> vila, jam, talking about python versionsupport in -elod now
<poolie> specifically dropping py2 from the cd in oneiric
<poolie> not from the distro
<mtaylor> poolie: you were right - easy_install launchpadlib works just fine now
<poolie> hooray
<poolie> i think it was broken but i might have fixed it
<poolie> or someone else did
<poolie> oh the thing with jenkins failures it turned out was actually from Brian
<poolie> i replied to him
<mtaylor> cool
<mtaylor> do you remember what the issue was? something crazy?
<poolie> https://issues.jenkins-ci.org/browse/JENKINS-1948
<poolie> jam, hi
<jam> hi poolie
<poolie> i'm just looking with eres at slow initial branching of gcc-licano into an empty repository
<poolie> noticeably slower than going into a new standalone branch
<poolie> this sounds familiar
<poolie> there are many get_parent_map calls
<poolie> but i thought this was fixed
<jam> poolie: if you branch without a tarrget repo we issue a "give me everything request"
<poolie> sorry, revital
<jam> if you have a target repo
<jam> we always _walk_to_common_revisions
<poolie> then it checks what's there
<poolie> right
<jam> We talked about having a "is the repo empty" api
<jam> never happened
<poolie> or faster spanning out to discover this
<poolie> ok ,https://bugs.launchpad.net/bzr/+bug/388269
<ubot5> Ubuntu bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,Confirmed]
<jam> poolie: or using the target branch as a hint to what might be in the target repo
<jam> (namely nothing)
<jam> though this won't always be correct (new branches will always be at NULL:)
<poolie> that's not a bad idea
<poolie> ok thanks
<Peng> What would that do if you were pulling into an empty branch even though the repo already has all the revisions?
<poolie> we'll just let it run
<jam> Peng: hence my point that it can only be a hint
<Peng> :D
<jam> (and one that doesn't cause things to explode badly)
<stewart> are there any gui tools (esp for exploring history with annotate) that won't make me cry?
<stewart> (this rules out bzr explorer and bzr-gtk's annotate)
<awilkins> bzr qannotate ?
<awilkins> Oh, hang on, bzr-explorer uses qbzr, doesn't it?
<stewart> awilkins, looks like it
<bialix> jelmer: should I package subvertpy 0.8.0 into windows installer? bzr 2.3 has packaged 0.7.5.
<jelmer> bialix, 0.7.5 should still be fine for that version of bzr-svn
<bialix> so, you don't recommend me to use 0.8?
<jelmer> bialix, 0.8 shouldn't have anything 0.7.5 doesn't as far as the version of bzr-svn you're currently bundling goes
<bialix> jelmer: can I have a very simple answer: y/n? I assume that I should use 0.7.5
<jelmer> bialix: go for 0.7.5 if you're sticking to the same version of bzr-svn
<bialix> svn version is lp:bzr-svn
<bialix> i.e. your trunk
<bialix> should I package specific version?
<jelmer> bialix, if you use lp:bzr-svn you should use subvertpy 0.8.0
<jelmer> but you shouldn't really use lp:bzr-svn in a release..
<bialix> what should I use for 2.4b2?
<jelmer> for 2.4b2 lp:bzr-svn is probably appropriate, there's no matching bzr-svn release yet
<bialix> so then I should use subvertpy 0.8, right?
<jelmer> bialix, yes
<bialix> jelmer: thank you
<fullermd> Woof, up into the 71 millions on lplibrarian.
<jelmer> jam: are you happy for my per-file-graph branch to land? you mentioned in your comments that you were ok with it, but you didn't vote.
<jam> jelmer: yeah, its fine
<jelmer> jam: thanks!
<fullermd> vila: Next release, should update the copyright date (still says -2010)
<vila> fullermd: huh ? What ? WHere ?
<fullermd> bzr version output's where I noticed it.
 * vila whistles
<fullermd> bzr script itself also has up to 2010.
 * fullermd didn't look farther.
<vila> argh, tricky setup for auto_update_copyright
<vila> fullermd: thanks for the heads-up
<fullermd> Yay, +karma.  Maybe now I can scream at people today and still wind up even.
<vila> hehe
<mgz> so, yelling at vila means you get to yell at other people too?
<throughnothing> is there a way to view the diff of 2 separate branches in launchpad WITHOUT doing a merge proposal first?  I'd like to be able to send a link around and get feedback before doing a merge proposal
<fullermd> mgz: Well, you gotta warm up first.  Otherwise you might strain your vocal chords, see.
<vila> . o O (mgz: Perfect, I don't have to say it myself ;)
<vila> throughnothing: no. But once you've made the proposal, you can just push your additional commits (or even different ones if you use push --overwrite), lp will happily re-calculate the diff
<mgz> throughnothing: `bzr diff --old lp:<1> --new lp:<2>`?
<vila> mgz: he want to send a link (presumably one showing the diff)
<vila> throughnothing: is that ^ correct
<fullermd> And the diff of two branches probably isn't what you really _want_; you want more a preview of the merge.
<fullermd> (unless one branch is a strict superset of the other)
<mgz> that's true.
<throughnothing> mgz: thanks, yeah I know i can do this locally, I guess that'll have to do, just not as easy to get ppl to do that than to go to a link :)
<mgz> getting feedback before a merge proposal seems a little over-cautious to me
<mgz> just do an mp and say in the description you want feedback before doing more work on the branch
<vila> throughnothing: mps are intended to cover getting feedback too
<mgz> you can set the reviewers to specific people rather than the whole team for the project
<mgz> (if you don't want to bug everyone)
<throughnothing> mgz: ok, I just know that its not ready to be merged, and I know more stuff I have to do, but would like feedback on whats already done (for instance, I know i still need to add more tests)
<throughnothing> but I understand your point as well
<mgz> I do mps like that all the time :)
<throughnothing> haha ok
<throughnothing> i guess i can mark it as work in progress
<throughnothing> or something similar
<vila> throughnothing: yes, once you get feedback, marking as wip means... you're still working on it
<briandealwis> Hi jelmer.  I'm trying to use bzr-git 0.6.0 with bzr 2.4b2 but it fails as "TypeError: As of bzr 2.4 Testament.__init__() takes a Revision and a Tree.".
<briandealwis> So I thought I'd try from bzr-git from trunk, but it fails with "ImportError: No module named versionedfiles" at repository.py line 46 which does an import: "from bzrlib.plugins.git.versionedfiles import (GitTexts)"  and there's no definition for GitTexts
<jelmer> briandealwis, hi
<jelmer> briandealwis, fixed
<briandealwis> great, thanks!
<jelmer> I had a .pyc file around locally, which is why I must have missed it
<briandealwis> ah right
<mgz> dammit, forgot spell check
<NielsD> hi
<hbeck> hey, having an issue with qbzr package (qlog specifically):  bzr: ERROR: No module named configobj  You may need to install this Python library separately.
<hbeck> quick google says this issue has been seen before but I'm not sure what the fix was/is
<hbeck> I have bzr 2.3.1-0 and qbzr 0.20.0-1
<hbeck> also, python-bzrlib shows "/usr/share/pyshared/bzrlib/util/configobj/configobj.py" installed.
<maxb> hbeck: Could you please check versions with "dpkg -l bzr python-bzrlib qbzr" - 2.3.1-0 does not look like a real version to me
<hbeck> bzr                             2.3.1-0~bazaar1~lucid2
<hbeck> I just chopped the end off
<hbeck> python-bzrlib                   2.3.1-0~bazaar1~lucid2
<hbeck> qbzr                            0.20.0-1~bazaar1~lucid1
<hbeck> maxb: that help any?
<chx> why is it that though i have not configured an editor in bazaar.conf, i do not have $VISUAL and $BZR_EDITOR set and $EDITOR is set to nano I *still* get vi?
<maxb> hbeck: Hmm. I thought we'd got rid of all these problems. Maybe the qbzr package isn't new enough
<maxb> huh, this is probably something fixed in 0.20.1
#bzr 2011-05-14
<maxb> hbeck: An updated package is currently building, which should hopefully resolve the issue
<NielsD> is there a api in bzrlib to access the toplevel repository, in a local sandbox environmen ?
<bignose> NielsD: what is a âlocal sandbox environmentâ? how is it different from just a normal branch?
<NielsD> i have a repo holding a trunk, and feature1, feature2 for example, repo is initialized using bzr init-repo --no-trees
<NielsD> and i'm looking for a way to find the repo path from trunk, or any branch in the repo
<bignose> NielsD: from Python API, or from command-line?
<NielsD> api
<bignose> I don't know :-)  someone else will need to answer.
<bignose> NielsD: you could begin looking at how âbzr infoâ gets the repository location.
<NielsD> yeah, that's what i'm looking at now, realized it when i thought of the cli command :)
<bignose> chx: the code to figure out which editor to use can be seen in âbzrlib.msgeditor._get_editorâ
<bignose> chx: as best I can tell, the cascade is: âBZR_EDITORâ, global Bazaar config âeditorâ, âVISUALâ, âEDITORâ, then a sequence of defaults to try depending on the OS.
<bignose> chx: so, I suspect the environment variables are not actually set to the values you think they are, and it's falling back to defaults.
<chx> hrm i tried echo $BZR_EDITOR echo $VISUAL
<chx> both came back empty
<chx> but $EDITOR was definitely nano
<bignose> chx: if you can understand Python, the module I mentioned is the one which decides what to do.
<bignose> chx: so have a look, it might be different on your system (maybe the behaviour changed between the versions we're running
<chx> bignose: i understnad Python but  i can't write Python, i will check
<maxb> hbeck: There's an updated qbzr package in bzr/proposed that should help
<hbeck> maxb: thanks, I'll take a look
<DrHalan> hey, i need some help setting up a bzr server
<maxb> DrHalan: OK, what sort of help and what sort of server?
<DrHalan> i have a remote linux (ubuntu) server i access via ssh and i want to setup a bzr repository on that remote server to backup my code
<maxb> If Bazaar and SSH are both installed on the server, you do not need to do anything at all to start using bzr+ssh://user@host/path URLs
<DrHalan> sorry my xserver crashed :/
<DrHalan> are there any good tutorials on how to setup a bzr server?
<DrHalan> maybe someone already answered it but i lost the conversation due to the crash...
<maxb> If Bazaar and SSH are both installed on the server, you do not need to do anything at all to start using bzr+ssh://user@host/path URLs
<DrHalan> i just init a bzr repostiory on the server and then i can push to it ?
<maxb> Yes, and you don't even have to be on the server for the init step
<maxb> You can run bzr init-repo with a remote URL
<maxb> Technically you don't even need to create a repository first (in the absence of a shared repository each branch uses an internal repository) but it's usually advisable to take advantage of the space and bandwidth savings
<DrHalan> maxb, thats pretty straightforward :) and how do i add an ssh key to a new user on the server? (don't want to use the rootuser to push to my server)
<maxb> Did you intend anything bzr-specific in that question, or are you asking about generic OpenSSH usage?
<DrHalan> guess its a generic openssh question
<maxb> So, create the user, add the public key to ~/.ssh/authorized_keys ?
<DrHalan> okay :)
#bzr 2011-05-15
<mgz> this laptop better behave itself now I've spent all evening fiddling with it.
<mgz> well, except for debian bug #619019 which means I'll just not be running x I guess
<ubot5> Debian bug 619019 in src:linux-2.6 "xserver-xorg-video-intel: latest update to debian squeeze made the mouse pointer invisible in my openbox/gdm session" [Important,Fixed] http://bugs.debian.org/619019
<bob2> heh, I have an awesome hardware cursor bug that turns my cursor into a 64pixel long vertical black line
<mgz> that's cute.
<mgz> I'm now risking my evening's work with squeeze-proposed-updates to see if it's really fixed.
<mgz> and I have a cursor, woho. will stop now before I break something else.
<maxb> Does anyone know how to alter which key bzr-builddeb signs with by default *If* there are multiple secret keys with the same uid on the local keyring?
<AuroraBorealis> is that a plugin?
<lifeless> maxb: DEB_somethingorother
<maxb> gah
<maxb> Answer: Don't forget that you hardcoded your keyid in ~/.devscripts several years ago
<maxb> :-)
<maxb> Hmm, no jelmer
 * maxb wanted to propose uncommitting a rogue merge from the debian packaging branch
 * maxb bemoans obscure bzr-builddeb on karmic test failure
<maxb> If I have a lower layer exception, which gets caught by a command implementation and a BzrCommandError thrown instead, what's the correct way to make the lower layer exception not completely lost so that debugging can find the underlying cause?
<maxb> Right, I believe the proposed PPA is back in reasonably good shape
<meoblast001> hi
<meoblast001> is a .bzrignore file maintained across all checkouts?
<meoblast001> or is it custom to each individual checkout?
<lifeless> both
<lifeless> there is one in your config directory
<lifeless> and one in each working tree
<lifeless> the rules are merged
<meoblast001> ah
#bzr 2012-05-07
<lduros> how can I remove a remote branch?
<lduros> I tried bzr remove-tree ........
<lduros> no luck
<lduros> rmbranch :-)
<lduros> now i'd like to do the same for an entire repo
<BasicOSX> haven't seen a update to bzr.dev in awhile did the repo move? I've been at revision 6523 for several weeks.
<jelmer> BasicOSX: no, the repository is still in the same location
<BasicOSX> Did poolie take a job at Google?
<lifeless> wgz: around ?
<lifeless> wgz: I has a python3 IO question:
<lifeless> :!python3 -c "import sys; print(type(sys.stdin.read()))"
<lifeless> <class 'str'>
<lifeless> in subunit, we have a _make_stream_binary that you wrote
<lifeless> on Python3 its a no-op, but ... we still need it
<lifeless> to do something here
<lifeless> is pulling out .buffer 'ok' ?
#bzr 2012-05-08
<spm> ftr, I <3 $bzr log -l <number> <== that is all
<simX> Can anyone help me with the configuration of an external merge tool in bzr 2.5?
<simX> â¦ :(
<mwhudson> spm: $ bzr alias sl
<mwhudson> bzr alias sl="log --short -l 10"
<spm> mwhudson: but that would getin the way of sl(1)!!!!
<mwhudson> ah yes, i guess you already have conditioning around those letters
<spm> I can't forgo my train
<simX> bzr is giving me a "Option this is not defined while expanding" error when setting the cmd for an external merge tool.  What's the deal?
<LarstiQ> simX: what version of bzr, and what are you doing?
<mgz> morning all!
<simX> LarstiQ: 2.5.0, and all I'm doing is reading the config cmd I set.
<simX> bzr config --scope=bazaar bzr.default_mergetool=MyCoolMergeTool
<simX> bzr config --scope=bazaar bzr.mergetool.MyCoolMergeTool="mycoolmergetool --wait \"{this}\" \"{other}\" \"{result}\" \"{base}\""
<simX> Those seem to succeed.
<simX> But then I do this: bzr config bzr.mergetool.Kaleidoscope --scope=bazaar
<simX> And it gives me "bzr: ERROR: Option this is not defined while expanding "'mycoolmergetool --wait "{this}" "{other}" "{result}" "{base}"'"."
<LarstiQ> simX: that sounds like {this} is not expanded for some reason
<simX> Well, yeah, but why not?
<simX> I'm just setting the mergetool cmd and reading it back.
<LarstiQ> simX: looking at the code now
 * LarstiQ has never set a mergetool before
<simX> Me neither, thus I thought I was doing something wrong. :(
<LarstiQ> simX: it sounds like a bug
 * bialix waves on mgz
 * fullermd waves on bialix waving on mgz.
<LarstiQ> ah
<bialix> hi fullermd!
<simX> LarstiQ: As in, you think the merge tool should work and its just incorrectly giving me the error when reading the cmd back, or the merge tool cmd setting actually won't work?
<LarstiQ> simX: I don't know the code well enough, but I have an idea of what might be wrong
<LarstiQ> simX: based on the traceback that we get
<simX> Ah.  Where should I file a bug, then?
<LarstiQ> simX: I'm checking bzr 2.4 to confirm my hunch
<simX> Alright, thx for the help!
<LarstiQ> simX: So, I _think_ that the (new) config expanding of {option} is conflicting with the pre-existing mergetools expansion
<LarstiQ> simX: do you want to file the bug, or shall I/
<simX> I'm happy to file the bug myself, but it sounds like you might be able to add a little more info/context, so maybe you'd be better off doing it.
<simX> Do you see any possible workaround?
<LarstiQ> simX: not yet, let me dig some deeper
<mgz> lwn scares the crap out of me for no good reason again
<LarstiQ> mgz: how so?
<mgz> they really should pick headlines, and which third party articles to highlight, more carefully
<LarstiQ> simX: I don't see a workaround :/
<LarstiQ> mgz: the google article?
<mgz> "Google guilty of infringement in Oracle trial" ... is not actually the case
 * simX Incredible sadness. :(
<LarstiQ> simX: well
<LarstiQ> simX: you could use bzr 2.4..
<simX> 2.5 bug?
<LarstiQ> simX: yeah
<mgz> quoting the config file might be a workaround if that's it LarstiQ?
<LarstiQ> mgz: how does one do that?
<mgz> how does str.format normally want {} escpaed...
<LarstiQ> mgz: the issue is that config.py tries to expand {this}, instead of letting mergetool do it
 * mgz hasn't actually needed to do that
<mgz> ah, or blast, config doesn't use str.format but its own thing
<mgz> which probably doesn't have escaping support
<mgz> need vila, but french holiday today
 * LarstiQ nods
<LarstiQ> I'll file the bug anyway
<simX> Thanks.  So it basically means 2.5 is a no-go for external merge tools?
<mgz> looks like {{new}} might work?
<LarstiQ> mgz: didn't work for me
<mgz> darn.
<mgz> okay, so that should, which is one bug, and merge tools shouldn't clash, which is another
<LarstiQ> simX: Imo this warrants a bugfix release for 2.5, but at the moment, it looks like that :/
<simX> :\
<fullermd> Probably due for one when it gets fixed anyway.
<simX> LarstiQ: Welp, toss me a link to the bug once you've filed it, so I can track it?
<fullermd> Not all that much has happened, but it's been a couple months...
<LarstiQ> simX: will do
<LarstiQ> mgz: _expand_options_in_string: # We need to iterate until no more refs appear ({{foo}} will need two iterations for example)
<LarstiQ> mgz: so not sure about that one
<mgz> right, that's what I was reading
<LarstiQ> simX: bug 996401
<ubot5> Launchpad bug 996401 in Bazaar "mergetool config clashes with config option expansion" [High,Confirmed] https://launchpad.net/bugs/996401
<LarstiQ> mgz: is it polite to assign this to vila?
<mgz> we don't generally work that way, but I can bug him about it tomorrow which should do
 * LarstiQ nods
<simX> One more quick question: to actually get bzr to use the specified external merge tool, I have to install a plugin like qconflicts?
<vila> simX: nothing is really broken, 'bzr config <option>' want to display the value bzr will use. But in this specific case (a config template), the additional options are provided when the template is used so the error is "valid"
<simX> vila: Yeah, saw the updates in the bug.  Thanks.
 * simX Still a bit confused on how to actually get the external tool to launch, though.  Is qconflicts necessary?
<simX> Grr.. keep accidentally sending msgs as actions...
<vila> simX: as for your last question, there should be an option to chose the mergetool you want to use but I can't remember it offhand
<simX> I can't seem to find anything in the documentation. :(
<vila> file a bug for that
<simX> I've set the *default* merge tool, but I merged a branch and got conflicts, now not sure how to even launch the default tool automatically on the various files.
<vila> ha, can't help there, I don't use it myself ;-/
<vila> simX: bzr.default_mergetool and yes, qconflicts seems to be the way to use it
<jave> im having memory problems with bzr. ive tried several different bzr versions, so either the problem is in my repo, or in my os install
<jave> I use the fedora 17 prerelease, which has python 273
<LarstiQ> jave: what kind of problems?
<LarstiQ> vila: thanks for the update!
<jave> LarstiQ: well, in a merge from upstream, or a commit, bzr keeps allocating memory until my 6GB ram is exhausted
<LarstiQ> jave: ouch
<LarstiQ> jave: are large files involved?
<jave> this is the emacs repo, so no big files
<mgz> it's a pretty big repo... but not 6GB big
<jave> ive tried bzr 2.4, 2.5, 2.6
<jave> yes its a big repo
<LarstiQ> might it be trying to repack?
<jave> but im not doing anything fancy
 * LarstiQ  attempts a testcommit 
<jave> repack?
<mgz> jave, pastebinning, or posting to the mailing list, the tail of your .bzr.log where you run out of memory would be useful
<jave> mgz: ok
<LarstiQ> jave: once in a while bzr tries to gather smaller packs in larger ones
<jave> LarstiQ: can I tell it not to?
<mgz> vila: (should be holidaying but...) what I don't understand from what you've said is if just setting the right string in the config file should still work, as you appear to imply that but LarstiQ tested a bunch of stuff and couldn't get merge tools working on 2.5 at all
<LarstiQ> mgz: I didn't test the mergetool functionality itself, just the reading back
<jave> also I dont care about disk size efficiency, can I get bzr to trade disk efficiency for time efficiency?
<vila> what I said is that 'bzr config <option>' can't expand, nothing about the rest ;)
<LarstiQ> mgz: and for the reading back, {{this}} doesn't help
 * LarstiQ will test mergetools functionality once he figures out how to use it
<LarstiQ> jave: not that I know, but you can `bzr pack` yourself, if that is the problem
<LarstiQ> jave: I admit to shooting in the dark
<vila> i.e. you can't make 'bzr config <option>' succeed, but the template *is* valid and will be populated at the right time
<LarstiQ> jave: the other long shot that comes to mind is if you're not using the C extensions, but just pure-python
<LarstiQ> vila: right
<LarstiQ> jave: fwiw, I managed to commit a revision 108158 on my copy of emacs trunk. And my laptop has 700mb ram
<vila> LarstiQ, mgz: in the general case, expansion should occur by default. Templates are the exception and you must use stack.get('xxx', expand=False) and *then* call stack.expand_options(template, {'this': 'xxx', 'other': 'yyy'})
<LarstiQ> vila: and it's also possible to configure a template with bonafide option expansion?
<vila> yes
<LarstiQ> I see
<vila> the additional 'env' parameter to expand_options takes precedence but other references will still be expanded
<jave> LarstiQ: would you mind trying the branch in question?  bzr+ssh://bzr.savannah.gnu.org/emacs/xwidget/
<vila> LarstiQ: also, keep in mind that mergetools was introduced while the new config scheme was designed/implemented so it suffered from lacking features at the time and Gordon did his best
<LarstiQ> vila: aye
<vila> LarstiQ: i.e. if this was rewritten *today* the resulting code should be simpler
 * LarstiQ nods
<LarstiQ> vila: would it make sense to implement the templating in terms of the config option expansion?
<LarstiQ> if someone were interested in that
<LarstiQ> jave: branched, trying a commit
<vila> LarstiQ: totally
<vila> it's on my radar but pretty low on my TODO list :-/
 * LarstiQ nods
<LarstiQ> vila: I might want to do some bzr hacking in a couple of weeks
<vila> LarstiQ: you're welcome ;)
<LarstiQ> jave: `bzr merge ../emacs; bzr resolve --all; bzr ci -m "test test"` completed
<jave> hmm
<jave> thanks LarstiQ
<jave> LarstiQ: which bzr and python version do you use?
<LarstiQ> jave: lp:bzr and python 2.6 from Debian testing
<LarstiQ> jave: does your current .bzr.log have some useful info?
 * LarstiQ needs to lunch, bbl
<vila> LarstiQ: 'bzr resolve --all' is EVIL, use --take-this or --take-other but '--all' just blew up the conflicts without any attempt to properly resolve them (it really is a last-resort-everything-is-broken-restore-some-sanity option)
<fullermd> Sanity is overrated.
<simX> LarstiQ, mgz, vila: BTW, got the mergetool to work in 2.5.  Seems actually using the tool is fine, just reading it back using the `bzr config` throws the error.
<mgz> simX: great, that's what was unclear to me. could you post a short summary of what you needed to get it working to your question?
<simX> Yep, sure.
<simX> mgz: Done.
<mgz> ace.
<LarstiQ> vila: I know that, but I don't know the emacs code and didn't care about the conflicts. Just wanted to see if I'd get a MemoryError
<LarstiQ> simX: cheers! I get as far as qconflicts claiming none of the mergetools exist
<vila> LarstiQ: ok, sry for the knee-jerk reaction but '--all' should die ;) And feedback on --take-{other,this} in hostile envs *highly* welcome !
<vila> LarstiQ: as in: this *should* work and I think I fixed all known bugs there so new ones should be rare and fixed too
<LarstiQ> vila: I would normally use it to signify I handled all conflicts. It looks like --done can do that job now?
<vila> LarstiQ: yup, there is still work to be done to mark more conflicts resolved when the user already took the appropriate actions
<lifeless> wgz: hi ?
<bsd> Can anybody tell me how to undo a rename detected by an 'bzr mv âauto' (or 'bzr mv âafter a b')?
<bsd> â¦without losing the original rename, of course.
<fullermd> mv it bak?
<fullermd> Or back, even.
<bsd> fullermd: hmm, that would lose the original rename.  Using âafter might have worked but it throws an error
#bzr 2012-05-09
<mgz> morning
<jelmer> hey mgz
<mgz> is it samba thing this week jelmer?
<jelmer> mgz: yes
 * jelmer waves from gÃÂ¶ttingen
<james_w> hi jelmer
<jelmer> hey James
<vila> hi all
<lifeless> mgz: hi
<lifeless> mgz: did you see my query about .buffer on python3 ?
<mgz> hey lifeless, no, I didn't
<mgz> where should I be looking?
<lifeless> here
<lifeless> I addressed it to wgz, couple days back
<wgz> I see it.
<wgz> ...I'm not completely clear on what's okay with the new io library either, but do need something other than TextIOWrapper
<wgz> as I understand it, python 3 now turns off the newline translation itself, and does it in the text io instead
<lifeless> yah, have a look at what I put in 0.0.8
<wgz> and .buffer does look okay to me.
 * wgz pulls
<lifeless> (or trunk) and let me know how it plays on windows
<wgz> hm, I'm not crazy about type checking the read(0) return
<wgz> but I guess it's a neat hack
<wgz> I get some failures on trunk but they all seem to be tags related.
<lifeless> :(
<lifeless> you have testtools 0.9.15 ?
<wgz> ...nope, apparrently not, will update
<wgz> so, the other option it seems io wants for detecting the stream type would be `isinstance(stream, io.RawIOBase)` for byte streams
<wgz> but that's assuming people who write their own little classes subclass it, which people are not in the habit of doing with python
<wgz> or `isinstance(stream, io.TextIOBase)` which then promises a buffer attribute
<wgz> ...which I now note it says " is not part of the TextIOBase API and may not exist on some implementations" in the docs
<wgz> the io module has been a pain whenever I've need to do anything with it
<wgz> possibly should call detach() rather than just using the buffer?
<lifeless> wgz: I'm not sure, happy to take recommendations
<lifeless> wgz: there was a pycon presentation I found
<mgz> I shall try poking people/things this evening and see what falls out
<lifeless> that talks about using buffer (its presenting the io module)
<mgz> ah, I'll look for that as well later.
<lifeless> http://www.dabeaz.com/python3io/
<lifeless> its on slideshare or something too
<lifeless> which is where I found it
<LeoNerd> I have one bzr branch that stores some C library code; it has a src/ and an include/ directory
<LeoNerd> Is there some way I can "mount" those two dirs in the same place in a different branch's checkout?
<bsd> LeoNerd: you can check out a branch within a branch
<LeoNerd> bsd: Yes, but just some subdirs of it..?
<bsd> LeoNerd: check out 'bzr help view'
<LeoNerd> Ah OK thanks
<KombuchaKip> Are there any plans to port the nautilus-bzr integration to Thunar, the native Xfce file manager?
<jelmer> KombuchaKip: not that I'm aware of
<KombuchaKip> jelmer: Thank you.
<jelmer> KombuchaKip: the nautilus-bzr is also pretty crappy atm, so I'm not sure if it's worth porting
<jelmer> KombuchaKip: it might be a good idea to extend rabbitvcs to support bzr
<KombuchaKip> jelmer: Yes, that's another option.
<Noldorin> can bzr push remember FTP passwords?
<Noldorin> also, what's the bzr equivalent of "git checkout" ?
<mwhudson> i guess switch, mostly, but well
<mwhudson> git checkout does a few things
<Noldorin> mwhudson, i thought switch was a loom plugin though?
<mwhudson> no
<Noldorin> that's what it says in bzr help :-S
<mwhudson> loom wraps switch i think
<mwhudson> but it's in core
<Noldorin> oh right
<Noldorin> okay
<Noldorin> might be nice to show that in bzr help, but i got it now :-)
<Noldorin> mwhudson, incidentally, bzr switch gives me a maximum recursion depth error
<Noldorin> bzr 2.6
<jelmer> Noldorin: bzr-loom?
<Noldorin> jelmer, 2.3.0dev
<jelmer> Noldorin: uninstalling it might fix it
<Noldorin> okay
<mgrandi> ok, so i'm really confused on how i'm supposed to resolve conflicts in bzr. I'm using this external tool, which seems to want to resolve all the changes into the '.BASE' file, but then bzr doesn't have an option to use the .BASE file, only OTHER and THIS
<Noldorin> jelmer, cheers.
<mgrandi> how should i be using these third party tools then? or what file should i be editing?
<Noldorin> jelmer / mwhudson any idea bout saving the the FTP password btw?
<mwhudson> Noldorin: i think it's possible, maybe involving ~/.bazaar/authentication.conf
<mwhudson> but i certainly don't know
<Noldorin> ah
<Noldorin> will have asearc, ta
<jelmer> Noldorin: you can stick it in netrc or authentication.conf
<mwhudson> Noldorin: bzr help authentication maybe?
<Noldorin> jelmer, netrc? i'm on windows
<Noldorin> jelmer, but yeah authentication.conf sounds good. cheers
<Noldorin> where does it belong on windows?
<Noldorin> win7
<Noldorin> oh wait; think i've found it
<mgrandi> *pokes about merging conflict question*
<jelmer> mgrandi: sorry, I have no idea about that
<mgrandi> well how does everyone resolve conflicts is what i'm asking
<mgrandi> what file do you edit?
<Noldorin> jelmer, btw, i am thankfully git-free at the moment, so no need for bzr-git fix yet...
<Noldorin> jelmer, if someone wanted a project (like a mirror of mine) in git, could they pay you to fix up bzr-git though? ;-)
<mgrandi> whats wrong with bzr-git? seems to work fine for me o.o
<Noldorin> it's broken for commits where files get moved
<Noldorin> and some other slightly unusual cases.
<Noldorin> and some other slightly unusual cases.
<mgrandi> (the only featured i'd like to see is native push support rather then dpush with rebasing the tree)
<Noldorin> mgrandi, i'm pretty sure that's impossible due to the differences in how bzr and git work with commits
<mgrandi> jelmer mentioned its possibly by just storing information in a magic file that git can't represent natively =P
<Noldorin> information that git can't represent natively in a magic file, you mean?
<mgrandi> yeah.
<mgrandi> or something along those lines
<Noldorin> yeah, might work... he knows how it works, naturally
<jelmer> native push support can indeed be done with a magic file where metadata that can't be represnted in git is stored
<Noldorin> can someone pay you to do that too? :-)
<Noldorin> heh
#bzr 2012-05-10
<Noldorin> hah
<Noldorin> silence...
<mgrandi> heh
<mgrandi> i'm still confused on how to do conflict resolution. every 'tool' ive tried sucks or does it wrong
<mgrandi> might as well just edit them by hand
<Noldorin> mgrandi, OS?
<mgrandi> any of them, mac windows or linux
<Noldorin> at the worst, use bzr resolve from the command line
<Noldorin> on windows i use winmerge
<Noldorin> kdiff3 is also fine on windows and linux
<mgrandi> well what file should it be 'merging into'
<mgrandi> is really my question
<mgrandi> the one i was using was merging everything into base, and bzr doesn't like that
<Noldorin> yeah, merge into the normal file
<Noldorin> no extra extension that is...
<mgrandi> hmm
<mgrandi> cause the one i was using on mac, DiffMerge asked me for the left right and 'ancestor file'
<mgrandi> and that was this other and base, and had me merge into base..
<Noldorin> http://doc.bazaar.canonical.com/beta/en/user-guide/resolving_conflicts.html
<Noldorin> mgrandi, read that
<Noldorin> download WinMerge and/or KDiff3
<Noldorin> they are the best tools, at least on Windows
<Noldorin> and then you're sorted
<Noldorin> use bzr qresolve for a GUI resolve
<Noldorin> or specify via the command line
<mgrandi> hmm
<Noldorin> so yeah, actually you can merge "into" any of those 3 files
<Noldorin> but bzr looks ofr an extensionless one at the end
<Noldorin> so you either have to create a new file that is the result of the merge...or rename an old one
<mgrandi> hmm
<mgrandi> ok
<Noldorin> brb
<vivekimsit> I have one doubt! I did a checkout of a branch, I commit some changes locally and saw that the branch from which I did the checkout has also done some changes after my checkout. What should I do?
<spiv> vivekimsit: depends on what you want to do :)
<spiv> vivekimsit: you might want to use 'bzr update', and integrate both sets of changes
<spiv> vivekimsit: if you want to discard your changes, or their changes, you'd do something different, etc.
<vivekimsit>  spiv: ok! so bzr up will integrate both the changes, no matter I have committed to my local or not!
<mgz> morning
<mgz> wonder if isp has reason for net having been down all night...
<fullermd> The electrons were spun down for refueling.
<crisb> is there a hook I can use that only gets run when doing a bzr update?
<jelmer> crisb: you can use the post_branch_tip_change hook, but that gets called for pull and push too
<jelmer> crisb: another option is to register a command hook and in that hook check if the command being run is update
<mgz> right, command hooks were added in 2.6, but you probably want one of the branch changed ones really
<crisb> can i do it so that it runs before the update using pre_branch_tip_change?  i'd like to bind the branch before update.
<mgz> ...it might help if you go back a few steps and say what you're actually aiming at
<crisb> sure, I'm doing a plugin to ensure that when someone does a bzr update they're always getting the latest stuff from the master branch, so i'd like to bind before updating, do the update and then unbind
<mgz> what prompted this? people pulling from the wrong branch?
<crisb> more like people doing update when unbound, finding no changes and then assuming they have the latest.
<mgz> I use update quite a bit to do things between local branches, I don't want to operate on a remote branch unless I pull explicitly on a branch with a remote parent
<mgz> I'd suggest instead of a hook touching update,
<mgz> that if you really want to do something to fit in a funny workflow like this, you do a plugin with a new command that does whatever fancy dance you need and tell people use that instead
<mgz> update does useful things not related to getting the newest code in a bound branch, changing that behaviour in a plugin is likely to break things
<crisb> what makes it a funny workflow? (it's not my workflow so i'm not necessarily saying I dont think it's funny :)
<mgz> if I understand correctly, people have a bound, but non-pristine, copy of a remote trunk, which is just asking for accidents
<mgz> either need a bound pristine copy of trunk, which would then complain if you try and merge a feature branch onto it when it's out of date
<crisb> sort of, usual workflow is they have an unbound version of a trunk, then do their work, commits la la la, then when they want to 'commit' their work to the server, they bind, update and commit the single revision, and unbind
<mgz> or just a copy of trunk that `bzr pull` will update
<mgz> ^right, that seems to be asking for problems to me
<mgz> is this a huge project that people don't want more than one working tree of around at a time?
<crisb> not massive no
<crisb> they're heavyweight checkouts anyway
<mgz> just seperating out the branch for hacking on from the copy of trunk would simplify things no end
<crisb> you're talking about having feature branches which someone merges onto the trunk?
<mgz> right, which is basically what they're doing currently, but by unbinding trunk to diverge rather than branching
<crisb> ok thats how my team operates
<crisb> they branch, hack, push to a dev location, i merge them in.
<mgz> they can still merge onto a local bound trunk themselves when they're done
<mgz> but with a merge between the two local branches operation, rather than bind/update
<crisb> this would avoid losing the history of their local commits too wouldnt it
<mgz> the history is always there, log just shows the mainline only by default
<crisb> sorry i mean if you bind to a trunk all your local updates become uncommitted and the history lost right?
<mgz> hm, I'm not totally sure what happens in that case as I've never tried binding a diverged branch, but it's something like that
<crisb> ok so you're saying have two copies of the branch, one bound, one unbound.  hack on the unbound one then merge using the bound one
<mgz> okay, so the effect is the same as the merging would be, your local commits get moved to a pending merge on the right hand side
<mgz> crisb: right, that's simpler to get right I think
<mgz> and when something goes wrong, it's easier to fix it too
<crisb> how so?
<mgz> the bind/update thing makes it hard to recover your local state if you can't commit
<crisb> hmm why wouldnt you be able to commit?
<spiv> Especially as update will default to attempting a merge even when you have uncommitted changes, whereas merge will stop (and require you to use --force if you really want to risk making that sort of mess)
<mgz> with seperate branches, you can just revert a messy merge conflict without worrying, because the other branch still has all your work right there
<spiv> ("that sort of mess" == having uncommitted changes mixed in with changes merged from another branch in a way that's hard to undo)
<crisb> hmm that's true.  ok so i do my bind, then update and I get loads of conflicts.  yikes!  so no way I can get out of it without resolving all conflicts?
<crisb> (without a breakdown)
<crisb> :)
<mgz> not easily, nope.
<crisb> hmm i wonder how that's never happened before then
<mgz> whereas with a feature branch you can declare conflict bankruptcy at any point
<crisb> the 'binders' team = largish and mainly inexperienced
<crisb> my team = small and very experienced
<spiv> crisb: if you've always committed the changes before updating (even just local commits) you don't get the problem
<crisb> spiv: why not?
<spiv> crisb: but really, it sounds like you're trying to have a feature-branch workflow, so just use branches :)
<spiv> crisb: because you can recover a committed state (that's large part of the point of committing it!)
<mgz> my impression is documenting a sensible way of working for the binders bunch based on what your guys do is a better use of your time than writing a plugin to make their way less error-prone
<spiv> crisb: but if you haven't committed, and then do a conflicting update then you don't have a way to 'bzr revert' (or any other simple command) back to the the state you had just before the update
<mgz> as for why they've not had issues... you can get out of a lot of trouble by blowing away history
<mgz> but it's generally best not to.
<crisb> mgz: agreed, i'm more of a fan of educating people than walled gardens, but i'm just the plugin guy :)
<crisb> i think they basically want to avoid the whole gatekeeper issue
<crisb> automated or not
<crisb> but i dont really think that goes hand in hand with a plugin that treats everyone like a moron..
<crisb> because if they cant even work out when they've not updated to the master copy, why would you trust them to fix any conflicts they come across?  there's no oversight then, their way of fixing the conflicts is on the trunk.
<crisb> or am i missing something?
<mgz> with better errors (which merging into a bound pristine trunk should give over the current way) and a few cheat sheet things like how to use --take-this and --take-other in bzr resolve, it should be harder to get wrong
<crisb> hmm it's harder to sell though, because they then need to do a separate merge on another tree which could lead to more mistakes
<mgz> well, it's the same underlying steps, seperating out the update from the merge means forgetting the update is safe
<mgz> you get prompted if you try to commit to the bound branch if it's not up to date, then if you blow things up doing update, you can just revert and merge the feature branch again
<bobweaver> Hello there is there a mailing list for the development of bzr and or bzr explorer as I am using them 20 + times a day. so if there is mailing list of up and coming things that are happening I would love to know thanks for your time
<sagaci> http://wiki.bazaar.canonical.com/BzrSupport
<bobweaver> Thanks
<Noldorin_> ho hum
#bzr 2012-05-11
<mgz> morning
<vila> morning mgz
<fullermd> Oh, not again.
<mgz> 'fraid so fullermd
<fullermd> So, I guess the lack of response means that nobody else is bothered by that wretched uncommit log output?
<mgz> you mean the thing where it says from revX to revX that you posted?
<fullermd> Yah.
<mgz> it's not great, don't think we have a neat way of printing rev ranges for logging, but adding three lines to fix it would be accepted if proposed I'd think
<fullermd> Well, I'd imagine not so much "add a neat way" as "fix the bug"...
<fullermd> It's already obviously trying to print both.  It's just failing.
<mgz> hm, that's not how I saw it
<mgz> looked like it was just handling the case where the first rev removed is the same as the last rev removed (ie, uncommiting one rev only)
<fullermd> I read the log message as [intending to be] meaning "uncommitting from [old head that's disappearing] to [new head]"
<mgz> it's clearly not clear :)
<fullermd> If that's not what it's trying to express, definitely not...  it hadn't occured to me that it _could_ be meaning anything else.
<mgz> what's the git equiv. of `bzr info`?
<mgz> just bzr info should work, but bzr-git isn't showing me the origin url
<mgz> I guess `cat .git/config` works
<fullermd> For showing locations, I think something under 'git remote'?
<mgz> seems `git remote -v show` does something reasonable there
<mgz> ...with show not being required
<fullermd> Now if you'll excuse me, I have to go cry in a corner at the realization that I had that bit of info in my head...
<frathgeber> quick stupid question (should be straightforward but just can't figure it out right now): i have a bare remote repo, which i want to revert to a previous revision
<frathgeber> bzr push -r <rev> doesn't change the remote revision
<frathgeber> update and revert also don't work since they only affect trees, not branches
<frathgeber> how can this be done?
<frathgeber> obviously i could delete the branch and re-create it, but i figured there must be an easier way?
<frathgeber> ok, i could edit .bzr/branch/last-revision, but that seems even less straightforward
<frathgeber> in case it matters: the branch is part of a tree-less shared repo
<spiv> frathgeber: push --overwrite -r REV
<frathgeber> nope, tried that
<frathgeber> note that the local and remote branches haven't diverged
<frathgeber> i just want go back to a previous revision on the remote branch
<spiv> What happens when you try that?
<frathgeber> behavious is the same as without --overwrite
<spiv> (e.g. do you get an error or warning, or anything like that?)
<frathgeber> actually thinking about it my question doesn't have anything to do with remote or bare branches
<spiv> bzr push --overwrite -r REV LOCATION_OF_BRANCH
<frathgeber> the same goes for a local branch: how do i revert to a previous revision?
<spiv> (perhaps your default push location is not the location you want to change)
<frathgeber> i know i can revert the tree using update -r or revert -r
<frathgeber> no, also not the problem
<spiv> I use push --overwrite or pull --overwrite to do that.
<spiv> Does it give any output at all?
<frathgeber> you're sure that works?
<spiv> Yes, or I wouldn't keep suggesting it :)
<frathgeber> it says no revisions to push
<spiv> (This is exactly what the --overwrite option is for)
<frathgeber> is your remote branch using a shared repo?
<spiv> Ah, yes, but did you check if the branch changesd?
<frathgeber> the overwrite option is for pushing despite the local and remote branches have diverged in my understanding
<frathgeber> it doesn't
<spiv> More generally, --overwrite is for forcing the branch's last-revision to change w/o the divergence or going-backwards check.
<frathgeber> ok, that would make sense and suggest it should work for my case
<frathgeber> odd
<spiv> The "no revisions to push" message is a bug here, really.  It's technically correct (to make the branch point to an older revision requires transferring no new revisions, because obviously they're already there), but gives a misleading impression.
<frathgeber> i figured out the bug
<frathgeber> the order of arguments matters
<frathgeber> push -r <rev> --overwrite doesn't work, push --overwrite -r <rev> does
<frathgeber> that is an actual bug
<spiv> I really doubt that makes a difference.  If it does then please do file a bug.
<spiv> But that would be hugely surprising.
<frathgeber> odd, can't reproduce it now
<frathgeber> but it defintely didn't work when i tried it before
<spiv> How were you verifying?
<frathgeber> first of all it said 'no new revisions to push' in both cases, i still have it right there in my shell
<frathgeber> also i checked .bzr/branch/last-revision
<frathgeber> which was unchanged
<spiv> Like I said, "no new revisions to push" is expected in this case.
<spiv> Checking .bzr/branch/last-revision or the output of "bzr revision-info -d LOCATION" would be definitive.
<frathgeber> in the successful case it prints 'pushed up to revision <rev>'
<frathgeber> can reproduce it now
<frathgeber> and the order of parameters doesn't matter
<frathgeber> it doesn't work either way
<frathgeber> explicit push location doesn't help either
<frathgeber> even more irritating: it works when i pushe the very same branch to the very same remote shared repo under a different name
<frathgeber> subsequently i can revert the tip
<frathgeber> now i can't any more, remains broken
<spiv> frathgeber: please file a bug
<spiv> frathgeber: --overwrite should work (or give a clear error if it needs to fail, e.g. because branch.conf has append_revisions_only = true.
<spiv> (or whatever the spelling of that option is)
<frathgeber> it's even more irritating
<frathgeber> if i initially create the remote branch with a push -r <rev>
<frathgeber> subsequent push --overwrite -r work
<frathgeber> if i initially create the remote branch with a plain push subsequent push --overwrite -r do nothing
<spiv> frathgeber: I strongly suspect there's something wrong in your diagnosis
<spiv> frathgeber: because how a branch is created just doesn't vary interestingly because you used push vs push -r
<spiv> frathgeber: but feel free to check by diff'ing the resulting .bzr/branch directories
<spiv> frathgeber: unfortunately I need to sleep now so I can't help you narrow down your problem any further
<spiv> frathgeber: good luck
<ciupicri> how can I see the version from ~2003 of http://bazaar.launchpad.net/~openerp/openobject-server/6.1/files/head:/openerp/report/render/rml2pdf/ ?
<frathgeber> i did
<frathgeber> literally the only difference is .bzr/branch/last-revision
<frathgeber> spiv: thanks for your help!
<spiv> ciupicri: through the web UI alone: with difficulty (click "view branch changes" and page through the results and/or url hack)
<spiv> ciupicri: with the bzr command line, something like "bzr log -r date:2003-01-01 lp:~openerp/openobject-server/6.1" (it won't be as fast as it could be in principle, but it should work)
<spiv> ciupicri: (and then once you've found the rev using bzr log jump to that revision in the web site, or use other bzr commands to view the contents)
<spiv> ciupicri: FWIW, the earliest rev in that branch dates to 2006
<ciupicri> spiv, the comand line is fine
<spiv> ciupicri: http://bazaar.launchpad.net/~openerp/openobject-server/6.1/changes/1
<ciupicri> spiv, so I should check the trunk branch?
<spiv> Perhaps, depends on how the branches were created
<spiv> Or possibly that old history was discarded rather than imported into bzr
<ciupicri> spiv, ok, I'll rephrase my request: how can I get the oldest code possible on my hard disk? I have run `bzr branch lp:openobject-server/6.1 6.1' and I would like to see how the project looked some time ago
<spiv> -r 1
<spiv> Well, that's for a given branch
<spiv> But how to find the branch with the oldest data is more a problem for Google than bzr...
<ciupicri> bzr and what command? checkout?
<spiv> Most bzr commands accept -r, including checkout and branch
<spiv> Anyway, I really should sleep.
<spiv> G'night all
<ciupicri> thanks
#bzr 2012-05-12
<rly> How can I just update to the latest version of a repo while deleting everything in my working copy?
<tsousa> how can i search for a file in bzr source controled applicartion?
<jelmer> tsousa: bzr-search can search
#bzr 2012-05-13
<kaziweb> Hello, I'm very new to bzr. I've just installed it. how can I use it for translation?
<kaziweb> can any one help me on this?
<kaziweb> hello
#bzr 2013-05-07
<jml> what's the command that deletes files that haven't been bzr added?
<vila> jml: clean-tree ? But read the help for caveats
<jml> vila: thanks.
<LeoNerd> If I have a machine with an old version of bzr, can I push in such a way as to create a format old enough it can read?
<LeoNerd> It's 1.5
<SamB> LeoNerd: hmm ...
<SamB> LeoNerd: I can't see how to specify rich-root in current versions of bzr; I guess you could try creating the branch using the old version?
<LeoNerd> I wonder if I can downgrade a push of it to pack-0.92
<LeoNerd> Hrm.. :/
<LeoNerd> No, complains about rich-root
<LeoNerd> I wonder if it'd be easier to sshfs mount the server and not have to run bzr remotely
<SamB> LeoNerd: try upgrading the branch to use rich-root?
<LeoNerd> The branch is using rich-root. It complains it can't downgrade it to pack-0.92 because of that
<fullermd_> There are pre-2a rich root formats.
<LeoNerd> Hmm, but any that 1.5 will understand?
<fullermd_> rich-root-pack I believe is pack-0.92+richroot.
<LeoNerd> Hmmm
<SamB> fullermd_: I don't see that in "help other-formats" on my modern bzr :-(
<SamB> I also don't see --rich-root listed anywhere
<jelmer> SamB: --rich-root-pack was introduced in 1.0 and supports rich roots
<jelmer> it's marked hidden to discourage people from using it
<jelmer> (and to cut down on the noise)
<SamB> well, it seems like the format should be listed in other-formats since that's where deprecated formats are supposed to be listed ...
<fullermd_> We'd have to list all the way back to weaves (I'm not sure we support the pre-weave formats anymore).  That gets to be a long confusingashell list.
<fullermd_> You get people using dirstate-tags because they know they want to use tags, frex.
<SamB> I'm not saying every single one should be
<SamB> but this is an important variant of pack-0.92
<fullermd_> Anything pre-2a is so positively ancient, people who don't already know them shouldn't ever hear of them.
<fullermd_> I mean, 2a came in in 1.16.  4 years ago.
<SamB> sometimes one needs to refresh ones memory
<fullermd_> It wasn't, really; before 2a, rich roots were the odd variant out.
<SamB> it was important since it was needed for bzr-svn, though
<fullermd_> Yeah, that's what I said: "odd"  ;)
<SamB> it's more useful than development-colo ...
<fullermd_> Well, see?  And look at who's behind both of them!   :p
<fullermd_> Now we know who to blame for the bzr-has-too-many-formats meme!
 * jelmer ducks
<LeoNerd> Hey jelmer; how's it going?
<jelmer> hey LeoNerd, I'm doing well - still learning
<LeoNerd> :)
<LeoNerd> You'll get that for a while
<jelmer> LeoNerd: How are you? What are you up to?
<LeoNerd> I seem to be getting into some freelance+contracting arrangements currently
<LeoNerd> Or.. somesuch. Not quite sure how to arrange it yet
<jelmer> what sort of area?
<jelmer> SamB: unfortunately bzr-svn will probably disappear soon, unless somebody steps up to fix its compatibility with svn 1.7 and later :-(
<SamB> that *is* unfortunate
<SamB> why do they have to keep screwing with the API :-(
<jelmer> well, s/disappear/working copy
<jelmer> well, s/disappear/working copy support will break and the tests will stop working/
#bzr 2013-05-08
<nicferrier> looking for some bzr help please! I've done bzr branch location local-branch-name twice, with 2 upstream branches... but bzr branches still just shows me "*" as the sum total of branches. am I doing something wrong?
<nicferrier> (I'm guessing "yes")
<LarstiQ> nicferrier: recent bzr will look at colocated branches for `bzr branches` iirc
<LarstiQ> nicferrier: what do you want `bzr branches` to do?
<LarstiQ> nicferrier: if you're not using colocation, then `ls` might be fine
<nicferrier> LarstiQ: thanks. I was being stupid. I was expecting co-located branches. never mind me :-)
<LarstiQ> nicferrier: right, so I guess the two branches you made were not colocated?
<nicferrier> LarstiQ: right.
 * LarstiQ wonders how to branch into colocation
<jelmer> LarstiQ: the only real way at the moment is "bzr branch URL co:local"
<LarstiQ> jelmer: the co: is not working here for some reason
<jelmer> LarstiQ: what version of bzr are you running?
<jelmer> I think it only works with 2.6
<LarstiQ> jelmer: bzr.dev
<jelmer> LarstiQ: hmm, not sure what's happening in that case. There is a branch in your current directory?
<LarstiQ> jelmer: I'll have to dig into the reason for the directory lookup not working, but not now
<LarstiQ> jelmer: fwiw, the error is  'bzr: ERROR: Unsupported protocol for url "co:apart"'
<jelmer> LarstiQ: are you sure that's bzr.dev?
<LarstiQ> jelmer: `~/src/bzr/bzr.dev/bzr branch ~/src/bzr/bzr.dev co:apart`
<LarstiQ> jelmer: fairly sure
<LarstiQ> ah
<LarstiQ> but maybe bzr.dev has a colo branch?
<LarstiQ> nope, that's not it
<jelmer> LarstiQ: that shouldn't matter - it would only copy the active branch anyway
<LarstiQ> jelmer: no I mean, the bzr I'm using might be on old branch
<jelmer> LarstiQ: I wonder if perhaps we don't do directory lookups for the second argument to zr branch'
<LarstiQ> but I just pulled from lp:bzr
<jelmer> LarstiQ: either way, this stuff is unfinished :-(
 * LarstiQ nods
#bzr 2013-05-10
<Wiz_KeeD> hello fellas!
<Wiz_KeeD> Can someone help about a bit? I've been reading tutorials about trees and repositories and all that and can't get my head around it
<Wiz_KeeD> I have a setup where there is a ubuntu machine that i push my work to from localhost if it works on localhost
<Wiz_KeeD> what is the best setup for this case?
<bob2> how'd you come to be using bzr?
<bob2> and http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
<Wiz_KeeD> :)
<waltermundt> question: what's the repository syntax for using bzr-git to branch a local git repository
<waltermundt> I tried both 'git:///path/to/git/repo' and 'git://localhost/path/to/git/repo'; neither one worked
<fullermd_> I'd assume you just give the path, no git://anything.
<waltermundt> ahh, yeah, that seems to "work"
<waltermundt> where by "work" I mean crash with a KeyError from dulwich.object_store for a commit hash
<waltermundt> running whichever bzr-git is in precise, which may be related
<waltermundt> looks like it's the HEAD's hash
<waltermundt> thanks for the tip though
<waltermundt> I figured I'd need to tell bzr to think in git somehow, but I see from the bzr-git code that it actually notices the .git being there
<waltermundt> ls
<waltermundt> oops, sorry
#bzr 2013-05-12
 * KombuchaKip reminds everyone Sunday is Mother's day in case they forgot.
 * KombuchaKip should have clarified that this is at least the case if you're in Canada.
#bzr 2014-05-05
<Wiz_KeeD> hey guys
<jelmer> hi Wiz_KeeD
<Wiz_KeeD> how are you jelmer ?
<jelmer> Wiz_KeeD: not bad - yourself?
<Wiz_KeeD> pretty good
<Wiz_KeeD> I have a, somewhat of a newbie question
<Wiz_KeeD> If I have a branch that's the "master/stable/original" whatever you want to call it
<Wiz_KeeD> And I branched out to try some experimental stuff that now seem to work and would like to include in the stable version, how would I do that so I don't loose the progress I've done on the original since the second one was branched from it?
<serg> jelmer: may I ask about bzr-git plugin? you've removed BaseObjectStore::get_graph_walker from dulwich on 2013-11-10, but bzr-git still uses it.
<jelmer> serg: it's moved from the object store to the repo
<serg> I've grepped it out there, yes. but how to fix bzr-git?
<jelmer> a similar change would have to be made in bzr-git
<serg> sorry, I don't think that's enough for me :( I can dig out the history in bzr, or grep, but I don't know what a "simialr change" is in this case. your patch in dulwich simply removed the method
<serg> how to get repository from BazaarObjectStore?
<jelmer> serg: that method has basically been moved up one layer
<jelmer> an object store is a part of a repository
<serg> bzrlib.repository?
<jelmer> in this case a git repository
<serg> yes, InterGitNonGitRepository is a repository. ok, let me try
<jelmer> serg: InterGitNonGitRepository is not a repository, but an interobject that works between two repositories
<serg> aha, yes, I see it
 * serg shouldn't have trusted the name
<serg> I don't see a repository accessible from InterRemoteGitNonGitRepository.fetch_objects(). Should I create it there together with BaazarObjectStore?
<jelmer> serg: there should already be access to the repository at that point
<serg> then I cannot find it
<jelmer> self.target presumably
<jelmer> that's the bzr repository
<jelmer> not sure about a git wrapper for that, we might have always just gotten away with just wrapping the object store
<serg> self.target and self.source are bzr Repository objects, not dulwich Repo objects
<serg> and get_graph_walker is in Repo
<jelmer> serg: right, so I don't recall if I ever added a wrapper that implements the Dulwich Repo API on top of the bzr repository API
<jelmer> I might not have, if we got away with just doing ObjectStore
<serg> okay, so how to fix bzr-git then?
<jelmer> you might have to add such a wrapper
<serg> heh, cool. that's not a simple fix. especially and I am neither bzr nor python hacker :(
<jelmer> serg: somebody just proposed (as in, in the last 5 minutes) a patch that might address this
<jelmer> https://code.launchpad.net/~ace17/bzr-git/dulwich/+merge/218313
<serg> thanks! looking
<jelmer> serg: sorry :( bzr-git has been in dire need of a new maintainer for more than a year now
<serg> I've seen few commits this year, so I believed somebody is looking after it
<serg> anyway, thanks for the patch!
<jelmer> serg: I did maintainance fixes until a year or so ago, I don't think anything has happened since
<serg> the patch doesn't quite work, but it's something I can try to start from....
<serg> got it, thanks
 * serg kind of hoped there was a "proper" fix for this bzr-git issue... oh, well
#bzr 2014-05-07
 * fullermd is seeing occasional insta-500's from wiki.bazaar.c.c.
<fullermd> 's pretty slow when it does render a page.  Load?
#bzr 2014-05-08
<dhon_> hi all
<dhon_> I'm trying to build "KiCad" on OS-X following http://en.wikibooks.org/wiki/Kicad/Installing_on_Mac_OS
<dhon_> it fails on step 2: bzr branch 'lp:~kicad-lib-committers/kicad/library'
<dhon_> saying that I need to login to launchpad to "write to Launchpad or access private data"
<dhon_> given that this is the recommended way of building this program on OS-X, I wouldn't have thought they would require everyone to have a launchpad account
<dhon_> is there an alternate command that might branch this from a public location?
<dhon_> or should I just login to launchpad (I might even have an account somewhere)
<jelmer> dhon_: that's not an error, but rather a notice
<jelmer> dhon_: it shouldn't be relevant since you're not actually trying to write to launchpad
<dhon_> jelmer: I've now uploaded ssh pub key to launchpad and it authenticates okay, but I'm now getting: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/".
<dhon_> looks like this is a known issue though: https://github.com/KiCad/KicadOSXBuilder/issues/21
<dhon_> however, reading that page I can't see a working solution
<jelmer> dhon_: that branch doesn't exist - that's not a bzr issue
<dhon_> never mind, looks like there are known issues with building KiCad on OS-X that haven't been addressed as there isn't much demand for it
<dhon_> thanks for the help jelmer
#bzr 2014-05-11
<SamB> % bzr list-branches lp:~doko/binutils/
<SamB> bzr: ERROR: Invalid url supplied to transport: "lp:~doko/binutils/": ~doko/binutils is too short to be a branch name. Try '~<owner>/+junk/<branch>', '~<owner>/<product>/<branch> or '~<owner>/<distribution>/<series>/<sourcepackage>/<branch>'.
 * SamB grumbles
<jelmer> SamB: list-branches is mostly for colocated branches
<thumper> heh, launchpad is 'special'
<SamB> indeed
<jelmer> SamB: my plan was to add a smart server verb for "list-branches" and have launchpad provide a custom backend for that
#bzr 2015-05-05
<cmars> hi, i'm trying to bzr branch an https:// url but outbound port 80 is blocked. bzr seems to hang up on this POST to an http://.../smart URL. is there a way to skip, ignore or disable that unencrypted request?
<cmars> for example, if I do: bzr branch https://launchpad.net/godeps
<cmars> i get bzr: ERROR: Connection error: while sending POST /~godeps-maintainers/godeps/trunk/.bzr/smart: [Errno 110] Connection timed out
#bzr 2015-05-06
<vila> cmars: $ bzr branch https://launchpad.net/godeps
<vila> Branched 29 revisions.
<vila> cmars: may be you hit lp when it was done ?
#bzr 2015-05-09
<GyrosGeier> hi
<GyrosGeier> I have an automated build in Jenkins that requires a branch to be merged to succeed
<GyrosGeier> in that branch are two new files
<GyrosGeier> when the next build starts, bzr pull --overwrite is run
<GyrosGeier> which rolls back all the changes, but leaves the files
<GyrosGeier> which leads to a conflict when redoing the merge
<GyrosGeier> is there a better way to do this?
<GyrosGeier> http://ci.kicad-pcb.org/job/kicad-windows-msvc/cpu=x86,label=windows/lastBuild/console  is the build log
<fullermd> Are you committing the merge, or just running on the dirty WT?
<GyrosGeier> just the dirty tree
<fullermd> You probably want to run a 'revert' at the end (or before the pull at the start of the next one).
<GyrosGeier> I can easily create a commit from that, but the build process looks at the bzr id and creates a version string from that
<GyrosGeier> ah
<GyrosGeier> so revert before pull should work?
<fullermd> Or commit the merge (pull --overwrite will remove the files, as they're no longer versioned in the new target), but that's probably just an extra dance for no reason.
<fullermd> Yeah.  pull --overwrite _does_ discard WT changes, but it isn't going to delete a file the pre-pull HEAD didn't know anything about.
<fullermd> But revert knows the file was created by the merge, so it'll remove it.
<GyrosGeier> ah
<GyrosGeier> right now I do pull, then revert
 * GyrosGeier checks if Jenkins can be taught to revert first
<fullermd> There's also a clean-tree command that deletes unknown files; that might be something to look at too.
<GyrosGeier> ah
<GyrosGeier> before the merge
<GyrosGeier> that is a good idea in any case, because I copy in lots of stuff from other builds
<fullermd> A hardcore option would be something like "bzr remove-tree ; rm -rf * (and maybe .something depending on your tree) ; bzr co ." to completely wipe the slate, but that's pretty drastic and dangerous; one little slip, and...
<GyrosGeier> well, the box is a VM with no persistent state
<GyrosGeier> interesting
<fullermd> Well, you could blow things completely away and do a fresh 'branch' on each run.  That would be the cleanest.
<GyrosGeier> now the extra files are listed with "-D" instead of "- " in the pull output
<fullermd> Depending on where the source branches are network-wise, that may be Obviously Right, or expensive enough to be questionable.
<GyrosGeier> the source is on lp, and takes a few minutes to copy
<GyrosGeier> I'd rather avoid that
<fullermd> But you could 2-step it with a local cache that you just use as a branch 'pull' source, and then branch from that to a temp loc to do your tests.
<GyrosGeier> http://ci.kicad-pcb.org/job/kicad-windows-msvc/cpu=x86,label=windows/55/console
<GyrosGeier> does that look good?
<GyrosGeier> well, that would require Jenkins to maintain a local cache
<GyrosGeier> it starts every job on the first free machine it finds
<GyrosGeier> and might run two jobs in parallel on the same machine
<GyrosGeier> that is a synchronisation nightmare
<GyrosGeier> btw
<GyrosGeier> since I'm here anyway
<GyrosGeier> is there a good way to maintain a stack of patches on top of another branch?
<GyrosGeier> and forcibly push the new branch state to LP
<GyrosGeier> use case is that I maintain a branch containing the necessary patches to make the program build under Windows, and quite often parts of my patches are accepted and sometimes reformatted
<fullermd> Mmm.  You probably do want to try and push the revert to before the pull.  In that case it seems to work right since the pull found nothing to do, but if it did, it woulda thrown away the WT state, so wouldn't know to delete files from a previously pending merge.
<GyrosGeier> hmm
<fullermd> Or do the clean-tree afterward.
<GyrosGeier> that's the Jenkins bzr plugin doing that
<GyrosGeier> the only thing I do manually is the merge
<GyrosGeier> so I can place the clean-tree right before that
<fullermd> There was once a 'pipeline' (I think that's what it was called) extension, that did sorta a stack of branches on top of an existing one.
<fullermd> Sorta a branch-queue instead of a patch-queue.
<fullermd> But I suspect it'd old enough to not work with current bzr.
<GyrosGeier> hm
<GyrosGeier> is there a better workflow for what I need?
<GyrosGeier> (provide something that is mergeable to the autobuilder, and change that regularly when the base tree changes)
<GyrosGeier> in a git workflow I'd rebase my branch, and force-push it
<fullermd> "loom" was another one, that implemented a patch queue.
<fullermd> There is a 'rebase' plugin.  I understand it's not _quite_ the same as git's rebase, but it may be close enough.
<GyrosGeier> so far, I've been going to the LP website, deleted the branch, then recreated it using bzr, pulled that into git, rebased my changes on top, and pushed the changes from git via the bzr plugin
<GyrosGeier> but that is really cumbersome
<GyrosGeier> LP uses something internal to determine whether two commits are the same
<fullermd> Oh, it'll use the commit-id.
<fullermd> But you can push --overwrite if necessary.
<GyrosGeier> ah okay
<GyrosGeier> I got an exception once when I tried that
<fullermd> There's a branch config option that can rejected it.  I don't think it should be set unless you set it, but if you can write the branch, you can unset it.
<fullermd> "can rejected it"?  What the heck?  I haven't had THAT much fun today...
 * GyrosGeier is already on his second beer
<fullermd> I've still got another hour or two of putzing with systems planned before getting there.
<GyrosGeier> you should get a continuous integration system
<GyrosGeier> when I want to stop working I start a matrix build of all configurations on all platforms
<GyrosGeier> and wait for it to finish
<fullermd> The pump broke.  Made a huge mess.
<GyrosGeier> ah
<GyrosGeier> so actual good reason
<fullermd> No, I meant the "continuous integration" system for the beer  ;>
<GyrosGeier> ah
<GyrosGeier> the party at the upstairs neighbours' is getting out of hand
<GyrosGeier> I should get a beer and go there
<fullermd> That sounds like it would increase the outofhandedness.
<GyrosGeier> yes
#bzr 2016-05-13
<psusi> I did a bzr branch lp:~ubuntu-core-dev/installation-guide/ubuntu, made a tiny modification, and am pushing to lp:~psusi/ubuntu/yakkety/installation-guide/partition-limits, and it refuses to perform a stacked push, instead trying to upload the whole ( large and time consuming ) repo... what is wrong?
<psusi> ok, I had to delete the repo, then start fresh with --stacked... but now there is no link to propose merging: https://code.launchpad.net/~psusi/ubuntu/yakkety/installation-guide/partition-limits
#bzr 2016-05-14
<psusi> does anyone know why my modified branch here does not give an option to propose merging back upstream? https://code.launchpad.net/~psusi/ubuntu/yakkety/installation-guide/partition-limits
