#bzr 2008-03-24
<dhon_> hi all, I've got files in d:\project\subdir under version control and I'd like to add files in d:\project. I'd say I need to change the root bzr directory to d:\project - how do I do that & preserve the history in subdir?
<dhon_> I guess I could just move the .bzr directory and then "bzr move --after" all the original files into subdir?
<dhon_> thoughts?
<Peng> You could probably do this with rich roots.
<dhon_> what are rich roots?
<Peng> The / directory entry of the branch is versioned. I'm pretty sure it's possible to move it.
<dhon_> Peng: so I could convert the repo to rich roots format and then move the root somehow?
<Peng> dhon_: Maybe.
<Peng> I dunno.
<Peng> I just tried it and it tracebacked.
<dhon_> Peng: what commands did you use?
<Peng> dhon_: "bzr mv . foo". Traceback. :)
<Peng> I'm pretty sure rich root formats should be able to support that; perhaps bzr doesn't yet though.
<jelmer> Peng: I doubt that will ever work - it doesn't even work for a regular mv
<Peng> Ok.
<Peng> Shucks.
<jelmer> Peng: Although the error message should obviously be more sensible
<jelmer> Peng: what exactly are you trying to do?
<Peng> I was seeing if it was possible to move the root.
<jelmer> Peng: it is certainly possible to change the root - see the split command
<dhon_> jelmer: I was trying to move the root from d:\project\subdir to d:\project
<dhon_> so I could add files at that level
<dhon_> I want the files in subdir to stay there (and to keep their history)
<dhon_> on another note: is it possible to "branch" or "copy" a single file in a repo into two separate files?
<dhon_> eg 1.txt to 1a.txt & 1b.txt?
<jelmer> dhon_: "bzr join" should be able to do that
<jelmer> dhon_: (moving the root from d:\project\subdir to d:\project)
<jelmer> dhon_: There's no way to split a file at the moment
<dhon_> jelmer: thanks - help shows join as still experimental as of 1.2 so I think I'll stay clear for the moment
<Peng> jelmer: Is it just me, or did you define CachingParentsProvider twice?
<Odd_Bloke> jelmer: Congrats on the release!
<aantn> hello
<aantn> does bzr uncommit actually revert your files
<bob2> no
<aantn> I'm trying to change the revision log and bzr uncommit seems to be the only way to do so
<bob2> (the point of uncommit is to not revert the files)
<aantn> bob2: what does the --dry-run flag do?
<bob2> just show you what it would do (which is not all that useful for 'uncommit')
<fbond> Hi, I'm seeing "authorization failed" trying to push to an svn repository.  svn has already cached my credentials.  What am I missing?
<jelmer> fbond: have you prefixed the URL with svn+ ?
<fbond> Oh, hmm...
<fbond> Yes.
<fbond> Pushing to svn+http://...
<jelmer> what os are you on? The caching trick doesn't work on Windows or Mac OS X
<fbond> Oh, maybe...
<fbond> I'm on LInux
<fbond> But I'm pushing to the trunk URL, should I instead be pushing to the repository root?
<jelmer> no, you should indeed be pushing to the trunk URL
<fbond> Oh, okay.
<jelmer> committing to this repository using SVN works ok, without any passwords being prompted?
<fbond> Yep, that's right.
<fbond> bzr: ERROR: Permission denied: ".": CHECKOUT of '/logistix/!svn/ver/183/trunk/pkg-src': authorization failed (http://svn.local.network)
<fbond> The error is on CHECKOUT, which is interesting...
<fbond> I'm using bzr-svn 0.4.8, bzr 1.2
<fbond> jelmer: I'm using a bzr branch, not an svn wc.  That's normal, right?
<fbond> jelmer: i.e. I made the branch with `bzr branch ...'; is this even relevant?
<jelmer> fbond: yeah, that all sounds fine
<jelmer> fbond: what version of svn are you using?
<fbond> On my workstation: version 1.4.4 (r25188)
<fbond> On the server: version 1.3.2 (r19776)
<fbond> jelmer: Do you need mod_svn version info?
<jelmer> Odd_Bloke: thanks :-)
<jelmer> Peng: Whoops, fixing..
<jelmer> fbond: Sorry, no idea
<jelmer> fbond: and you were able to create a bzr branch of the svn branch earlier without problems, or does that not require authorization?
<fbond> jelmer: only write access requires auth.
<fbond> jelmer: I'll try making the branch again, I think I made it with an earlier version of bzr/bzr-svn...
<jelmer> fbond: that shouldn't be relevant
<fbond> jelmer: Hmm.  Is there any way to turn on debug logging so I can see what's going on?
<jelmer> fbond: running bzr with -Dtransport will print to ~/.bzr.log what it is trying to do
<fbond> jelmer: thanks!
<jelmer> fbond: there is no way to debug the authentication step though - that all happens deep down inside the subversion libraries
<rexbron> andrea-bs: bzr builddeb does not use LP as it's bugtracker, do you have a link to the upstream one?
<andrea-bs> rexbron: the exception was raised by bzr itself, so you should file a bug against bzr
<rexbron> andrea-bs: kk
<jelmer> andrea-bs: afiak it just uses the debian bugtracker
<andrea-bs> jelmer: thanks
<rexbron> andrea-bs: https://bugs.edge.launchpad.net/bzr/+bug/206013
<ubotu> Launchpad bug 206013 in bzr "bzrlib.errors.ObjectNotLocked: KnitPackRepository('...') is not locked error when using --merge mode" [Undecided,New]
<andrea-bs> thanks rexbron
<rexbron> I would still like to file a bug against bzr-builddeb for the uncommited changes problem
<rexbron> does anyone have a link to their tracker?
<james_w> rexbron: bugs.launchpad.net/bzr-builddeb
<rexbron> james_w: I was intending to file it against the upstream code base
<james_w> rexbron: I'll move the existing bug over, thanks.
<rexbron> ok will post a link soon
<james_w> rexbron: ah, I never enabled launchpad bugs for it, I'll move it to the Ubuntu package for now.
<james_w> rexbron: please don't use pastebin for tracebacks on bug reports, as they expire.
<rexbron> I will not in future, I just looked at the scroll back from an earlier conversation
<andrea-bs> rexbron: mh... strange... I'm not able to reproduce the situation
<rexbron> andrea-bs: Could be a pecurilarity of the branch
<andrea-bs> rexbron: could you give me the exact command you used, please?
<rexbron> andrea-bs: just to remind you, this is from a script not from the commandline
<andrea-bs> rexbron: oh, right
<rexbron> I am making this call:
<rexbron> builddeb.run(branch=self.debianLocalLocation, result='./build-area', orig_dir='./', builder='dpkg-buildpackage ' + self.debuildOptions, merge = True)
<fbond> jelmer: got my issue resolved; svn was acting *very* oddly...
<fbond> jelmer: it seems that it cached auth info that worked for me, but wasn't my user, or something similar.
<fbond> I minimized the server-side config to allow just me, and it asked for a new password.
<fbond> Dunno
<fbond> Fixed now, anyway.
<rexbron> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/206021
<ubotu> Launchpad bug 206021 in bzr-builddeb "builddeb should raise a python exception when the .run() method is called and there are uncommited changes to the working tree" [Undecided,New]
<rexbron> andrea-bs: as for the first bug I reported, it could have something to do with the watch file not existing
<andrea-bs> rexbron: does "debian.bleedingedge/.bzr" exist?
<ubotu> New bug: #206013 in bzr-builddeb "bzrlib.errors.ObjectNotLocked: KnitPackRepository('...') is not locked error when using --merge mode" [Undecided,New] https://launchpad.net/bugs/206013
<rexbron> andrea-bs: yes, otherwise bd would not work if the orig-dir is set correctly
<fbond> jelmer: I probably would have seen the issue right away in ~/.subversion/auth/svn.simple; everything is in plain text in a file whose name looks like a hash.
<fbond> jelmer: may want to suggest that if anyone else asks.
<fbond> jelmer: also, this is an interesting passage from the svn book:
<fbond> http://svnbook.red-bean.com/en/1.4/svn.serverconfig.pathbasedauthz.html; Partial Readability and Checkouts
<fbond> jelmer: thanks again
<andrea-bs> rexbron: sorry, I can't reproduce it: I get every time a IOError (No such file or directory)  :(
<rexbron> andrea-bs: try and pull this branch https://code.edge.launchpad.net/~ubuntu-bleedingedge/blender/debian.bleedingedge
<andrea-bs> rexbron: done
<rexbron> still the same error?
<andrea-bs> rexbron: there's no "blender-svn.py" file
<rexbron> andrea-bs: copy the bzr-bd.run() method I posted (replacing the varriable where nessicary) and try it out
<andrea-bs> rexbron: Could not find the upstream tarball after uscan
<rexbron> it won't as I am creating it at run time
<andrea-bs> rexbron: I've tried with all possible orig-dirs, they all raise a good exception to me
<rexbron> andrea-bs: Could it be version specific?
<andrea-bs> rexbron: probably, which version of bzr and builddeb are you using?
<rexbron> I am running bzr 1.0 and bd 0.90
<rexbron> Ubuntu Gutsy with backports
<andrea-bs> oh, now I understand
<rexbron> :)
<andrea-bs> I'm using bzr 1.2.0.candidate.1 and builddeb 0.92.0dev0
 * rexbron appolgises not not mentioning this sooner
<andrea-bs> you told me you were using the 1.0 so I was thinking you were on hardy
<andrea-bs> I mark the bug as "Fix released" so
<rexbron> andrea-bs: wait
<rexbron> I will try to reproduce it on hardy and if not, we can mark it as released
<andrea-bs> rexbron: sure
<andrea-bs> rexbron: ok, great idea
<andrea-bs> rexbron: generally I prefer to close bugs and reopen them because sometimes the reporters forget to tell if the bug still occur, so I'm going to mark it "Incomplete": it will expire after 60 days
<rexbron> ok
<james_w> rexbron: the raising an exception thing is completely different in newer releases.
<james_w> rexbron: it doesn't complain at all and just builds the working tree.
<rexbron> james_w: ok
<c0le> hello people..
<c0le> I have a doubt with bzr-svn ..
<james_w> hi c0le
<c0le> james_w: I noticed that bzr-svn is adding an entry to the bzr:revision-id:v3-trunk property of svn every time I do a commit..
<c0le> Does this list of entries in the property keep increasing ?
<c0le> or does it get recycled after reaching a max number of entrieS?
<james_w> I don't know, I think it keeps increasing.
<c0le> james_w: Ouch :-S that would look bad after a 1000 such commits..
<dato> I think that entry contains the full revision history
<dato> so yes, it'll increase afaik
<james_w> c0le: are you using trac?
<c0le> james_w: Yes, and I can see the list increasing over each commit..
<c0le> james_w: i.e., trac shows it in the changeset..
<james_w> c0le: I think there's a way to turn of the display of them.
<c0le> james_w: Aw.. something like 'ignore property'?
<james_w> c0le: I've no idea what the option is, I just think I remember someone mentioning such a thing before.
<c0le> Hmm.. I wonder how git-svn does this tracking..
<c0le> james_w: ok.. i'll google on that..
<james_w> it doesn't
<c0le> james_w: ah, ok..
 * lamont tries again to understand how to break from bzr's belief that he wants a directory-per-branch and create a single working tree with multiple branches in it that he can switch between
<luks> lamont: bzr init-repo --no-trees foo; bzr init foo/branchA; bzr co --lighweight foo/branchA workingtree
<luks> then you can have as many treeless branches under foo as you want
<luks> and switch the working tree with bzr switch
<jelmer> c0le: git-svn doesn't do tracking as far as I know
<jelmer> c0le: bzr-svn 0.5 will hopefully support storing that sort of metadata in revision properties rather than file properties
 * lamont wonders "what sort of tracking"?
<jelmer> lamont: All bzr-specific metadata
<lamont> ah, ok
<jelmer> lamont: so it is possible to push a bzr branch into svn and then create that exact same branch again from the data pushed into svn
<james_w> jelmer: isn't it that git doesn't need to, as its model doesn't create a parallel imports problem?
<james_w> lamont: cbranch from bzrtools may also help with that workflow.
<luks> james_w: it still stores more metadata than svn can
<dato> like full author name
<luks> author name, author date, etc.
<dato> or timezone
<jelmer> james_w: it reduces the need for full round-tripping support
<james_w> ah, ok.
<MikeJJ> hi, i'm trying to install Bazaar on windows following the quick install guide (the python one), but i get stumped here . . .
<MikeJJ> "Bzr Tools and Bazaar GUI needs to be compiled. Use same procedure as for compiling Paramiko."  i fail at finding how to compile Paramiko :P
<MikeJJ> any advice ? :)
<luks> python setup.py install?
<MikeJJ> lol, that simple ?  thanks :D
<luks> I don't really know, just guessing
<MikeJJ> well, looks like that did it.  thanks again :)
<thekorn> hi, I've got another bzrlib question: what is the easiest way of getting the 'kind' of an unknown file in a workingtree?
<james_w> thekorn: osutils.file_kind is what you want I think
<arnetheduck> jelmer, another question for you - should this be reported as a bug?: "Using saved location: https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk
<arnetheduck> bzr-svn is not up to date with installed bzr version 1.3.
<arnetheduck> There should be a newer version of bzr-svn available.
<arnetheduck> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<arnetheduck> "
<james_w> arnetheduck: are you doing push?
<arnetheduck> jelmer, when pushing a new directory to svn...
<arnetheduck> james_w, yes
<james_w> can you try "bzr push svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk"
<arnetheduck> james_w, I think it may be working since the command is taking a lot longer now =)
<arnetheduck> (it's a big commit and sf isn't the fastest site on the net
<james_w> arnetheduck: if it works do "bzr push --remember svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk"
<thekorn> james_w, oh, i'm too much focused on bzrlib that I don't see the obvious
<james_w> thekorn: no problem
<arnetheduck> james_w, that's what I did actually =)
<james_w> arnetheduck: great, your faster than me :-)
<abentley> james_w: I would use Tree.kind, unless trying to get the kind of unversioned files.
<jelmer> arnetheduck: to push new branches, use "bzr svn-push"
<arnetheduck> jelmer, it wasn't a new branch, just a new dir in an existing branch...
<james_w> thekorn: you said "unknown" you meant "unversioned" rather than "arbitrary" didn't you?
<arnetheduck> jelmer, btw, should I worry about the 1.3 warning?
<jelmer> arnetheduck: how do you mean?
<arnetheduck> "bzr-svn is not up to date with installed bzr version 1.3"
<jelmer> arnetheduck: 0.4.9 is out and supports bzr 1.3
<thekorn> thekorn, well, I think i'm a bit confused: I would like to get all files which are in the 'unknown' section when I run 'bzr status'
<thekorn> james_w, i meant
<arnetheduck> jelmer, bugger, I checked yesterday I think and it wasn't =)
<jelmer> arnetheduck: the warning itself isn't really worrysome but you'll find that one or two things give tracebacks
<thekorn> james_w, and I thought I could get these files with tree.unknowns()
<thekorn> but this does not work as expected
<james_w> thekorn: yes, I think that's right, and in that case osutils.file_kind is the correct function to use to get the kind.
<james_w> what do you get that you don't expect?
<thekorn> james_w, damn I'm always mixing workingtree and revisiontree, sorry, my problem is that list(revtree.unknowns()) always returns an empty list
<thekorn> when revtree is an revisiontree object
<arnetheduck> jelmer, the one I reported the other day? something about some revision number being wrong?
<james_w> thekorn: I think that's right isn't it?
<thekorn> james_w, I don't know, have not read any documentations on this, can't revision trees have unknown files?
<thekorn> and if so, why is there a unknowns()-method for RevisionTree-objects?
<Peng> Hmm, one project moved its svn repo to Google Code. Does svn consider the repos different and does bzr-svn?
<Peng> Hmmm, I think it might have changed significantly.
<Peng> There are fewer revisions in G Code.
<james_w> thekorn: a revisiontree is a committed state, so I think it makes sense for it to have 0 unknowns
<james_w> as to whether the method should be implemented on it I am not too sure.
<thekorn> james_w, yes this makes sense, thank you
<arnetheduck> james_w, here's what I got now: bzr: ERROR: libsvn._core.SubversionException: ("MKCOL of '/svnroot/dcplusplus/!svn/wrk/0dd13b40-b1d2-4fab-9b0e-5fb8b3a13bb3/dcplusplus/trunk': 405 Method Not Allowed (https://dcplusplus.svn.sourceforge.net)", 175002)
<james_w> arnetheduck: I have no idea about that I'm afraid.
<abentley> It's implemented on Tree so that we don't have to special-case other functions depending on their Tree type.
<arnetheduck> jelmer, how about http://www.pastebin.ca/955617?
<jelmer> arnetheduck: one sec
<jelmer> arnetheduck: doesn't make much sense to me. I don't understand why bzr would be trying to create a directory there
<arnetheduck> jelmer, it does make sense - svn by default first creates a working folder for the transaction, commits everything there and then moves the transaction to a new revision file...
<arnetheduck> jelmer, could it be that the digest auth is not being sent (when using pure svn, my credentials are fetched automagically)?
<jelmer> arnetheduck: that all happens under the hood though - the protocol doesn't include commands like that
<jelmer> arnetheduck: does "bzr branch <repos-url>" list the branch you're trying to push to?
<ubotu> New bug: #127734 in bzr-gtk "Progress bars as widgets" [Medium,Triaged] https://launchpad.net/bugs/127734
<lifeless> moin
<abentley> lifeless: moin
<jelmer> hey lifeless, abentley
<arnetheduck> jelmer, I've successfully committed to the svn branch before, but never with a new directory
<jelmer> arnetheduck: you added a new directory in your bzr branch and you're now trying to push the revision that added that directory?
<arnetheduck> jelmer, correct
<arnetheduck> jelmer, now that I think about it, I first removed a directory and then added one with the same name
<arnetheduck> jelmer, hm, that makes it two revisions to commit - one that removes a directory (and contents), then another that adds a directory (and contents) with the same name as the one removed
<jelmer> arnetheduck: that shouldn't be relevant here though
<jelmer> the mkdir call you're seeing is about creating a new branch, not about a directory in a branch
<arnetheduck> jelmer, I'll try again, maybe it was some temporary error
<jelmer> arnetheduck: I doubt that
<jelmer> arnetheduck: does "bzr branch <repos-url>" list the branch you're trying to push to?
<jelmer> arnetheduck: sorry, I mean "bzr branches <repos-url>"
<arnetheduck> jelmer, running...
 * Peng wonders what bzr-svn is doing.
<Peng> Augh!
<Peng> It took like 2 minutes to pull 1 revision!
<jelmer> Peng: are you using 0.4.9 ?
<Peng> jelmer: I'm using yesterday's 0.4 branch.
<jelmer> Peng: the development branch can have major performance regressions while in flux
<Peng> Apparently so.
<mathrick> hiya
<Peng> Hello.
<mathrick> what would be the easiest / best way of serving a writeable public repo with authentication?
<Peng> mathrick: bzr+ssh?
<mathrick> Peng: and without ssh?
<james_w> webdav?
<mathrick> okay, I guess ssh is the easier way then
<Peng> Yeah.
<Peng> If it's a FOSS project, you could use Launchpad.
<mathrick> it's not, not yet anyway
<arnetheduck> jelmer, it's still stuck...
<jelmer> arnetheduck: in the "bzr branches.." run?
<jelmer> it took only a minute or so here..
<arnetheduck> jelmer, here's what I tried: "bzr branches svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk"
<jelmer> arnetheduck: please try the repository url
<jelmer> bzr branches
<jelmer> svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/
<spiv> Good morning.
<lifeless> hi
<mathrick> bzrserve@sei.meidokon.net's password:
<mathrick> Server is too old for fast get_parent_map, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
<mathrick> bzrserve@sei.meidokon.net's password:
<mathrick> why does it have to reconnect?
<mathrick> it makes me input the password twice
<james_w> mathrick: because the server is too old.
<mathrick> yeah, but why does it have to reconnect to use the older protocol?
<spiv> mathrick: because the older protocol wasn't designed to allow graceful degradation in the case where a client sends a request with a body but the server doesn't recognise the request
<lifeless> mathrick: because the old protocol let the server get confused about edge of messages
<mathrick> aha, not nice of it
<lifeless> mathrick: so there was no way to be sure when it was actually ready for new input
<arnetheduck> jelmer,  bzr branches svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/ returned nothing
<jelmer> arnetheduck: what do you have the branching scheme set to?
<arnetheduck> auto I think, didn't specify anything, and when importing it got my branches right so...
<arnetheduck> jelmer, sorry, gotta go, I'll check back tomorrow...
<jelmer> the fact "bzr branches" returns nothing suggests something may be wrong there
<jelmer> arnetheduck: what does "bzr svn-branching-scheme <repos-url>" print?
<ubotu> New bug: #206242 in bzr-svn "Add append-revisions-only setting for Subversion repositories" [Wishlist,Triaged] https://launchpad.net/bugs/206242
<lifeless> spiv: looks like only us around; point 2 point call ?
<spiv> lifeless: sure.
<igc> morning
<evarlast> is it possible to branch or export a subdirectory of a repository? maybe this is called NestedTreeSupport ?
<Peng> evarlast: To turn a subdirectory of a branch into its own branch, see bzr split.
<lifeless> evarlast: we discussed this in london
<lifeless> you can also split as Peng says
<lifeless> igc: hi, spiv and I just did a p2p call as we couldn't see any others :>
<igc> hi lifeless
<spiv> igc: FWIW, my plan for the day is email + smart impl of set_last_revision_info
<igc> spiv: thanks
<evarlast> thank you so much. I searched as searched and could not find split.
<igc> spiv,lifeless: my plan for the day is ... email + reviews + package the new hook we worked on at PyCon
<lifeless> igc: I'm working on versionedfiles
<ubotu> New bug: #206258 in bzr "incompatible repository error messages are unhelpful" [Undecided,New] https://launchpad.net/bugs/206258
<sabdfl> hi folks
<sabdfl> are 1.3 packages available in the usual ppa? i haven't seen them for hardy yet
<sabdfl> and is there an agreement with the distro team to put 1.3 into hardy itself (not the ppa)?
<Peng> sabdfl: The PPA takes a few days to update.
<Peng> Hey, hg 1.0 is out. :)
<sabdfl> thanks peng, and congrats on the 1.0
<Peng> Not congrats to me.
<Peng> I mean, I'm not one of their developers.
<sabdfl> ah, thought you were
<Peng> I'd *like* to be, if I was smart enough. :P
<Peng> (I'd like to do more than typo fixes on bzr too. I'm not a traitor!)
#bzr 2008-03-25
 * Peng wanders off.
<igc> bbl - got some errands to run
<jml> lifeless: remind me
<jml> lifeless: which formats are "stackable"?
<lifeless> jml: the new ones in my loom
<jml> oh right, 'development' and friends
<lifeless> in theory, I have now removed users of VersionedFile.get_graph
<lifeless> some of the replacements are so obviously wrong I want to cry.
<jml> lifeless: shallow branches are confusing me.
<jml> lifeless: http://rafb.net/p/zleZ3572.html
<jml> lifeless: in that example, I make a branch, push it, do a shallow branch from *that*, make some changes, then try to push it and get a fairly low level error.
<lifeless> lets see
<jml> lifeless: am I doing something wrong?
<lifeless> jml: its a little hard to read; please consider passkeys
<lifeless> but that aside
<lifeless> look in sftp://localhost/tmp/server/testdoc.shallow
<lifeless> in .bzr/branch/
<lifeless> there should be a stacking pointer
<jml> there is no branch/ dir
<jml> branch-format  branch-lock  README  repository
<lifeless> what is there
<jml> that's it
<lifeless> ok
<lifeless> so, you are making a full branch from a shallow branch
<lifeless> this is interesting
<lifeless> could you try push --reference
<jml> am I?
<lifeless> erm, push --shallow
<lifeless> yes, bzr push will make a full branch
<jml> even if you are pushing from a shallow branch?
<jml> that's interesting.
<lifeless> this is open for tuning
<lifeless> for now, --shallow is needed everywhere you want to make shallow branches
<lifeless> as for why it is blowing up
<lifeless> I don't know, I would appreciate a bzr blackbox test for this in the push.reference thread
<jml> lifeless: "jml@rhino:/tmp/client/testdoc.shallow$ bzr push --shallow sftp://localhost/tmp/server/testdoc.shallow.shallow" works.
<jml> lifeless: I can do that.
<lifeless> local file paths should be enough
<lifeless> jml: does 'bzr log sftp://localhost/tmp/server/testdoc.shallow.shallow' work ?
<lifeless> hmm 12:30, lunchtime. bbiah
<jml> lifeless: yep
<jamesh> lifeless: I've uploaded the bzr-dbus changes I discussed with you a while back.  There are three branches if you want to see the incremental changes.
<lifeless> jamesh: thanks
<lifeless> jamesh: I need to look at that soon; hopefully tomorrow I'll have enough of versionedfiles behind me to do a loom 1.3 release and bzr-dbus foo doo too
<lifeless> spiv: around?
<jamesh> lifeless: the lan-gateway protocol is unchanged, but the dbus interfaces change a bit
<jamesh> (mainly that the Revision signal can come from any source
<jamesh> lifeless: also, https://bugs.edge.launchpad.net/bzr-dbus/+bug/198645 makes the plugin less than useful with current branch formats
<jamesh> since the set_rh hook isn't called for many of the interesting operations
<abentley> jamesh: Branch formats since dirstate-tag have not stored the revision-history on disk; they store only the revision_id and revno of the last_revision.
<jamesh> abentley: I know.  The bzr-dbus plugin hooks "set_rh" to detect branch changes, which is what that bug is about
<jamesh> it should be hooking post-commit, post-pull, etc
<abentley> We could also have a hook on set_revision_info
<jamesh> that sounds useful
<jamesh> saves having to update the plugin every time a new way of modifying a branch is added
<abentley> The bug suggests that bzr never invokes the set_rh hook, but it will on old-format branches.
<jamesh> yeah.  I should update the description
<lifeless> jamesh: yeah, igc & spiv are working on that
<spiv> lifeless: I'm around now
<lifeless> spiv:  how do you want hpss method deprecations done?
<spiv> lifeless: hmm
<lifeless> indeed
<lifeless> did you include Warning: in your new protocol ;)
<spiv> lifeless: I did include headers, so I suppose so ;)
<dstanek> why is it recommended to init-repo a branch and then inside of it create other branches?
<spiv> lifeless: that's a good idea
<lifeless> dstanek: init-repo creates a shared repository, not a branch
<lifeless> dstanek: specifically it creates a database that many branches can use to share their disk storage
<lifeless> dstanek: this saves disk space and increases performance when making a new branch in a sibling diectory
<lifeless> spiv: so thats the future. for now I have smart server methods I want to nuke
<dstanek> lifeless: so its really all about disk space?
<lifeless> dstanek: yup
<lifeless> dstanek: we consider repositories to be 'storage optimisation'. there  should be no features or behaviours that require a shared repository
<lifeless> dstanek:  if you just do 'bzr init' without having done 'bzr init-repo' you get a repository - the database - in .bzr/repository, a private one just for that branch.
<bob2> currently also handy for checking out instead of branching rich root branches
<spiv> lifeless: at the moment, a comment in the implementation is the best we have
<lifeless> spiv: uhm test failures
<lifeless> spiv: no deprecation warnings are permitted by the test suite on pqm.
<lifeless> spiv: smart server verbs call repository.get_revision_graph
<lifeless> spiv: applyDeprecated doesn't really work here :/
<spiv> lifeless: ah, I see.
<lifeless> so far I have thought of:
<spiv> lifeless: we perhaps need a decorated SmartServer_for_Testing?
<dstanek> lifeless: in order to use the shared repository you create a branch in a subdirectory of the repository right?
<lifeless> dstanek: yes
<spiv> lifeless: or more evilly, something that temporarily overrides a specific request handler to suppress warnings...
<spiv> lifeless: other ideas are welcome
<spiv> lifeless: I assume this is a method that connect be sensibly re-implemented to avoid the deprecated API?
<lifeless> no
<lifeless> the method is one that is being deprecated
<lifeless> so I have thought of:
<lifeless>  - private reimplementation
<lifeless>  - _method version which isn't deprecated
<lifeless>  - global flag which causes Request.do to catch deprecations
<lifeless> so specificially
<lifeless> Repository.get_revision_graph
<lifeless> is
<lifeless> VersionedFile.get_graph
<lifeless> with fillips
<lifeless> so is beind deprecated
<lifeless> forcing all Repositories to implement Repository._get_revision_graph is an api break
<lifeless> deprecations are about not breaking apis
<lifeless> so I think I have to have an implementation on the smart server request
<lifeless> which doesn't call the old one
<lifeless> but this still leaves open the question of how to tell clients they should upgrade
<lifeless> brain diarreha completed
<lifeless> spiv: ^ any comments
<lifeless> abentley: still up ?
<abentley> yep
<lifeless> there are two uses of get_revision_graph in log.p
<spiv> lifeless: I think telling clients to upgrade is probably something for a header in protocol v3
<ubotu> New bug: #206330 in bzr "bzr diff --using <whatever> crashes if no commit has been made" [Undecided,New] https://launchpad.net/bugs/206330
<lifeless> I am deprecating this function; does your patch remove either/both - should I merge it to my branch
<spiv> lifeless: otherwise if you can teach RemoteRepo to avoid the problematic smart method I guess that's enough for now.
<lifeless> spiv: I have to fix the method for old clients
<lifeless> spiv: I didn't consider, for a fraction of a second, using self._real
<spiv> I didn't think you did :)
<abentley> lifeless: It's in mainline now.
<abentley> It doesn't remove either one, but it moves them around.
<lifeless> ok
<lifeless> well I'll remove them
<lifeless> really need a bread first search that returns the parents data
<lifeless> not just the keys
<spiv> Mmm, bread.
<lifeless> grah
<abentley> lifeless: I can imagine that'd be useful.
<spiv> (not meaning to pick on a typo, just musing on the tastiness of bread!)
<lifeless> abentley: it would for some of these things 1/2 the index query count
<abentley> lifeless: Don't let me stop you making the API more useful.
<lifeless> abentley: oh, I won't :].
<lifeless> abentley: cycles and roi
<sabdfl> poolie: ping
<lifeless> sabdfl: poolie is on leave today
<sabdfl> lifeless: do you know why bzr 1.3 isn't yet in hardy or the ppa?
<lifeless> ppa: can't say absoltelu, but I think the reason is simply that Martin (who is doing the deb maintenance now) has not had any work hours since the release: friday and monday were public holidays, and he took today as leave
<sabdfl> ok
<lifeless> hardy, I don't know anything any which way, but I can look into it
<sabdfl> thanks
<sabdfl> pretty clear we should get 1.3 in hardy
<lifeless> for sure
<lifeless> I will check into it before I finish today
<sabdfl> not sure what our policy has been w.r.t. stable release updates into gutsy, feisty, dapper
<lifeless> we've done backports
<lifeless> but not made a push for stable releases; we got some [reasonable] push back in casual converstations with distro about it
<lifeless> (because its not broken ..)
<jdong> sabdfl / lifeless : I offered on Friday to look into getting bzr 1.3 into Hardy, but I've been running behind schedule. It's just a matter of syncing from Debian and making sure all the plugins also get updated at the same time
<jamesh> lifeless: it is broken in the sense that the old versions can't access current branches ...
<lifeless> jdong: awesome; do you need any help with that
<jdong> as far as pushing bzr 1.3 into previous releases, so far we've been using Backports, as bzr's not 100% backwards-compatible plugin-wise which makes it a harder case for stable release updates
<jdong> lifeless: I saw today that bzr-svn 0.4.9 is out which is 1.3 compatible
<lifeless> yup
<jdong> lifeless: I'll try to invest some time tomorrow to fill out all the paperwork :D
<jdong> just did my taxes today, so enough paperwork for one night :D
<jamesh> I doubt anyone wants to backport packs to bzr-0.8.2 in dapper
<lifeless> jamesh: yeah not going to happen ;>
<abentley> I'm upgrading Bundle Buggy.  It will be down for a few.
<lifeless> k
<abentley> Back up.
<abentley> Now with super-awesome new versions of SQLAlchemy and Elixir
<lifeless> yay
<Pengwn> Hi
<Pengwn> If i don't want to log my undo to bzr should  i do "bzr revert" or "bzr uncommit"
<jamesh> abentley: you should try Storm :)
<jamesh> Pengwn: "bzr revert" reverts changes in your working tree that you haven't committed yet.
<jamesh> "bzr uncommit" is used to undo commits
<abentley> jamesh: Yeah, like the Python world really needs three ORMs ;-)
<jamesh> so it depends on what you want to do
<jamesh> abentley: true.  It doesn't need those other two.
<Pengwn> jamesh: I accidently commited and it's at revision 10. I want my bzr in the state it was at revision 9.
<Peng> What about ORMs?
<Pengwn> jamesh: will uncommit do it or there's some other method ?
<lifeless> abentley: at least three
<lifeless> abentley: ran into a new one today, 'Mother'
<Peng> Pengwn: bzr uncommit erases the commit. Then you can use bzr revert to erase the changes in the working tree.
<Peng> lifeless: That makes it four.
<jamesh> Pengwn: okay.  Running "bzr uncommit" will take you back to r9 with the changes from r10 sitting in your local tree.
<Pengwn> oh thanks Peng.
<jamesh> Pengwn: if you'd previously pushed r10, you will probably need to use "push --overwrite" to push the altered branch.
<Pengwn> no push done yet.
<Pengwn> so I can safely uncommit then revert ?
<jamesh> Pengwn: yep.  If there is no other record of the commit, then there is no problem uncommitting it
<jamesh> Pengwn: what "uncommit" can't do is stop people from using a revision you've previously published
<Peng> SQLAlchemy, SQLObject, Elixir, Geniusql, that Canonical one.
<Pengwn> cool. it's screams.
<Peng> Storm!
<Pengwn> Jamesh: thanks, if I am the publisher admin, I guess the uncommit and revert trick will do there as well ;-)
<jamesh> Pengwn: what I mean about published revisions is this kind of situation: (1) you upload your branch to a public location, (2) someone else downloads the branch, hacks on it making a few commits and uploads those changes, (3) you uncommit some revisions and publish new versions, (4) you want to merge from the second person
<jamesh> 's branch
<jamesh> Pengwn: while you can remove the revision from branches you control, you can't do so from other people's
<jamesh> and if you are planning to collaborate with them, you'll probably run into the uncommitted revisions again in a merge.
<lifeless> Peng: sqlalchemy, sqlobject, elixir, genuisql, storm, mother
<lifeless> Peng: this is at least 3 :)
<Peng> lifeless: Haha. True.
<bob2> and django's (maybe for small values of 'orm')
<Pengwn> jamesh: oh ok got it. yeah that would be too late a scenario for reverting/uncommiting.
<Pengwn> Jamesh: I meant maybe like within a minute i published maybe it's doable.
<jamesh> Pengwn: yep.  In those sort of situations, you're better off leaving history as it was and making a new commit to fix the problem.
<jamesh> Pengwn: just making sure you know the limitations on what uncommit can do :)
<abentley> lifeless: My mistake, my patch hasn't been merged yet.
<lifeless> abentley: ok
<lifeless> abentley: well I've gone ahead and done the changes anyhow; I'll wear conflicts I guess
<abentley> Sorry.
<Pengwn> yep. got that. have some cvs/clearcase admin experience :-)
 * nDuff wonders aloud (and off-topic'ly) why anyone would use an ORM other than SQLAlchemy for a new project.
<lifeless> abentley: no proba
<lifeless> nDuff: well, storm was built after looking at sqlalchemy seriously
 * nDuff might have to look at that one, then.
<abentley> lifeless: It was not well-advertised then.  When it was released, it looked like it didn't have enough functionality to be useful.
<lifeless> abentley: it may be true anyhow :>
<jamesh> lifeless: to be fair, SQLAlchemy has improved since niemeyer was using it.
<hazmat> the nutshell is sa is complex and does alot, and storm is simple and does just enough..
<jamesh> hazmat: that said, it does quite a lot within the problem space it covers.
<hazmat> right.. but that definition is subjective ;-)
<hazmat> i like sa's flexibility to work with db schema constructs, a problem space storm punts on
<jamesh> yep.  Storm doesn't have anything to help you manage your SQL schema.
<jamesh> but then the type of schema-generation-from-python-classes I've seen in things like SQLObject was useless for a long running project.
<tuxcantfly> Do the newer versions of bzr svn-push from the bzr-svn package support Sourceforge's Subversion services? I'm using 4.7-1~gutsy1 from the gutsy-backports, with bzr 1.0-1~gutsy1 (also from gutsy-backports), and I'm getting 'bzr: ERROR: Not a branch:  "https://unetbootin.svn.sourceforge.net/svnroot/unetbootin/trunk/".' whenever I do 'bzr svn-push "https://unetbootin.svn.sourceforge.net/svnroot/unetbootin/trunk"' from my local bz
<lifeless> jamesh: I thought sa was not capable of the multiple backend stuff storm is; which was the key thing
<lifeless> tuxcantfly: I would have thought it would; I suggest you file a question on bzr-svn's launchpad answer tracker
<lifeless> tuxcantfly: as jelmer, the primary author is likely asleep.
<jamesh> lifeless: to be honest, I haven't investigated the guts of SQLAlchemy particularly deeply.
<tuxcantfly> oh sorry, I'll do that
<lifeless> tuxcantfly: nothing to be sorry about
<jamesh> lifeless: I know that the cache integrity problems were one of the major reasons why niemeyer started working on Storm though
<jamesh> (I believe those have been fixed in subsequent versions though)
<lifeless> jamesh: all i'm trying to say is that it wasn't 'sa is too complex/buggy', but rather 'sa is by design not able to do the long term stuff we need'
<hazmat> lifeless, sa can definitely handle the multiple backend stuff
<hazmat> lifeless, i think that comment might originally been in reference to sqlobject..
<lifeless> could be
<lifeless> I don't really collect ORM details :>
<Peng> Dejavu too.
<lifeless> yay, in theory, add deprecations, and done
<lifeless> see you all tomorrow
 * igc dinner
<ubotu> New bug: #206406 in bzr "[win32] local push finished with error message: Could not acquire lock" [Critical,Confirmed] https://launchpad.net/bugs/206406
<uniscript> this is probably a daily faq but any news on bzr-svn for bzr 1.2 or later?
<fullermd> It's out for 1.3....
<uniscript> any .debs for gutsy around?
<dato> james_w, jdong: bzr-svn 0.4.9 is in unstable, so bzr 1.3 could go into hardy if you wish
<james_w> dato: thanks for the heads up.
<james_w> uniscript: not yet, sorry.
<uniscript> looks like it's only in hardy then
<dato> but those debs, eg. from debian sid, will install fine on gutsy for all I know
<uniscript> that was naughty pushing 1.2 to us and then breaking bzr-svn
<james_w> not yet either.
<dato> ("those" = bzr-svn)
<james_w> ah, there's one compatible with 1.2, yes.
<awilkins> jelmer: I'm having a go with bzr 1.3. / bzr-svn 0.4.9 on my "big repo" and initial impression is very favourable. It's no longer CPU-bound, for starters, so I would guess that it could be going as fast as the constraints of disk I/O will allow.
<ubotu> New bug: #206443 in bzr-gtk ""bzr commit-notify" should listen for Revision signals from any source" [Undecided,New] https://launchpad.net/bugs/206443
<ubotu> New bug: #206480 in bzr-gtk "Should monitor changes in visualized branch" [Undecided,New] https://launchpad.net/bugs/206480
<beuno> james_w, howdy. Have you made any progress on the bazaar transition?
<james_w> hi beuno, I haven't I'm afraid.
<james_w> are you back in Argentina now?
<beuno> james_w, yes  :) :) :)   back at the office
<james_w> did you enjoy your holiday?
<beuno> james_w, holiday?  I was on holiday?  I didn't know  :p
<beuno> I did enjoy the trip very much
<james_w> :-)
<james_w> I thought it was a holiday
<beuno> not as much as I would of liked
<thekorn> hi, can any moderator of the bazaar@lists.canonical.com mailinglist please moderate my mail, I sent it before subscribing
<james_w> thekorn: is it something we can help with over IRC?
<thekorn> james_w, no not really, i just started to think about a FUSE filesystem for bzr
<igc> night all
<james_w> thekorn: ah, ok.
<james_w> night igc
<james_w> thekorn: I think there was a quick hack of one around somewhere
<james_w> heh, I was just about to point you to your own
<thekorn> james_w, hehe
<dato> thekorn: maybe it'd be faster just to resend it
<thekorn> dato, ok, will do
<ubotu> New bug: #206574 in bzr "bzr send should reject creating empty submissions" [Undecided,New] https://launchpad.net/bugs/206574
<ubotu> New bug: #206577 in bzr "bzr send should warn on uncommitted local changes" [Undecided,New] https://launchpad.net/bugs/206577
<jelmer> jdong: are you still working on getting bzr 1.3 in hardy?
<jelmer> jdong: bzr-svn 0.4.9 is now out and should be compatible
<jdong> jelmer: yes, I plan on doing that a bit later today :)
<gioele> hi
<gioele> how come bzr 1.3 is not available via PPA?
<abentley> gioele: Best to ask poolie.  He should be awake in ~5 hours.
<Lo-lan-do> Hi all.  Stupid question about bound branches...
<Lo-lan-do> Let's assume I checkout a branch onto my laptop, then go work in a train/plane/whatever.
<Lo-lan-do> I do a few commits, then when I come back home I want to re-bind.
<Lo-lan-do> Is there a way not to see my commits as merges?
<fullermd> Pull or push them in.
<Lo-lan-do> (Assuming, of course, that the upstream branch hasn't been touched in the meantime)
<Lo-lan-do> I see.  push before update, I guess?
<gioele> http://bazaar-vcs.org/Branch says Â«[bzr puts] the repository, branch, and working tree all in the same place. If there is no tree, it is called a "standalone branch".Â» But http://bazaar-vcs.org/StandaloneBranch says Â«Standalone branches contain two components: The RCS data and a working tree.Â»
<gioele> "if there is no tree" vs "RCS and working tree"
<gioele> who is right: the Branch page or the StandaloneBranch page?
<Lo-lan-do> gioele: I believe the latter, but I could be wrong.
<Lo-lan-do> I'm still confused about the fact that there are 4 options in bzr reconfigure (I was only expecting 3, and I don't know which one I wasn't expecting)
<gioele> Lo-lan-do: I aggree, I'd call a branch without working tree a repository branch
<dato> gioele: no, because it may not be in a repository
 * fullermd actually expects several more options   :p
<dato> a standalone branch is one that *contains* a repository
<dato> if it contains a repository, it is a standalone branch, independently of whether it has a working tree or not
<gioele> contains a repo == .bzr/repository esists
<dato> yes
<Lo-lan-do> fullermd: So what's the difference between --branch and --tree there?
<dato> gioele: as opposed to "is contained in a repo"
<dato> but if it has a tree, maybe the correct term would be "standalone tree", dunno
<fullermd> I presume --branch turns something that isn't an isolated branch (like a checkout) into one; --tree involves the working tree.
<gioele> branches contained in a repo have .bzr/branch but not  .bzr/repository
<gioele> isn't it?
<Lo-lan-do> gioele: Right
<gioele> let's write this down in my notebook :)
<Lo-lan-do> fullermd: OK, I got it.  --branch is for a tree-less branch, --tree is standalone branch+ working tree
<Lo-lan-do> That could be made more explicit.
<gioele> Lo-lan-do: patch to add this to "help reconfigure" output?
<gioele> http://bazaar-vcs.org/RepositoryBranch says Â«This type of branch is not hackable on by users as it does not have a working tree.Â». This is not always true, is it?
<dato> no, it is not
<Lo-lan-do> Close enough: the working tree is not kept up-to-date, so it'll frequently be wrong and best ignored.
<fullermd> I don't know if --branch is for an explicitly treeless branch, or simply leaves the WT alone in whatever state it's already in.
<dato> Lo-lan-do: well, you can have your *work* branches in a repository; are they not RepositoryBranches?
<gioele> what about "A branch that lives in a repository that has been created with --no-trees, will not be hackable by users as it will not have a working tree"
<Lo-lan-do> dato: You *can*, but I wouldn't recommend that :-)
<fullermd> "RepositoryBranch" only refers to the repo and branch; it doesn't say anything one way or another about the WT.
<dato> Lo-lan-do: uh?, why not. I do it all the time
<dato> in a --trees repository
<Lo-lan-do> fullermd: reconfigure --branch removes my working tree here
<fullermd> Well, I guess that demonstrates the point about detail of documentation   :)
<Lo-lan-do> dato: Hm.  I have a non-flat structure for my branches, so I'd rather know that a directory under the repo == a branch
<dato> hm. maybe I misinterpreted something
<Lo-lan-do> Anyway.  Back to my original question: can I programmatically extract the bind-to branch location?
<dato> Lo-lan-do: Branch.get_bound_location afaik
<Lo-lan-do> Aehm, I was expecting a "bzr bound-location" command or so, which I could call from shell :-)
<dato> ah, that programatically
<dato> info -v | grep ? :)
<fullermd> Suck it out of info
<Lo-lan-do> I guess I can awk bzr info
<fullermd> Don't need -v
<dato> ok
<Lo-lan-do> Hm.  But if I'm unbound, then I don't get that in bzr info.
<fullermd> Mmm.  I doubt it's UI exposed anywhere in that case.
<Lo-lan-do> bzr info | awk -F: '/checkout of branch:/ {print $2}'
<Lo-lan-do> Actually, awk -F= '/bound_location/ {print $2}' .bzr/branch/branch.conf would be faster.
<Lo-lan-do> About a hundred times faster :-)
<Lo-lan-do> (0.004s vs. 0.5s)
<fullermd> Well, as long as we're working on performance anyway, and you've just taken the first step toward reimplmenting bzr in awk...
<dato> fullermd: needs a test
<dato> so half-step
<Lo-lan-do> But I'm glad to hear performance is being worked on.  Does that include startup time?
<Lo-lan-do> I can live with complex rebases or merges taking some time, but half a second for a simple bzr info is a bit boring.
<fullermd> Heck, that's nothing.  See what any command does with a cold cache and my somewhat aged disks...
<Lo-lan-do> I know, I was just dodging the "cold cache" counter-argument :-)
<fullermd> bzr stat (wait, wait, listen to disk heads for a while, wait, trim toenails, wait, order pizza...)
<Lo-lan-do> As long as you don't have time to eat the pizza :-)
<fullermd> Oh, no.  I haven't had time for the pizza since 0.13 or so.
<jelmer> hi Lo-lan-do
<Lo-lan-do> Hi jelmer :-)
<jelmer> Lo-lan-do: Do you know what the chances are of f-spot not depending on beagle in the near future?
<gioele> is there a standard testsuite to run in order to test performance and spot regressions?
<Lo-lan-do> jelmer: No idea.  You should ask diocles.
<abentley> Lo-lan-do: --tree implies only "branch", not "standalone branch".  It's perfectly possible to have a repository tree.
<Lo-lan-do> abentley: I'm aware of that, I was just wondering about the difference between --branch and --tree in reconfigure.
<Lo-lan-do> It seems --branch removes the tree, whereas --tree ensures it's there.
<abentley> Yes.  In your earlier comment you said --tree meant standalone branch + tree, so I thought you misunderstood.
<Lo-lan-do> gioele: bzr selftest maybe
<gioele> what is the name of a working tree that lives outside a branch? Checkout? And what is the name for a working tree that lives in a branch?
<Lo-lan-do> Lightweight checkout for the first.
<jelmer> Lo-lan-do: thanks
<Lo-lan-do> Hm, bzr selftest fails some tests here.
<gioele> unbinded heavyweight checkout for the latter?
<abentley> Lo-lan-do: Try running with --no-plugins.
<Lo-lan-do> Not a checkout, since as far as I know a checkout is synonymous with a bound branch.
<Lo-lan-do> abentley: Nah, LANG=C "fixes" it.
<abentley> Lo-lan-do: I can have a look.
<Lo-lan-do> http://paste.debian.net/51815 for instance
 * Lo-lan-do goes away to buy food before the shops close
<abentley> What's your locale?
<gioele> s/unbinded/unbound/
<Lo-lan-do> fr_FR.UTF-8
<abentley> We don't really have a name for the working tree inside a branch.  We just call it a working tree (but checkouts and lightweight checkouts both have working trees too).
<gioele> abentley: ok
<gioele> now http://bazaar-vcs.org/Revision: Â«Bazaar uses something called weaves to store revisions.Â» is that still true? Wasn't weaves the name of an old format?
<abentley> That is very out of date.
<tca> http://bazaar-vcs.org/BzrDevelopment links to http://bazaar-vcs.org/ReleaseRoadmap and say the latter is to be updated. Should I update the table listing releases? Or are there other plans for the page?
<gioele> another question about revisions: Â«Revisions are stored in one of two places: either branches or repositories.Â» I read branches as .bzr/branch and repositories as .bzr/repository, am I right?
<fullermd> I think a lot of that glossary is wildly out of date...
<fullermd> I don't think it's been comprehensively examined since jblack put it together way back when.
<gioele> fullermd: good, I spent last day going through it and trying to make sense of it :)
<rodge> hi, is there any way to push code to a branch you checked out from, and have the working tree updated without having to log into that machine and doing an update?
<dato> rodge: if bzr is installed on the remote end, the push-and-update plugin
<rodge> and that's the only way?
<rodge> i'll take that as a yes since i have to go now :) thanks, i'll try that
<beuno> rodge, yeap, or mount the remote location locally
<rodge> mmk
<rodge> thanks
<beuno> with samba/nfs/etc
<beuno> np
<ubotu> New bug: #206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,New] https://launchpad.net/bugs/206728
<gioele> if the location a branch is pushed to is local (file://) it will rebuild the working tree, won't it?
<dato> gioele: yes
<gioele> ok
<oskude> hi, im going through this http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html (under ubuntu) but after "bzr push sftp://and.so.on" it only uploads the .bzr dir, not the files im writing... what could i check ?
<oskude> (and .bzr dirs content)
<dato> oskude: that's expected
<oskude> huh? what did i miss ?
<bob2> oskude: push only updates the working copy if it's a file:/// url (ie a local directory)
<oskude> oh...
<bob2> oskude: if you want to update remote working copies, https://launchpad.net/bzr-push-and-update or 'ssh remotehost bzr update /path'
<oskude> hmm, so if my server only has ftp for upload, i cant upload my code to it with bzr ? (sorry, i just started with version control:)
<bob2> not with bzr
<oskude> :(
<dato> nor with any other vcs afaik
<oskude> dato, thanks, was just gonna ask that :)
<dato> basically creating a remote tree requires you to have the $vcs binary on the server
<bob2> maybe using a local branch + 'mirrordir' would work for you
<oskude> dato, youre good!, that was going to be my second question :))
<oskude> bob2, hmm, would that have the possibility to just to upload the "last changes" ? (or is that exactly what the $VCS on the server would do?)
<bob2> afaict it would only upload changed files (but the whole content of them)
<bob2> and that is what a vcs would do, yes
<oskude> bob2, i assume with "mirrordir" you mean a tool outside bzr ?
<dato> oskude: you said you pushed with sftp. when you have sftp, you normally have shell access, though.
<oskude> dato, thought so too, but logging with ssh gives "Allowed commands: sftp Connection to osku.de closed." (my server is the cheapes i could find ;)
<dato> ok
<dato> cheap always comes at a price :)
<oskude> definetly! its like 0.25 cent per month :)
<oskude> is ftp capable to only upload changed files ? (if it even can recursive)
<dato> I don't know mirror tool, but I guess it'll recurse the tree, asking the server for the mtime, and uploading that stuff whose mtime is newer in your machine
<oskude> roger, thanks. ill check to that. back to explore bzr :)
<bob2> oskude: 'mirrordir' is a specific tool (that I found with apt-cache search) that seems to do precisely that
<oskude> bob2, ah, thanks!
<bob2> (I think:)
<oskude> bob2, description sounds good, ill test later
<oskude> do you also need bzr on the server to get a "real working" branch ?
<oskude> i mean would my "mirrordir"ed branch dir work when i "bzr branch" it from other machine ?
<bob2> how do you mean?  people can bzr branch from the one you're pushing, yes.
<oskude> would this work ? : i start my code at home, "bzr it", and upload the branch dir with mirrordir to my ftp server. then at work i get that branch with "bzr branch http:/myserver/branch, "code some more", and then upload again the branch dir with mirrordir ?
<dato> oskude: I recomend that you use mirrordir for the working dir only (ie., *not* .bzr), and bzr push to push .bzr
<dato> I'm sure mirrordir has some --exclude option
<dato> or so
<oskude> dato, ok, thanks. has someone done this or do all use bzr with real bzr server ?
<dato> I'd say most people just push .bzr
<dato> and those that need a working tree, have ssh access to the machine
<dato> though I'm also sure there's more people in your situation I never heard about :)
<oskude> ok, now i get it
<oskude> so the "real coders" are allowed to upload code and the "others" can only upload changes to existing code ?
<bob2> I don't think many people care about having working trees with their remote branches
<dato> oskude: uh, no, not sure where you got that idea from or what you mean by it
<dato> oskude: people push to share; pushing .bzr is enough to bzr get it, so enough to share.
<bob2> oskude: you don't need working copies to use bzr branches - people can checkout, branch, merge, etc, without it
<oskude> i mean in this examle "real coders" would be "ssh+bzr server" and "others" would be "ftp server"
<bob2> oskude: anyone with write access via ftp could commit code to that branch
<oskude> bob2, ok, then i was lost. sorry.
<bob2> oskude: nothing to be sorry for, it is all a bit confusing
<oskude> so why didnt this upload my code ? bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject
<oskude> (of course with my servers attributes)
<bob2> oskude: unless you really need to have the files checked out (e.g. people need to be able to browse the files using a web browser), you can skip all this and just use bzr
<bob2> oskude: that should work fine, maybe sftp's weird quoting rules broke it - try sftp://blah@blah/home/blah/myproject, maybe
<oskude> bob2, the branch dir and .bzr dir are boh created ok, and the .bzr dir content too. but the files i wrote are not uploaded, so the URI should be ok, no ?
<dato> oskude: if you bzr get http://example.com/~your.name/myproject, people will get the files
<dato> oskude: I thought bob2 and me had tried to make that clear
<oskude> dato, didnt test that yet as i dont see the files on my server... you say they are in the .bzr dir on server ?
<dato> yes
<oskude> argh...
<dato> try wget http://example.com/~your.name/myproject/.bzr/branch-format
<oskude> well, i had the "crazy idea" to use bzr also to control the html files...
<dato> then use mirrordir, as we already explained
<dato> dinner time, bbl
<oskude> dato, yup, thanks for the help! and good infos!
<oskude> ok, do i get this right: all my code is in the .bzr dir ? on the server (after push) and on my machine ?
<igc> morning
<james_w> hi igc
<oskude> ARGH! now i got it, theres no reason to have the "actual" code file if you have all changes in VCS... how stupid from me...
<igc> hi james_w
<james_w> igc: I've got a plan to fix the file-ids problem with the bzr.dev round trip.
<igc> james_w: great to hear
<igc> is it a good one?
<igc> :-) :-)
<james_w> mmm, I don't know yet.
<james_w> We keep a file_id cache for each root node in the import, and then when we ask for a file-id from the cache we pass a list of roots that we are descendants of, and we get given the first cache hit for that list.
<james_w> that means that you don't get the file id of a file in another branch
<james_w> and that we favour the left hand ancestory, which I think is right.
<LaserJock> is there anything faster for getting a branch than a bzr checkout --lightweight ?
<james_w> LaserJock: probably not, as that will only get the working tree.
<james_w> what are you pulling?
<LaserJock> ubuntu-docs
<LaserJock> it's always a beast but I was hoping things had improved since last time I tried
<LaserJock> I just wanted a tmp branch
<bob2> what is it that makes ubuntu-docs so big?  lots of images?
<LaserJock> not too many images I don't think
<LaserJock> long history, lots of files
<warren> What are the benefits of rich-root?
<warren> pack-0.92 seems to be the default, so wondering if I should use rich-root
<bob2> atm, mostly "lets you use bzr-svn"
<warren> what are tree-roots?
<LaserJock> bob2: my edubuntu-docs branch is 217MB with 211MB being .bzr/
<bob2> tree-root = the root of the branch
<bob2> LaserJock: wow
<LaserJock> we're thinking of starting our bzr branches over again
<LaserJock> it just takes forever to branch/checkout
<bob2> is it packed?
<LaserJock> but then we loose history
<LaserJock> that I don't know
<LaserJock> it's imported from svn about 6 months ago or so
<james_w> warren: it is anticipated to make a transition to rich-root at some point, so by choosing it now you lessen the impact of that transition.
<LaserJock> bzr info gives: Standalone tree (format: dirstate-with-subtree)
<bob2> can you, e.g., branch bzr.dev into a rich-root repository yet?
<LaserJock> that's not the "latest and greatest" format is it?
<bob2> LaserJock: no
<lifeless> LaserJock: I would suggest not starting over; we'll have shallow branches soon
<LaserJock> how easy is it to upgrade formats, and would that help?
<LaserJock> lifeless: what does "shallow" mean?
<lifeless> LaserJock: checkout --lightweight is probably slower than 'checkout' today; because 'checkout' will stream all the data, but '--lightweight' will do many round trips
<lifeless> LaserJock: deep history will be left on the server
<warren> james_w, bzr-1.0 is good enough for that?
<LaserJock> oh, well that's good to know :/
<lifeless> LaserJock: checkout --lightweight on a lan, or local disk is good
<warren> james_w, any performance/storage benefits of rich-root over pack-0.92?
<LaserJock> lifeless: k
<LaserJock> lifeless: how much slower do you think it'd be going from LP?
<LaserJock> I could restart my checkout but not sure if it'd actually help me out
<LaserJock> yikes, I just killed it and the dir is only 1.2 MB :/
<james_w> warren: 1.0 is sufficient, and I don't think there are any benefits.
<james_w> I think there will be a few more bytes stored, but only a few.
<warren> I'll use pack-0.92 for now since it is the default...
<lifeless> james_w: I wouldn't recommend people use non default unless they have a specific reason
<lifeless> james_w: it won't lessen the transition as rich-roots is not what we will transition too
<lifeless> james_w: we'll transition to a new format that is very similar to rich roots but not the same,.
<james_w> ah, ok, sorry then.
<warren> lifeless, thanks
<lifeless> james_w: so tell me about file ids and fast import
<lifeless> james_w: I'm really concerned, not having read the fast import or export code, that you and Ian are smoking huge piles of toenails
<james_w> :-)
<james_w> it's a little dodgy (well wrong) at the moment, as it uses a global path->file-id cache, which leads to things like the concrete problem I was describing
<james_w> that can be solved by splitting the cache so that there is one per branch.
<lifeless> uhm
<lifeless> we normally call that cache 'the basis tree inventory'
<james_w> yeah, I'm not sure why we don't just use that.
<lifeless> and if you have issues turning up with this; I am amazed you don't have corrupt per file graphs
<abentley> Because the toenails are so flammable?
<james_w> igc: did you decide to implement the cache rather than use the parent inventories?
<james_w> ...for a reason?
<lifeless> back shortly
<james_w> the more general problem I was hinting at is that using file-ids means that we are attempting to track the user's picture of the file identities in the branch, and as the stream format doesn't provide that information we can't do that.
<james_w> Which means that our current code neither allows us to track the user's ideas (due to the limitations of the stream format), or help them after then fact with rename detection and the like.
 * LaserJock wonders what lifeless was smokin' when he told me --lightweight is probably slower ;-)
<LaserJock> at least if these progress bars are anywhere close to comparable
<james_w> LaserJock: do you already have a branch locally?
<abentley> LaserJock: What format is the branch in?
<LaserJock> james_w: no, that's what I'm trying to get
<LaserJock> abentley:  bzr info gives: Standalone tree (format: dirstate-with-subtree)
<james_w> (the less charitable interpretation of the second case would be "by training the users not to think  about file identities")
<abentley> LaserJock: So you're pulling from a format that's inefficient to pull from.
<LaserJock> abentley: lucky  me :-)
<abentley> If you were pulling from a more efficient format, I'd expect what he said to be true.
<LaserJock> so, how hard is it to switch formats?
<abentley> bzr upgrade LOCATION
<igc> james_w: I spoke to abentley in London about removing the need altogether for inventory caching
<james_w> igc: inventory caching, or file-id caching?
<LaserJock> abentley: is that something Launchpad people could do?
<igc> james_w: the file-id caching is there mainly because we don't want to create new file-ids for existing files ...
<igc> it does need to be per branch though ...
<igc> not global as it currently is
<abentley> LaserJock: In theory, maybe.  But we don't want to be hostile to people using old clients, and we don't want to do it piecemeal.  (I am a Launchpad people)
<LaserJock> abentley: I see
<james_w> igc: yes, but couldn't you just take the file id from the parent inventory (cached or not), rather than a separate cache.
<LaserJock> I thought maybe we could just offer like weekly tarballs of the branches
<james_w> You would lose identity between paths in two revisions if the path isn't present in an intermediate revision, but I don't know if that is a desirable property or not.
<abentley> LaserJock: have you tried the packs format yet?
<LaserJock> abentley: no, apparently not
<abentley> It's a lot more like weekly tarballs.
<LaserJock> I'm just trying to do an initial checkout so I can do a trivial diff of a directory
<abentley> i.e. all the changes in a certain number of commits.
<bob2> I think LaserJock just wants branching/checkout from lp to be faster
<abentley> Bunched together.
<igc> james_w: getting the file-id from the parent inventory sounds better to me
<LaserJock> so something that used to take me maybe 5 min is taking me a couple hours
<bob2> the doc team could run a pack-0.92 mirror somewhere and see if that helps
<igc> james_w: there's no reason I know for not oding that
<igc> s/oding/doing/
<james_w> igc: cool, that's a much easier solution as well.
<abentley> LaserJock: Even if you're not using packs, are you using bzr+ssh?
<LaserJock> abentley: I'm doing bzr checkout http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
<LaserJock> I tried --lightweight before but gave up to try a regular checkout
<LaserJock> but well, that doesn't seem faster so I guess I'll just stick with it
<abentley> LaserJock: Try bzr checkout bzr+ssh://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
<LaserJock> ok, so after 21 min. it had 39M done on the checkout
<LaserJock> starting over with bzr+ssh
<abentley> also, what version of Bazaar do you have?
<LaserJock> whatever's on Hardy
<LaserJock> 1.2-1~bazaar1~hardy4
<LaserJock> I guess I'm using the PPA
<abentley> That should be good, then.
<LaserJock> I get an error
<LaserJock> bzr: ERROR: Repository KnitPackRepository('<local dir>') is not compatible with repository  is not compatible with repository RemoteRepository (<remote URL>)
<LaserJock> sorry, that wasn't pasted all that well
<LaserJock> abentley: did I do something wrong?
<abentley> Just trying it here.
<LaserJock> k
<abentley> Did the progress bar show at all for you?
<LaserJock> no
<LaserJock> it didn't do anything, just immediately errored out
<abentley> It's going for me.
<LaserJock> weird
<abentley> So you're checking out into a shared repo?
<LaserJock> what do you mean by that?
<LaserJock> not sure exactly what that is
<abentley> A shared repository is a storage location for all your revisions.
<LaserJock> I just want to get a little directory of the branch actually so I can diff it against a branch I have
<LaserJock> but that seems to be a big task today :-)
<abentley> The problem is that you've got two incompatible formats.
<LaserJock> but how is that if I don't have *any* branch of it yet?
<abentley> I would assume it's because you have a shared repository.
<LaserJock> I don't think I do
<abentley> Did the directory exist when you started checking it out?
<LaserJock> no
<LaserJock> I rm -rf it every time I try
<spiv> "bzr info" should be able to tell you if there's a shared repo for the directory you're in.
<LaserJock> bzr: ERROR: Not a branch
<spiv> I guess that's a "no", then :)
<LaserJock> that was my guess ;-)
<LaserJock> hmm, so anything else I could have screwed up?
<abentley> Well, the problem is that this branch you're trying to check out is in the experimental 'dirstate-with-subtree' format.
<LaserJock> experimental?
<LaserJock> interesting
<abentley> Yes.
<abentley> But your local bazaar is using the default version.
<LaserJock> it was made like 6 months ago
<LaserJock> I wouldn't have thought it would have been experimental still :-)
<abentley> It's not supposed to do that; it's supposed to imitate the remote branch's format.
<abentley> LaserJock: It's been experimental for about a year now.
<LaserJock> ah
<abentley> And using it is strongly discouraged.
<LaserJock> well, it wasn't us
<spiv> It was a bzr-svn import, I think?  Probably it can be converted to just rich-root.
<LaserJock> LP guys set it up
<LaserJock> yeah, it was an svn import
<LaserJock> I can't remember if mdke actually did the import or not
<LaserJock> but I remember it took around 5 days to push it
<spiv> Packs make that much better :)
#bzr 2008-03-26
<LaserJock> so i think somebody in LP made the other branches
<LaserJock> because as bad as 1 branch is, i really want 4 of them
<abentley> spiv: Were there any bugs in the format detection in 1.2?
<spiv> abentley: I'm not sure.  I don't see anything in NEWS about it.
<LaserJock> abentley: can I force it?
<bob2> co uses the bzr default branch format, instead of the remote format
<spiv> abentley: I do vaguely recall something got fixed in that area, but I think before 1.2?
<abentley> Oh, doh.  I forgot I defaulted checkout to --lightweight.
<LaserJock> ohh
<abentley> Yeah, I get that failure too.
<LaserJock> k, so I'm not nuts
<LaserJock> doing the checkout now
<abentley> The way to force it is: bzr init --dirstate-with-subtrees $DIR; cd $DIR; bzr pull bzr+ssh://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy;
<schierbeck> hey guys
<jml> something weird just happened to me
<ubotu> New bug: #206886 in bzr "bazaar send should support inlined content" [Undecided,New] https://launchpad.net/bugs/206886
<jml> I tried branching using 'bzr+ssh' from a server -- worked fine. Then I did branch using 'sftp' from the same server and got an authentication error.
<warren> Can a bzr smart server prevent clients from deleting tags?
<jml> the same machine appears under a different hostname & using a different port in my .ssh/config
<LaserJock> abentley: but will that be fast? doing a bzr pull?
<jml> and when I use sftp://hostname:22/, branch works.
<warren> BTW, does pack-92 automatically mean you also have dirstate-tags?  (or the ability to do bzr tagging)
<jml> is Bazaar using one mechanism for bzr+ssh and another for sftp?
<bob2> warren: yes, pack-0.92 includes tag support
<abentley> LaserJock: It certainly ought to be.
<spiv> jml: it shouldn't, IIRC
<LaserJock> abentley: and it won't let me do --dirstate-with-subtrees
<abentley> my bad, no 's' on the end.
<lifeless> LaserJock: the training trees were meant to be getting upgraded by tetet
<lifeless> LaserJock: setup a local repository for them, then the cost of all 4 is minimally more than the cost of 1
<jml> maybe it's a bug in openssh
<warren> bob2, thanks for the clarification.
<LaserJock> lifeless: can I do that with an existing branch?
<spiv> ValueError: invalid literal for int() with base 10: '# Loom'
<spiv> http://rafb.net/p/PiTZ3863.html  has the full error.
<lifeless> LaserJock: yes; make the repo locally, then bzr branch your existing branch into it
<LaserJock> lifeless: oh!
<LaserJock> I have an edubuntu-docs branch right here
<spiv> lifeless: I just got an error pulling the loom trunk into my local copy, but it was resolved when I upgraded my local branch from dirstate to pack-0.92.
<lifeless> spiv: bizarre
<spiv> lifeless: full traceback in the pastebin above
<lifeless> just looks like a corrupt file
<spiv> lifeless: want a copy of the troublesome branch?  Or a bug report?
<lifeless> spiv: it looks like the knit code being handed a loom current file
<lifeless> spiv: which is really bizaare
<lifeless> spiv: uhm, if you can make it reproducable sure
<spiv> lifeless: yep, I can reproduce.
<lifeless> cool <damn>
<spiv> :)
<lifeless> then I'd like enough stuff to reproduce it please :)
<abentley> I can't reproduce spiv's error, though I think I've seen it before.
<spiv> lifeless: http://people.ubuntu.com/~andrew/loom-pull-case.tar.gz has the branch
<LaserJock> hmm, so how do I make a share repository?
<spiv> lifeless: I simply did "bzr pull", which pulled from bzr+ssh://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/
<warren> lifeless, btw, if I'm converting a huge repository from dirstate to pack-92, should I use bzr-1.3 or is 1.1 fine?
<lifeless> LaserJock: for a svn converted project, bzr init-repo --rich-root-pack path
<lifeless> warren: 1.1 is fine
<ubotu> New bug: #206890 in bzr "Help pages for merge and pull should tell users about bundles" [Undecided,New] https://launchpad.net/bugs/206890
<lifeless> warren: after the conversion, just run bzr reconcile
<warren> Do tags come across in merges?
<warren> foo-trunk> pull ../foo-bar (which has its own tags); bzr merge; bzr ci, are tags from foo-bar visible in foo-trunk now?
<LaserJock> lifeless: so does a shared repo mean that a new branch will take common revisions from the local repo?
<abentley> lifeless: PQM has committed my last merge request, but not published it.
<abentley> Could you give it a whack please?
<lifeless> abentley: 'log' ?
<lifeless> abentley: was the merge request for yoru log changes ?
<abentley> No, it was for pulling lp: locations
<lifeless> so if pqm didn't publish, it will have rolled back
<lifeless> let me look for an error
<abentley> Last time I tried, it told me "nothing to merge".
<lifeless> ok; weird then
<LaserJock> dang, even a local branch takes quite some time
<LaserJock> I seriously wonder if we shouldn't just start over
<abentley> LaserJock: You're branching from a location in your shared repo into another location in your shared repo?
<LaserJock> no
<LaserJock> from a branch I already had outside my shared repo into the shared repo
<LaserJock> but it's still local
<abentley> A branch in a different format?
<LaserJock> no
<LaserJock> I don't think so
<abentley> lifeless told you to use rich-root-pack.  You didn't?
<LaserJock> yep, same formate
<LaserJock> oh, you're right
<LaserJock> ok, that makes sense then
<abentley> So what you are hitting is an unoptimized conversion path.
<LaserJock> can two bzr instances run at the same time?
<abentley> Sure.
<abentley> They can't both write to the same thing at the same time, of course.
<LaserJock> I started doing the local branch at the same time I'm doing a bzr pull
<LaserJock> and the bzr pull doesn't seem to be doing anything
<abentley> You should probably wait until the local branch is done anyhow.
<abentley> But bzr+ssh doesn't give great progress indicators.
 * LaserJock notes that after 26 min :-)
<LaserJock> so it looks like it's gonna be about 40 min to do the local branch
<abentley> How big is this data?
<LaserJock> well, the branch is 217MB
<LaserJock> .bzr is 211MB
<LaserJock> that's why I'm wondering about starting over
<LaserJock> we're carrying so much history around for like 6MB
<abentley> That seems extremely disproportionate.
<LaserJock> well, the size of the "working tree" has grown and shrunk quite a bit with time
<LaserJock> the size of the files in my branch probably won't ever get over ~20MB
<LaserJock> but the ubuntu-docs branch is probably more like 100-150MB
<LaserJock> it's just a frustration because it used to take < 5min or so to do a SVN checkout and that worked well for us
<LaserJock> we're trying to get to the same level with bzr
<LaserJock> but I think our project is not a great example :/
<lifeless> LaserJock: once you have your repo seeded, upgrade it to rich-root-pack, because that is lots faster :>
<LaserJock> you mean push the new branch back up to LP?
<spiv> LaserJock: with a shared repo locally and rich-root-pack as the format, it'll be much snappier.  The coming stacked branches feature will also help.
<LaserJock> spiv: I hope so :-)
<lifeless> LaserJock: no, I don't mean push
<LaserJock> I guess I didn't get it then
<LaserJock> what branch do I want to upgrade?
<LaserJock> the one I'm making should be already rich-root-pack right?
<lifeless> abentley: your patch is published
<abentley> lifeless: tx
<lifeless> LaserJock: what does bzr info on the repository you created say its format is ?
<LaserJock> lifeless: just a sec, it's just finishing branching
<LaserJock> Shared repository with trees (format: rich-root-pack)
<LaserJock> that's the share repo obviously
<LaserJock> and the new branch is:
<LaserJock> Repository tree (format: rich-root-pack)
<LaserJock> so that took about 36min to branch locally, just FYI
<LaserJock> now I'm trying a bzr branch of one of the other branches
<LaserJock> ohh, that's much better
<lifeless> james_w: so, were did we get to
<lifeless> james_w: right, file ids. are they deterministically allocated? do you generate correct merge graphs? (that is, does 'bzr check' give no errors on an imported branch)
 * igc food
<nir> where is bzr 1.3 for ubuntu?
<nir> https://launchpad.net/~bzr/+archive contains only 1.2.1
<kgoetz> aiui, coming
 * mneptok jumps up and down on kgoetz 
 * kgoetz bruises painfully
<mneptok> how's tricks, Kaiserlicious?
<kgoetz> mneptok: pretty good. gobuntu is a bit quiet atm, but other things i;m involved in a fairly lively :)
<kgoetz> how is the support hotseat these days?
<mneptok> kgoetz: getting hotter as more customers don;t like the fact we don't officially support Hardy yet
<jamesh> mneptok: I'd have thought they'd have moved on to Intrepid by now.
<kgoetz> mneptok: hehe. and i assume it'll keep warming up until well after release
<mneptok> kgoetz: you got that right
<mneptok> jamesh: usually that's ~3m after libc drops into the next release ;)
<kgoetz> ;)
<eugeneoden> anyone here familiar with bzr-loom?
<spiv> Several, including me.
<lifeless> yay get_parents hath died
<eugeneoden> spiv: hello.  you helped me with bzr-svn branch problem last monday at the sprint.  on the plane i started working on a deloomify command for bzr-loom and was wondering if anyone else was interested in that functionality.
<jelmer> lifeless: btw, if you think setting the inventory_sha1 to "" in bzr-svn is a bad idea, please speak up :-)
<lifeless> jelmer: its a terrible idea
<spiv> eugeneoden: I think so, jam filed some bugs on bzr-loom including one asking for a command to deloomify.
<lifeless> eugeneoden: I think you'll find that that is in the TODO already :)
<spiv> eugeneoden: https://bugs.edge.launchpad.net/bzr-loom/+bug/203285
<ubotu> Launchpad bug 203285 in bzr-loom "unable to "de-loom" a branch" [Undecided,New]
<eugeneoden> cool.  i might have seen it somewhere - i'm not familiar enough with this stuff to come up with changes on my own.
<jelmer> lifeless: worse than using a sha1 from a semi-random serializer?
<lifeless> jelmer: well, perhaps you might be more clear about what you mean
<lifeless> jelmer: do you mean 'when you call repository.get_revision(X) on a SvnRepository, the inventory_sha1 will be blank'
<lifeless> jelmer: or do you mean 'the revisions in a pack repository pulled from SvnRepository have an inventory_sha1 of ""' ?
<lifeless> jelmer: or perhaps you mean both
<lifeless> jelmer: so for the former, I think None is appropriate if svn has no validator
<lifeless> jelmer: for the latter it must be the validator returned by add_inventory (which will be the case if you use anything other than the lowest level apis for inserting into the pack repository)
<eugeneoden> spiv, lifeless: i took a brute-force approach to start with - deleting last-loom and reverting the branch format.  ran into locking issues - LoomSupport.unlock() attempts to record any changes before calling the superclass unlock() and fails if last-loom has been deleted.
<lifeless> eugeneoden: I suggest: lock(); write new format, unlock(), delete last-loom in that order
<lifeless> it will have to be a valid loom at unlock time
<eugeneoden> makes sense
<eugeneoden> lifeless: would it be better to insist that all threads have been combined except for the last implicit one or should deloomify combine all threads, leaving the contained changes as uncommited modifications?
<jelmer> lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory
<lifeless> jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision...
<lifeless> jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :>
<lifeless> eugeneoden: I would say that you must have one and only one thread or supply a --force.
<lifeless> eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check.
<eugeneoden> ok, sounds good.
<jelmer> lifeless: heh, commit builder is only used for the other way around :-)
<jelmer> lifeless: add_revision doesn't appear to set revision.inventory_sha1
<spiv> jelmer: I'm getting 'bzr: ERROR: Revision {('svn-v3-trunk0:bbbe8e31-12d6-0310-92fd-ac37d47ddeeb:trunk:22922',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c7c74c>".' when I try to update my Twisted import with current bzr-svn stable
<jelmer> spiv: does "bzr selftest svn" pass?
<jelmer> spiv: if not, please file a bug
<jelmer> I'm getting some sleep :-)
<lifeless> bbiab
<spiv> jelmer: ok
<spiv> jelmer: thanks
<lifeless> yay internode suckage
<lifeless> jelmer: if you replied to me, I missed it
<lifeless> 14:30 < jelmer> lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory
<lifeless> 14:31 < lifeless> jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision...
<lifeless> 14:32 < lifeless> jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :>
<lifeless> 14:32 < lifeless> eugeneoden: I would say that you must have one and only one thread or supply a --force.
<lifeless> 14:32 < lifeless> eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check.
<lifeless> 14:33 < lifeless> bbiab
<lifeless> 14:38 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr
<spiv> lifeless: he replied:
<spiv> 14:34 < jelmer> lifeless: heh, commit builder is only used for the other way around :-)
<spiv> 14:35 < jelmer> lifeless: add_revision doesn't appear to set revision.inventory_sha1
<spiv> And he also said < jelmer> I'm getting some sleep :-)
<spiv> lifeless: and with that, I think you're back in sync
<lifeless> yay bugs
<lifeless> jelmer: thats clearly a bug; care to fix ?
<poolie> lifeless: nice response to sjturnbull
 * lifeless bows
<LaserJock> lifeless: so in the end I the branching into the shared repo too 36 min and a subsequent bzr branch of another ubuntu doc branch took 90 min
<LaserJock> if that makes any sense
<lifeless> LaserJock: into the same shared repo ?
<LaserJock> yeah
<lifeless> LaserJock: what does 'bzr info' on the second branch (in the repo) say
<LaserJock> Repository tree (format: rich-root-pack)
<LaserJock> and it said it's part of the shared repo
<lifeless> ok
<lifeless> 90 minutes - I have to guess that the remote format is knits
<LaserJock> it's interesting that there is such a difference in repo sizes
<LaserJock> the edubuntu-docs branch (the one I did the local branch into the shared repo) is 5.5MB
<LaserJock> the ubuntu-docs branch which is the one I did the bzr branch on afterwards is 205MB
<lifeless> LaserJock: did you do that one into the shared repo ?
<LaserJock> yes
<LaserJock> I guess the .bzr is small though
<lifeless> can you ls .bzr/ on that one ?
<LaserJock> the first is 108K and the second is 1.4M
<LaserJock> so it's just a difference in "working tree" size
<LaserJock> and the shared repo .bzr is 198MB
<lifeless> ok
<LaserJock> so it looks like the shared repo is working well
<lifeless> perhaps the svn conversion used silly svn 'branch' layers, and grabbed too much data.
<LaserJock> 90 min isn't great, but at least it's a lot better than doing the whole stinkin' thing
<LaserJock> I believe it only had to get 178 revisions to do the ubuntu-docs branch
<LaserJock> seems like 90 min for 178 revisions is a lot
<LaserJock> we're at revision 3781 so if that scaled that means it would take almost 32 hrs to do the full branch
<LaserJock> so it must take a lot to do the conversion between formats
<lifeless> whats the url of the second branch you made? the launchpad url I mean
 * igc bbl - school pickup today
<LaserJock> http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
<LaserJock> lifeless: btw, I really do appreciate your help and all the effort the bzr team puts into bzr and the LP hosting
<LaserJock> sorry if my frustration and inability to "get" bzr sometimes made me seem cranky
<lifeless> LaserJock: bzr info http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
<lifeless> Standalone branch (format: dirstate-with-subtree)
<lifeless> Location:
<lifeless>   branch root: http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
<lifeless> LaserJock: ^ its in knit format, which means lots of round trips
<lifeless> LaserJock: as I thought :>
<lifeless> chat to tetet about this :)
<LaserJock> so maybe we can get that changed on the LP server?
<LaserJock> this shared repo stuff is fantastic
<lifeless> ;)
<LaserJock> now, is it right that I can remove everything from a branch but the .bzr/ without ill effect?
<lifeless> LaserJock: 'bzr remove-tree'
<LaserJock> hot dog
<abentley> bad lifeless: please promote "reconfigure --branch" instead.
<LaserJock> so now I have  both edubuntu-docs and ubuntu-docs branches and it's 14MB *smaller* than my previous edubuntu-docs branch
<lifeless> abentley: perhaps 'bzr remove-tree' could do that advertising for me :)
<lifeless> jelmer: thanks
<LaserJock> abentley: how would I then get the tree back, reconfigure --tree?
<abentley> LaserJock: Right.
<LaserJock> I'm kinda confused/amazed. How can the ubuntu-hardy .bzr only be 40K?
<LaserJock> there's 178 revisions difference between the edubuntu-hardy and ubuntu-hardy branches
<lifeless> LaserJock: the .bzr in a shared repository only contains the branch pointer
<LaserJock> does it store all revisions in the shared repo and then the individual branches only hold what revisions belong to the branch
<LaserJock> I was thinking it would hold the revisions that were not in common
<lifeless> that would reqire continual shuffling to keep that property
<lifeless> all it does is move the database out of the branch and to a centralised location
<poolie> abentley: i haven't read all of all the threads, but i don't think there is a standard way to launch them
<poolie> it is basically like unix MUAs
<poolie> in that to control them in detail, you need to use which one you're calling
<poolie> i may be out of date though
<abentley> poolie: But at least Gnome and KDE provide a standard way of launching them, to say nothing of Windows and Mac.
<lifeless> gnome and kde focus on usability though
<lifeless> the standard way to configure emacs is to write lisp
<abentley> I just don't want to wind up with an endless proliferation of mail clients.
<lifeless> me neither
<lifeless> We could say 'get your client registered with xdg-mail'
<poolie> well
<lifeless> but that doesn't deliver a fix to the users in the short term
<abentley> That requires a GUI desktop, I think.  I could see backlash.
<lifeless> we could promote a 'sensible-mail' alias for debian* systems :>
<abentley> Does debian not provide a "sensible-editor"?
<bob2> it does
<abentley> I meant "sensible-mail".
<abentley> It's late.
<lifeless> it does, but editor & mail client are different I thought :>
<lifeless> there is no sensible-mail on my system
<jdong> sensible-editor Conflicts: emacs *ducks*
 * TFKyle wonders what it is, nano or something?
<abentley> jdong: Hey, play nice.
<jdong> :)
<abentley> They're Bazaar users now, we should make them feel welcome.
<lifeless> let me register right now
<lifeless> that if php switches to bzr
<lifeless> I will _not_ stop trolling
<LaserJock> :-)
<bob2> check out the flock() page in the user-editable php docs sometime
<TFKyle> think it'd be very hard to convert their cvs repo to bzr anyway (well, need a bit of automagic encoding detection iirc, the commits are in various encodings)
<TFKyle> s/commits/commit messages/
<bob2> how does cvs handle that?
<bob2> just throw raw bytes at the terminal with 'cvs log'?
<lifeless> cvs spits at encodings
<TFKyle> think so
<lifeless> TFKyle: if you detected each one well, you could stuff it into bzr just fine
<lifeless> TFKyle: unless a single commit had multiple encodings :>
<lifeless> k gents, thats all she wrote;
<bob2> that emacs patch unfairly discriminates against gnus users, anyway
<abentley> lifeless: What if MySQL switches?
 * abentley clocks out of the channel just after an Oz resident.
<ufuntu> hello :)
<mdke> hi there. We at the ubuntu-doc project have completed our first release cycle of using bzr, it's gone relatively well! However our branch history is pretty huge so we're just trying to decide whether to start a fresh branch for the next cycle. I'd like feedback on potential advantages and disadvantages
<mdke> as I see it the advantages are that we can move to the new bzr format (we are currently using a bzr-svn format) and that the branch will be (much) quicker to download
<mdke> obviously the disadvantage is that we lose the history but we can probably live with that. Are there any other disadvantages?
<Peng> "new bzr format"?
<Peng> mdke: You can use rich-root-pack, which is (a variation of) the new pack format.
<Peng> mdke: I hate losing history, so I'd say don't do that. If performance is really that bad, grit your teeth until there are further improvements, or switch to git or hg or something. :P
<mdke> Peng: right, I meant the pack format which comes with bzr 1.0
<mdke> Peng: what are the reasons you hate losing history?
<Peng> mdke: OTOH, if svn's history didn't import well, starting with a clean slate might be nice.
<Peng> mdke: "Because.". It's...history. You're not supposed to lose it.
<mdke> Peng: alright...
<Peng> mdke: So, in summary, I'm no help at all. :P
<mdke> we'd have the history in the branches for the previous releases, I guess
<mdke> we wouldn't abandon those
<Peng> mdke: I'd say that you shouldn't throw out the history unless you really, really need to.
<Peng> Would you be maintaining the previous branches in svn or bzr?
<mdke> in bzr, we imported all of them
<mdke> the branch size is currently 200MB on disk
<Peng> Ouch.
 * igc dinner
<Peng> That's about the size of the entire history of Python imported into bzr.
<mdke> there ya go.
<Peng> And that has *really* bad performance.
<Peng> (35 or 38k revisions per branch, some large number of files.)
<Peng> (Oh, 36k.)
<mdke> we're only at 3700 revisions
<TFKyle> mnm, I should try branching that
<mdke> although I suppose it might not be comparable, given that our material is all text
<mdke> and translations of text
<Peng> 4000 files.
<mdke> Peng: do you know whether if members download the branch without revision history, they can still push to our master branch on launchpad?
<Peng> mdke: What do you mean? Bzr needs the history.  Well, you can use lightweight checkouts, but that would be slow.
<mdke> yeah, I meant lightweight checkouts
<Peng> TFKyle: They distribute it as a tarball. :(
<mdke> so that would be corresponding slow to push?
<Peng> mdke: Well, there's zero history stored on the client. Even "bzr status" would have to get some information from the server. And, obviously, that's slower than the local disk..
<TFKyle> Peng: indeed, hadn't completely read the page yet (just read bcannons post mentioning it a little while ago)
<mdke> Peng: yeah, not great. So I think the answer is either to drop the history, or figure out why it's so damn huge
<mdke> and do something about it
<Peng> mdke: Huge number of files? Did anyone accidentally commit an ISO?
<mdke> hah
<mdke> I can't figure out how to exclude history from a "du" command
<lifeless> mdke: I can look at your tree tomorrow sometime
<lifeless> mdke: I strongly urge you to do nothing in terms of discarding history for about 4 months. some good shit in the pipeline
<mdke> lifeless: that would be great :) I just want to check it's not a wild goose chase and the problem isn't just a large working tree
<mdke> maybe it's bigger than I thought
<lifeless> I think someone familiar with bzr scaling needs to look at your tree & history to make an assessment of whats going on
<lifeless> *I* suspect svn conversion breakage
<lifeless> for now, I have to go. tchau.
<mdke> lifeless: ciao
<mdke> ah shit. The working tree is 200MB... I wasn't counting the history before
<mdke> I've got that in a shared repo
<mdke> which is around 1.6GB
<mdke> my .bzr directory is 635MB
<mdke> I'll come back tomorrow and have a chat with lifeless
<mdke> thanks all
<poolie> >  With regard to writing style, I agree with Steven Turnbull - the
<poolie> yeh
<poolie> bad paste
<poolie> mdke: if you branch out of that repository into a new one it will carry only the relevant history
<awilkins> Does the "new" format support rich roots?
<awilkins> I'm in a similar situation, large SVN repo (~1.5GB), large number of medium - large files, about 13000 revisions... I've not finished converting mine over yet though
<awilkins> Just finishing off the trunk, then I shall work on the branches
<awilkins> THen I can see what kind of performance is available
<Peng> awilkins: pack-0.92 has a rich-root variant called rich-root-pack and a subtree variant called pack-0.92-subtree. Even if you're currently using dirstate-with-subtree, you can probably upgrade to only rich-root-pack.
<dato> Peng: to pack-0.92-subtree, you mean. and possibly to rich-root-pack, but it'll be very ver slow afaik.
<Peng> Oops, I should've said "If you're currently using dirstate-with-subtree *with bzr-svn*".
<Peng> dato: What would be slow? Why?
<dato> -subtree -> -rich-root is slow, I think
<Peng> Oh.
<Peng> You may be correct. I'm branching ubuntu-doc's dirstate-with-subtree branch over bzr+ssh into a rich-root-pack right now, and it's going about as fast as a bzr-svn conversion (thankfully without the svn memory leaks though ;) ).
<Peng> into a rich-root-pack repo*
<awilkins> Peng: I meant the "dev" format ; I'm already using rich-root-pack
<Peng> awilkins: Oh. Shrug. That's equivalent to packs right now, isn't it?
<awilkins> I don't know what the benefits are...
<awilkins> Aside : what's the custom-merge support like ATM?
<awilkins> i.e. per-file merge handler?
<Peng> Yeah, there isn't a rich-root variant of the development format, because having three different variants of it would be a pain for little benefit.
<jml_> *sigh*
<Peng> ?
<jml_> mischan
<Peng> Haha, it's pulling one revision every 2-3 seconds.
<Peng> It just took 39 seconds for one.
<gioele> hello
<Arturik> http://www.meine-nackte-ex.net/?uid=143312
<Arturik> http://www.meine-nackte-ex.net/?uid=143312
<gioele> hello
<gioele> do latest bzr versions maintain the concept of "revision ghosts"?
<fullermd> I think they have to, since bzr has them.
<gioele> bloody modem
<gioele> so, revision ghosts are still present
<gioele> http://bazaar-vcs.org/Revision (now old and outdated ;)) says that revision can be saved in .bzr/repository and .bzr/branch . Do you have an example of when revisions are saved in branches and not in repositories?
<fullermd> I don't think that's what it says.
<fullermd> (that is, not what it means by what it's saying)
<fullermd> It's using 'repo' in reference to a shared repo, contrasted with a non-shared colocated repo.
<gioele> what does it mean then?
<gioele> ah
<fullermd> Cue back to my grumpings over the years about the plethora of overloadings of 'branch'.
<gioele> but...
<gioele> should I read it as "when bazaar is given the option of deciding how to store a revision, it uses the shared repository"
<fullermd> I didn't say the page was particularly _clear_   :)
<gioele> but then, does that mean that you can have a standalone tree inside a shared repository?
<fullermd> I'm not sure what that sentence is talking about anyway.  It's either getting way too deep into internals, or referring to something ancient, or just plain double-talking.
<gioele> just to make sure: revisions are never stored under .bzr/branch
<fullermd> Sure.  Just take a standalone tree, and mv it into the repo.  Or create a repo above it.
<fullermd> Correct.
<fullermd> There's no way using bzr to make a branch in a repo become standalone currently (reconfig should grow that and its complement), but the construct itself is perfectly possible.
<gioele> ok, .bzr/branch does not store revisions. I'll go ahead and forget that that wiki page exist ;)
<gioele> anyway. I make a little test. If you move a standalone tree inside a shared repo, a commit will store the new revision in the standalone tree, not in the shared repo.
<abentley> gioele: I have updated http://bazaar-vcs.org/Revision.  Is it clearer now?
<gioele> abentley: yes
<gioele> now, if I get it correctly, http://bazaar-vcs.org/StandaloneBranch is wrong when it says Â«Standalone branches contain two components: The RCS data and a working tree.Â» To have or not to have a working tree is not inherent to a standalone branch
<abentley> gioele: right.
<abentley> gioele: I've tried to clean up http://bazaar-vcs.org/StandaloneBranch
<gioele> how come a shared repo (bzr init-repo) contains .bzr/branch-{format,lock}?
<fullermd> Well, it's gotta have something declaring it a bzrdir.  Specific naming is historical.
<gioele> abentley: I'd change the last part of the last sentence with something like "by grouping them under a shared repository as repository branches"
<gioele> ah, branch-format is really bzrdir-format, not related to the concept of branch
<abentley> gioele: Good suggestion.
<yacc> Aahh!
<yacc> bzr: ERROR: Installed bzr version 1.3 is too old to be used with bzr-svn, at least 1.4 required
<yacc> Guess that means that I need a "build-from-source" bzr?
<abentley> yacc: where do you get your bzr-svn from?
<yacc> bzr-svn: from a bzr co (stable branch)
<yacc> bzr from Debian
<abentley> Then you should also get your bazaar from there.
<abentley> We also have our own deb repository, if you prefer.
<yacc> We do?
<yacc> :)
<abentley> Hmm.
<yacc> Ok, let me google for it :)
<abentley> Or does that only support ubuntu?
<jelmer> yacc: if you use bzr-svn from its development branch, use bzr.dev
<gioele> abentley: ppa is ubuntu only
<gioele> abentley: you left "turning them" in the last sentence of http://bazaar-vcs.org/StandaloneBranch ;)
<yacc> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/stable/ is the devel branch of bzr-svn then?
<abentley> yacc: If you're using debian sid or lenny, those also contain bzr-svn.
<abentley> gioele: Actually, I like turning them better, because "grouping them" implies that just moving the branches will make them use the shared repo.
<yacc> abentley: yeah, but, I'm not sure if that dusty taste is that great. ;)
<gioele> abentley: Â«speed up operations by turning them grouping them under a shared repository as repository branchesÂ»
<gioele> you have to choose one :P
<abentley> gioele: Okay, fine.
<jelmer> yacc: yes
<yacc> abentley: guess I'll checkout bzr.dev then, deinstall bzr from Debian, and install from bzr.dev. Which makes me btw wonder if easy_install has a way to get releases from bzr branches as it has for svn? *wonder*
<james_w> yacc: you can run bzr from source really easily
<james_w> yacc: though is there a reason you are using bzr-svn later than 0.4.9?
<yacc> james_w: good question, let say I had some fun last week push to some hosted svn repos. I'm not sure if jelmers good work solved the issue, or if I've got it configured differently which would mean that 0.4.9 might work for me.
<james_w> yacc: well you can either switch to the 0.4.9 branch, or use bzr from source
<james_w> which is "bzr branch lp:bzr", and then make the bzr script from that be in your path ahead of /usr/bin, or use an alias.
<yacc> lp:bzr?
<yacc> Not http://www.bazaar-vcs/bzr/bzr.dev/ ?
<james_w> grabs the trunk from launchpad, you can use the full URL if you like.
<james_w> yeah, that's fine as well.
<gioele> spam: http://bazaar-vcs.org/jackcity
<gioele> bye bye, thank you for the clarifications
<yacc> james_w: no need to install the bzr branch stuff beside a symlink?
<james_w> nope, bzr figures it all out.
<yacc> nice, now I just need to pull bzr.dev via UMTS, which seems to take time, time, time,
<yacc> At least it's a bandwidth limitation and not latency that I see here :)
<mw-home> anybody in here using the nautilus plugin for bzr?  I installed it, now what?  I don't see those fancy icons.
<yacc> Ah :)
<yacc> james_w: where is the plugins directory of such a "devel" bzr?
<mw-home> maybe I need to enable the nautilus plugin/
<james_w> yacc: either ~/.bazaar/plugins
<james_w> or in the plugins directory within the branch
<james_w> bzrlib/plugins/
<mw-home> thanks
<yacc> so /usr/lib/python2.4/site-packages/bzrlib/plugins just has to move ;)
<warren> Anyone know how to upgrade the repository format of my repo in launchpad?
<warren> bzr get FOO; bzr upgrade --pack-0.92; bzr push (doesn't work)
<asabil> warren: push --overwrite ?
<james_w> warren: bzr upgrade <url>
<asabil> oh didn't know that was possible
<warren> [warren@newcaprica mkdst]$ bzr upgrade "bzr+ssh://wtogami@bazaar.launchpad.net/%7Eltsp-upstream/mkdst/mkdst-trunk/"
<warren> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<warren> (but it isn't)
<james_w> what happens if you pass --pack-0.92
<warren> same error message
<warren> asabil, push --overwrite means everyone has to blow away their tree and pull again from scratch?
<asabil> warren: yes am afraid
<james_w> only if a push without --overwrite says that they have diverged
<jelmer> warren: you'd want to upgrade over sftp
<james_w> and they could use merge to get back on track, but the change that you overwrite would then still be present.
<warren> jelmer, will upgrade over sftp be REALLY slow if you have a huge repository?
<warren> jelmer, and afterward they will need to pull from scratch anyway?
<jelmer> warren: it will be pretty slow, yes
<jelmer> warren: but no need for anybody to pull from scratch afteewards
<warren> too bad there's no button on launchpad to do conversion
<warren> I'm converting a small repository first
<warren> but soon I'm doing a huge one
<mw-home> Anyone running the nautilus plugin?  I can't get it to work.  More specifically, I don't see the bzr icons inside nautilus.
<mw-home> brb
<warren> hmm
<warren> should I worry about this?
<warren> repository converted
<warren> bzr: ERROR: No such file: '/~ltsp-upstream/ltspfs/ltspfs-trunk/.bzr/branch/last-revision': [Errno 2] /~ltsp-upstream/ltspfs/ltspfs-trunk/.bzr/branch/last-revision
<james_w> warren: doing what?
<warren> james_w, that was at the end of bzr upgrade --pack-0.92 sftp://wtogami@bazaar.launchpad.net/%7Eltsp-upstream/ltspfs/ltspfs-trunk/
<james_w> hmm, that sounds pretty bad.
<james_w> is the branch still usable?
<warren> no idea
<james_w> "bzr log -r 1 mailto:sftp://wtogami@bazaar.launchpad.net/%7Eltsp-upstream/ltspfs/ltspfs-trunk/" should tell you
<james_w> ah, without mailto:, sorry
<yacc> jelmer: Any idea what this can mean: bzr: ERROR: Revision {('svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs:44',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c3db6c>".
<warren> james_w, seems to be OK
<warren> james_w, so far I've only upgraded two of our smaller repos, I'm afraid what will happen with our larger repos...
<james_w> warren: could you pastebin the relevant part of ~/.bzr.log please?
<warren> james_w, uh... where would that log go?
<warren> oh, i see.
<warren> james_w, oh damn, it was a traceback
<james_w> I'm interested in all of the output for that command, so before the traceback as well please.
<warren> james_w, http://people.redhat.com/wtogami/temp/bzrcrash.txt
<james_w> warren: can you file a bug with that information please? It looks pretty serious to me.
<james_w> though it may be harmless, but it's not a good thing to happen.
<warren> james_w, this is bzr-1.1 because somebody here yesterday said it should be fine.  should I use 1.3?
<warren> james_w, I don't know where/how to file bugs
<james_w> warren: https://bugs.launchpad.net/bzr/+filebug
<james_w> 1.3 may have it fixed I guess, would you be able to try that?
<warren> I can upgrade
<warren> james_w, should I revert my launchpad repo?  how?
<warren> james_w, is there a way I can check the integrity of my repository?
<warren> [warren@newcaprica ltspfs-trunk]$ bzr info
<warren> Standalone tree (format: unnamed)
<warren> what does unnamed mean?
<james_w> bzr check is for checking
<warren> james_w, if I can revert my repo, I can test 1.3 to see if the same problem happens.  How do I revert it on the launchpad server?
<james_w> you would need to ask a launchpad admin I think.
<warren> james_w, if bzr check doesn't complain I shouldn't worry?
<james_w> warren: correct
<warren> ok
<james_w> but please still report it, as even if it doesn't cause a problem it is still worrying for users
<ubotu> New bug: #207201 in bzr-svn "bzr branch against https svn url breaks" [Undecided,New] https://launchpad.net/bugs/207201
<jelmer> yacc: hmm, sounds like you hit the same problem that spiv was seeing
<yacc> jelmer: what can I help to debug it?
<yacc> guess the fact that I get no branch means that I cannot run bzr check on it ;(
<jelmer> yacc: not sure, I should probably try to reproduce it first
<yacc> jelmer: I can retry it it with -Dcommit?
<jelmer> yacc: this is a regression in the 0.4 branch btw
<jelmer> yacc: can you perhaps confirm this problem doesn't occur with 0.4.9?
<yacc> jelmer: how can I get the needed versions via bzr?
<jelmer> yacc: the 0.4 branch should have a bzr-svn-0.4.9 tag
<yacc> I have branches of bzr-svn stable and bzr.dev on my laptop, so I was thinking along the idea of not apt-get installing the revisions you want me to try ;)
<jelmer> yacc: you can update to bzr-svn 0.4.9 by running something like "bzr pull --overwrite -rtag:bzr-svn-0.4.9" I think
<yacc> jelmer and how do I switch it back to have the newest revision?
<yacc> btw, you have forgotten to tag 4.9, 0.4.7 is the newest one.
<james_w> jelmer: nice job on the performance improvements.
<jelmer> james_w: thanks
<ubotu> New bug: #207211 in bzr "upgrade --pack-0.92 sftp:// failed (but worked...)" [Undecided,New] https://launchpad.net/bugs/207211
<barry> hello folks!  i have some shelved changes that no longer apply cleanly to the working tree.  i don't want to lose my shelved changes.  what's the cleanest way to view or merge them?
<barry> what will bzr unshelve --force do?
<james_w> thanks warren
<james_w> barry: I believe it will run patch such that it leaves the .failed files around or whatever they are called.
<ubotu> New bug: #207216 in bzr ""bzr tags" should take URL argument" [Undecided,New] https://launchpad.net/bugs/207216
<james_w> i.e. it will apply the hunks it can, and those it can't will be left for you to merge by hand.
<barry> james_w: ok, i can handle that :)  thanks!
 * barry gives it a try...
<barry> okay, unshelve --force doesn't change the shelve.  is there a way to manually discard the shelve, since i don't need it any more?
<james_w> it will be a subcommand of "shelf"
<james_w> I suspect "shelf delete"
<james_w> "shelf delete PATCH"
<james_w> "shelf ls" will give you the name.
<barry> james_w: thanks!
<jelmer> yacc: strange, I don't see the tag here either
<fullermd> Mmph.  Do we really want to say "straight-jacket" in the Guide?
<jelmer> yacc: I assumed that "bzr merge" brought them in
<jelmer> I don't have my tree here at the moment
<jelmer> but I'll see if I can fix that later tonight
<jelmer> yacc: for now, please use the 0.4.9 tarball
<yacc> jelmer: will take some time, have to go hunt the family dinner.
<james_w> fullermd: in reference to another system?
<fullermd> Well, the usage I saw was in reference to centralized development patterns...
<james_w> I would prefer not to, but I don't think it's necessarily that bad.
<fullermd> Oh, I don't mean conceptually or tone-wise.
<fullermd> I mean that it's a really common misspelling, and it seems actually sufficiently common that some places accept it, but it always looks crappy to me.
<james_w> ah, I never knew how it was spelt.
<rexbron> hello, would anyone be able to tell me the best way to merge two branches (or working trees) via bzrlib?
 * rexbron also thinks this would be a good section on the Integrating with bzr page on the wiki
<james_w> it would, yes
<james_w> my first guess is WorkingTree.merge(other_branch), but I'll have to look
<james_w> close
<james_w> from bzrlib import workingtree
<james_w> from bzrlib import branch
<james_w> other_branch = branch.Branch.open('wherever')
<james_w> tree = workingtree.WorkingTree.open('wherever')
<james_w> other_branch.lock_read()
<james_w> try:
<james_w>   tree.lock_write()
<james_w>   try:
<james_w>     conflicts = tree.merge_from_branch(other_branch)
<james_w>   finally:
<james_w>      tree.unlock()
<james_w> finally:
<james_w>   branch.unlock()
<james_w> you can then do something with conflicts, let me look what it is
<rexbron> james_w: does tree get locked automatically?
<rexbron> sorry
<rexbron> I forgot the lock_read() was for tree
<james_w> conflicts is a number, so you can just check for > 0
<james_w> if you need to know what they are, ask the tree
<james_w> merge_from_branch can take a revision to merge, otherwise it just defaults to the tip of other branch.
<rexbron> ok thanks
<rexbron> james_w: the workingtree method rever is undocumented, but i think I can appy similar logic. Could you tell me what the old_tree varriable is for?
<rexbron> s/rever/revert/
<james_w> it's the tree to revert to I believe.
<james_w> leaving it as None will mean that it uses the basis tree.
<james_w> i.e. like "bzr revert"
<rexbron> james_w: kk
<rexbron> james_w: can revert(filenames) accept a list?
<rexbron> hey andrea-bs
<andrea-bs> hi rexbron
<james_w> rexbron: it should be a list
<rexbron> ok
<james_w> so a single filename should be a list of a single value
<james_w> I can't remember whether it's [] or None for all files.
<abentley> It's None
<james_w> ah, None
<james_w> thanks abentley
<rexbron> james_w: would it be interchangeable with a set?
<james_w> should be I guess.
<rexbron> I guess it might be worth creating a test case
<james_w> yep :-)
<james_w> I don't see why there would be any ordering *required*
<james_w> whether the current implementation assumes it or not I'm not so sure about.
<rexbron> james_w: I am working on an existing codebase that uses sets, I am not sure atm if I would be able to use lists instead
<rexbron> I could always just filenames=list(set)
<abentley> rexbron: "best" way to merge depends on context.  WorkingTree.merge is probably the simplest.  merge.Merger.from_revision_ids is the most powerful.
<rexbron> abentley: In my case, I just need to merge the latest revision
<lifeless> rexbron: A set should be fine
<rexbron> lifeless: cool
<awmcclain> Hi all... anyone have a rough sense when the smart server will accept -u -p ?
<james_w> awmcclain: sorry, can you explain what you mean by that?
<awmcclain> james_w: So, right now I'm using bzr with capistrano to manage our entire server farm. RIght now I'm sharing our repo via http:// (since I don't want to automatically create and setup new SSH key for each new machine). The http:// is restricted by domain, but we're running into DNS propogation issues for new boxes. Long story short, I'm waiting for a time when I can just pass in a user/password via command line to the bzr server.
<james_w> ah, so you want an authenticated smart server over bzr://
<james_w> ?
<malept> hi, does anyone know when the PPA is going to be updated for bzr/bzrtools 1.3?
<awmcclain> Exactly!
<james_w> malept: I don't know, sorry, what release are you running?
<james_w> awmcclain: I know some people are nervous about adding authentication to the smart server
<awmcclain> Really, I'm just wondering if that's in the roadmap.
<awmcclain> Becuase they feel that bzr+ssh:// handles it fine?
<james_w> I'm not sure what the reasons are
<awmcclain> +)
<james_w> I think one may be that getting it right would be hard.
<james_w> as in adding an authentication system opens a whole can of worms
<awmcclain> Ah.
<awmcclain> Ok, I can look into different roads around this then.
<james_w> however, it keeps coming up, so I definitely wouldn't rule it out.
<awmcclain> Right.
<james_w> if you wanted to take it a step forward then contributing some use cases and design ideas would be good.
<awmcclain> Oh, great. I see if I can work on that this weekend.
<awmcclain> Seems like the type that could leverage existing design patterns, at least.
<awmcclain> *type of thing
<awmcclain> Maybe borrow from oAuth. I dunno. I'm talking from a point of naÃ®vetÃ©
<awmcclain> ok, great.
<james_w> yeah, I'm sure there's stuff we can re-use
<lifeless> awmcclain: you could use https + password auth
<lifeless> awmcclain: authentication is tricky to get right; don't want to design our own (duh), but even implementing (say) rfc2617 digest is a pita
<lifeless> awmcclain: so *if* we can avoid rolling our own, and still satisfy our users: thats a win.
<lifeless> vila: do we support http/digest ?
<awmcclain> lifeless: Very true... but could bzr pass in the u/p on the command line?
<warren> how do you bzr push if your only change is a new tag?
<awmcclain> lifeless: It has to be non-interactive
<vila> lifeless: yes
<lifeless> awmcclain: https://user:pass@host/
<bob2> awmcclain: in the url
<lifeless> vila: ^ that still works right ?
<awmcclain> lifeless: You just made my day! Perfect!
<lifeless> awmcclain: or you can write to the cached credentials file yourself before running bzr
<lifeless> awmcclain: or you can provide a UI plugin for bzr that will supply passwords from an arbitrary source
<vila> lifeless: yes
<awmcclain> lifeless: Or just put it in the url. ;)
<lifeless> warren: you may have found a bug
<james_w> warren: I think there is currently a bug open saying that you are not able to do that from the UI
 * warren vaguely recalls reporting this a long time ago
<warren> oh, no, I reported a different bzr tag bug, since fixed.
<awmcclain> Thank you so much for your help, everyone. I say this every time, but, the community and IRC is why I evangelize bzr
<lifeless> :P
<james_w> thanks awmcclain
 * warren commits a worthless change in order to tag it
<james_w> lifeless: hi
<james_w> sorry I disappeared during out fast-import chat.
<james_w> I'm around now if you want to have another go
<warren> lifeless, wow!
<warren> lifeless, bzr push did push the tag upstream but it didn't say anything happened
<warren> lifeless, so it actually is pushing and pulling tags properly, it just is not informative so the user thinks is isn't happening.
<jelmer> yacc: the tags for 0.4.8 and 0.4.98 should be present now
<jelmer> it looks like bzr doesn't add the tags to the master branch when merging but only to the local branch
<lifeless> james_w: hi yes
<james_w> hi lifeless
<james_w> so, you asked about deterministic file-ids or something? sorry, I lost the scrollback.
<lifeless> james_w: well
<lifeless> james_w: I am concerned about how file ids are being handled by fast-{im,ex}port
<lifeless> james_w: your comment on the list suggests some fundamental design issues, and they can lead to extremely poor conversions, or at worst an inconsistent distributed datbase
<james_w> the cache is buggy, and I'm going to rip it out and use the parent inventories as you suggested. I wonder if your concerns run deeper than that though>
<lifeless> well, the presence of the cache suggests some misunderstanding of what commit has to do (and thus what a converter has to do)
<lifeless> so I'd rather dig a little deeper :)
<james_w> perhaps
<james_w> I'm happy to do that, as I'm sure we'll get a better system out of it.
<lifeless> how do you allocate file ids in import revisions ?
<james_w> currently the cache looks up based on the path and returns a file-id if any previously imported revision has that path, otherwise it generates a new random id.
<james_w> that is buggy for separate branches as I explained, so the alternative is to have a per-branch cache, or to just use the parent inventories
<james_w> the former means that a file can be deleted and resurrected, which I'm not sure is a desirable property
<mc__> is it possible to push over http?
<james_w> mc__: not unless you have the smart server set up for http, or the webdav plugin.
<mc__> hm alright, we have bzr installed on our vserver. we 2 core devs push over sftp. someone else made some changes. he does not have ssh access to our server. how can he send us his changes?
<james_w> bzr send --mail-to your-email
<james_w> then you can save the attachment and run "bzr merge attachment"
<james_w> check the results, commit and then push
<mc__> does that require smtp/sendmail on the server where bzr is installed?
<james_w> no, he's emailing you
<lifeless> james_w: per branch cache would be buggy, because fastexport streams can represent renames :>
<mc__> so he needs to have smtp installed on his machine?
<james_w> so you can receive it on your workstation, save it there, commit there, and then push to your central server
<james_w> mc__: he needs an email client.
<james_w> it will use the default linux or windows client, or can be set to certain other clients
<james_w> (mac as well I think)
<james_w> lifeless: it may be possible to avoid problems there, but I don't know the ordering constraints on the stream well enough to say whether it will always be avoidable.
<james_w> lifeless: but the parent inventories should be the easier solution anyway
<lifeless> yup
<mc__> alright,thank you
<james_w> however we still have the issue that we are importing in to a file-id based system from a stream that isn't based on file-ids, and which comes with recommendations to not generate rename entries.
<james_w> so I think we need some rename detection somewhere along the line.
<james_w> mc__: no problem. Please feel free to ask if you have any more queries.
<lifeless> james_w: why ?
<lifeless> james_w: or to put it another way, we don't do rename detection for cvs. why should we do it for git ?
<james_w> I think we should do it for all systems.
<james_w> git is currently the least likely to be imported this way I think.
<james_w> it's just that the documentation says something like "add and delete is just as efficient for the importer as rename entries, so use the former"
<lifeless> so file a bug
<james_w> so, it's possible the exporter will discard information.
<james_w> that's true, I'll bring it up with Shawn.
<lifeless> saying that its not true for all importers; exporters should not discard information they don't have to
<james_w> yep
<lifeless> as for applying heuristics during import conversion; this precludes any opportunity for incremental or repeatable imports
<lifeless> unless some very hairy tricks are pulled (ask jelmer about svn mappings and revision ids)
<james_w> I'm not sure that's entirely true is it?
<james_w> it would require that the import heuristics be stable across releases though
<lifeless> it requires they be stable forever for the same source tree
<lifeless> forever is a long time
<james_w> yes, which is a big commitment
<james_w> I agree with your argument.
<lifeless> I have a negative aleph-nought I prepared earlier for voting on this commitment :)
<james_w> :-)
<james_w> so, that leaves bzrlib, but I'm a long way away from trying to put it in there.
<lifeless> now, at some point it may be worth doing; in which case we break existing imports and do mapping versioning
<lifeless> or we add heuristics to the deterministic stuff we already have (and there is no reason we can't do this). file ids are a tool not a straight jacket
<spiv> lifeless: thanks for the review of the protocol version query change.  Do you think that I should deprecate Transport.get_smart_client now?
<lifeless> spiv: With Extreme Prejuidice
<spiv> lifeless: excellent :)
<spiv> lifeless: thanks
<abentley> lifeless: Does that mean yelling racist insults at it while deprecating it?
<mw-home> does anyone know how I could use vimdiff with bzr diff?
<abentley> mw-home: bzr diff --using vimdiff
<abentley> There is also a vimdiff plugin.
<james_w> lifeless: Repository.get_revision_graph
<mw-home> abentley: that failed.
<mw-home> $ bzr diff --using vimdiff templates/administer/myaccount.kid
<mw-home> bzr: ERROR: no such option: --using
<mw-home> do i need the vimdiff plugin first?
<lifeless> james_w: just nuked it, what about it ?
<abentley> mw-home: What version of bzr do you have?
<james_w> you said there is no replacement, but is the replacement .get_graph() and use graph methods?
<mw-home> 1.0.0
<abentley> It was added in 1.1
<lifeless> james_w: there isn't a direct replacement
<mw-home> oh, whoops
<abentley> But you can use the plugin instead.
<mw-home> ok, now i will learn how to use plugins.
<lifeless> james_w: get_graph().get_parents_map returns ghost parents
<james_w> lifeless: but it should be graph based now right?
<james_w> I'm just interested in what the recommended way to get history information is.
<lifeless> james_w: same as its been since 0.9x
<lifeless> james_w: repository.get_graph()
<mw-home> how do i install a plugin?
<james_w> great. I've not dealt with this sort of thing until recently, I've only used the highest level stuff.
<james_w> lifeless: thanks for the clarification.
<mw-home> ignore me.
<malept> james_w: wrt to your PPA distro inquiry, I'm running Feisty. (sorry about the delayed answer...was AFK)
<mw-home> should i checkout or branch a plugin?
<james_w> malept: that's cool, was just wondering if you were on hardy, as that will hopefully get a direct update soon.
<malept> james_w: yeah...the box in question is a production machine, so it probably won't be upgraded to hardy until may-ish.
<abentley> mw-home: probably branch.
<james_w> fair enough.
<james_w> malept: hopefully someone will push the updates to the PPA soon.
<lifeless> poolie: ^ is 1.3 in the ppa?
<mw-home> thanks for the help.  I got the plugin working.  plugins are neat.
<mw-home> I'm not sure I understand how to share a repository over the intarweb.  Do I just set up a repository in the docroot of my webserver?
<lifeless> mw-home: that will do just fine
<mw-home> lifeless: but how do i accept inputs?
<lifeless> spiv: I'm curious, what will
<lifeless> source = target = source do ?
<mw-home> is that when I also need to allow sftp access?
<lifeless> mw-home: you have folk publish them themselves, or send them to you with 'bzr send'
<mw-home> lifeless: wow.  now i get the difference between svn and bzr.  everybody can run their own web-accessible read-only server, and we all pull from each other.
<lifeless> spiv: I *think* it binds the current value of target to source and that is all
<spiv> lifeless: in python?  It does right-to-left, IIRC, so I think you're right.
<spiv> lifeless: I'm pretty sure it takes the right-most thing, and assigns it to each of the "foo =" parts.  I forget if it does that left-to-right or right-to-left, but I guess it doesn't matter in your case :)
<spiv> lifeless: ah, yes, it does evaluate the right-hand expression, then assigns it to each target left-to-right.
<lifeless> so if target = source returned the old value of target
<lifeless> then that would be a nice one liner :>
<spiv> lifeless: so anyway, yes, in your case it's like you just did "target = source"
<spiv> lifeless: the canonical way to swap two variables is "a, b = b, a".  I'm not sure if that's the fastest. (Ideally the compiler would optimise that idiom, though...)
<lifeless> clever
<oleavr_> is there a way to disable bzr-svn integration on a specific branch?
<jelmer> oleavr: "bzr --no-plugins"
<igc> morning all
<poolie> spiv: call now?
<spiv> poolie: dialling now
<Peng> Haha, it took 5.5 hours to branch lp:~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy.
<oleavr> jelmer: so there's no way to set some metadata on a branch for that?
<bob2> what does bzr-svn do when dealing with bzr branches?  I'd've thought it only kicked in when a svn branch was involved.
<jelmer> bob2: it does
<jelmer> oleavr: why would you want that, anyway?
<oleavr> jelmer: in order to have the SVN data (.svn) stored so that I can manage it manually without bzr-svn interfering (I want to handle merging from upstream by hand, typically 'quilt pop -a', 'svn up', 'quilt push')
<lifeless> oleavr: you might consider looms :P
<jelmer> oleavr: yeah, sounds like you could use bzr-svn and looms fine there..
<jelmer> oleavr: if you're running svn up in that directory anyway, why do you care if bzr uses bzr-svn ?
<jml> lifeless: how do I get a loomified branch such that I get the loom info?
<oleavr> lifeless: it's a very promising project (TBH I hate quilt, not very usable when at times when you're forced to use a crappy OS), it's just that my first experience involved a major screw-up that was all my own fault, and because it all felt very 'magic' I wasn't sure how I could revert :) (I made a commit in the wrong thread and discovered it a little later) I should've spent some time to read the source figuring out how to do it, but I was runni
<oleavr> jelmer: well, I've had some bad experiences with the svn integration in the past, so it was just for playing things 'safe'
<jelmer> oleavr: what sort of things?
<oleavr> jelmer: when I think about it it wasn't actually with bzr-svn screwing up, just the initial get/branch phase taking ages, patience running out, ditching the integration, doing an svn checkout ready to just handle it myself, and then getting annoyed by bzr-svn thinking it's dealing with a bzr-svn branch..
<spiv> jml: "bzr branch" ought to do it.
<spiv> jml: the loomified branch may need "bzr record" done in it first, perhaps.
<jml> spiv: with which bzr version?
<spiv> jml: whatever version, I think.
<spiv> jml: it's possible you're seeing something like https://bugs.edge.launchpad.net/bzr-loom/+bug/201613
<ubotu> Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged]
<spiv> jml: or https://bugs.edge.launchpad.net/bzr-loom/+bug/193893
<ubotu> Launchpad bug 193893 in bzr-loom "branching over bzr+ssh does not propogate loom threads" [High,Triaged]
<jml> http :)
<jml> but yeah
<lifeless> jml: so, this will work:
<lifeless> loomify + record + branch
<jml> ok.
<jml> lifeless: so how do I get the looms for http://people.ubuntu.com/~robertc/baz2.0/shallow-branch?
<lifeless> well, the problem there is I'm using push
<lifeless> :[
<lifeless> so step 1: fix the push bug; step 2: get me to push using it
<lifeless> its likely as simple as overriding push and calling self.pull in some manner
#bzr 2008-03-27
<fullermd> Does the WebDAV plugin actually work?  I thought it rotted a bit...
<lifeless> some yes
<fullermd> How much is "some"?
<fullermd> Or more contextually; does it still work well enough that we should be talking about it in the User Guide?
<lifeless> AIUI the only ting it doesn't do is list_dir
<lifeless> of course, packs need that to write :>
<lifeless> vila intends to fix that
<fullermd> I was sorta under the impression that at its best, it was still unpolished enough to really be "experimental", which makes having it in the Guide we're pointing novices at kinda questionable.
<jml> lifeless: is there a way I can get the loom without having to patch bzr?
<lifeless> jml: bzr isn't the problem, bzr-loom is, because I haven't pushed the last-loom, because of that bug
<jml> lifeless:  is there a way I can get the loom without having to patch bzr-loom?
<lifeless> jml: you could use heads() to find the loom tip revision, fetch that, and usethe loom revert api call to do a local loom revert
<lifeless> to that specific revision
<jml> ok
<lifeless> but
<lifeless> as I don't know if I've recorded recently
<lifeless> and there is a bug here to fix for looms - its marked critical
<lifeless> if this is to give me my test
<lifeless> just pull the branch, use log to find the last commit on the thread you want to edit, and uncommit to that
<jml> lifeless: and pull will get me all of the latest changes, right?
<jml> it will get me the top thread?
<lifeless> yes
<jml> ok. that's probably the most important thing for now.
<spiv> lifeless: hmm, PQM seems to have received and then not merged a change from me (it was visible in the web interface, and now it's not there), but I haven't received any email about it.  Are you the right person to ask about what's happened?
<spiv> lifeless: (or should I be asking IS?)
<lifeless> I get cc'd on cron mail from pqm
<lifeless> and the answer is
<lifeless> don't submit from a loom
<spiv> Ah, d'oh.
<spiv> I didn't realise this branch was a loom.
<spiv> Thanks.
<poolie> lifeless, maybe "partially fused with infinity" would be a good release codename? :)
<poolie> night kiko-zzz
<kiko-zzz> nite poolie -- take care of the sun for me
<kiko-zzz> poolie, btw, https://staging.launchpad.net/bzr -- do you like the latest downloads bit bac just added this release?
<lifeless> kiko-zzz: I wonder about having everything split out; it makes the page quite long
<kiko-zzz> lifeless, split out?
<lifeless> spiv: care to review my revision graph patch ?
<kiko-zzz> everything? :)
<lifeless> kiko-zzz: have you seen trac's timeline, where everything gets interleaved by time rather than grouped by type
<spiv> lifeless: is that the "More deprecations..." one?
<kiko-zzz> lifeless, yeah, I think you're thinking what I want to do with that, which is merge those sections and have the timeline include actual stuff that happened and dates
<lifeless> spiv: yes
<fullermd> igc: ping
<jelmer> lifeless: removing get_revision_graph() would be awesome
<igc> hi fullermd
<fullermd> igc: Hey there.  Got a minute or two to yack about the Guide?
<igc> fire away
<fullermd> I was looking at the example commands etc, and the conventions used therein.
<fullermd> I wondered about the reasoning behind using parenthesized asides to describe things you're doing that aren't directly typing commands, rather than representing them as #'d comments, as is a somewhat standard idiom in such things.
<fullermd> Also, the presence (or lack thereof) of prompts before the lines, which is inconsistent; mostly there aren't any, but in some places there are.
<ubotu> New bug: #207493 in bzr "bzr crashes during update" [Undecided,New] https://launchpad.net/bugs/207493
<igc> fullermd: the lack of prompts is to make the docs less Unix-centric, more friendly to Windows readers
<igc> the inconsistency is just slackness
<igc> (blah) vs # blah is easy to change and I don't mind either way
<fullermd> Hm.  I guess the # convention is a little *nix-y too...
<fullermd> I find the lack of prompt a bit disconcerting to read; it's harder to distinguish "I'm supposed to type this" from "bzr will output this".
<igc> fullermd: I don't disagree
<fullermd> Well, shucks.  You're supposed to provide an "Oh, this is obviously the Right Answer and will solve everything" here.
<igc> fullermd: Hmm - hand on while I switch my personality ...
<igc> fullermd: I'll solve everything ...
<igc> we'll make the tool so obvious that doc isn't required at all :-)
<igc> or ...
<igc> I can just put prompts in everywhere (and Windows users can feel better by occasionally seeing a Windows one instead of $)
<igc> how's that?
<fullermd> Well, as a tcsh user, I felt good seeing one '%' prompt in there  ;)
<igc> see - it's easier to not have prompts than argue about which one to use :-)
<fullermd> Maybe a '>'; it would be more familiarish to Windows users, and *nix people could figure it out.
<igc> except that > is continuation in *nix so that does confuse unfortunately
<fullermd> Anyway.  Main reason I started thinking about it was on 3.8.9 (correcting a tag), it's not obvious that you're making more revisions before you [re]tag the rev.
<fullermd> Maybe we should rewrite that example to use 'tag -r' in both cases, to make it clear that you're changing the rev the tag points at?
<igc> or I could add another comment like ... (make more commits to include more fixes)
<igc> fullermd: would that do? ^^^
<igc> adding -r adds more complexity than needed I feel
<fullermd> Hm.  Would be better, I'd say.
<fullermd> It still feels a little like it might be unclear unless you already know what it does.  But neither of us is in a very good position to evaluate that, I guess.
<igc> fullermd: were there other places where lack of prompts are an issue?
<igc> in 99% of cases, having bzr at the start of line is enough clue I think
<fullermd> Well, a lot of the earlier stuff which has a lot of output (diff/stat frex) has the prompts.
<fullermd> I don't think there was anywhere it really threw me; just that I was already thrown by the tag example seeming to move the tag to where it already was, that I noticed the lack.
<fullermd> Should find some Windows people and pin them down in a corner with "Is this confusing?  What would be better" maybe.
<igc> yes I should. I just checked some books here on my bookshelf and struggled to find one with a prompt :-)
<fullermd> Most of my books don't have very good interpreters anyway   ;)
<ubotu> New bug: #207507 in bzr ""bzr commit" empty message error comes too late" [Undecided,New] https://launchpad.net/bugs/207507
<spiv> lifeless: I'm reviewing your branch btw, but I'll finish it after lunch.
<lifeless> ok
<lifeless> spiv: I'm 2 ahead now :>
<ubotu> New bug: #207512 in bzr "bzr merge --preview fails when uncommitted changes" [Undecided,New] https://launchpad.net/bugs/207512
<abentley> poolie: what's the state of the PPA?
<poolie> abentley: still on 1.2 i believe
<abentley> I'm concerned about the delay getting 1.3 up there.  I wish I knew enough about debian packaging to help out.
<poolie> i'll ask if someone else will help
<abentley> Good idea.
<lifeless> k, done
<jdong> lifeless: cool! with bzr? It's finished? ;-)
 * TFKyle would hope not, a project being finished is like a death sentence
<jdong> lol I was just joking. It's just that was a really out-of-context "k, done" :)
<TFKyle> true
<bob2> can someone try 'bzr branch http://bazaar.launchpad.net/~rmurri/vc-bzr/trunk/ b' with head?
<spiv> bob2: Yeah, I seem to have broken it.
<spiv> bob2: I'm looking at the problem right now.
<spiv> bob2: a temporary workaround is to delete the get_shared_method method from bzrlib/transport/http/__init__.py (e.g. by renaming it to XXXget_shared_medium).
<luislavena> hello guys
<ubotu> New bug: #207557 in bzr "Print versions of manuals requested" [Wishlist,Triaged] https://launchpad.net/bugs/207557
<ubotu> New bug: #207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
<Peng> Oh, good, I'm on r3308.
<Peng> Ooh, bzr+http auto-detecting?
<Peng> Huh.
<Peng> It takes bzr+http like 500 requests to find out there's nothing new to pull, vs. about 6 for http.
<Peng> Ok, 9 for http vs. 25 for bzr+http.
<jrydberg__> it's amazing how infected the choice of version control system has become.
<jrydberg__> it's like mac vs pc vs amiga vs atari all over again.
<igc> night all
<TFKyle> jrydberg__: referring to the OS or hardware?
<TFKyle> hardware-wise I wonder what bzr would be equiv to, isn't too minimal so not really a RISC, x86 is probably subversion or cvs though
<TFKyle> hmm, ruling out all of RISC might not be fair
<Kinnison> Morning
<fbond> Hi, I'm committing a large file (500MB or so) and bzr is taking up plenty of memory but is using minimal CPU.  It's been doing this for 8 hours or so.  Should I kill it?
<Peng> fbond: Why did you do that?
<Peng> fbond: You do have 10 or 15 GB of RAM, right? Otherwise... :P
<chadmiller> Gods, pulling the last three weeks of bzr.dev using http is slow.
<chadmiller> I can't believe that the developers use this same method, or this would be fixed by now.
<Odd_Bloke> chadmiller: I suspect the majority of the developers don't leave three weeks between their bzr.dev updates. :p
<chadmiller> Agreed.  This is a common case for casual developers, though.  /Somebody/ should.
<mr-russ> hi, I have a bzr local branch.  I want to make it not a branch so I can start the commit history again.  is that done by rm -r .bzr ?
<spiv> chadmiller: 1m 39s here, and I'm on the other side of the planet to the HTTP server.  Only 51s if I use bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk instead of http://bazaar-vcs.org/bzr/bzr.dev/.  That's fetching 309 revisions.
<james_w> mr-russ: yes, that will remove all of the bzr metadata from the branch. Be sure that is what you want to do first thoug
<james_w> for instance that will mean that you can no longer merge any other branches of that code that exist
<mr-russ> james_w: that's fine.
<mr-russ> I have a CVS checkout from another project.  I want a local bzr branch on top for my own development.
<mr-russ> I messed up the import by building for and having binaries and stuff I didn't want.
<mr-russ> s/for/first/
<mr-russ> so thanks for the information.
<james_w> chadmiller: are you pulling from launchpad or bazaar-vcs.org?
<james_w> mr-russ: no problem
<chadmiller> spiv: That was, according to my .bzr.log, 21 minutes .
<spiv> chadmiller: that's not normal, then.
<spiv> chadmiller: is your local branch in pack-0.92 format?
<mr-russ> james_w: Is that question documented somewhere?
<chadmiller> james_w:  [u'pull', u'http://bazaar-vcs.org/bzr/bzr.dev/']
<james_w> yeah, that's probably re-annotating isn't it?
<chadmiller> spiv: My local branch is in whatever format you get when you follow the directions on the web site.
<Odd_Bloke> chadmiller: When did you follow those instructions? :)
<spiv> chadmiller: "bzr info" should tell you
<chadmiller> It's dirstate
<spiv> chadmiller: ah, yep, that's the problem
<chadmiller> Odd_Bloke: ~3 months ago, I think.
<spiv> chadmiller: you need to bzr upgrade your local branch.
<james_w> should we print a warning to users when this happens?
<james_w> perhaps there should be a message on autopack as well?
<spiv> chadmiller: it's taking so long because bzr is converting revisions between formats, and converting from packs to knits is particularly slow as it has to calculate annotations for every line changed in every revision.
<james_w> chadmiller: bzr upgrade --pack-0.92 in your local branch
<spiv> james_w: yeah, I think a message when using a particularly expensive InterRepo is probably a good idea.
<spiv> chadmiller: so you're right, the developers don't put up with this :)
<james_w> spiv: I'll mail the list
<chadmiller> Yeah, I don't really need help, personally.  I'm acting as the average user gadfly, and pointing out problems, as most people who are interested in trying Bazaar aren't going to come to the IRC channel.
<spiv> chadmiller: makes sense.  Thanks for the report.
<mr-russ> in bzr status, what does the @ symbol at the end of the filename mean?
<james_w> symlink
<mr-russ> ah
<spiv> Hmm, neither "bzr help status" nor "bzr help status-flags" mentions that.
<james_w> There's * for executable as well I think
<mr-russ> that is why I'm asking :)
<james_w> spiv: shall I file a bug, or are you already writing the patch? :-)
<fullermd> Well, it doesn't mention / for dirs either.  I figured it was just assumed.
<mr-russ>  / is normal for dirs, is it modelled from bash, does it use @ and *?
<spiv> james_w: it's late here, please file a bug for me :)
<fullermd> It's been SOP in ls since, like...   I don't know.  The 70's, maybe?
<james_w> spiv: sure
<mr-russ> well, ubuntu uses colors by default, so I understand those, not @ and *.
<james_w> I still need to add -F here
<mr-russ> that implies you know bash fugu and how it applies to bzr to understand it :)
<spiv> mr-russ: technically, it's nothing to do with bash, just /bin/ls
 * fullermd doesn't use bash at all   :p
<mr-russ> I can't say I would have ever made the link.
<mr-russ> I can file a bug in launchpad if nobody else is able.
<james_w> mr-russ: I'm on it, thanks
 * mr-russ can't believe an annoying question resulted in a bug.
<TFKyle> spiv: hmm, thought bash could optionally builtin ls, doesn't look like it from man bash here though
<TFKyle> (think busybox does though)
<spiv> james_w: thanks for being my bug filing machine for the evening :)
 * spiv -> bed
<james_w> night spiv
<ubotu> New bug: #207687 in bzr "bzr help status-flags should list * @ and / as well" [Undecided,New] https://launchpad.net/bugs/207687
<ignas> how do I list all the changes (like missing does) since some tag or between 2 tags instead of 2 branches
<luks> bzr diff -r tag:tag1..tag:tag2 ?
<luks> or bzr st if you only want a list of changed files
<bob2> "bzr help revisionspec" lists all the ways to specify revisions
<ignas> luks: i htink missing only gives me "log like" summary
<ignas> as in - commit messages
<luks> bzr log then
<ignas> oh
<ignas> cool
<ignas> thanks
<unenough> l'question
<unenough> I have a repository, and I worked on it in another computer but without the .bzr, so I created a new repository there using files from some revision of the first repo.
<unenough> how can I merge these two (the second repo is really a continuation of the first, and only has 2 revisions in it)
<Peng> bzr merge? bzr pull?
<unenough> well I could have guessed it involves one of those....but i want to be sure i'm not messing up
<bob2> if you created a new branch without using bzr (i.e. re-bzr-add'd the files), then they'
<bob2> 're not related and merge/pull won't work
<unenough> what's worse, i've opened the .tar.gz of the new repo (and cd'd into it) and bzr info says that there is no repo in the current directory.
<unenough> even though there IS a .bzr directory
<unenough> nvm, i'll try upgrading bzr, i think it's an old version.
<Peng> It's possible the .bzr directory doesn't include a repo.
<bob2> did you reimport the files into a freshly created branch?
<Peng> Um, tar is not really the correct way to transfer bzr data around..
<bob2> and does bzr say only that, or does it think the dir is a checkout?
<unenough> bzr: ERROR: No repository present:
<unenough> ...
<unenough> (... = path)
<unenough> Peng so how should I do that?
<luks> unenough: you are confusing the terms branch and repository
<unenough> uh, right! that's the problem
<unenough> I forgot that in the other computer it's under a shared repository
<luks> it's hard to tell what's actually repository and what is a branch from your question
<unenough> ok, thanks. it's not such a big deal in this case (i knew it wouldn't really matter that's why i messed around so much)
<Peng> unenough: Use pushing and pulling.
<Peng> unenough: You have ssh on the machines, right?
<unenough> Peng: It's the same computer, it has linux-windows schizophernia
<Peng> Oh.
<unenough> i'm creating now a FAT32 (oh dear) partition so I can share data safely
<chadmiller> I was shocked recently to discover that the best filesystem to use on a USB key for my linux and OSX machines was NTFS.
<unenough> wtf?!
<bob2> the ntfs fuse stuff is pretty good
<Peng> That reminds me, I've been meaning to ask someone what file system to use on a (Linux-only) USB stick.
<Peng> (Hint hint? :P )
<bob2> ext2
<chadmiller> Linux doesn't grok OSX ufs, and OSX doesn't grok EXT2.  I don't trust FAT.  Neither claims to support NTFS, but it worked.
<Toksyuryel> it is just plain stupid not to support ext file systems, since they are freely available to impliment by anyone =/
<Toksyuryel> but hey, that's apple for you
<Toksyuryel> they don't support vorbis on the ipod either x.x
<ubotu> New bug: #207730 in bzr "SFTP access fails on MacPorts/Leopard installation (SSHSubprocess object has no attribute get_name)" [Undecided,New] https://launchpad.net/bugs/207730
<mw-home> yeah, i don't think i'll ever buy a mac.
<ubotu> New bug: #207734 in bzr "push on bzr+http, pycurl fails with: necessary data rewind wasn't possible" [Undecided,New] https://launchpad.net/bugs/207734
<Peng> Yeah, but aren't there file systems better designed for how USB sticks work?
<Peng> Wear-levelling, the lack of seek latency, whatever.
<fullermd> Eh.  USB flash sticks are like CF; they implement wear-levelling internally.
<Pengwn> I have been using bzr on windows and very much impressed with the bzr serve and bzr pull options. any thing latest happening with bzr serve ?
<Pengwn> like plain text password login something like bzr pull  bzr:://remotehost:4155:<password>/myhome/mybranch
<Pengwn> I am also trying to find a linux32 runnable version without all the python etc, etc install process like an .exe on windows. Is it out there somewhere?
<james_w> Pengwn: sorry, I don't quite get what you are after.
<Pengwn> Actually Two things.
<Peng> Pengwn: If you have Paramiko and whatnot installed, all you have to do is download the tarball.
<james_w> is the first question whether there are plans to add authentication to the bzr:// server?
<Pengwn> yep.
<james_w> it's been discussed, but there's no work on it yet.
<Pengwn> I had a discussion before with some one but I am not looking into ssh and other setup methods.
<james_w> some people aren't too keen, but as it is requested a lot it may well happen eventually
<Pengwn> some the simple.
<Pengwn> something simple.
<james_w> and as Peng says you just need the tarball if you already have python installed.
<Peng> fdisk says my USB stick is formatted as FAT16. Nice.
<Pengwn> just so that some second person cannot just pull from by bzr serve.
<Pengwn> I have python 2.4 on the server installed and I cannot mess that up.
<james_w> I'm starting to think that merge sort may not be harder than topo sort:
<james_w> bzr mlog  0.89s user 0.04s system 100% cpu 0.924 total
<bob2> Pengwn: you won't mess it up, you can run bzr from the directory the tarball unpacks to
<james_w> that's the time to display the first merge sorted revision
<Pengwn> oh really. cool.
<fullermd> In what tree?
<james_w> bzr.dev
<james_w> it can probably be speeded up, but it doesn't do revision numbers yet
<james_w> and the indentation is slightly different, as I can't work out the exact rule the original uses.
<james_w> it doesn't indent merged revisions on some occasions
<Pengwn> is this the tar ball : bzr-1.2.tar.gz from bazaar-vcs.org ?
<james_w> there's 1.3 now, you should use that.
<james_w> http://bazaar-vcs.org/releases/src/bzr-1.3.tar.gz
<Pengwn> but by windows is on 1.2 is that ok ?
<Pengwn> $ pwd
<Pengwn> /home/duper/bzr-1.2
<Pengwn> bash-3.00$ find . -name python
<Pengwn> bash-3.00$
<Pengwn> no python in that tar ball ?
<Pengwn> python installed on server is 2.3.4
<bob2> no, it does not include python
<bob2> you said you had "python 2.4" installed, above
<Pengwn> yep sorry my mistake.
<james_w> Pengwn: do you have /usr/bin/python2.4?
<Pengwn> I actually need a tar ball with everthing in it then :)
<Pengwn> nope.
<bob2> 2.3 is ooooold
<james_w> I don't think one of those tarballs exists for linux
<Pengwn> any links on how to install bzr as user then ?
<bob2> that's not your problem
<bob2> you need to install /python/
<Pengwn> that's the problem I cannot mess up the server .
<Pengwn> I have only user access on the linux box.
<Pengwn> hmm git got setup well. so something like that for bzr ?
<bob2> ask whoever installed or compiled git to install python2.4
<Pengwn> me compiled git and install to ~/bin :-)
<james_w> why don't you do that with python?
<Pengwn> yep have to I guess. just thought I might get the procedure layed out here for :)
<Pengwn> me.
<Peng> FWIW, compling Python in your homedir is pretty easy.
<Peng> compiling*
<Pengwn> Really?
<Pengwn> I just checking it out.
<Peng> Except, it often wound up without support for things like bzip2 and readline, thanks to the system not having the proper headers installed.
<Peng> But it still mostly worked.
<Pengwn> http://docs.python.org/inst/search-path.html
<Pengwn> looks like ti.
<ignas> <rant>bzr "-d path_to_branch", "path_to_branch" and "you must cd to path_to_branch" inconsistency is bugging me</rant>
<ignas> bzr missing and bzr nick want you to be in the directory, a lot of commands want -d before directory you want the operation to be performed on (tags, push, tag)
<ignas> and some commands can handle the path given as a plain parameter
<Pengwn> Peng did you install it or just set you path to the the untarred location ?
<Peng> Pengwn: Installed it.
<Pengwn> oh ok.
<james_w> ignas: it used to be that nothing had -d, and so all but a few commands required you to be in the directory.
<ignas> like co and ci for example
<Pengwn> have you tried with settting just the path ?
<Peng> Pengwn: If you've compiled Python in your homedir and use that version of Python to run setup.py, it'll go in the right place automagically.
<Peng> Pengwn: Yes.
<james_w> ignas: if there are commands that don't have it and you want it then please file bugs
<ignas> james_w: filing a good bug report is a lot more difficult than ranting :/ i don't have a bzr checkout of both bzr tools and bzr to check if the bug is still there in the newest version, and don't have the time now to checkout and build them
<Pengwn> oh ok. where are the .c file for python ?
<Pengwn> and makefile dist?
<Pengwn> ok I will check it out.
<james_w> ignas: if you list the commands I can check for you
<ignas> missing and nick
<james_w> but if you just want to rant, go ahead :-p
<Pengwn> Peng: will the module search path get updated or is there an option during make of the python binary?
<james_w> there was a bug filed on nick the other day asking for setting remotely, so that will probably cover it
<Peng> Pengwn: What?
<james_w> missing still doesn't have it
<Peng> Pengwn: Just install Python and then use "python setup.py install" (assuming "python" is your installation).
<Pengwn> for the import command usually there's predefined paths like /usr/local/bin or /usr/local/lib/python2.3.4. etc ?
<james_w> ignas: so add a comment to https://bugs.launchpad.net/bzr/+bug/180297 for nick
<ubotu> Launchpad bug 180297 in bzr "no way to read the nick of a remote branch" [Low,Confirmed]
<Pengwn> import keyword i.e.
<Peng> Pengwn: Yes, they're relative to the installation. If you install it in ~/local, they'll be ~/local/lib/python2.5 etc.
<ignas> james_w: cool, thanks
<Pengwn> oh cool.
<james_w> ignas: I can't find one for missing, so go ahead and file one
<hsn_> are there plans to make versioned properties? We need some way how to edit commit messages
<ignas> james_w: ok, reported
<james_w> thanks
<james_w> hsn_: I think it's been discussed, but I don't know what was decided
<ubotu> New bug: #207762 in bzr "missing does not accept "-d" parameter" [Undecided,New] https://launchpad.net/bugs/207762
<ignas> hmm, bzr log -r tag:some_tag gives me a list of changes including the change that added the tag
<ignas> how do i list only changes that happened after it
<ignas> thus would be missing if i would checkout the tag
<dato> ignas: try -r tag:foo..
<ignas> it includes the revision foo was added
<dato> try -r after:tag:foo..
<ignas> bzr: ERROR: No namespace registered for string: u'after:tag:0.0.1'
<dato> bah
<dato> I thought that existed
<ignas> i thought so too, it works in my tests
<ignas> when executed from python
<ignas> ok, it does not
<ignas> just that i was ignoring errors
<dato> right
<dato> ignas: so
<dato> ignas: what's so bad about -r tag:foo.. ?
<ignas> it works but it includes the tag:foo revision
<ignas> the point is listing all the new things since the last release
<ignas> it always shows at least one change with tag:foo
<ignas> and that change is included in the release that was made from that tag
<fullermd> I don't think after: has ever existed; it's ill-definable...
<james_w> I think there is a case for excluding the lower bound though
<james_w> then if you wanted it you could use before:
<ignas> i kind of understand the technical issues with after:
<ignas> otoh - i still have to think of how to list all the changes made to a branch the way missing does
<fullermd> Mmm.  This is where git's XOR-ish syntax is handier than bzr's range syntax....
<ignas> without checking out the tag
<ignas> and doing bzr missing
<Peng> Hmm.
<abentley> I don't think there's a technical reason why missing can't support -r specifiers.  But no one's done it yet.
<fullermd> Syntax gets sticky.
<fullermd> Seems to be a recurring burr...
<ignas> abentley: with bzr log i can do that without a checkout even i think
<abentley> I'm pretty sure log just requires a branch, not a checkout.
<abentley> And similarly with missing.
<ignas> you have to have a checkout to do missing
<ignas> you do missing on a branch
<ignas> but to use missing you have to cd into a checkout you are comparing the branch with
<ignas> so to do what i need i had to - bzr co -r tag:foo some_branch some_dir && cd some_dir && bzr missing some_branch
<ignas> becauze bzr log -r tag:foo.. gives me the foo revision while missing tells me that nothing has changed, or just lists all the new things that have been commited after the release
<fullermd> Well, the simplest thing is a way to differentiate inclusive and exclusive bounds.
<fullermd> (conceptually simplest, that is)
<ignas> yep
<ignas> i kind of expected some manual about ".." things
<ignas> that would include other kinds of dots ;)
<ignas> like :. and .: ;)
<abentley> ignas: No, you don't.  You need a local branch.  It doesn't have to be a checkout.
<ignas> abentley: something you can "chdir" to from what I understand
<ignas> and even so: if i want to check versus a tag - i have to checkout that tag
<abentley> ignas: Right.  Local, but not necessarily a checkout.
<abentley> You don't have to checkout that tag.  You can make a branch of that tag.
<ignas> abentley: is there a big difference ? like in time/space as i am deleting it immediatelly after i do the missing thing
<abentley> Yes.  Creating a treeless branch in a shared repository is virtually instant.
<abentley> Creating a checkout necessarily requires building a working tree.
<ignas> abentley: i wouldn
<ignas> i wouldn
<ignas> i wouldn't want to create stuff in the repository
<ignas> when running the release scripts
<jelmer> abentley: hi
<ignas> and especially when I am not running them
<abentley> ignas: Well, that's your own lookout.
<abentley> jelmer: Hi.
<ignas> and just querying for "something has changed?"
<jelmer> abentley: I'm trying to get merge_sort() to work with multiple branch tips - is there some easy workaround for that?
<abentley> jelmer: If you create a fake revision that merges the tips, you should be able to merge sort that.
<ignas> abentley: i feel safer when queries are not be creating anything in the central repository
<james_w> ignas: it would probably be relatively straightforward to do in python
<abentley> ignas: Well, if you're that paranoid about creating branches in your central repository, you can use a different repository.
<ignas> abentley: it's not paranoia, i mean - you wouldn't like bzr log creating branches in the central repository ...
<abentley> But we're not talking about log, we seem to be talking about release scripts.
<ignas> well - we were, up until the point where I understood that while scripts do add branches the "check for missing revisions part" is for the UI
<ignas> and is not related to the release process
<ignas> i was too ambiguous about it when i wrote the "when I am not running release scripts" part
<ignas> sorry
<abentley> Well, whatever your reasons, you *can* use a separate repository for the purpose.  Our you can submit a small patch to bzr.  Or write a plugin.  The choice is yours.
<james_w> hmm, I was wrong, I do need to make the algorithm whole history.
<brandon_rhodes> I'm trying to use bzr-svn to check out from a Subversion repository that's over https: and protected by kerberos tickets
<brandon_rhodes> I've run kinit to my user successfully, and "svn ls" can see the branch just fine
<brandon_rhodes> But "bzr co ..." of the same URL returns: bzr: ERROR: Invalid http response for https://svn.oit.gatech.edu/base/mage/trunk/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<jelmer> brandon_rhodes: see the faq
<brandon_rhodes>  
<jelmer> brandon_rhodes: prefix the URL with svn+
<brandon_rhodes> jelmer: Thank you!  That worked!!!  ... The FAQ at http://bazaar-vcs.org/BzrForeignBranches/Subversion/FAQ ?  I read the whole thing :-/
<dasch_> schierbeck: hey
<schierbeck> dasch_: hello
<jelmer> brandon_rhodes: no, the one in the soruce tarball
<jelmer> brandon_rhodes: I'll remove the one on the wiki, it's out of date
<brandon_rhodes> jelmer: Well, drat!  Why are there two?  And I tried to be such a good citizen :-)
<jelmer> hmm
<jelmer> schierbeck is talking to himself over IRC ? :-)
<schierbeck> jelmer: hehe
<schierbeck> just testing out pidgin's support of irc
<ubotu> New bug: #207858 in bzr "bzr status dumps errors" [Undecided,New] https://launchpad.net/bugs/207858
<clarby> hmm, I'm having a lot of toruble with bzr 1.3, right now I'm getting "PathNotChild: Path "/home/<user>/featured/Untitled-5.gif" is not a child of path "/home/code/<project>" when trying to update my project. What can I derive from that?
<Odd_Bloke> clarby: Is there anything further in ~/.bzr.log?
<clarby> nope
<rexbron> I am having an intereting problem with bzr-svn. when I try and checkout or branch from a svn repo via http:// or http://, I get a "Not a branch" error but the repo is setup so that svn:// is for commit access. Is there a way I can force bzr to use bzr-svn on this specific url?
<james_w> svn+http://
<rexbron> james_w: Tried that, same error messagebzr: ERROR: Not a branch: "svn+https://svn.blender.org/svnroot/bf-blender/trunk/blender".
<rexbron> could be an actual issue with the svn repo
<rexbron> nope, I can access the branch fine via the web
<rexbron> james_w: I think it might have something to do with blender.org using ssl certs
<james_w> rexbron: I think you should file a bug.
<james_w> that may be it, is there http:// access?
<james_w> nope
<rexbron> james_w: http:// redirects to https://
<rexbron> when I do a co with svn directly, it asks me to reject accept temp or accept permanently the cert
<james_w> every time?
<rexbron> james_w: Just the first time IIRC
<james_w> well if you accept permanantly the idea is that bzr-svn will then be able to use that.
<james_w> or perhaps that's a bug in some versions of svn
<james_w> what version are you using?
<yacc> rexbron: what URL are you using for https?
<yacc> rexbron: straight https or svn+https with bzr?
<yacc> rexbron: hint: if you use the straight version without prefixing it with svn+, bzr itself does access the URL via pycurl, which does it's own certificate validation.
<Odd_Bloke> If that is the case, then urllib+https:// might work.
<yacc> Odd_Bloke: it's not necessary. svn+https signals that it's work for bzr-svn, and that means that it goes they => svn => Neon path.
<brandon_rhodes> Does the GTK browser have a way to do a blame, or to look at the change history of just one file?
<brandon_rhodes> A friend wants an alternative to Trac for browsing repositories, but I haven't found anything else that makes it as easy to hop between a file's history and its content and the full change history
<jelmer> "bzr gannotate"
<brandon_rhodes> jelmer: Neat!  Now once I've brought up a changeset, and it shows three files, how do I jump back "into" one of the other files?
<jelmer> brandon_rhodes: there's no way to do that yet at the moment
<brandon_rhodes> Well, drat, maybe I'll be installing Trac for him anyway :-)
<deepjoy> is http_smart_server.txt in the userguide the correct place to look for configuring a bzr+http server?
<deepjoy> it seems to refer to things that I can't find
<deepjoy> for example bzr-smart.py
<deepjoy> where  is this file?
<jelmer> there is a bzr http smart server?
<deepjoy> Hi there. if you are asking that the text file exists. yes it does in 1.2 at least.
<deepjoy> jelmer:  I didn't understand you question.
<jelmer> deepjoy: I was just surprised to hear there is something like a http smart server
<deepjoy> ok
<jelmer> ah, it's still experimental, etc
<deepjoy> yes
 * fullermd blinks.
<fullermd> There's been a http smart server as long as there's been any other smart server...
<fullermd> It's just that setting it up is apparently an exercise in mass aggravation, and it seems too inflexible to be used any way I'd particularly want to.
<deepjoy> basically authentication via ssh is a problem for most people trying this out
<deepjoy> mod_auth is much more flexible in what it talks to
<jelmer> fullermd: well, it's also still insecure
<jelmer> as opposed to the "normal" smart server
<fullermd> I don't think it's any more insecure than any other SS.
<Peng> AFAIK, that "insecure" and "experimental" comment is really out-of-date.
<Peng> And it's less of an exercise in mass aggravation since the path bug was mostly fixed.
<deepjoy> 1.2 and 1.3 had noted speed improvements in bzr+http
<Peng> Well, fixed some amount.
<Peng> Enough for it to work for me. :D
<fullermd> I still can't config it   :p
<Peng> Oh?
<Peng> What's wrong?
<deepjoy> the path bug that was 1.1 right?
<fullermd> All the hardcoded paths.
<deepjoy> Peng: so where did you get bzr-smart.py?
<Peng> deepjoy: Yuhh, http_smart_server.txt I think.
<deepjoy> ah
<deepjoy> Peng: thanks
<Peng> Also, I named it "bzr-smart.cgi", but I'm a bad person.
<fullermd> You did WHAT?!
<deepjoy> so you are using fast cgi and not mod_python
 * fullermd calls in the SWAT team.
<Peng> Yeah, FastCGI.
<Peng> I'm on shared web hosting with no mod_python.
<Peng> (Now *that's* an exercise in aggravation.)
<Peng> (I used to use regular CGI for it. It's not like my bzr+http ever gets any hits, so FastCGI would just be wasting RAM.)
<deepjoy> next question : http://trac.pocoo.org/wiki/ModPyWsgi does not exist as before
<Peng> ModPyWsgi?
<deepjoy> which project from http://dev.pocoo.org/ do I need to install?
<Peng> Not mod_wsgi?
<deepjoy> so http://code.google.com/p/modwsgi/ then?
<deepjoy> the text file in the release still says http://trac.pocoo.org/wiki/ModPyWsgi
<Peng> Yeah, ModPyWsgi seems to be a different thing, related to mod_python.
<Peng> You should check out mod_wsgi though.
<ubotu> New bug: #207959 in bzr "Assertion error after a case sensitivity clash" [Undecided,New] https://launchpad.net/bugs/207959
<deepjoy> it seems to be 2 implementations of the same thing
 * Peng shrugs.
<Peng> mod_fastcgi, mod_python, mod_wsgi... Is there a mod_scgi?
<Peng> They're all different.
 * fullermd uses mod_wtfe.
<Peng> Heh.
<Peng> Insert Lighttpd or Nginx comment?
 * Peng wanders off.
<deepjoy> Peng: could you share your bzr-smart.cgi script?
<poolie> hello
<deepjoy> poolie: Hi
<deepjoy> I'm trying to get a http+bzr server up and running
<Peng> deepjoy: http://paste.pocoo.org/show/35997/
<Peng> deepjoy: Also, in .bzr/.htaccess, I have "RewriteRule ^(.*/)?\.bzr/smart$ /bzr-smart.fcgi [L]".
 * Peng changes the regex.
<lifeless> poolie: how did your one-file-library-test-go?
<deepjoy> Peng: thanks for that. I'v got it running on mod_python with modpywsgi from http://ice.usq.edu.au/trac/browser/ice/trunk/apps/ice-server/modpywsgi.py?rev=6940
<deepjoy> now for authentication :-)
<Peng> I never tried auth.
<Peng> ssh++
<bob2> ssh lets both you and bzr punt it on to something else (pam), and that something else has had years of other people looking for bugs
<deepjoy> yup if only I could get ssh to run standalone with pam
<deepjoy> :-(
<bob2> standalone?
<bob2> or does your os not use pam?
<deepjoy> as in a chrooted sshd+pam
<deepjoy> my userbase is in ldap
<deepjoy> auth comes from there
<deepjoy> ssh refuses to talk noce to ldap
<deepjoy> /noce/nice/
<deepjoy> it wants pam
<bob2> and pam isn't working in the chroot?
<i386> lifeless: ping
<lifeless> pong
<i386> Are you coming along tonight?
<i386> Its a celebration of me getting off the hook
<lifeless> which hook ?
<poolie> lifeless: not resolved yet, i might go back to that today after clearing some todo items
<poolie> lifeless: my net connection seems very flaky recently
<deepjoy> all the tutorials for sshd in chroot talk about the sshd process being started in a chroot jail but authenticating from outside
<poolie> if i die, tell canonical i loved her :)
<deepjoy> poolie: :-)
<bob2> deepjoy: if you're using ldap, that doesn't sound too hard...just install pam-ldap and nss-ldap in the chroot..
<poolie> (in a bug) > Martin Pool's suggestion makes more sense to me, but I guess sabdfl
<poolie> knows better.
<poolie> pah!
<lifeless> which bug ?
<poolie> https://bugs.edge.launchpad.net/launchpad/+bug/84332
<ubotu> Launchpad bug 84332 in launchpad "Scope of global search field isn't clear" [Undecided,Confirmed]
<poolie> just what he is referring to there is unclear to me though
<poolie> i'm pretty sure the proposed fix will please both mark and me
<igc> morning all
<lifeless> yo
<lifeless> abentley: ping
<lifeless> spiv: ping
<poolie> (back)
<poolie> igc, spiv: call now
<spiv> https://bugs.edge.launchpad.net/bzr/+bug/207558 us the bug
<ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress]
<abentley> lifeless: pong
<spiv> lifeless: pong (also, you have mail from me)
<lifeless> hoping  to have a three-way irc chat on this duplicate code
<abentley> Sure.
<lifeless> so I can probably create a function for this
<lifeless> I really don't want to have an api folk use, with tested defined behaviour
<lifeless> the functional areas using my quite-similar code fragments are already tested
<lifeless> it can't be deprecated spiv, because these areas are not deprecated
<abentley> Well, I can see how this might be one of those halfway-private things we discussed.
<luislavena> hello guys, where I could find more about the trunk layouts used by bzr-svn?
<abentley> The big win is getting everything going through Graph, because we think that API's got legs.
<lifeless> yes; which this does though with redundant filtering to take it back to a ghost-ignorant api
<lifeless> which sucks, but I figure i have time to fix that, or get stacking working, but not both
<lifeless> SO
<lifeless> I can create an untested helper function somewhere like repository.py
<lifeless> plastered with 'do not use' stickers
<spiv> So, my concerns about code that is temporarily duplicated and a bit ugly are: "temporary" has a habit of being less temporary than we expect; people will look at this code and copy-and-paste it as if it is the best way to do things; if something does need changing at one site (e.g. adding ghost filtering where currently there is none, or a bug) then duplication makes it unlikely that code gets re-used, wasting effort.
<spiv> An untested helper function plastered with 'do not use' stickers deals adequately with all those concerns.
<lifeless> ok
<lifeless> abentley: makes you happy?
<abentley> Yes, that's okay with me.
<lifeless> ok, I'll do that. I've sent a couple of subsequent patches
<lifeless> easiest for me would be to make this change and merge the whole lot.
<lifeless> do I have a victim^Wvolunteer to review them ?
<james_w> luislavena: hi, I don't quite understand what you mean, could you explain please?
<spiv> lifeless: I can take a look at that, but I want to fix 207558 first, so it might be much later today.
<bob2> jelmer: is bzr-svndev's README still correct wrt gutsy's p-subversion being recent enough (I have it installed, but bzr-svn claims it is not)
<bob2> luislavena: 'bzr help svn-branching-schemes', I think
<lifeless> bug 207558
<ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
<lifeless> spiv: if you think it will be after 2pm, say so now, other wise deal ( except I will keep churning out patches, so the size may be >> when you get to it)
<luislavena> bob2: too vague reference, but thank you.
<luislavena> bob2: I'm dealing with a repo that uses a automated tool to manage merges between branches.
<spiv> lifeless: I think there's a good chance it'll be after 2pm.
<bob2> luislavena: too vague?
<lifeless> ok
<lifeless> igc: poolie: desperately seeking reviewer
<igc> lifeless: which patch
<luislavena> bob2: yep, that don't explain trunk0, trunk1, or which other schemes and how they match to your repo...
<igc> I'm happy to help
<lifeless> http://bundlebuggy.aaronbentley.com/?selected=mine -> 500 error
<lifeless> AttributeError: ("'NoneType' object has no attribute 'submitters'", <bound method Root.index of <bundlebuggy.controllers.Root object at 0x8e4f94c>>)
<abentley> Ooh.
<lifeless> I think my session had timed out
<igc> lifeless: an email title will do me
<abentley> lifeless: confirmed-- it happens when I'm logged out and access that URL.
<lifeless> http://bundlebuggy.aaronbentley.com/request/%3C1206593719.7512.459.camel@lifeless-64%3E
<lifeless> http://bundlebuggy.aaronbentley.com/request/%3C1206591531.7512.456.camel@lifeless-64%3E
<luislavena> bob2: example, I don't know if bzr-svn will take the following as a branch:
<igc> lifeless: ok
<luislavena> svn://host/repository/project/branches/exp/enhanced-img-processor
<bob2> luislavena: ok
<lifeless> hmm, switch-relative failed to land in london
<lifeless> thank you bb
<bob2> luislavena: note that you can use 'bzr branch' without caring about branching layouts
<bob2> luislavena: hope that automated tool is compatible with svk
<luislavena> bob2: I was worried of pushing the changes back to the repo :-)
<luislavena> bob2: no, no svk, just svn.
<lifeless> spiv: for http://, I think the default in bzr.dev should be to try for smart server facilities
<bob2> luislavena: afaik if you just branch/push/pull, you don't need to worry about branching layouts
<luislavena> bob2: it create tags between up and down operations between branches and trunk to keep reference when merging back
<lifeless> spiv: but if we know of places that this doesn't degrade well, we could have some means to explicitly disable it in the client
<spiv> lifeless: "nobzr+http:" ;)
<luislavena> bob2: thank you :-)
<lifeless> spiv: http-bzr:// ?
<abentley> lifeless: btw, BB now uses launchpad for bug tracking.
<spiv> Heh.
<fullermd> http&~bzr://
<spiv> I don't like how it will degrade, though.  You get unfortunate errors along the lines of "No branch at http://..."
<spiv> Which won't hint to the user what's going on.
<lifeless> spiv: can we tell what servers are fixed?
<spiv> lifeless: not without a protocol bump, I think
<lifeless> so this problem won't go away ever, potentially :>
<spiv> Co-incidentally, we have one of those coming up fairly soon ;)
<lifeless> Does lp's http server run the smart server?
<spiv> lifeless: yes, hence "bzr branch http://bazaar.launchpad.net/~bzr/bzr/trunk" is currently broken if you have bzr.dev on the client.
<lifeless> so
<spiv> (which is bug 207558)
<ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558
<lifeless> I propose: disable that on launchpad
<lifeless> because elmo will probably have a hernia about memory use; and it will be slower than http with packs :>
<spiv> lifeless: (incidentally, bzr+ssh beats plain http for pulling the last three weeks of bzr.dev, 52s vs. 1m 21s IIRC)
<lifeless> and for other servers; can we not recommend that they upgrade / :>
<lifeless> spiv: ok, thats good to know
<lifeless> I think initial pull is still slower though
<abentley> Huh.  I would have thought bzr+ssh would tend to win on large amounts of data.  On small amounts, SSH connection time has a notable impact.
<spiv> abentley: I was pleasantly surprised, I must admit.  I assume the graph RPC stuff is beating the index-bisection-over-HTTP.  Or maybe my intercepting squid proxy is influencing the HTTP results...
<lifeless> spiv: incidentally, I suspect packing bzr.dev would reverse the figures
<lifeless> spiv: oh yeah, you see hno's comments on the http bug ?
<spiv> lifeless: no?
<lifeless> spiv: turn of the ******g evil interception and I suspect it will be a lot faster
<spiv> Oh, right :)
<lifeless> spiv: you're triggering squids pre-load the whole file behaviour
<lifeless> which is a bug in your version of squid
<spiv> lifeless: yeah, I remember that bug now.
<spiv> lifeless: we just need to hack our range requests ;)
<spiv> lifeless: so, I'm uncomfortable with introducing a regression, even if buggy servers are technically the cause.
<spiv> I don't think keeping the status quo (you need to explicitly use bzr+http to use smart http) for one more release is bad idea.
<jdong> hey folks, I've filed a FFe for bzr 1.3 at bug 208039
<ubotu> Launchpad bug 208039 in bzrtools "Feature Freeze Exception: bzr 1.3" [Undecided,New] https://launchpad.net/bugs/208039
<jdong> let me know if I've missed a package
<lifeless> spiv: ok, though it seems a shame
<lifeless> spiv: because, for broken servers, bzr+http is already not working
<spiv> lifeless: right, but http *is*.
<lifeless> what I mean is that its unlikely the operator is ignorant of the fact
<lifeless> they will, like AfC, have either setup bzr+http so it works, or tried and failed and left it not working
<lifeless> release notes that say 'bzr+http is no longer needed unless you want to disable plain http use' are IMO going to be enough for those admins
<spiv> Well, I guess there is a general issue here, which is that bzr+http can be misconfigured, even if we have all our bugfixes in place.
<spiv> But reporting a "sorry, no branch here" error in that case as if it were plain HTTP is needlessly confusing.
<lifeless> spiv: we don't seem to have any answer to that though
<lifeless> spiv: I don't see how waiting a release makes it better
<lifeless> i386: what hook
<spiv> I think we probably need an answer to that problem, because it'll be useful for admins if users know which method is actually involved when things fail.
<markh> ramdon question: if launchpad shows me a date as '05/01/2007', is it US or european?
<spiv> Perhaps just a message along the lines of "Detected smart server" if the probe over HTTP succeeds.
<markh> roger ramdom :)
<lifeless> markh: if you are not logged in , its UTC
<lifeless> markh: if you are logged in, its as per your TZ config for launchpad
<markh> but is it d/m/y or m/d/y?
<lifeless> markh: oh, its always sane.
<lifeless> :>
<markh> heh - cool :)
<lifeless> spiv: so, I think that if we need an answer to this diagnostic problem anyhow, that effort during 1.4 dev should be on that answer, not on disabling and renabling autodetection.
<lifeless> spiv: there is every chance that by the time we release 1.4 all users will have fixed their servers anyway :)
#bzr 2008-03-28
<poolie> lifeless: can tribunal already handle subunit?
 * poolie just branches lp:tribunal
<lifeless> tribunal runs a python test suite
<lifeless> if that uses a SubProcessTestSuite, its transparent to tribunal
<lifeless> igc: how are those reviews going
<igc> starting now
<igc> (been reading the threads with abentley's and spiv's comments)
<lifeless> the one I pointed you at is much simpler
<lifeless> *ones*
<ubotu> New bug: #208039 in bzrtools (main) "Feature Freeze Exception: bzr 1.3" [Undecided,New] https://launchpad.net/bugs/208039
<poolie> markh: that document is pretty interesting
<markh> poolie: thanks!
 * poolie avoids getting sucked into reading the whole Old new thing
<markh> heh - its a very intersting blog for windows developers
<markh> I'm going to dig deeper into the tsvn cache etc
<markh> and decided to get sidetracked by pulling their svn tree via bzr ;)
 * beuno pokes poolie and lifeless about the debconf bzr talk deadline
<poolie> beuno: hi
<poolie> thanks
<beuno> hey poolie  :)
<poolie> so what did we work out about that? that lifeless would propose a talk and james_w might go too, iirc?
<beuno> yeap, he was willing to go
<beuno> and jelmer and LarstiQ are interested in going too, they where going to apply for sponsorship by debian
<beuno> and with me and Verterok, we might be a pretty big bzr possy
<beuno> might even be worth organizing a sprint  :)
<beuno> oh, and dato might come too, right dato?
<jelmer> 'evening markh
<jelmer> markh: great to see you taking on TortoiseBzr !
<markh> hi jelmer - thanks!
<markh> key to its success will be these "external apps" which we call to do the grunt work.  I haven't really looked at them yet
<markh> I don't have pygtk locally
<markh> but the cool thing is we can fix them later, and independently of the shell itself
<jelmer> I think it would make sense to call out to qbzr from tortoisebzr rather than bzr-gtk
<jelmer> qbzr is easier to install than bzr-gtk and looks more native on windows
<markh> there is an existing impl for a couple of "commands" in the tbzr tree
<markh> I *think* they are gtk, but I've really only noticed they exist, not what they do :)
<jelmer> yeah, that's all gtk
<markh> so I'm up for nuking them, or whatever everyone agrees
<beuno> jelmer, hey  :)    I haven't had _any_ free time at all these past weeks, but I do have a few hours now. Is the bzr-gtk release missing anything other than the disable-through-nautilus bit?
<jelmer> we initially created tortoisebzr as a fork of bzr-gtk
<markh> but no1 focus should be the shell IMO
<jelmer> beuno: yep, that's the only bit missing
<jelmer> beuno: hi :-)
<lifeless> right, I need a topic I think
<jelmer> lifeless: "sock puppets" ?
<markh> how about xul? ;)
 * markh ducks
<beuno> jelmer, alright, I'm on it. I'll try and get that done tonight
<jelmer> beuno: that'd be awesome
<beuno> xul!  that would be interesting!
<poolie> beuno: if those people don't get sponsorship from debian talk to me
<poolie> markh: i don't have any particular comments, but it looks like a good start
<jelmer> markh: I think nuking them wouldn't be a problem - they're also in bzr-gtk anyway
<abentley> lifeless: your deprecation of get_graph_with_ghosts appears to also affect get_graph
<poolie> markh: i guess i would be inclined not to have a separate cache process other than the xmlrpc server, at least at first, just to reduce the number of moving parts
<luislavena> jelmer: hello.
<jelmer> luislavena: hi
<poolie> also, maybe you could expand in a future post on what kind of debug/trace _is_ needed?
<beuno> poolie, sure, I'll follow it closely. jelmer, LarstiQ, keep your agendas open got august  ;)
<luislavena> jelmer: is there a way I can branch/svn-cache 16K svn revisions without hit the memory error?
<luislavena> :-D
<jelmer> beuno: will do, thanks :-)
<markh> poolie: it we move to pure C++ for the shell, I'm a little concerned the xmlrpc requirement will complicate what should be fairly simple
<jelmer> luislavena: use a version of python-subversion with the memory leaks fixed
<markh> and slower and less secure if implemented via sockets on windows :)
<poolie> hm
<poolie> what would be better?
<lifeless> abentley: thats 'index.get_graph' which is on a private attribute of knits - knit._index.get_graph.
<poolie> i guess you could make a dcom server in python?
<luislavena> luislavena: mmm, that will need me to swtich to ubuntu and put that on a pendrive :-D
<jelmer> luislavena: or you can use "bzr init dir"; bzr pull -r1000; bzr pull -r2000; bzr pull -r3000.. etc
<poolie> would that be easier to talk to?
<beuno> markh, you'd also be able to get XML straigh out of bzr, just like with the current xmloutput plugin
<markh> the cache process is likely to need to create a hidden window to receive shell notifications from explorer when a user deletes files, for example, and maybe register for asynch NT filechange notifications to even handle the command-line changing the file-system
<luislavena> jelmer: pull directly instead of branch?
<jelmer> luislavena: yes, pull 1000 revisions each time
<poolie> markh, i guess i don't understand what you mean by "the xmlrpc requirement will complicate what should be
<poolie>               fairly simple"
<markh> poolie: dcom might work, yeah - but a few simple commands over a named pipe is really quite trivial
<luislavena> jelmer: great, thank you for the pointer.
<abentley> lifeless: acceptable breakage.
<markh> xmlrpc imples a few C++ libraries I'm not familiar with
<jelmer> DCE/RPC \o/
<markh> and we want this as thin as possible, as it gets dragged into many processes
<poolie> markh: another option is to talk the bzr network protocol
<poolie> the encoding for it would be pretty trivial to write in c++
<poolie> some of the commands you need may not exist
<poolie> this will possibly be smaller or simpler than xmlrpc
<poolie> probably more new code though
<igc> lifeless: looks like abentley and I just reviewed that patch for you. One was approve and the other was resubmit (though my review was borderline tweak)
<markh> Would all the gui apps be written to use this xmlrpc server?
<beuno> markh, that's the plan, GUI and IDEs
<abentley> lifeless: please to be running the test suite before submitting your patch.
<bob2> snap
<markh> But isn't it more moving parts for a GUI app that has direct access to bzrlib?  I do see the benfit for IDEs etc, but not so much for gui apps that are "part of" bzr
<markh> but thats fine :)
<markh> I don't need to be convinced ;)
<poolie> i didn't think guis would but i might be out of date
<beuno> markh, well, if you can access python directly, then it makes sense, yes
<beuno> IIRC, there where some use cases for GUIs that couldn't interact with python
<markh> so - that would make the shell code the only known consumer of this server on windows today.  Its not written yet, it adds complexity and offers a much richer API than we actually need :)
<markh> hence I'm still on the "simple" side of the fence :)
<lifeless> abentley: igc: both of you reviewed the superseded, broken, version of it
<lifeless> abentley: I do run the test suite usually :)
<abentley> Should BB have noticed that it was superseded?
<beuno> markh, after a whole sprint of "windows support is extremely important", and nobody willing to do anything about it, I guess you should go down whatever path you want, and we can just help  :)
<markh> I'm obviously happy to go with whatever is decided - but in the meantime I must take off to the shops for lunch.  bb in an hour.  thanks for the info about the server thinking!
<markh> beuno: thx - its still obviously open for discussion!
<abentley> I'm pretty sure BB didn't notice that it was superseded, because I voted using BB.
<lifeless> oh hmm
<igc> lifeless: sorry about that. I don't seem to have a more recent one in my email though and BB didn't list another with a similar name?
<lifeless> hmm
<lifeless> oh, *I* was confused
<LaserJock> is there an advantage to having a shared repo on a bzr server other than saving space?
<beuno> LaserJock, nope, and that just applies if the branches have common revisions
<beuno> jelmer, we agreed on setting the nautilus disable flag in "~/.bazaar/bazaar.conf", right?
<fullermd> Well,  You save a lot of traffic...
<abentley> LaserJock: Yes, it also saves time.
<LaserJock> I guess my question is, is there a difference if the user creates a shared repo or if it's already a shared repo on the server?
<LaserJock> not sure if I was clear the first time
<lifeless> LaserJock: no different really; but lp doesn't support or use shared repos's. if thats what you were thinking :>
<beuno> LaserJock, my attempts to use shared repos for _many_ unrelated branches led to some weird results
<LaserJock> lifeless: yeah it was
<LaserJock> lifeless: does LP support rich-root-pack ?
<lifeless> yes
<beuno> LaserJock, LP has the latest version of bzr, so whatever you push to it will work
<LaserJock> so just getting some LP bzr admin type to convert our dirstate-with-subtree branches to rich-root-pack should speed things up and allow us to make shared repos, correct?
<LaserJock> that's my bottom line I guess :-)
<beuno> LaserJock, you shouldn't need an admin if you have access to the branch
<beuno> you can just "upgrade --format="
<LaserJock> heh
<LaserJock> but I can't really push it back up
<LaserJock> if it takes pushing the whole branch
<beuno> LaserJock, no, you can do bzr upgrade --format bzr+ssh://laserjock@baza....
<lifeless> well
<RAOF> beuno: But upgrade doesn't work over bzr+ssh, right?
<lifeless> you can't beuno
<beuno> oh?  sftp then?
<RAOF> That works, or should.
<beuno> LaserJock, right, sftp instead of bzr+ssh
<LaserJock> so would the LP server then do the conversion?
<beuno> yeap
 * LaserJock struggles to wrap his brain around this stuff
<RAOF> Well, no.  Your local bzr client does the conversion over sftp.
<RAOF> So this can be _sloooooooow_.
<LaserJock> so when I did it locally it took 40 min
<beuno> of course, I'm not sure what wil happen when pushing/pulling from other local formats. You'd probably want to upgrade all current branches
<LaserJock> when we first pushed this branch it took about 5 days
<LaserJock> so roughly how long do you think it'd take?
<beuno> LaserJock, I'd say run it and go to sleep  :)
<LaserJock> I'd have to do it for 4 branches
<LaserJock> and I only have 2 locally
<beuno> LaserJock, many times it's faster to re-branch
<LaserJock> what do you mean by re-branch?
<beuno> upgrade in LP, and re-branch to your box
<LaserJock> ah
<beuno> much cheaper in big repos
<LaserJock> if we could get that done before Intrepid get's really going I think it'd be a big advantage for new contributors
<lifeless> beuno: upgrade over sftp copies all the data twice
<lifeless> beuno: over the wire
<beuno> LaserJock, if it's that big of a deal, then it might be faster to get a LP admin to do it. Maybe abentley?
<beuno> lifeless, ah, so it should be cheaper to upgrade locally and fully re-upload?
<LaserJock> beuno: yeah, I just sent an email to the team to start a discussion about shared repos and getting the format upgraded
<LaserJock> we'll see how it goes, but I'm sure everybody will like the improvement
<LaserJock> how old of a bzr version will handle rich-root-pack? 1.0 ?
<beuno> LaserJock, I think from 0.92
<beuno> or 0.91 even
<beuno> so 1.0 should be a safe bet
<LaserJock> k, just wondered about gutsy users
<abentley> They were introduced in 1.0, according to NEWS.
<beuno> abentley, wasn't it introduced with packs itself?
<lifeless> no
 * beuno is awfully wrong today
 * beuno alt+tabs into vim
<jdong> beuno: at least that's one thing right.
<beuno> jdong, :p
<LaserJock> jdong: I thought it was just typo ;-)
<LaserJock> *just a
<beuno> igc, btw, thanks for redirecting all the IDE people to be, I've got a pretty good list of people working on stuff. I'll put up a wiki page with it soon
<igc> beuno: excellent. I almost did exactly that yesterday but didn't get to it
<igc> I want a page called EditorsAndIDEs (say) that lists all of them together with software and/or contact points
<beuno> exactly what I had in mind  :)
<igc> we can also use that to direct people to the team you've set up
<beuno> igc, yeap, sounds great. Seems the news from the sprint got many people excited about it
<lifeless> igc: there were two patches ...
<igc> lifeless: didn't abentley approve the seocnd one?
<lifeless> *blush*
<lifeless> ok
 * igc lunch & doctor visit
<lifeless> abentley: cool patch; I don't think I'll get to review it myself today
<lifeless> abentley: but it sounds excellent (though I'm not 100% sure about validating against different formats automagically)
<lifeless> abentley: spiv: duplication reduction ping
<abentley> lifeless: Well, that's only on conversion.  And it's only if the obvious choice fails.
<lifeless> so, I've reduced about half of the duplicate sites to use helpers; the rest are not actually all the same
<lifeless> the knit and versionedfile ones don't filter nulls and so on
<abentley> Otherwise, I would have to fail to convert.
<lifeless> well, my thoughts were that if its wrong, its wrong and failure is expected.
<lifeless> I'll sleep on it
<abentley> So that means that if we convert something from format 5 into 6, we can't convert it to 8
<abentley> And similarly for 7 -> 5
<abentley> sorry, 7->6
<lifeless> the way I looked at it, reading the old inventory will fail
<lifeless> so this is a job for reconcile, which is allowed to be slower and more complex than just pull
<spiv> lifeless: yeah, in the patch I saw I think there were two variants.
<lifeless> spiv: do you want to see the new diff; I think its about as reduced as I'm comfortable with
<lifeless> or an incremental diff?
<lifeless> or <alternate>
<abentley> lifeless: But then you're generating format 5 serializations with differing inventory_sha1s for the same revision.
<spiv> lifeless: an incremental diff would do
<lifeless> abentley: huh? whatever rich-root is today - yes. And it can happy today trivially.
<lifeless> abentley: all you have to do to get different inventory sha 1s today is to do a bzr baz-import into a rich root repo, and also a bzr baz-import into a pack-0.92 which you then upgrade.
<abentley> The 5, 6 and 7 serializers all use format 5 for their serialization.
<abentley> of revisions.
<lifeless> and ditto with bzr-hg/hg-import etc - all the deterministic importers will create this
<lifeless> spiv: mailed you
<spiv> lifeless: ta
<abentley> lifeless: That's just them not being completely deterministic.
<beuno> jelmer, sent the patch  :)  I suppose I have to add the stuff I ahve done up to now in NEWS, but I'll wait until it gets approved to send that in
<lifeless> abentley: they would have to generate a format 5 inventory, grab its sha, and then reserialise to format 7 inventory
<lifeless> abentley: I think they are being completely deterministic; its *our* bug on upgrade that makes any problems exist; which is what your patch is about fixing.
<abentley> They're not deterministic.  They don't force the root revision_id to always be updated, AFAIK
<abentley> which is the non-rich-root behavior.
<lifeless> abentley: mmm, possibly;
<abentley> i.e. what you'd get if you converted something from baz into knit, then rich-root.
<spiv> lifeless: +1
<lifeless> thanks
<beuno> poolie, if you want some help with bzr packaging for ubuntu, just upload the current branches to LP and I'll pitch in to get 1.3 into PPA
<lifeless> beuno: I need a topic suggestion; looms would be ideal but they aren't really polished yet :(
<beuno> lifeless, how about generically going for "managing your packages with bzr"?
<beuno> and then see how polished they are by august  :)
<markh> is there a simple way to have bzr show the traceback when it can't load a plugin?
<spiv> markh: the traceback is written to the .bzr.log
<markh> ah - thanks!
<spiv> markh: it might be good if there were a -Dplugin debug flag, perhaps.
<poolie> markh: i would think -Derror should do that but i guess it does not?
<markh> heh - the log is in "my documents" :)
<markh> so - .bzr.log is misplaced IMO on windows.  What is the best place to discuss that?  Open a launchpad bug or just email the list?  The patch is trivial, but agreement on the correct place might not be ;)
<lifeless> markh: see the archive first please
<lifeless> markh: its not accidental where it is :>
<markh> bugger - so it is to help the user find the log?
<lifeless> it may be that there is a better place
<lifeless> bzr --version shows where the log is going
<lifeless> so please google a bit, and if you decide that it should be moved:- send a [MERGE] in  :)
<markh> well - making it easy to explain to a user where to find the log is very true and I don't want to start a bikeshed discussion - but I think its safe to say I'm very glad that no other apps take the approach of dumping their logs where I store my documents ;)
<lifeless> markh: which is why I am acking that there may be a better place; but asking you to check the history a bit first, and rather than openning a bikeshed discussion, send in a patch that does the right thing
<markh> fair enough - tho me even bringing it up is kinda bikeshedding :)
<lifeless> I don't think its bikeshedding to say 'here is a way to do things better'. bikeshedding is arguing about trivialities.
<spiv> "I want my shed to be pink, and called 'My Documents'" ;)
<markh> I did assume the location was "accidental" - but given it was explicitly decided, the location of the log file is almost a triviality at this stage of the game - much bigger fish to fry!
<markh> eg, how we bend py2exe to allow plugins to work OK in binary releases.  For now I'll just switch to a source version of bzr instead though...
<lifeless> tchau
<poolie> bye lifeless
<AfC> Is jam up? Guess not.
<poolie> AfC: he's on holidays for the next week and a bit
<AfC> poolie: ah! Nice. Thanks
<poolie> i've forwarded your expenses
<poolie> btw
<AfC> poolie: thanks
<AfC> !
<AfC> poolie: So it's probably a rear guard action at this point,
<AfC> but I'm trying to [automate] set up [of] bzr-svn branches for GNOME projects for people to use.
<AfC> I'm happy to publish a selection of the resultant branches on our R&D server, but
<AfC> I was wondering if the launchpad guys are {likely, in progress} doing that themselves
<poolie> i'd like them to move to doing it through bzr-svn rather than cscvs
<AfC> (versus bzr-vcs-import, which is unfortunately no good for projects that are not migrating but still using Subversion as their main)
<poolie> for a few reasons including the result being more useful, ... well you can imagine
<poolie> but that is not on their plate at present
<poolie> um
<poolie> i have heard there is interest in having those imports though
<AfC> poolie: ok. Just thought I'd ask before writing a bunch of scripts and kicking them off.
<poolie> sure
<poolie> can you mail the list when you do it?
<poolie> i'd like to at least mirror them to launchpad
<AfC> poolie: yeah, I sorta heard that murmour in the back of the room in London; I also now understand some of the things the Launchpad team are up against.
<poolie> :)
<AfC> poolie: yeah, for sure.
<poolie> we had an interesting thread about downtime recently
<poolie> it's actually above 99% but whether that's good or not depends on your point of view
<poolie> anyhow i should finish rebuilds
<AfC> Not bzr-svn's fault, but I had to do the 100 revisions at a time trick to try and do the 19,000 revision repo. I didn't have a server handy with the patched Subversion, and the machine I was on (ie, my laptop) was in an environment that was VERY intermittent.
<AfC> It took 9 days to do the import.
<AfC> Needless to say, I'm not going to tell anyone else that :)
<poolie> well
<poolie> this is one reason it would be good to get it running on proper infrastructure
<AfC> poolie: [99%.... for most people, that's pretty good. The one I usually look for is planned vs unplanned]
<spiv> AfC: jelmer says bzr-svn 0.4.9 is much faster, btw
<AfC> spiv: I was just going to grab it... I know it has the changes that you and he made a couple weeks back
<spiv> AfC: so if the dependencies aren't too horrible, it'd be worth trying the upgrade
<AfC> spiv: should be ok... I just had to jump through lots of stupid hoops to get Subversion to co-operate.
<AfC> Anyway, it's on my list of things to contribute in April.
<igc> night all - have a good weekend
<james_w> thanks jdong
<poolie> hi james_w
<james_w> hi poolie
<james_w> how are you?
<poolie> very good
<poolie> i should sign off though...
<james_w> have a good weekend
<Lo-lan-do> G'day all
<james_w> Hi Lo-lan-do
<Lo-lan-do> I'm reading about the new dpkg source formats, including one called "3.0 (bzr)".
<Lo-lan-do> (Basically, replace orig.tar.gz+diff.gz with a single tarball containing a bzr branch)
<Lo-lan-do> That sounds interesting to me, but converting my main package (gforge) to it would make the source package grow from ~10MB to ~60MB, because of the full history included.
<Lo-lan-do> So I was wondering whether the history horizon/shallow branches feature is still being worked on...
<Kamping_Kaiser> i expect any package will have that problem too :|
<Lo-lan-do> Not every package has thousands of revisions, but yeah.
<Lo-lan-do> It would be nice to be able to only keep like the last year of revisions.
<poolie> some preparatory work is happening but it is still over the horizon
<Lo-lan-do> I see.
<poolie> um
<poolie> but you can use lightweight checkouts in many places, i presume
<poolie> and then they will not be so large
<poolie> anyhow, really going now
<Lo-lan-do> I know about lightweight checkouts, but that's not the use case I'm talking about.
<james_w> poolie: nice pun :-)
<dato> heh, so I wasn't the only one =)
<james_w> hi dato
<dato> hello james_w
<james_w> Lo-lan-do: I haven't looked in to those formats to understand them yet.
<Lo-lan-do> james_w: They sound promising to me, but I won't switch quite yet, because of the size problem.
<james_w> yeah, I think that's reasonable.
<james_w> it seems to me like they may be more of a stepping stone to get to a proper VCS based workflow
<chadmiller> Moin moin.
<yacc> Just making sure, when I work with a remote repo, I do a "bzr commit" and after that a "bzr push", right?
<yacc> So that my changes get immediatly applied to the remote repository?
<Lo-lan-do> Yes, unless you're in a checkout (bound branch)
<luks> by repo you mean a branch created by 'bzr branch'?
<yacc> luks: not hundred percent. By repo I mean a svn+https:// url that I have created via bzr svn-push.
<yacc> andreas@andi-lap:~/lookery/lookery_memberfind> bzr merge svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process/trunk/logs/lookery-memberfind
<yacc> bzr: ERROR: Repository KnitPackRepository('file:///home/andreas/lookery/lookery_memberfind/.bzr/repository/') is not compatible with repository SvnRepository('svn+https://lookery_andreas@lookery.unfuddle.com/svn/lookery_process')
<luks> oh, no idea about bzr-svn
<yacc> Isn't that peachy?
<luks> this looks like a incompatible shared repository format
<james_w> yacc: you created ~/lookery/lookery_memberfind with bzr-svn?
<luks> and I think it's explained in bzr-svn's FAQ
<yacc> No, lookery/lookery_memberfind was the initial directory where the project started, so it was created by bzr init.
<bob2> the project originated in bzr, then was branched to svn?
<yacc> bob2: yeah.
<bob2> the bzr branch has to have a compatible repository format
<yacc> Yeah, but upgrade --rich-root-pack breaks too.
<bob2> 'bzr upgrade --rich-root-pack' (ideally after making a backupof it)
<bob2> ah, suck
<yacc> bob2: well, I did already svn-push from this directory.
<bob2> the push will be fine
<bob2> pull/merge won't, tho
<bob2> some missing revision error from bzr upgrade?
<james_w> yacc: what's the error on upgrade?
<yacc> Yeah, but it complains about diverged branches and asks me to merge. Which is curious, as there have been no commits to the directory in the mean time.
<yacc> bob2: it complains that some version does not exist in the repo.
<yacc> james_w: bzr: ERROR: Revision {('andreas@andi-lap-20080318163204-v6cbndpdo3k2hneq',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb6c53b2c>".
<james_w> suck
<james_w> yeah, I don't know if there is a workaround for that problem yet, sorry
<bob2> what about 'bzr missing' - does it show revisions missing on both sides?
<james_w> abentley: hi, are you around?
<yacc> james_w: yeah, I'm getting this sick feeling that despite jelmer's efforts bzr-svn is not a viable svn client solution ;(
<bob2> 'bzr reconcile' might 'fix' it for now
<yacc> bob2: I already run reconcile
<abentley> james_w: hi
<james_w> abentley: hi, is there a workaround known for yacc's error above?
<bob2> yacc: the issue is with the conversion, as far as I know - if you'd started with rich-root-pack (or branched from svn), pretty sure it would be fine
<yacc> That's curious, branching the svn repo freshly, commit the single again, and pushing it worked fine.
<yacc> bob2: yeah, I have a feeling that the "start a svn repo with bzr" is not exactly a typical usecase.
<james_w> yeah, you get the right local repository format that way, the problem is with the upgrade
<bob2> yacc: maybe branching the original bzr branch into a rich-root-pack repo would work, too
<abentley> What was the original format?  dirstate-tags?
<yacc> bob2: well, I'll try to start my new egg with svn mkdir && bzr branch for a change.
<yacc> abentley: the format before was pack-0.92.
<bob2> abentley: KnitPackRepository
<yacc> abentley: But svn-pushing worked before, ...
<james_w> yacc: yeah, it's not the typical use case.
<bob2> yacc: pushing wiwll work, it's the pulling of data from svn that is the issue, afaik
<abentley> yacc: You were using bzr-svn 0.3?
<yacc> abentley: nope :)
<yacc> bob2: yeah, but it complained about diverging branches, so pulling was needed too.
<yacc> bob2: despite that nobody has commited anything to the directory on svn.
<bob2> yacc: does 'bzr missing' explain that?
<abentley> yacc: AIUI, bzr-svn 0.4 requires a rich-root format.  So I don't know how you got that.
<yacc> bob2: nope, I already managed to push it via a fresh branch.
<yacc> abentley: which makes me wonder how the revisions in lookery-memberfind ended up in the svn repo in the first case?
<yacc> Ok, I've got an idea what can be out of whack.
<yacc> bzr missing complains that I'm missing the initial revision the directory is based on, that I did via "svn mkdir" if I remember right.
<abentley> yacc: Could you run this in the root of your branch please?
<abentley> python -c "from bzrlib import workingtree; wt = workingtree.WorkingTree.open('.'); wt.lock_read(); print wt.inventory.root; wt.unlock()"
<yacc> abentley: nope, the branch had a portion of tender-love-care from rm -Rf ;(
<abentley> yacc: So you didn't originate this bzr-svn conversion?
<yacc> I did orginate yet again, but I solved it by branching the svn url freshly, applying my change and pushing it. Everything worked fine then.
<james_w> yacc: did you just start with bzr init, made some commits, and then did bzr svn-push?
<yacc> james_w: yes.
<abentley> Alright, I guess there's nothing for me to see here.
<james_w> thanks abentley
<abentley> james_w: To somewhat answer your question, there are two fixable causes of that error.
<abentley> One is the sort of data inconsistencies that reconcile will fix, so that's fixable.
<yacc> And the second one?
<abentley> The other is that the non-rich -> rich converter assumes non-rich trees have TREE_ROOT as their tree root.  That hasn't been addressed yet, but I'm planning to do it as part of my pack-1.4 work.
<schierbeck> hey guys -- any news on nested branches?
<james_w> abentley: great, thanks.
<james_w> schierbeck: I think LarstiQ had almost all tests passing in London, so hopefully we will get the first bits to review at some point.
<schierbeck> awesome!
<deepjoy> bzr+http woohoo!!!
<deepjoy> finally got the basics running
<deepjoy> not if only I could figure out how to use the update the working tree remotely or an alternate work flow that will server multiple developers
<deepjoy> I have bzr+http with write enabled working with mod_authz_ldap
<deepjoy> anybody here to share my joy :-)
<dato> "yay!"
<Lo-lan-do> Yaaay.
<deepjoy> dato: Lo-lan-do: thanks
<chadmiller> Hi all.  I'm trying to push a Very Large pack-0.92 branch (total repo is ~500MB) to Launchpad using very recent bzr.dev over bzr+ssh.
<bob2> deepjoy: you should document that somewhere :)
<chadmiller> By my calculation, if it were just streaming data, it would take ~30 minutes over my 'net connection.
<chadmiller> But, I stopped it yesterday at 8 hours, with the progress bar about 2/5ths the way across the screen.
<Lo-lan-do> chadmiller: You might try packing it first
<Lo-lan-do> (But I don't know what I'm talking about, so ignore me if I'm just giving nonsense)
<chadmiller> It is packed.
<bob2> was it still sending data when it stopped (according to iptraf or tcpdump or whatever)
<chadmiller> bob2: Yes.
<chadmiller> The trees are public, if anyone wants to try.
<chadmiller> https://code.edge.launchpad.net/~mysql-developers/
<chadmiller> branch from 6.0-trunk, push back.
<Lo-lan-do> chadmiller: Are you trying to push over a DSL line?
<chadmiller> Lo-lan-do: No.  Cable.
<Lo-lan-do> Large latency?
<chadmiller> No, not usually.  Very good, most of the time.
<Lo-lan-do> If so, you may want to rsync over to a good server, and push from there
<luks> pushing over sftp will be probably faster than over bzr+ssh if it's just one big pack file
<chadmiller> Lo-lan-do: I can scp the whole repo in ~30 minutes.
<Lo-lan-do> chadmiller: Hence the idea to push over bzr+ssh from a place where network roundtrips don't matter much
<chadmiller> Lo-lan-do: That's not it, sorry.
<Lo-lan-do> Then I'm happy to be ignored :-)
<chadmiller> While I've been patient about other uses of bazaar, I'm trying to decide whether or not to use bazaar (and launchpad) for my Google-Summer-of-Code students.
<james_w> chadmiller: the ~/.bzr.log from the push may give some clues
<james_w> chadmiller: for future reference -Dhpss can help debugging this
<chadmiller> james_w: The .bzr.log has the startup info, and then at t+33 "Using fetch logic to copy..." and is then silent.
<james_w> chadmiller: that's not much use then.
<james_w> shame
<chadmiller> james_w: I left it running last night with -Dhpss, and (I suppose) it bogged down enough that the ssh socket timed out.
<chadmiller> Oh, wait, that was -Devil.
 * chadmiller uses hpss.
<james_w> -Devil isn't that useful as it doesn't really change depending on your specific circumstances
<chadmiller> (Yeah.  After the 8-hour wait, I wanted to see if there was anything obviously algorithmic in the way.)
<asabil> when having a conflicts
<asabil> is there a way to tell resolve to auto pick the .THIS ?
<asabil> overriding the changed from .OTHER ?
<james_w> I don't think so
<asabil> oki thanks
<fullermd> cp ; resolve
<fullermd> Or revert, I s'pose.
<asabil> fullermd: yes, but when you have a bunch of files
<asabil> you need to end up using find
<Lo-lan-do> Not necessarily.
<fullermd> Nah, you could use perl instead   ;)
<Lo-lan-do> How about "bzr conflicts --text | xargs bzr revert"?
<james_w> that should work
<asabil> hmmm right, forgot aboy xargs
<asabil> about*
<asabil> thanks
<fullermd> Though it does lead one to think that bzr really needs a -0 option...
<fullermd> Got it on ls, but not on conflicts.
<Lo-lan-do> Also, this will entirely drop the parts of the patches that are not conflicting.
<luislavena> hello guys, question for any using bzr-svn...
<luislavena> even I created a branch in svn using svn copy from trunk, bzr merge is not accepting it:
<luislavena> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<luislavena> I use bzr pull since branch was eating all my memory :P
<Lo-lan-do> luislavena: I know, I already reported that bug.
<luislavena> Lo-lan-do: oh, I see, I'm not the only one.
<Lo-lan-do> https://bugs.launchpad.net/debian/+bug/197356
<ubotu> Launchpad bug 197356 in debian "Branches created in svn don't seem related in bzr (dup-of: 203368)" [Unknown,Confirmed]
<luislavena> Lo-lan-do: how do you workaround it?
<ubotu> Launchpad bug 203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Wishlist,Confirmed]
<Lo-lan-do> Which is even a duplicate
<Lo-lan-do> I, uh, don't.
<Lo-lan-do> Apart from using bzr-push to create the branch in the first place.
<luislavena> Lo-lan-do: the branch already existed :-(
<luislavena> guess that will have to deal with the shelve.
<Stavros> hello
<Stavros> what's the difference between "bzr branch" and "bzr co"?
<LeoNerd> Where the commits go
<LeoNerd> If you commit to a 'branch'ed one, it's only stored there
<LeoNerd> If you commit to a 'co'ed one, it'll try to push it back upstream again
<Stavros> ah, so you need to push afterwards
<Stavros> aha, thanks
<LeoNerd> push, or pull from the other place, or merge..
<Stavros> ah
<LeoNerd> Basically, it's a question of "is this some other branched work, or is it supposed to be 'thesamework' in another physical location?"
<Stavros> hmm, it's the latter, but i think i'll still tell people to branch
<Stavros> so they can commit offline until they're ready to push
<LeoNerd> Ah.. well, that can be done too
<LeoNerd> For "occasional-offline" machines, you can co anyway.. and pass the  --local  flag to commit
<Stavros> indeed...
<Stavros> is there a windows setup package that includes a gui?
<Stavros> i suggested bzr over svn so i want to make this as easy as possible
<Stavros> (to avoid getting lynched, you understand)
<jkakar> Is bzrtools distributed in the bzr PPA?
<abentley> jkakar: yes
<jkakar> abentley: Cool, thanks.
<sabdfl> hey folks, should we still have "baz" packages in ubuntu, labelled "bazaar"?
<chadmiller> sabdfl: I think it's to be fixed soon.  The disambiguating version number is about to be false too.
<dato> sabdfl: afaik james_w and beuno are putting some work into having them renamed to baz, and have bazaar be bzr (at some point)
<sabdfl> james_w: is that a hardy exercise?
<sabdfl> imo, we definitely don't want "bazaar" being "baz" for all of hardy
<james_w> sabdfl: I would like it to be, but baz FTBFS and I haven't been able to fix that yet
<james_w> so the transition is stalled until we can fix that.
<dato> .oO(unless you completely drop it from the dist)
 * sabdfl is inclined to drop baz
<sabdfl> does bzr still do a good job of conversion from baz?
<chadmiller> sabdfl: What's the "sa"?
<james_w> that's reasonable, we'd like to do the transition in Debian as well, and there is less support for just dropping it there
<james_w> the other thing is that baz is a requirement for bzr baz-import, and so it's a way we can provide a migration path for baz users to bzr
<ubotu> New bug: #208387 in bzr "bzrtools 1.3 is not available for feisty fawn" [Undecided,New] https://launchpad.net/bugs/208387
<sabdfl> chadmiller: self-appointed
<Stavros> hmm, i think bzr doesn't like cygwin
<Stavros> bash: bzr: command not found
<james_w> Stavros: did you install the cygwin or Windows bzr?
<Stavros> james_w: python, i think
<Stavros> definitely not cygwin
<Stavros> let me doublecheck
<james_w> I think you may need to adjust your $PATH
<james_w> though I think windows bzr through cygwin is a long road to pain
<ubotu> New bug: #208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Undecided,New] https://launchpad.net/bugs/208418
<Stavros> damn, it's huge
<Stavros> james_w: it's not through cygwin
<Stavros> i didn't touch cygwin
<james_w> yeah, there's a separate cygwin port
<Stavros> i have no clue wtf it's doing with bash now..
<Stavros> oh
<Stavros> maybe it's running bash on the remote server
<Stavros> or maybe bash is telling me bzr wasn't found
<Stavros> that's it :/
<Stavros> what's an easy to install gui for windows?
<james_w> ah, what command are you running?
<Stavros> bzr+ssh
<Stavros> but it's odd, because bzr is supposed to be there
<james_w> BZR_REMOTE_PATH might help you there.
<james_w> set that in your environment to be the path to bzr on your server
<Stavros> hmm, it's multiuser, so it should just work :/
<Stavros> i will ask the admin to do it
<Stavros> hmm, shouldn't bare ssh:// work?
<fullermd> Well, it doesn't.
<fullermd> "should" is a very broad question  :p
<Stavros> hmm
<Stavros> so anything i can do now?
<sabdfl> poolie: ping
<james_w> Stavros: sftp:// should work for you
<Stavros> oh, thanks
<Stavros> ah, it needs paramiko :/
<Stavros> does anyone have the link to the qt redist i need to install to get qbzr to work? the one i got is 70 mb
<james_w> does it work?
<Stavros> does what work?
<james_w> the distribution you have?
<Stavros> what do you mean? i'm in windows
<james_w> you said "does anyone have the link to the qt redist i need...the one i got"
<Stavros> oh
<james_w> which seems contradictory to me
<Stavros> i mean the link i found
<Stavros> i didn't download it
<james_w> ah, ok
<Stavros> is that the correct one?
<james_w> is it a qt distribution, or a qbzr one?
<Stavros> qt
<Stavros> damnit, why doesn't anyone include the correct link in the qbzr page? :(
<luks> because you are supposed to use the binary qbzr installer
<Stavros> what if you used the python bzr package?
<luks> that's not a problem
<Stavros> apparently it is, because i can't get it to work
<luks> unless you have some strange version of python
<Stavros> i just installed 2.5
<Stavros> qt isn't included in what i installed
<luks> yep, I said the binary installer
<Stavros> the 110 kb one?
<luks> you can use http://www.riverbankcomputing.co.uk/pyqt/download.php for the other one
<luks> I dunno how big is it
<Stavros> it doesn't include qt
<luks> that's the wrong one then
<Stavros> there's one for python and one for standalone
<luks> "qbzr-setup-0.8.0.exe  "
<Stavros> that's for the standalone bzr version
<Stavros> i don't want that version
<luks> ignore that
<luks> otherwise, download pyqt from the link I posted
<Stavros> ok, i'll do that and see...
<james_w> jelmer: my apologies, I underestimated bzr-svn
<jelmer> yacc: if you want a stable bzr-svn, use a release...
<LarstiQ> bzr: ERROR: Unable to push revision 'wouter@chuck-20080328195425-e5de7xtz87t6ozd4' because it would change the ordering of existing revisions on the Subversion repository root. Use rebase and try again or push to a non-root path
<LarstiQ> ho hum
<LarstiQ> jelmer: I suppose this is due to different branching schemes
<jelmer> LarstiQ: you can only append revisions when pushing to a repository root
<jelmer> LarstiQ: you merged I think, and that would change the lhs revision history
<jelmer> yacc: still there?
<LarstiQ> jelmer: well. That sucks.
<jelmer> LarstiQ: it's impossible to change the root in subversion
<LarstiQ> jelmer: I don't understand it yet, but I'll just uncommit for now
<fullermd> Anything's possible if you push hard enough   ;)
<RainCT> Hi
<RainCT> can I let bzr remember two commit URLs?
<RainCT> ie, save a second one with an alias so that I don't have to write the complete URL each time I want to push there
<beuno> RainCT, I don't think you can have aliases on a per-branch basis
<RainCT> hm.. well I think I'll just keep two branches locally too
<RainCT> thx
<beuno> RainCT, you can always file a bug requesting it  :)
<james_w> yeah, aliases would be a good thing to have
<RainCT> james_w: great you want them too, feel free to request them then :P
<james_w> feel free to implement them :-)
<fullermd> It's probably been at least a month since they were last requested   :P
<javierder> Hello!
<javierder> I'm working in a bzr plugin for Gedit.
<javierder> And I have a problem! :)
<dash> Hi. does bzr have anything like svn's "externals"?
<javierder> when doing a workingtree.smart_add("mypath") to add everything there, it only adds files in that directory, but it's not recursive...
<beuno> jelmer, ping
<abentley> dash: There has been some work on that, but it is incomplete.
<dash> OK
<dash> is it the useful-in-limited-situations kind of incomplete or the breaks-in-surprising-ways kind? :)
<abentley> sabdfl: bzrtools does good conversion from baz, but it uses baz to do it.  (bzr itself has never handled baz)
<abentley> dash: The latter.
<dash> OK.
<sabdfl> thanks abentley
<dash> Guess I'll be patient then. :)
<sabdfl> anybody know why 1.3 hasn't shown up in the PPA?
<beuno> sabdfl, it has today  :)
<beuno> I just installed a few minutes ago
<beuno> ah, you meant bzrtools
 * beuno goes back into vim
<awmcclain> Just to be clear... there's no way to check out one file from a branch, correct?
<james_w> corrrect
<james_w> javierder: I think it should be recursive, is there a recursive parameter to the method?
<james_w> javierder: another possibility is that all the files in there are ignored.
<javierder> james_w, i found the problem. there was a .bzr inside the subfolder. thanks!
<james_w> javierder: cool
<awmcclain> uh oh
<james_w> what's up?
<awmcclain> I think i really broke something... I changed my .bzr/branch/location  from sftp:// to bzr+ssh://, got a bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request '/'\n"
<awmcclain> And now when i changed it back, i get bzr: ERROR: Not a branch: "sftp://bamboo.fluther.com/repos/conf/
<james_w> ouch
<awmcclain> any thoughts?
<james_w> double ouch
<james_w> I'm not really sure.
<awmcclain> triple ouch
<james_w> that's a public branch? Is there http access?
<awmcclain> no, it's publicly available authenticated branch
<james_w> ok, can you ssh to the machine?
<james_w> if you can please do so and ls -R .bzr on the branch.
<james_w> let's find out what state it is in
<luislavena> hello everybody.
<luislavena> been testing bzr-svn in my workflow, and found something funny...
<luislavena> if you svn-push a new branch (which previously was a branch from trunk) and forgot to push the changes in trunk, it always mark as missing and don't let oyu push them...
<awmcclain> ok
<awmcclain> james_w: Here's the output of the ls http://dpaste.com/41918/
<awmcclain> james_w: Fortunately, I don't have very many changes
<awmcclain> james_w: I can re-checkout the branch and port my changes over
<james_w> luislavena: you probably want to file a bug on that
<james_w> awmcclain: sorry, I was trying to code, let me look now
<awmcclain> james_w: np
<hno> Is there any way of creating a submission bundle (bzr send) of changes already in trunk?
<james_w> awmcclain: that's the remote branch?
<awmcclain> james_w: Correct.
<james_w> it looks ok. perhaps you should cat .bzr/branch/format and check it is sane
<awmcclain> james_w: I just rebranched and was able to checkin
<james_w> hno: you might be able to do it with a -r
<awmcclain> err
<beuno> hno, I suppose you could copy over trunk, bzr revert to where you want it, and do a send against that one
<luislavena> james_w: ok, I'll try to recreate the steps and post on a bug.
<luislavena> james_w: thank you.
<james_w> and what beuno says
<awmcclain> james_w: (re checked-out, i should say)
<lifeless> hno: yes, just supply the exact revision range
<hno> james_w: Not quote.. the patch gets rendered fine, but the resulting bundle is empty..
<lifeless> hno: -r x..y
<james_w> hi lifeless
<hno> hi lifeless
<james_w> awmcclain: odd, perhaps your local end was messed up
<james_w> awmcclain: does it still happen with the original checkout?
<awmcclain> hrm
<hno> lifeless: I guess it's due to not really having a target branch..
<james_w> awmcclain: -Derror and ~/.bzr.log might help if so
<james_w> though I don't know if -Derror will change anything here
<hno> (used trunk as the target)
<james_w> hno: what do you want the merge directive for?
<lifeless> hno: perhaps try manual target branch etc; it seems to me it should still add content in this case and I'd call it a bug
<fullermd> Mmmph.  Seems like we've had that discussion more than once...
<awmcclain> james_w: A ha!
<hno> lifeless: I guess it would work specifying an empty target branch, or at least one not having the change...
<awmcclain> james_w: Newline at the end of the file!
<james_w> awmcclain: wow
<fullermd> hno: I doubt that would do what you want either...
<awmcclain> james_w: FTR, this is all because you can't do a branch on a rich-root-pack over ssh://
<james_w> bzr+ssh://>
<james_w> ?
<awmcclain> james_w: Correct.
<james_w> awmcclain: sorry, I'm not familiar with that problem, what is it?
<awmcclain> james_w: Ah. Branch over a smart protocol default to creating the branch in the default format (pack?). If you have a branch converted from svn (in rich-root-pack) it will fail. The workarounds are 1) Do a lightweight checkout 2) cehckout into a shared repo formatted with rich-root-pack 3) checkout over sftp://, then change the protocol to bzr+ssh://
<hno> using an empty target branch was not a good idea.. bzr send -r x..y /empty/branch is chewing up all the cpu...
<lifeless> hno: yah; I think this is a bug :>
<fullermd> It'll end up bundling the WHOLE branch.
<lifeless> hno: using a branch without y, where -r x..y, will work; ideally the branch will contain x.
<hno> Feels kind of odd to not be able to create an untargeted bundle..
<fullermd> The logic (AIUI) goes like   - "-r" gives the rev range to be commanded   - The displayed patch is an approximation of the result of applying that   - The revisions bundled up are determined by what doesn't exist in the target branch
<james_w> awmcclain: ah, I remember now, thanks
<hno> fullermd: Yes, I understand that. But what I need in this case is to bundle exactly the revisions said without a specific target.. it's input to a separate cherrypicking/backporting tracker.
<fullermd> Right; there isn't a way.
<fullermd> What you'd do is make a temp branch to use as the target holding the base rev.
<fullermd> (at least, there isn't a UI way; you could probably force it using bzrlib directly)
 * hno isn't a very python guy..
 * fullermd isn't either   :)
 * hno wonders what that send against an empty target is up to.. it's still running..
<fullermd> Bundling up the whole history of the branch.
<fullermd> (after all, the target doesn't have ANY of those revs, so we need to send them ALL)
<hno> that doesn't make sense.
<fullermd> A merge directive is a directive to merge.  -rx..y defines what revs the other end is being told to merge.  The target branch determines what revs need to be bundled to do that.
<fullermd> So the bundled revs are something like -r{HEAD_OF_TARGET_BRANCH}..y
<fullermd> And since the head of your target branch is nothing (or at least, nothing in the ancestry of x or y, which is the same thing in this case)...
<james_w> heh, it seems I've invented an O(ugliness of history algorithm)
<james_w> or rather O(ugliness of history) algorithm
<james_w> though I'm sure the former would be an interesting one to try and analyse
<hno> fullermd: I believe you that it's what bzr does. But still doesn't make sense.
<james_w> on bzr.dev: bzr mlog  4.21s user 0.09s system 93% cpu 4.598 total
<james_w> on emacs: 0.24s user 0.05s system 87% cpu 0.328 total
<james_w> (straight line history for the latter)
<james_w> though I guess it's not unusual
<fullermd> james_w: The prettier the algorithm is, the better it scales?  There's a PhD thesis in there somewhere...
<james_w> I think so too
<fullermd> Hm.  That suggests that code optimization could best be done in Befunge...
#bzr 2008-03-29
<ubotu> New bug: #208566 in bzr-svn "missed commit never get pushed between branches and trunk" [Undecided,New] https://launchpad.net/bugs/208566
<james_w> beuno: nice photos. The make you look like you spent a week whiteboard shopping
<bronson> Hi.  I have a single repo tracking an upstream bzr project.
<bronson> I'd like to have 3 different local configurations, and be able to merge between them during development.
<bronson> In git, I'd just have 3 branches.
<bronson> I don't quite see how to accomplish the same thing in bzr?
<bronson> (the changes are very small so I'd like to keep everything in the same repo)
<james_w> bronson: you are confusing the terms repo and branch, from the bzr point of view anyway
<james_w> you currently have a single branch tracking an upstream project
<bronson> OK so far.
<james_w> so in bzr you would make three branches and merge between them
<james_w> just like git
<james_w> however bzr identifies branches with a location on the filesystem, so unfortunately you need three copies of the upstream source
<bronson> ack.
<bronson> not good.
<james_w> however if you use what's called a "shared repository" then you can share the history between them, which makes it less painful
<bronson> OK, I'll look into shared repository.
<bronson> thanks!
<fullermd> And you could always blow away the WT's of the branches you aren't using at a given time.
 * fullermd does that with some regularity.
<james_w> there are two ways that you can use a single directory to do what you want, they're not that straightforward, but they will work.
<james_w> the first is to use the "loom" plugin, that provide functionality similar to git-style branches. However looms are ordered, so it's a bit different.
<james_w> the other, and probably better way for you, is to use a "checkout" and the switch command.
<TFKyle> james_w: I assume it'd be pretty hard not to have 3 copies of the source (hmm, a custom FUSE fs might be able to do that actually, then only create new copies on-demand when you save first)
<bronson> Ah, I saw the switch command in the faq.
<TFKyle> (working copy wise that is)
<james_w> there you create a treeless shared repository, with the tree branches.
<james_w> this still takes up three directories, but the cost is minimal, about a dozen files in total, and virtually zero size
<james_w> you then use "bzr checkout" of one to create a working area.
<TFKyle> ah, guess loom/shelve would sort of work, as long as you don't need them both to exist on the filesystem concurrently
<james_w> you can then use the switch command to change which branch your working area is pointed at, which makes it act like "git checkout" here.
<james_w> I can walk you through the steps if you like.
<bronson> Shared repo doesn't seem to do what I want...  It still has individual WTs.
<bronson> That second suggestion sounds more like it.
<bronson> switch command.
<james_w> TFKyle: I guess shelve would work as well, but it's not what I'd do.
<bronson> I can picture how it would work.
<james_w> bronson: yeah, I think it's the winner for you.
<james_w> bzr init-repo --no-trees project
<orutherfurd> hi, can anyone give me pointers re figuring out files involved in a revision (added, modified, removed, renamed)?  I'm trying to write an importer from bzr to hg and while parsing bzr output is easier, I figure using bzrlib would be better.
<james_w> cd project
<bronson> OK, thanks james_w
<james_w> bzr branch whatever
<james_w> then bzr checkout branch working-area
<james_w> cd working-area
<james_w> and play with switch, passing it the path of the branch that you want to work on
<james_w> also see cbranch from bzrtools if you are going to be creating a lot of new branches with this style.
<james_w> hopefully we'll have some improvements in this area soon to make your workflow easier.
<james_w> orutherfurd: get the revision_id
<james_w> then tree = repository.revision_tree(revision_id)
<james_w> changes = tree.changes_from(tree.basis_tree())
<james_w> changes is then a tree delta
<james_w> it has .added .removed .renamed etc.
<james_w> you can also pass the parent trees directly if you need to know what changed compared to each parent.
<orutherfurd> james_w: that's great, though, does basis_tree() the 'tip'?
<orutherfurd> oh, right -- didn't see your last message
<james_w> orutherfurd: does this mean you are converting away from bzr, or are you a hg user that wants to use that to work on a bzr project?
<orutherfurd> james_w: well, I am a bzr user, but at work we'll be moving to hg -- and want to convert projects we have in bzr
<james_w> ah, ok.
<james_w> can I ask why you are moving?
<orutherfurd> sure, there are a few reasons: people find the docs better (the hg book), the convert extension worked really well (we're also converting some cvs repositories), plus other extensions people like (mq, springs to mind), the bundled web viewer which can be run as a cgi (vs loggerhead which has lots of deps)
<orutherfurd> (not to hit you with a pile of reasons)
<orutherfurd> the main reason for starting w/bzr was not needing to install software on a central server, but with the ssh directory permission problems, that didn't end up working
<orutherfurd> but from a maintenance point of view, having to install 1 piece of software, vs bzr + plugins, etc... is easier -- we're running an ancient version of rhel
<james_w> cool, thanks
<james_w> most of those are known I think.
<james_w> there is bzr-webserve which is a port of the hg one, so it runs the same way
<orutherfurd> oh, right -- I'd forgotten about that
<james_w> I can argue with the rest of your reasons as well if you would like :-)
<orutherfurd> if you' like :-P
<orutherfurd> have been using bzr since 2005 though, so not new to it, but for our setup, I think hg is a better fit; I do use bzr for personal stuff, so as not to come off as totally down on it ;-)
<james_w> longer than me then, so I'm sure you know it all
<orutherfurd> certainly didn't mean to suggest that -- otherwise I wouldn't be hear asking for help!
<orutherfurd> hear -> here
<orutherfurd> just figured I should disclose I've been hanging aorund for a while (reading the lists and as an end-user) for a while before you started in on your convincing ;-)
<james_w> well, ok
<james_w> the hg book is a great asset for them. The bzr docs have improved a lot recently thanks to Ian, but they are still lagging.
<james_w> I'm not familiar with the convert extension, but hopefully bzr-fastimport will be stable soon, and that should be really useful
<orutherfurd> the bzr docs do seem much improved lately
<james_w> bzr-loom is intended to do a similar thing to mq, and it has some features that I don't think mq has
<james_w> it's not there yet though
<james_w> the installation point is tricky, I think you are right.
<orutherfurd> the convert extension is pretty neat -- you provide some classes to interact as source or sink for another vcs and then you can, well, convert
<james_w> However bzr doesn't actually require installation, as long as you have python >= 2.4 and paramiko etc.
<orutherfurd> it already has support for cvs, svn, git, and darcs, I think
<awmcclain> Is there a way to specify a different status bar type via the command line?
<james_w> and plugins can just be dropped in bzrlib/plugins
<james_w> though keeping them up to date can be a pain, hopefully beuno's work will make that really easy soon
<james_w> awmcclain: I don't think so.
<awmcclain> okee doke.
<james_w> I think there is an environment variable
<orutherfurd> james_w: initially, the big draw was not having to install bzr on the server (which is the primary reason I use it for personal projects)
<james_w> that's a pretty neat feature.
<fullermd> Funnily enough, I've always considered that one of the least important features  :)
<awmcclain> Ok, I'm in a funky state. I thought I was working on a checkout, but it's actually a branch. I've made one checkin. I can't ci after I bind because my tree is "out of date". I'm pretty sure if I merge, I'll lose my updates. What should I do?
<fullermd> You need to 'update' after bind.
<awmcclain> Won't that remove the file I just added in my local ci?
<fullermd> No, it turns what you have locally that isn't upstream into a pending merge.
<awmcclain> hrm. ok. conflicts. "conflicts:
<awmcclain>   Conflict: can't delete load_tests because it is not empty.  Not deleting.
<awmcclain>   Conflict adding file load_tests.  Moved existing file to load_tests.moved."
<awmcclain> Ah, I see. Looks like I've deleted the directory and then readded. Hrm. How do I resolve the conflilct without removing my changes?
<james_w> put the directory that you want there, and then run resolve load_tests
<ubotu> New bug: #208608 in bzr-gtk "bzr-icon-64.png not included in package" [Undecided,New] https://launchpad.net/bugs/208608
<MrLieven> hi
<MrLieven> is there a way to combine two bzr branches into one
<i386_> perhaps your looking at merging ?
<i386_> check the docs
<MrLieven> ie. I have one bazaar branch, and want to import a different bazaar branch into a subfolder of that branch
<Kinnison> aah yes
<Kinnison> yes there is
<MrLieven> how?:)
<Kinnison> give me a sec
 * Kinnison is working it out again
<james_w> MrLieven: you can use "join"
<MrLieven> ok, i'll look it up
<james_w> however it is pretty experimental at the moment
<james_w> and will probably break in interesting ways
<MrLieven> hmm.. well, I can give it a try:)
<Kinnison> The way I was taught was:
<james_w> There is also a "merge-into" plugin that can do this, but if you want to continue merging from the other branch it does some interesting things.
<james_w> Is this a one time thing?
<Kinnison> in the branch you've adding *IN*, commit a change moving everything into the subdir of the name you want
<MrLieven> james_w, probably only once, yes
<Kinnison> then in the branch you're merging *TO*, do: bzr merge -r 0..-1 /branch/you/bring/in
<Kinnison> but that is a one-time-only operation
<james_w> that would work too.
<Kinnison> That's how Aranha (one of my programs) has a branch with three ultimate ancestors :-)
<AnMaster> is there something like git bisect for bzr?
<dato> there is a bzr-bisect plugin
 * AnMaster googles
<MrLieven> I guess I will go for kinnison's solution. Sounds the safest
<MrLieven> thx
<AnMaster> how do you install plugins? can you do it in your home dir?
<AnMaster> I don't want to mess up /usr/lib really
<dato> AnMaster: drop it in ~/.bazaar/plugins/bisect
<AnMaster> ok, I don't know python, don't you need a setup.py thing or something (why can't everyone just use a single build system...(
<AnMaster> s/($/)/
<james_w> AnMaster: no, just place it there.
<AnMaster> hm
<AnMaster> Unable to load 'bzr-bisect' in '/home/arvid/.bazaar/plugins' as a plugin because file path isn't a valid module name; try renaming it to 'bzr_bisect'.
<AnMaster> hm
<james_w> AnMaster: as dato said use ~/.bazaar/plugins/bisect
<AnMaster> ah seems it didn't like the result of a plain  bzr branch lp:bzr-bisect
<james_w> yeah, that's unfortunate
 * dato wonders if bzr-bisect, the directory, could not be imported as bzr_bisect
<dato> but, alas, I don't know much about python's import mechanism
<AnMaster> I'm no python programmer
 * AnMaster codes in C
<james_w> dato: I think it used to work, but it was changed so that one plugin could use bits from another
<james_w> I think that may still work with your scheme, but it makes it harder to know what the other plugin will be named for the import statement
<dato> yes; but that relies on for example plugin bzr-foo being installed as directory "foo" and not "bzr_foo"?
<dato> what I meant, it would be nice if the directory could be named $whatever, and then for its code to appear under bzrlib.plugins.<name_provided_by_the_code_inside_the_plugin>
<asabil> I agree with dato on this
<asabil> also it would be cool to have a plugin-manager plugin
<dato> james_w: btw, two things bzr has that git doesn't: (1) patience diff; (2) pulling into a dirty tree where the pulled revisions touch dirty files (and, relatedly, merge --force)
<TFKyle> dato: hmm, I'd expect it to be possible with sys.modules hacking, might be a bit ugly doing it though (havn't looked at bzr's plugin code though)
<TFKyle> hmm, actually it might be slightly harder than just changing sys.modules, probably need to change the bzrlib.plugins namespace as well
<james_w> dato: cool thanks. Is patience diff that much better?
<dato> it seems git will always refuse merge files with uncommitted changes, no matter how hard you try to convince it to do so (as far as I've investigated, that is)
<james_w> dato: yeah, I think Robert's proposal for plugin metadata may allow that
<james_w> asabil: beuno_ is working on one
<dato> james_w: well, I guess I've only noticed the cases where it's indeed better (in my case, mostly rewriting a file). but other git users have told me that, indeed, git is very willing to consider empty lines as "common" lines, thus making big changes appear interspersed with the old, deleted code
<dato> james_w: (http://chistera.yi.org/~adeodato/tmp/2008-03-28/diff/ fwiw)
<james_w> wow, thanks
<AnMaster> dato, not very useful that bisect, it gives a traceback
<AnMaster> bzr: ERROR: exceptions.RuntimeError: attempting to add revid anmaster@envbot.org-20080324152901-taj150bcztmhtf8q twice
<james_w> ouch
<dato> aha. well, I'm afraid I can't be of much help, I've never used, only knew that it exists.
<james_w> are you using https://code.launchpad.net/~jeff-licquia/bzr-bisect/bzr-bisect ?
<james_w> ah, you did lp:bzr-bisect didn't you? so you will
<james_w> AnMaster: can you rub with -Derror and pastebin the traceback?
<AnMaster> rub?
<asabil> run
<AnMaster> ok
<asabil> :)
<AnMaster> like bzr -Derror bisect ...  or?
<AnMaster> also I think I need to redo the bisect from start as it is probably messed up now
<AnMaster> anyway I did run with -Derror, no change in output
<asabil> paste the output in a pastebin
<AnMaster> http://rafb.net/p/dBp98k79.html
<AnMaster> asabil, yes I did just then
 * AnMaster waits
<asabil> poke james_w
<AnMaster> james_w, there?
<AnMaster> james_w, http://rafb.net/p/dBp98k79.html
<james_w> hehe, rub with -Derror
<AnMaster> james_w, I did that yes?
<AnMaster> $ bzr -Derror bisect yes
<AnMaster> looks like a -Derror to me
<james_w> I was just laughing at my typo
<AnMaster> ah
<james_w> ok, talk me through all the steps you did
<AnMaster> james_w, was looking for a bug, so I started with bzr bisect start on my source (can be found at http://rage.kuonet.org/~anmaster/bzr/cfunge)
<AnMaster> and did bzr good first to tell it the last had the think I wanted to check
<AnMaster> err bzr bisect good*
<AnMaster> do you want the order of good and bad bisects?
<AnMaster> james_w, if it matters I got this branch in a shared repo
<AnMaster> I can pastebin entire output if you want
<james_w> yeah, pastebin the session please
<james_w> I've never used it, and so I'm not sure whether you're doing something wrong or it's really buggy
<AnMaster> a sec just need to check for any sensitive info
<james_w> ok
<AnMaster> james_w, http://rafb.net/p/0wxvte63.html
<AnMaster> now I am happy I did a branch for this and didn't just run it in trunk
<AnMaster> james_w, what I'm doing is looking for when the test suite started outputting odd non-printable chars in case you wonder
<AnMaster> james_w, any idea? :(
<AnMaster> branch format is pack-0.92
<AnMaster> if it matters
<james_w> so you land on "BUGFIX: Fixing a series of improbable bugs that together made mycology pass on y when it shouldn't have..."
<james_w> twice, so it might well be a bug in the plugin
<AnMaster> james_w, not sure where I should have landed exactly, that is what I'm trying to find out using bisect :)
<AnMaster> james_w, but that one sounds quite possible like the one that could have caused it, the changes were in the affected area so
<AnMaster> the old way was broken too, but looks like new is as well heh
<james_w> AnMaster: I can't see anywhere in the code that actually reports that you have found the critical revision, which is odd
<AnMaster> indeed
<james_w> can you tell me if the revision mentioned above is a merge revision?
<AnMaster> james_w, no I have not worked with anyone else on this project, or rather they sent classical patches from diff -Naur
<AnMaster> and I only used one branch
<AnMaster> up until now where I branched to do a bisect
<james_w> ok, it's proabably just that problem then
<AnMaster> I do not wish to mess up my trunk
<james_w> a "bzr revert" will undo anything that bisect does
<AnMaster> yes, except it places some files into .bzr
<james_w> a bzr bisect reset should remove those I think
<james_w> however the plugin looks dangerous as it doesn't check for uncommitted changes in the tree first.
<AnMaster> james_w, anyway I got stuff in trunk that is not versioned (stuff like test files and so on) and jumping between revisions where the file doesn't exist could cause problems
<AnMaster> I mean directory where file is doesn't exist
 * AnMaster removes the bisect plugin from his system
<ChristopheT> Is there a reason when pushing through FTP that the .bzr/checkout/ is not trasferred?
<ChristopheT> This may be a problem when FTP pushing but others trying to branch via HTTP (some services only allow FTP upload).
<james_w> ChristopheT: yes, that's the expected behaviour
<james_w> you only push the branch, not the working tree
<james_w> others will be able to branch from that fine
<james_w> however if you want the working tree files to be available on disk on the server you are a bit stuck
<ChristopheT> My problem is exactly the following https://bugs.launchpad.net/bzr/+bug/129307 (the dummy server configuration -- of the service provider -- redirects the URL instead of issuing a 404)
<ubotu> Launchpad bug 129307 in bzr "Unable to branch from http server after ftp push" [Undecided,New]
<ChristopheT> How do I go about it?
<james_w> ChristopheT: is there anyway you can override this behaviour?
<james_w> ChristopheT: for instance a .htaccess?
<james_w> it would perhaps be possible to make bzr handle this better, I don't know
<muszek> hi
<muszek> my bzr suddenly started to freeze while commiting to a repo that's binded to an external server
<muszek> I have bzr 1.2.0.candidate.1 (on Hardy) and 1.1.0.candidate.1 (on production server running Debian Sarge)
<muszek> here's the output: http://pastebin.us/?show=m2e622911
<bob2> press cancel?
<bob2> ctrl-c?
<muszek> bob2: that's what I did...
<muszek> bob2: then I do bzr break-lock and repeat commit - same thing happens
<bob2> is it still doing anything or really hung?
<bob2> e.g. does tcpdump show traffic
<muszek> I'll try to run it
<muszek> err... I don't think I'll be able to learn using tcpdump in the next few minutes :)
<bob2> 'sudo tcpdump host poradnik.org and port 22'
<muszek> the commit is rather small (I'd say less than 1kB of changes in 4 files)
<bob2> does ssh'ing normally work fine and as fast as expected?
<muszek> yes
<muszek> hmmmm... not as fast as usually.  I've just initiated a download over ssh - 15kB/s
<muszek> upload goes at 8kB/s... could that be a reason?
<bob2> still should only take 1/8th of a second, right ;)
<muszek> yep
<bob2> ~/.bzr.log might show you where it's stuck
<muszek> well, it was never extremely fast, but commits usually took 10-20 seconds
<muszek> ok
<muszek> http://86.144.127.50/temp/.bzr.log
<bob2> it says it was packing the remote repository...does 'ssh -t muszek@poradnik.org bzr pack -v /home/tomekg/ifront/app/' return quickly or sit for a while?
<muszek> bob2: it executes in 14 seconds
<bob2> does commit work now?
<muszek> doing it right now...
<muszek> btw... I had an old commit hanging in there for some time... it finished with an error 'bzr: ERROR: No such file: '/home/tomekg/ifront/app/.bzr/repository/packs/631446bfbfbaf528bfa3518f048fd76d.pack'' (propably after that bzr pack you gave me)
<muszek> it finished successfully
<muszek> thank you very much
<bob2> yay
<bob2> no worries
<bob2> dunno why that helped, maybe the autopack code executes on the client instead of the server
<muszek> I'll keep that command around in case it happens again
<muszek> well thanks again and have a nice weekend :)
<bob2> you too :)
<muszek> bye
<ubotu> New bug: #208869 in bzr "info command failed at committers" [Undecided,New] https://launchpad.net/bugs/208869
<cdleary> I just did a bzr split [subdir] and now performing bzr status in the subdir returns "No working tree exists for [subdir]/.bzr/checkout/"
<LasseP_> hi
<LasseP_> does bazaar work with ant?
<bob2> in the sense that sccs works with make?
<luks> how does a version control system need to work with a build system?
<bob2> (as in magically checking thins out)
<LasseP_> i used to work with CVS and now i'm thinking about switching to bzr. i used ant as a build system so i can commit my changes, update specific working copies in a specific testing environment and to create automatic releases with just one keystroke ;)
<bob2> what does cvs integration does ant have?
<bob2> (I've never heard of it nor of simialr integration wih bzr)
<LasseP_> ant has some tasks available to work with CVS. i was wondering if there is something like that for bzr.. otherwise i will just execute the command lines from ant
<james_w> I've not heard of it
<james_w> you could probably write the stuff for ant to do it and then share it with everyone
<LasseP_> i will write the ant file, so it will execute the bzr commands. :)
<gdoubleu> I've got a bunch of small fixes to the core_concepts.txt docs.  Would it be ok to submit that as one patch or should I break it up?
<gdoubleu> Also I tried looking for some sort of style document for the documentation, but didn't find anything.  Are there any defined standards for the documentation?
<gdoubleu> For example, I noticed that bulleted lists had inconsistent indention.
<gdoubleu> Some, the bullet started in the first column of the line, and others it was spaced over one or two spaces.
#bzr 2008-03-30
<dacresni> are there any bottle necks identified in bzr >
<dacresni> ?
<ubotu> New bug: #209025 in bzr "ignore local changes" [Undecided,New] https://launchpad.net/bugs/209025
<schierbeck> jamesh: hey james -- do you know of any bzr-avahi gutsy debs lying around?
<elijah> Can bzr merge multiple branches into the current one at once (i.e. an octopus merge, in git-speak)?
<jelmer> elijah: technically yes
<jelmer> elijah: but I think the UI doesn't make it easy at the moment
<elijah> How does one do so?
<elijah> (feel free to point me at the docs if they're around somewhere)
<jelmer> elijah: The first branch you merge you can use regular merge for
<jelmer> for subsequent merges, specify --force (otherwise it'll complain about the working tree having uncommitted changes)
<elijah> ah, so you simply don't commit between merges, and force the 2nd, 3rd, etc. merges.  Is that right?
<jelmer> elijah: yep, exactly
<elijah> sweet, thanks.
<ubotu> New bug: #209046 in bzr "Crash when comitting with non-English description" [Undecided,New] https://launchpad.net/bugs/209046
<Peng> 1.3 will be out March 20th? Wow!
<rolly> only 346 days left
<jdong> rolly: never worry! Maybe my branch on LP will have refreshed by then!
<jdong> (kidding, kidding :D)
<abentley> Peng: Maybe it's an announcement that 1.3 *is* out, as of 20 Mar?
<Peng> It was set on 20 Mar, so maybe you're right.
 * Peng wanders off.
<Cheba> Hello.
<Cheba> I've seen several times "bzr+http" mentioned here and there on the net. But can't find any info about that. Is there anywhere docs on that?
<mc__> How do you resolve your conflicts? May you recommend me a good tool?
<RAOF> mc__: Meld is quite a nice graphical diffing tool, but I tend to just rummage through in emacs.
<bob2> smerge-mode is quite cool
<mc__> I'm not an emacs user though.
<bob2> people use vimdiff, too
<matthewlmcclure> Hi, I'm using Bazaar on Cygwin with a Windows diff program.
<matthewlmcclure> I had to edit the Bazaar source to make it work since the Windows program doesn't understand symlinks.
<matthewlmcclure> Is there a better way?
<jelmer> matthewlmcclure: I think there is a plugin
<matthewlmcclure> jelmer, I see "win32symlinks".  Is that it?
<phanatic> matthewlmcclure: it is that
<matthewlmcclure> Thanks.  I'll give it a try.
<jelmer> hey phanatic
<jelmer> phanatic: does bundlebuggy work again for you?
<phanatic> hey jelmer, it does :) i've just merged those requests...
<matthewlmcclure> Hm... I think win32symlinks isn't what I need.  It looks like win32symlinks is for avoiding file copies on Win32-native bzr
<phanatic> jelmer: sorry, but i'm not used to this workflow yet, and i don't always get right who has to merge.
<matthewlmcclure> My trouble is that my Windows-native diff program doesn't understand the symlinks created by Cygwin bzr.
<jelmer> matthewlmcclure: there's not really a way around that I think
<jelmer> phanatic: Thanks for merging them
<jelmer> phanatic: Basically, the idea is that the submitter merges the merge request once it is approved
<jelmer> unless the submitter doesn't have commit rights, in which case the second approver merges it
<jelmer> at least, that's what's done for bzr.dev and I think it makes sense for bzr-gtk as well
<Cheba> matthewlmcclure: use something that works under cygvin. Say, vim diff. There is no other way.
<phanatic> jelmer: thanks for the clarification
<matthewlmcclure> I'd like to offer a patch to bzr to make my use case work.  I think I have to make bzr use file copies instead of symlinks.
<Cheba> That won't work.
<jelmer> schierbeck: hi
<matthewlmcclure> Cheba: do you mean it won't work at all?  Or that symlinks are preferrable when they work, so you won't accept a patch that stops using symlinks on Cygwin.
<Cheba> First you'll have to mainatain symlink index somewhere so bzr know if it have to commit changes in symlink-copy file.
<Cheba> Second you'll have to deal with the case when original file and symlink are edited separately and has different changes.
<Cheba> While first is rather simple to deal. The second case is a big break in symlink idea.
<schierbeck> jelmer: hi
<schierbeck> jelmer: i read up on some of the sprint notes -- you guys were talking about signed revisions in bzr-gtk?
<jelmer> schierbeck: Yep, we talked about that a little bit
<schierbeck> jelmer: i've got a branch implementing the basic stuff in lp:~dasch/bzr-gtk/signatures/
<jelmer> the ability to sign revisions from gcommit and the ability to display signatures in bzr viz as we discussed on the list earlier
<jelmer> schierbeck: ah, cool
<schierbeck> it's very basic; it just informs the user whether the revision has been signed or not, and if so, if the signature is trusted
<schierbeck> i don't even think i got the icon installation working
<schierbeck> you're more than welcome to play with the code and make changes, i have exam the next week, so i'm kind of busy
<schierbeck> *exams
<jelmer> oh, ok
<jelmer> schierbeck: btw, you mentioned wanting to discuss the future direction of bzr-gtk
<jelmer> would now perhaps be a good time? phanatic also appears to be around
<matthewlmcclure> Cheba: doesn't windows-native bzr have to solve the second problem already?  Forgive me, I'm not very familiar with the code yet.
<schierbeck> jelmer: yeah, i have some time now
<jelmer> matthewlmcclure: Windows native doesn't support symlinks either
<phanatic> me too :)
<jelmer> cool :-)
<schierbeck> awesome :)
<schierbeck> well, i'd better start then
<schierbeck> my main concern is what our product should be
<schierbeck> should we keep the status qou -- i.e. a bunch of loosely couple utility programs?
<schierbeck> or should we try to integrate them more tightly -- i.e. buff up the viz
<schierbeck> erm, status "quo"
<Cheba> matthewlmcclure: it doesn't. It just complies that platform doesn't support symbolic links.
<jelmer> From my POV it makes sense to have bzr-gtk as a set of utility apps that can be reached from a couple of places - i.e. from GNOME, olive or the command-line.
<jelmer> GNOME being the nautilus integration, task bar, preferences
<schierbeck> jelmer: i agree that our widgets should be generalized in order to fit into different contexts, such as olive, nautilus and the viz
<schierbeck> but i'm not sure about the command line -- do we really need to provide gui versions of *all* commands?
<matthewlmcclure> cheba, jelmer: right, so I think if bzr had a workaround for Cygwin that "Cygwin doesn't support symbolic links", bzr would satisfy my use case.
<schierbeck> i mean, what does gpull provide that plain pull doesn't?
<schierbeck> i think we need to beware of command pollution
<jelmer> schierbeck: Pops up a dialog that allows you to select a branch
<schierbeck> well, true dat
<jelmer> schierbeck: I don't think the fact it adds commands is really a problem
<schierbeck> still, as a user of bzr-gtk, all i really need is the viz
<phanatic> schierbeck: that's useful for olive, for example. so maybe just hiding it as a command would be okay, but please don't remove it :)
<schierbeck> phanatic: don't worry, i'm not gonna go on a delete-frenzy :)
<schierbeck> but i think we should perhaps consider whether anyone is actually using all those utility apps from the cli
<jelmer> schierbeck: I'm happy to hide some of them
<Cheba> matthewlmcclure: well, cygwin internaly handles symlink emulation so for all applications under cygwin those emulated symlinks look just like real. That's why I proposed to use tools that also run under cygwin.
<jelmer> schierbeck: So they don't show up in "bzr help commands" but I don't see a reason to remove them alltogether.
<jelmer> I use "bzr gpull" to test the pull dialog, for example.
<schierbeck> jelmer: that sounds reasonable
<phanatic> to me too...
<jelmer> schierbeck: We could only make those commands visible that actually add something that's not present in their command-line equivalent
<jelmer> such as gdiff / gcommit / viz
<schierbeck> jelmer: exactly!
<phanatic> jelmer: and gannotate
<TFKyle> should probably add a help hidden-commands or something too imo
<matthewlmcclure> Cheba, agreed, that would work; but it's a better user experience to be able to use Windows since I have all of Windows.  I use Cygwin because I like it better than the Windows shell.  I'm advocating better flexibility for the user to choose his own tools.
<schierbeck> TFKyle: i think the hidden commands should be so peripheral to the average user that web documentation should be enough
<TFKyle> schierbeck: I think it'd be useful still for debugging and/or making sure when you create a command in a new plugin that the name isn't already taken
<schierbeck> TFKyle: that's true -- but perhaps have a central table on the bzr website with all command names is the optimal solution?
<schierbeck> okay, i think we just need to sit down and sift through the commands -- should i just send in a list of commands i find irrelevant later on?
<schierbeck> then we can discuss them individually
<schierbeck> jelmer, phanatic: okay, the next thing on my mind is what the role of olive and nautilus should be
<TFKyle> that's probably a good idea, though I'm slightly iffy on that being the only way to tell all of the hidden commands in your env out (sometimes I'm too lazy to go to the bzr website or offline (not so much, but I imagine a couple people are often enough))
<jelmer> schierbeck: btw, the signatures code looks very nice!
<jelmer> schierbeck: Any chance you can make it optional though (hide the Signature tab if "import gpg" raises a ImportError) ?
<schierbeck> jelmer: thank you -- still in its early stages, though. i need to go through the gtk icon docs.
<schierbeck> jelmer: sure
<TFKyle> mm, signed rev stuff in bzr-gtk will be nice
<schierbeck> TFKyle: perhaps an environment variable?
<jelmer> schierbeck: imho the various bits and pieces in bzr-gtk should be reachable from nautilus and/or other core ui's
<jelmer> I don't think bzr-gtk should rely on GNOME (Nautilus) to be usable though
<schierbeck> jelmer: i was more thinking: could we place all of olive's functionality in the nautilus plugin?
<schierbeck> jelmer: yeah, but is anyone using olive outside gnome?
<jelmer> schierbeck: that's already happened to the extent in which it is possible
<jelmer> schierbeck: yes, it is perfectly possible to use olive without gnome
<Cheba> matthewlmcclure: if anyone uses symlink I assume they know what they're doing. Say, I would newer rely on symlink if I'd know that this software have to run on windows. It's just because windows sucks and does not provide a way to define symlinks.
<phanatic> schierbeck: i think olive should be improved, and i have some plans on that. it has its place as a tool - i talked to a few people at the sprint, and they told me that olive is not a bad approach at all, since there are similar tools for svn/cvs (cervisia, wincvs, etc.)
<TFKyle> jelmer: havn't read the code, but you're saying the gpg module is part of gnome? seems odd
<jelmer> TFKyle: where did I say that?
<schierbeck> okay, i was just probing here. i think generalizing our widgets will improve all the bzr guis
<Cheba> Though, AFAIK, NTFS has hardlinks which can ease emulation of symlinks.
<schierbeck> TFKyle: we're running a dual-track discussion here
<schierbeck> TFKyle: we'll merge them later on ;)
<TFKyle> jelmer: heh, I assumed <jelmer> schierbeck: Any chance you can make it optional though (hide the Signature tab if "import gpg" raises a ImportError) ? and <jelmer> I don't think bzr-gtk should rely on GNOME (Nautilus) to be usable though were related, I likely suck though
<jelmer> TFKyle: ah, yes - that was mixing two discussions
<matthewlmcclure> Cheba, I think you're talking about symlinks inside a branch's working tree.  My main issue is how bzr internally uses symlinks to make 'diff --using=' faster, more space-efficient.
<jelmer> schierbeck: Yep, exactly
<jelmer> schierbeck: We're already there to a large extent
<jelmer> schierbeck: nautilus-bzr.py just imports dialogs from bzr-gtk and is itself very small
<schierbeck> jelmer: yeah, although some widgets could be split into smaller ones, e.g. the revision view
<Cheba> matthewlmcclure: oh... I see.
<matthewlmcclure> sorry i wasn't clear before
<schierbeck> jelmer, phanatic: what's your stance on the viz? should we make it more interactive?
<schierbeck> i.e. add pulling, pushing, merging, committing?
<phanatic> schierbeck: in fact that would make it similar to olive, but revision based instead of file based :)
<jelmer> schierbeck: Adding the ability to open the pull / push dialogs from viz sounds like a good idea to me
<schierbeck> phanatic: exactly -- but those are two very different workflows!
<jelmer> schierbeck: although that's already possible somewhat too
<jelmer> schierbeck: Merge and Commit I'm less sure about
<schierbeck> jelmer: i don't think the viz is updated with the new revisions, so you still have to restart
<phanatic> schierbeck: my plan is to actually merge the two workflows. so you can switch quickly between revision and file based views...
<jelmer> allowing "bzr merge" and "bzr commit" inside viz is kinda pointless imho since those two operations require you to do working tree operations
<schierbeck> phanatic: just what i'm thinking -- but what should be merged into what?
<jelmer> schierbeck: that's a bug :-)
<schierbeck> jelmer: i don't see why -- you most likely have a terminal window open anyways, since that's the only way i know of to open the viz outside of olive
<phanatic> schierbeck: i don't really care to be honest :)
<schierbeck> phanatic: well, you know i love the viz :D
<schierbeck> phanatic: if we could provide the file view as a widget, that would be awesome
<phanatic> schierbeck: yeah, that's why - i don't want to fight about this tiny little detail :)
<phanatic> schierbeck: yeah, sounds sane
<schierbeck> okay, i guess we should commence work on that soon, then
<schierbeck> btw phanatic, jelmer: i've been reporting loads of bugs on launchpad, many related to merge proposals -- when that works well, and email support has been added, would you be interested in moving merge proposals to lp?
<phanatic> schierbeck: bundlebuggy coming to launchpad? :P
<jelmer> schierbeck: I'm a little bit concerned about having viz as a full bzr frontend
<schierbeck> phanatic: exactly!
<jelmer> schierbeck: to me it's mainly a revision browser
<schierbeck> phanatic: i think they're working on it
<jelmer> schierbeck: as long as it doesn't require me to use a web ui, I'll happily consider launchpad
<phanatic> schierbeck: it would be better, since unfortunately our current bb instance switches off sometimes :/
<schierbeck> jelmer: i don't think we need to go full right away -- we could start with pull/update, which seems reasonable in a browser
<schierbeck> jelmer: yeah, they have plans for email control
<schierbeck> jelmer: bug #202003 covers this
<ubotu> Launchpad bug 202003 in launchpad-bazaar "Should be able to review merge proposals over email" [Medium,Confirmed] https://launchpad.net/bugs/202003
<schierbeck> when the merge proposal workflow on lp is good enough, we can talk about moving to that
<schierbeck> jelmer: i've also just made the signature tab optional
<schierbeck> push as we speak
<jelmer> schierbeck: Doh, I also did that..
<schierbeck> :)
<jelmer> I've also moved the tab to a separate window
<schierbeck> jelmer: do you want me to move the branch to ~bzr-gtk?
<schierbeck> jelmer: in what sense?
<jelmer> s/window/class/
<jelmer> schierbeck: Yes, if you could change the owner that would be useful
<jelmer> schierbeck: unfortunately launchpad doesn't appear to be very fast implementating wishlist items :-/
<jelmer> not sure how much priority this has for them internally
<matthewlmcclure> Would it be best if I open a bug in https://bugs.launchpad.net/bzr ?
<jelmer> matthewlmcclure: about symlinks?
<jelmer> matthewlmcclure: Is there a clear way to move forward?
<matthewlmcclure> yes, re: symlinks.  I'm not 100% clear on the best solution, but the symptoms are clear.
<jelmer> matthewlmcclure: there's probably already a bugreport open
<jelmer> matthewlmcclure: this is about being able to check out symlinks in working trees, right?
<matthewlmcclure> jelmer: no, it's about 'diff --using=' not working when the arg to using is a Windows app, and bzr running in Cygwin.
<schierbeck> jelmer: it seems to work :)
<schierbeck> "change registrant"
<schierbeck> jelmer: ~bzr-gtk/bzr-gtk/signatures
<jelmer> thanks
<matthewlmcclure> I think bzr needs to pass the physical path to the diff program instead of the symlink path.
<Pilky> hey all, does anyone know if there's anyone doing anything along the lines of a Mac GUI client for bazaar?
<jelmer> matthewlmcclure: ahhh, yes please file a bug
<jelmer> Pilky: any reason for not using bzr-gtk or qbzr?
<matthewlmcclure> will do.  thanks.
<Pilky> jelmer: I'm thinking more along the lines of a native Mac GUI client
<schierbeck> wow, launchpad bzr operations are extremely slow today
<schierbeck> Pilky: there are, to my knowledge, not any native ones
<schierbeck> but if you'd like to write one...
<Pilky> I might consider it at some point, the main issue would be finding time (and the fact that I only found out about bazaar yesterday ;) )
<schierbeck> Pilky: if you do, i'd be more than happy to help you if you have any questions
<phanatic> Pilky: both qbzr and bzr-gtk work well on os x. and qbzr has native look.
<Pilky> I think I'll play around with bazaar for a while and start using it on my apps to get used to it and then I might consider looking into a GUI client over summer
<Pilky> phanatic: aqua buttons does not a native Mac UI make ;)
<phanatic> textmate has a really good bazaar integration as well
<Pilky> hmm, now that's more interesting
<phanatic> Pilky: i know :)
<Pilky> I have to say I knew that the background images on the Mac disk images are an extremely nice touch
<Pilky> hell, having disk images on the official site for a vcs is a nice touch :P
<phanatic> hehe :D
<phanatic> i'm glad you like them ;)
<jelmer> schierbeck: still there
<jelmer> ?
<Pilky> especially after spending most of yesterday fighting to get git to do something vaugly useful
<jelmer> schierbeck: I think the signature branch is ready for merging
<jelmer> I've added code to be able to find the icon path
<phanatic> Pilky: of you have Leopard, you should have no problems getting it running after the install...
<Pilky> phanatic: git ran, I just couldn't get my head around it, dunno why really
<Pilky> bazaar just seems simpler and has nicer documentation
<luks> you are not the only one who has that problem :)
<phanatic> :)
 * TFKyle was never able to wrap his head around git either
<Pilky> in fact the general mentality seems to fit my Mac mind, like it doesn't have to be the fastest, it just shouldn't be slow
<jelmer> schierbeck: anyway, merge request sent :-)
<jmehdi> I've just created a branch by doing "bzr init", "bzr add", "bzr commit" but now I'd like to know which files are under source control, is it possible?
<jelmer> jmehdi: bzr st
<jmehdi> it displays nothing... my "bzr add" didn't add anything??
<jelmer> sorry
<jelmer> you need "bzr ls --versioned"
<jmehdi> yep it's better ;) thanks!  I should read the manpage as soon as I have time ^^
<LeiraHua> hi, everyone~
<LeiraHua> i wanna setup a bzr server for several of my firends
<LeiraHua> i am trying to use sftp
<LeiraHua> but i thing i don't quite understand, is the user access of sftp~
<LeiraHua> i have sftp enable by default on my ubuntu box~  but each user can access there own home dir~
<LeiraHua> even i can create a public dir which can be written by all these users, the files they create there are belong to themselves, which seems not so proper
<LeiraHua> i think the bzr repo such as sftp://host/bzr, under this dir, all the files submitted by different users should have the same owner~ isn't it?
<schierbeck> jelmer: awesome!
<schierbeck> i'll take a look right away
<LeiraHua> how can i setup an sftp bzr server, that all users use different user/passwd to login, but the files submitted on the server will have the same owner?
<matthewlmcclure> jelmer, I opened a bug re: symlinks on Cygwin: https://bugs.launchpad.net/bzr/+bug/209281
<ubotu> Launchpad bug 209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,New]
<LeiraHua> hello?
<schierbeck> LeiraHua: i think that's an issue with the ftp server
<LeiraHua> schierbeck: well, seems so, but is there any hint?
<LeiraHua> i didn't find any howtos for this~
<schierbeck> LeiraHua: i'm sorry, but i haven't messed around that much with ftp and bzr
<LeiraHua> schierbeck: then how did you setup your bzr repo?
<schierbeck> LeiraHua: i generally use a smart server
<schierbeck> bzr serve
<LeiraHua> is it better?
<schierbeck> it's faster, yes
<schierbeck> and i think it's easier to set up
<ubotu> New bug: #209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,New] https://launchpad.net/bugs/209281
<schierbeck> jelmer: i think the text should be more elaborate in the sig tab. i'll take a look at it.
<LeiraHua> schierbeck: good, thank you, i will check how to setup it~
<LeiraHua> schierbeck: BTW, besides the Bazaar User Guide, it there any other docs for smart server setup? any hint?
<schierbeck> LeiraHua: try googling, i vaguely remember reading some tutorials
<LeiraHua> schierbeck: thx~ googling~
<LeiraHua> schierbeck: i am still confusing, i've just read the smart server part of Bazaar User Guide. Smart server is invoked over ssh, from inetd, or in a dedicated mode. ssh which i can understand, but every is back to the start point, which i asked at first, that how to share the access control. but for the inet/dedicated mode, how can i control the access?
<LeiraHua> schierbeck: how did you setup the smart server?
<ubotu> New bug: #209299 in bzr "TestLongLogFormatter.test_author_in_log" [Undecided,New] https://launchpad.net/bugs/209299
<asabil> LeiraHua: I am not sure you can handle the access controle using inetd
<LeiraHua> asabil: dose it mean, every one can access this bzr repo without any passwd?
<LeiraHua> i just tested with the dedicated mode, seems so~
<asabil> yep
<asabil> the only to have access control is through ssh
<asabil> or using a dummy transport like sftp/rsync
<asabil> LeiraHua: if you have a team, you can create a folder with a sticky bit on it
<asabil> and put your branches there
<asabil> and make the team part of the same group
<LeiraHua> sticky bit~
<LeiraHua> just recall that~  thank you asabil~
<jelmer> schierbeck: cool, thanks
<LeiraHua> asabil: if i add a sticky bit on this dir, dosen't it mean that the files in this dir can be removed and renamed only by its owner? then how can i let my team members to rename files in branch?
<LeiraHua> asabil: shouldn't i set guid on this dir, that make sure all the files in this dir share the same group?
<asabil> yep
<LeiraHua> yep for guid?
<asabil> yep
<asabil> s/sticky bit/set guid/
<asabil> I always confuse the name
<asabil> LeiraHua: I meant the set gid bit, not the sticky bit sorry
<LeiraHua> well, i just tested this sguid, the problem is when i use "bzr init" to create a branch, the newly created branch dir has "drwxr-sr-x" permmision
<LeiraHua> so only the creator can commit files
<asabil> chmod -R g+w
<LeiraHua> do i have to do this on server side every time manually after each time branch create?
<LeiraHua> asabil: can i ask a direct question? how did you setup your repo?
<LeiraHua> i just want to learn some good practice, i find it's really hard to find any complete howtos for bzr hosting~
<asabil> LeiraHua: I did it a long time ago so I don't really remember (and I have no longuer the access to those repositories)
<asabil> but iirc, I had a /srv/bzr/projectX
<asabil> and /srv/bzr/projectX/trunk
<asabil> and /srv/bzr/projectX/branches
<asabil> /srv/bzr/projectX is a repository with the set gid bit set
<asabil> I created a group named projectX
<asabil> and added the users to it
<asabil> each user had a ~/public/bzr/projectX/ repository
<asabil> that allows the users to have private branches with back ups
<LeiraHua> can they submit changes into the main branch?
<ubotu> New bug: #209328 in bzr-gtk ".olive.conf should be moved to $XDG_CONFIG_HOME/olive/" [Low,Confirmed] https://launchpad.net/bugs/209328
<ubotu> New bug: #209332 in bzr-gtk "Use colours to highlight different statuses" [Low,Confirmed] https://launchpad.net/bugs/209332
<hajs> Hi! On https://lists.ubuntu.com/archives/bazaar/2007q1/021660.html there was a discussion about re-editing commit messages. Is this possible now?
<Pilky> hajs: from what I understand, you can uncommit something and then re-commit it with a new message
<hajs> Pilky: Thanks for the hint. Unfortunately it only works with the last revision. Sometimes I find typos in changelogs and it would have been great if I could correct them.
<beuno> jelmer: ping
<jelmer> beuno: pong
<beuno> jelmer: I'm working on the nautilus tweak you requested
<beuno> do you want me to leave the global disable
<beuno> or move it into a per-branch basis?
<jelmer> beuno: The global disable should come for free if you add the per-branch one
<jelmer> I think
<beuno> jelmer: what do you mean?  It has to be done differently, even on a UI level
<jelmer> beuno: I mean, the option can be set in ~/.bazaar/bazaar.conf to be global and then Branch.get_config().get_user_option("disable-nautilus-bzr") should Do The Right Thing
<jelmer> at a UI level the global disable could set GlobalConfig().set_user_option("disable-nautilus-bzr") and the per-branch one could call Branch.get_Config().set_user_option("disable-nautilus-bzr")
<beuno> jelmer: right, I'll get to work then
<beuno> thanks  :(
<beuno> er
<beuno> :)
<jelmer> :-
<jelmer> )
<jelmer> (-:
<beuno>  /me is dizzy now
<asabil> are there any plans/ideas about how to make bzr-svn faster ?
<jelmer> asabil: are you running 0.4.9 ?
<asabil> nop 0.4.7
<jelmer> asabil: 0.4.9 is significantly faster
<jelmer> asabil: The memory leak fixes for python-subversion (present in Ubuntu hardy / Debian sid) also help
<asabil> okidoki
<xma> hello
<xma> is aaron here ?
<jelmer> his nick is abentley
<jelmer> not sure if he's awake
<xma> ok thank you
<lifeless> hi
<lifeless> abentley is probably awake at this time
<xma> is he the admin of BB ?
<lifeless> yup
<lifeless> he runs the bzr BB
<xma> k
<igc> morning
<bob2> hm, the "trying to use bzr+ssh but bzr isn't in the remote path" error has become the rather scary 'bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x896f22c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.'
<spiv> bob2: in bzr.dev?
<bob2> yeah
<spiv> bob2: can you file a bug?  That's a pretty serious regression.
<bob2> hm, gives the same error as #125784
<spiv> bob2: that bug has two different errors; the one in the original report was an interrupted connection, at least one of the comments is an errors like yours, where a smart connection could not be established.
<spiv> Probably there should be two bug reports, if only because it's easier to combine bugs (via marking one as a dupe) than it is to split them.
<poolie> good morning
<lifeless> hi
<bob2> surreal, it only gives the scary traceback if you pass a url to 'pull'
<bob2> even if it's the parent from 'info'
<thumper> is there a bzrtools update coming soon to work with bzr 1.3 in the PPA?
#bzr 2009-03-23
<ronny> lifeless: aware of a simple way for automated installs of different bzr versions?
<lifeless> bzr branch?
<ronny> (im trying to refactor anyvc's tests to check multiple versions of the different vcs's if possible)
<lifeless> ronny: just don't install bzr, if you are using bzrlib, set PYTHONPATH, if you are running the command line, just run the bzr in the source tree
<ronny> hmk
<lifeless> rationale - bzrlib isn't versioned, short of lots-of-magic-with-eggs, you can't have more than one installed at a time
<jelmer> igc: hi
<igc> hi jelmer
<jelmer> igc: You mentioned on the list you're working on a patch to support custom rules
<igc> jelmer: just about to. See http://comments.gmane.org/gmane.comp.version-control.bazaar-ng.general/51347
<igc> jelmer: let me know if that sounds ok to you
<jelmer> igc: I like the flexibility
<jelmer> igc: though it also means local configuration is *always* required when using keywords/eol-conversions
<jelmer> igc: and this doesn't e.g. allow for use of rules set in svn
<igc> jelmer: can you explain further?
<lifeless> igc: How do filters interact with diff -r x..y?
<igc> jelmer: I was hoping we could ...
<igc> do something like "rules_location = svn:..."
<igc> lifeless: diff should apply to the canonical text, not the text in the working tree
<jelmer> igc: ah, hmm
<jelmer> igc: that seems like overkill though, as you would set that to the same location you've just checked out
<igc> external diff tools are an issue though
<lifeless> igc: ok; I was just considering the case of dealing with versioned files
<jelmer> igc: and that would require on-line access to the svn repo
<lifeless> versioned rules
<lifeless> I'm still extremely nervous about them, I don't think its thought out enough
<jelmer> IMHO ideally rules should be a per-tree versioned setting, while not being part of that tree itself.
<jelmer> and access to them abstracted away
<lifeless> jelmer: my concerns are about things like 'merge' when the rules change
<lifeless> do we read via old rules and write via new correctly? and what if they conflict
<jelmer> (that's non-trivial to achieve though, so I understand we should support look at other solutions in the short term)
<jelmer> s/support//
<lifeless> or pull, as a simpler case to analyse
<lifeless> igc: I'm really glad the core filter support has landed
<igc> jelmer: my immediate concern is to support something better than "just global" rules
<igc> lifeless: thanks
<jelmer> igc: Yes, I agree
<igc> jelmer: while allowing you ...
<igc> to do something smarter when you can
<jelmer> igc: so, the main thing I'm worried about is if we introduce things now that will prevent the utopian situation I mentioned earlier from happening
<jelmer> igc: putting a magic .bzrrules file in the tree would make it very hard to get to that situation at some point
<jelmer> igc: Your current proposal doesn't appear to
<igc> jelmer: I feel the rules_location setting solves many problems. It's a technical solution that still needs good guidelines around it, of course
<igc> jelmer: but I'm convinced that we just can't answer everyone's desires here
<jelmer> igc: Sure, I understand. I think the current proposal is reasonable
<lifeless> I like the concept that bzr won't magically handle the versioned file in the tree before we are ready to do that
<igc> lifeless: me too
<igc> jelmer: are there tweaks to my proposal that would help you?
<igc> jelmer: btw, there's no default - if rules_location isn't set, then just global rules apply
<igc> jelmer: importantly though, rules_location can be set in locations.conf and re-used across a bunch of branches
<jelmer> igc: No, I don't think there's much that can be done to support bzr-svn other than moving to per-tree (but not in-tree) rules
<jelmer> igc: My main worry was your proposal would add a in-tree .bzrrules with a magic meaning (much like .bzrignore), since that would pretty much prevent moving to per-tree rules in the future
<igc> jelmer: so perhaps tree.conf is what you want?
<igc> jelmer: there will be no magic .bzrrules file, though some projects may decide to put their rules in such a file and set rules_locations to pint to it, of course. *But* it's just a path - it could be called anything and put anywhere
<igc> s/pint/point/
<jelmer> igc: For svn, the rules would have to be a property of a Tree object, including RevisionTree objects
<igc> jelmer: my expectation is that many people (e.g. me) will put rules in the shared-repo directory, i.e. above the branch directories
<igc> jelmer: from memory, the API for looking up rules is on Tree, because rules are path dependent
<jelmer> igc: But they're not stored as part of a Tree atm
<jelmer> bzr-svn can import rules for historic svn revisions, but it isn't involved for the working tree
<lifeless> igc: please make info [-v?] print out the rules config
<igc> jelmer: right
<igc> lifeless: shall do
<lifeless> I just mean the value of the pointer, not all the rules - just thinking fordebugging with users
<igc> lifeless: yes, that's what I thought you meant
<lifeless> :)
<lifeless> james_w: ping
<jelmer> igc: anyway, even if we can't import rules from svn yet, we can support svn keywords now (-: Thanks!
<igc> jelmer: well, keeping in mind that our keywords aren't a one-for-one match with svn's ones, yes
<jelmer> igc: Yeah, but filters should allow the bzr-svn plugin to provide a svn-keywords Contentfilter that does
<igc> jelmer: absolutely true!
<jelmer> igc: (I didn't mean to come across as negative wrt filters btw, I like how they're shaping up so far)
 * jelmer gets some sleep
<igc> night jelmer, and thanks for the input/feedback - much appreciated
<james_w> hi lifeless
<lifeless> james_w: can you pastebin your hackjob, or something
<james_w> http://paste.ubuntu.com/135726/
<lifeless> james_w: how did it perform
<james_w> I've no idea
<james_w> I was just running the testsuite and looking at the failures
<bignose> bzr branch foo/ bar/ && bzr loomify bar/
<bignose> cd bar/ && bzr create-thread spam && hack hack hack && bzr commit
<bignose> What now needs to be done so that I can get changes from bar/ to foo/ such that foo/ doesn't need the loom plugin?
<bignose> if I generate a patch bundle from bar/ at the above point, will that patch bundle have problems in foo/ (which has no loom plugin)?
<lifeless> bignose: bzr switch spam && bzr push foo/
<bignose> okay. so the revision data won't depend on the loom plugin?
<bignose> in particular, can I make a patch bundle from bar/ and give it to the owner of foo/ who doesn't use looms?
<lifeless> yes
<bignose> thanks.
<bignose> if I want to avoid surprises for the owner of foo/, are there any actions I should avoid so they don't get messages about incompatibilities caused by the loom?
<lifeless> nope
<lifeless> the loom won't pollute an existing branch
<bignose> great, thank you.
<lifeless> if you push to a new url, you'll get a new loom, if you push to an existing branch, it pushes the current thread of the loom to that branch
<mwhudson> jelmer: are you around, by any chance?
<lifeless> if you 'bzr send' it does the normal thing, of getting the revisions from the target branch common ancestor through to the current tip
<lifeless> with loom, I often do 'bzr send -r thread:..-1' to get a cherrypick of the current thread only
<bignose> doesn't âbzr send -r thread:â do the same thing? (i.e. I thought the end-of-range defaulted to the tip)
<mwhudson> er
<lifeless> bignose: Please use ascii quotes, or I can' read it
<bignose> nnnggg
 * bignose curses IRC for not preserving character encoding information
<mwhudson> why does the main branch of dulwich now have revision ids that look like bzr-git revids?
<lifeless> mwhudson: jelmer has gone to sleep, I don't know the answer :P
<bignose> mwhudson: could be because someone used git as a branch-sanitise tool?
<lifeless> bignose: oh, its at my end, its not IRC per se, but still :(
<bignose> lifeless: it's still IRC that doesn't carry the information :-(
<lifeless> anyhow, you'll need to say again, s..> t Ã¡ d<... wasn't helpful for me
<bignose> doesn't 'bzr send -r thread:' do the same thing? (i.e. I thought the end-of-range defaulted to the tip)
<lifeless> unfortunately different commands behave differently
<lifeless> this has been discussed and is not resolved
<SamB> bignose: what do you mean, "preserving"?
<SamB> bignose: are you proposing that each message should have a Charset: header?
<bignose> SamB: I'm proposing that a text medium should declare the encoding of its content, yes.
<SamB> now, having "use UTF-8" in the RFC would be nice, I admit ;-)
 * emmajane waves
<ub3rst4r> hi, does anyone know how i can have my launchpad bzr code mirrored onto sourceforge?
<lifeless> ub3rst4r: well you can probably just push there
<lifeless> I don't know much/anything about the sourceforge bzr support; it would be nice if the sourceforge folk were to hang out here :)
 * igc lunch
<lifeless> kfogel: ping
<poolie> hi all
 * emmajane waves to poolie 
<emmajane> but then opts for sleep.
<poolie> hi there
<poolie> koalas soon i promise
<emmajane> YAY!
<poolie> i had some apparent jaunty usb failures
<poolie> but i have them downloaded now :)
<emmajane> poolie, stupid ubuntu. ;)
<poolie> heh
<poolie> apparently koala photos will be better supported next time
<emmajane> gettin' between me and koala pictures!
 * emmajane chuckles.
<emmajane> aight. sleep time!
 * emmajane waves
<lifeless> lunching
<awmcclain> What's the command to get the revision number of the working revision? (NOT the revisions at head like revno gives)
<spiv> awmcclain: I'm not sure what you mean by "the working revision" if not head?  Oh, is this a checkout?
<awmcclain> spiv: Yes.
<spiv> Hmm, I'm not sure if there is a command that does that.
<awmcclain> Really?
<awmcclain> Ug.
<spiv> There certainly should be...
 * awmcclain cries
 * AfC freely admits he doesn't have a clue what is being probed here.
<spiv> awmcclain: FWIW, the code to get that revision number would be something like from bzrlib.bzrdir import BzrDir; tree = BzrDir.open('.').open_workingtree(); revid = tree.get_parent_ids()[0]; print tree.branch.revision_id_to_revno(revid)
<lifeless> awmcclain: bzr log --show-ids -r -5.. | grep -C `bzr revision-info`, or something like that
<spiv> lifeless: ooh, tricksy.
<lifeless> :>
<lifeless> spiv: I'm assuming no meetup today; I'm nearly done with commit, so will either be tackling one of the interesting network bits, or <dunno> tomorrow
<spiv> Hmm, actually, I think log still uses the tip from branch rather than the tree?
<lifeless> yes
<spiv> We really should have a tree: revspec or something.
<lifeless> eys
<spm> not sure if I'd class this as a bug, per-se, but was a tad unexpected: Have a .bzr dir that is chmod 750 (some of the files controlled are sensitive). did a bzr upgrade and wound up with backup.bzr being 755. Strictly that was also the umask (0022), but my gut feel is the right thing would be to maintain permissions. ???
<lifeless> spm: if you want it fixed, file a bug :)
<spm> lifeless: heh. yes. I nearly did, but thought I'd canvass opinion first. :-)
<poolie> i'd agree it's a bug
<kfogel> lifeless: pong
<lifeless> so David Reitter is someone in the emacs community?
<BasicOSX> lifeless:  bug 305006 I haven't release 1.13.1 how did Dorin get it to report the bug? Any idea?
<ubottu> Launchpad bug 305006 in bzr "shelve fails on win32 with "Could not acquire lock"" [Undecided,Fix committed] https://launchpad.net/bugs/305006
<BasicOSX> nm, except for the doc changes it's in lp
<kfogel> lifeless: the name doesn't ring a bell, actually
<lifeless> BasicOSX: I think they mean 1.13rc1
<lifeless> BasicOSX: which doesn't have all of 1.13.0 :P
<lifeless> kfogel: oh, well he's playing with emacs and filing a cluster of bugs
<BasicOSX> :-(
<lifeless> some of which are flailing-new-user stuff and some are good
<lifeless> I was hoping someone in the same TZ and community could lend a hand
<kfogel> lifeless: filing launchpad bugs or bzr bugs?
<lifeless> bzr bugs
<lifeless> ciao for the day
<poolie> night lifeless
<vila> hi all
 * igc dinner
<poolie> hello vila
<BasicOSX> bug 347130
<ubottu> Launchpad bug 347130 in bzr "test_msgeditor.MsgEditorTest.test__run_editor_EACCES breaks noninteractive test suite" [Undecided,New] https://launchpad.net/bugs/347130
<BasicOSX> poolie:  that's bug that breaks non-interactive test suite, looks to be related to another bug on how the VISUAL vs EDITOR is choosen
<poolie> BasicOSX: thanks
<poolie> interesting
<poolie> so it fails when VISUAL is set and EDITOR is unset?
<BasicOSX> I had other words, but interesting fit it too
<poolie> :)
<BasicOSX> yes
<BasicOSX> if EDITOR is set and VISUAL unset we are ok
<BasicOSX> I keep typing bzr-get update bzr, apt, sheesh
<vila> BasicOSX: :)
<poolie> ok
<poolie> relatively early night for me
<poolie> BasicOSX: bug 347130 is probably pretty easy but if it will still take a little while
<ubottu> Launchpad bug 347130 in bzr "test_msgeditor.MsgEditorTest.test__run_editor_EACCES breaks noninteractive test suite" [Undecided,New] https://launchpad.net/bugs/347130
<poolie> so i'm not going to do it right now
<poolie> thanks for filing it though
<BasicOSX> poolie:  np, unset VISUAL and I'm good
<BasicOSX> I'm adding notes to bzr.dev releasing so I don't forget
<jelmer> mwhudson: hi
<gmarselis> hi
<gmarselis> i'm getting these wierd ssh auth failures on the 6th minute of the hour
<gmarselis> and only then
<gmarselis> http://rafb.net/p/GprFbL61.html
<gmarselis> i can't wrap my mind around it to find a starting point
<gmarselis> halp!
<gmarselis> guess everybody's asleep
<apw> does bzr in jaunty now do notifications?
<james_w> bzr-gtk does
<jdobrien> I would like to show the history of a file that has only had renames and no content changes, how can i do this with bzr?
<SamB> did you try bzr log already?
<james_w> jdobrien: does "bzr log -v filename" do what you want?
<jdobrien> james_w: that works...thanks
<james_w> cool
<james_w> (the -v is just to show what changed (renames etc) it's slower, but it helps to make sure you know what you are getting)
<cammoblammo> Hmm, bzr seems to freeze when trying to pull the bzr repo:
<cammoblammo> It get stuck at [#|                  ] http >    508kB     4kB/s | Pull phase:Copying revision texts:Copied record 17/288
<cammoblammo> Is this my end, the server or something in the middle?
<Peng_> cammoblammo: I only have some guesses, but... http://bazaar-vcs.org/bzr/bzr.dev/? What version of bzr are you running? Got a proxy?
<cammoblammo> Peng_: Yes, that's the URL. I'm running 1.14dev, no proxy. Hmm, I seem to be having a similar issue with another project that uses bzr.
<cammoblammo> Ah well, it's bed time now. I'll try again in the morning, that magical time when bugs disappear and computing nirvana awaits.
<Peng_> cammoblammo: Good night. :)
<cammoblammo> :-)
<CBro2007_> am reading up on Bzr and I am very interested in the "Decentralized with human gatekeeper model"
<CBro2007_> was wondering if there were any examples of how to set this up?
<bob2> did you check out the user manual?
<CBro2007_> yeah did
<CBro2007_> can I run you through some of my doubts bob2
<CBro2007_> ? :)
<bob2> you can ask the channel, someone might know :)
<CBro2007_> ok you asked for it
<CBro2007_> so say I was the gatekeeper and I set up a repository and setup a TRUNK or Main Branch and multiple branches for each developer
<CBro2007_> now how do developers manage to update their own branches from a. The MAIN branch or b. Each other's branches directly?
<CBro2007_> and when they are done completing a feature that needs merging into the MAIN branch.. how do they submit a Merge request?
<bob2> they can merge from each other or the trunk
<bob2> best to stick with the trunk if possible
<bob2> they can send you a merge request or a url for you to merge from - the end result is pretty much the same
<CBro2007_> ok so you are saying I should make it a process to only allow features updated when they are in the main branch?
<CBro2007_> so developers cannot share code between each other's branches without going through the main branch and hence a merge request process?
<CBro2007_> is that correct bob2
<CBro2007_> ?
<bob2> they can, if they want
<bob2> it might make merging harder for you
<CBro2007_> ok I think I like the process where they submit their merges to the MAIN branch from which we can all UPDATE our branches
<CBro2007_> what about the "request to merge"?
<CBro2007_> Are you talking about them PUBLISHING their branches on Launchpad and then we can merge from there?
<CBro2007_> can they not send me an e-mail using that bzr send feature or something?
<CBro2007_> just wondering what is the better option?
<bob2> no, I'm not
<CBro2007_> ok what you saying then ? :)
<bob2> they can send you a merge request (with bzr send), or they can just send you a url to pull from
<bob2> I guess they could send you a lp url, if you're using lp
<CBro2007_> we are all working on the same machine
<CBro2007_> but different UNIX accounts
<CBro2007_> so I can really merge between branches locally
<bob2> that's just a particularily boring url then :)
<CBro2007_> what do u mean?
<CBro2007_> Bundle Buggy was mentioned in that model to help review the changes etc
<bob2> nevermind
<CBro2007_> I was thinking when a developer is ready he might send me this e-mail that shows all his changes etc... and I can code review it before I merge it into our MAIN branch
<bob2> sure
<CBro2007_> yeah but how does bzr help me do this?
<CBro2007_> Can you give me an idea?
<bob2> I don't know what you mean
<bob2> the developer can send you an email, telling you which branch they would like you to merge
<bob2> you merge it, run the tests, look at the diff, then commit it if you're happy
<bob2> you can use bundlebuddy to help with that stage, if you like, but it's not essential
<CBro2007_> Hmmm
<CBro2007_> bundlebuddy helps in which stage sorry - merge, diff or test ?
<CBro2007_> dont you think I should do a diff before I perform a merge?
<bob2> keeping track of merge requests
<CBro2007_> :)
<bob2> of course you should
<bob2> 'bzr merge' just changes your working copy
<bob2> the merge is not commited until you commit
<CBro2007_> ok and the bzr merge command is issues in the TARGET branch you want to merge into yeah?
<bob2> yes
<bob2> bzr help merge
<CBro2007_> I suppose I got to look at the merge command
<CBro2007_> hahah yeah
<CBro2007_> I think I will setup a dummy project and test all these scenarios out on them
<CBro2007_> oh and one more thing... say I just merged a developer's branch into the TRUNK or MAIN branch... and want to update my branch with his changes... is that another merge from my branch?
<CBro2007_> wondering if my own changes that I am working on will get affected in this situation?
<CBro2007_> and how BZR deals with conflict resolutions?
<bob2> if YOURBRANCH was up to date with TRUNK before you merged SOMEONEELSESBRANCH into TRUNK, then you can jus do a 'bzr pull' in YOURBRANCH to bring it up to date
<bob2> it drops conflict markers in the files, and leaves the this, other (and sometimes base) versions for you to merge manually
<CBro2007_> ok
<CBro2007_> man have to play around with it now.
<CBro2007_> :)
<CBro2007_> cheers bob2
<CBro2007_> thanks
<bob2> no worries
<CBro2007_> bob2: last one :)
<CBro2007_> should I be creating ONE repository or multiple repositories with one for each developer?
<CBro2007_> which one is a better model you reckon?
<bob2> depends
<CBro2007_> I was initially thinking... one repository - multiple projects - each project with multiple branches
<bob2> you can't (easily) do access control within a repository
<CBro2007_> ok
<CBro2007_> so if I wanted to be the only one who could COMMIT changes to the MAIN branch.. is that just with UNIX permissions?
<CBro2007_> or is there a way of doing it in bzr?
<CBro2007_> setting up some sort of roles in bzr
<bob2> unix permissions
<bob2> but as above
<CBro2007_> k
<bob2> I'm sure there's some addon to do something fancier
<CBro2007_> so u think its better to have separate repositories for each developer and then one for MAIN repository holding the GOLD copy for the project?
<CBro2007_> that make sense?
<Peng_> The point of a shared repository is to prevent disk space from being wasted when you have multiple branches of a project. You should use one repo per project, unless you need more for access control.
<Peng_> (In that case, if everyone has bzr 1.6 or newer, using stacked branches will help.)
<CBro2007_> Peng: so now if I have a single repository then how do I implement access control?
<CBro2007_> how do I stop other developers to have READ ONLY access to the MAIN branch?
<CBro2007_> so they cannot COMMIT their changes directly without a review process
<bob2> just use single branches
<bob2> and no repository
<CBro2007_> I thought I always have to setup a repository ?
<bob2> no
<CBro2007_> so bob2 ... are you saying I just setup directories in their account homes where I can do a bzr init and then bzr branch?
<CBro2007_> so there is no need for a repository
<bob2> yes
<bob2> well, you'll do init once
<bob2> then branch all the rest from that
<CBro2007_> you think it would be a good idea to just create a different UNIX user for the MAIN branch?
<CBro2007_> say something like bzruser
<CBro2007_> :)
<bob2> no
<CBro2007_> ok
<CBro2007_> just wondering what will happen when I merge the developer's files to this main repository... it would have their owner names on it ?
<bob2> you could, but it seems like overengineering to begin with
<bob2> you mean branch, not repository, I think
<bob2> yes
<bob2> I think you should just have a go
<bob2> make a simple branch, then make some other branches from it and try merging, and using 'bzr log'
<CBro2007_> yeah... its just the access control that I am worried about to be honest
<bob2> why?  it's simple
<CBro2007_> I am worried that after merging the file might have the developer's ownership.. say I ADDED new files from his branch to MAIN... then I am pretty sure he can anytime go straight to the MAIN branch and modify stuff
<bob2> no
<CBro2007_> k let me test it out... will let you know if I have any dramas then
<persia> Good day.  I've a directory that contains a heap of branches.  I'm curious if there's a handy way to query the default pull location for each of these all-at-once, rather than checking individually.
<Peng_> persia: You mean from the shell or what? I'd probably just use something evil with find and grep on .bzr/branch/branch.conf (.bzr/branch/parent on really old branches), or hack something together with bzrlib.
<persia> Peng, From the shell would be ideal.  I was just about to hack something up with for and grep, but thought I'd ask to see if someone else already wrote a plugin first :)
<Peng_> Ah.
<persia> Peng, Thanks anyway.  `for i in */.bzr/branch/branch.conf; do echo -n $i:; grep push_location $i; done | grep 7Epersia` does what I wanted :)
<jam> vila: good morning
 * persia decides `for i in */.bzr/branch/branch.conf; do grep push_location $i > /dev/null && echo $i | cut -d/ -f1; done` is even more useful, and wanders off, happy.
<jam> igc: just a quick check if you are still around. I was going to work on iteritems if nothing else came up, but I wanted to make sure you had not done it
<vila> jam: Hi jamm quick call ?
<jam> hey vila, give me ~5 minutes, but yeah
<vila> ok
<jam> vila: I'm ready for my phone call, Mr. Ladeuil
<jam> :)
<vila> Was grabbing the phone already :)
<hunmonk> does anybody know if bzr 1.6 and 1.9 are compatible?  i have a repo that i'm needing to move back and forth from two machines that have those versions installed...
<Peng_> hunmonk: Bazaar is more or less always compatible. Just use disk formats that both versions support (i.e. not 1.9).
<CBro2007_> guys if someone sent me a request to merge their changes for a certain rev no... would I be able to do a diff and check my trunk vs the rev no commit copy in their local branch?
<CBro2007_> or should I first do the merge for the revno they supply and then do a diff before I commit to trunk?
<CBro2007_> Peng: any suggestions as to what is the better approach?
<Peng_> CBro2007_: I'm not fully awake and don't understand what you said. :P
<CBro2007_> great
<CBro2007_> :)
<CBro2007_> say I am the gatekeeper for the trunk copy or MAIN branch
<CBro2007_> you are a developer who just completed a feature
<CBro2007_> you want me to MERGE a given rev no from your branch... not the latest one
<CBro2007_> do I first do a DIFF to see what is being merged ?
<CBro2007_> Or do I first merge it and then do a Diff later?
<Peng_> CBro2007_: I'd do the latter. You can always "bzr revert" if you don't like it.
<CBro2007_> so bzr revert goes ahead and removed the merge?
<CBro2007_> or reverts to the last committed copy?
<Peng_> Um.
<CBro2007_> Um?
<CBro2007_> :)
<CBro2007_> I suppose if I first do a merge then there will be nothing to diff against?
<CBro2007_> or I can probably diff against the LATEST COMMITTED branch
<Peng_> "bzr revert" reverts any uncommitted changes, including uncommitted merges.
<CBro2007_> copy
<CBro2007_> hmmm
<Peng_> FYI, you can do "bzr merge --preview" to show what doing a merge would do.
<CBro2007_> ah thats helpful
<CBro2007_> ok cool
<CBro2007_> thanks
<Peng_> Like I said, I would personally do "bzr merge" first, diff, fix conflicts, etc., and commit, or "bzr revert" if I don't like it, but you should do whatever works for you.
<CBro2007_> how do conflicts show?
<CBro2007_> does it come up in the merge command?
<Peng_> "bzr merge" will yell at you, and put conflict markers in the files, and create .{THIS,OTHER,BASE} files. "bzr status" will show it as well.
<CBro2007_> ok
<CBro2007_> thanks
<Peng_> Try it and see. :D
<CBro2007_> don't think that should be the case most of the times as we will be hopefully working on different features
<CBro2007_> but you never know
<Peng_> CBro2007_: Bazaar will also refuse to commit conflicted files.
<Peng_> So it's really hard to miss. :P
<CBro2007_> will try and commit the copies in trunk before any merges etc
<CBro2007_> Hey Peng_
<CBro2007_> I tried this.... I added a new file from the developer's branch and did a bzr add then commit
<CBro2007_> then from the trunk I went :
<CBro2007_> bzr merge  -r 6 /home/dev/dcrepo/ --preview
<CBro2007_> I don't see the NEW file in my working directory after this merge
<CBro2007_> do you know why that is?
<CBro2007_> I am trying to get a certain revision number from his branch.... as he has done more commits AFTER rev 6
<CBro2007_> anyone got any ideas why merge doesn't work here?
<Peng_> CBro2007_: "merge --preview" doesn't change your working tree. It's just a preview.
<CBro2007_> yeah just realized that now
<CBro2007_> :)
<CBro2007_> sorry
<Peng_> Okay.
<CBro2007_> thought it does the merge + gives a preview
<CBro2007_> Peng_: I also noticed that you have to ADD new files with bzr add
<CBro2007_> so then i am thinking I will have to make it a rule that developers check bzr status
<CBro2007_> and then do adds etc
<Peng_> Checking bzr status and bzr diff before committing is always a good idea.
<CBro2007_> yep
<CBro2007_> Peng_: If developers wanted to UPDATE their sandboxes or branch with the TRUNK copy how would they go about doing that?
<CBro2007_> with the Merge again?
<Peng_> CBro2007_: Yeah.
<CBro2007_> whats the PULL option there for?
<CBro2007_> would that be something they should be using?
<Peng_> Erm.
<CBro2007_> or just the normal merge?
<Peng_> "Merge" is there to merge changes from another branch into your branch. "Pull" is there to update your copy of another branch.
<CBro2007_> I am not sure I understand the --pull option
<CBro2007_> is pull a seperate command?
<CBro2007_> because the local branches are really copies of the TRUNK branch
<Peng_> There's a "bzr pull" command and a "--pull" option to the merge command.
<aelkner> does anyone know how to find out what version of a branch is actually installed on a machine?
<aelkner> when i do bzr revno or bzr log, it shows me what's in the repository
<aelkner> but i haven't, nor do i want to at this time, done a bzr up
<aelkner> but it want to figure out which version of the code is actually there
<aelkner> does anyone know how i can determine that?
<exarkun> 'bzr version-info'?
<aelkner> that worked, thanks
<aelkner> what's the intention with the difference between revno and version-info?
<Kinnison> mmm interesting. I never knew of that particular difference
 * Kinnison ponders integrating that into his prompt
<aelkner> is there a version of bzr log that takes into account the currently loaded revision number?
<aelkner> ir do i need to do bzr log -r 'revision number returned from bzr version-info'
<exarkun> bzr log -r `bzr version-info --custom --template="{revno}"` maybe
<aelkner> that seems hostel to the user, doesn't it?
<aelkner> i mean, shouldn't the commands work against what is actually on the machine?
<aelkner> rather than what's in the repository?
<Kinnison> revno talks about the branch
<Kinnison> Where version-info talks about the working tree
<aelkner> but bzr log only talks about the branch
<aelkner> wouldn't it be nice to have one that talks about the working tree?
<Kinnison> Given you can know the version numbers you care about, what are you trying to achieve?
<aelkner> it's not that i can't achieve what it need, using the version-info command to get the revision number
<aelkner> it's just that it would be great if there was a command that gave you what bzr log gives you
<aelkner> but only up to the revision number that the working tree has
<Kinnison> Oh I see
<Kinnison> wtlog () { bzr log -r1..$(bzr version-info --custom --template="{revno}") "$@"; }
<Kinnison> something like that?
<aelkner> i'm not sure what you mean by that
<aelkner> i know that's a shell script
<aelkner> but i don't know how you mean that it would be used
<aelkner> if one is at a command prompt
<Kinnison> oh it creates a shell function "wtlog" which when called, automatically gives bzr log the right -r1..blah to only give you the log for the working tree
<aelkner> issuing the command bzr log --working_tree would be nice to be able to do
<Peng_> Better would be a revision spec, so you could do e.g. "bzr log -r tree:".
<aelkner> it just seems unfortunate that the default commands would tell the user about the repository and not the working tree
<Peng_> aelkner: The branch, not the repository.
<aelkner> sorry, true enough
<aelkner> s/repository/branch for my previous comment
<aelkner> if one want to know about the branch and not the working tree, i could see forcing them to supply the branch url
<aelkner> but then again, others may find that to be a hassle
<aelkner> so i guess it's a trade-off
<aelkner> Peng_: i sinned and failed to mention that i was dealing with a light checkout and not a branch
<aelkner> with branches, bzr revno and log DO show the version that's on the machine
<aelkner> and not what
<aelkner> and not in the branch in the repository
<Peng_> They always show the branch tip. It's just that with lightweight checkouts, the branch tip and the current revision of the working tree are often different.
<Peng_> They can be in regular branches though.
<bitmonk> howdy, i'm trying to branch via bzr+ssh protocol, with bzr 1.6.1 at both ends, and i get an error regarding rich-root support, because 'bzr branch' seems to be creating a KnitPack.  what can i do to avoid this?
<bitmonk> there is a bug that the message could be clearer, but i'm not sure i need that fix to move on ;)
<Peng_> bitmonk: Are you trying to branch into a shared repository?
<bitmonk> Peng_: nope, just from one into a deployment location.
<Peng_> bitmonk: Well, you could create a rich-root repo and branch into it (e.g. "bzr init-repo --rich-root-pack"), or create a standalone rich-root branch and pull into it (e.g. "bzr init --rich-root-pack").
<Peng_> bitmonk: "bzr branch" should be less brain-damaged, of course. I don't know if it's been improved in more recent releases.
<bitmonk> yah i was thinking along those lines, i haven't seen this before, oddly.  i just created a new shared repo on the server and branched from another shared repo to start a new project based on another's code.  then, on dev server, tried to branch the new location right alongside a branch of the old.
<bitmonk> ah it just occur to me, i made the other branches from http and just push over ssh.
<bitmonk> thanks for help, maybe i will get some time and i can help test and improve further.
<Peng_> bitmonk: FWIW, as of current bzr.dev, "bzr branch" is smart enough to create a branch in the right format, at least locally.
<bitmonk> i'll try to find a place to test that, thanks, and look forward to a new stable release.
<bitmonk> seems to me it must be the protocol handler in this case, because i'm not running any kind of smart server, just straight apache access to the flat repo files.
<bitmonk> but, eh, i'm full of conjecture.
<mwhudson> jelmer: hello
<stianse_> I have installed two plugins that both override/decorate the commit command. But it seems like only one of the can be active.
<stianse_> Is it supported to have two plugins overriding the same command? How?
<stianse_> Both plugins use "commands.register_command(cmd_commit, decorate=True)"
<mtaylor> if I do this: bzr branch lp:drizzle/mordred  ... is there any reason it couldn't default to pulling over HTTP, or to falling back to http if ssh auth fails?
<mtaylor> I don't actually need ssh auth to work for that branch to succeed, after all
<Peng_> With how everything is structured, I bet that would be difficult to do.
<jelmer> mwhudson: you were looking for me yesterday?
<Peng_> Hmm, it would be neat if there was an "lp+http" URL scheme though.
<bitmonk> does lp have branches that require authentication to read?
<jam> bitmonk: yes
<LarstiQ> Peng_: hmm, does the lp directory service have any say in retrying?
<jam> bitmonk: they are called "private" branches, I know there are a couple projects that make use of them, though I think it is done on a per-project basis
<mwhudson> jelmer: still am :)
<mwhudson> jelmer: why does lp:dulwich have completely new, bzr-git-ish, history?
<mwhudson> LarstiQ: i don't think to, the directory service basically just gets the chance to turn one url into another
<mwhudson> aiui
<mwhudson> well, "url"
<LarstiQ> mwhudson: feh
<LarstiQ> mwhudson: although, since it isn't storing the unexpanded form right now, it doesn't matter too much
<jelmer> mwhudson: ah
<jelmer> mwhudson: it was dpushed into git
<jelmer> mwhudson: and so the revision ids changed as bzr-git doesn't do round-tripping yet
<mwhudson> jelmer: any particular reason?
<jelmer> mwhudson: for dpushing into git?
<mwhudson> yes
<jelmer> mwhudson: cooperation with the pyrite folks who are interested in using and hacking on dulwich rather than on their own homegrown code
<mwhudson> ah, ok
<mwhudson> jelmer: so i need to upgrade the version of bzr-git in launchpad's source code, because of the _lock_count thing in bzr 1.13
<mwhudson> jelmer: will bzr-git trunk, dulwich trunk and bzr 1.13 work together ok?
<jelmer> mwhudson: yeah
<jelmer> mwhudson: bzr-git trunk should support bzr.dev and 1.13 at the moment
<mwhudson> jelmer: ok
<mwhudson> thanks
<mwhudson> jelmer: i'll just have to smile sweetly at the OSAs to get them to run pull --overwrite a couple of times :)
<jelmer> mwhudson: whoops
<jelmer> mwhudson: sorry, I wasn't aware this was causing that much more work for you
<jelmer> mwhudson: at least it shouldn't happen again in the future
<mwhudson> jelmer: no worries
<LarstiQ> mwhudson: how are git import plans faring?
<mwhudson> jelmer: it's just a shame that i only noticed after you'd gone to bed last night
<mwhudson> LarstiQ: mostly wrangling dependencies :)
<LarstiQ> mwhudson: I see :)
<mwhudson> LarstiQ: the code to do the import is mostly written, there's some ui work
<mwhudson> but that shouldn't be hard
<mwhudson> so maybe it'll be done for the april rollout
<LarstiQ> cool
<jelmer> mwhudson: just curious, do you handle git branches specially or is it just like mirrorring a native Bazaar branch ?
<mwhudson> jelmer: nope, "pull"
<jelmer> ah, neat
<mwhudson> will do the same for bzr-svn sooner or later
<mwhudson> (probably we'll do something where new imports use bzr-svn and old ones continue to use cscvs)
<jelmer> mwhudson: ah, neat
<mwhudson> jelmer: how's bzr-svn 0.5 working?
<mwhudson> ^ out
 * LarstiQ needs to file a bug on bzr-svn, sigh
<LarstiQ> which means making a test repo to reproduce the bug we're seeing on a proprietary repo
<LarstiQ> jelmer: I'm not sighing about bzr-svn, honest! :)
<jelmer> LarstiQ: is this the bug we were debugging earlier?
<jelmer> mwhudson: 0.5 is working out pretty well
<LarstiQ> jelmer: nope!
<LarstiQ> jelmer: same project though
<LarstiQ> jelmer: but now it's push failing with an assert
<jelmer> mwhudson: I'm thinking of doing a 1.0 quite soon (perhaps together with 1.15)
<jelmer> LarstiQ: is there a bug open yet? I might be able to fix something based on the assertion..
<brink> I hate to ask, but is there a way to convert a bazaar repository to git?   I've tried the latest tailor, but it appears to be broken.
<luks> bzr fast-export | git fast-import ?
<mwhudson> jelmer: cool
<LarstiQ> jelmer: nafaik. I'll look through the bugs. (Of course, it's never me but always a colleague who triggers bugs)
<brink> luks:  Do you know where I can get the fast-export plugin?
<LarstiQ> brink: try bzr-git and hack on it if it doesn't meet your requirements? ;)
<brink> larstiQ: bzr-git would if it worked.  It crashes and burns too.
<LarstiQ> brink: http://bazaar-vcs.org/BzrPlugins in general, lp:bzr-fastimport in specific iirc
<newz2000> hi, I accidently added some files I didn't want to add. I haven't commited yet though, can I un-add them?
<jelmer> brink: any chance you can file a bug against bzr-git if you didn't get it to work?
<LarstiQ> newz2000: bzr rm (--keep or --force) the files in question
<newz2000> ah, thanks
<brink> jelmer:  Oops.  It was git-bzr that crashes and burns.  I haven't tried bzr-git.     Can bzr-git actually convert a bzr repo to a git repo?
<thumper> morning
<LarstiQ> there is a git-bzr?
<jelmer> brink: yeah, although it will only work for relatively small branches atm
<jelmer> brink: and you need a patch for bzr to push from bzr into git
<LarstiQ> Pieter: aha! :)
<Pieter> hmm?
<brink> jelmer:  So I just pull bzr-git and installed it.   But bazaar tells me it is unable to load git from the plugins directory.
<mwhudson> brink: you need bzr 1.13
<jelmer> brink: in particular for being able to push into git you need bzr.dev and my dpush patch posted to the list yesterday
<LarstiQ> Pieter: I wondered who that pieter of git-bzr was.
<Pieter> ah :)
<brink> jelmer:  I'm at version 1.2.   I'll update it.
<brink> jelmer:  bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev  give me an internal error.   That's after installing the latest bzr1.13.
 * LarstiQ blinks
<LarstiQ> brink: could you pastebin that?
<brink> jelmer: http://pastebin.com/m30ee2bd7
<LarstiQ> brink: ok, bzr-git shouldn't mess with other bzr invocations
<LarstiQ> brink: either install dulwich (which you'll need for git interaction later on) or disable the bzr-git plugin momentarily (usually accomplished by moving the plugin away)
 * jelmer back in ~40 min
<LarstiQ> brink: did that help?
<brink> LarstiQ:  I was able to download the latest development release by moving bzr-git and I installed Dulwich.   Not sure what to do next though.
<LarstiQ> brink: let me dig up jelmer's patch
<LarstiQ> brink: I suppose he meant http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49C6A5B7.1050105%40vernstok.nl%3E
<LarstiQ> brink: so, in bzr.dev: `bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C49C6A5B7.1050105@vernstok.nl%3E`
<LarstiQ> ok
<LarstiQ> brink: in case you missed it, 21:53:02 < LarstiQ> brink: so, in bzr.dev: `bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C49C6A5B7.1050105@vernstok.nl%3E`
<brink> LarstiQ:  It seems to have merged and installed successfully.   Do you know the command to try the conversion by any chance?
<LarstiQ> brink: `bzr dpush path/to/git/branch` I think
<LarstiQ> brink: but this guess isn't hindered by any actual experience with bzr-git ;)
<LarstiQ> hmm, that sentence works better in Dutch
<brink> LarstiQ:  It seems my version of Dulwich is too old.  http://pastebin.com/m3050c87f
<LarstiQ> hmm
<LarstiQ> brink: http://samba.org/~jelmer/dulwich/ doesn't list any later release
<brink> LarstiQ:  Can't say much about the dutch.  I only know how to ask for beer in Dutch.  But that sentence works pretty well in English.  I think I'll use it in the future.
<LarstiQ> brink: a useful skill too :)
<thumper> Hi people, I've got lots of this type of directory in /tmp bzr-limbo-dxujgp
<thumper> I am using some code for preview trees
<thumper> is bzr not cleaning up after itself?
<brink> LarstiQ: In most languages yes.  But I've never met a dutch bartender who didn't speak fluent English along with several other languages.
<LarstiQ> brink: we're bad like that, sorry :/
<LarstiQ> thumper: could be, limbo does indeed sound like TreeTransform, employed by preview trees afaik.
<brink> LarstiQ:  Well, it still seems polite to make the attempt in the local tongue even if it isn't necessary.
<james_w> thumper: your code may not be cleaning up the TreeTransform in all cases
<thumper> james_w: what do I need to do?
<LarstiQ> brink: I agree, and replying in a different language is something that makes language learning harder for me.
<thumper> james_w: the code is lp:mad
<james_w>     def finalize(self):
<james_w>         """Release the working tree lock, if held, clean up limbo dir.
<james_w>         This is required if apply has not been invoked, but can be invoked
<james_w>         even after apply.
<james_w>         """
<LarstiQ> brink: (I'm slowly learning Finnish, their English is also good enough usually)
<LarstiQ> brink: since you're running bzr.dev anyway, could you try a development version of dulwich?
<thumper> james_w: thanks, I'll add that to my bug report.
<james_w> aren't you the author? :-)
<thumper> yes
<thumper> james_w: but I'm not getting to it right now
<thumper> james_w: I have other things to do
<james_w> sure
<brink> LarstiQ:  I tried.  Bazaar failed with an internal error.   http://pastebin.com/m7e8d920a
 * LarstiQ investigats why the os module might not have fdatasync
<LarstiQ> brink: are you on !unix?
<LarstiQ> brink: ah, OSX
<LarstiQ> brink: this reminds me of a Firefox/sqlite thread on fsync
<LarstiQ> brink: so, `python -c 'import os; print os.fdatasync'` will fail if I'm right, does `python -c 'import os; print os.fsync'` work?
<jelmer> SamB: ping
<jelmer> SamB: you'll need a newer dulwich than the last release
<jelmer> s/samb/brink/
<jelmer> brink: this is all still very much alpha code
<LarstiQ> jelmer: he's got that
<LarstiQ> jelmer: but fdatasync does not exist on OSX
<jelmer> ah, yuck
<jelmer> does it have os.fsync() ?
<LarstiQ> jelmer: http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch03lev1sec13.html
<LarstiQ> jelmer: it does in C afaik. But it's behaviour is different.
<jelmer> LarstiQ:     All four of the platforms described in this book support sync and fsync. However, FreeBSD 5.2.1 and Mac OS X 10.3 do not support fdatasync.
<jelmer> LarstiQ: so I guess we should fall back to fsync if fdatasync is not available
<LarstiQ> jelmer: see http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/ for example
<LarstiQ> jelmer: yeah
<stianse_> trying one more time before asking on the mailing list: is it possible to have two plugins installed that decorate the commit command?
<LarstiQ> stianse_: yes, but could be tricky.
<brink> LarstiQ:  That is right.  It fails.  I'm on OS X.    I also have Linux boxes here too that I could try.
<stianse_> LarstiQ: Do you have a possible solution?
<LarstiQ> brink: for a short term workaround, that should give better results.
<stianse_> It's a shame if I have to choose one between several plugins that  I need
<LarstiQ> stianse_: is this a developer or user oriented question?
<LarstiQ> stianse_: for the former there has been discussion on the list that might be interesting
<stianse_> LarstiQ: I'm writing a new plugin
<stianse_> LarstiQ: Perhaps I should try to digg in the archive then. I've not subscribed but I guess I can find some archive on the web
<LarstiQ> stianse_: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/52239/match=decorate+plugin iirc
<LarstiQ> jelmer: boohoo, I get a different assert.
<stianse_> LarstiQ: Sorry, but I'm not sure if I fully understand. Does that link describe a proposal of changes in bzrlib or a way to solve the problem that works today?
<LarstiQ> stianse_: proposal of changes
<LarstiQ> stianse_: if you're adding something another plugin isn't also doing, then you should be good for now I think
<stianse_> I want to add a new option to the commit command. But I also have the interactive-plugin installed which also adds an option to that command.
<stianse_> That does not seems to work.
<jelmer> stianse_: the trick is that plugins that decorate don't simply import cmd_commit from bzrlib.builtins
<dash> is there a way to get bzr-svn to remember svn passwords?
<jelmer> dash: see the bzr-svn FAQ
<dash> gasp, a faq
<dash> i will do so. :)
<dash> hmm. the one at http://samba.org/~jelmer/bzr-svn/FAQ.html ?
<jelmer> dash: oh, I removed that from the FAQ, sorry
<jelmer> dash: so, basically, you can either make sure Subversion caches the password somehow
<bob2> haha
<jelmer> dash: and bzr-svn will then also use the password
<dash> right, ok
<jelmer> dash: or alternatively you should be able to use bzr's infrastructure for stored credentials
 * LarstiQ looks at his subvertpy bugreport
<poolie> hello LarstiQ, all
<LarstiQ> moin poolie :)
<poolie> what do you say in dutch?
<stianse_> jelmer: Sorry, some english problems:) Do you mean that a plugin should or should import bzrlib.builtins?
<stianse_> jelmer: because both plugins I look at now defines a cmd_commit class that inherits from builtins.cmd_commit
<LarstiQ> poolie: as a goodmorning greeting?
<stianse_> jelmer: both register with commands.register_command(cmd_commit, True)
<jelmer> stianse_: I mean how they retrieve the original class they use as base class
<stianse_> jelmer: but only one of the plugins are in effect
<jelmer> stianse_: what do you mean with "in effect" ?
<stianse_> jelmer: I'll explain: the interactive plugin adds the option "-i" to the commit command.
<stianse_> jelmer: The bzr-text-checker adds the option "--text-checker-warn-only" to the commit command.
<stianse_> jelmer: but only the option from the interactive plugin is valid
<jelmer> stianse_: but both extend and register the commit command ?
<jelmer> stianse_: and are loaded at the same time?
<stianse_> jelmer: yes
<jelmer> stianse_: in that case you can't just import cmd_commit
<jelmer> stianse_: but you need to do something like bzr-nm does
<stianse_> jelmer: ok. perhaps I'll get some tips if I look in the source code of bzr-nm
<jelmer> stianse_: bzr branch is at http://people.samba.org/bzr/jelmer/bzr-nm/trunk
<stianse_> jelmer: thanks. i'll see if this solves the problem
<jelmer> stianse_: IIRC you need to call bzrlib.commands.get_cmd_object
<BasicOSX> Someone with op please /topic 1.13.1 released 23 Mar
<LarstiQ> BasicOSX: it didn't get through to the announce list yet?
<BasicOSX> not yet
* bob2 changed the topic of #bzr to: Bazaar version control system | 1.13.1 released 23 Mar | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<joschan> hi, what can i do, i added files that should not be added, but did not yet commit? is there an "unadd"?
<spiv> joschan: "bzr remove"
<spiv> (you can even "bzr revert")
<joschan> thank you!
<spiv> BasicOSX: btw, I don't think the topic is protected in this channel
<stianse_> jelmer, LarstiQ:  seems like I got it. at least bzr help commit shows options from both plugins
<bob2> it is not
<BasicOSX> heh. ok
<stianse_> jelmer:  used what's in bzr-nm except from adding decorate=True to the register_command call
<Glenjamin> is anyone else seeing a lot of "Unable to read from standard input" messages using bzr on windows?
<Glenjamin> it doesnt seem to affect anything, but i suspect something somewhere is closing stdin
<jelmer> stianse_: cool
<stianse_> jelmer: By the way, is this considered a workaround or the correct way of doing it?
<stianse_> Because if this should work, both plugins need apply this approach
<stianse_> jelmer: I was just wondering if I should commit a patch to for instance the interactive plugin or keep the changes locally if they are hackish
<lifeless> hai, I has net
<bob2> ph33r
<emmajane> \o/ for innnnernets
<jelmer> stianse_: no, this is the proper way
<lifeless> now, foods
<stianse_> jelmer: good to know, thanks
<jelmer> stianse_: If you can submit a merge request for bzr-interactive, that would be nice :-)
 * igc breakfast
<stianse_> jelmer: I was just about to commit actually :)
<lifeless> spiv: shall we pair today?
<spiv> lifeless: yeah
<spiv> lifeless: I don't have much preference about venue
<lifeless> spiv: Lynne is out all day, so here works well for me.
<spiv> lifeless: ok, I'll head to Epping then.
<mwhudson> are there any known sillinesses with push --overwrite over bzr+ssh from bzr.dev to bzr 1.12?
<spiv> mwhudson: not off the top of my head (certainly nothing specific to --overwrite springs to mind)
<mwhudson> it just says "fetch up to rev {git-v1:f9b8c7c7aef07f8a7c1646f4f87089ebaea537c3}"
<mwhudson> in .bzr.log
<mwhudson> i guess i should have said -Dhpss
<spiv> Yes.
<spiv> Or echo "debug_flags = hpss" >> ~/.bazaar/bazaar.conf
<mwhudson> ah right
 * mwhudson makes it so, kills and restart
<mwhudson> s
<mwhudson> spiv: it seems to be appending 100 bytes at a time
<mwhudson> 139.403  hpss call w/body: 'append', '/~launchpad-pqm/dulwich/devel/.bzr/repository/upload/x8ptbehx7d83ijydfcqn.pack', '' ('B110\n\n\x1f\x8b\x08\x00\x00\x00\x00\x00\x02\xff\x95\xcc\xc1\r'...)
<mwhudson> 139.403                116 bytes
<spiv> mwhudson: I'm fairly sure that's not specific to --overwrite.
<mwhudson> spiv: probably not
<mwhudson> spiv: it's surely very slow though :)
<spiv> mwhudson: Basically, upgrade the server, kthxbye ;)
<mwhudson> spiv: not helpful
<spiv> mwhudson: is this a stacked branch?
<mwhudson> i guess it's too late for anything else now though, given that 1.13 is out\
<mwhudson> spiv: don't think so
<spiv> Hmm, I guess devel/ is the dev focus, so probably not.
#bzr 2009-03-24
<mwhudson> so the fetch over sftp was much quicker, the autopack not so much
<mwhudson> spiv: sftp push taking 8 minutes and bzr+ssh being killed after 45 minutes is pretty sad making :(
<lifeless> mwhudson: in 1.12, if the branch was stacked, its the same code as 1.13 is doing
<lifeless> mwhudson: _no_ change
<lifeless> mwhudson: I realise its totally sad, but hey, thats why we added the streaming codepath
<mwhudson> lifeless: no stacked branches here
 * mwhudson resovles "less pointless grousing"
<jelmer> igc: hi
<spiv> lifeless: it is a regression since InterOtherToRemote was removed; now InterPackRepo will never trigger if one end is bzr+ssh
<spiv> lifeless: so even non-stacked pushes to packs suck if the server is 1.12
<spiv> lifeless: a "fix" would be to update my unmerged InterOtherToRemote hack that I did for John (that checks _is_remote_before((1,13))) to be in InterPackRepo
<igc> hi jelmer
<spiv> I'd be ok with merging that too, because that with the _ensure_real_inter mess gone that hack wouldn't have to cause get_parent_map RPCs to be skipped too.
<spiv> (Which was my main objection to merging the hack for John)
<jelmer> igc: So, I've been looking at implementing a svn-keywords filter
<jelmer> igc: however, I'd ideally like its value to match the value of the svn:keywords property (to avoid the need to support two settings in the future)
<igc> jelmer: ok
<jelmer> igc: svn:keywords however contains a comma-separated list of keywords to expand
<lifeless> spiv: alternatively we could add a cache when we're pushing, which we can detect
<lifeless> spiv: or tell people to upgrade ;)
<jelmer> igc: is there some way to support that atm?
<jelmer> igc: It looks like the current filter registration function requires a dictionary with all possible settings
<igc> jelmer: it does
<igc> jelmer: maybe we want a 'catch-all' handler as well
<igc> jelmer: basically, the current design makes it easy to ...
<igc> have different filters for different values
<igc> jelmer: but I think you want the *one* filter covering all values, don't you?
<jelmer> igc: yeah, having separate filters, one per keyword, seems overkill
<igc> jelmer: I don't feel it's overkill - it maps well to the eol case for example
<igc> jelmer: but it's definitely not what you need I think
<jelmer> igc: I don't think multiple *filters* is overkill
<jelmer> igc: I think having one filter for $Id$, one for $Date$, one for $SVNHead$, etc is
<igc> jelmer: right
<igc> and the current keywords filter handle all keywords from memory
<igc> it just doesn't a configurable list of which ones to expand
<igc> s/doesn't/doesn't take/
<jelmer> igc: right, so a catch-all handler would basically mean registering a "fn(value) -> filterlist" callback rather than a dictionary ?
<igc> jelmer: yes, something like that
<jelmer> igc: ok, I'll look into that
<jelmer> igc: did you see my patch for lazy registration?
<jelmer> igc: Do you prefer an extra wrapper function or rather making the registry public?
<igc> jelmer: just now - approved
<igc> I prefer a wrapper fn (for now at least)
<jelmer> igc: thanks
 * igc starts reviewing jam's LRUCache patch
<trypticon> hey I gotta quick question about the FAQ page on http://bazaar-vcs.org/FAQ#head-e6448836a60a73c1954f287ef5e928b79e3ff005 .
<trypticon> In section "4.1. Are binary files handled?" what are other tools that can be used to better handle binary files and or media files?
<lifeless> trypticon: in what way
<trypticon> I just wanted to know if there are better tools than bzr for handling binary files.
<lifeless> I'm not aware of anyone with better answers in the open source version control space today
<lifeless>                                                              ^distributed
<trypticon> humm.... So would it be a good idea to use an app like bzr for handling Binary-only files for version control?
<lifeless> well, plenty of folk do; it really depends on your requirements and what you mean by handling, and if your machine has the resources
<lifeless> like, if you are versioning 10GB database, files, you'll need 35GB of main memory, or so, to do a commit
<lifeless> but if you just want archiving, then maybe rsync is better and don't use version control at all
<trypticon> I'm trying to set up an archive of binary files (iso's. executables, etc) that I would like to be able to quickly checkout and manage.  I was wondering if bzr would work for this task?
<lifeless> iso's may be noticably slow, (700MB is a lot to shuffle round), executables shouldn't be an issue
<trypticon> why would you need 35G to handle a 10GB file?
<lifeless> 10GB for the copy you are recording, 10GB for the basis copy to generate a diff, and python has some overhead for objet handling; doing a merge requires 3 copies, and some commits need to do a merge to generate annotations
<lifeless> thats assuming we manage to perfectly avoid unnecessary copies in memory
<trypticon> sounds to me like bzr probably isn't the tool I should be using.  Humm.....
<lifeless> I suggest giving it a spin and seeing if it does what you need
<lifeless> we are improving things continually, and at some point will create drastically better handling for large files
<SamB> jelmer: pong
<trypticon> the thing is that I need something strictly for handling binaries though.  Binaries as large as 4.5gigs.  I don't have any more than 3gigs on my system so I'm not sure bzr will be able to do what I want it to.  Either way I will take some time and look through the site because it sounds like a great system.
<lifeless> trypticon: yes, I suspect you'd have some trouble using bzr for 4.5GB binaries on a 3GB memory system :)
<trypticon> I'll continue to research
<trypticon> thanks so much for your help
<lifeless> my pleasure, good luck
<spiv> mwhudson: lp:~spiv/bzr/remote-pack-hack probably fixes your performance issue
<spiv> mwhudson: as a bonus, I think it improves pushing to stacked packs on old servers too
<mwhudson> spiv: cool
<spiv> mwhudson: e.g. pushing up that branch only took 175 RPCs (1m 27s)
<spiv> mwhudson: which is still much worse than a 1.13 server :)
 * spiv tries with bzr.dev to compare
<spiv> Oh, hmm, a test failure.
<BasicOSX> I must have not been paying attention, 1.14dev NEWS file is totally different then 1.13
 * SamB wonders if he should bother to report that bzr repo-push doesn't work on launchpad urls ...
<thumper> SamB: what should repo-push do?
<spiv> mwhudson: yeah, it's a bit better than bzr.dev even on this trivial branch
<spiv> mwhudson: it should make a world of difference to pushing up a stacked branch with a large delta (ObNag: although still not as awesome as 1.13 on the server :)
<mwhudson> spiv: that's coming
<spiv> mwhudson: I know :)
<spiv> mwhudson: just think of me as the kid in the car repeating "are we there yet?"
<mwhudson> spiv: two can play that game
 * mwhudson mumbles something about lazy inventories
<lifeless> mwhudson: heres one we prepared earlier
<lifeless> BasicOSX: yes
<lifeless> BasicOSX: its restier
<BasicOSX> heh, isn't that more RESTful? Anyway, how can I do a local convert of the docts into html? I got some un-restier markup and PQM hates me
<BasicOSX> make rst2html?
<lifeless> make docs
<spiv> Or to just do the NEWS file, "make doc/en/release-notes/NEWS.html"
<lifeless> igc: ping
<emmajane> w00t! /me continues to be a bad influence: * esmerel makes a brief mention of source control in one of the book chapters, and includes bzr cuz of  you
 * emmajane bets that didn't make sense to anyone else.
<poolie> can some people help with a quick test: go to bazaar-vcs.org and tell me if you see a search box in the top right
<spiv> poolie: I do
<emmajane> poolie, are you fixing templates again?
<emmajane> I cleared cache and am still seeing a search box top right (under community and plugins)
<poolie> i'm trying to help newz fix them
<poolie> there's meant to be one
<poolie> i don't see it, and i don't know why
<emmajane> poolie, which browser?
<BasicOSX> poolie:  the merge of NEWS from 1.13.1 into bzr.dev with the format change was messy, think I got it, PQM is happy, but need another set of eyes looking at it
<poolie> jaunty's firefox
<emmajane> poolie, firebug is having a hard time finding the actual markup for the search box.
<poolie> ah i see
<poolie> i had my account set to use his preview stylesheet, not the default
<emmajane> ah
<emmajane> the tab index is screwy because of the edit stuff being at the bottom. not that it really matters, just "point of interest"
<SamB> there is an attribute for tab indexes ... or is that how the problem arises?
<Stanlin> hello
<Stanlin> is there any how to start with bazaar ?
<SamB> tried the manual ? the wiki ?
<SamB> http://bazaar-vcs.org being the latter
<lifeless> jelmer: I'm hearing scary rumours
<lifeless> jelmer: about dulwich & history
<SamB> what's dulwich?
<lifeless> the bzr-git git implementation
<SamB> and what are the scary things you've been hearing about it & history?
<Stanlin> SamB thank you, first opensource project with documents
<SamB> Stanlin: what? you've never seen documentation for an open source project before?
<spiv> poolie: have you seen the Branch.open jail / ignore_fallbacks thread on the list?
<spiv> poolie: a third opinion on that thread would be welcome
<poolie> a bit; i'll look
<lifeless> poolie: we need a tie break on 'boolean flag used explicitly in the server' and 'trinary flag with 'auto' as the default'
<lifeless> poolie: you can nearly entirely ignore the rest of it - we're both happy with the code and its been reviewed etc
<poolie> so if it was not "automatic in the server" then if some code in the server called it with "yes, open" it would run into the jail wall and fail?
<lifeless> poolie: unless it had explicitly opened the jail first
<poolie> interesting thread...
<poolie> you know it's spiv when there's a correct unicode diaresis on "naÃ¯ve"
<poolie> diaeresis*
 * igc lunch
<spiv> :)
<lifeless> Ã¦ surel
<lifeless> y
<poolie> "nÃ¦ve"??
<lifeless> diÃ¦resis
<poolie> oic; maybe
<poolie> i tend to only use unicode when needed
<lifeless> me too
<lifeless> I can't see any of the unicode glyphs I just typed
<poolie> lol
<lifeless> Ã¤
<lifeless> Ã®
<poolie> *anyhow*
<lifeless> Ã¯
<lifeless> ah yes
<spiv> lifeless: stop flushing your vowels in public :P
<lifeless> I'm in my own living room thank you very much :)
<poolie> lifeless: i think you marked bug 181367 invalid
<ubottu> Launchpad bug 181367 in bzr "bzr update should work in a treeless bound branch" [Low,Invalid] https://launchpad.net/bugs/181367
<poolie> despite filing it yourself :)
<poolie> i have an old tree that starts to fix it
<poolie> should i discard it?
<lifeless> uhm
<lifeless> I'll tell you once you tie break
<poolie> sent
<poolie> don't mix gaol and jail :)
<lifeless> poolie: so, I don't think update() on a treeless bound branch is safe or sensible, you need a tree, as my last comment describes why
<poolie> i agree with your reasoning
<poolie> i just wasn't sure if you'd had educated second thoughts or what
<lifeless> if you have a branch that makes update cleaner and safer, that is good; if your goal was just to fix that specific bug - delete it
<spiv> poolie: I only use gaol in the branch nick :)
<poolie> spiv: still.
<poolie> people may search for it
<lifeless> we need some fun!
<spiv> This is a good moment for lifeless to say "they should use bzr search" ;)
<lifeless> they should use bzr search
<lifeless> and it should know
<poolie> hee hee
<lifeless> anyhow, we restrained from creating commonwealth gaol in the api
<poolie> that was good
<poolie> so the blackbox test fell to 23 calls because it was previously opening the fallback across the wire?
<poolie> it would be nicer if this was not done in per-thread state but i suppose that's the only practical way for testing
<lifeless> poolie: no
<lifeless> poolie: it was because the server was opening the fallback
<lifeless> poolie: and the hook to record events was getting the events generated by the server during its opening of the fallback; each of the 23 commandline client generated hpss calls that was on a branch was triggering many hpss operations in the server (to the server itself)
 * ToyKeeper misses feature branches and bzr's merge-aware bisect tool
 * ToyKeeper is isolating a bug with hg  :(
<poolie> lifeless: oh huh
<lifeless> poolie: so fixing third-party access requests fixes the apparent request count :)
<lifeless> poolie: btw, did you see jam's 'dont use =======' in news?
<poolie> lifeless: yes i thought i fixed it
<spiv> Hmm, not according to my copy of bzr.dev.
<lifeless> not in .dev, it starts with ============= Bazaar Release Notes ...
<ToyKeeper> ow...  my head hurts.  In this hg tree, revision 1 is between r783 and r784.
<lifeless> fun
<ToyKeeper> A bisect narrowed it down to r771 to r773, then jumped back to r491 (which apparently actually happened in-between).
<ToyKeeper> I guess all I'm saying is...  I love you guys.  :)
<lifeless> cool :)
<poolie> lifeless: oh ok, i changed the others but not the toplevel one
<poolie> i'll change that too
<poolie> though, it's odd to me that resolve thinks they're conflict markers
<poolie> which should be just '======= '
<poolie> i mean it should require 7 followed by a space
<lifeless> I'm happy however you want to fix it :)
<lifeless> though requiring whitespace to be significant is a little ugly too
<lifeless> I mean, why not '=======\n'
 * lifeless shrugs
<poolie> spiv, jml, i just got
<poolie> LockFailed: Cannot lock LockDir(lp-46121936:///~mbp/bzr/controlfiles/.bzr/branchlock): Transport operation not possible: readonly transport in _remote_lock_write
<poolie> trying to push to https://code.edge.launchpad.net/~mbp/bzr/controlfiles using bzr.dev
<poolie> i thought this was strange
<poolie> lifeless: apparently cvs established the convention that there must be a space there
<poolie> and some tools expect it so we had to do it too
<mwhudson> poolie: it's a mirrored branch
<poolie> ah ok
<mwhudson> there has to be read only access to it for stacking
<poolie> that's a bit unobvious but of course you're right
<mwhudson> and um well
<mwhudson> accessing it :)
<poolie> wbn if it said "mirrored branch is readonly" but i understand
<jml> poolie: it'd still say "Cannot lock ...: Transport operation not possible: mirrored branch is read only"
<mwhudson> can a readonly decorator be customized to complain in a specific way?
<poolie> it would have given me a clue
<poolie> mwhudson: sure just raise whatever you want
<poolie> um and maybe refactor ReadonlyTransportDecorator to remove the duplications of that string
<mwhudson> right, i meant the one in bzr
<poolie> it would need either changing the one in bzr to allow passing in a string when it's constructed
<poolie> or subclassing it
<poolie> it's probably easy
<poolie> i'll do the bzr bit if you're keen to do the lp bit
<james_w> would it also be possible to improve the situation with lp: and no launchpad-login?
<poolie> which particular situation?
<james_w> so that we can get rid of the unpleasant warning in that situation
<james_w> "bzr push lp:foo" without a launchpad login gives you "cannot lock ...: Transport operation not possible: http does not support mkdir()"
<james_w> or similar
<mwhudson> poolie: sure, the lp bit should be easy
<james_w> I added a warning whenever lp: resolves to http to say "you haven't run launchpad-login, if you are doing a write operation it will fail"
<poolie> spiv i'm just trying your stacking hack branch against lp
<james_w> which is obviously not great
<spiv> poolie: cool
<poolie> and it's not drastically better :(
<poolie> it might be a bit better?
<lifeless> poolie: also, you're pushing to https ?
<poolie> lifeless: no, of course i'm pushing to the ssh branch described on that page
<poolie> so that was, to create a new stacked branch, 404 round trips in 5m16s
<poolie> a new stacked branch with a few new revisions mind you
<lifeless> poolie: there is no of course :)
<spiv> poolie: on a small branch from bzr.dev it saved me ~10 round trips when pushing to launchpad
<spiv> Which seemed about right given the small number of modified texts and new revisions in that file, and the savings were in append calls.
<poolie> ok so fwiw i had 49 append calls using your branch
<poolie> i'm just rerunning it with trunk
<poolie> i realize even smalls improvements are worthwhile
<igc> poolie: trying to review your doc patch ....http://rafb.net/p/ML5S7O90.html
<spiv> I was expecting it to be more than a small improvement.  Certainly if it does fix the regression vs. 1.13 that part is a big improvement... pushing a full history with that bug would hurt!
<poolie> hm that's not so good
<poolie> spiv, ok for trunk it was 489 rpcs in 5m30s
<poolie> igc, ok, that seems to be a bug
<poolie> probably easily addressed in the makefile by setting the path
<igc> 'make docs' is fine in bzr.dev so I'm pretty sure your patch is causing that
<spiv> That's a pretty substantial saving in rpcs.
<poolie> yes, it probably is
<poolie> because i moved the script
<igc> poolie: the rest looks fine so I'll vote tweak
<poolie> spiv, it is
<Stanlin> is there any quickguide, without launchpad marketing??
<jml> james_w: we aren't running anything for http that's smarter than apache
<james_w> ah, it has to come from the server side?
<jml> james_w: well, it might not *have* to
<jml> bzr asks launchpad to resolve lp:foo
<jml> launchpad gives it a bunch of URLs
<jml> bzr decides to use the http one since there's no launchpad-login
<jml> bzr raises confusing error
<jml> that's the rough flow.
<Stanlin> why i need to sign up in launchpad to use bzr??
<jml> Stanlin: you don't
<Stanlin> well all the docs points to launchpad
<spiv> Stanlin: I don't see much reference to launchpad on http://bazaar-vcs.org/ http://doc.bazaar-vcs.org/latest/
<Stanlin> im trying to configure a server, and give full permission to all users to do what they want... what is the best scenario in this document?? http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#personal-version-control
<spiv> Stanlin: simplest is to give each user a normal system account and get the users to put their branches in world-readable directories inside their home directories.
<Stanlin> but they want to share the same files
<spiv> And have bzr and ssh installed on the server so they can use bzr+ssh:// URLs to access those branches.
<Stanlin> should they share the same branch?
<spiv> Sure, if they want to write to the same branch.
<Stanlin> oh its simple as that?
<spiv> Right.  Normal filesystem permissions with users and groups basically :)
<Stanlin> they just point to that directory ... commit and voila?
<spiv> Yep.
<Stanlin> oh nice
<Stanlin> well ill be annoying here for a while im new in bzr thanks for the cooperation
<Stanlin> thanks a lot
<Stanlin> time to sleep
<spiv> G'night.
<bignose> if branch âfoo/â has a loom, and I âbzr branch foo/ bar/â, should I expect âbar/â to have the same loom?
<bignose> 'cause it doesn't :-(
<bignose> Bazaar (bzr) 1.13rc1, bzr-loom 1.4.0~bzr93-2
<lifeless> bignose: if 'a' and 'a' are the same branch, clearly they will, otherwise not unless you have run 'bzr record'
<lifeless> bzr help loom may be useful for you
<bignose> lifeless: ah. you don't yet have UTF-8 working properly?
<lifeless> no, it will be months
<bignose> if branch 'foo/' has a loom, and I 'bzr branch foo/ bar/', should I expect 'bar/' to have the same loom?
<lifeless> there is something fucked deep in libx
<lifeless> bignose: right, you need to run 'bzr record' to record the loom, it is for the loom as a whole what commit is for a tree
<bignose> okay, I have *no clue* what that command does, and the help is no help.
<lifeless> the loom is a stack of branches
<lifeless> this is versioned
<bignose> when am I supposed to run it? what does it do, that I might *not* want to run it?
<lifeless> record records a version
<lifeless> generally you should run it before you branch/push to a loom
<bignose> so why would I not want it run, say, every time I commit?
<bignose> okay, it requires a message argument. I don't know anything useful to say in the message.
<bignose> all the useful stuff goes in a commit message, but apparently this is not a commit.
<lifeless> an analogy may help
<lifeless> imagine you are using a loom for a debian package
<lifeless> where the bottom thread is upstream
<lifeless> and the top thread is 'debian'
<bignose> okay
<lifeless> and the threads in between patch the upstream code
<lifeless> such that you can patch bomb what other packages might have in debian/patches straight out of the loom
<lifeless> the list of threads is something that we need to merge - if I merge my loom from you patches[threads] you have deleted need to be deleted in mine
<lifeless> so record records the list of threads - the (name, revid) for each thread
<lifeless> np
<vila> hi all
<igc> hi vila
 * igc dinner
<CBro2007> hey guys... if developers wanted to UPDATE their branches with what is in the MAIN branch or TRUNK ... do I get them to do a bzr merge or bzr pull?
<CBro2007> Just trying to understand the difference
<bob2> pull
<Peng_> CBro2007: If they're maintaining a mirror of the main branch, "pull". If they're developing independent branches that'll be merged into the main branch, "merge".
<Peng_> CBro2007: In the latter case, once they have been merged, they can use "pull", but it'll change how "bzr log" is organized.
<CBro2007> Peng_: I created a trunk copy first and then created their branches from it... so that should be a mirror yeah?
<CBro2007> I mean its got the exact same dir structures etc of the project
<Peng_> Ehhhh.
<Peng_> CBro2007: What's the workflow? Do you use "bzr branch trunk feature_branch", hack on feature_branch, and merge it back into trunk; or do you do stuff directly in trunk?
<CBro2007> Yeah the branches are each developer's own branch... where they work on different features ... run it past me for a code review and I merge their changes to TRUNK
<CBro2007> I got that part working... now I want to do the reverse.. where they synch their own branches with LATEST changes that I merged into the MAIN branch
<CBro2007> so I think a PULL would be the best way to go eh?
<CBro2007> Maybe for smaller changes I will put the change DIRECTLY into Trunk
<CBro2007> and then developers can update their branches accordingly... very much like the CVS update command that developers run every day before they start work
<CBro2007> [dchoon@onyaaltd02 dcrepo]$ bzr pull /goldRepo/
<CBro2007> bzr: ERROR: Permission denied: "/goldRepo/.bzr/branch-format": [Errno 13] Permission denied: u'/goldRepo/.bzr/branch-format'
<CBro2007> Got this error when I was trying to PULL from the MAIN branch.
<CBro2007> have to check the permissions....
<CBro2007> its hard to get the permissions correct
<pygi> poolie, poke?
<poolie> hi pygi
<pygi> poolie, can I pm you? :)
<pygi> or are you busy?
<poolie> i am but you can
<jelmer> lifeless: hi
<jelmer> lifeless: yes, I dpushed dulwich
<lifeless> jelmer: why?
<lifeless> or are you developing it in git or something?
<lifeless> [it broke mirrors and people tracking it]
<jelmer> lifeless: yes, pushed into git so that others can contribute to it in git
<lifeless> jelmer: I'm not clear do you commit to it in git, or bzr?
<jelmer> lifeless: I personally commit to bzr then dpush
<lifeless> jelmer: whew :P had me worried.
<lifeless> jelmer: but why was a rewrite of the bzr history needed?
<lifeless> surely just dpushing to a git branch would make it accessible to git users?
<lifeless> *yawn* 11pm
 * lifeless sleeps
<jelmer> lifeless: well, we don't have roundtripping yet in bzr-git
<jelmer> lifeless: dpush changes the local history
<jelmer> lifeless: so that it is in common with the history in the foreign vcs
<jelmer> lifeless: I can now pull from people who contribute to dulwich in git without problems
<MvG> Hi! I'm using bzr-svn from time to time, and have a local branch for this. After the latest bzr update to 1.13, I had to update bzr-svn as well in order to support that version of the API. While pulling, bzr died with a backtrace and a "KnitCorrupt" error message. That was while operating on a shared repo for all my bzr-svn branches. Initializing a new repo and creating a fresh checkout succeeded. In the original setup, the issue can be reproduced. Do
<MvG> Hint: above problem is NOT about bzr-svn per se, so don't stop reading after hitting that keyword... :-)
<jelmer> MvG: what bzr-svn were you running prior to that?
<MvG> jelmer: jelmer@samba.org-20090202154824-ks8tepmvoam9dmpz if I'm not mistaken.
<MvG> In case you want to have a look at the error message: http://rafb.net/p/kfbdrg91.html
<jelmer> MvG: ah, it's the bzr-svn repository itself that you can't fetch?
<jelmer> MvG: I doubt I can help there
<igc> night all
<abentley> jam: when you're punched in, can we do a skype call?
<MvG> jelmer: Sorry, missed your reply. Fetching from scratch works, only updating fails. I guess I'll file a bug report, as I haven't found a related one, and as I don't think I've done anything evil on that repo to warrant this kind of error.
<yogsototh> Hi,
<yogsototh> I tried to understand what the plugin loom is about
<yogsototh> and I didn't find any resources.
<yogsototh> Can someone tell me what this plugin do
<yogsototh> please ?
<jam> abentley: sorry about the delay. I've been on for a bit. Sure we can do skype
<abentley> jam: np
<NEBAP> hi
<NEBAP> is it correct that "bzr push .." is the only way to upload changes from a branch into the "trunk"?
<yogsototh> I would say "bzr merge" could do the trick also
<NEBAP> but, how I understand, merge can only be used to "download" the changes, but in my case the editor wants to upload his changes..
<NEBAP> like you would do in svn ..
<LeoNerd> merge just pulls changes into the working tree, similar to a local edit
<LeoNerd> Yuo still have to commit those changes with  bzr ci
<NEBAP> so what is the correct way? Bind my local branch to the "server-branch" and then commit? Or maybe, merge the "server-branch" into my local branch, then bind the local branch to the server branch, and then commit?
<LeoNerd> Either works.
<LeoNerd> They're basically the same.
<LeoNerd> Depends if you want to leave it bound, or do a separate push operation
<NEBAP> ok, I try to describe my workflow
<NEBAP> there is a "server-repository" where the mainline of the code is stored. Know I want to add a new feature (or bugfix or whatever). For that I want to create a local branch (copy) of the mainline on the server. In this local copy I want to create a new branch with the name of the feature. Then I work on the feature branch and do local commits there. After I finished all, I want to merge thoses changes back into the server mainline...
<jam> morning vila, how goes the battle on the starward front?
<vila> jam: it's bloody and uncommitable so far, but I have good hope :)
<vila> jam: I'll get back to you once I get at least failing tests instead or erroring out ones
<jam> :)
<jam> I'm happy to chat if you want
<vila> jam: Thanks. I know that, but I need more meat first :)
<SamB> hmm, how can I do a bzr push over SSH to a system where bzr is only installed in my home directory?
<SamB> oh, sftp://
<jelmer> MvG: have you tried running "bzr reconcile" in the repository before pulling?
<MvG> jelmer: not yet, trying...
<MvG> BTW: filed as https://bugs.launchpad.net/bugs/347979
<ubottu> Ubuntu bug 347979 in bzr "KnitCorrupt listing _KnitGraphIndex when pulling" [Undecided,New]
<MvG> jelmer: No luck with reconcile.
<MvG> Ran it in the repo dir, not in a branch. Is that correct?
<abentley> SamB: You can also configure the location of the remote bzr using the BZR_REMOTE_PATH environment variable or the bzr_remote_path config variable.
<SamB> the config variables sounds more promising
<SamB> hmm, I'd want it as a per-host option though ...
<SamB> how come the usual SSH paths aren't supported?
<SamB> er, I mean, how come you can't say, e.g., sftp://cs.widener.edu:devel/dosemu/ to mean ~/devel/dosemu on cs.widener.edu?
<Kinnison> sftp://cs.widener.edu/~/devel/dosemu/
<Kinnison> because the colon is the port separator?
<SamB> oh. there *is* an ietf draft about this, and what you say is consistant with that.
<SamB> where is it documented in bzr's help/docs?
<Kinnison> dunno, it's always how I've used sftp URLs in gnome etc.
<SamB> oh, hmm, I guess that's normal
<SamB> I just hardly ever create that form myself ...
<SamB> still, I think it should be documented ...
<Kinnison> Is it truly up to bzr to document how URLs are formed?
<SamB> well, the draft doesn't even have an RFC number
<Kinnison> Should it explain about http[s]://[user[:password]@]hostname[:port]/...
<Kinnison> most URLs are scheme://[auth info@]hostname[:port]/path
<SamB> true
<Kinnison> it's not a stretch to assume that for sftp
<SamB> but most VCSes document the path formats they accept ...
<SamB> e.g. see git-clone(1)
<fR33b1Rd> hi. i've problem with .bzignore! Patterns only work for the topmost directory. Any patterns fÃ¼r subdirs don't work. any idea what could be wrong?
<Kinnison> True
<Kinnison> fR33b1Rd: Odd, I find plain patterns work anywhere. Did you put a slash in your pattern?
<fR33b1Rd> i tried many different patterns. "*.tmp" etc. just doesn't work
<Kinnison> Are you editing .bzrignore directly, or typing "bzr ignore *.tmp" ?
<fR33b1Rd> I tried both. There's no difference
<fR33b1Rd> is searched the whole docs, different forums, buglist etc. seems like nobody had such a problem before.
<Kinnison> Well it works for me
<Kinnison> I just did "bzr ignore '*.tmp'"
<Kinnison> and then it ignored .tmp files in the top level and in subdirs
<fR33b1Rd> okay, I just found the problem. "bzr ignored" doesn't show ignored files if the specific subdir is unknown, which is absolut plausible behavior.
<fR33b1Rd> I thought it would be better to setup the ignore rules first and then add the dirs and files to version control. obviously not the best idea.
<jam> vila: how's it going?
<vila> jam: it's going :-) I get a bit distracted by unrelated failures since... bbc has a couple now :-) Last trip ended up in one more failing test for loom :-/ I thought I excluded them with -x '(?i)loom' but it came back by the window :0)
<jam> vila: I was grabbing some food, and realized that it is ~ time for you to be done with work, right?
<jam> Did you want to skip the call today?
<vila> jam: yup, gf just came in anyway
<jam> vila: k, have a good evening
<OllieR> Hey, run into a problem on mac osx. I have done a complete restore from a backup and the system is running as it should but bzr has gone a little wrong, bzr: ERROR: Couldn't import bzrlib and dependencies. Please check bzrlib is on your PYTHONPATH. ImportError: No module named bzrlib. So from googling I have found out that i need to add bzrlib as a pythonpath but i can't figure out how to do this
<Kinnison> How did you have bzr installed before?
<OllieR> its looks like it was a macport
<Kinnison> I'd suggest just reinstalling it then
<Kinnison> it possibly didn't get backed up properly
<OllieR> ok i am going to try the dmg
<OllieR> not sure how this is going to react to the old macport version
<OllieR> yes a simple reinstall solved things :)
<fbond> Hi, is there any way to get bzr diff to put revision numbers instead of dates?
<abentley> SamB: If you specify it in locations.conf, it's a per-host or even per-path option.
<fbond> Oh, I found bzr-diff-revid.  Will core diff integrate this change?
<james_w> what does it do?
<james_w> ah
<james_w> it has been suggested that an extra comment line be added with the revision ids
<james_w> it could certianly be an option IMO
<abentley> jam: I'm looking at these iter_reference callsites.  The two approaches I can think of so far are: 1. Implement a reference cache on RevisionTree when read_locked.  2. Pass iter_entries_by_dir output into WorkingTree.initialize, build_tree and _build_tree.  Thoughts?
<rocky> jelmer: hey i just instlaled bzr-gtk manually using the sdist ... how do i get nautilus to "pick up" the integration features?
<rocky> nvm, found readme
<exarkun> Is there something like "bzr missing <repo url>" which doesn't involve typing <repo url> where <repo url> is the remembered push location for the working copy?
<jelmer> rocky: hi
<jelmer> rocky: did you see my review of your trac-bzr patch?
<abentley> exarkun: "bzr missing :push".  And of course, you can alias that to anything you like.
<rocky> jelmer: sorry got dc'ed earlier, didn't catch what you were saying ...
<rocky> jelmer: how would i go about troubleshooting the bzr-nautilus integration? is there a nautilus log i can view someplace?
<rocky> don't suppose anyone knows if there is a $HOME dir script that gets run before nauitlus launches in ubuntu such that it can setup some env vars that will be available to nautilus ?
<fbond> rocky: ~/.gnomerc
<fbond> Gets run when your Gnome session starts.
<rocky> ohh
<jelmer> rocky: you can restart nautilus, and it will write to stdout
<rocky> jelmer: what i'm trying to accomplish here is to use the nautilus integration of bzr-gtk where bzr (and bzr-gtk) are installed in a virtualenv ;)
<rocky> and i just got it to work, woot
<rocky> thanks fbond ;)
<fbond> rocky: No problem.
<rocky> jelmer: bzr-gtk doesn't display any sort of emblems on files in nautilus to show they're versioned?
<rocky> scratch that
<jelmer> re
<jelmer> beuno: ping
<jam> abentley: back to iter_references call sites...
<jam> A cache while read locked seems fine
<jam> though I'm not 100% sure what paths are benefiting
<jam> branch/sprout/whatever is an obvious case that needs to know about references, which is the 'fetch' fix we were talking about
<jam> we don't really have a RevisionTree at that time
<jam> for building the tree
<jam> (checkout)
<jam> it seems that build_tree could cache references it finds on the WT object
 * adrianrf newb q: want good repo setup strategy for managing multiple Drupal client projects. want all to share core Drupal distro code, and also per site have some shared contrib modules, some unique. can I nest repos? or should I treat each client site as a branch of the main distro?
<jam> adrianrf: I'm not really sure how drupal projects are laid out. In general, if you want to version a group of files independently from others, then they should be in their own branch
<jam> so that would hint that the various contrib modules would be independent branches
<jam> you may want to look at the 'scmproj' plugin, as a way to aggregate multiple branches into a meta-project
<jam> (we have some nested trees work, but that isn't fully baked yet)
<jam> you *can* nest repos
<jam> though you may be thinking of what we call "branches" and calling them a "repo"
<abentley> jam: in principle, BzrDir.sprout can use the same RevisionTree for create_workingtree and iter_references.  Though at present, it can't even accept a RevisionTree.
<abentley> (create_workingtree can't accept a RevisionTree)
<jam> abentley: so your idea is that if it created a working tree, it has already found the references, and it can just return those in the 'iter_references' call, right?
<abentley> jam: Right.
<jam> One can also contend that during the *fetch* portion of sprout, we would know the references
<jam> (I think)
<abentley> jam: For the purpose of fetching, yes.  Not for the purpose of creating branches or trees.
<abentley> because we wouldn't have encountered the references if fetch didn't do anything.
<jam> abentley: so is this so that sprout recurses to create child working trees?
<abentley> jam: right.
<jam> is there a reason that create_workingtree wouldn't be the one creating them?
<BFrank_> hey, can someone help me. I created a directory, and added a symlink and commited. Now the symlink has changed. How do I commit just the symlink?
<abentley> jam: Are you proposing that sprout first fetches everything for all branches, then creates all branches, then creates all working trees?
<BFrank_> anytime I try to commit the symlink by typing commit <symlink name>. I get this message... bzr: ERROR: Not a branch: "/symlink_path"
<jam> abentley: I'm saying that a call to the top-most "create_workingtree()" then creates the children
<jam> but I suppose you're saying the issue is that we haven't fetched them yet
<abentley> jam: In order to do that, it would need to create the branches first...
<abentley> And possibly the repositories.
<abentley> BFrank_: That's a bug.
<BFrank_> is it a known bug? Or is there a place I need to file it or something?
<jam> BFrank_: at the moment we have a bug with dereferencing symlinks at the wrong time. The workarounds are to commit the containing directory of the symlink
<abentley> BFrank_: It's a known bug.
<jam> and if that isn't specific enough
<jam> you can use something like "bzr shelve" to temporarily remove your other changes
<jam> then "bzr commit" then "bzr unshelve"
<BFrank_> ok, unfortunately, commiting the container directory will also commit a bunch of stuff I don't want to commit yet
<BFrank_> ahh
<BFrank_> I haven't messed with shelve yet
 * adrianrf @jam: many thanks! will check out scmproj, and do some more experimentation. 
<BFrank_> also, with blame, is there any way to get the --long parameter to put the date and time on the line, instead of just the date?
<abentley> jam: It's a whole layering problem.
<abentley> jam: I don't think create_workingtree should be creating branches and repos.
<abentley> jam: That sort of functionality seems to belong in sprout.
<jam> abentley: sure, though it seems like create_workingtree should be creating working trees ...
<jam> BFrank_: use "gannotate" or "qannotate" from bzr-gtk and qbzr respectively :)
<jam> but no, I don't think annotate has a way to do so
<BFrank_> hmm
<abentley> jam: Actually, I worry that such behaviour would be too smart for such low-level functionality.
<jam> BFrank_: you'll find that gannotate is a much richer interface in general
<jam> showing the commit message
<abentley> jam: I don't think putting all this on fetch solves the problem either, because if you're creating nested branches, you need to know about all references, not just those that were fetched.
<jam> and the whole information, etc.
<jam> abentley: which is why fetch should be creating the branches
<jam> and create_workingtree should be creating the child workingtrees
<jam> ...
<BFrank_> thanks, I will have to look into that
<jam> at least that feels like an appropriate layering to me
<abentley> jam: But fetch doesn't have enough info to create all the branches.
<jam> I don't have a specific problem passing the Revtree down to the working tree create
<jam> since if we already have it
<jam> we really should be using it
<jam> abentley: it has all the information to create new ones
<jam> and if it created them the last time it was fetched
<jam> only things that have changed should be 'new'
<abentley> jam: It won't fetch CHK nodes for revisions that are already present in the repo.
<abentley> jam: But those CHK nodes must be used to determine which branches to create.
<jam> abentley: but the previous time those nodes were fetched would have created them
<abentley> jam: But you can branch something multiple times.
<abentley> So when you branch the second time, into a new location, you don't create the branches.
<abentley> i.e. the subtree branches.
<abentley> Which would be bad.
<jam> abentley: but you would have the revisions in the shared repo...
<abentley> jam: But fetch won't have seen them, because they're already in the shared repo...
<jam> sure, but you can't really create the branches until the meta-workingtree has been created, because otherwise you don't have the containing dirs created
<jam> (you could create them ahead of time, but that would conflict with 'co')
<jam> ...
<jam> so what happens in a tree-less repository?
<jam> or when doing 'bzr co --lightweight'
<jam> or switch... ouch
<jam> anyway, I think having the option to pass a revision tree to create_workingtree is a good idea
<jam> if you can leverage that for iter_references, it is a fine starting point
<abentley> jam: The more I think about it, it doesn't seem like a solution, because we still have to call iter_references with no cache when creating a treeless branch.
<abentley> So it doesn't fix the case you were describing.
<abentley> jam: If we assume 1. revision present in repo, 2. treeless repo, I can't see any way to avoid hitting the tree.  (Except changing the data format or indexes)
<jam> abentley: I posted some of this to bug 347070
<ubottu> Launchpad bug 347070 in bzr "'bzr branch' with revisions transferred takes 20s" [High,Triaged] https://launchpad.net/bugs/347070
<jam> it seems robert's reply got messed up by my mail client
<jam> I'm not sure if you saw the same thing
<abentley> jam: I haven't been reading bug mail.  Looks okay on the web, though.
<abentley> jam: Your summary looks good.
<lifeless> jelmer: does that mean you'll be continually rewriting the local history of dulwich ?
<jam> morning lifeless
<jam> lifeless, abentley: I just discovered a significant effect of api friction between "iter_files_bytes()" and TT.create_file()
<jam> It seems the former returns a string
<jam> and the latter calls f.writelines(contents)
<jam> which works for strings
<jam> but takes 6.7s to write all of launchpad
<jam> rather than 1.0s when using f.write()
<lifeless> jam: interesting
<jam> yeah, I'm trying to decide what the best fix is
<jam> isinstance(contents, str): f.write()
<jam> or changing iter_files_bytes() to return chunks
<lifeless> use type(contents) == str rather than isinstance
<jam> lifeless: I believe that is type(contents) is str :) going by the recent patch submitted to change class comparisons to 'is' :)
<lifeless> jam: yes :)
<jam> lifeless: so you would change TreeTransform? (that was my basic feeling, but I thought I'd ask for feedback)
<lifeless> IIRC iter_files_bytes is allowed to return chunks
<lifeless> I'd need to check the docstring, but if a single string is valid for output,then yes, I'd change TT to cope
<jam> lifeless: well it claims: bytes_iterator is an iterable of bytestrings for the file.
<jam> of which
<jam> a string is a valid iterable of single-character bytestrings
<jam> just a really crummy one
<jam> hmm.... it seems that RevisionTree.get_file_text() assumes that the return value is *exactly* a string
<jam> especially since RT.get_file()  wraps StringIO(self.get_file_text()) which wouldn't work for a list
<igc> morning
<jam> morning igc
<igc> hi jam
<lifeless> jam: they are possibly not honouring the contract and should be fixed
<thumper> abentley: could I get a few line summary about the regression relating to nested trees?
<jam> thumper: "iter_references()" takes a long time because it walks the whole tree looking for tree-references
<jam> we are trying to find a way to either make that faster, or only do it when we are already walking the tree for some other reason
<jam> (store a separate list of tree references, do it as part of building the working tree)
<jam> the problem is that "bzr branch" in a shared repository with no trees
<jam> never does an operation that walks the content
<mwhudson> jam: so you have to do "for entry in tree: if entry.kind == 'ref': yield entry" sort of thing
<jam> mwhudson: that sort of thing, yes
<mwhudson> rather than "return entries.select(kind=='tree')"
<jam> mwhudson: we don't have an "index" or tree kind
<mwhudson> right
<mwhudson> ugh
<jam> s/or/on/
<jam> And if we need to create that index
<jam> then we need a disk-format change
<mwhudson> what format would need to change?  inventory + dirstate?
<jelmer> lifeless: no
<jelmer> lifeless: old revisions don't change
<jelmer> lifeless: not even in git :-)
<lifeless> jelmer: but, if you commit in bzr, then dpush, and that rewrites your branch, your branch will be continually changing?
<lifeless> jelmer: we're tracking bzr
<jelmer> lifeless: it only rewrites the new revisions in bzr
<jelmer> lifeless: and I don't publish them before I push to git
<lifeless> so you push to git then pull to the public bzr branch?
<lifeless> Seems like a lot of swings and roundabouts to me, unless you're getting lots of git-side contributors
<jelmer> lifeless: there's one additional command in my workflow
<jelmer> lifeless: basically, before I push my changes to a public location, I dpush to git first
<poolie> igc, if you're still in usertest mode, could you try to fix the trafficlight display on orcadas?
<lifeless> jelmer: well its up to you; I know I'd be treating bzr as master and merging from git contributors - or have them mailbomb me
<jelmer> lifeless: I am merging from git contributors
<jelmer> lifeless: my current workflow allows me to not have to touch git
<jelmer> and still keep contributors happy
<lifeless> jelmer: ok; well I look forward to the day that the bzr trunk looks like it originates in trunk :)
<lifeless> jelmer: how many git contributors are you getting?
<jelmer> lifeless: one, but should be a major one
<poolie> actually i see it just hasn't updated for some time
<jelmer> lifeless: the guy who is working on pyrite ("Mercurial UI + Git file formats") is ditching his own implementation in favor of Dulwich
<lifeless> jelmer: what are they doing? (And who is it, if thats not too nosy :)
<lifeless> cool
<lifeless> brb
<lifeless> spiv: I hear its a hot day
<jelmer> lifeless: in the short term, this will mean a proper git index implementation in dulwich
<jelmer> lifeless: in the long term, it'll hopefully mean bug fixes and speed improvements
<spiv> lifeless: :)
<spiv> lifeless: sure, I can head to Epping.
<igc> poolie: I'll take a look today hopefully
<mwhudson> jelmer: so we should start our tests of git imports with the linux kernel, right?
<mwhudson> :)
<jelmer> mwhudson: How much terabytes of RAM do the Launchpad servers have ? :-)
<mwhudson> jelmer: only a couple :)
<mwhudson> jelmer: do you know what needs to be done to support large imports?
<jelmer> mwhudson: yes
<mwhudson> jelmer: good
<mwhudson> jelmer: maybe i'll be able to get some time to helping you at some point :)
<mwhudson> wow, the performance of converting a packs branch to knits blows
<fullermd> Well, it's probably faster than converting to weaves at least  ;)
<lifeless> mwhudson: 'don't do that'
<lifeless> mwhudson: it shouldn't be slow slow, just writing one knit and index per file, unless you're also changing rootedness
<mwhudson> lifeless: i'm doing it so that i can test auto-upgrading of branches by the import system
<mwhudson> i guess i should have found a smaller one to play with
<fullermd> So apparently tomorrow I'm going to be trying to explain to somebody how to use bzr on windows.
<mwhudson> hm
<mwhudson> bzr: ERROR: Cannot convert to format <class 'bzrlib.branch.BzrBranchFormat5'>.  No converter
<mwhudson> seems to have worked though
<lifeless> mwhudson: there isn't a branch downgrader
<mwhudson> ah ok
<lifeless> mwhudson: so use a custom format via bzrlib
<mwhudson> i guess i should have said upgrade --dirstate-tags, not upgrade --knit
<fullermd> You could init/pull instead of upgrade, too.
<SpamapS> Does anyone know of bazaar users that have migrated from Perforce? I'm wondering if bazaar's changeset tracking is as good as Perforce's merge tracking.
<fullermd> Well, going to knit lets you test the full gamut too; all 3 formats are different there.  d-t -> packs is only 1 difference.
<bob2> better!
<fullermd> Is it?  I thought p4 had decent cherrypick handling.
<fullermd> (of course, it's got plenty of insanity aside from that...)
<bob2> I don't know!
<SpamapS> we've been relatively happy with Perforce
<SpamapS> its just expensive.. and doesn't have any decentralized abilities..
#bzr 2009-03-25
<SpamapS> when we had 15 users... we were like "well we need it" .. now we have 25 users... every user is I think $500 .. plus $100/year.
<mwhudson> jelmer: if you're still here
<mwhudson> jelmer: how does bzr-git's GitBranchBuilder avoid the
<jelmer> mwhudson: I am
<mwhudson> *** Your name cannot be determined from your system services (gecos).
<mwhudson> problem?
<mwhudson> i'm saying
<mwhudson>             run_git(
<mwhudson>                 'commit', '-m', 'dsadas', '--author', 'Joe Foo <joe@foo.com>')
<mwhudson> and the above message is making me sad :(
<mwhudson> (run on a test server, it works locally)
<mwhudson> i guess i can just run git config
<mwhudson> but it seems pretty ick
<jelmer> ah
<jelmer> you might need a ~/.git/config file
<jelmer> mwhudson: please file a bug, we shouldn't require that to be able to run the testsuite
<mwhudson> jelmer: it's not your tests that are failing :)
<jelmer> ah
<jelmer> mwhudson: I'm not so sure we avoid that
<jelmer> do we?
<mwhudson> i can probably find out
<mwhudson> jelmer: bzr selftest git ?
<jelmer> mwhudson: yep
<mwhudson> jelmer: yeah, some tests fail
<mwhudson> jelmer: i'll file a bug
<jelmer> mwhudson: thanks
<mwhudson> jelmer: https://bugs.edge.launchpad.net/bzr-git/+bug/348238
<ubottu> Ubuntu bug 348238 in bzr-git "tests fail if "Your name cannot be determined from your system services (gecos)."" [Undecided,New]
<skeftomai> hi...is Bazaar the VCS created by Ubuntu and/or the one they use?
<bob2> the same company that largely funds ubuntu also supports bzr
<skeftomai> ah. did Ubuntu create a VCS?
<lifeless> skeftomai: no, Ubuntu uses bzr
<skeftomai> ok. that answers my question. thanks
<lifeless> jam: ping
<Jimerson> Has anyone here run bazaar on aix?
<lifeless> Some folk have posted on the list from time to time
<Jimerson> I've read some of those posts.
<Jimerson> I'm having issues getting it compiled, and I can't tell if it is a issue with python or bazaar
<lifeless> Jimerson: pastebin the error, or you could file a bug
<Jimerson> http://pastebin.com/m7d649346
<jam> lifeless: pong
<jam> Jimerson: it looks like you don't have the compiler that python was compiled with
<jam> "xlc_r"
<Jimerson> Thanks guys.
<Jimerson> Now I have to try and find the compiler :)
<lifeless> jam: I'mmaking record_iter_changes a generator
<jam> lifeless: to return what?
<lifeless> fs hashes
<lifeless> its that or call tree._observed_sha1 directly, this seemed more accessible for testing/flexibility
<Jimerson> Thank you guys so much.
<Jimerson> That resolved my issue.
<lifeless> cool
<jam> lifeless: I don't have a huge opinion either way. It seems a bit odd to iterate over record_iter_changes, just because if you stop mid-way it seems to be in a strange state.
<jam> however, it is obviously an 'iter' sort of interface :)
<lifeless> right
<lifeless> anyhow, its done already :P
<lifeless> there are two issues, it could yield more than is put in (merge commits) or less (no stat cache calculations to update), which is why generator is better
 * igc lunch
<Jimerson> One last question and I will leave you all alone, As bazaar does not handle partial checkouts. How do you handle a situation, where you want to arrange the structure, with folders that are only their for organanization, but you want to be able to export it to a production server?
<bob2> put them in separate branches
<bob2> or don't use your vcs for deployment
<lifeless> Jimerson: I'm not entirely sure I understand the question
<Jimerson> For example:
<Jimerson> In bazaar I want it like /project/version/blah
<Jimerson> But I just want to export out to the server everything under blah.
<lifeless> so, bzr export can do that
<Jimerson> That means I would have to do a full overwrite everytime though correct?
<lifeless> yes, if you used export
<lifeless> uhm
<lifeless> for production deployments a number of folk use 'bzr upload'
<lifeless> I agree with bob2 though, in bzr you wouldn't normally have project/version as part of your versioned paths
<lifeless> note that 'bzr init-repo', if you've used that, is *not* related to versioned data, its just a storage area
<Jimerson> How do people seperate things then, just branch them out?
<lifeless> Jimerson: well typically they start separate
<bob2> you want one branch per project
<bob2> and they would start that way - you'd bzr init each individual thing indidividually
<lifeless> Jimerson: I mean, examine 'version' as part of a tree
<Jimerson> I get what you are saying.
<lifeless> if you made a tarball of your project, each version would be a separate tarball right? and thus in bzr each version is a separate branch, or even just separate commits in a single branch, but they aren't both versioned in the same tree
<Jimerson> I am new to scm, so I am learning.
<lifeless> likewise project
<VSpike> Just wondering... for a checkout, should bzr push to the "checkout of" branch ever do anything?
<Jimerson> lifeless, Thanks for all your help. I think I have enough to get rolling down the path. I'll be back. you have a nice evening.
<Jimerson> bob2, Thank you as well.
<lifeless> jam: around?
<lifeless> or poolie
<lifeless> currently we do housekeeping in commit
<lifeless> when we implicitly unversion something, to make sure we only unversion the root of a collection of things that all got unversioned
<lifeless> like if we have a/b and both are missing
<lifeless> if we don't, then wt.unversion() blows up
<lifeless> I'd like to change wt.unversion([a-id, b-id]) to just deal IFF b-id is a child of a-id
<jam> lifeless: so it wouldn't blow up if you did it in reverse, right? (unversion b-id before you unversion a-id)
<lifeless> yes
<jam> and the issue is that we are passing in a 'set'
<lifeless> yes
<jam> so it doesn't know what order to do things
<jam> the problem is that you may have a/b/c/d/e
<jam> and get b-id, then e-id, then a-id, etc
<lifeless> as the unversion set should be generally small, I think tracking this in unversion is ok, and easier to work with
<jam> lifeless: so I would think that keeping track of "things not yet unversioned" would be fine
<jam> and unversion should complain if all the children don't get unversioned
<jam> or something like that
<lifeless> well unversion should complain if something provided was never versioned at all
<lifeless> but sure, we seem agreed that pushing this to unversion is fine
<jam> lifeless: right, I'm actually saying that unversion should complain if you unversion "a" but *don't* unversion "b"
<lifeless> jam: I don't think so, its meant to recurse for us
<lifeless> and I like that
<jam> lifeless: I think it can lead to deleting things that didn't get properly recorded as being deleted as part of the commit
<jam> say "iter_changes" somehow
<jam> for the case of "a/b" and "a/c"
<jam> somehow just saw a and a/b being deleted
<jam> suddenly the commit doesn't think about 'c'
<jam> but unversion removes it anyway
<lifeless> if that bug exists we have it already
<lifeless> if you do bzr commit a/b and a is deleted, we should just delete b
<lifeless> care will be needed, I agree
<jam> lifeless: I agree, but I'm saying that "record_iter_changes" is only going to have a delta for 'a/b' and not 'a/c' even though we are removing it in a follow up pass
<lifeless> I'm down to 20 failures
<lifeless> but we won't remove all of a unless we record a delete of a
<jam> I feel like it is opening up a hole, that you can catch by saying that the delta must verify itself complete
<lifeless> and thus a/c won't be deleted, and if we did record a delete of a, a/c will be deleted [or the inventory delta is corrupt, which is even more serious]
<jam> I agree, a delta being corrupt is serious, and you are missing a chance to catch it
<lifeless> jam: unversion is on tree, its not the delta committed to the repository
<lifeless> jam: I don't quite see the correspondence
<jam> lifeless: the delta you are committing to the repository *should* match the one that tree is applying to itself
<lifeless> jam: uhhhh
<lifeless> jam: may be we're talking about completely different thigns
<jam> so commit auto-detects missing files
<jam> and then calls tree.unversion on them
<jam> to match the fact that it commits the delete to the repo
<jam> I'm saying that the logic in unversion
<jam> can check that the logic from commit is matched properly
<jam> If commit sees that 'a' is missing, commit *better* see that a/b and a/c are missing
<jam> and thus it can pass all of those to unversion
<jam> and unversion can double check that it agrees that everything under 'a' was marked removed
<lifeless> well
<lifeless> these sets do not have an equality constraint
<lifeless> already unversioned things
<lifeless> I think that it might be good if repo.add_inventory_by_delta checked deletes remove all children correctly (by checking the basename map)
<lifeless> or something
<poolie> lifeless: hi i'm back
<poolie> lifeless: so iiuc you're saying
<poolie> deleting the parent will implicitly remove the childern
<poolie> children*
<poolie> but explicitly removing some or all of the children as well will not be an error?
<poolie> that makes sense to me
<lifeless> right
<lifeless> specifically today, unversion[b,a] works, unversion[a,b] doesn't
<lifeless> I think it should work
<lifeless> down to 16 errors
<poolie> agree
<igc> poolie: one patch you may wish to review before you go on leave is http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cb87b89280902251019u212be32bv5e1b33fbe3dea83c%40mail.gmail.com%3E
<poolie> thanks igc
<poolie> ah right
<igc> poolie: from memory, you were involved in the email thread leading up to it
<igc> poolie: and it's been sitting there for a month now as most of us are buried in brisbane-core
<poolie> sure
<poolie> i read the previous version
<poolie> i asked for tests and they seem to be there so it should be good to go
<poolie> thanks for the nudge
<lifeless> bah
<lifeless> iter_changes skips over subtrees
<lifeless> 6 to go
<poolie> igc: that docs fix does actually work for me even in a new checkout
<poolie> which is odd
<poolie> igc, i'm inclined to just send it and see if pqm agrees...
<igc> poolie: worth a try :-)
<lifeless> 4 tests left
<poolie> lifeless: hi?
<poolie> you fell offline?
<VSpike> Just wondering... for a checkout, should bzr push to the "checkout of" branch ever do anything?
<lifeless> poolie: nope
<lifeless> poolie: still here :) deep hack is all
<poolie> hm how curious, pidgin shows you as offline
<lifeless> lies, its all lies!
<lifeless> so, I have inventory free commits
<lifeless> -woo-
<chrispitzer> i'm hitting a problem pushing to a remembered location with bzr.
<chrispitzer> I'm getting this when I try to push... bzr: ERROR: Generic path error: '85zdaceo7r26xzgd8t3m.fetch': Failure: unable to rename to '../packs/e1918987d0a82b7fad850f3c976fe036.pack')
<chrispitzer> any idea what's happening?
<lifeless> chrispitzer: hmm, are you onwindows perhaps?
<chrispitzer> nope
<chrispitzer> dev on ubuntu - pushing to shared hosting.
<chrispitzer> so I guess i don't know what the shared host is using... it's dreamhost
<lifeless> is it ftp?
<lifeless> (sorrry, on a phone call will be high latency
<chrispitzer> The remembered location is over sftp
<lifeless> chrispitzer: thats odd
<lifeless> could be permissions, or a still open file
<Peng_> DreamHost used to use NFS. They do something different now; probably just local ext3. Shrug.
<lifeless> chrispitzer: what bzr version are you using?
<chrispitzer> how do i check that?
<Peng_> chrispitzer: "bzr version"
<Peng_> Augh!
<chrispitzer> 1.6.1
<chrispitzer> I just nuked the .bzr folder on the remote server and pushed using --use-existing-directory
<chrispitzer> so that solves it for now.
<chrispitzer> *shrug*
<lifeless> chrispitzer: I suspect this is fixed somewhere around 1.10 or so
<lifeless> I recall a similar bug report which we fixed
<Peng_> What's Andrew Bennetts's nick again? andrew?
<lifeless> oh, or someone deleted a directory
<lifeless> Peng_: spiv
<Peng_> Oh, duh, right!
<Peng_> Thanks.
<Peng_> spiv: ping
<chrispitzer> hm
<chrispitzer> how so i push a working copy to a remote location?
<Peng_> chrispitzer: You could use the bzr-upload plugin.
<Peng_> chrispitzer: Or, if you have bzr installed on the server, you could push the branch, create a working copy on the remote side ("bzr co" in the branch), and install the bzr-push-and-update plugin locally.
<chrispitzer> i think I'll need bzr-upload, as the server doesn't have bzr and I don't have control to install it
<Peng_> chrispitzer: DreamHost? Why not? You can install it in your homedir if you want to.
<Peng_> chrispitzer: I don't recommend it, since procwatch will probably murder it in the middle of large operations, but you *can*.
<chrispitzer> lol
<chrispitzer> ug...
<chrispitzer> bzr upload only allows full uploads, not differential?
<lifeless> it does incrementak
<lifeless> but each file is full copied
<chrispitzer> lol
<chrispitzer> what's the point of that?
<chrispitzer> it uploads the file, and if the file's already there it ignores the upload?
<Peng_> What's the point of what?
<chrispitzer> uploading everything, when you're going to discard 90% of what you upload
<Peng_> Why are you going to discard 90% of what you upload?
<spiv> Peng_: pong
<Peng_> spiv: Hi!
<chrispitzer> that's what bzr upload is doing (if I'm reading it correctly)
<Peng_> spiv: The smart server jail stuff completely broke bzr+http with shared repos. What's the solution? File a bug? Edit my smart server script?
<spiv> Peng_: possibly both
<spiv> Peng_: start with filing a bug, though
<spiv> I'm surprised to hear that case broke, though.
<Peng_> :D
<spiv> In what way did it break?
<Peng_> spiv: The server's logs get spammed with "BzrError: jail break: 'chroot-139142476:///repo/", the client gets a similar UnknownErrorFromSmartServer.
<spiv> That's very odd.  That suggests a mismatch between the jail setup and the backing transport on the request handler.
<poolie> igc, i did that review btw
<poolie> hullo spiv
<Peng_> spiv: Filed bug 348308.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [Undecided,New] https://launchpad.net/bugs/348308
<lifeless> chrispitzer: you're reading it wrong :P it uploads only the changed files AFAIK
<chrispitzer> it uploaded everything the first time, but only incremental since then.
<chrispitzer> so it's good.
<chrispitzer> I mean, even the first time the working copy should have matched the remote copy time stamps and all... but oh well. :P
<lifeless> chrispitzer: it doens't work with working copies though, because we don't have the ability to efficiently and in a user-friendly deal with concurrent changes, conflicts etc
<igc> poolie: saw that, thanks
<vila> hi all
<lifeless> hi vila
<poolie> hi vila
<poolie> it might be nice if we really could deal with full remote working copies
<poolie> it's possibly possible :)
<vila> hmm, it would be nice if people stop proposing bzr-upload to upload a working tree since there is an explicit check there to ensure it will refuse to do so :)
<lifeless> poolie: I'm still skeptical but won't stop people doing it:)
<poolie> oh sometime i'd like to talk to you about whether just adding an indirection file to the dirstate is really enough
<lifeless> poolie: ok
<lifeless> poolie: over lunch perhaps :P
<poolie> as i said in the bug i thought there was a bug in that but imbw
<lifeless> on my plate is to analyse 'st' updates and then I have enough data for a proposal
<lifeless> I'll check the bug when I next think aboout that problem
<lifeless> for now, conversion to current chk is in progress, -> dinner
<poolie> do you mean analyze the value of updating the hash from st?
<poolie> cool, good night
<lifeless> I mean to analyse the potential race conditions of status doing that
<lifeless> with the alternate design
<igc> hi vila
<igc> vila: a present for you in the mailing list: my 'log DIR' patch ready for you to reconsider :-)
<vila> igc: hehe, ok, will look at it
<igc> vila: that would be awesome - thanks
<vila> igc: on the other hand if you could have a look at the bbc test failures related to 'CHKInventory' object has no attribute 'filter' ... :)
<igc> vila: Sure do. I'll do that either tonight or tomorrow
 * igc dinner
<vila> igc: thanks, enjoy your dinner :)
<lifeless> 19K test revisions converted
<poolie> hi lifeless
<poolie> i'm about to press send...
<spiv> lifeless, jml: http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html
<lifeless> spiv: well, thats good. the total lack of discussion is a bit odd
<lifeless> or perhaps we were looking in the wrong place?
<lifeless> also the implementation of class skipping is pretty bong
<lifeless> wtf doesn't def run() handle that
<AfC> bong.
<OllieR> is there a command to find out if a checkout if lightweight or heavyweight?
<Peng_> OllieR: "bzr info", I suppose
<OllieR> Peng_: that gives checkout location info and type
<OllieR> but doesn't tell me whether it was lw or hw
<OllieR> annoyingly :(
<Peng_> Seriously?
<Peng_> Huh!
<OllieR> yah
<OllieR> unless it does on a later version i am running Bazaar (bzr) 1.3.1
<Peng_> OllieR: I'm on bzr.dev, and the second line will say either "checkout root" or "light checkout root".
<Peng_> (err, third line. The first line of the Location section.)
<OllieR> Peng_: right yes so it does :)
<OllieR> Peng_: many thanks
<Peng_> :)
<Mez> Hey there, getting a bit of a weird error.
<Mez> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x9e117ac>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<Peng_> Mez: That probably means some unknown error happened, but it got masked by that. What version of bzr? It might've been fixed.
<Mez> 1.12
<Peng_> Mez: Oh. That probably won't help, then. Still, 1.13.1 is out; you should upgrade. :)
<Peng_> Mez: Sorry I can't help you...
<Mez> seems an upgrade to 1.13 worked Peng_ (after running break-lock)
<Peng_> Mez: Really? Great. :)
<lifeless> igc: did you see my commit figures?
<igc> lifeless: I did. well done
<igc> lifeless: we just need to sort out the nested trees issue & I'm be very happy
<igc> re commit in brisbane-core
<Peng_> This is a dumb comment, but.. is it just me, or is brisbane-core a scarily large amount of new code?
<igc> Peng_: it's a scary amount of thought ...
<igc> the code change themselves aren't huge in volume
<igc> night all
<Peng_> igc: G'night.
<Peng_> igc: 12,230 new lines according to diffstat, though they aren't all necessarily very interesting.
<OllieR> can you get bzr to default to a lightweight checkout?
<lifeless> igc: would like it if you could arrange to run usertest with bbc + my patch from bundlebuggy merged + the lineI highlighted commented out
<lifeless> igc: it would be very useful to know if there are surprises
<lifeless> igc: there is about 12MB of packs
<Peng_> OllieR: I guess you could make "checkout" an alias for "checkout --lightweight".
<Peng_> OllieR: I'm not sure how you'd make a heavyweight checkout then..
<lifeless> igc: I am wondering if we want to just cherry pick from bbc a lot to do the merge
<lifeless> Peng_: --no-lightweight
<Peng_> lifeless: Oh, okay.
<Peng_> lifeless: Cherrypicking's no fun.
<lifeless> 10% of our total history isn't either :P
<OllieR> Peng_: yeah not bad thinking
<OllieR> lifeless: how do you mean --no-lightweight?
<OllieR> can't see that in any man pages
<Peng_> Once everybody upgrades to bbc, that'll only be like 20 KiB, right? So what's the big deal? :D
<Peng_> lifeless: 10% of history ish't *that* terrible. It'll be a pain to "bzr pull" when it lands, but it's not significant to "bzr branch" or anything.
<Peng_> It's only significant because it'll come all at once.
 * Peng_ gets shot by someone on dial-up
<jelmer> Peng_: you can also always do a stacked branch
<Peng_> I wonder how large it would be even without history?
<Peng_> Sending it to BundleBuggy would be funny. :)
<james_w> does the new progress ever move to a unit larger than KB?
<james_w> 130000KB is too many digits for me
<nilg> hi, is there a tool to print what modifications has been done by who for a given file, thx
<Peng_> nilg: "bzr annotate"?
<nilg> yeah exactly what I wanted Peng_, thanks!
<Peng_> :D
<james_w> vila: hi
<vila> james_w: hi !
<james_w> vila: would adding something like transport.get_transport(for_writing=True) make any sense?
<james_w> then bubbling that up to things like Branch.open()?
<james_w> having the intent there would allow better error messages when there is a mismatch between what you want to do and what is possible on the transport I feel
<vila> 1) I think most commands already use {branch,repo,wt}.open[_containing] so I'm not sure it's the right place
<vila> 2) You can't always decide from the url only if you will be able to write or not
<vila> and even if the scheme itself allows writing you may be denied later
<vila> You're back to the not-logged-in-launchpad error message ?
<james_w> yeah
<james_w> I put it there, so I feel responsible that it sucks so much
<vila> responsible does not imply gulty :)
<james_w> I don't see what commands using open_containing et al have to do with it, they would indicate whether they will try and lock the branch for write or not
<james_w> Branch.open_containing(for_writing=True) or similar
<james_w> there may be a few cases where they don't know, but that would be acceptable I guess
<james_w> your point 2 makes sense, but I believe we could at least communicate this to the directory service
<james_w> the lp: service could then give an error when it needs to
<vila> How about checking that in the commands themselves via the underlying transport ?
<vila> or catch the exception and rephrase it if needed ?
<vila> :-/
<james_w> checking was my first attempt, but the way that I did it was vetoed
<james_w> I think we do attempt to catch the errors in a few places, but it's hard to get them all, and it keeps shifting
<james_w> plus that gives no way for the lp: service to suggest lp-login
<jam> james_w: I think we would consider a "Branch.open_locked(for_write=True)" or "Branch.open_write_locked()"
<jam> We've talked about it on the list
<jam> as a way to get around the current open + lock as a standard function
<jam> also, some internals tend to lock objects, and then unlock them to return them
<jam> which then gets locked right away
<james_w> that sounds sensible
<james_w> would passing that information down to the transport layer be ok?
<james_w> most things wouldn't use it I imagine
<james_w> or perhaps I misunderstood at what layer the directory services operate
<abentley> james_w: It is a lookup that is performed by get_transport.  Transports themselves don't use it.
<abentley> james_w: So I think pushing it down there would be fine.
<rocky> jelmer: is svn-push still required to setup a new branch folder with bzr 1.13 and related bzr-svn ?
<abentley> jam: +1000 on a method for opening locked branches.
<jelmer> rocky: yeah
<jelmer> rocky: I have a patch for bzr.dev that allows it to integrate into "bzr push", but it hasn't landed yet
<jelmer> whoa, when did "bzr branch --stacked" get so freakishly quick?
<jelmer> checkout out bzr.dev takes just 7 wallseconds
<Peng_> jelmer: http://bazaar-vcs.org/bzr/ was upgraded to btrees recently; maybe that's why?
<jelmer> Peng_: yeah, I guess that'd explain it
<rocky> jelmer: hrm, my svn-push is hanging :/
<Peng_> rocky: Hanging or doing a lot of work very inefficiently? :D
<rocky> hehe it's hard to tell the difference when it doesn't end ;)
<brink_> jelmer:  bzr git took me by surprise.   I had some bzr commands I forgot about in some scripts.  Accidentally ran them in a git repo and it just worked.  Nice.
<jelmer> brink_: :-)
<gnomefreak> can i push a branch using sftp?
<james_w> yep
<gnomefreak> james_w: thanks
<jam> jelmer: Along with the btree changes, I also recently changed the "grab the working tree" code to batch up requests into 5MB chunks
<jam> which made a big difference for the python 'branch --stacked' I was testing
<jam> (rather than requesting the content for each file separately)
<abentley> jam: The need for a fast iter_references seems legitimate to me, but since the current bbc format doesn't have it, should we consider having a new format for nested trees?
<jam> abentley: it wouldn't be terribly hard to add another "chk_map" or similar to the disk format for brisbane-core
<jam> and bring it in before we merge it to stable
<jam> (we have a few more days, at least)
<jam> otherwise, if you feel it isn't possible to do efficently without a disk format bump
<jam> then we can just disable it, and plan for one
 * Kinnison finally works out what brisbane-core is. "oooh" is my reaction
<jam> I'm wondering, for example, if "bzr branch meta-1 meta-2" *needs* to create the new branches
<abentley> jam: I think an additional chk_map would probably work.
<abentley> jam: I guess we could make it optional.
<jam> abentley: I would sort of like if the top level "inventory" record could know whether there was actually any entries, and could store a "NULL" reference, separate from a genuine sha1 reference
<jam> otherwise, I guess you just get the same null-sha1 everywhere
<jam> which isn't terrible
<abentley> jam: The idea is that nested behaviour should match non-nested behavior as much as possible.
<abentley> jam: not sure what you mean.  Are you talking about the chk map?
<jam> abentley:  we still have an inventory text, which points out the file-id for the root of the tree, the root node in the id_to_entry map, and the root node in the parent_id_basename_to_file_id map
<jam> I assume we would add a root key for the "tree_reference" map
<abentley> jam: That seems like a sane optimization.
<jam> I'm just offering that it should probably consider having a "tree_reference: NULL" entry
<jam> when we don't have any actual references
<jam> it isn't a big deal
<jam> but it means avoiding paging in an empty page
<abentley> jam: so about nested matching non-nested behavior: if you branch from foo, you have a new line of development for all files in foo.  If you branch from bar, and bar contains baz, it makes sense that you have a new line of development for all files in baz.
<abentley> Whether baz is a tree reference or a directory.
<abentley> jam: We're probably also going to want some more sophisticated branch/checkout operation that knows some trees should be checkouts and some should be branches.
<abentley> jam: based on user configuration.
<jam> abentley: my argument is that there are a lot of ways it could be done, I would also venture that in the most common case, you *don't* want new branches for *all* of the sub projects
<jam> I understand your arguments, and it comes down to the "implementor" gets to decide
<jam> I'm just thinking that if the only use case that *has* to have the index, is "bzr branch" in a shared treeless repository
<jam> (all other cases being ones where we are already walking the inventory)
<jam> then maybe we need to re-think that use case
<abentley> jam: I would venture that you want at least two new branches in the common case: one for the top-level directory holding the project and all its libraries, and one for the project source code itself.
<gioele> hello
<gioele> is the bzr package on PPAs based on 1.13 or 1.13.1?
<abentley> jam: That's the only one we've found so far, but I haven't looked around at the others yet.
<jam> gioele: I would guess the ppa hasn't been updated yet, as it should be "1.13.1-X"
<jam> johnf is the one who has been building them, but I haven't seen him around
<jam> then again, maybe he used -2 rather than going .1-1
<jam> which would be incorrect, but possible
<gioele> jam: I see
<abentley> jam: At a glance, everything else could be redesigned to not use iter_references, not that this would be especially easy.
<jam> gioele: if you install it, you can always do "bzr --version" to find out :)
<jam> abentley: sure, like I mentioned in the post with Robert, the layering gets a bit tricky for stuff like "commit"
<jam> though I think having iter_changes always return tree references
<jam> because we don't *know* whether they have changed or not
<jam> is a reasonable change
<abentley> jam: it depends on what you mean by changed.  We don't know if the subtree is changed, but the tree reference is only changed if its revision doesn't match the last_revision.
<jam> abentley: but we don't know if its revision would match last_revision unless we've checked that the subtree has/hasn't changed
<jam> consider what "diff" really cares about when it wants to recurse
<jam> Arguably iter_changes in revision trees could chop off that entire subtree
<abentley> jam: The subtree will commonly change without its last_revision changing.
<jam> but workingtrees seem like they should always recurse
<jam> abentley: .....
<jam> then when you commit
<jam> it doesn't record a new reference
<jam> so that checkout
<jam> gives you the new subtree?
<jam> I thought the "content" for a tree-reference was the last-committed revision of the subtree
<jam> not the last-modified revision of the tree root
<abentley> jam: last-modified revision of the *subtree* root?
<jam> right
<jam> sorry
<jam> It should be the Tree.get_revision_id() not Tree.inventory.root.revision
<abentley> jam: Correct.
<jam> abentley: which means that if the subtree content changes
<jam> then it's Tree.get_revision_id() should change
<jam> possibly being "None" to indicate it doesn't know what it will be
<jam> yte
<jam> yet
<abentley> jam: only if there's a commit.
<jam> abentley: I would argue that it should be None if there are changes and no commit
<jam> such that "bzr commit --no-recurse" would then know to record the last value
<jam> but "bzr commit" and "bzr diff" would both know that there are changes to be checked
<abentley> jam: I don't think so.
<jam> abentley: what do you gain by having a value that is "not quite correct" ?
<abentley> jam: The value is entirely correct.
<jam> (the content of the tree that is referenced, does not match exactly the content that the revision_id describes)
<abentley> It's defined to be whatever the last_revision in the subtree was at the time when the last commit in the parent tree happened.
<abentley> If there are no commits to the subtree, it's unchanged.
<jam> abentley: that is the "basis_revision_id"
<jam> which I think we sort of get confused with "revision_id"
<jam> because WT.last_revision() and RevisionTree.last_revision() both return something
<jam> but it doesn't actually have the same meaning
<abentley> jam: No, it's MutableTree.last_revision
<jam> abentley: so if you compare the current WT versus its basis, the fact that the tree reference points at the old value is sort-of wrong
<abentley> jam: I was not aware that RT had a last_revision
<jam> because it would indicate that there are no changes in the subtree
<jam> when there are
<abentley> jam: You are assigning a meaning to the tree reference that I am not assigning to it.
<jam> abentley: And I'm wondering why have a value there that doesn't have meaning
<jam> if you can't use it to check for equality
<jam> then you may as well use None
<abentley> jam: My mistake, for a WT the value of the tree reference should always be the subtree's WT.last_revision
<jam> abentley: you still can't use it as an equality check
<jam> and it still seems like it should be None
<jam> just like the last-modified-revision for all files/dirs in the WT
<abentley> jam: You can then compare it to the basis one and decide whether to commit the entry.
<abentley> jam: I think it's more like get_file_sha1.
<jam> abentley: but without scanning the subtree, you don't know if there are any modifications
<jam> I suppose "bzr commit --no-recurse" could use it
<abentley> jam: and neither do I care if there are uncommitted modifications in the subtree.
<jam> abentley: commit and diff both care, don't they?
<jam> as in "bzr diff" in the parent project
<jam> should tell you there are changes in the child
<jam> even if you haven't committed
<jam> Or are "commit" and "diff" not fully recursive?
<abentley> jam: Sure they do.
<abentley> jam: They don't use iter changes that way, though.
<jam> abentley: I'm arguing that they should...
<jam> as it means you don't need iter_references()
<abentley> jam: At the cost of damaging the clarity of iter_changes futher.
<abentley> jam: If you're going to do recursion via iter_changes, you might as well just recurse in iter_changes itself.
<abentley> That way, you don't have to emit unmodified entries.
<jam> abentley: except 'commit' needs to start a new commit process in the subtree
<jam> since it won't share the revision_id, etc of the containing tree
<abentley> jam: commit can figure out that the containing tree doesn't own the file and start a new commit process.
<jam> abentley: that seems far more expensive
<jam> I think there should be room for a WT.iter_changes() that can return objects that may-or-may not have changed
<jam> so that we don't have to verify that things have definitely changed
<jam> until commit has finished
<jam> (to avoid double-sha, etc)
<abentley> jam: I don't know how expensive it would be, but it doesn't seem like it has to be expensive.
<jam> abentley: checking that every record is in the containing tree means you have to check every file, and recurse up to its root
<jam> abentley: at a minimum, it is an extra check on every object
<jam> rather than having it handed to you
<jam> since it already knows it
<jam> when we hit a tree-reference, we *know* we are at the boundary
<jam> we don't have to check every modified file to see if it "really is" in this tree
<jam> (the check isn't very expensive, but it is still a check on all files, and even whether you have tree references or not
<jam> because there *might* be a tree reference)
<abentley> jam: Don't we already look up the record for each modified file anyway?  And wouldn't that automatically fail?
<jam> abentley: perhaps, though you then need to go figure out which subtree it was really in, etc.
<jam> it still seems far cleaner to have it done with commit getting a tree-reference
<jam> not that it isn't possible to do either way, just cleaner
<jam> again, whoever is willing to write the code gets the final say
<jam> I'm just describing my viewpoint
<abentley> Yeah, and I disagree about all of this being cleaner.
<jam> abentley: consider that the file_id may not be present, because it was an added file
<abentley> jam: what happens when you implement iter_changes betweeen two CHK trees?
<jam> abentley: we have one, but it doesn't support subtrees
<jam> because the behavior is still pretty "undefined"
<jam> also, note that WT versus basis
<jam> is *very* different from RevisionTree to RevisionTree
<jam> and will always be so
<jam> as you have to probe the content on WT
<jam> and you *don't* on RevisionTrees
<jam> and you also don't try to *commit*
<abentley> It just seems that it's hard to emit the tree reference in that case unless it has changed.
<jam> the results of RT.iter_changes(RT)
<jam> abentley: I generally, agree, my main argument is that for WT.iter_changes() we don't *know* without recursing if the subtree has changed
<jam> separate from RT.iter_changes(RT)
<jam> abentley: I suppose I would agree that RT.iter_changes(RT) doesn't return tree references that haven't changed
<abentley> jam: They're supposed to have the same behaviour, given the same options.
<jam> but WT.iter_changes(WT.basis_tree()) doesn't know
<jam> and *should* return something
<jam> either that, or it has to recurse into the subtree, wait for it to return whether it has changed or not
<jam> and then use that to decide the last-modified of this tree
<jam> entry
<jam> and then finish scanning
<jam> that would be okay
<jam> as it would then emit records for subtrees that really have changed
<jam> which is what commit cares about
<abentley> jam: I don't think last-modified enters into it.
<abentley> jam: are you thinking of reference_revision?
<jam> possibly, I'm not 100% sure what values go where
<jam> the point is that WT.iter_changes(basis) needs to actually scan, and can't rely on a cached value
<phinze> is it considered "bad form" to commit code to a downstream shared branch that really belongs in the central main branch?  i'm working on a feature that belongs in our trunk shared branch, but currently it has only one use case in the shared project branch i'm on... so i've been essentially shelving and unshelving to make sure that the code that belongs in trunk doesn't make it into the project branch
<phinze> my question is whether or not this is unnecessary and i should just commit it and pull it upstream when i'm ready?
<abentley> phinze: I'd be inclined to commit it into a separate branch, just to reduce the hassle.
<vila> phinze: I think you answered yourself, commit in branches with clear definition, create as many as you need and then merge them when you're ready
<phinze> yeah i suppose i'm only running into this because in this particular case i've neglected to use a task branch
<vila> phinze: see, you knew :)
<abentley> phinze: The loom plugin gives a way to automate this more.
<abentley> jam: Well, iter_changes doesn't emit either, so it's just a question of whether to set the modified boolean.
<phinze> okay so assuming i have a task branch were all changes belong in project branch "bar" but changes to file "dir/qux" belong in trunk
<phinze> i would just merge everything into bar and then from trunk merge ../foo/dir/qux?
<phinze> ooop
<jam> phinze: I'll often split things out to go into a separate feature of trunk, commit it, get it merged to trunk, and then bring it back into my project branch
<phinze> that should be ../bar/dir/qux in my example
<phinze> jam: like this?: bzr branch trunk trunk-feature; cd trunk-feature; bzr merge ../bar-feature/dir/qux; bzr ci -m "Merging trunk feature from bar task branch"; cd ../trunk; bzr merge ../trunk-feature; bzr ci -m "Adding trunk feature"; cd ../bar; bzr merge ../trunk; bzr ci -m "Merging trunk into bar"; bzr merge ../bar-feature; bzr ci -m "Merging bar feature that happens to have trunk feature that I already merged from upstream"
<phinze> perhaps i should have pastebinned that... :\
<phinze> jam: http://pastie.org/426694
<rocky> bah i hate it that in emacs shell the status tty stuff doesn't work very well with bzr
<phinze> bbl
<jelmer> rocky: did your svn-push finish?
<rocky> jelmer: it didn't but i cancelled it, i'm trying again right now
<rocky> outside of emacs ;)
<rocky> it's doing something but the status message is "discovering revprop revisions 609/"
<jelmer> jam: hi
<rocky> so far it says 10285kB @ 30kB/s ... whatever that means
<jelmer> rocky: well, that's the amount of data it's transferred from the remote server
<rocky> from or to?
<jelmer> rocky: both, subversion doesn't distinguish when reporting data transfer
<rocky> it occurs to me that there is a lot of content to upload so perhaps that's the issue here
<jelmer> rocky: this all happens before the actual pushing
<jelmer> rocky: it's just checking which revisions you have in your bzr repo already exist in the svn repo
<Mez> how do I get rid of
<Mez> No handlers could be found for logger "bzr"
<Peng_> Mez: Context? Where is this happening?
<beuno> Mez, try removing bzrtools
<beuno> and see if it still happens
<beuno> what version of bzr are you using?
<Mez> Peng_: any action with bzr
<Mez> using 1.13
<Mez> removing bzrtools makes no difference
<Peng_> Mez: Oooh. I don't know. Do you have permissions to write to ~/.bzr.log?
<Peng_> Mez: Do you have the environment variable BZR_LOG set?
<Mez> ah...-rw-r--r-- 1 root root 66911 2009-03-25 16:42 /home/mez/.bzr.log
<Peng_> Mez: Better, "bzr version" will show where it puts the log file. -- but you've already got it.
<Mez> that resolved it (chown)
<Peng_> :)
<Peng_> Maybe bzr should warn if the log setup fails.
<jam> jelmer, phinze: sorry I didn't get back to you yet, I had a phone call, and I'm going to eat lunch real quick, bb ~30min
<jam> phinze: my guess is that doing "bzr merge ../bar-feature/dir/qux" is going to actually be a "cherrpick" because you aren't merging all of the changes from that branch.
<jam> However, it otherwise looks correct.
<jam> I might do it as...
<jelmer> jam: I was wondering if a combination of your two suggested solutions for subtree performance handling in bbc would work
<jam> phinze: nm, I saw that you were merging trunk back into bar, which is what I was about to mention
<jam> jelmer: there are certainly lots of possibilities. There is also the "we would like to have bbc in core by the end of this week"
<jam> so it is part of the rc1 next week
<jelmer> oh
<jelmer> I wasn't aware that was the plan :-)
<jam> so what is our immediate goal
<jam> and what will we get done later
<jelmer> not that I'm complaining ;-)
<jam> can we get subtree performance to not be an immediate regression such that it would block bbc
<jelmer> jam: in that case the "subtrees known broken" one seems most reasonable to me
<jam> jelmer: though if "known broken" is the case, and we know we need a disk format bump
<jam> then we may as well continue to leave them broken
<jam> sorry
<jam> disabled completely
<jam> and expect there to be a --dev6 before we make them an official format
<jam> so the discussion was about seeing if we reall need a --dev6
<jam> or whether the current structures are enough
<jelmer> ahh
<jam> The current structures are enough for all cases but 1
<jam> well 'hypothetically given enough coding" enough
<jam> and that 1 case could be written to happen differently
<jam> but if that is seen as a bad route to what we want ultimately
<jelmer> jam: but leavning them broken would mean people don't need to upgrade to a new inventory file format
<jelmer> jam: when they start becoming supported
<jam> jelmer: right, but if we need new data on disk
<jam> they have to upgrade *anyway*
<jam> so why allow them to shoot themselves in the foot with the current format
<jelmer> jam: we'd just have to do a (cheap) upgrade to a format that had that index
<jam> jelmer: sure, but why wouldn't the rest of it also be cheap?
<brink_> Starting to think rename determination should be automatic.   Now that I've played around with it enough I realize that it makes integration, refactoring, etc., work much better.
<jelmer> jam: aren't upgrades that involve inventory rewriting expensive?
<jam> jelmer: it depends on how much of the inventory you have to rewrite
<jam> XML inventories have a single text for everything
<jam> so you have to rewrite MB of data
<jam> If it is just changing a format value in the top level node
<jam> that is pretty cheap
<jam> Anyway, I don't have a problem having a serializer that can include "tree-reference" in the stream
<jam> and just set the flag "supports_subtree = False" in the RepositoryFormat
<jam> And possibly add a bit in the serializer to have it check that it really-doesn't-yet have 'tree-reference' written.
<jelmer> jam: ah, I hadn't considered the fact that bbc's inventory format is faster to write deltas for
<jelmer> jam: thanks for the explanation of all of this
<jam> jelmer: out of curiosity, how does subversion handle commits with svn:external?
<jam> Is it not possible to have an atomic update?
<Peng_> So would bbc make going from plain to rich roots cheap as well?
<jam> Peng_:bbc is rich-root only
<jam> at least, that is the plan
<jam> we may back down
<Peng_> jam: Sure, but if it wasn't, would it be?
<jam> Peng_: converting a CHK-plain => CHK-rich-root should be *much* cheaper than it is today, yes
<jam> as it is writing 2 pages
<jam> (affected page, and root)
<jelmer> jam: externals are a bit of a hack
<Peng_> How cheap? Like, "bzr pack" cheap or "instant" cheap?
<jelmer> jam: basically it will run "svn commit" in all underlying trees as far as I know
<jam> Peng_: well, you'd probably want to do a "pack" afterwards anyway...
<jam> but that is 10-20min cheap, not 48hours
<jam> for the MySQL repo
<Peng_> 48 hours? Woah.
<jam> "bzr pack" on bzr.dev takes approx 2 minutes in bbc
<jam> and recompresses all the texts
<jelmer> jam: externals are a bit like config-manager, in that they point at a URL that's to be checked out
<jam> jelmer: I thought it could also refer to an exact revision
<jam> possibly URL@revnum
<jelmer> jam: but it's possible to not reference a specific revision, and if you reference a specific revision, you have to write that into the externals property yourself AFAIK
<jam> jelmer: so you could "guess" at the right revnum
<jam> but in the end you could be wrong
<jam> jelmer: I also thought with svn there was a way to say "i'm starting a commit, when I'm ready to finish, if the revnum doesn't match what I thought it would, abort and start over"
<jelmer> jam: yeah, in the case of a two-phase commit there could be some other person committing in between the first and the second commit
<jelmer> *first and second phase
<jelmer> jam: that's only for the base revision
<jelmer> jam: so if you open /trunk for committing when the last revision is 3
<jelmer> then somebody else could be committing revision 4 in /branches/foo and you wouldn't get an error
<chrish1> Hello. I've been reading the bazaar workflows documentation, and I've noticed something that puzzles me. In the "Decentralized with human gatekeeper version", Bundle Buggy is given as an example. Then at the end in the notes, it says "The Bazaar developers use Decentralized with automatic gatekeeper to develop Bazaar itself." And from what I understood from reading the mailing list, Bazaar uses Bundle Buggy
<chrish1>  for its development. So, one of these three statements has got to be wrong, no? Which one is it?
<chrish1> Can Bundle Buggy also do "automatic gatekeeper" (run a testsuite before commit, etc.)?
<Peng_> chrish1: Bundle Buggy is used for reviews. PQM is used as the gatekeeper.
<LarstiQ> chrish1: the human gatekeeper needs to track what to merge, the Bazaar developers need to track what to review (with bundlebuggy)
<LarstiQ> hi davidstrauss
<chrish1> Oh. So when the merge request is approved via Bundle Buggy, it forwards that to PQM to be merged into the trunk?
<davidstrauss> LarstiQ: hi
<Peng_> chrish1: No, when it's approved via BB, someone manually sends it to PQM.
<chrish1> Oh. So there's no need for any integration between the two. If I want to duplicate that setup, I just install Bundle Buggy and PQM separately, and forward manually between the two. That clarifies it, thanks!
<LarstiQ> chrish1: I guess you could make bundlebuggy submit requests to PQM, I think we like to keep some human judgement in the loop still.
<LarstiQ> but maybe it can be smoothened
<chrish1> I guess it's just a single command to submit a change to PQM once it's been accepted at review?
<LarstiQ> chrish1: hmm, you ask PQM to merge a branch, maybe you could point it at BB. That might not actually be mergeable depending on the state of trunk, hmm.
<LarstiQ> chrish1: try it! :)
<chrish1> Will try it when the project has started to get off the ground (when there's a testsuite, etc.). Btw, what's the best place to suggest a clarification to the bazaar-vcs.org web site content? (For what confused me in the Workflows page.)
<LarstiQ> chrish1: if you're confident about the change, editing the wiki.
<LarstiQ> chrish1: if not, the list or maybe here if it's something I could apply immediatly
<chrish1> I just want to suggest adding something like "(using Bundle Buggy for patch reviews and PQM to manage the trunk.)" after the "The Bazaar developers use Decentralized with automatic gatekeeper to develop Bazaar itself." sentence. Would have clarified things for me.
<LarstiQ> chrish1: sure, I can do that
<LarstiQ> chrish1: especially since I realise that documentation is not on the wiki :)
<chrish1> Thanks!
<LarstiQ> chrish1: could you point me at the exact url/section you had in mind?
<poolie> chrish1: you should also look at launchpad.net/tarmac
<poolie> which is meant to read review results and then test and merge automatically
<chrish1> LarstiQ: http://bazaar-vcs.org/Workflows (go to the end, the "Notes" section, etc.) Basically clarifying what I didn't understand before asking here...
<LarstiQ> chrish1: thanks
<LarstiQ> chrish1: so I was mislead by similar sections existing in the user guide, this _is_ the wiki afterall.
 * LarstiQ edits
<chrish1> poolie: Wow. Looks cool. Thanks for the pointer! Is it already at a stage where it's usable, or should I wait some more before giving it a shot?
<abentley> jam: Can you clarify: iter_references is slow on a RevisionTree?
<jam> abentley: yes
<abentley> jam: Even though it's an all-memory operation?
<LarstiQ> chrish1: edited.
<jam> abentley: it is all memory for XML trees, it isn't for CHK, but regardless it is an O(tree) operation
<jam> so 'slow' is a bit relative
<chrish1> LarstiQ: Saw it, cool. Nice to see the quick turnaround time for clarifications to the documentation. :-)
<jam> it is only slightly fast for XML RevisionTrees because we already paid the cost of deserializing every entry
<LarstiQ> chrish1: it helps that you had a clear request :)
<LarstiQ> chrish1: so thank you for the feedback.
<chrish1> LarstiQ: Thanks. Will come back and visit (and hopefully have clear requests) if there's something I find unclear again.
<fullermd> Does tortoise have an interface to 'revert'?
<LarstiQ> chrish1: cool. I haven't set up PQM myself, but am here to help regardeless.
<LarstiQ> fullermd: hmm, it should.
 * fullermd is on a conference call.
 * LarstiQ looks at the code
<LarstiQ> fullermd: it has a call to qrevert, so I'd wager yes.
<fullermd> I couldn't guess how to get at it, and he couldn't find it...
<LarstiQ> I can't actually test fully without windows here.
<LarstiQ> but:  gettext("Re&vert..."), gettext("Revert local changes"),
<LarstiQ> if that's not showing up in the context menu, I don't know how it works
<fullermd> Well, we ended up using the obvious and trivial workaround of making a new checkout of the whole tree at a given revision and copying the files.
 * fullermd is sure that was good PR.
<LarstiQ> fullermd: :/
<jelmer> lifeless: hi
<lifeless> hi
<Peng_> Who thought of stacked branches? They're a really great idea. :)
<jelmer> lifeless: You did some research before choosing a db format for bzr-search right?
<jelmer> lifeless: I'm trying to decide what bzr-svn should use instead of sqlite
<jelmer> lifeless: the main things I'm looking for are simple search keys (integers or strings), append-only, multiple concurrent writers/readers, preferably widely available (ideal would be included with bzr/python by default)
 * mwhudson would also be interested in such a thing for loggerhead/revnocache
<Peng_> Doesn't bzr-search just use bzr indexes...?
<jelmer> Peng_: it uses an additional index
<Peng_> jelmer: Yeah. And the format is just a GraphIndex or btree index.
<jelmer> ah, crap
<mwhudson> jelmer: what's the problem with sqlite?  the writers-block-readers thing?
<jelmer> mwhudson: yeah
<lifeless> jelmer: yes, I did
<lifeless> jelmer: gimme 30 to grab food and stuff, and I'll chat about this with you
<jelmer> lifeless: thanks!
<lifeless> jelmer: so
<lifeless> jelmer: I  researched search engines first
<lifeless> jelmer: with a requirement that they be able to work over ftp etc [ideally by hooking into the python transports of bzr]
<lifeless> non-starters, or at least 'much work needed'
<lifeless> for various reasons
<lifeless> jelmer: I ended up writing my own search engine; and yes I based it on bzr's B+Tree indices which are pretty good and have nice characteristics like write-once
<lifeless> jelmer: bzr-search builds a similar infrastructure to packs to get multiple writer multiple readers safely
<spiv> I just had a spam that started with "Jam with your bundle!".  No wonder it got past my spam filter...
<lifeless> spiv: 1:30 is definitely fine
<spiv> lifeless: cool
<jelmer> lifeless: hmm
<lifeless> jelmer: and I have a small project aiming to replace bzr searches storage guts with a general purpose thing it could reuse
<lifeless> I'm feeling my way around the domain/needed heuristics at the moment
<lifeless> jelmer: if you need to replace the value of keys its a little more tricky than bzr-search or repositories support
<lifeless> do you need to do that?
<jelmer> lifeless: no, it's read-only
<jelmer> s/read/append/
<lifeless> jelmer: k
<jelmer> basically there are three kinds of information in the cache:
<jelmer> - a copy of "svn log -v" on the root of the repository (incrementally updated whenever new revisions appear in the svn repo)
<jelmer> - a table mapping bzr revision ids to svn revno/path tuples
<jelmer> - a table with basic bzr metadata about each round-tripped revision
<lifeless> right
<lifeless> so bzr-search's approach would work fine for you, I think
<lifeless> as my generic thing isn't fit to show yet :) - its basically:
<lifeless> have a collection of packs with a names list (crib this from bzr-search)
<lifeless> with a function to merge at log2 or whatever
<lifeless> each pack has a directory, which the names list points at (by saying the bytes the index is found at)
<lifeless> the directory maps table names to byte ranges in the pack
<lifeless> each of those byte ranges is itself a B+Tree index, with the right tuple keywidth for the table and strings as values
<jelmer> lifeless: thanks, I'll look into that
<lifeless> bzrlib.plugins.search.index
<lifeless> read through that
<lifeless> you'll be able to discard everything specific to searching
<lifeless> jelmer: https://code.edge.launchpad.net/~jelmer/pqm/distutils/+merge/569 did you get notified of my review/
<lifeless> ?
<mrooney> Is there an easy way to see the unpushed commits of a branch to the push branch?
<jelmer> lifeless: yeah, I just haven't gotten round to fixing it yet
<lifeless> mrooney: bzr missing
<lifeless> mrooney: e.g. bzr missing :push
#bzr 2009-03-26
<mrooney> lifeless: awesome thanks!
<mrooney> my wildest dreams have true
<mrooney> have come true, that is
<mrooney> Actually my wildest dream would be one that functioned instantly offline by remembering info when it could
<mrooney> but this will do nicely
<jelmer> lifeless: so, different topic
<jelmer> lifeless: you were talking about (optional) support for an index in bzr quite a while ago
<jelmer> lifeless: how exactly would that fit in with the working tree?
<lifeless> jelmer: remind me?
<lifeless> jelmer: oh, no, I don't want an index. I think the index is a bug
<lifeless> I want tagging of changes/paths in a tree, and tags supplied to operations like commit and diff
<lifeless> I called these 'marks' to differentiate
<jelmer> ahh
<jelmer> so no staging area-like things?
<lifeless> hell no
<jelmer> bleh
<lifeless> that leads to UI confusion and layer leakage
<lifeless> look at commit -A,
<lifeless> an unbreakme option if ever there was one
<jelmer> you're making my job implementing a good mapping for git indexes ;-)
<lifeless> being able to commit content totally unrelated to what your editor sees is a bug
<jelmer> *a lot harder
<lifeless> I wouldn't map it, I would give bzr running against a git tree bzr semantics.
<lifeless> igc: so commit is good yeah?
<jelmer> lifeless: well, I have to map git semantics to bzr semantics
<jelmer> lifeless: that's a lot easier if bzr has a staging area :-P
<lifeless> jelmer: You'll need to explain this for me, because I don't see why
<jelmer> lifeless: so, what I'm trying to figure out is what "bzr add" should do in a git working tree
<lifeless> jelmer: it should make sure the files are versioned
<ronny> well, git add works on a  "add to the content of next commit basis"
<poolie> lifeless: i just filed bug 348750 quoting your mail
<ubottu> Launchpad bug 348750 in launchpad-bazaar "merge proposal mail context is confusing" [Undecided,New] https://launchpad.net/bugs/348750
<poolie> i was quite confused :)
<ronny> the staging area basically keeps track of the desired content changes in the whole tree
<jelmer> lifeless: yeah, but that means adding the *current* version to the index
<jelmer> lifeless: if the file gets changed after the add, those new changes won't be committed
<lifeless> ronny: not quite, but yes, I do know what goes on here :)
<jelmer> lifeless: in other words, what I'm saying is it's hard to map a git index to the Bazaar working tree APi
<lifeless> jelmer: sure they will if you make sure you do the equivalent of 'commit -A'
<ronny> yeah, i probably oversimplified the issue
<lifeless> jelmer: as I said, I wouldn't make the index *at all*.
<lifeless> s/make/map/
<poolie> jelmer IMO it should remember it as 'versioned' and then commit should build the index implicitly
<lifeless> looks like poolie agrees with me :)
<lifeless> poolie: 'commit -A' in git updates the index from the current disk, for paths already in the index.
<poolie> there is a bit of a question of where you would keep that
<poolie> is this for using bzr in a git working tree, or just committing to a git repo?
<jelmer> bzr in a git working tree
<ronny> one could view the index as temporary commit on top of the actual tip
<poolie> jelmer: i don't know if this is a great solution but one thing that would work would be to use the index just to keep track of which ones are versioned
<poolie> ronny: i know what it is thanks
<poolie> we just have a different model and we're trying to map them across
<poolie> so, anyhow, then commit would need to re-add the files already in the index that match the commit parameters
<lifeless> and back out unselected ones to the last commit state
<lifeless> poolie: I think you are proposing exactly what I am
<poolie> right
<jfroy> Hello people. Quick question: is there a command to change the name of a local branch and update where a lightweight checkout of that branch?
<jfroy> I have repo/A and a lightweight checkout of A in repo/sandbox. I want to move A to B (simple mv command), but I'm not sure how to switch over sandbox. switch will not operate because it doesn't find A.
<jfroy> *and update the branch path of a lightweight checkout of that branch
<poolie> jfroy: hi, will 'bzr bind NEWLOCATION' do it?
<jfroy> poolie: no, it also errors out
<mrooney> If I am going to attempt to do a branch of a quite large svn repos with bzr-svn, is it worth upgrading bzr on my Intrepid machine via the PPA, from 1.6.1-1?
<mrooney> Will I get anything to improve that
<spiv> mrooney: latest bzr-svn is much better than the version in Intrepid
<spiv> mrooney: and it in turn requires a more recent bzr than 1.6.1-1
<lifeless> mrooney: there is a major version upgrade to bzr-svn. much goodness.
<spiv> Hopefully the ~bzr PPA has the current bzr-svn package, it usually does.
<mrooney> spiv: 0.5.3-1?
<spiv> mrooney: yeah
<mrooney> oh for the PPA dependency, do I have to manually add that for it to work?
<mrooney> oh no here we go I think
<mrooney> oh no! this works differently
<mrooney> before if my username didn't match and I just hit enter, it would ask me for the username
<mrooney> now it just changes to "None password: "
<mrooney> how can I specify a username?
<spiv> mrooney: I think bzr-svn uses the same authentication.conf as the rest of bzr
<spiv> mrooney: bzr help authentication | less
<mrooney> okay, well the None user thing seems to be a regression
<SamB> I would have expected it to use subversions authentication cache ...
<spiv> mrooney: or maybe you can just stick the username in the URL?
<spiv> mrooney: yeah, it does sound like a regression.
<SamB> just make a bug
<mrooney> yes that does work if I put it in the right place!
<Guest68274> SamB: it also uses the svn authentication cache
<Guest68274> SamB: but it won't store new credentials into the svn cache
<mrooney> sweet bzr: ERROR: exceptions.AssertionError !
<lifeless> mrooney: try running 'svn log URL' to get svn to cache the credentials, that used to work
<mrooney> lifeless: well I got the credentials to work I think
<mrooney> the AssertionError came in the middle of a branch
<mrooney> multiple revisions in
<mrooney> Expected <CachingRevisionMetadata for revision 5, path  in repository '4c6ca7b2-8423-0410-87e0-f25a40cf7e9c'> got <CachingRevisionMetadata for revision 4, path  in repository '4c6ca7b2-8423-0410-87e0-f25a40cf7e9c'>
<lifeless> mrooney: interesting
<lifeless> unfortunatly the bzr-svn author is asleep right now
<lifeless> could you file a bug ?
<mrooney> sure, against bzr?
<Guest68274> lifeless: no, I'm not :-)
<lifeless> mrooney: bzr-svn please
<Guest68274> mrooney: is this bzr-svn 0.5.3?
<mrooney> Guest68274: yeah, from the PPA
<lifeless> Guest68274: oh, I didn't recognise you
<mrooney> "  svn                  /usr/lib/python2.5/site-packages/bzrlib/plugins/svn [0.5.3]"
<mrooney> jelmer: http://paste.pocoo.org/show/109661/
<mrooney> that should be helpful I hope!
<mrooney> it seems to get to roughly 30/1000 before dying
<jelmer> mrooney: the repository is not public, I presume?
<mrooney> jelmer: that is true :)
<jelmer> mrooney: please file a bug
<mrooney> jelmer: okay, can you give me a title for it?
<jelmer> mrooney: what sort of changes do "svn log -v -r4" and "svn log -v -r5" report?
<mrooney> jelmer: -r4 is a commit "manufactured by cvs2svn to create branch XX"
<jelmer> mrooney: what sort of changes does it contain though?
<jelmer> mrooney: file edits, file adds, deletes?
<mrooney> Changed paths:
<mrooney>    A /branches/XX (from /trunk:3)
<mrooney>    D /branches/XX/CVSROOT
<mrooney> and then r5 seems to be...nothing?
<mrooney> jelmer: But the error doesn't appear until decently past r5, does that still make sense?
<mrooney> the last number I seem to see is "copying revision 31/1000"
<jelmer> mrooney: "revision without changes causes exception" would be a good title
<jelmer> mrooney: bzr-svn should be warning you that you are cloning Subversion repository as branch.
<mrooney> yes it is indeed
<jelmer> mrooney: any reason you're cloning the repository root anyway, rather than using svn-import ?
<jelmer> The latter should not trigger this bug
<mrooney> I don't know, I just want to have the whole svn repos with version history
<mrooney> is there a better way?
<jelmer> mrooney: yes, svn-import should do that
<mrooney> it says to use svn-import to get individual branches in the warning
<mrooney> it doesn't recommend using that instead
<mrooney> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348786
<ubottu> Ubuntu bug 348786 in bzr-svn "revision without changes causes exception" [Undecided,New]
<mrooney> okay I must head out for today, but I can look into svn-import tomorrow if you recommend it
<jelmer> mrooney: but you're looking to import the individual branches right?
<mrooney> no
<jelmer> mrooney: e.g. trunk/ as a separate branch
<jelmer> mrooney: branches/foo as a separate branch, etc
<mrooney> I basically want a backup of the svn repository, that I can pull from each night and be up to date
<mrooney> having those as branches would be nice
<mrooney> so then I want svn-import?
<jelmer> mrooney: yes
<mrooney> jelmer: okay, I will use --incremental I guess
<mrooney> since I don't want to lose it all if it fails at the 25,000th rev :)
<mrooney> I am guessing that is what --incremental will get me, at a slight speed loss?
<jelmer> mrooney: it's failsafe even without --incremental
<jelmer> mrooney: --incremental will give you a speed improvement
<mrooney> ...interesting!
<jelmer> as it will remember where you left off the import
<mrooney> okay, I am off for now but this has made it much further using svn-import
<mrooney> at 500
<mrooney> but, it says of /23902
<jelmer> it breaks again at r500?
<mrooney> no it is still going :)
<jelmer> ah good :-)
<mrooney> and it actually ends at 28,000 something
<mrooney> and using branch seemed to notice that correctly
<mrooney> so I am not sure, what that means
<jelmer> mrooney: not all svn revisions will be imported as bzr revisions
<mrooney> oh okay, whereas with branch they would?
<jelmer> mrooney: e.g. that revision 5 won't show up in the bzr repository created this way
<mrooney> hm so you lose forced commits and their messages?
<jelmer> mrooney: yes, you lose commits that don't touch any of the branches
<jelmer> however, a branch created with "bzr branch" on the repository root wouldn't be very useful in bzr and would use a significant amount more disk space
<mrooney> oh okay, well thanks for your help and good work on bzr
<mrooney> good night!
<jelmer> gnight
<johnf> Has anyone ever tried using bzr bd on a cdbs based package that only has a control.in in the repo?
<johnf> hmm dpkg-buldpackage doesn't work either. Maybe time to read up on cdbs
<spiv> jelmer: has the escaping of / in bzr-svn revids changed recently?
<spiv> jelmer: I'm getting 'branches have diverged' when I try to pull Python's trunk, my disk has svn-v4:6015fed2-1504-0410-9fe1-9d1591cc4771:python/trunk:70244, but "bzr revision-info -d http://svn.python.org/projects/python/trunk" reports svn-v4:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:70601
<spiv> jelmer: I'll just file a bug :)
<spiv> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348805
<ubottu> Ubuntu bug 348805 in bzr-svn "Incompatible change to path escaping in revision-id mapping" [Undecided,New]
<lifeless> igc: ping; any chance of a reviewof my commit branch?
<igc> lifeless: probably not today unfortunately - I didn't sleep last night so I'm not awake enough for a review that important
<poolie> lifeless: i possibly can but i'm going to finish that mail first
<igc> lifeless: I can tomorrow if no-one beats me to it
<lifeless> igc: thanks
<lifeless> poolie: no worries; that mail has priority :)
<igc> lifeless: I didn't publish the results without your patch. For commit, they were 4x slower from memory so the proposed code is a big win. Really well done
<lifeless> igc: thanks
<BasicOSX> pyftpdlib working nicely with python2.6, good job
<lifeless> well I'm done for the day modulo interest-fiddles
<vila> hi all
<vila> BasicOSX: glad you like it ;-)
<CBro2007> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<CBro2007> I get this error when I do a "bzr pull /goldrepo"
<CBro2007> why is it saying that the branches have diverged?
<CBro2007> Is it good to use pull or should I use merge?
<CBro2007> I basically have a MAIN trunk where the gold copy of the app resides... every developer has his own FEATURE branch
<CBro2007> now I want them to be able to UPDATE or SYNCH their branches with the latest changes in the gold copy as I could have merged in some other developer's features in there that everyone must have
<CBro2007> should I use merge or pull?
<CBro2007> or get them to infact use... merge or pull?
<bob2> diverged = one is not a subset of the other
<bob2> ie they're not just out of sync, they have both made independent commits the other has not picked up
<CBro2007> but that will always be the case wouldn't it
<bob2> no
<CBro2007> I mean in reality developers will constantly keep committing changes to their own branch
<CBro2007> ok so if a developer was working on a feature....  he shouldn't be commiting his changes to his local branch before his feature is completely done and he is ready to merge it into TRUNK?
<CBro2007> is that what you are saying?
<bob2> no
<bob2> it will vary depends on what you and your developers do
<CBro2007> yeah but I just told you what they will do
<CBro2007> they will work on feature branches
<lifeless> CBro2007: if its a feature branch they should merge from trunk
<CBro2007> and once they are happy with their changes they will tell me which rev no committed copy I should merge into trunk
<lifeless> CBro2007: if its a mirror they should pull
<CBro2007> I suppose I am using a FEATURE branch then eh?
<CBro2007> so when they do a merge they would still keep their local changes yeah?
<lifeless> yes
<lifeless> have you experimented with merge
<CBro2007> yeah i have
<CBro2007> whats the "pending merges"
<CBro2007> ?
<CBro2007> it seems like local changes have to be COMMITTED before you can do a MERGE
<bob2> yes
<lifeless> CBro2007: so you do a merge, and bzr leaves the result wwaiting for review
<lifeless> you review it and commit
<lifeless> and then you can continue
<CBro2007> ok cool
<CBro2007> get it
<CBro2007> its pretty cool when you get the hang of it
<lifeless> we think so :)
<CBro2007> so I am thinking that the merge should work both ways - trunk to feature branch and vice versa
<CBro2007> even if they are out of synch
<lifeless> yes
<CBro2007> like someone has been adding stuff to trunk directly
<CBro2007> and someone to the feature branches
<CBro2007> and we can merge all at anytime yeah>?
<lifeless> to take something from a feature branch and put it in trunk, you cd to trunk, run bzr merge feature-branch, bzr commit -m "add feature to trunk"
<CBro2007> yeah
<CBro2007> and I can also merge a given revision with the -r (n) if i wanted
<CBro2007> :)
<CBro2007> soon I will be full of "bazaar life" mr lifeless
<CBro2007> hahahhaha
<lifeless> :)
<lifeless> vila: so, I've spun up 18-way amazon on 8-way cores for testing... its fun
<vila> lifeless:  isn't it :-)
<lifeless> finding some interesting bugs
<lifeless> did you see my doctest bug ?
<vila> lifeless: I don't think so, where ? tests.parallel ?
<lifeless> bb
<CBro2007> wondering if I should let developers merge their shit into trunk directly
<CBro2007> :)
<CBro2007> or have them send it to me for review first
<lifeless> CBro2007: what do they do at the moment ?
<CBro2007> nothing
<CBro2007> :)
<CBro2007> I am setting up bzr so we can start to share the code
<lifeless> ok
<CBro2007> and they can make changes
<lifeless> so I'd say don't add policy at the same time as adding technology
<CBro2007> but don't want them putting in shit willy nilly
<CBro2007> if they merged in stuff that is shit... it would be harder for me to get rid of it
<lifeless> if at the moment the way they get their code deployed is 'cp to production', then thats basically willy nilly
<CBro2007> they are not coding at the moment
<CBro2007> its just been me all this while
<CBro2007> they are going to be jumping on board to work on more features
<CBro2007> but its still going to be a learning curve for them
<CBro2007> so I would still like to review some of their work before I merge it into the GOLD copy
<CBro2007> :)
<CBro2007> I know I sound like a dick.. but hey
<CBro2007> :)
<lifeless> so, in which case, you should own 'gold' and merge features you're happy with
<maxb> Does anyone know if 1.13.1 will be reaching Debian sid soon?
<lifeless> vila: so, command line arg or variable, for test suite munging
<lifeless> actually,
<lifeless> I know
<lifeless> I will do shiny long needed refactorin
<lifeless> g
<vila> lifeless: I'm all ears :-) Refactoring  what targeting what ?
<kinkie> Hi guys.. a question o repository moving (if it's possible at all). I have a shared repo at /src/project/repo, containing various branches, which I check out and work on at /src/workspace. I'd like to move the shared repo up one level, to /src, to save on storage space. Is it possible to do somehow or would I have to create new branches, send -o and merge? Thanks1
<Kinnison> I would recommend branching inside the repo and then making lightweight checkouts into /src/workspace
<Kinnison> that way you get the "space" savings you're interested in, without compromising your current workflow any
<kinkie> ok.
<LarstiQ> also making sure not to have working trees in the repo
<Kinnison> Indeed
<Kinnison> a treeless repo and a separate area for lightweight checkouts is what I do for these kinds of things
<kinkie> That's what I also do, but I was wondering if it was easier to do something different ;)
<lifeless> vila: suite modifications, chain, like I made log
<vila> lifeless: Hmm, the alternative. I'm not totally convinced by it, but I see where you're going,
<vila> the main point that makes me nervous is that it means adding a 'fake' test to represent the remote suite,
<vila> which I find a bit artificial, but I may be wrong and it may be the best trade-off
<vila> I think it should make remote(parallelized) possible and clearer though
<lifeless> vila: test suite is a composite pattern
<lifeless> so a test is a suite is a test
<lifeless> jml: http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html
<vila> I think it also requires that such modifications be done last rather than first
<lifeless> well
<lifeless> I think the ordering will be important
<lifeless> if thats what you mean
<vila> yes
<vila> we don't want TestInSubprocess to filtered out because its id doesn't match some pattern for example
<vila> since we tend to flatten test suite via iter_suite_tests or things like that, not a big concern right now, but it kind of make the design more fragile
<vila> lifeless: your refactoring will include putting randomize_suite and exclude_tests_by_re inside that chain right ?
<lifeless> vila: do you have python 2.4 handy?
<lifeless> vila: if so, can you tell me if the base TestSuite has __iter__ defined in 2.4
<vila> yes
<vila> in unittest ?
<lifeless> yes
<vila>     def __iter__(self):
<vila>         return iter(self._tests)
<lifeless> so, regarding iter_suite_tests
<lifeless> I see two possible approaches
<lifeless> one is to say, if we iter, and it would break it (e.g. randomising), we should pass that responsibility onto children
<lifeless> by e.g. passing --random to them too
<vila> you mean children == subprocess, not children == tests right ?
<lifeless> yes
<lifeless> the other is to say, if we iter, the container should do what it needs to
<lifeless> anyhow, nearly done
<vila> Or we can make two chains: one post-load and one pre-run :-)
<vila> lifeless: by the way, since randomizing was introduced to exhibit isolation problems (AFAIU) I wonder if it's still needed...
<vila> I found more isolation problems by running test one by one than by randomizing the order
<lifeless> I have no use for randomisation, never did :)
<poolie> that was the point of it
<lifeless> poolie: ok, well I'm not proposing to remove it
<lifeless> it fits into this refactoring fine
<lifeless> vila: not quite right :P
<vila> lifeless: what ?
<lifeless> [6/17475 in 8s]
<lifeless> Ran 6 tests in 9.021s
<vila> oh, your refactoring :)
<vila> I like the elapsed time, try to keep it that way :)
<lifeless> so
<lifeless> http://paste.ubuntu.com/138181/
<nevans> I'd like to set "whoami" for all of the branches in a shared repo (vs 'bzr whoami --branch' in each individual branch)... is that easily doable?
<lifeless> sure, set it in ~/.bazaar/locations.conf
<lifeless> vila: what do you think [there was a tiny bug, its fixed]
<lifeless> two teeny bugs, fixed :P
<vila> lifeless: in ExcludeDecorator ?
<vila> lifeless: ignoring the details, the design sounds good
<lifeless> can I claim 'refactoring, please no new tests'? :)
<lifeless> vila: with this design, a plugin can do all of BZR_PARALLEL
<vila> lifeless: you two bugs were caught by the actual test suire right ?
<lifeless> yes
<vila> s/you/your/
<lifeless> [160/180 in 45s] test_selftest.TestTestResult.test_strict_with_known_failure
<lifeless> ----------------------------------------------------------------------
<lifeless> Ran 180 tests in 45.973s
<lifeless> selftest selftest
<vila> refactoring under test suite umbrella doesn't require new tests :-)
<vila> selftest -s bt.test_selftest :)
<lifeless> bb:approve then?
<vila> BB:APPROVE
<vila> But I don't see a way to plugin into suite_decorators
<vila> provided in builtins.py ?
<lifeless> yes
<vila> yeah ! :)
<lifeless> Command.hooks['extend_command']
<lifeless> btw
<lifeless> run 'bzr selftest selftest
<lifeless> note the double printing of what we're testing
<lifeless> something isn't isolated correctly
<vila> ECANTREPRODUCE, bzr selftest selftest --no-plugins ?
<vila> reproduced elsewhere
<lifeless> kinkie: just mv /src/foo/bar /src/bar
<lifeless> kinkie: or whatever
<lifeless> kinkie: you may want to adjust some paths in ~/.bazaar/locations.conf
<vila> lifeless: mv ~/lib/python/subunit ~/lib/python/subunitxx makes the double printing disappear
<vila> not pointing fingers....
<lifeless> odd..
<lifeless> vila: its printed out in builtins.py
<nevans> lifeless: thanks!  of course.  (I walked away from the computer right before you answered)
<vila> lol, I bet that sys.stdout.write is coming back to hunt you !!!
<vila> via a run_bzr or in a blackbox test or something :-)
<lifeless> vila: sys.stdout is wrong
<vila> lifeless: I know ! But yet :)
<vila> using 'print' in builtins is wrong too
<lifeless> yes
<lifeless> jml: so, ConcurrentTestSuite, testtools will accept, or won't.
<lifeless> jml: I need to know
<vila> lifeless: bzr selftest -s bt.blackbox.test_selftest.TestOptions.test_subunit
<vila> either gulty or victim
<lifeless> ah
<lifeless> I know what it will be
<lifeless> the runner is not being contained
<lifeless> or something like that
<lifeless> probably guilty
 * lifeless points fingers at whoever reviewed the test
<vila> LOL
 * vila points finger to self for still missing a test farm running isolated tests on a regular basis :)
<lifeless> do you know if its possible to have an optional option
<lifeless> e.g. --parallel[=foo] ?
<vila> came under discussion with jam recently: no, but we should
<vila> work-around : use a magic value :-/
<vila> i.e. --parallel=0 => cpucount()
<vila> lifeless: can you take http://paste.ubuntu.com/138205/ ?
<vila> rhaa http://paste.ubuntu.com/138206/
<lifeless> vila: thats better, but you know what would be awesome
<vila> you know I don't (yet :)
<lifeless> vila: do that printing by calling something [not foo.stream.write!] on the result object
<vila> 'that' ?
<vila> you realized -v and progress bar prints *during* execution, right ?
<lifeless> 'that' == 'testing: ...'
<vila> haa, so it can tell: testing 'this' 'here' ?
<vila> I was wondering about remote testing issues if you test from os1 to os2...
<vila> .. cans of worms
 * vila needs to eat
<lifeless> I'm off to be
<lifeless> http://paste.ubuntu.com/138212/
<lifeless> d
<lifeless> thats my reimagined version
<lifeless> it looks better to me
<lifeless> night all
<blizzz> hi, i have trac installed on a ubuntu 8.10 server. i want to use trac-bzr, but i get the warning: Warning: Can't synchronize with the repository (Unsupported version control system "bzr". Check that the Python support libraries for "bzr" are correctly installed.)
<blizzz> i am new to both bzr and trac, so i don't really know where to look... google search didn't help either
<jam> morning vila
 * blizzz found a solutiob
<jam> vila: http://paste.ubuntu.com/138325/
<Tak|work> jelmer: have you tried my branch of the md-bzr addin lately?
<Tak|work> jelmer: also, hi
<jam> vila: http://paste.ubuntu.com/138326/
<SamB> Is there a good way to see what the default push target is from a (non-python) script?
<asabil> SamB: using bzr info ?
<SamB> hmm.
<SamB> I suppose that's not much dirtier than a lot of the tricks dvc already uses ...
<asabil> SamB: I think you can also use the xml-output plugin
<asabil> well gtg now, ttyl
<stbuehler> how can i get bzr log to show the svn revision numbers? (debian testing/unstable bzr 1.13~rc1 + bzr-svn 0.5.3 )
<Peng_> stbuehler: It doesn't do it for revisions created by bzr.
<stbuehler> another reason never to use it again -.-
<stbuehler> thx for the info
<stbuehler> and please update at least the docs to mention this
<jelmer_> hmm?
<Peng_> Hiya jelmer_.
<jelmer_> Peng_: what's up with lighttpd and bzr-svn?
<Peng_> jelmer_: I don't know. What he said.
<jelmer_> Peng_: 18:25 < stbuehler> another reason never to use it again -.-
<mrooney> jelmer_: the svn-import seems to have been a success!
<mrooney> although how do I update it, I tried doing a pull but it isn't a branch
<Peng_> jelmer_: I don't know about that.
<Peng_> Oh, he upgraded to bzr-svn 0.5! That's nice.
<Peng_> jelmer_: He has a point about documenting the revno thing. I only found out about it after asking you. Not that I read the docs anyway... :P
<jelmer_> mrooney: you can run svn-import again
<jelmer_> Peng_: well, he didn't exactly seem happy about the upgrade..
<Peng_> Indeed.
<Peng_> I don't know anything about it, though.
<mrooney> jelmer_: so it doesn't have a memory of the location, I should specify it each time?
<jelmer_> mrooney: yeah
<mrooney> I basically want to run it nightly to have a backup
<mrooney> okay
<mrooney> jelmer_: how functional, thanks :)
<sohail> hey guys, I have a versioned directory that I want ot move into its own repository, maintaining history
<sohail> any ideas on how to do this?
<sohail> main use case for this is that this directory is never branched and I keep ediitng branched versions by accident
<nekohayo> hmm. is there a way to apply a .patch easily? Tried bzr apply and bzr patch, no luck?
<Peng_> nekohayo: What kind of patch? A regular .patch file, or a bzr bundle? For the latter, "bzr merge foo.patch"; for the former, I dunno.
<nekohayo> a regular patch I guess.. I usually make patches by doing bzr diff>foo.patch
<Peng_> Why are you sending around regular patches? You've got a DVCS! Use it! :D
<nekohayo> peng_ in normal circumstances yes, but someone sent me a patch by mail :)
<thumper> sohail: I know it can be done, but I don't know how
<thumper> sohail: perhaps jam recalls
<thumper> jam: splitting a versioned directory out of a branch into its own branch
<jam> thumper, sohail: So there is a hidden command 'bzr split' which effectively does this, though I think you have to be in a 'rich-root' format for it to 'just work'.
<jam> The direct alternative is:
<jam> bzr branch project newsubproj
<jam> cd newsubproj
<jam> rm * (not the dir I want)
<jam> mv dir/* .
<jam> rmdir dir
<jam> etc
<jam> sohail: but do you want to continue having this subdir in the project? Just not edit it most of the time?
<sohail> jam no I want it to be totally separate
<sohail> essentially, I have a "training" sub-directory which I use to store the tex sources for training sessions
<sohail> don't really need to branch it. I'll look into bzr split
<sohail> thanks thumper & jam
<thumper> sohail: bzr split will branch it
<thumper> sohail: I'm pretty sure it is just a nicer UI around what jam suggested
<sohail> I guess I could just do a branch and remove everything else like you say
<jelmer_> 'evening jam, thumper
<jam> hi jelmer_
 * jelmer_ just finished some performance improvements to bzr-git
<jelmer_> it now works ok on medium-size repositories, such as the git one
<Peng_> jelmer_: Congrats. :)
<thumper> hi jelmer_
<thumper> jelmer_: excellent
<thumper> jelmer_: we have the bzr-git stuff landed in LP now
<thumper> jelmer_: no UI yet to request it though
<jelmer_> thumper: ah, cool
<thumper> jelmer_: we're going to test it over the current cycle
<jelmer_> thumper: is there some other way to request imports?
<thumper> jelmer_: yes, there is an import your project button
<jelmer_> thumper: I have URLs for some small repositories that would be worth testing with
<thumper> jelmer_: feel free to email them to me
<jelmer_> thumper: will do
<jelmer_> trying the kernel now >-)
<jelmer_> thumper: looks like the kernel is actually doable
<jelmer_> thumper: no huge memory usage anymore, albeit a bit slow
<gnomefreak> what does bzr-builddeb do differently than dpkg-buildpackage with patch handling
<jelmer_> gnomefreak: it can set tags for you when you release
<jelmer_> gnomefreak: it provides revision specifiers in bzr for accessing debian versions
<jelmer_> (e.g. "bzr ls -rpackage:1.0-1")
<gnomefreak> jelmer_: dpkg-buildpackage fails to build makes a patch fail where as bzr builddeb doesnt make it fail. same source same bzr branch
<jelmer_> it can automatically check out upstream if that's in bzr/svn
<jelmer_> gnomefreak: what does dpkg-buildpackage provide exactly?
<gnomefreak> since hardy doesnt have bzr-builddeb i have no choice
<gnomefreak> jelmer_: it has to be used oin hardy since i get errors about bzr-builddeb not finding module or something along those lines
<jelmer_> gnomefreak: but I mean, what patch handling are you talking about?
<gnomefreak> jelmer_: dpkg-buildpackage in hardy the build fails on a patch where as bzr-bd doesnt fail at all
<jelmer_> gnomefreak: what sort of patch?
<jelmer_> gnomefreak: dpatch/quilt/cdbs/... patch ?
<gnomefreak> +++ mozilla/config/autoconf.mk.in
<jelmer_> or is the packaging branch in bzr-loom ?
<gnomefreak> quilt
<gnomefreak> bzr-loom?
<gnomefreak> all mozilla packages that we package are quilt cdbs now
<jelmer_> gnomefreak: afaik bzr-builddeb just runs a builder (such as dpkg-buildpackage), it doesn't worry about patches in debian/patches/ itself
<gnomefreak> jelmer_: my point
<jelmer_> gnomefreak: does debuild work?
<gnomefreak> did try it i guess i should
<gnomefreak> there is the failed build http://launchpadlibrarian.net/24369029/buildlog_ubuntu-hardy-i386.lightning-sunbird_0.9%2Bnobinonly-0ubuntu3~8.04~jjv1_FAILEDTOBUILD.txt.gz  on my PPA the other 2 built fine
<gnomefreak> debuild fails the same way on same patch
<gnomefreak> if the patch was a problem than intrepid and jaunty would have failed as well
<gnomefreak> im fairly sure building bzr bzr-bd python and friends is a bit more work than i would have thought
<jelmer_> gnomefreak: sorry, no idea :-/
 * jelmer_ joins nevans in saying spiv/lifeless's work on HPSS push rocks \o/
<gnomefreak> jelmer_: thanks i have to get back to this build. does bzr-builddeb need a version of python or any version will work?
<gnomefreak> if i can get away without building all python deps than it shouldnt take too long
<jelmer_> gnomefreak: I think 2.4 (which dapper has) should be sufficient
<gnomefreak> jelmer_: ok thanks ill give it a shot tonight i hope
<spiv> jelmer_: thanks :)
<lzhang> stacked branches in bzr
<lzhang> what are they for?
<Peng_> lzhang: So you can make a branch without keeping the entire history of the parent on your disk.
<Peng_> lzhang: It's like heavyweight vs. lightweight checkouts.
<sohail> jam, thumper fyi I just did it the manual way :-)
<lzhang> Peng_: what's the distinction between a stacked branch and one created with the --lightweight flag
<thumper> lzhang: a lightweight branch is a checkout and points to the repository and branch which are often in a different directory
<thumper> lzhang: a stacked branch is one where the branch contains only the revisions that are not in the stacked on branch's repository
<fullermd> There's no such thing as a --lightweight branch.  That's a checkout.
<fullermd> So, the difference is that one's a checkout, and the other's a branch  ;)
<lzhang> I see, makes sense
<sohail> how do you guys back up your bzr repositories?
<sohail> I'm using rsync for offsite backup
<lzhang> no need, it's distributed all over the place for us
<lzhang> every dev has a copy
<sohail> sure but I mean for personal repositories
<sohail> by "you guys" I meant "users of bzr"
<lifeless> sohail: I push it somewhere :)
<sohail> :-)
<lzhang> oh, time machine hehe
<sohail> rsync should be safe right?
<lifeless> as long as noone is committing
<lzhang> ya man totally
<lifeless> or pushing
<sohail> right now I have it distributed across 3 machines locally but I am making an offsite backup
<lzhang> is there anything like svn's vendor branches for bzr?
<sohail> svn does vendor branches by accident
<lifeless> sohail: rsync reads the file system but isn't guaranteed to get a consistent snapshot of databases; and bzr is basically a databas.e
<lifeless> sohail: which is why you can't be altering a repo when it runs and get a safe backup
<lzhang> sohail: what does that mean
<sohail> lifeless, so how would I push onto my server?
<lifeless> sohail: 'bzr push' :)
<sohail> that' sit?
<lifeless> its what I do to make sure I have another copy of my code
<sohail> really
<lifeless> you can use rsync, just don't be committing/pulling/pushing while rsync runs
<sohail> yeah I get that
<sohail> I should be using anacron to schedule this too..
 * igc breakfast
<davidstrauss> We need something like this: http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/
<lzhang> I say you guys need to fix up launchpad
<lzhang> github is way cooler
<lzhang> if you want a designer to use bzr then there has to be a gui client that looks like this
<lzhang> http://versionsapp.com/
<lifeless> davidstrauss: wow, someone vomited on that web page
<davidstrauss> lifeless: lol
<sohail> lzhang, a designer is not going to use bzr... svn is way easier
<sohail> though I guess a gooey makes it easier
<lifeless> well, designers do use bzr
<lifeless> so there is at least an existence proof that they do :)
<wgrant> How is svn easier than bzr?
<jelmer_> wgrant: it has more polished GUI's, especially on windows
<wgrant> Ah.
<wgrant> But GUIs are overrated.
<sohail> wgrant, you'd probably have some kind of time explaining that to a designer
<lifeless> jam: do you want to talk about fetch?
<lifeless> jam: also, is the commit stuff approve/tweak/whatever?
<lifeless> jml: ping
<jml> lifeless: pong
<lifeless> so, I want to land bzr parallel test support to trunk
<lifeless> poolie is happy with a [for-this-only] dependency on testtools
<lifeless> or I can land the bits I wrote in evenings in bzr
<lifeless> there are two classes I think have nothing to do with bzr, ConcurrentTestSuite and ThreadsafeForwardingResult
<jml> lifeless: ok. so you think those should go into testtools
<lifeless> I think that few people are finding 'bzrlib' when they search for python test support stuff
<lifeless> have a look at this patch: http://paste.ubuntu.com/138212/
<lifeless> you can see that all the bzr machinery for achieving parallelisation is separate to these classes
<jml> sure.
<jml> why the startTest / stopTest around all the calls in ThreadsafeForwardingResult?
<lifeless> it aggregates
<lifeless> consider two threads each with a test that takes 1 second to execute
<lifeless> the point of TFR is to make sure the target sees t1.start, t1.RESULT, t1.stop, t2.start, t2.RESULT, t2.stop
<jml> except if one of those tests adds two errors, then the output will be a bit confusing
<lifeless> yes, though calling addError twice is not well defined anyhow
<lifeless> stock TestResult in verbose mode will look ugly if you do that, for instance
<lifeless> sorry, TextTestResult
<jml> agreed. it happens a lot in testing concurrent apps though.
<lifeless> ewll
<lifeless> I could make it batch until stopTest
<lifeless> so stopTest would do result.start, for status in self.statii: status(result); del self.status[:]; result.stop
<lifeless> bah, to clever in spelling for my own good, but you get the idea
<jml> my hunch is that some people would want that, and others would want what you have in the patch.
<lifeless> I think that while unittest is unclear, but essentially implies that you should call just one status, its appropriate to stay with that
<lifeless> also hav eyou seen the upstream skip stuff now?
<jml> no, not yet.
<jml> I've seen the Twisted bug report about it.
<lifeless> http://svn.python.org/view/python/trunk/Lib/unittest.py?r1=70555&r2=70554&pathrev=70555
<lifeless> http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html
<jml> wtf is ClassTestSuite?
<lifeless> exactly
<lifeless> I'm rather unhappy with the patch
<lifeless> but perhaps I'm just coloured by liking clear code
<lifeless> anyway
<lifeless> jml: what I need is 'in princple yes, this is testtools material, submit to bzr without them and we'll move testtools stuff through' or
<lifeless> 'no, I'm not happy with this in the near/immediate future, put it in bzr'
<jml> lifeless: in principle I'm happy with concurrency support in testtools.
<jml> lifeless: so, yes.
<lifeless> ok
<lifeless> I'll get a branch of testtools with both of these in it; that will let us review and discuss it, and put a patch for bzrlib depending on that branch
<lifeless> and I'll make any changes you need
<jml> lifeless: thanks.
#bzr 2009-03-27
<spiv> jelmer: thanks for fixing the escaping bug, although I had to delete my svn-cache to fix it completely
<spiv> Ah, hmm, or perhaps not quite...
<SamB> escaping bug?
<spiv> SamB: %2F in svn-v4: revids rather than /
<jelmer_> lifeless,jam,igc: is now too late to get another change to the bbc file format in?
<lifeless> jelmer_: its never to late
<lifeless> jelmer_: we just can't change the format in bzr.devwithout issuing a new one
<jelmer_> ok
<lifeless> it will come in as beta, meaning we can issue new versions easily
<jelmer_> I'd still like to get that new revision serializer in
<lifeless> well, get a patch up :)
<jelmer_> Well, I asked for feedback a while ago about this
<jelmer_> about the format to use
<jelmer_> (See "[RFC] New revision serializer format" on the mailing list)
<lifeless> you'll need to make sure send keeps working
<lifeless> and possibly other things
<lifeless> I don't have a strong opinion about revision serialisation; I would say though that it should still be typed
<lifeless> I mean
<lifeless> having it not know the encoding, or store badly encoded things is undesirable
<spiv> lifeless: I think I'll head to epping on the 1:35
 * spiv -> lunch
 * igc lunch
<lifeless> jam: ping
<jelmer__> https://code.edge.launchpad.net/~jelmer/git/trunk (-:
<lifeless> igc: ping
<lifeless> jam has reviewed my commit change, but unless I'm blind managed to not say approve|tweak|whatever
<lifeless> abentley: is bb dead?
<lzhang> I know this is from a while ago but seriously
<lzhang> svn is way harder than bzr
<lzhang> if you are coming from no vc experience, bzr is super easy, the only hurdle is the command line
<spiv> jml: you may be amused to know that python trunk breaks bzr's test suite too (not to mention bzr itself).
<spiv> jml: although for different reasons.
<jml> spiv: right now I'm full of despair.
<jml> spiv: and I can't say that lightened my mood :)
<spiv> jml: fun fact #1: sys.version_info isn't a tuple anymore, and cannot be used in expressions like "%s,%s,%s,%s,%s" % sys.version_info
<spiv> jml: #2, TestCase._exc_info has been removed.  Which is actually reasonable I think, although a DeprecationWarning might have been nice.
<spiv> (Although being an _-prefixed method I guess their policy doesn't oblige them to do so)
<spiv> With those fixed the test suite at least runs, although there are failures from at least test_http, I haven't dug much further...
<Peng_> Do new Python releases always cause fallout like this? What happened when Python 2.5 was released? Was bzr even around back then?
<spiv> Peng_: well, 2.7 isn't even a beta release yet, so there's still hope ;)
<spiv> But basically, yes.
<lifeless> so spiv provoked me to minirant
<lifeless> http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html
<lifeless> the least "you" can do is join in.
 * lifeless looks at spiv
 * lifeless looks at jml
<jml> not going to, sorry.
<seb_kuzminsky> i have a shared repo with a bunch of branches in it, and each branch has a single working dir with a checkout in it
<seb_kuzminsky> some of the branches are *also* checkouts of a CVS repo elsewhere
<seb_kuzminsky> yes it's messy
<seb_kuzminsky> it gets worse
 * lifeless cris on jml's shoulder
<bob2> Peng_: bzr was like 18 months old when 2.5 came out
<seb_kuzminsky> the CVS repo recently branched, and now i want a new bzr branch that tracks the new CVS branch
<seb_kuzminsky> but i want to be able to merge between my bzr branches...
<seb_kuzminsky> if i simply check out the new cvs branch into an empty bzr branch, i can't merge between the bzr branches properly
<seb_kuzminsky> what should i do?  just shoot myself?
<seb_kuzminsky> is it safe to just "cp" one branch-directory to another?
<seb_kuzminsky> ie "cp upstream-trunk upstream-2.3"
<lifeless> its about the same as 'bzr branch'
<seb_kuzminsky> then in upstream-2.3 do a cvs update to the new branch, and "bzr commit" that
<bob2> bzr-load-dirs might still exist
<bob2> also the wiki has a list of solutions
<seb_kuzminsky> oops i'm back
<bob2> seb_kuzminsky: also the wiki has a list of solutions
<seb_kuzminsky> ok bob2 i'll check that
<seb_kuzminsky> bob2: i'm pretty much using the "converting and ignoring history" method from "TrackingUpstream"
<seb_kuzminsky> maybe i should switch to "Converting and keeping history"
<igc> lifeless: pong
<seb_kuzminsky> i dont have access to the machine hosting the repo, so i can't use "bzr cvsps-import"
<jam> igc: hey
<jam> hey lifeless, I just "tweaked" your patch, sorry I forgot to vote earlier
<lifeless> no worries
<lifeless> I fixed the link test
<lifeless> I don't think there were other changes needed? it was more informational?
<lifeless> jam: if you want to talk about fetch we can arrange a voice call
<igc> jam, lifeless: do we have a tool that 'looks' into a pack and gives you info about it?
<lifeless> igc: there is an index dump command
<lifeless> and there is repository-details
<jam> igc: not specifically for a .pack file, there is "repository-details" that does a bit more
<lifeless> there isn't a single- .pack tool, partly because they are not standalone enough for that to be useful in current format
<lifeless> s
<igc> I've added incremental packing to fast-import as lifeless recommended and it does reduce disk space usage
<igc> but ...
<igc> I'm seeing something weird
<igc> emacs has 105K revisions
<igc> after importing 100K of them, the single pack file is 100M - cool
<jam> lifeless: I would like to see "ExistingContent" return the fs hash
<igc> but the pack file generated for the last 5K is 500M!
<lifeless> jam: oh right, it doesn't in the current commit code path either
<jam> but I'm not sure if that would mess things up because you expect only real changes to come out
<lifeless> jam: and I need to figure out why I didn't then
<igc> and it seems that the packs grow bigger as fast-import goes
<jam> UnsupportedOperation(_generate_inventory) seemed dodgy, but as long as it is good enough...
<jam> igc: trees get bigger, packing makes a *large* difference
<lifeless> jam: yeah, I'm unhappy with it, but it seems awfully close to make work to make another exception class
<igc> is that expected? I would have expected the pack for each 10K to be roughly the same size
<jam> I would guess that the new revisions have non-overlapping texts
<jam> such that it all gets inserted as fulltexts to GC
<jam> groupcompress
<lifeless> they may have become more branchy
<jam> igc: 'bzr pack' and 'autopack' make a world of difference
<jam> like 2.3GB => 30MB for bzr.dev
<jam> 500M for 5k is a bit surprising, but not impossible
<jam> I'm assuming that with all packing disabled everything is a fulltext
<jam> igc: Do you (effectively) have 1 call to insert_record_stream per text that you add?
<igc> jam: just wondering out loud whether running pack multiple times in the one process is not releasing something it needs to
<jam> Put another way, do you call add_lines() or do you stream in texts?
<jam> igc: we don't delta between "insert_record_stream()" calls
<jam> even less between pack files
<lifeless> igc: so you need to pack again basically
<jam> (as in, we may at some point delta inbetween insert_record_stream() calls, but we would really *like* to not delta between pack files)
<jam> igc: consider the size of the fast-import stream
<jam> how large is it for those 5k revs
<jam> I would expect brisbane-core without packing to be ~ that size
<igc> jam: I'm using repo.texts.add_lines() to load the texts
<jam> igc: add_lines() does 1 insert_record_stream() per text
<jam> so yeah, you are getting all fully-expanded texts  in the target repo
<lifeless> same as commit
<jam> igc: on the good side, it should make things fast, because we don't spend any time working about those stinkin' deltas :)
 * igc goes to look at the size of the fast-import stream
<lifeless> I think if I was to write a fast import I'd do a 2-pass, pass-1 plan out everything and generate revids etc, pass-2 act like a fetch operation;
<lifeless> then I'd probably get clever and make it look like a repo :)
<lifeless> jam: where are we at for freezing the disk format
<lifeless> I know its alpha, but I'd like to start dogfooding on my laptop; don't want to do that until we're <reasonably> sure its copacetic
<jam> lifeless: well, there is the subtree question
<jam> whether that is a data format bump or not
<jam> and certainly should be answered if you want to dogfood
<jam> 20s to do a no-trees branch in a shared repo is a bit much
<jam> :)
<jam> There is 1 bit I'd like to at least play with to see if we want to change
<jam> it is maybe 4 bytes per record, so 3-4% total size,
<lifeless> so subtrees are in discussion
<jam> nothing huge, but something that is wasteful and easy to remove
<lifeless> whats the thing you want to play with?
<lifeless> I need to lsprof commit to, I am wondering if group overhead is hitting commit
<jam> (each delta record has a "source size" indicator, which isn't useful to us)
<jam> lifeless: I would think commit would do really well with groups, since it doesn't have to delta
<jam> but perhaps to load inventories, etc.
<jam> The stuff about how we want to lay out groups after "bzr pack" isn't a data format bump
<jam> so we are fine there
<lifeless> jam: it has to load the pages that add_inventory_by_delta hits
<jam> If we want a new chk index would be a format bump
<jam> but that is a lot more work
<lifeless> right, but I'm not trying avoid all changes
<jam> and probably won't land in a --dev5
<lifeless> heck I'll have to change when we land --dev-5 as it will have a new string anyhow
<lifeless> I just don't want to dogfood while we are churning
<jam> sure
<jam> I just have the one real data-format thing
<jam> but it keeps getting pushed off because it doesn't seem critical
<jam> I should just do it
<lifeless> what is it
<jam> (delta records have "source size")
<jam> 4-bytes at the start of each delta record indicating the size of the source text they were generated against.
<jam> well ~4-bytes
<lifeless> useful for extraction
<jam> anyway, igc, I was hoping you would be able to bench branch for your python conversion, just to see where I'm at versus .dev
<lifeless> if you delete the tree reference walk in branch, you can do that :)
<jam> For my testing of Launchpad branching, it dropped from ~44min under lsprof down to 14min (12min without lsprof)
<lifeless> jam: I really thought difference_update was only a problem if the rhs wasn't a set
<lifeless> jam: am I wrong?
<jam> lifeless: you are wrong
<lifeless> ok, thanks
<jam> it just uses the Iterator protocol
<jam> .difference() probably cares whether it is a set or not
<jam> .difference_update() seems pretty stupid
<lifeless> I'm amazed
<lifeless> I wonder if we should blacklist difference_update
<jam> lifeless: so... I'm slightly wrong
<jam> I just looked at the code
<jam> if the other is a set
<jam> it uses "set_next()"
<jam> rather than PyIter
<jam> but it still calls "discard_entry" for every entry in the object
<lifeless> thats still size
<jam> yep
<lifeless> its probably because they are mutating the LHS
<jam> it might be *slightly* faster, in that it would have the hash
<jam> lifeless: yeah, you would have to create a temp object, build it, and then overwrite the current set with the temp data
<lifeless> they should at least recast it as self.difference_update(self.intersection(other))
<jam> lifeless: interestingly, that *is* genuinely faster
<igc> jam: I'll run the benchmark now
<jam> at least when "other" is >> larger than self
<lifeless> is it as fast as your .difference using code?
<jam> igc: revno 3916 should have a decent set of updates
<jam> lifeless: I didn't test it in the real-world, but TIMEIT gave equivalent results
<jam> though TIMEIT seems to say that "s = set(small)" takes 9ms, but "s = set(small); s = set(small)" takes 9.5ms
<lifeless> lol
<jam> so I don't entirely trust it
<lifeless> so, I think in C we'd make a list verison of intersect
<lifeless> iterate that without increasing refs
<lifeless> s/iterate/generate/
<lifeless> then iterate it to dec refs in self
<lifeless> should be pretty fast
<lifeless> and possibly only do that when len(other) > 3* len(self)
<lifeless> I wonder if we should write
<lifeless> in e.g. osutils
<lifeless> difference_update(a_set, other_set)
<lifeless> to avoid unclear code and still be fast
<jam> lifeless: so is it "BB:tweak" to use a FIFOCache instead of LRUCache for btree._internal_node_cache ?
<lifeless> yes
<lifeless> long as its capped I'm happy
<lifeless> damn, four test failures in commit_uses_ric that I didn't know about
<lifeless> fixing...
<jam> igc: revno 3916 is 14m under lsprof, down from 44min. And if we can get a better fetch order, it would drop another 3.5min
<jam> My first tweaks are good, the later tweaks only effect really large repos
<jam> s/good/good everywhere/
<igc> jam: that benchmakr is running now - bzr.dev 4208 vs bbc 3916
<igc> jam: give it 10 minutes
<jam> igc: thanks. Note that "bzr branch bzr.dev" is still 2m8s up from 1m16s.
<jam> (but down from ~4min)
<jam> so even fixing the obvious stuff, it is going to be a bit slower
<jam> though maybe not... the overall time in "item_keys_introduced_by" is 52s
<jam> which would bring us very close.
<igc> jam: 68s (bzr.dev) vs 132s (bbc)
<jam> igc: down from ~350s, right?
<jam> igc: this is on python trunk?
<jam> (just surprising, because I'm seeing similar numbers for bzr.dev on my machine)
<igc> jam: yes, down from 357
<igc> python 3.0 branch
<jam> lifeless, igc: question for you guys... If a root node turns out to be a simple leaf node which is redundant with a reference from an internal node you already have, is it a big deal if we transmit it?
<jam> the chances are pretty low
<jam> though it happens to occur in the launchpad history
<lifeless> you mean if someone were to e.g. delete everything leaving a much smaller tree?
<jam> something like that
<jam> If one tree has "aa" and "ab"
<lifeless> I don't really care
<jam> and then we add "bc" causing a split
<jam> then the second tree references a leaf node with just "aa" and "ab"
<lifeless> is this in aid of 'only read once'?
<jam> lifeless: right
<jam> being able to go ahead and transmit the roots
<jam> as we read them
<lifeless> I think its fine if we read a page to transmit it
<jam> so we don't have to try to read them again
<lifeless> 'read a page on the changed side'
<jam> lifeless: right
<jam> iter_interesting_nodes is the only code that buffers records
<jam> and now that I have lazy streaming
<jam> I'd like to get rid of buffering
<jam> because it causes refcycles
<jam> and at the moment
<jam> the only nodes it buffers are the root nodes
<jam> though for a slightly different reason
<jam> but still part of the issue as I rewrite it
<lifeless> are you going for something more similar to iter_changes?
<jam> lifeless: I'm playing around with that
<jam> though it gets hairy when you also try to "read once"
<lifeless> Ideally we'd only have one function
<jam> and "no buffer"
<jam> as well as "read in batches"
<jam> Though I think I can go away from a pure "never read a node I may find is unneeded" by using the fact that we generally have very flat, and very similar shaped trees. so grouping by exact prefix is generally 'good enough'
<jam> rather than worrying about possible longer prefixes
<jam> we'll see
 * jam goes and finds a soft pillow
<lifeless> gnight
<lifeless> I'll drop by tomorrow mornign if you want to chat
<lifeless> -> town, night all
<crisb> is there a way to make a remote branch 'append only'?  Ie for my trunk I dont want someone to be able to push to it if they've synchronised an old version via merge, as it will mess the revision history.
<vila> hi all
<spiv> crisb: yes, there's a setting you can put in the branch.conf
<spiv> crisb: append_revisions_only = True in .bzr/branch/branch.conf IIRC.
<crisb> spiv: cheers, found it in the manual too. rtfm!
<spiv> crisb: :)
<Mez> how do I resolve the conflict
<Mez> RK  connect-config.php => connect-config.php.OTHER@
<Mez> I'm not even sure what the conflict is
<Kinnison> what's the diff between the files?
<lifeless> Mez: thats a rename and a kind change
<lifeless> Mez: or remove + kind change perhaps
<lifeless> one branch made it a symink
<lifeless> one did something different
<Mez> ah fair enough
<Mez> it should be a smylink to be honest
<lifeless> bzr rm the one you don't want
<lifeless> bzr mv the other to the right spot
<Mez> I've just removed it
<lifeless> ciao
 * lifeless waves bye
<thecookie> Hmm, is there any nice stats plugin? Like.. commit stats and such
<spiv> thecookie: there's a basic one at https://edge.launchpad.net/bzr-stats
<thecookie> Thanks :)
<beuno> spiv, lifeless, bzr performance is really starting to shine for remote operations
<beuno> you guys rock
<Tak|work> jelmer: ping
<jam> morning vila
<vila> Hi jam !
<jam> vila: I noticed you have some gc-python-only commits happening :)
<vila> jam: yup, almost up to speed (still not 100% on the subject though :-/)
<vila> but close
<igc> hi jam, vila
<igc> time for bed for me
<jam> hey igc, surprised to still see you around :)
<jam> and off you go
<jam> sleep well igc
<vila> wow igc, try to get some sleep !
<igc> jam: I wanted to get a patch out and it just didn't want to pass all my tests thanks to a bug :-(
<igc> solved now and patch out - hooray!
<jam>  \o/
<igc> jam: thanks for your work on branch speed
<jam> igc: well, it mostly came down to not being something we were profiling, there were a few simple fixes, though there are more that are a bit complex to get right
<jam> 'difference_update' being code that I've known to poor scaling in the past, but sometimes forget
<jam> "known to have poor"
<igc> jam: if you get a chance, I'd really like you to be super brave and stabilise the disk format soon
<igc> jam: I want to convert OOo and I really would like to do that on a semi-stable format
<igc> jam: those big conversions take some time, even with fast-import
<igc> jam: fast-export of mysql from btree format took over 16 hours for example
<jam> igc: fast-export, or fast-import?
<igc> jam: export
<jam> converting mysql took about 44hrs total on my machine
<jam> though memory consumption was up in the 1.8GB until I restarted it
<jam> so I think we have a bit of a leak somewhere
<igc> fast-import of mysql isn't working yet 'cause I think fast-export has some bugs
<jam> (it *did* go back up to 800MB or so)
<igc> it did import 20K+ revisions in 95 minutes though (to gc-chk255-big)
<jam> igc: you *can* just do "bzr init-repo --gc-chk255-big target; bzr branch source target"
<igc> right
<jam> igc: especially given that the conversion is then guaranteed compatible :)
<igc> but I like to stress test fast-export/fast-import to get the bugs out :-)
<jam> I don't know if you preserve revision ids and file-ids across fast-export | import
<jam> igc: I will also say, having 1 export, and then N imports is a nice property.
<jam> as import with CHK is much faster than export from XML
<igc> jam: especially if the export time is the bottleneck
<lifeless> vila: btw, parallel test branch up for review :)
<igc> jam: no preserving of ids yet 'cause it doesn't matter for my testing
<igc> anyhow, night all
<vila> lifeless: Well, I know the code so it's bb:approve from me, I was wondering if I qualify as a reviewer here (I've seen similar situations where co-authored code is reviewed by a third dev)
<jam> vila: we've done it both ways
<jam> I usually try to post it, and wait for feedback in case a 3rd-party case
<jam> cares
<jam> but I'm more willing to merge it anyway
<jam> lifeless: I just sent an email about questions with "insert_record_stream()" checking to see if the key already exists in the target.
<jam> the problem is that we have an explicit VF test that you can send the same records multiple times
<jam> without error
<jam> (random_id=False)
<jam> but branching LP is 2x faster with (random_id=True), because we don't query all the spilled indices
<jam> (the issue is having a .cix with 340k keys as you are copying)
<jam> vila: want to do our phone call?
<jam> I was about to play with changing the byte stream for gc
<vila> sure
<jam> and I realized it is going to effect the work you are doing
<vila> I push what I have and then call you
<vila> jam: pushed, calling
<jam> k
<lifeless> jam: uhm, perhaps check for dups before linking the pack in, rather than on each key
<lifeless> jam: there are some potential attacks if we don'tcheck
<Leonidas> hi, I am trying to add files to a tree but somehow I don't know how to do it. Any tips?
<Leonidas> (I would like to work without a working tree)
<Leonidas> My code currently looks like this: http://paste.pocoo.org/show/109863/
<Leonidas> So I am able to build the revisions and get a repository with all log messages but unfortunately I don't know how to add the actual file contents to the repository
<lifeless> meep, its nearly 2:30
<lifeless> gnight
<lifeless> Leonidas: you really should use commit builder
<lifeless> use a MemoryTree
<lifeless> or a PreviewTree
<lifeless> and call commit() on it
<lifeless> doing what you're doing I can nearly guarantee that your output branch will fail 'check'
<Leonidas> lifeless: what is the difference between a memorytree and a previewtree?
 * Leonidas happily uses that if it is easier.
<lifeless> a memory tree is mutable, you lock it and edit the content
<lifeless> a previewtree is the result of a merge, held in memory
<lifeless> anyhow, I must go sleep
<lifeless> perhaps ask on the list
<Leonidas> ok, thanks
 * Leonidas plays with MemoryTree
<jelmer> Tak|work: pong
<Tak|work> hello
<Tak|work> have you tried my md-bzr branch lately?
<jelmer> Tak|work: No, I've been meaning to give it a try
<Tak|work> ok
<Tak|work> I think it's to the point now where it might be worth submitting it to the MD community addin repo
<jelmer> ah, cool
<jelmer> I'll see if I can give it a try in a couple of hours when I get back home
<vadi2> how do I solve a tag conflict?
<jelmer> vadi2: remove the tag locally and pull again
<jelmer> vadi2: or use --overwrite
<vadi2> I want to overwrite it on the server
<vadi2> how can I do that? I remapped the tag from one revision to another locally
<jelmer> bzr push --overwrite
<vadi2> says no revs to push
<jelmer> vadi2: but did it change the tag?
<vadi2> good question. I think it did actually
<vadi2> thanks!
<Leonidas> strange, when I do a memorytree.put_files_non_atomic(file-id, "something")
<Leonidas> I get this:
<Leonidas> bzrlib.errors.NoSuchFile: No such file: u'/whatsonair/seewhatsonair.py'
<Leonidas> but I added both whatsonair as well as seewhatsonair.py
<james_w> Leonidas: do you have a full backtrace?
<Leonidas> james_w: yes, http://paste.pocoo.org/show/109875/
<Leonidas> starts getting interesting in line 26
<Leonidas> everything above is mercurial stuff
<james_w> Leonidas: did you mkdir the dir in the tree?
<Leonidas> james_w: is 'add' not enough?
<james_w> not sure
<Leonidas> ok, sounds like I know where my problem is, moment..
<james_w> I haven't used MemoryTree, but normal working trees, you first create then file, and then version it with "add"
<Leonidas> hmm, in MemoryTree it looks somehow different
<Leonidas> how can I check whether something exists already (mkdir) or is already versioned (add)
<Leonidas> the latter could be done by path2id which returns none, but I don't know a nicer solution for checking whether a mkdir is neccessary.
<Leonidas> james_w: directories need to be mkdir()'ed and files add()'ed as far as I see. I can't mkdir() and add() afterwards.
<james_w> hmm
<james_w> that sounds odd
<Leonidas> yep
<beuno> jam, hi
<beuno> you mentioned at some point you had a script to recursively pack branches?
<jam> beuno: I'm not sure about "recursively pack", though a simple find + 'bzr pack' would do the job
<beuno> aw, that means I have to brush up on my bash foo  :)
<jam> beuno: find . -path '*.bzr/repository' | sed -e "s#.bzr/repository##" | xargs -n1 bzr pack
<jam> beuno: brushed up enough?
<beuno> jam, :)
<beuno> thanks
<beuno> we should have this on a wiki page somewhere
<beuno> recipies
<vila> jam: gc extraction speed \o/
<jam> vila: yeah, I've known it was good, it is nice to see "just how good" it is.
<jam> and shouldn't you be off with Valentine?
<jam> :)
 * vila runs :)
<beuno_> ah!
<beuno_> when did we make upgrade recursive by default?
<beuno_> it's a fantastic idea
<beuno> man, I'm so in love with bzr today
<fullermd> It is a fantastic idea, but I didn't know that we did.
<fullermd> I was grumbing about it just a week or two ago...
<mrooney> Is there a way to unversion things with a pattern? For example I committed and a bunch of things I wanted to ignore went it, so I did bzr ignore pattern and that is fine, but warns me of all the versioned things with that pattern
<mrooney> How can I tell it to say remove those from VC in the next commit
<mrooney> oh it looks like it has done that for me :)
<mrooney> well it says deleted I hope it doesn't mean that
<Peng_> Eh? upgrade was made recursive by default? Cool!
<fullermd> mrooney: I doubt it would...   my first impulse would be find | grep | xargs bzr rm
<Pieter> bye
<Peng_> jelmer: ping
<jelmer> Peng_: pong
<Peng_> jelmer: This is off-topic, but I just wanted to point out that *!*@rhonwyn.vernstok.nl got banned from #oftc until your connection issues are worked out.
<jelmer> Peng_: ah, thanks
<abentley> jam: It looks like we're doing a case-insensitive match when moving files into directories on all platforms.  (builtins.py:766)  Is that right?
<jam> abentley: from the looks of it, if you do "bzr mv foo bar BAZ" and 'baz' exists as a versioned dir, it will be used
<jam> however, I think that "BAZ" has to hit a "os.isdir()" check earlier
<jam> so on non cicp platforms
<jam> the "into_existing" won't be true
<abentley> jam: BAZ might be an unversioned dir.
<jam> abentley: if BAZ is an unversioned dir, than the "_yield_canonical_inventory_paths" will probably fail
<jam> not positive, though
<jam> I suppose if you had a versioned 'baz' and an unversioned 'BAZ' 'bzr mv foo bar BAZ' might, indeed, move it into the versioned dir
<abentley> jam: Do you agree that we should not be hitting this canonical_inventory_paths at all for case_sensitive filesystems?
<jam> abentley: I don't think there was consensus on that, because of vfat
<abentley> vfat is not case-sensitive, only case-preserving.  On vfat, we should hit that.
<abentley> Or you mean that on Linux, it's actually case-sensitive?
<jam> abentley: so, the last I discussed it was quite a while ago
<jam> I think we talked about moving "case_sensitive" up into Tree
<jelmer> Peng: I've fixed my connection issues
<jam> and then something like "canonical_path" would return the first item or None
<jelmer> Peng: Can you perhaps ask for an unban?
<jam> that said, I'm not really sure, and wasn't the direct reviewer of the code
<jam> so... I could agree with you, but I haven't spent a lot of time thinking about the various implications
<abentley> jam: WT supports it already, and other Trees don't really have filesystems.
<abentley> jam: I would be happy for canonical_path to just return the input on case-sensitive Trees, though.
<vadi2> If a file is deleted locally, how can one get bzr to re-download it? "bzr pull" thinks it doesn't need to do anything
<mrooney> vadi2: have you tried bzr revert file?
<vadi2> no the person just deleted the branch and re-checked out
<vadi2> I'll try that next time though, thanks
<vadi2> (though svn's behavior in this case makes more sense)
<mrooney> if it was a checkout, pull isn't going to do anything
<mrooney> your language is conflicting "deleted the branch" "re-checked out" so I am not sure if you were actually dealing with a branch or checkout :)
<mrooney> or, maybe I am wrong about pull?
<mrooney> oh, he is gone
<lifeless> vila: ping
<blueyed> I'm having problems with tailor, which appears to want remove files which are not versioned (anymore). Can I filter those out somehow in bzr?
<blueyed> The following is the log snippet, including the traceback: http://pastebin.com/m33875e52
<blueyed> It seems like those files have been removed in the commit before, but (also?) in the next one (CVS sucks after all).
<lifeless> you might have better results with bzr cvsps-import
<blueyed> That had other issues IIRC. I'm currently looking into ignoring unversioned files in BzrWorkingDir._removePathnames
<furlith> Hi all, I need to download the last version of a project using bazaar, I never used it so I quickly read the user guide to know what I should to get it but it doesn't work
<furlith> I've made this: "bzr branch [url]" but i have this error: bzr: ERROR: Not a branch: "http://trunk.ocaml-gnuplot.bzr.sourceforge.net/bzr/trunk.ocaml-gnuplot".
<furlith> could anyone help me?
<Peng_> furlith: Bazaar is telling the truth. That URL is not a branch. It's a redirect to SourceForge's homepage.
<Peng_> furlith: You can see the Bazaar web viewer at http://ocaml-gnuplot.bzr.sourceforge.net/bzr/ocaml-gnuplot/ , but I have no idea where to get the branches.
<Peng_> SourceForge--
<blueyed> furlith: you prolly need to find the correct URL to branch from.
<lifeless> furlith: http://sourceforge.net/scm/?type=bzr&group_id=115637
<lifeless> Peng_: ^
<Peng_> lifeless: Oooh, where'd you find that URL?
<lifeless> bzr://ocaml-gnuplot.bzr.sourceforge.net/bzrroot/ocaml-gnuplot
<lifeless> Peng_: project, then svn repo, then url hacked to bzr
<lifeless> :P
<Peng_> lifeless: Ah, smart.
<blueyed> Peng_: see the "Code" tab on SF.net
<blueyed> https://sourceforge.net/scm/?type=bzr&group_id=115637
<Peng_> blueyed: Oh! You click on "More", which magically makes the other tabs appear.
<Peng_> I didn't know that.
<Peng_> I just moused-over "More", which linked to the main page, so I didn't click it.
<blueyed> yep. strange thing that is.
<Peng_> Interesting that SourceForge uses bzr:// for anonymous access.
<Peng_> Wait, that's dumb. The website just links to bzr://ocaml-gnuplot.bzr.sourceforge.net/bzrroot/ocaml-gnuplot , which is the shared repo, not an actual branch.
<Peng_> furlith: bzr branch bzr://ocaml-gnuplot.bzr.sourceforge.net/bzrroot/ocaml-gnuplot/trunk/
<furlith> Peng_: thanks but I have an empty directory and this error: bzr: ERROR: KnitPackRepository('file:///home/maelick/plot/gnuplot/.bzr/repository/')
<furlith> is not compatible with
<furlith> RemoteRepository(bzr://ocaml-gnuplot.bzr.sourceforge.net/bzrroot/ocaml-gnuplot/.bzr/)
<furlith> different rich-root support
<Peng_> Uh.
<Peng_> furlith: What version of bzr?
<Peng_> furlith: Did you create a shared repo for the project? If so, run "bzr upgrade --rich-root-pack".
<furlith> thanks it works :)
<Peng_> Uh, I hope he didn't have anything else in that shared repo.
<Peng_> Oops.
<fullermd> Oh well, it'll resolve itself when we release 1.2 or 1.3 and have rich roots by default.
<lifeless> fullermd: be nice
#bzr 2009-03-28
<ricardokirkner> hi. I am about to create a shared repo in order to track a svn project. I wanted to know, which one is the recommended repo format? (I see there is a --subversion repo format, although I am not sure how I should use it, as it really creates a subversion repository, instead of a bzr shared repository)
<ricardokirkner> I am using bzr 1.13 and bzr-svn 0.5.3
<garyvdm> ricardokirkner: I assume that --subversion will create a bzr shared repo, in the format recommended for storing svn branches.
<garyvdm> I'll check
 * fullermd wouldn't be so sure.
<fullermd> ricardokirkner: Who all needs to be able to access it, and how ancient are their bzr versions?
<ricardokirkner> fullermd, right now it's just for me in order to use bzr to track and contribute to a project that is hosted on a svn repo
<fullermd> If you can assume (or dictate) that anybody accessing it uses 1.9 or later, 1.9-rich-root is what you want.
<fullermd> Which is sounds like is the case.
<ricardokirkner> fullermd, anybody accessing what? the shared repo I am creating?
<ricardokirkner> I could do that, as it will be only me
<ricardokirkner> what's the difference between 1.9-rich-root and rich-root / -rich-root-pack?
<ricardokirkner> (featurewise)
<fullermd> Feature-wise?  None.
<fullermd> 1.9-rich-root is a variant of the 1.9 format that supports rich roots.
<fullermd> Rich root pack is the similar counterpart to pack-0.92.  rich-root is something you just want to stay the heck away from.
<fullermd> It doesn't serve any practical purpose.
<ricardokirkner> fullermd, alright... so, right now the best format (regarding performance and future compatibility) for svn branches
<ricardokirkner> is 1.9-rich-root
<ricardokirkner> i will use that..
<ricardokirkner> thank you
<fullermd> Yah.
<fullermd> Only reason to back up would be to handle older bzr versions.
<ricardokirkner> ok, no prob... I can dictate bzr>1.9 for this
<ricardokirkner> thanks
<garyvdm> Is there a way to see how big a branch is on launchpad before you fetch (branch) it?
<garyvdm> I need to branch lp:mysql-server/6.0 to try reproduce a bug in qbzr, but I'm worried I going to hit my adsl cap :-(
<lifeless> bzr info -vv might
<lifeless> its abot 600MB
<garyvdm> Eish!
 * garyvdm hits ctrl-c
<garyvdm> I'm asking for someone to do a big faviour for me. If you have copy of the mysql-server/6.0 and you are running qbzr trunk, please try and confirm Bug 349673.
<ubottu> Launchpad bug 349673 in qbzr "MYSQL/BZR P3: "bzr qlog FILE" misses many revisions" [Undecided,New] https://launchpad.net/bugs/349673
<lifeless> perhaps ask on the list? at least some of the mysql folk read it, I believe
<garyvdm> ok
<thumper> garyvdm: do you think it'd be a good feature to have the repo size shown in LP?
 * thumper wonders
<thumper> garyvdm: if so, plz file a bug on launchpad-bazaar :)
<garyvdm> Ok
<lifeless> thumper: bit tricky with stacking :)
<lifeless> vila: https://code.edge.launchpad.net/bzr-ec2test
<lifeless> jml: https://code.edge.launchpad.net/bzr-ec2test
<bob2> how fast?
<lifeless> with 2 instances, if they  are already up and running, 1m35
<bob2> spiffy
<lifeless> yeah
<lifeless> next month I'll do another 20 instance trial
<meoblast001> hi
<meoblast001> does anyon eknow how to delete a bazaar revision from launchpad/
<meoblast001> bzr: ERROR: Could not install revisions: meoblast@aol.com-20020101213319-n82drkov5a6ct5st
<meoblast001> how do i fix that
<bob2> how did you trigger it?
<meoblast001> bob2: modifying .bzr files and trying to push
<meoblast001> don't worry... i fixed it
<spiv> !
 * wgrant points out .bzr/README
<meoblast001> wgrant: yeah... i thought i had to fix something in there
<meoblast001> but i ended up backing up revision 11
<meoblast001> fixing the whoami
<meoblast001> reverting to revision 10
<meoblast001> overwritting in launchpad; then restoring backup and pushing
<meoblast001> i've gtg
<meoblast001> bye
<alf> Hello, for some days now I am experiencing extreme slowness when pushing to lp using 1.13rc1. Has lp upgraded to a 1.13 server?
<wgrant> alf: No - it will upgrade on the 1st of April.
<wgrant> Then things should speed up, or so I hear.
<cammoblammo> Is anyone havng trouble pulling from the bzr repo at http://bazaar-vcs.org/bzr/bzr.dev/ ? I seem to freeze after a few minutes.
<cammoblammo> I had this issue a week or so ago, but deleting my branch and pulling a completely fresh one fixed it for a bit.
<lifeless> cammoblammo: its not frozen, just we haven't polished the new fetch codes progress marker
<lifeless> the spinner will be spinning
<lifeless> if it is frozen please be sure to get a backtrace when you intererupt it
<cammoblammo> lifeless: Hmm. It seemed to freeze completely. It goes for a minute or two than nothing for an hour. How do I get the backtrace?
<lifeless> nothing for an hour certainly seems borked :P
<lifeless> hit ctrl-\
<lifeless> then type
<lifeless> bt<ENTER>
<alf> wgrant: thanks, I just used bzr.dev and it seems to perform better than 1.13 on a non-1.13 server
<lifeless> yes, we fixed a long standing bug which 1.13 made more obvious, in 1.14
<cammoblammo> lifeless: Where should I paste the backtrace?
<lifeless> however when lp upgrades on the first it will run a totally different code path, which streams and is much faster
<lifeless> cammoblammo: somewhere I can see it :)
<lifeless> cammoblammo: if this is happening regularly, I suggest a bug report
<alf> hmm, I just tried to branch lp:bzr using bzr.dev and it crashed with a "ErrorFromSmartServer: Error received from smart server: ('NoSuchRevision',)"
<cammoblammo> lifeless: I'm happy to file a bug report if necessary. In the meantime, I've put up the backtrace (I think!) at http://pastebin.com/m6404b8e6
<spiv> alf: strange!
<spiv> alf: I'll try that.
<spiv> alf: hmm, I think it's the recent get_parent_map RPC changes.
<spiv> lifeless: ^ NoSuchRevision with from get_parent_map RPC doing "bzr branch lp:bzr", I guess the key count in the serialised search is wrong somehow?
<spiv> lifeless: weirdly it doesn't fail until the 4th get_parent_map call
<spiv> (on the 3rd with a non-empty request body)
<spiv> alf: thanks for the bug report, that does seem to be a regression in bzr.dev
<spiv> alf: Oh, in case I wasn't clear, yes I can reproduce it too.
<alf> spiv: ok, thanks!
<antoranz> Hi, guys!
<antoranz>  know this is not a git forum, but they didn't help me an gits forum and it's a very simple question
<antoranz> what's the equivalent in git to bzr revert -r -2?
<james_w> something with reset I think
<mathrick> hiya, bzr just started dying on serve
<mathrick> it's the ipv6 sockname problem again
<mathrick> I remember it happening before
<mathrick> http://pastebin.com/m1b93a98c
<gutworth> has the bzr.dev format changed?
<mwhudson> lifeless: have you encountered tokyo cabinet in your data persistence travels?
<johnjosephbachir> Does bzr do anything intelligent with inter-line whitespace changes? and/or, where can i read more about this. :) thanks
<johnjosephbachir> or actually, inter-ling changes at all. for example, i change "foo bar baz" to "foo-prime bar baz", and then a merge from parent changes the same line to "food bar-prime baz", can the bazaar merge result in "foo-prime bar-prime baz" ?
<johnjosephbachir> gah, typos. "inter-line" in the beginning, and "foo bar-prime baz" in the third quoted string
<mwhudson> jelmer: hello
<mwhudson> jelmer: i think bzr-git is generating corrupt data
<mwhudson> jelmer: http://pastebin.ubuntu.com/139834/
<lifeless> mwhudson: I hadn't no
<mwhudson> lifeless: i don't know how relevant it is for bzr-search etc
<lifeless> spiv: interesting
<lifeless> mwhudson: its not :)
<mwhudson> but it makes a heck of a lot more sense for what i'm doing with sqlite in loggerhead than sqlite
<lifeless> mwhudson: no python bindings according to http://tokyocabinet.sourceforge.net/spex-en.html, and no obvious way to hack the backend for transports
<mwhudson> lifeless: there's python bindings called pytc
<lifeless> ah ok
<mwhudson> lifeless: no idea of kwality
<lifeless> sqlite has benched faster than similar things; I wouldn't assume its worse
<mwhudson> and might make sense for jelmer too
<mwhudson> i dont know what it's concurrency behaviour is like
<lifeless> tokyo cabinet is one-process per db
<mwhudson> ah
<mwhudson> i guess their concurrency story is "tyrant
<mwhudson> "
<lifeless> hmm I may be wrong
<lifeless> its hard to read janglish
<lifeless> As with QDBM, the following three restrictions of traditional DBM: a process can handle only one database, the size of a key and a value is bounded, a database file is sparse, are cleared. Moreover, the following three restrictions of QDBM: the size of a database file is limited to 2GB, environments with different byte orders can not share a database file, only one thread can search a database at the same time, are cleared.
<lifeless> it does explicitly support concurrent threads
<lifeless> In cases that multiple processes access a database at the same time or some processes access a database on a remote host, the remote service is useful.
<lifeless> found it
<lifeless> so, one process per db full stop, but there is a server
<lifeless> myself, I'd tend to use sqlite
 * mwhudson sighs at http://bazaar.launchpad.net/~vcs-imports/nunit-2.5/trunk/changes?filter_file_id=srcnunittestservernu-20081008020403-2ajrt9spm9ob8qah-96
<lifeless> sadness
<mwhudson> i guess the file is deleted in tip or something
<lifeless> in tree None is a hint
<lifeless> speaking of unit test frameworks - http://bazaar.launchpad.net/%7Elifeless/subunit/polish/annotate/head%3A/c//check-subunit-0.9.6.patch
<mwhudson> lifeless: gnu check?
<lifeless> http://check.sourceforge.net/
<chronos> hello for everyone
<chronos> I installed now bzr on my gentoo and i getting this error when try to login on launchpad: http://rafb.net/p/prmVYo69.html
<chronos> someone have idea how fix?
<lifeless> install the standard certificates for curl
<lifeless> I don't know how to do that on gentoo
<chronos> I will check lifeless , thx
<chronos> lifeless, how you do in other distros?
<chronos> lifeless, found :), instal ca-certificates
<chronos> thx
<lifeless> spiv: yes, smells like our change is at fault
<mwhudson> vila: tentative ping?
#bzr 2009-03-29
<stopie> Hey all. Just learned of bazaar and find it to be a very vague concept in my mind and Ive done some looking for information on wiki and the bar webpage, and its not helping. I was wondering if anyone had a link to some information that might help explain how bzr does what it does and such. Thanks!
<johnjosephbachir> stopie: have you used other SCMs before, like subversion or cvs?
<devilsadvocate> hi. can someone point me to a document which describes why version control is required? I need to convince a team that its needed.. would be nice to have all the arguments in one place
<cody-somerville> Theres a team that doesn't think its needed? :S
<cody-somerville> http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf <-- heres a good resource
<devilsadvocate> i really dont know what to do other than bang my head against a wall
<lifeless> devilsadvocate: are you the team lead?
<devilsadvocate> they want to do file renaming on ftp, etc
<devilsadvocate> not the lead, but its my responsibility to make sure different parts of the system work together, etc
<lifeless> devilsadvocate: well, if folk want to do it hard, and the lead agrees, just use bzr yourself
<devilsadvocate> and i also am the one with the most experience in writng actual code, so i have a feeling i'll be doing a chunk of that work as well
<lifeless> and show it off when ever a suitable time happens
<lifeless> it will spread ;)
<devilsadvocate> the suitable time has already happened
<devilsadvocate> we ended up submitting a report that had different sections at different levels of recent, since it turned out people were editing different docs
<devilsadvocate> and the argument that is used against it is that "we wont be able to make people wont use it"
<devilsadvocate> cody-somerville, thanks for the link. it might just be enough to tip it over the edge (added to my threat of leaving the project)
<bialix> garyvdm: ping
<garyvdm> Hi Alex!
<garyvdm> bialix: pong
<bialix> hi Gary
<bialix> can you teach me about qlog internals a bit?
<garyvdm> Sure - Thats why I did that review - and did not just fix
<bialix> thank you
<bialix> in log.py I see method update_search
<bialix> there is special code paths for revid and revno
<bialix> do you want me to place tag filter there?
<garyvdm> We could.
<garyvdm> It depends on how you want it to behave
<garyvdm> for revid and revno - we don't filter - we just jump to the revision - cause there will only ever be 1
<bialix> my intent to provide the search for specif tags
<garyvdm> For tag - your search might
<garyvdm> brb
<garyvdm> sorry - I'll be back in 10 min
<bialix> btw, search for tags has one weak place: if tag in merged revision then it still collapsed. how can I force it to be visible?
<bialix> ok
<rusty> Dumb q: what's the best way of showing a change, ie. log + diff?
<bialix> log -p
<rusty> bialix: not in 1.6.1?
<bialix> rusty: nope
<bialix> upgrade?
<bialix> garyvdm: perhaps I understand your suggestion: I need to use self.sr_index_matched_revids dict, and fill it with matching keys. Is that right?
<rusty> bialix: thx, but sticking with ubuntu default pkgs.
<garyvdm> bialix: Yes- if you want to filter.
<bialix> btw, there is something strange
<garyvdm> For revno, revid - we select, and not filter.  For message, author, we filter
<bialix> you're using self.sr_filter_re and self.sr_filter_regex in the same time
<bialix> in constructor you define self.sr_filter_re
<garyvdm> Oh
<bialix> it seems like a typo or bug
<garyvdm> self.sr_filter_re is the one that gets used. I'll fix that though.
<bialix> I have working filter for tags: http://pastebin.com/m4a3a752c
<bialix> garyvdm: how can I force merged revision to be visible?
<garyvdm> Ah
<bialix> um?
<garyvdm> http://pastebin.com/d2cb3b507
<garyvdm> You need to set self.branch_lines[branch_id][1] = True
<garyvdm> For the revisions, and the revisions that merge them
<garyvdm> recursively
<bialix> oh
<bialix> it will play badly with multiple branches?
<garyvdm> No
<garyvdm> See invaladate_filter_cache_revs to see how I find the revisions that merge them.
<garyvdm> back in 1min
 * bialix -> lunch, back in 20 min
<garyvdm> bialix: Please don't use sr_index_matched_revids. Create a new field, say sr_tag_matched_revids
<bialix> why?
<garyvdm> bialix: To make it easier to understand / read.
<garyvdm> It will work just as well if you don't.
<bialix> will do
<bialix> I'll send the patch for review
<Tecan> how would i check this repository out ? https://launchpad.net/alarmclock
<lifeless> typically you can just do bzr branch lp:alarmclock
<Tecan> cool it worked ;)
<Tecan> but with a dash in it
<Tecan> alarm-clock
<Tecan> i'm starting to like bzr alot. the website looks/works like a few million dollars
<xiaohui> hi, I am a newbie of bzr, could some tell me how to make a patch
<xiaohui> which command should I use
<jpds> xiaohui: 'bzr diff' will show you what uncommited changes you have.
<jpds> You can redirect it to a new file with: bzr diff > my_patch1.diff
<xiaohui> oh , thank you jpds
<luks> or better, commit them and use: bzr send -o mypath.diff
<jpds> luks: Oh, did not know that, thanks.
<luks> this is dvcs, offline commits are one of it's main point :)
<luks> and if the upstream is using bzr, they can just use bzr merge/pull mypatch.diff
<xiaohui> jpds: I have done as your said , but I havn't seen the patch show the info about the added file
<bob2> welcome to patches
<bob2> what's the patch for?
<luks> xiaohui: did you 'bzr add' the file?
<luks> and seriously, use bzr send
<xiaohui> oh  luks , I haven't do that
<xiaohui> I just used the bzr from this moring
<luks> the usul way of contributing patches to a project using bzr is to branch the remote branch, work on the branch, make a commit, bzr send the resulting patch
<luks> the patch produced by bzr send will then contain your name, the commit message, etc.
<luks> and the maintainer will just merge it like if it was a normal branch
<luks> *ussual
<luks> bah, I can't type
<xiaohui> it works, thank you guys
<xiaohui> I will read the document later
<magcius> How do I change the default push location for a branch?
<bob2> edit .bzr/branch/branch.conf or bzr push --remember somethingelse
<magcius> Is the --remember switch documented?
<bob2> bzr help push
<jrib> hi, is there a gui frontend for bzr on os-x?  I want to use bzr on a project, but I need to provide a nice gui for my friend on os-x or he will refuse :)
<jrib> Is there some way to configure bzr so that if I do Â« bzr branch foo Â», then it remembers the parent branch as the push location so that I can do Â« bzr push Â» without having to specify where I want to push?  In short, I want to be able to do: Â« bzr checkout foo; *hack*; bzr push Â», instead of: Â«bzr checkout foo; *hack*; bzr push foo Â»
<jrib> erm.  s/checkout/branch
<bob2> no
<jrib> Is there a reason other than "no one has contributed the code" why that is?  Or at least why a configuration setting does not exist?
<cody-somerville> jrib, probably to prevent accidental pushing
<cody-somerville> jrib, however, I'm pretty sure checkout does remember. Infact, with a checkout, when you commit, you're committing to the remote branch
<cody-somerville> Whereas branch is actually creating a new branch that you commit to
<jpds> jrib: bzr push :parent
<cody-somerville> thats a neat trick
<jrib> jpds: that will do, thanks
<jpds> 'tis a nifty shorthand, true. :)
<jrib> is there a gui frontend for bzr in os-x?
<cody-somerville> I think there is good bzr integration with netbeans
<jpds> jrib: Looks like QBzr runs on it: http://bazaar-vcs.org/MacOSXBundle
<jrib> thanks again
<BlackLukes> hi, I added a .bzrignore file in my project directory and typed on the terminal "bzr ignore ./config.cfg"
<BlackLukes> but I got this: "Warning: the following files are version controlled and match your ignore pattern: config.cfg"
<BlackLukes> if I write bzr ignored, config.cfg is not showed. what should I do to ignore it?
<LarstiQ> BlackLukes: euh
<LarstiQ> BlackLukes: the warning tells you that the file is under version control
<LarstiQ> BlackLukes: in which case, even if it matches an ignore rule, it will not be ignored.
<BlackLukes> I have to keep it under version control but it should ignore changes
<LarstiQ> that doesn't make a lot of sense
<LarstiQ> BlackLukes: if you're not interested in versioning it, why keep it under version control?
<BlackLukes> no it's not that case
<BlackLukes> I have a configuration file that shouldn't change if a developer commit a changes to other files that automatically changes the configuration file (it's system dependent)
<LarstiQ> BlackLukes: so, why does it need to be versioned in the first place then?
<BlackLukes> I have to keep the default value every time the application run.. if a developer commit a change, the conf file is changed so I have to manually change the conf file to default values
<LarstiQ> BlackLukes: ignores do not work the way you seem to want to use them, and I don't completely understand your situation so have trouble recommending a solution
<BlackLukes> yeah you're right, it's very difficult to explain and maybe it's even an incorrect thought. I'll try to do a code workaround
<stbuehler> just rename the file in version control to "config.cfg.default"
<BlackLukes> and then I have to put under version control.. but what if I want to keep it unchanged?
<LarstiQ> BlackLukes: as stbuehler said, a common pattern with config files is to version a template, copy that to something unversioned (and ignored), changes to that won't propagate
<BlackLukes> ah yeah that make sense
<BlackLukes> thanks, I'll do in this way
<LarstiQ> BlackLukes: ok, I hope that solves your use case :)
<stbuehler> another idea (if you have "include" available for your configs), is to have a versioned "config.default" and a "config"; the "config" includes "config.default" and tries to include "config.custom" if it exists
<BlackLukes> yeah, another good way. I think I can do this also through code
<Flare-laptop> How can I fix these errors: http://flare183.pastebin.ca/1375983
<SamB> [#|                  ] None ?   3257KB    24KB/s | copying revision 176/2287
 * SamB wonders if he needs to pull a new version of bzr-svn
<SamB> Flare-laptop: did you actually install bzr?
<Flare-laptop> SamB: Yeap
<SamB> where is bzrlib?
<Flare-laptop> And it gives me this crap too: ImportError: Bad magic number in /usr/lib/python2.5/site-packages/bzrlib/__init__.pyc
<SamB> OH
<SamB> maybe try reinstalling?
<Flare-laptop> ...
<Flare-laptop> Ok, I'll try that
<Flare-laptop> fail
<Flare-laptop> It still gives me the same error
<SamB> still bad magic number?
<Flare-laptop> Yeap
<SamB> that's not good
<Flare-laptop> Yeah I know
<Flare-laptop> It works fine on my Ubuntu Laptop, but not on my Arch Linux Server
<Flare-laptop> :(
<SamB> % python --version
<SamB> what's the output for you?
<Flare-laptop> Python 2.6.1
<SamB> oh.
<Flare-laptop> I have BOTH python 2.5 and 2.6 installed
<SamB> and what is the shabang line on bzr?
<Flare-laptop> Sorry for the cpas
<Flare-laptop> caps*
<Flare-laptop> shabang?
<SamB> the first line
<SamB> it has a "#!" at the beginning
<Flare-laptop> I'm confused
<SamB> i.e., run "head $(which bzr)"
<SamB> read off the first line
<Flare-laptop> oh ok
<Flare-laptop> hold on
<Flare-laptop> Output: http://flare183.pastebin.ca/1375998
<Flare-laptop> SamB: ^^
<SamB> okay ... so it looks like you have python 2.6 trying to load bytecode compiled by python 2.5
<Flare-laptop> Yeah, and I'm also having problems with my supybot not wanting to load either
<SamB> out of the python 2.5 library directory, no less ...
<Flare-laptop> Same problem too, I think
<SamB> what does "echo $PYTHONPATH" tell you?
<SamB> oh, btw, this is the shabang line:
<Flare-laptop> Ok, here is stupid part; when I go to install supybot, it installs python2.6
<SamB> #!/usr/bin/python
<Flare-laptop> hold on
<Flare-laptop> ahh ok
<SamB> called that because it starts with a sharp and a bang
<SamB> (# and !)
<Flare-laptop> lol like crunchbang
<Flare-laptop> whoa wt*
<Flare-laptop> [jesse@flare183 ~]$ echo #PYTHONPATH
<Flare-laptop> [jesse@flare183 ~]$
<Flare-laptop> There's nothing there!
<SamB> er, $, not #
<Flare-laptop> oops
 * Flare-laptop facepalms
<SamB> hehe
<Flare-laptop> :S
<Flare-laptop> Same thing
<SamB> oh, okay
<SamB> that is very wierd ...
<Flare-laptop> I agree
 * Flare-laptop wishes he had enough RAM to install Ubuntu Server
<garyvdm> jam: Please can I chat to you about Bug 350796?
<ubottu> Launchpad bug 350796 in bzr "merge_depth from merge_sorted_revisions incorrect." [Undecided,New] https://launchpad.net/bugs/350796
<SamB> maybe you should ask in a forum (channel, mailing list) for Python on Arch
<Flare-laptop> alright
 * SamB wishes the gcj runtime library on Debian was in smaller pieces ...
<Flare-laptop> SamB: But what exactly should I say/put on the forums?
 * cody-somerville pouts at how difficult git is.
 * cody-somerville huggles his bzr.
<magcius> Why does bzr try to push through http on Windows?
<magcius> Instead of through bzr+ssh?
<magcius> Is pushing through http even possible (Launchpad here)
<jelmer> magcius: are you specifying a http:// url?
<magcius> jelmer, lp:*
<jelmer> magcius: it will use http:// if you haven't logged in
<jelmer> try "bzr lp-login"
<magcius> jelmer, he tried it.
<magcius> bzr noobie here
<magcius> I did a bzr pull, now how do I merge the changes with the local working copy?
<jelmer> magcius: bzr pull will automatically update the working tree
<magcius> jelmer, hmm...
<magcius> jelmer, it didn't appear to change anything in emacs.
<magcius> jelmer, bzr says to use "merge" then "push". Even after I do that it does the same thing.
<magcius> jelmer, oh, I had to merge, commit, then push.
<magcius> Just a usability issue, that's all.
<jelmer> magcius: "bzr pull" only works if you are behind on the branch you're pulling from, not if you have any local commits
<jelmer> if you have any additional commits locally, you have to merge
<magcius> jelmer, yeah, I fixed the pull issue. I am trying to push, it said to "merge" then "push"
<magcius> I had to merge, then commit, then push.
<magcius> Just an unhelpful error message, that's all.
<magcius> Is there a quick how-to on bzr merging?
<stbuehler> jelmer: just wanted to give some feedback: bzr dpush does *not* give you the svn-revisions back, even if you had new commits pushed to upstream svn
<stbuehler> perhaps that works if you never used the normal push, didn't try that
<bob2> magcius: maybe in the user's guide - it's mostly just a matter of 'merge, fix any conflicts, commit', though
<lifeless> jelmer: ping
<lifeless> jml: ping
<jml> lifeless: pong.
<jml> lifeless: I'm on a call with thumper at the moment.
<lifeless> I have a tiny review I'd like done when you can - lp:subunit, the polish branch. Its a no-brainer
<lifeless> I just got a mail titled 'using SubUnit for Python on Parrot' :)
<jelmer> lifeless: moin
<jelmer> lifeless: one sec
<lifeless> jelmer: hi
<lifeless> jelmer: subunit, you put up an RFP
<jelmer> lifeless: ah, yeah
<lifeless> jelmer: its come a ways since then, and with my polish branch installs correctly AFAICT
<jelmer> lifeless: did you request a merge or anything for the polish branch?
<lifeless> yes
<jelmer> lifeless: since I didn't see any email yet
<lifeless> are you suscribed to trunk for reviews
<jelmer> ah, probably not
<lifeless> https://code.edge.launchpad.net/subunit/+activereviews
<jelmer> thanks
<jelmer> hmm, subunit developers is the standard reviewer for lp:subunit
<lifeless> subscribe to trunk
<lifeless> the default subscribtion status changes when reviews were added
<lifeless> s/changes/changed/
<lifeless> existing subscriptions were not updatd
<jelmer> ahh
#bzr 2010-03-29
 * mwhudson attempts to figure out how releases on launchpad work these days
<jelmer> Tak: it's sometimes mentioned in the NEWS file
<jelmer> Tak: I'm not seeing anything on Lucid
<Tak> I thought maybe there was a change in the embedding api, or that I've been Doing It Wrong in a way that just didn't break before (md-bzr), but then a google search is gives hits for similar issues with a fair number of python apps
<Tak> (not that I couldn't still be doing it wrong)
<Tak> cool, so the api change was 2.1.0b1 - thanks
<defn> hi everyone.  I am new to bzr and I have a question...  Basically I have this external "branch" which hooks into a larger repository externally -- i would like to do development on my branch locally and then "commit" only to my branch on the remote shell
<defn> how does one go about "committing" to a branch
<defn> if you have any suggestions for doing local development and then getting those changes under version control please let me know
<jelmer> defn: I'm not sure I understand what you're trying to do
<defn> jelmer: me either! :)
<Tak> jelmer: btw, I'm seeing the filehandle leak on both sid and osx 10.6
<jelmer> defn: you'd like to do a partial checkout of a remote repository basically?
<jelmer> Tak: I'm not claiming it doesn't exist on lucid, just saying I haven't seen it yet :-)
<jelmer> s/seen/noticed/
<jelmer> 'morning Ian!
<igc_> hi jelmer
 * Tak nod
<defn> jelmer: hmm, im just sort of confused on how my repo was setup initally -- let me do some digging for how it was created and then let me rephrase :)
<poolie> hi
<jelmer> moin poolie
<poolie> hi there
<igc_> hi poolie
<poolie> hi
<igc_> poolie: Windows installers built and uploaded for 2.0.5 and 2.1.1 over the weekend
<poolie> yay
<poolie> how hard/easy would it be to do a 64-bit windows build?
<poolie> people have asked a few times
<poolie> jelmer, igc_: i think my mail about plugin compatibility was too braindumpy; nobody replied yet
<lifeless> poolie: I haven't seen it
<poolie> but what would you two think about 1- having a blacklist in bzrlib to make it more symmetric
<lifeless> but it sounds like something I'd have an opinion on
<poolie> heh, it does, doesn't it :)
<poolie> 2- making the failure less noisy
<fullermd> I fear that sort of blacklist.  It's got a neon sign above it saying "Ask Me About Being Out Of Date"
<lifeless> fullermd: depends how its phrased and populated
<lifeless> fullermd: if it was 'plugin X < Ver-Y is bust' then its not stale daya
<lifeless> < very-Y will stay bust
<lifeless> s/day/data
<poolie> right
<poolie> it may be that we add the faciliity and don't make use of it
 * fullermd confiscates lifeless's 'y' key for rampant misuse.
<lifeless> poolie: I don't know how quiet you want to go. I think a broken plugin should be listed on every invocation of bzr.
<poolie> we could put it only in 'bzr plugins'
<lifeless> even though its noisy, its an aberrant situation.
<lifeless> and crucially its not easily discoverable
<poolie> we may just substitute wonders about why something broke though
<poolie> right
<poolie> so i think the main thing is to only be giving warnings if the plugin actually would not work
<lifeless> hmm
<lifeless> we could
<poolie> ie eliminate both type I and II errors
<lifeless> if exiting with non-zero (e.g. NotBranchError, NoSuchCommand etc)
<lifeless> also show broken plugins
<fullermd> That could get irritating in the case where the user can't do much about it though.
<poolie> mm
<lifeless> 'svn:///host/path is not a branch\nWarning: plugin bzr-svn failed to load. See ~/bzr.log for details.'
<fullermd> They can wind up with nothing to do but set whatever that env var is to disable a plugin, which then becomes an eternally-encysted part of the env.
<lifeless> fullermd: so, if they are running a non-installed bzr, they can set BZR_PLUGINS_PATH to control the plugins, without disabling just-one
<fullermd> I was thinking more the case of running an _installed_ bzr, with installed b0rked plugins.
<lifeless> fullermd: so, a sysadmin fail ?
<fullermd> In a hard or soft sense, yes.
<fullermd> I tried fixing such things, but I ran out of bullets   :)
<lifeless> poolie: anyhow, I think both your 1 and 2 could be good
<lifeless> though I haven't [yet] read the mail to know the context.
<lifeless> fullermd's concern about staleness of data would be something to cater for in the blacklist design.
<igc_> poolie: I'm yet to read it sorry
<igc_> poolie: I scanned it and it had good ideas IIRC
<igc_> poolie: no opinion on 64-bits builds currently
<GungaDin> how can I merge just a couple of directories into a branch?
<bob2> with difficulty
<bob2> (assuming the changes are in changesets that altered other files)
<bob2> you can merge + revert the bits you don't want (but then the other bits will never be merged)
<lifeless> huh
<lifeless> easy
<lifeless> bzr emrge branch/dir1
<lifeless> bzr merge --force branch/dir2
<lifeless> bzr commit
<lifeless> note though, that like *all* partial merges, it won't be recorded as a merge.
<mbohun> what is the proper way to rename/move A.c to B.c and B.c to A.c ?
<Peng> "bzr rename"?
<fullermd> Use an intermediate name and 3-step it.
<fullermd> Or use the `bzr xor` trick...    ;>
<Peng> Oh. You can't do it in one step?
<fullermd> How would you?
<Peng> Err, sorry.
<Peng> I was thinking, like, commit wise. Some VCSes don't let you do something like that in one revision.
<mbohun> that's what i m wondering, though my example was a bit retarded in fact i have to version of the same html page: index.html and index2.html (index.html being the default) - now i want to swap them so index2.html is going to be the default index.html
<fullermd> bzr mv index.html tmp ; bzr mv index2.html index.html ; bzr mv tmp index2.html
<lifeless> Peng: one commit is fine.
<fullermd> You can do it all in one rev, sure.  I've...  well, I've never done that, but I've moved a file and then created a new file with the old name a lot.
<mbohun> fullermd: thanks
<Guest87486> Hiya  an a Sunday nite! If I 'bzr branch aRepo', then 'bzr mv aRepo/someDir aRepo/newDir', does 'bzr merge aRepo' automagically put changes under version control in the original source's aRepo/someDir in the *renamed* aRepo/newDir?
<lifeless> Guest87486: I don't know quite what you're asking.
<lifeless> Guest87486: but I want to know that you can't branch a repo. Youc an only branch a branch.
<Guest87486> lifeless: I'm just trying to understand if bzr is smart enuf to put changes originally meant for "aRepo/someDir" into the directory I renamed it as "aRepo/newDir".
<lifeless> Guest87486: yes
 * igc_ out for a few hours
<lifeless> Guest87486: (yes, bzr is smart enough)
<Guest87486> lifeless: I just started with version control in general, and bzr in particular.  pretrry amazing once you start to get the hang of it!  Thanks.
<tommytb> hi, what is the submit branch shown in branch.conf?
<fullermd> It's the default location used for certain operations (send and merge at least, I think)
<tommytb> any way to move it back to trunk?  (i messed up my repository when trying out my first branching operation)
<fullermd> Using something like `merge --remember` would reset it.  You could manually edit it in the branch.conf.
<tommytb> branch.conf also has some of my commit messages in it
<tommytb> what does merge --remember do?  i don't want to mess things up more
<fullermd> It shouldn't....    oh, maybe qbzr's uncommit hook stashes them there.
<fullermd> `merge --remember xyz` does pretty much the same thing as `merge xyz`, except that it stores xyz as the remembered location.
<fullermd> Without --remember, it will only save it if there isn't already a saved one.
<tommytb> the submit branch is set to a branch I manually deleted, which is causing me some errors.  I have nothing to merge
<fullermd> What errors is it causing you?
<fullermd> The stored location is just used as a default location for certain commands when you don't specify one explicitly.  Aside from that, it's pretty much cosmetic; it doesn't imply any lower-level link between the branches.
<tommytb> when i open my trunk it says in bzr explorer "Not a branch: ~/project/trunk/branch1
<fullermd> Mmm.  Explorer is off my turf.  That's igc_'s baliwick, but he's away right now.
<fullermd> You could just manually delete the line wholesale from the branch.conf.
<lifeless> right
<lifeless> also please file a bug on bzr-explorer at bugs.launchpad.net/bzr-explorer
<tommytb> deleting the submit branch=...  line from branch.conf seemed to work
<tommytb> should i also delete the line below it that just says [commit data]?
<tommytb> i have a question on launchpad bzr-explorer already
<lifeless> about this?
<tommytb> ya
<fullermd> Probably not...   I assume those are saved uncommit messages or something.  Might as well leave 'em alone without a good reason to fiddle.
<tommytb> ok, thx, i think its fixed
<tommytb> does anyone know what the colored circles indicate in bzr explorer when viewing your log history? One of my branches is colored pink and one is colored sky blue.
<fullermd> I think it uses some heuristic to guess which branch different revs came from, and colors them based on that.  I'm not sure it has any deeper meaning.
<GungaDin> can bzr apply patches?
<mwhudson> GungaDin: yes, bzr help patch i think
<mwhudson> hm
<GungaDin> thx
<Peng> If you just have a plain diff, you can use the usual 'patch' command...
<mwhudson> maybe that's from some plugin actually...
<parthm> I am trying to run 'bzr log' with bzr from trunk. but thats failing with api not compatible error. version and st work and pull says there is nothing to pull http://pastebin.com/Hbgt3KRM
<parthm> am i missing something?
<vila> hi all ! (new DST here for those who care :)
<vila> parthm: upgrade or disable your plugins until they update their checks against bzrlib API
<parthm> vila: ah ok. so a plugin probably updated the log command. it works fine with --no-plugins. thanks.
<vila> parthm: just loading the plugins (even without modifying log) can trigger that
<parthm> vila: i should have thought of that earlier :)
<davidstrauss> How can I change the path to Python that Bazaar uses?
<lifeless> davidstrauss: an installed bzr ?
<lifeless> davidstrauss: or running from source?
<davidstrauss> lifeless: Either, preferably installed
<davidstrauss> lifeless: I need to run Bazaar under Python 2.6 for bzr-svn support for one use.
<davidstrauss> user*
<lifeless> well
<lifeless> you'll need to installed it under python 2.6
<lifeless> unless you're using packages, which should have instaleld it under all versions
<lifeless> the #! line at the top of /usr/bin/bzr controls the interpreter used to run bzr
<lifeless> but you can also do 'python2.6 /usr/bin/bzr ....'
<davidstrauss> lifeless: Running the "python2.6 /usr/bin/bzr" complains about not having bzrlib in the PYTHONPATH
<lifeless> davidstrauss: then its not installed for python2.6
<lifeless> davidstrauss: is it ubuntu packages that you've installed it with ?
<lifeless> or something else?
<davidstrauss> lifeless: This is with the Four Kitchens Yum repo packages for RHEL/CentOS
 * Peng declares dealing with plugin API compatibility the most annoying thing ever.
 * fullermd waves at vila.
<davidstrauss> lifeless: I think I figured it out.
 * vila waves back !
<lifeless> davidstrauss: I don't know anything about CentOS python package sorry
<poolie> lifeless: teddybear about apport
<poolie> with my current fix for bug 528114 we can get ubuntu-bug sending the crash files to lp again
<ubottu> Launchpad bug 528114 in bzr "apport complains "This problem report applies to a program which is not installed any more."" [High,In progress] https://launchpad.net/bugs/528114
<poolie> but there are two drawbacks
<poolie> firstly they are filed against the ubuntu package when they're probably upstream bugs
<poolie> secondly they are private by default, pending retracing
<poolie> and there seems to be a long delay there
<igc1> back
<igc1> with a running system this time :-)
<lifeless> poolie: hi
<lifeless> poolie: uhm, some apport is better than no apport
<poolie> yeah that was basically the question
<lifeless> poolie: what caused the issue? Have you corresponded with pitti ?
<poolie> previously; not today
<poolie> i think i just need to fix a larger bug
<lifeless> well yes, I know previously :)
<lifeless> pitti is up , I saw him in another channel; might make sense to have a hallway chat with him about this now.
 * igc1 dinner
<writer> Hi everyone
<writer> Is it okay to use bzr on a low-bandwidth connection ?
 * writer is on a 512 Kbps connection, and getting 'bzr: ERROR: Connection error: while sending GET /ikarus.dev/.bzr/repository/indices/a2ff5c6db2537db1740e0e9ba5216e52.six: [Errno 4] Interrupted system call' with bzr 2.1.0-2 on Arch GNU/Linux
<lifeless> thats not going to be your connection per se
<lifeless> perhaps there is an intercepting proxy at your ISP or something
<lifeless> bzr is usable with lower speed connections than yours
<writer> lifeless: there is not any, AFAIK, and I'm getting download speeeds like 2KB/s, 1KB/s and then also get spikes like 67KB/s, 22KB/s
<Peng> Wait a minute. "Interrupted system call"? As in EINTR?
<Altreus> Hey, I accidentally forgot to specify files to commit. Can I un-commit?
<Altreus> oh
<Altreus> uncommit heh
<Altreus> I didn't expect that to be there :o
<igc1> night all
<ronj> Hello. It's impossible for me to to even a simple bzr branch, I always get http://pastebin.com/mrm62Bd1 . However, 1. my public key is in ~/.ssh/launchpad_id_rsa.pub, 2. It matches what LP outputs when I click on  "SSH keys: ronj@launchpad.blob", and 3. I tried removing it from LP and reimporting it. Help!
<ronj> Using Ubuntu 9.10 x86 with bzr 2.0.2
<ronj> And I forgot to mention: it used to work. I don't know what caused it no now fail
<davertron> hi guys, i currently have a bzr branch that's pack-0.92 that i want to convert to rich-root-pack so i can pull; how can I do this?
<jelmer> davertron: bzr upgrade --rich-root-pack
<jelmer> davertron: or, alternatively -- 'bzr upgrade --2a' if you're on bzr >= 2.0
<davertron> jelmer: is that a pretty safe avenue?
<davertron> jelmer: should i worry about the possibility of a corrupted branch or anything like that?
<jelmer> davertron: yeah, though I'd really recommend using 2a if you can - it's much faster
<davertron> jelmer: looks like i'm using 1.13.1
<bendj> For remote access, I know I can use bzr+ssh or sftp.  What's the _difference_ between the two?  When should I use which?  Does it matter?
<LeoNerd> sftp uses a dumb filesystem on the other end; namely the SFTP server
<LeoNerd> bzr+ssh shells in to the remote server, runs bzr, and uses it as a smart agent
<bendj> LeoNerd: so bzr+ssh is a better opt, it seems
<LeoNerd> bzr+ssh costs more in terms of resources on the server, but the smart agent can help reduce network usage or roundtrips
<LeoNerd> Can be. Depends on your setup
<LeoNerd> between my desktop and my server I use sftp, because my server is a celeron 333 with 784MiB of RAM accessible over a 100Mbit LAN with <1msec of latency.
<LeoNerd> sftp is finished well before that celery has even fork()+exec()'ed a python process.
<bendj> LeoNerd: Thanks for the explain!
<IslandUsurper> does anybody know if horizontal scrolling with the mouse wheel doesn't work in qbzr because of qbzr or Qt itself?
<IslandUsurper> I'm using a touchpad, but I know that's not the problem because Chrome and Firefox scroll horizontally when I use it
<luks> IslandUsurper: where in qbzr?
<luks> it works for me in qdiff
<luks> (using a touchpad)
<luks> also works in qlog
<IslandUsurper> luks, well, I was looking at qdiff
<IslandUsurper> However, I'm using Windows
<luks> ah, can't test on windows right now
<IslandUsurper> when I get home, I guess I can test it on Linux
<maxb> Hi, I've just found a crash in qbzr owing to lazy-importing bzrlib.revision.NULL_REVISION. Is lazy-importing a constant ever the right thing to do?
<salgado> vila, around?  can you have a peek at https://answers.edge.launchpad.net/launchpad/+question/105604?
<salgado> (I just ran 'bzr get lp:vm' and it worked just fine)
<mwhudson> jam: does that loggerhead merge proposal have any particular bzr version requirements?
<GaLiLe0> we are looking for a version control system for our developers to install on their machines. Some dev work is done directly on a web server though. can Bazaar integrate directly to keep a backup of files on a remote web server?
<beuno> GaLiLe0, you have a plugin called "bzr-upload" which will just upload the working tree
<GaryvdM> Hi all.
<jelmer> hey Gary
 * GaryvdM came to find bailix
<GaryvdM> Hi Jelmer
<GaryvdM> \o/ Built qbzr inno installer under wine :-)
<GaryvdM> Bye - rebooting to test in windows....
<beuno> jam, ping
<thumper> jelmer: we have some fun problems with bzr-git
<thumper> jelmer: in particular the size of the cache for the incremental kernel import
<jam> hi beuno
<jam> mwhudson: I'm sure it does, I don't know it offhand, probably bzr 2.1?
<jam> maxb: it would be reasonable to lazy-import the module
<beuno> jam, 1) You rock! Thank you for the loggerhead branch.  2) Is it compatible with previous bzr'z?
<jam> but yeah, the constant is bad
<jam> beuno: prob bzr 2.1
<beuno> ah, mwhudson already asked that  :)
<jam> beuno: actually, I see "KnownGraph" in one of my bzr 2.0 branches, let me look closer
<jam> KnownGraph was introduced in bzr 1.18
<mwhudson> sounds ok to me then
<beuno> me too
<mwhudson> ps: does someone want to maintain loggerhead instead of me?
<jam> however, KnownGraph.get_parent_keys is in 2.1, but not 2.0
<mwhudson> i don't feel like i've been doing a very good job lately
<mwhudson> jam: ah
<beuno> I vote for Peng
<jam> let me see if there is a way to work around it in an obvious manner
<jam> mwhudson: both the C and python versions expose self._nodes which is the internal graph
<GaryvdM> jam: I've bumped qbzr min required bzrlib version due to that.
<jam> however, the objects in there aren't identical wrt the C vs python versions
<jam> so it isn't great to grab that
<jam> I could certainly write (ugly) code that would work under all versions
<jam> if 2.0 compatibility is important
<jam> (pure python stores a reference-by-key , Pyrex stores a reference-to-the-node)
<beuno> jam, I think we can just say that the next release of LH only works with 2.1
<beuno> and it's twice as fast  :)
<jam> well, this isn't the history cache loading, just the generation without-cache step
<jam> I'm toying with ideas about how to handle a graph data store that isn't "1 rev-at-time" while also not being "all revs, all the time"
<jam> I plan on writing something up for the list
<beuno> I think the first hit is usually what gives people the impression it's slow
<jam> though honestly, the loggerhead code doesn't really need to be calling "self._load_whole_history_data()" all the time
<jam> which could help a lot
<jam> The main page doesn't seem like it uses most of that data
<mwhudson> jam: i think hazmat has been working on that
<jam> mwhudson: assuming that is the same Kapil that was posting to canonical-tech, that is actually what inspired me to look into this code
<hazmat> jam, mwhudson i just removed it from a views that where obvious, i'm not  going to be actively pushing it, my knowledge of bzr internals is pretty rudimentary
<jam> however, his discussion was "use chameleon, disable all the stuff that seems to be O(history)"
<hazmat> jam, thanks for having a look at that
<jam> vs, how keep the info, without having to load the *entire* history
<hazmat> i checked out your branch, it does seem to better on the cache computation
<hazmat> but yeah.. that's an accurate summary :-)
<jam> mwhudson: so, other than pushing data into production, and letting people bang on it, what sort of testing does loggerhead have?
<jam> specifically, if I just started hacking in 'history.py' to make it not load the whole graph
<mwhudson> jam: yeah, that's about it
<jam> how would I find out where the gotchas are
<mwhudson> jam: i don't know
<jam> code-inspection it is, I guess
<mwhudson> the code makes me very sad in general
<jam> btw, there is one other part of my patch I didn't mention, which is the "try: import loggerhead.app.branch" stuff
<mwhudson> there's not actually that much code at least
<jam> for some reason on my machine, "try: import loggerhead" succeeds
<jam> but "try: import loggerhead.apps.branch" fails
<mwhudson> oh yes
<mwhudson> that end of things is all screwed up too :/
<jelmer> thumper: Hi
<thumper> jelmer: on a call right now, with you shortly
<jam> anyway, with that patch "bzr serve --http" works for me, so I'm happy enough with it :)
<jelmer> thumper: If it's a stand-up, mwhudson knows about it :-)
<jam> mwhudson: what is "cache_key", it seems to be BranchWSGIApp.friendly_name, but that still doesn't help much
<jam> is it ~ the path on disk?
<jam> and, IIRC, the mapping in the sql data structure is "branch_tip_revision => revision_graph_of_whole_ancestry" right?
<jam> (so the data currently stored cannot be parsed in anything less than all history)
<mwhudson> jam: it's supposed to identify the branch
<jam> mwhudson: in theory this could also be applied to your valid concern about the branch => ancestry table
<jam> since that is O(branches*ancestry)
<poolie> jam, hi?
<jam> hi poolie
<poolie> shall we talk?
<jam> are you off DST yet?
<poolie> not yet, next weekend
<poolie> so it's 7:30 here
<jam> poolie: I have nothing to say to you :)
<jam> sure
<jam> poolie: how about skype?
<poolie> sure
<thumper> vila: thanks for jumping in on that question
<vila> thumper: I'm ill, so don't hope too much either :-/ I just woke up after falling alseep instead of dining (to give you some idea ;-)
<jam> poolie: I logged in, but I don't see you on skype yet
<poolie> likewise
<thumper> vila: sorry you're feeling crap, get well soon
<vila> thumper: no worries, I'm rarely ill and it rarely last long :) (crossing fingers, killing some chicken, etc)
<maxb> I love qbzr. Not only is it an amazing tool, but I'm repeatedly astonished by how fast bugs are turned around. <4 hours filed->fixed in this case :-)
<GaryvdM> maxb: I was doing the release, and it was a easy thing to fix.
<GaryvdM> maxb: Thanks for the bug report.
<maxb> You deserve the praise - this isn't the first time I've had a bug turnaround measured in hours :-)
<GaryvdM> maxb: However, we do have our share of old bugs, and open bug seems to grow all the time :-~
<maxb> So do all projects, I fear
<lifeless> moin
<GaryvdM> moin lifeless
<poolie> can someone review my apport mp?
<GaryvdM> jelmer: If I want to add an entry to debian/changelog, but I am not going to be uploading, should I just exclude the -- Gary... line?
<jelmer> GaryvdM: Just include it - whoever will actually do the upload will change it to their name
<GaryvdM> jelmer: Ok thanks
<Boingo> Hello everyone.  I am still a bit new to bzr and trying to get my head wrapped around how I should best use it.  In my case, I have a distributed team work on a base project (PHP website).  Most of the work goes into the base product.  But, from time to time, we need to branch and create specific version for a client.  Most of the changes are cosmetic, CSS, images, etc.  Some are code changes.  Either way, we would like to be able to track the changes in th
<timClicks> is there an equivalent to bazaar explorer for Gtk+?
<GaryvdM> timClicks: olive, which is a part of bzr-gtk
<timClicks> GaryvdM: ty
<GaryvdM> timClicks: You can also configure bzr explorer to use the bzr-gtk dialogs, but it will still require that you have qt installed (which i guess is what you don't want)
<timClicks> well, I'm fine mixing and matching but used a Windows machine for checking out some code yesterday
<timClicks> and was really impressed by Bazaar Explorer
<timClicks> and wanted to have something that easy for my Ubuntu machine
<GaryvdM> timClicks: bzr explorer/qbzr will honner your gnome styles, if thats whats important
<GaryvdM> timClicks: see http://doc.bazaar.canonical.com/explorer/en/visual-tour-gnome.html
 * timClicks didn't realise that bazaar explorer was available for GNOME
<GaryvdM> timClicks: bzr explorer is built with qt. (qt!=kde)
 * timClicks nods
<timClicks> understood
<timClicks>  I actually thought it was a native MS Windows app
<GaryvdM> Oh
<timClicks> things make much more sense now
<jrib> Hi, how does one start bazaar explorer in OS X?  I installed the desktop bundle and qt libraries (things like bzr qinit work ok from a terminal)
<GaryvdM> jrib: run bzr explorer
<GaryvdM> jrib: there is allready a bug for adding a application shortcut
<jrib> GaryvdM: hmm, I'm getting "bzr: ERROR: unkown command "explorer"".  I installed 2.0.1 + desktop bundle
<GaryvdM> jrib: thats odd. Do you see explorer under bzr plugins ?
<jrib> GaryvdM: bzr plugins | grep -i explore    returns nothing
<jrib> GaryvdM: it is possible that I installed bzr some other way and now installed the bundle on top of it (I don't use OS X and am just trying to get some simple instructions down for a colleague).  bzr currently points to /usr/local/bin/bzr
<GaryvdM> jrib: sorry - I don't own a mac. Not sure
<jrib> GaryvdM: ok, thank you.  In any case, it's clear now that if I did have explorer installed it should be listed under bzr plugins, right?
<GaryvdM> jrib: yes
<GaryvdM> jrib: If you have pyqt installed, then you should be able to just put bzr-explorer in the plugins dir
<GaryvdM> Not sure where that would be though
<jrib> GaryvdM: thanks, copying it to the plugins folder was sufficient.  Now I have to redo it without using a terminal to explain it to my friend :)
<GaryvdM> jrib: Not sure why + desktop bundle did not work for you.
<GaryvdM> I ran it on a family members mac once, an it worked for me
#bzr 2010-03-30
<TimoJJ> I am looking for a good examples of use for Bzr in Web Site developing.  I read the many doc but so much!  I look for ideas of central server that holds Production and Development repositores. And then I am checking out at my laptop somewhere else for Development then pushing to Production at central again.
<TimoJJ> I am so much confused with to use branches or checkouts.  Good examples are nice!
<TimoJJ> Can you help if you have time?
<poolie> TimoJJ: maybe http://beuno.com.ar/archives/80
<poolie> or http://wiki.bazaar.canonical.com/BazaarUploadForWebDev
<TimoJJ> poolie: I read the second before but it also added trees.  I dont know if or no to use trees in central server.  It was more advanced right then than me.  I am looking to the other reference now also.
<TimoJJ> poolie: These is intersting but I start in the other direction.  WIth every thing first on the central server then to check out at remote.  Is this still good for me?
<igc> morning
<poolie> TimoJJ: is the central server an actual web server where you want to deploy your stuff, or just a place to hold your bzr branches?
<poolie> igc, hi!
<igc> hi poolie!
<jrib> TimoJJ: http://wiki.bazaar.canonical.com/BazaarForWebDevs too
<TimoJJ> poolie: It is both things.  On the Central server I think to have /path/DirA as the Master branch that will publish on web server to public.  Then I want to work developing only at a different branch or maybe chekcout that will publish on web server only to me privatly.
<TimoJJ> When I am happy with the private web project apparance then to push the changes to the Master branch again for the public to see.
<jam> hi igc
<igc> hi jam! Back from leave now?
<jam> poolie: I just sent you an email with some of the details about the 'denormalization' stuff I was talking about. It would be nice if you could give it a look over
<jam> igc: technically back last week, but not particularly high-availability :)
<TimoJJ> jrib Thanks you also.  Yet the URL is for the laptop first then the server but I can make it back ways too.
<poolie> TimoJJ: in that case you do need a tree on the server for the version exposed to the public
<TimoJJ> poolie: So it is not to expose to the public the Master branch but a checkout of it?  The checkout is in the tree then, yes?
<poolie> so one setup you could have is
<poolie> a repository on the server with all your branches
<poolie> jam: o
<poolie> jam: ok
<poolie> and then a separate checkout of the production branch, with a cron job to update it every hour or so
<Peng> jam: <3
<Peng> Loggerhead currently supports pretty old versions of bzr. Back to 1.13, IIRC. I personally don't really mind dropping <2.0 in the next release, but I always run bleeding-edge stuff anyway.
<Peng> Plus, this is probably worth it anyway. :-\
<Peng> beuno: Noo, I'd be a terrible maintainer. jam touched the code last, let's make him do it. :P
<Peng> Anyway I was AFK...
 * Peng goes back to that
<lifeless> Peng: so tht was a 'yes' then ?
<GungaDin> How long does bzr patch usually take to patch about 5  files?
<GungaDin> sorry for the weird question... but for me it takes AGES!
<lifeless> instant, I'd expect
<lifeless> unless the files are big (megabytes)
<lifeless> or perhaps you have a lightweight checkout of a network branch or something
<GungaDin> no, they're just regular txt files. nothing too big.
<Peng> lifeless: What did I just agree to?
<lifeless> maintaining loggerhead?
<GungaDin> my bzr on another machine doesn't recognize the command 'patch'
<GungaDin> is it in bzrtools?
<poolie> could be, 'bzr help patch' will tell you
<GungaDin> how am I supposed to create the diff file to? if I want directory A to change into directory B?
<lifeless> what do you mean
 * igc out for a few hours
<GungaDin> I tried to create one with diff -crB but when I try to patch --dry-run I get an error saying it can't find the file to patch (and it exists!).. so I'm doing something wrong.
<mwhudson> is the news_merge plugin bundled with bzr
<mwhudson> ?
<poolie> yes, in 2.2
<mwhudson> i guess we should be looking at upgrading lp to the 2.2 series
<bignose> I've branched from an upstream Git repository. can I generate changesets that, when upstream adds them to their repository, will be recognised by Bazaar as the same changes I made?
<lifeless> thats 'round tripping', and no, its not supported for bzr-git yet.
<lifeless> however, bzr handles duplicate changes pretty well, most of the time - so it may not matter.
<bignose> okay. is it supported for any of the foreign VCSen?
<lifeless> bzr-svn
<bignose> do I require commit access to upstream's Subversion repository for successful round-trip changesets?
<bignose> or can I generate changesets that upstream can incorporate for themselves that will be round-trip changesets?
<NfNitLoop> bignose: you'd need to be able to push your own changes for svn round-tripping.
<lifeless> commit access, for bzr-svn
<lifeless> I suspect git round triping, when it happens, won't require that.
<poolie> hello bignose, lifeless, NfNitLoop
<thumper> I wish I could go `bzr merge -i :next some/file` in a pipeline
<NfNitLoop> poolie: H'lo!
<bendj> Can bzr-explorer initiate/open a bzr+ssh URL?  I can easily do it from cmd line, and then have explorer 'explore' the local store ... but simply not clear how/where to specify the bzr+ssh connection IN bzr-explorer GUI.  Is it right in front of my nose, and I'm missing it?
<poolie> Open/Location i think
<bendj> poolie Yup, thanks.  NOT in the 'get source from elsewhere' tab.  sigh.
<poolie> lifeless/jam: what do you think of https://bugs.edge.launchpad.net/bzr/+bug/551391
<ubottu> Ubuntu bug 551391 in bzr "on MemoryError, log/report memory usage by type" [Low,Confirmed]
<lifeless> poolie: from the one liner it sounds interesting if it works
<lifeless> thumper: try :next/some/file
<thumper> lifeless: ah, thanks will try
<poolie> mm, i think i don't have a good enough idea what data realistically helps
<lifeless> poolie: if it got a meliae dump we can figure out what matters later
<lifeless> but they are big
<poolie> yes, and also we're not likely to have it in every case
<Peng> jam: ping
<jam> Peng: what's up?
<Peng> jam: Hi. :D
<Peng> jam: Wanted to ask you about Loggerhead, known_graph and statictuples.
<Peng> Basically, I run my statictuples branch on my server, I'd like to try merging known_graph, and I was wondering what I should do about the conflicts. :D
<Peng> I'm not sure if I had a more specific question formed when I pinged you. :P
<Peng> jam: You wrote in a comment that you tried using StaticTuples in it. Do you still have the code? :D
<jam> well if you have a conflict, clearly you should revert to my code :)
<jam> I didn't to ST everywhere, but certainly inside that func
<Peng> I had stuck compute_whole_history_data full of StaticTuples, and you rewrote the whole thing, so it conflicts everywhere. :D
<Peng> Well, not all of it, but...
<jam> rev 409 has some ST stuff, I think, though that might have just been the timing comments
<jam> i can  redo it if you want
<Peng> It doesn't have any code.
<jam> it wasn't very hard
 * Peng shrugs.
<Peng> On the one hand, I'm selfish and don't want to do work. On the other hand, I also feel that's immoral. :P
<Peng> Also -- that "What about ghosts?" comment sounds ominous. Is it likely to explode?
<jam> Peng: http://paste.ubuntu.com/406331/
<Peng> Oh. Thank you. <3
<jam> I didn't explicitly test it, but the KGmerge_sort code knows how to handle ghosts
<jam> *without* having to stirp them
<jam> strip
<Peng> I just pushed it to https://code.edge.launchpad.net/~mnordhoff/loggerhead/statictuples_and_known_graph fwiw
<Peng> Trying it out, it hasn't died yet. \o/
<spm> Peng: is that a challenge for me to break it on you? no reason for asking.... >:)
<Peng> spm: Go ahead. :)
<Peng> It's running on http://bzr.mattnordhoff.com/loggerhead/ too
<spm> woo!
<lifeless> EODing
<Peng> lifeless: See ya. :)
<Peng> spm: BTW, the most important branch to break is lp:~jameinel/loggerhead/known_graph. The StaticTuple stuff probably isn't going to be merged any time soon anyway, so it doesn't matter as much.
 * spm has stepped into an alternate universe where users encourage bofhs to break their work. this is wrong. WRONG i tell you!!! it's like cows pointing out which part of their anatomy is tye best to eat!
<lifeless> spm: oh, you saw that simpsons episode?
<spm> lifeless: was thinking hitchhikers GTTG?
<Peng> Hey, if you don't kick the tires now, it'll fall over when it eventually gets deployed to Launchpad/
<spm> Peng 1, spm 0
<bendj> When creating a *shared* repo, containing multiple branches etc, is there just *one* .bzrignore file at the top level of the repo that applies to all contained branches?  or does/can each branch have its own .bzrignore?
<Peng> .bzrignore is a branch thing.
<Peng> Shared repos are simply a storage and performance optimization.
<bendj> Peng Ah, so every branch gets a .bzrignore, if needed.  Do I need to include ".bzrignore" *IN* .bzrignore, or does it knwo to ignore itself?
 * igc dinner
<nlisgo> is there any way to get bzr to create a diff file that contains differences in binary files too?
<nlisgo> not saying I'm going to use it, but is it possible?
<maxb> The diff format itself has no way of representing binary files
<Peng> Although there is git's extension.
<Peng> nlisgo: Why? You can use "bzr send" to create a file that bundles revision data, including a diff for text files. (Binary files are just encoded in the base64 chunk at the end.)
<nlisgo> peng: I'm working on a site that is versioned by svn. They didn't give me access to the repo but just provided me with the site files. I've versioned with bzr for my development and now want to create a patch file that can put everything in place for them
<nlisgo> peng: can send create a patch file that can be applied using the patch command?
<Peng> nlisgo: Probably, but mostly it's intended for bzr. Certainly nothing else supports the binary part.
<nlisgo> bzr diff allows me to create a batch file from revision 2 to the present version. How do I do this with a send file
<Peng> Um. Convince them to use bzr-svn? :D
<Peng> Although if *you* didn't use bzr-svn it would still be a huge pain.
<nlisgo> I think for ease in this instance I'm going to give them a diff genrated patch file and then just zip up the image folder
<Peng> That sounds like a good idea.
<nlisgo> just wanted to ask the question
<nlisgo> bzr gets funny if file names contain a single quote
<Peng> I doubt it.
<Peng> Creating a file called ' works fine for me.
<nlisgo> I tried to version a site the other day and it churned out an error when it reached so files that had been uploaded with single quotes in the filename
<nlisgo> when I tried to commit those files to the repo
<Peng> What kind of error?
<Peng> Um.
<Peng> Scratch that. What was the error message?
<Peng> Perhaps you weren't escaping shell args properly or something.
<Peng> Oh... Is this on Windows?
<nlisgo> on linux
<nlisgo> i'll try and recreate the problem again because I just deleted the files because they weren't being used
<Peng> Ah.
<nlisgo> i'll be back in a few minutes
<Peng> Linux should really be fine. Bazaar doesn't do anything to arguments and the kernel and file systems aren't stupid.
<nlisgo> couldn't recreate problem on my local machine but it might have been to do with the tree that is used when a bzr repo is initialised on the server
<nlisgo> i'll try again later on the server
<nlisgo> thanks for your help peng
<Lo-lan-do> G'day all
<Lo-lan-do> Is there a working email-on-commit plugin that I can install on a remote server?
<Peng> nlisgo: When pushing to a server, Bazaar doesn't create a working tree. It doesn't use any unusual characters at all.
<nlisgo> well, if I see the problem again I'll come back with the error
<mgedmin> waaaah! either bzr or launchpad is being nasty to me
<mgedmin> a while ago I did bzr branch lp:zodbbrowser
<mgedmin> now I can't push back to launchpad
<mgedmin> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~zodbbrowser-dev/zodbbrowser/trunk/.bzr/)
<mgedmin> is not compatible with
<mgedmin> CHKInventoryRepository('file:///home/mg/bzr/zodbbrowser/.bzr/repository/')
<mgedmin> different rich-root support
<mgedmin> sorry for the paste
<Peng> Uh-huh.
<mgedmin> actually, this appears to be a bound branch (aka checkout), so turns out I don't need to push
<mgedmin> but the error message is ... confusing, to say the least
<Peng> It's a pretty straightforward error message, just not very...explanatory.
<mgedmin> wait, it's a lightweight checkout of a branch in my home directoryu
<mgedmin> I was following the instructions at http://wiki.bazaar.canonical.com/GitStyleBranches
<mgedmin> bazaar, you're not winning any friends this way
<mgedmin> what do I do now?
<Peng> mgedmin: Either create a non-rich-root repo and redo your revisions somehow, or get lp:~zodbbrowser-dev/zodbbrowser/trunk to upgrade to a rich-root format.
<mgedmin> I hate people who go to a project's channel and say "you're crap, I'm switching to $ALTERNATIVE"
<mgedmin> but now I deeply understand that urge
<Peng> One day everyone will be on rich-root formats and this won't bite anyone anymore. Until then...yeah. :-\
<SamB_XP> Peng: what, who's not on rich-root yet?
<SamB_XP> I need to go byte them!
<Peng> SamB_XP: lp:~zodbbrowser-dev/zodbbrowser/trunk apparently
<SamB_XP> zodbbrowser, switch, if you value your neck!
<mgedmin> I don't suppose mere mortals can upgrade repositories stored on launchpad?
 * mgedmin tries bzr upgrade lp:zodbbrowser
<mgedmin> wow, it's doing something
<mgedmin> ... very slowly ...
<SamB_XP> sure they can, if they've write access
<Peng> mgedmin: You're in ~zodbbrowser-dev?
 * mgedmin is
<SamB_XP> but it's probably smarter to just steal them, convert them, and then upload them again
<spiv> Isn't there a button in the web UI for upgrading now?
<SamB_XP> oh, is there ?
<Peng> Oh, right, I've heard something about that.
<SamB_XP> who would have delayed-computation (er, that is, thunk) it ?
<spiv> Yeah, there is.  Well, a link rather than a button.  .../+upgrade
<mgedmin> cool
<SamB_XP> hmm ... how come upgrade on a remote smart repo doesn't just ask the server end to do it ?
<Peng> The developers are mean?
<spiv> SamB_XP: because no-one has written that yet
<mgedmin> because it's fun to have people wait at 10 kB/s
<mgedmin> upgraded!
<SamB_XP> spiv: good answer
<SamB_XP> well, I mean, tolerable
<spiv> SamB_XP: the most immediate problem is that there's not really any infrastructure for streaming progress info via the smart protocol yet
<mgedmin> thank you, Peng and SamB_XP!
<SamB_XP> spiv: ah, that *would* be an issue
<mgedmin> I had no idea I could/had to upgrade repositories hosted on launchpad by myself
<spiv> SamB_XP: the current version of the protocol supports streaming info
<SamB_XP> mgedmin: what'd I do ?
<mgedmin> SamB_XP, said "zodbbrowser, switch, if you value your neck!"
<SamB_XP> lol
<spiv> SamB_XP: just no-one has taken the time to figure out what streaming progress should look like for bzrlib (although subunit is probably a good place to look for inspiration if you're interested...)
<mgedmin> which made me try 'bzr upgrade lp:zodbbrowser", which I trully expected to fail with "cannot do that remotely"
<SamB_XP> the thing is that bzr is perfectly happy to do remote filesystem access when the "smart" protocol is missing a piece of functionality
<spiv> And even some smart remote fetching, in this case, I think, but not as much as it could.
<spiv> I'm sure that we'll fix 'bzr upgrade' via smart server before the next major format bump, but at the same time we're also not planning a major format bump any time soon.
<spiv> It'd be very nice to fix, but there are plenty of other very nice to fix things I'd probably want to fix first.
<spiv> e.g. commit to stacked branch
<mgedmin> commit or push?
<spiv> Or support resuming interrupted fetches.  Although they are both probably a bit harder, but they'd also be more valuable I think.
<mgedmin> a friend was recently complaining that a trivial bugfix to a large repository took ages to bzr push to a new hosted branch
<spiv> (especially now that LP has the 'upgrade' link in its UI)
<spiv> mgedmin: that's odd
<spiv> mgedmin: there aren't any major known issues there
<mgedmin> it could be a case of old repository formats
<mgedmin> schooltool is not a new project
<spiv> Definitely worth upgrading to 2a
<spiv> (Also, I have a patch in review that helps one of the minor known issues with pushing via non-smart server: https://code.edge.launchpad.net/~spiv/bzr/smarter-index-search)
<spiv> mgedmin: if poor performance persists after upgrading, please ask your friend to file a bug or post to the list about it.
<Peng> Hello, jelmer's evil twin. :D
<SamB_XP> Peng: it looks like he just changed IP address or somesuch, nothing to be alarmed by!
<jelmer> Peng: I thought jelmer was the evil one? :-P
<SamB_XP> jelmer: aren't YOU jelmer?
<Peng> SamB_XP: That's what he wants you to think!
<Lo-lan-do> Is dato still maintaining bzr-hookless-email?  I think I fixed itâ¦
<jelmer> Lo-lan-do: I don't think he is
<Lo-lan-do> Who should I send the merge request to then?
<jelmer> Lo-lan-do: Congratulations on becoming the new bzr-hookless-email maintainer!
 * jelmer runs
 * Lo-lan-do grumbles
<Lo-lan-do> I guess I'll push to somewhere under pkg-bzr in Alioth :-)
<jelmer> heh
<jelmer> Actually, I think LarstIQ was doing some maintainance work on it recently
<jelmer> not sure what happened to that
<Peng> He gave up so we wouldn't make him the new maintainer. :D
<SamB_XP> Peng: you must be more careful not to remind people of that tradition before they are drafted!
<Peng> SamB_XP: I was already victimised today.
<vila> morning jam, ping me when you're here
<jam> morning vila
<Lo-lan-do> branch.revision_history() will only return a linear sequence of revisions, right?  Not a DAG?
<Lo-lan-do> (Still working on bzr-hookless-email)
<james_w> Lo-lan-do: I'm pretty sure
<Lo-lan-do> Okay, thanks
<james_w> it's the left-hand history, you need to use branch.repository.get_graph() to look at the DAG
<james_w> bear in mind that computing revision_history() involves loading the whole graph and sorting it, so if you care about performance and aren't doing whole-graph things then using the Graph may be better
<james_w> sorry, doesn't involve sorting, but does mean loading a potentially large chunk of the data
<Lo-lan-do> I'm just trying to understand bzr-hookless-email's logic when dealing with new branches or disappearing tips due to merges.
<james_w> ok
<Lo-lan-do> Dealing with new branches is okay, I think.
<Lo-lan-do> Now for merges, it might make sense to use the graph indeed.
<Lo-lan-do> There seems to be a graph.is_ancestor() method, which is good if it does what I hope it does and doesn't walk the left-hand only.
<GaLiLe0> How does this work with or without Eclipse or VS? If there are merely plugins for these does it work without them?
<GaLiLe0> In other words do you have to interface it with an IDE?
<GaLiLe0> Or does it simply back up the files from the file system itself?
<Lo-lan-do> GaLiLe0: What's "it"?
 * Lo-lan-do uses Bazaar without an IDE
<GaLiLe0> bzr of course
<james_w> Lo-lan-do: it is full-history
<Lo-lan-do> james_w: Great.  Would you know of a method to find a common ancestor to two revisions?  I can search, but if you know it offhand that's easier :-)
<jelmer> Lo-lan-do: Graph.iter_ancestry() ?
<jelmer> Lo-lan-do: There's also Graph.find_common_ancestor() I think
<GaLiLe0> Lo-lan: without the IDE how do you sync to your repository?
<james_w> not offhand, but I would expect something like jelmer suggests
<Lo-lan-do> Thanks j*
<Lo-lan-do> GaLiLe0: With the Bazaar commands or the Gtk interface or whatever else
<GaLiLe0> So the plugins are unnecessary. Is there an advantage to using the plugin?
<Lo-lan-do> Some people don't like external tools, and they prefer doing everything from their IDE.
<GaLiLe0> it works for source code. word documents etc?
<Lo-lan-do> It works for any kind of files, so yes.
<Lo-lan-do> It's more efficient on text files than binary files, though.
<GaLiLe0> binary files like WORd docs?
<Lo-lan-do> Yes
<GaLiLe0> do you like the Tortiose interface?
<Lo-lan-do> I never tried it myself.
<ejat> i got this error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
<CoffeeIV> If I have a source tree retrieved from launchpad with "bzr branch lp:whatever" , can I move that directory around and have it still work, or is it's full path hardcoded into itself somewhere ?
<Lo-lan-do> You can move it around
<Lo-lan-do> I do that all the time :-)
<Lo-lan-do> It sometimes gets tricky when you have a local repository because sometimes the references are using relative paths, but for standalone branches it's not a problem.
<CoffeeIV> Thanks !
<james_w> has anyone ever seen a tag not be sent on push?
<james_w> commit; tag; push; with the tag not being visible at the remote end after the push?
<james_w> hmm, it's not that
<lifeless> moin
<cody-somerville> Whats the easiest way to see if a branch is a decedent of some other branch?
<james_w> cody-somerville: "bzr missing"?
<james_w> bzr missing --mine-only should be empty
<james_w> err, hang on, you want to know if they are related, or if they have diverged?
<cody-somerville> If they are related
<james_w> merge --preview might tell you
<phinze_> this should be simple, but i'm at a loss -> "find all commits by a given committer"
 * phinze_ needs bzr-search it seems?
 * luks recommends bzr qlog if it doesn't have to be a command line
<cody-somerville> What branch format do I need to use to have interoperability with 1.13.1?
<cody-somerville> (bzr version 1.13.1 that is)
<james_w> I think the 1.9 are the most recent supported by 1.13.1
<exs> hi
<exs> need helÃ¼
<exs> i have a repo with code. someone had downloaded this repo and changed it. how to merge them together?
<exs> but he downloaded without bzr
<awilkins> If he downloaded the whole repository, that's still fine
<exs> yea
<exs> how to merge them together
<awilkins> He will need to get the changes to you ; if you don't have common file system access or a shared server, he can send you a merge bundle
<exs> he can zip them into a file
<exs> then send my the zip file
<awilkins> Yes
<exs> and i want merge his code with my code
<awilkins> Look at `bzr send`
<exs> how to do this?
<awilkins> Essentially you receive a file and you merge that
<awilkins> Bazaar just knows what to do with them
<exs> awilkins, can u try to explaim me how to solve the problem
<exs> i trying to read the docu but Its difficult to understand
<awilkins> Your friend needs to do `bzr send <branch URL>` where the URL is the original branch that you want to merge with
<awilkins> His email client will open (if properly configured), or you can dump it to a file
<awilkins> You take the file and merge from that as if it was a branch
<IslandUsurper> exs, it helps if your friend commits his changes first
 * awilkins had assumed this was true when it was said "changed (the repo)" but that's a fair point
<jpds>  /1
<lifeless> jpds: haha
<cody-somerville> hmm... running bzr add results in: bzr: ERROR: exceptions.AttributeError: children
<lifeless> cody-somerville: bzr version?
<cody-somerville> 2.1.1
<lifeless> and the exact command line ?
<cody-somerville> bzr add
<cody-somerville> lifeless, http://pastebin.ubuntu.com/406738/
<cody-somerville> I rmed a symlink and then copied over a directory with the same name.
<cody-somerville> remvoing the directory makes bzr add work
<cody-somerville> Seems to be bug #341555
<ubottu> Launchpad bug 341555 in bzr "crash on "bzr add" -- changed symlink to actual directory" [Undecided,Fix released] https://launchpad.net/bugs/341555
<cody-somerville> I'll reopen that for you.
<lifeless> cody-somerville: 'bzr add', not 'bzr add path' ?
<cody-somerville> both throw the exception
<lifeless> cody-somerville: please don't reopen fix released bugs
<lifeless> open a new bug
<cody-somerville> too late :(
<cody-somerville> I attached my crash report and everything.
<lifeless> ugh
<lifeless> its almost certainly different, because we unit test things quite thoroughly
<cody-somerville> It looks like maybe the bug just got closed because it was for 1.6.1.
<cody-somerville> fyi, it works when if you replace the symlink with a file and not a directory
<lifeless> I suspect if you run 'bzr st' first it will work too
<AfC> oh dear
<AfC> worthil ~/vcs/java-gnome/mainline $ bzr pull
<AfC> Using saved parent location: /home/andrew/src/java-gnome/mainline/
<AfC> bzr: ERROR: No such file: u'/home/andrew/vcs/java-gnome/.bzr/repository/obsolete_packs/': [Errno 2] No such file or directory: '/home/andrew/vcs/java-gnome/.bzr/repository/obsolete_packs/'
<cody-somerville> lifeless, how wonderful. it does!
<exs> hi
<exs> i need help
<exs> i executed bzr uncommit
<exs> and he deleted all my new changes
<AfC> a second `bzr pull` succeeds
<exs> can i undo bzr uncommit?
<lifeless> AfC: someone deleted that dir, make it by hand
<lifeless> exs: yes, it will have printed instructions when you ran it
<lifeless> exs: follow those instructions
<exs> these structions are away
<AfC> lifeless: fine. Perhaps bzr should just make such a directory on demand? Floating around here for a while now has been "yes it's ok to delete obselete_packs to save Gigs of disk space" so it'll be a common case
<exs> lifeless, did he saved something?
<mathrick> hey guys, I just pushed a branch over sftp, and it created some files with 600 perms
<mathrick> -rw-r--r-- 1 mathrick mathrick   35 2010-03-24 04:44 branch-format
<mathrick> errr
<mathrick> wait
 * mathrick can't read
<lifeless> mathrick: that looks like 644 to me :P
<mathrick> yes, I know
<lifeless> AfC: making the directory is another round trip; we've only ever said its ok to delete the *contents* and then only if you have done sync.
<mathrick> I was going off on a bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://sei.meidokon.net/repo/thesis/report/.bzr/branch-format
<poolie> good morning
<mathrick> the client that gives that is 1.15.1
<mathrick> poolie: good midnight :)
<mathrick> lifeless: so the error is completely bogus, but I can read it fine with 2.1, so I guess it's just "1.15.1 horribly broken when it encounters an unknown repo format"
<mathrick> 1.3 correctly barfs on unknown format, FWIW
<mwhudson> igc: now fix all the loggerhead bugs!!
<igc> mwhudson: wow - that's service!
<igc> I only applied for membership 30 seconds ago :-)
<mwhudson> i guess i saw the mail as it arrived by chance
<lifeless> mathrick: interesting
<AfC> lifeless: right, but surely if the write failes you can check for the directory's existence and just mkdir the damn thing rather than failing back to the user
<lifeless> AfC: we can try I guess, but error handling like that tends to go wrong IME
<poolie> rebooting
#bzr 2010-03-31
<AfC> lifeless: (I accept your guidance to only delete contents from now on, but "sure it's fine to delete obsolete packs sure sounds like it's ok to delete obsolete_packs" is all)
<lbieber> I've tried to run "bzr branch lp:drizzle/staging" from several machines but keep getting these errors - http://pastebin.com/stUsEjNC
<spiv> lbieber: hmm :(
 * spiv looks
<lbieber> I can run bzr branch lp:drizzle with no problem  and also "bzr branch lp:drizzle/build"  which are our main branches that we work with
<spiv> Hmm, it doesn't seem to be bug 354036.  Which is good news, although it makes this error a bit mysterious...
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory (unfixable by users) error when pulling a branch from the mirrored area" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<lbieber> spiv:  any work arounds for now?
<spiv> lbieber: hmm, it just worked for me...
<spiv> lbieber: I'm guessing you have a local shared repository
<spiv> lbieber: if you could, please tar up that .bzr/repository right now, before anything changes
 * spiv digs up the likely bug number
<lbieber> I'm not aware of any shared repository that we are using
<spiv> You haven't done 'bzr init-repo' at all?
<spiv> Hmm.
<lbieber> no, didn't do init-repo, let me try that
<spiv> lbieber: strange
<spiv> lbieber: so, two comments:
<spiv> 1) you probably should be using a shared repository if you have multiple branches of drizzle locally, it'll save space and be faster
<spiv> 2) I have no idea why you're getting that error
<spiv> Hmm, I guess try again, add -Dhpss to the command line, and paste the .bzr.log if it fails again.
<spiv> But that exact command worked for me (branching into my /tmp, so no shared repository either)
<lbieber> I've tried it now on 3 different machines and always get the same result
<spiv> What's your lp username?
<spiv> Are you a member of ~drizzle-developers?
<lbieber> yes
<lbieber> lp username is kalebral
<spiv> Hmm, and I'm not.  That might be the key difference.
<spiv> mwhudson: ping?  'bzr branch lp:drizzle/staging' works for me, but gives a server-side 'absent factory' error for a user in ~drizzle-developers (which owns that branch)
<spiv> lbieber: you might be able to workaround it by using nosmart+lp:drizzle/staging as the URL
<spiv> mwhudson: it's not a stacked branch perhaps you could grab a tarball of it for me?
<lbieber> just had another drizzle engineer try it and they got the same error, also a member of drizzle-developers
<spiv> lbieber: great, that does suggest that's a key ingredient then
<spiv> lbieber: some background: lp's codehosting serves you a different copy of the branch depending on whether you have write access to it or not
<lbieber> spiv:  ahhhh, ok
<spiv> lbieber: so you get direct read access to the version that you (and the rest of ~drizzle-developers) can write to
<spiv> lbieber: and I (and everyone else) read from the read-only mirror that lp makes automatically
<spiv> It seems there's some sort of glitch in the writeable copy that has been fixed in the read-only copy, presumably the act of mirroring has fixed it up somehow.
<mtaylor> spiv: fwiw - branching lp;drizzle/staging works for me - and I should be accessing the read-write version ...
<jelmer> poolie: are you landing those two approved branches for lp:bzr ?
<lbieber> spiv:  what does "nosmart" do, that appears to be working for me although hasn't finished yet
<spiv> mtaylor: perhaps you already have the affected revs in a local shared repo, though?
<poolie> i'm going to land ajeans and mine
<poolie> hello spiv, jelmer
<mtaylor> spiv: that is certainly possible
<jelmer> poolie: ok
 * mtaylor never operates without a local shared repo
<jelmer> moin poolie
<poolie> yes, those are the two
<spiv> lbieber: it basically disables any efficient streaming of the repo by the smart server
<lbieber> spiv:  ok, it does seems very slow
<spiv> lbieber: i.e. it's like using sftp, the client does all the work and the server is just sending files, not interpreting them
<spiv> I *suspect* that if someone grabs an exact copy of the read-write version from lp, and runs 'bzr check' on it, it will report that it is damaged.
<spiv> The mystery is how it got damaged.
<spiv> I don't know of any bugs in 2.0 or any later release that would cause that.
<poolie> lifeless: could you have a think about bug 551332, a subunit-related thing, or try to reproduce it
<ubottu> Launchpad bug 551332 in bzr "selftest --parallel on windows fails with 'lost connection'" [Medium,Confirmed] https://launchpad.net/bugs/551332
<lifeless> poolie: I thought your speculation was on target
<lifeless> poolie: so I didn't say anything
<lbieber> spiv:  so how do we repair it?
<spiv> lbieber: Perhaps 'bzr reconcile lp:drizzle/staging', although I'd expect that to be abominally slow
<spiv> If 'bzr reconcile' can fix it, we could ask an lp admin to run it server-side for you
<spiv> Or maybe we should just ask an lp admin to replace the read-write copy with the contents of the read-only copy?
<lbieber> spiv:  either way, which ever you think is more efficient
<lifeless> spiv: why  do you think the ro copy is ok ?
<bj0> there a workaround for https://bugs.launchpad.net/bzr/+bug/522637 ?
<ubottu> Ubuntu bug 522637 in bzr "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Confirmed]
<spiv> lifeless: because I can branch it just fine, but lbieber (who is in the owning team) can't from three different machines, no shared repo, and at least one colleague in that team has the same problem
<lifeless> ok
<spiv> lifeless: mtaylor can branch it... but into a shared repo that may well already have the relevant records
<spiv> lifeless: alternative theories welcome :)
<lifeless> I can suggest a test
<lifeless> mv the .bzr dir there to backup.bzr
<lifeless> and have mtaylor push to the dir using '--use-existing-dir'
<lifeless> if that fixes it, we can analyse the backup async
<lifeless> if it doesn't fix it, then it may be a stacking interaction with whatever it stacks on
<thumper> poolie: bug 551525
<ubottu> Launchpad bug 551525 in bzr "reconfigure --unstacked doesn't quite work for lp branches" [Undecided,New] https://launchpad.net/bugs/551525
<lifeless> and a genuine bug
<thumper> moring bzr people
<thumper> well, afternoon for me now
<poolie> hullo thumper
<lbieber> lifeless:  what is the command line you want mtaylor to try?
<lifeless> mtaylor: ping
<lifeless> lbieber: if he has a local copy of staging, pushing it up fresh to the existing branch location
<lifeless> which requires sftping in to move the current data out of the way
<lbieber> lifeless:  ok
<lifeless> and if we can distract him from his shiny new machine, I'll step him through it
<poolie> jelmer: actually considering john's point in https://code.edge.launchpad.net/~mbp/bzr/484558-merge-directory/+merge/22430 i'm not going to merge that now
<poolie> why do you ask
<spiv> lifeless: it doesn't seem to be stacked, btw
<lifeless> spiv: interestinger and interestinger
<lifeless> spiv: what do you think of my suggested test?
<spiv> lifeless: sounds good
<spiv> lifeless: well,
<lbieber> lifeless:  :)   ok, I have to run for now but  will try to grab him to work this out
<lbieber> thanks for all the help on this issue
<spiv> it's possible that mtaylor's copy is also damaged, just that for some reason he isn't encountering the damage
<jelmer> poolie: I'm patch pilot this week, so wanted to make sure ajeans patch was going to make it in
<spiv> So if the problem still occurs after the test, the result is going to be ambiguous
<jelmer> poolie: so far, you've been making it very for me though :-)
<spiv> but if it works, and there's a good chance it will, then great :)
<poolie> heh
<poolie> there are still lots of branches
<mtaylor> lifeless: pong
<lifeless> mtaylor: see above
<lifeless> your staging branch is bust
<lifeless> we should see if your local copy is ok
<mtaylor> how do I test if my local copy is ok?
<lifeless> and if it is replace the server copy, preserving the current .zbr for analysis
<lifeless> cd /tmp
<mtaylor> yup
<lifeless> bzr branch bzr+ssh://localhost/home/path/to/your/staging/branch
<mtaylor> gotcha
<mtaylor> lifeless: worked
<mtaylor> lifeless: shall I push --overwrite to lp:drizzle/staging?
<mtaylor> lifeless: or does someone need to save something to debug later?
<spiv> mtaylor: --overwrite won't have any effect, and yes we do want to save something to debug
<spiv> mtaylor: so sftp in, move .bzr to .backup.bzr, and then push --use-existing-dir
<spiv> Actually, I think "backup.bzr" is the preferred name now.
<AfC> The corporate network I'm on blocks bzr:// :(
<mtaylor> AfC: whatabout http and/or ssh?
<mtaylor> bzrlib.errors.PermissionDenied: Permission denied: "/~drizzle-developers/drizzle/staging/.bzr"
<mtaylor> I tried using hitchhiker... lemme try with sftp itself
<mtaylor> Couldn't rename file "/~drizzle-developers/drizzle/staging/.bzr" to "/~drizzle-developers/drizzle/staging/backup.bzr.20100330": Permission denied
<spiv> mtaylor: just "backup.bzr"
<mtaylor> spiv: there is already one of those :)
<spiv> ah
<spiv> launchpad restricts the filenames you can have in that dir
<AfC> mtaylor: yes, in this case I have http:// set up at a parallel URL, but for the duration of the day it's going to be annoying to have to manually express every single branch in terms of a different URL from the ones stored by Bazaar
<mtaylor> AfC: find a different corporate network? :)
<mtaylor> WOW. Lucid is really f-ing borked at the moment
<AfC> mtaylor: I'm not going to bother to try and explain Bazaar to the network admins here. They're as useless as is usually the case with that lot.
<mtaylor> AfC: I usually use bzr via ssh myself...
<spiv> mtaylor: ALLOWED_DIRECTORIES = ('.bzr', '.bzr.backup', 'backup.bzr')
<mtaylor> spiv: nice
<spiv> mtaylor: if neither of those is free, you could probably cheat and move it to backup.bzr/backup.bzr.20100330...
<lifeless> you could move it to backup.bzr/broken.backup.bazaar
<lifeless> jinx
<mtaylor> spiv: I moved it to .bzr.backup
<spiv> mtaylor: just be sure to tell us :)
<spiv> Ok, thanks :)
<mtaylor> done
<lifeless> ok
<cody-somerville> bzr: ERROR: Can't export tree to non-empty directory.
<cody-somerville> The directory doesn't exist!
<cody-somerville> oh, weird.
<cody-somerville> The destination is the first argument.
<poolie> sorry, that is a bit weird
<poolie> we should change the second to be -d
<lifeless> poolie: try stopping apparmour and restartnig it
<poolie> heh, apparm_o_r
<AfC> bastards
<lifeless> poolie: if that fixes it, there is a bug either open or needing filing about this
 * igc out for a few hours
<mwhudson> hazmat: hello
<mwhudson> nm, i'll email
<hazmat> hi mwhudson
<hazmat> mwhudson, thanks, i missed that in my conversion attempt, that should do the trick
<lifeless> EOD; ciao
<poolie> ciao, thanks for the bug & review comments
<poolie> and lh feedback
<lifeless> np :)
<poolie> hello spiv
<poolie> nice to see you back
<spiv> poolie: thanks
<spiv> poolie: so nice that you'll review https://code.edge.launchpad.net/~spiv/bzr/smarter-index-search/+merge/21615? :)
<poolie> i did read it actually
<poolie> should i go through and try to check if you did everything john wanted
<poolie> or should i just review it myself?
<poolie> if you're confident on the former i can do the latter more qucikly
<spiv> Either would satisfy our process, and me, I think.
<poolie> :) ok
<spiv> I am pretty confident that I've done everything John suggested, but it's been almost two weeks so my memory for the details is fading.  The biggest thing by far though was that it needed tests, and I've added some.
 * vila @dentist, bbs
<phexter> when trying to branch somthing like lp:xyz i get the following error message: "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.", while http connection work fine. can someone explain me how to solve that? gooogling turned out to be rather frustrating and fruitless... though i think i know that it has to do something with the key verification.
<fullermd> You could try connecting to LP with sftp/ssh directly and check the keys that way.
<phexter> problem solved
<phexter> i didn't had openssh-server installed and the lp ssh key i registered was wrong as well
<spiv> phexter: you don't need openssh-server, you do need openssh-client (or an alternative client like paramiko) instead
<spiv> phexter: but I'm glad it's working for you now :)
<phexter> well i had the whole ssh packet not rightfully installed, and i needed the ssh server package so seahorse could create and setup a new ssh key which i then could update to lp
<phexter> i probably could have created just the key, but it worked and therefore i don't worry too much about it ;)
<d1b> question on windows is pycurl still used ? (for ssl stuff)
<vila> d1b: .bzr.log should already contains the answer. If it doesn't try adding -Dhhtp and use an https url
<d1b> vila: im not on windows
<vila> d1b: well, me meither :)
<d1b> vila: ...
<vila> d1b: it used to be included for https certificate verification, if you don't need that, you shouldn't care, is that the case ?
<d1b> vila: im trying to work out how to solve bundling pycurl on windows
<d1b>  / ssl checking on windows
<vila> d1b: meh, how do you do that without being on windows ?
<hansinge> What is the best way to upload/update a website? The  bzr-upload plugin? Is it better to install bzr on the server?
<d1b> vila: do it on windows in a vm
<vila> d1b: so my first remark applies, check .bzr.log on windows
<vila> bialix: do you know the status of pycurl on windows ? And its history if it's not included anymore ?
<bialix> vila: last time you said me that pycurl is not needed
<bialix> vila: I think it's no more bundled into windows installer
<bialix> but I don;t know is there any explicit disbale for pycurl
<vila> bialix: it's needed if you want certificate verification
<bialix> yes, if you want verification. but even without it everything is works, no?
<vila> bialix: if you don't need the verification, yes, the urllib based transport works
<bialix> I don't know is I need verification
<vila> bialix: *you* may not need it, but d1b seems to be needing it :)
<bialix> yeah, I'm trying to joke
<vila> d1b: so all that is needed is to check if pycurl is still bundled and if not file a bug on lp asking for it
<vila> d1b: all the code is already in bzr to use pycurl if it's installed
<bialix> vila, d1b: there is no pycurl library in 2.1.0
 * vila finds that amazing...
<awilkins> I found PyCurl caused more problems than it solved when I was running earlier versions so I uninstalled it
<bialix> I mean in the official bzr.exe Windows installer
<awilkins> (on Windows)
 * bialix remember to have some "nice" days to attempt adding support for certificates
<bialix> d1b: pycurl itself is not enough, you have to add bundle with CA certificates
<bialix> I've used the ones from Mozilla
<bialix> also there was problem with self-signed certificates
<d1b> bialix: yes
<d1b> i saw thah too
<lifeless> anyone know how big a task it was to glue the bzr http server layer into loggerhead?
<spiv> lifeless: I don't think it was too large
<spiv> lifeless: bzr's http server stuff is WSGI, after all
<spiv> lifeless: there's a fairly small "if relpath == '/.bzr/smart':" check in loggerhead/apps/transport.py
<spiv> lifeless: I'm not sure how much other code had to be rearranged to keep that so simple, but the end result seems fairly straightforward :)
<u-foka> Hy!
<u-foka> What is the best practice to set up a shared remote repository?
<u-foka> I have 3 system users who have to access the repository but noone else
<u-foka> I tryed troughsftp:// but the first push seems to remove my group write permissions :S
<u-foka> is bzr+ssh works better in that situation?
<u-foka> or where I should look around?
<naoki^_> u-foka: May sticky bit help you?
<naoki^_> http://www.profarius.com/content/creating-your-own-bazaar-server
<u-foka> thanks, will read :)
<fullermd> Sticky bit won't affect anything.
<fullermd> Presumably you mean the setgid bit.  That affects the group ownership, but wouldn't touch the group write.
<fullermd> That gets set based on <some directory>.  Generally just setting g+w on every dir under .bzr/ is the simplest way.
<u-foka> yeah, you both right, now I checked again, and really the files created with group write by bazaar, but under my users's name+group, and this what sticky bit can solve right?
<fullermd> setgid.  Yes.
<fullermd> I dunno who started the fad of calling it 'sticky', but it's totally wrong.  Sticky bit is 01000.  Setgid is 02000.
<vila> fullermd: it may have to do that both are displayed 's' in ls -l ?
<fullermd> Well, all the 0x000 bits show as s's.
<vila> Or that both carry the idea that they "stick" to whatever they are applied to
<fullermd> My cynical side says it's because somebody heard "sticky bit" once, and it stuck floating in their head looking for something to hitch onto.
<spiv> fullermd: ...for something to *stick* to ;)
<fullermd> But then, I'm a grumpy old misanthrope.  And git offa my lawn!
<spiv> fullermd: or to put it another way... your theory is that "sticky bit" is a sticky bit of terminology ;)
<vila> fullermd: the thing is.... I mixed them for a long time... until I read the Fine manual :)
<spiv> fullermd: and you wonder why people are confused? :)
<fullermd> Oh, I don't assume people are confused.  Never attribute to incompetence what can be adequately explained by malice   :)
<spiv> So the "Referer" header was misspelled as part of an evil plan, rather than by accident?  Hmm.
<fullermd> Right.  The conspiracy becomes totally obvious when you link it with the creat() syscall, see.
 * vila feels warm inside about all those people making typos too...
 * bialix using bzr log to look at his own timezone
<u-foka> thanks again! now it works great :) But this setgid (or whatever) thing shouldn't be part of the user-guide's server page?
<Tak> when I do a lightweight checkout from a svn repo, is bzr supposed to go through the "analyzing repository" stuff for all the revisions?
<LeoNerd> It moreorless has to, doesn't it?
<Tak> I don't know; does it? :-P
<Tak> I would expect a lightweight checkout to just need the tip
<fullermd> How can it know what the tip is?
<fullermd> Light co of svn sounds like pain incarnate.  A regular light co has to talk to the other side any time it needs any rev info.  With svn, it would have to re-derive it every time it needed something.
<Tak> hmm
<Tak> I guess I was hoping to get more or less a svn co, but with ability to do things like shelve
<fullermd> You may be able to do that in an actual svn co.
<ibboT> hi I'm trying to pull from a branch on a USB stick (I originally created the repository by branching from the USB stick) but I get: bzr: ERROR: [Errno 17] File exists
<ibboT> this is using bzr in cygwin on windows
<awilkins> Tak, what you want are stacked-branches-on-svn-repo   . I don't think bzr-svn supports that yet.
<awilkins> Tak, I just take a local bazaar branch of the svn branch and make a lightweight checkout of that (or a topic branch of it)
<Tak> awilkins: thanks - I was hoping to avoid that in this case
<awilkins> Tak, big repo? Know the feeling.
<awilkins> Branching things out of the Apache SVN is a PITA, it has about 900,000 revisions or something stupid
<Tak> big repo, often big changes in big binaries between commits
<awilkins> Yuck
<awilkins> Jelmer might be able to answer, if he wasn't Guest91560
<Boingo> Hello everyone.  I am still a bit new to bzr and trying to get my head wrapped around how I should best use it.  In my case, I have a distributed team work on a base project (PHP website).  Most of the work goes into the base product.  But, from time to time, we need to branch and create specific version for a client.  Most of the changes are cosmetic, CSS, images, etc.  Some are code changes.  Either way, we would like to be able to track the changes in th
<Tak> oh, and my connection is through a vpn to a different continent ;-)
<awilkins> Tak, One way I deal with this is having a machine close to the repository on which I can take the Bazaar branch and then I pull that using bzr+ssh
<awilkins> Tak, but not always an option of robvious reasons
 * Tak nod
<Hillshum> Can I put repos inside other repos?
<fullermd> Do you really mean that, or do you mean branches inside other branches?
<fullermd> Either way, the answer is "yes, but", but the buts are different.
<Hillshum> fullermd: Maintain subprojects within one main repo
<fullermd> See, I think you really mean 'branches' there.  Anything you work on is a branch, not a repo.
<fullermd> In any event, you can certainly put one branch inside another in your workspace, but that doesn't establish any connection between them, just impositioning.
<fullermd> Establishing a logical connection would be the realm of "nested trees", which isn't an implemented capability.  There are some plugins that approximate it (scmproj and externals being the two primary ones now, I believe)
<maxb> oh dear, is it the qt changes in lucid that have broken qbzr? :-(
<maxb> Hillshum: A question you might like to consider is: Should these subprojects really share a single common history? Will they really always be branched, merged, tagged as one complete unit?
<Hillshum> maxb: No
<maxb> In that case, they definitely should be a separate branch per subproject, and if you need a tool to compose a certain filesystem layout from a set of branches, scmproj or externals may be relevant to you
<Hillshum> Okay
<masklinn> excuse me, I'm trying to list the branches contained in a shared repository, my googling lead me to believe there would be a "bzr branches" command that would do that, but upon trying it this results in bzr: ERROR: unknown command "branches" using bzr 2.1.0 in OSX
<IslandUsurper> masklinn, it's in the bzrtools plugin/package
<masklinn> IslandUsurper: oh damn, I thought I'd reinstalled it along with bazaar yesterday, but you're right I forgot about it and it indeed isn't installed
<masklinn> thanks
<IslandUsurper> np
<TresEquis> Is this the channel for 'bzr explore' hacking?
<GaryvdM> TresEquis: Hi, yes
<TresEquis> I'd like to work on getting 'make' to run from inside a project (to build Sphinx docs, actually)
<TresEquis> any pointers on where to start?
<TresEquis> I'd like to stay mostly "naive" about the code, if I can help it, although I read and write Python for a liviing
<the_angry_angel> hi guys, stupid question, but i've hunted through the docs and tried what I'd consider to be the obvious - how can I get bzr forced to use a username and password when checking out from a svn repo? theres anonymous read access, but no matter wht I've tried bzr 2.1.0 on OSX will not allow me to commit. I've tried including the username and password in the URL, I've looked for arguments and failed. any sugestions, or does it need to be shoved i
<beuno> the_angry_angel, including them in the URL is the way to go, AFAIK
<the_angry_angel> beuno: thats what I figured from some old, old posts on the mailing lists
<GaryvdM> the_angry_angel: You can also try authentication.conf
<GaryvdM> TresEquis: Confused. How does make/spdinx docs relate to bzr explore?
<the_angry_angel> GaryvdM: will do. I've just confirmed that it works as expected under Windows and Linux, so I'm guessing that its an OSX specific bug - cheers for the assistance guys
<DebbieWork> Hiya.  I just got told to 'use bzr' for our project's VCS.  I've been reading up, and get a little lost in the diffs bet shared, stacked & nested branches.  If I init-repo my own repo @ "/project", and pull in two branches, /proj/brA & /proj/brB, from 2 different sources, I think I have a 'shared' repo, right?
<GaryvdM> DebbieWork: Yes
<GaryvdM>  repo @ "/proj/" not  repo @ "/project/"
<DebbieWork> GaryvdM: Oops type :-) Thanks.  Ok, so what if I instead create /proj/, pull in /proj/brA, then pullin /proj/brA/brB.  Is that 'nested' or 'stacked'?
<DebbieWork> Ugh. typO.
<thumper> DebbieWork: you can pretty much ignore stacked and nested branches (you shouldn
<thumper> DebbieWork: shouldn't need them
<GaryvdM> DebbieWork: shared,
<DebbieWork> GaryvdM was it something i said? ;-)
<GaryvdM> No press ctrl q by mistake
<DebbieWork> thumper Then what's the best way to 'do' /proj/brA/brB?
<DebbieWork> GaryvdM: :-)
<thumper> DebbieWork: what are you trying to do?
<GaryvdM> DebbieWork: You can safely ignore stacked and nested branches when you are starting out. However shared repos are important.
<DebbieWork> thumper: Well, first - LEARN! :-)  But, eventually, the proj is a CivicSpace rollout.  Basically, Drupal layout.  Which has the site files buried in a folder in the install.  So, I wanna check out the install from the CivicSpace site (into /proj/brA), then checkout the site files from somewhere else (into /proj/brA/brB), and "end up" with a dir structure that I can publish to the web.
<thumper> DebbieWork: I'd ask emmajane
<thumper> DebbieWork: I'm sure emmajane has worked with bzr and drupal
<DebbieWork> GaryvdM: I'm missing the "important" part of shard repos.  I get the "convenient" biz -- less disk space.
<thumper> DebbieWork: shared repos are really helpful for speed of creating other branches (as it isn't copying revisions)
<DebbieWork> thumper: Thanks!  emmajane ping?
<GaryvdM> DebbieWork: Disk space, and time to branch.
<DebbieWork> GaryvdM: Time to branch inside the same shared repo, you mean?
<lifeless> moin
<GaryvdM> DebbieWork: Yes
<DebbieWork> Ooh, is that *this* EmmaJane? http://www.amazon.com/gp/product/0137136692/
<GaryvdM> Yes
<DebbieWork> GaryvdM: Huh.   Didn't think that that'd be 'important'.  But, I havan't done a gazillion branches yet.  Probably adds up!
<DebbieWork> GaryvdM: Great!  I ordered her book yesterday :-D
<DebbieWork> thumper: "as it isn't copying revisions".  Just the latest changes, then?  That's the 'sharing' part, right?
<idnar> if you're branching within the shared repo, then by necessity all of the revisions involved must already be in the repo, so none will need to be copied
<idnar> if you branch from somewhere else, then any revisions not already present in the repo will need to be copied, but those that you already have don't need to be
<orbarron> hello all.. need some help :) I want to do the following:  lp: project-rootstock however I am getting the following error --> bzr: ERROR: Connection error: Could not resolve 'edge.launchpad.net' [Errno -2] Name or service not known
<orbarron> has anyone seen this?
<orbarron> opps.. let me correct that I am running the following command --> bzr branch lp:project-rootstock
<DebbieWork> idnar: "any revisions not already present in the repo will need to be copied".  Ok, I see the various .bzr folders -- at the 'top' dir for the init-repo, and in each of the branches.  The shared, and need-to-be-copied, repos' revisions *all* go in to the top-level .bzr? Or each bracnh gets its revisions, but meta-data about it all in the top level?
<idnar> DebbieWork: as I understand it, the branch is a record of which revisions make up that particular branch
<idnar> DebbieWork: but the actual data about those revisions (file contents etc.) are stored in the repository
<idnar> DebbieWork: so the shared repository resides in the top-level .bzr, while the branch data sits in the lower .bzr dirs, as you said
<GaryvdM> orbarron: can you access launchpad.net in a web browser?
<GaryvdM> orbarron: do you use a proxy server?
<DebbieWork> idnar: Poking around with 'du -h', that seems to make sense. Of course the actual DATA files stay in each branch.
<GaryvdM> DebbieWork: FYI "Data files" are refered to as Working Tree
<GaryvdM> If I understand you correctly.
<poolie> hello gary, all
<GaryvdM> Hi  poolie
<GaryvdM> bla #qt is so rude.
<GaryvdM> unhelpfull
<GaryvdM>  /rant
<DebbieWork> GaryvdM: Hum.  Well, I created 'init-repo --no-trees', then pulled some branches of external projects into the top-level repo.  Those barnches have all the project code in them -- my "data files" -- but there are not Trees involved yet.  Iiuc, I only get a Working Tree if I now checkout (rather than branch again) a branch somewhere.
<DebbieWork> This all makes a girl's head spin 8-}
<DebbieWork> GaryvdM: They're even worse if you're a paying customer!  ;-p
<GaryvdM> DebbieWork: if you do bzr checkout in an existing, that branch will then have a working tree. Run bzr remove-tree to remove the working tree.
<GaryvdM> *existing branch
<DebbieWork> GaryvdM: Ooh, didn't know that.  So a branch minus its WorkingTree is ... Empty? (except for the .bzr)
<GaryvdM> a branch without a working tree
<idnar> yeah, there'll just be a .bzr
<DebbieWork> Hum.  I guess I need to re-read the checkout vs branch stuff (still thinking about how to layout the CivicSpace project code -- for Production, Staging & Development using bzr).  So many options!   CVS is *much* simpler.  Of course you can't DO much with it :-)
<DebbieWork> Well, DUH!  This page snuck past me http://wiki.bazaar-vcs.org/CheckoutTutorial.
<TresEquis> GaryvdM: I want to add a tool to my explorer which can kick off a 'make html' inside the project's 'docs' directory
<TresEquis> Typical IDE task
<TresEquis> This page mentions it as a future feature: http://doc.bazaar.canonical.com/explorer/en/tutorials/customization.html
<TresEquis> Note
<TresEquis> It would be nice to support make, ant, etc. here. That may work via launching a shell each time. Patches welcome.
<TresEquis> (end of quote)
<orbarron> GaryvdM: I can access it in a web browser
 * orbarron believes this is a proxy issues... :(
<GaryvdM> TresEquis: I see. I'm not sure myself. Look out for igc. He is in Australia, so he will be awake soon.
<orbarron> just not sure how to set up for bzr
<DebbieWork> Ok. So if I have a local branch in a shared repo, /proj/brA, and want to hack on brA *on the same machine*, I can either (1) just hack diretcly on brA, (2) checkout brA brAdev, hack on brAdev, with @commit auto pushed to brA, or (3) branch brA brAdev, hack on brAdev, commit, then update ?
<GaryvdM> poolie: I'm not sure if I have missed mail or not. What is the status of 2.2b1?
#bzr 2010-04-01
<TresEquis> DebbieWork: branch /proj/brA -> /proj/brAdev, hack on brAdev, comit (lather, rinse, repeat);  then "push" brAdev->brA when ready
<spiv> Good morning
<TresEquis> for extra bonus points, brA can be "bound" to a remote branch, so when you push brAdev -> brA, it also pushes to the remote branch
<DebbieWork> TresEquis: Ok, that sounds the most straightforward.  And do heavyweight chekouts @ remote locations?
<poolie> GaryvdM: no, just delayed for silly reasons, should be out today
<GaryvdM> poolie: Ok - understand.
<TresEquis> DebbieWork: the "bound" branch (/proj/brA) can be a checkout of the remote branch
<TresEquis> making it "heavyweight", and inside a share repo, makes it possible to unbind if needed (e.g., while disconnected)
<DebbieWork> TresEquis: Sure thing.  But @ my local box, that's remote to the source repo's origin, I'd *checkout* to my local machine, typically, right?
<DebbieWork> This sentence: Let's start by saying there is nothing you can do with a Checkout that you can't do with plain Branches. A Checkout just enables different defaults and workflow helpers.
<DebbieWork> has me trying to figure out the which/when bits ...
<TresEquis> checkouts work by default like SVN / CVS
<TresEquis> your commits get pushed to the remote server, and you have to be up-to-date to commit
<TresEquis> you might check out the workflows doc:  http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html
<DebbieWork> TresEquis: Yah, saw that.  I can image using any/all of them :-/  I'm hoping to use what's typical in CivicSpace/Drupal land, so I can chat with them about stuff.  Hoping emmajane will be able to share a comment/recommendation or two.
<igc> morning
<DebbieWork> TresEquis: @ #drupal I just learned that Drupal.org is "moving to git", but for my purposes, I don't think that matters at all.
<igc> TresEquis: it's not easy to run 'make html' in a given directory inside Explorer yet
<DebbieWork> TresEquis: Given your example, "then "push" brAdev->brA when ready"  What would you typcally do, e.g., when it's time to publish to the web?  publish brA directly? Or 'branch brA brAprod' and publish brAprod?
<TresEquis> igc:  I was looking to hack on the tools / commands stuff to make it easy.  I just want to know where to start looking, rather than having to read the whole BE codebased
<igc> TresEquis: you can configure "local application" tools though so one option is to try writing a script that changes directory there before running 'make html' say
<igc> TresEquis: ah - ok
<TresEquis> DebbieWork: remote server as the "canonical" / published branch and working dir;  locally, I make a "heavyweight checkout" if it in my shared repo, then branch from the checkout for development
<igc> TresEquis: lib/extensions/tools.py is the core of the tool support
<TresEquis> I can commit to the dev branch without touching the published side
<igc> TresEquis: see https://code.edge.launchpad.net/~simon-kersey/bzr-explorer/add-bzrexec-tool/+merge/22522 for a nice patch to improve things
<TresEquis> when I "push" inside my dev branch, it updates the heavyweight checkout, which in turn pushes to the remote server
<TresEquis> igc: thanks -- I didn't see code there to interpret command line, tc.
<igc> TresEquis: I'll hopefully review that patch today
<igc> TresEquis: hmm - why are you expecting to interpret the command line?
<DebbieWork> TresEquis: Bingo! That makes sense, and does what I think I want!  And I didn't even have to make sens asking for it ;-)
<poolie> hi igc
<TresEquis> igc:  I want to figure out how the %(foo)s expansions are done
<TresEquis> e.g., to add new names if need be
<TresEquis> for instance %(pool)s resolves to a file:///.... URL, which can't be passed to commands like 'cd'
<igc> TresEquis: see lib/app_suite.py
<igc> hi poolie
<TresEquis> igc:  thanks
<DebbieWork> Dinner-time!  Thanks everybody! Helped a lot :-)
 * GaryvdM -> bed. Bye all.
<TresEquis> night all
<bendj> After commiting changes in a checkout, what't the right way to delete the checked-out directory, if I don't want it around anymore?  Just 'rm -rf' the dir? Do I need to do a 'bzr remove' or 'bzr remove-tree'?
<spiv> bendj: just rm -rf
<bendj> spiv No need to tell it's parent repo (if I've checked out into a shared repo for example ...) about the removal?
<bendj> Oops, its.
<spiv> bendj: nope
<bendj> Great, thanks.  Confusing keeping track of what's keeping track of what!
<poolie> hello spiv
<poolie> i'm going to start cutting 2.2b1
<spiv> poolie: yay
<poolie> actually i really am
<poolie> but it will help me concentrate if you can clear the new bugs
<spiv> Ok
<poolie> thanks
<bendj> I've got a shared bzr repo containing multiple branches & checkouts.  If I want to update to all the latest sources, I can certainly enter each branch/checkout and pull/update/whatever.  Is there a *single* command that can update everything to the most current?
<fullermd> There's a multi-pull command in bzrtools.  It's basically the moral equivalent of `find . -is-a-branch | xargs bzr pull`
<ctrlsoft> fullermd: the /moral/ equivalent?
<fullermd> Well, immoral equivalent, maybe.
<bendj> fullermd Got it.  Took me a minute to figure out its an addition plugin ...  Is that typically the approach used for "assembling" a project for final-publication ( a book, a website, whatever) from numerous, disparate sources?
<bendj> Agh! it's
<bendj> (always bass-ackwards!)
<poolie> wow launchpadbugs (used by check-newsbugs) is strange
<poolie> which is https://bugs.edge.launchpad.net/bzr/+bug/354985
<ubottu> Ubuntu bug 354985 in bzr "check-newsbugs.py LaunchpadLoginError" [Low,Confirmed]
<ctrlsoft> poolie: strange in what sense ? :-)
<ctrlsoft> check-newsbugs should probably be ported over to launchpadlib now, it's more widely available
<poolie> yes, it should be
<poolie> just the object proxy abstraction in eg /usr/share/pyshared/launchpadbugs
<poolie> for a moment i expected this had been ported to use the api
<wgrant> python-launchpad-bugs predates the API by quite a while.
<poolie> mm
<wgrant> Any remaining users of it are wrong.
<poolie> and was probably very useful before it existed
<poolie> right, that bug says we should move away from it
<wgrant> Right.
<poolie> i wonder if its ubuntu package description should be updated
<wgrant> It should probably be removed from Lucid.
<wgrant> Only two packages depend upon it, and they both also use launchpadlib.
<wgrant> And fixing that for five years isn't going to be fun.
<poolie> k
<poolie> bum de dum "please wait"
<poolie> wgrant: but it would need upstream changes to detangle those packages?
<wgrant> poolie: Well, upstream for both is Ubuntu, but yes.
<poolie> well, https://bugs.edge.launchpad.net/ubuntu/+source/python-launchpad-bugs/+bug/552953 if you want to say your piece
<ubottu> Ubuntu bug 552953 in python-launchpad-bugs "launchpadbugs should be deprecated or removed from launchpad" [Undecided,New]
<poolie> title corrected
<wgrant> ubuntu-qa-tools should be easy to port -- it already mostly uses launchpadlib. bughelper will be harder, since it doesn't yet. But that might indicate that it's mostly abandoned.
<poolie> jelmer, lifeless, it would be interesting, maybe next week, maybe in belgium, to look at making looms fit with jelmer's named branch work
<ctrlsoft> poolie: yeah
<TresEquis> igc: I was able to get my new command type added
<TresEquis> just pushed the branch to LP and proposed a merge
<igc> TresEquis: cool. I'll take a look later today
<TresEquis> thanks for the pointer
<TresEquis> BTW, I couldn't figure out how to run the tests
<igc> TresEquis: no problem
<eydaimon> how can I see the current revision number?
<Meths> bzr revno
<eydaimon> bzr log | head? is there an easier way?
<eydaimon> ok, thanks
<TresEquis> it might be good to have a HACKING file which tells how
<igc> TresEquis: Explorer don't really have any tests currently
<TresEquis> ok, then I don't feel guilty for not adding any ;)
<igc> TresEquis: the current HACKING page is http://doc.bazaar.canonical.com/explorer/en/development.html
<fullermd> Heck, you added tons of 'em.  At least doubled the previous total.  Maybe tripled  ;p
<TresEquis> that page needs a "Running the Tests" link, once it is relevant ;)
<igc> yes :-)
 * igc back in a few hours
<poolie> lifeless, where does the python-testtools in the pqm chroot come from? the testtools ppa?
<lifeless> the sysadmin archive
<poolie> oh of coursne
<poolie> but as a custom backport from lucid or karmic?
<lifeless> no idea sorry
<DebbieWork> ping emmajane
<emmajane> DebbieWork, what's up?
<DebbieWork> emmajane: Hiya!  Folks in here said I shoud ask you :-)  Have a question about using bzr with CivicSpace/Drupal layout ...  Can bzr do this:
<DebbieWork> (sec, typing ...)
<emmajane> DebbieWork, errr I'm not sure how useful I'll be. It's pretty late here. :)
<DebbieWork> can it, or should it?
<DebbieWork> emmajane: bzr init-repo ./TOP_DIR; cd ./TOP_DIR; brz branch DRUPAL_BZR_REPO ./myDrupal; cd ./myDrupal; bzr branch MY_FILES ./sites/mySite
<DebbieWork> What I'm trying to do , of course, is put together my drupal site tree from multiple branches, and manage it as one.
<DebbieWork> emmajane: Just looked up!  Sorry, if it's late -- np!  Another time.
<emmajane> I keep all sites as completely unique branches.
<emmajane> you mean the /sites folder, right?
<DebbieWork> emmajane: Yah, the /sites folder.  How do you include them in the Drupal install tree, then?  symlink?
<emmajane> i.e. I'm not sure what the advantage would be of merging www.example.com with www.foo.com.
<emmajane> just a sec
<DebbieWork> emmajane: Nah, I'm only talking about one site (for now).  Just trying to understand how best to separate the branch pulls of drupal source and my files ...  Seems like it should be two separate branches.
<DebbieWork> Don't know how to embed one branch UNDER another, since the /sites folder needs to be UNDER the drupa site install 'top'
<emmajane> DebbieWork, this is how I do it: http://www.flickr.com/photos/emmajane/4480852752/
<emmajane> I remove /sites from the drupal folder and then symlink that back in
<emmajane> I don't version drupal core.
<emmajane> I let CVS take care of that for me.
<emmajane> when I'm hacking on core then I hvae that in a totally separate place from my live sites and I put core (but not sites) under version control.
<emmajane> http://horncologne.com/content/nice_server_setup_helps_streamline_upgrades that's sort of what I do.
<emmajane> (as far as the directory structure goes)
<emmajane> even sites I don't really put under version control though. Just themes.
<emmajane> (but I'm not a module developer)
<emmajane> i.e. I *only* version the stuff I will be editing.
<DebbieWork> emmaja Cool!  Thanks for the reference, too!  So when you CVS up your core, you've an ignore set for the symlink?
<emmajane> CVS ignores symlinks by default IIRC
<emmajane> CVS is stupid. :)
<poolie> hello emmajane
<poolie> rebooting, biab
<emmajane> DebbieWork, I also don't CVS up core.
<emmajane> I download a new version and adjust the symlink.
<emmajane> that's why there's drupal5.22 and random other older versions kicking around.
<emmajane> (also: yes, i ought to be shot for not upgrading my D6 installation)
<DebbieWork> emmajane: Hehe!  Actually, I'm debating CivicSpace, or going with Pressflow (Just found that! Neat!) and rolling my own.  Pressflow maintains in/with bzr, Iiuc.  Same principle applies, I guess.
<DebbieWork> Although I'd like to follow the Pressflow repo.  Thinking of some variation of  http://xdeb.org/node/1249
<emmajane> I don't have the capacity to follow links. :)
<emmajane> sorry. too tired.
<DebbieWork> emmajane: Np!  You've been a help already :-)  That link is ""Bazaar workflow for developing Drupal based web sites".  Talks about multiple branching levels of Pressflow source, source+modules, source+modules+customizations etc.
<emmajane> if you're just deploying drupal you probably don't need to worry at that level.
<emmajane> poolie, hey :)
<DebbieWork> emmajane: I'm w worrier! :-)  Lots of grey hair, doncha kno ;-)  Anyway, I just got lost in all the options bzr presents.  Really helpful to get your take on it.  Seems that there are countless discussions about how to stage Drupal/CivicSpace/etc, but few best-practice recommendations.  That I've found anyway.
<DebbieWork> emmajane: Hoping your book (which will arrive tomorrow, I hope :-D) will help with same on the themeing end of things!
<emmajane> Do you know the term "bike shedding"? ;)
<emmajane> I say: put the stuff you edit under version control and get on with life. :)
 * emmajane is a minimalist though.
<DebbieWork> emmajane: "Bike shedding".  Ha!  My brother in law has a big one.  Chock full of old motorcycles.  But I get your point :-)
<SamB_XP> the point is arguing about what color to paint it ;-)
<SamB_XP> you can even do that after you already made a bikeshed, IRL ;-P
<emmajane> :)
<fullermd> What's to argue?  Turquois, obviously.
<DebbieWork> Hm, since 'stupid' CVS nicely ignores symlinks, I'll presume that 'smarter' bzr doesn't.  Does it follow symlinks and version-control the file under them, or simply version control the link itself?
<emmajane> bed time for me.
<fullermd> The link itself.
<emmajane> DebbieWork, g'luck with everything. :)
<DebbieWork> Thanks :-)
<DebbieWork> emmajane Nighty nite!
<DebbieWork> fullermd: Is there an option to follow the link?  I've found requests in '08 for that capability, but haven't found a resolution yet.
<fullermd> Not AFAIK, no.  That would get into all sorts of icky questions about what to do when it points outside of the branch, frex.
<poolie> ok so i'm going to pull a bit more on lazy command loading
<fullermd> What a coincidence.  I was going to go be lazy a bit more on pull command loading.
<poolie> since that is paged in
<DebbieWork> fullermd: K, good point I suppose.  Anyway, good to know. Thanks.
 * Tak agree @ turquoise
<SamB_XP> wait a minute, someone just mentioned bikeshedding in a #haskell-unaffiliated channel?
 * SamB_XP didn't realize that before ;-)
<lifeless> SamB_XP: http://haskell.bikeshed.com/
<Tak> bikeshedding predates haskell
<poolie> lifeless: istm .testrepository should be ignored?
<lifeless> poolie: yep
<igc> back
<poolie> hey igc
<igc> poolie: it might be good to announce 2.1.1 and 2.0.5 today
<poolie> igc, yes, i think so
<poolie> i think in general it would be good to announce the whole bundle of releases together
<igc> poolie: also, I'd like to find out why the website build script is failing
<poolie> but in this case there is too much of a gap between them
<igc> I just tested it here and it worked fine for me
<poolie> maybe it's a python2.4 thing
<igc> maybe
<igc> I guess we can guard against that field not being here and continue working
<lifeless> poolie: so, as discussed yesterday, a call now ?
<poolie> give me a couple of minutes to file this rt
<lifeless> sure
<poolie> igc: works
<igc> thanks
<poolie> well, "doesn't crash" :)
<igc> :-)
<igc> poolie: hmm, the developer blog isn't rendering at all
<igc> poolie: so maybe it's a firewall thing accessing that location?
<lifeless> poolie: ring when you're ready
<poolie> someone else called; ok
<lifeless> heh
<poolie> igc, it says "fetching data from bazaarvcs....."
<igc> poolie: it's weird
<vila> hi all !
<igc> hi vila!
<lifeless> wow http://xkcd.com/ today
<nlisgo> whats your preferred comparison tool for the mac? I just discovered FIleMerge
<vila> lifeless: history navigation ftw ! (up and down arrows work :)
<jszakmeister> anyone here familiar with the bzr-email plugin?
<vila> jszakmeister: better ask your question anyway, familiar depends on the area your question is related to...
<poolie> hello vila
<vila> hey poolie !
<bialix> hi poolie
<jszakmeister> I'm just trying to understand some of the documentation for bzr-email.  In one section it says:
<jszakmeister> The URL of the branch is determined from the following checks (in order):
<jszakmeister>  - If the configuration value 'post_commit_url' is set, it is used.
<jszakmeister>  - If the configuration value 'public_branch' is set, it is used.
<jszakmeister>  - The URL of the branch itself.
<jszakmeister> How does it determine the URL of the branch itself?
<jszakmeister> And I'm curious about why no emails get sent for push by default?
<jszakmeister> (I think I want to enable them, but I'd like to understand the philosophy behind it more before making that decision). :-)
<jszakmeister> And, I have one more: in the docs it says "if not supplied defaults to the email address reported
<jszakmeister> by ``bzr whoami``" but is that of the person doing the commit?  Or is that the ``bzr whoami`` of the hosting provider?
<jszakmeister> (In my case, Apache)
<poolie> on the last one, it would be whereever the plugin is actually running
<poolie> isn't bzr-email normally client-side?
<jszakmeister> I dunno. :-)  This is the first time I've ever looked at it. :-)
<jszakmeister> How do you ensure that an email always gets sent with a commit to a public branch then?
<poolie> http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/hooks-plugins.html
<jszakmeister> Heh.  Wonder how I missed that?  I'll take a look at one of the other alternatives. :-)
<lifeless> poolie: jszakmeister bzr-email can be client or server side
<jszakmeister> I was just looking at that again, and getting ready to ask that question. :-)
<lifeless> no emails on push by default because if installed client side that results in emails on commit and then on push
<jszakmeister> Ah.
<jszakmeister> Makes sense.
<lifeless> on a server side install you want it set to send on push
<jszakmeister> How is this typically configured server-side?
<jszakmeister> Via the branch.conf or through locations.conf?
<lifeless> yes
<jszakmeister> ?
<jszakmeister> Is one preferred over the other?
<lifeless> not really
<lifeless> up to you
<lifeless> if one was preferred,t he docs would say so :)
<jszakmeister> Does the branch.conf follow the branch when cloned?
<lifeless> no
<jszakmeister> (or at least some of it's settings).
<jszakmeister> Okay.  So I don't need to worry about things propagating unexpectedly. :-)
<igc> poolie: what branch did 2.2b1 come from? lp:bzr/2.2 is 6 weeks old
<jszakmeister> I think I need to look at that a little more.  I'd like to avoid having an admin go and configure a branch every time a new one shows up (which kind of points to using locations.conf), but...
<poolie> igc i'm confused why there would be a 2.2 branch
<poolie> igc, also, my merge to 2.2 bounced because of a python2.4 issue, i think
<jszakmeister> then I don't want to have to edit the locations.conf by hand every time either.  Screams for a script to help me.
<igc> poolie: not sure. I recall jam asking for one
<igc> poolie: also wrt the website, I think we should just revert index.html for now
<igc> and disable the build.py script from running
<igc> poolie: we an sort out the feed issue after you get back from leave
<igc> s/an/can/
<poolie> ok i'll do that now
<lifeless> jszakmeister: you could do locations.conf, though we don't supoprt bzr:// soft chroots all that well in there
<lifeless> johnf posted something about this a while back, I think
<lifeless> checkt he bzr-email bugs perhaps?
<jszakmeister> I'll take a look...
<jszakmeister> BTW, what does "soft chroots" mean?
<lifeless> inside bzr serve
<lifeless> we don't use the disk url for branches
<lifeless> we use a chroot:// url, which normal path traversal can't break out of
<lifeless> only code that explicitly unwraps it can - so it enforces configuration of writable/accessible roots
<lifeless> bbiab
<jszakmeister> And that's a problem because it may affect how the branch is looked up in locations.conf?
<lifeless> yes
<lifeless> I don't remember what johnf did to deal with this
<jszakmeister> Okay.  I'll search around a bit... the initial searches haven't turned up anything though.
 * igc dinner
<lelit> hi all, does bzr allow giving access only to particular subtree of a repository, ala svn? I'm going to do a complete switch from svn to bzr, and I'm currently looking for the best fit
<bialix> no
<lelit> ok, thanks
<bialix> you have to put every subtree into separate branch
<awilkins> Or put up with it and arrange your build system to cope with it
<awilkins> There are still advantages to atomically versioning co-dependant packages
<bialix> both scmproj and bzr-externals has support of snapshots for achieving this goal
<lelit> awilkins: not sure I understand... what I need is to give only a subset of my "whole thing" to some other developer
<bialix> lelit: split your whole thing into components
<awilkins> lelit, Then that needs to be in a separate branch
<lelit> then of course my "build system" (and deploy) take the whole thing into consideration
<lelit> ok
<bialix> and then assemble the whole thing in similar fashion as with svn:externals
<lelit> ah
<bialix> lelit: you may find bzr-externals plugin very useful for this
<lelit> didn't know about bzr-externals (this will be my first serious use of bzr...)
<bialix> there is also scmproj
<bialix> but it seems people like bzr-externals more
<lelit> ok, thank you
<bialix> lelit: if you don't like to use command-line, then bzr-externals will be the best choice
<lelit> another simple doubt: I'm a darcs guy, and am wondering about its interactive "commit" feature; I know about the shelves, but is there some kind of wrapper/plugin that simplify its usage?
<lelit> bialix: that's not a problem for me
<bialix> lelit: check interactive plugin
<lelit> great
<bialix> shelve has support of using external editor to edit hunks
<bialix> I find this very cool
<jml> can I set submit branch for a branch on the command line?
<IslandUsurper> jml, `bzr merge --remember`
<IslandUsurper> or maybe push --remember
<IslandUsurper> no, push branch is different from submit branch
<gustavonarea> Hello, I'm trying to migrate a couple of HG branches to Bazaar, but I'm getting the following error: http://pastebin.com/A6CaLXfM
<gustavonarea> This is how I got there: http://pastebin.com/V5YAV4Yb
<gustavonarea> "cleanup" is a clone of "trunk", and it has ~100 revisions which haven't been merged into trunk
<bialix> do you have shared repository there?
<gustavonarea> bialix: no, I set them up with "bzr init bzr-trunk" and "bzr init bzr-cleanup"
<bialix> then execute following in the parent dir of bzr-trunk: bzr init-repo .
<bialix> then: cd bzr-trunk; bzr reconfigure --use-shared
<bialix> delete bzr-cleanup; bzr init bzr-cleanup
<bialix> then try again last fast-import
<gustavonarea> bialix: will try that
<bialix> bzr fast-import --import-marks=initial-trunk-raw-frontend.marks cleanup.fi bzr-cleanup/
<gustavonarea> bialix: http://pastebin.com/7UTA5WtS
<gustavonarea> maybe i should start it all from scratch, using a shared repo?
<bialix> mmm, you can
<bialix> but it seems there is bug
<gustavonarea> yes
<bialix> gustavonarea: can you try again with fresh shared repo, and don't create bzr-trunk / bzr-cleanup branches manually
<bialix> jam: can you suggest something about this traceback?
<jam> bialix, gustavonarea: other than knowing that there is an open bug on bzr-fastexport wrt "_find_ancestors" I don't really have an answer
<bialix> oops
<gustavonarea> bialix: you mean some thing like "bzr init-repo bzrrepos; cd bzrrepos; bzr init trunk; bzr init cleanup" ?
<bialix> gustavonarea: without last two `bzr init xxx`
<bialix> but as jam said there is open bug
<gustavonarea> bialix: ok, i'll try that
<bialix> maybe you need to downgrade fastimport plugin
<gustavonarea> bialix: that wouldn't be a problem -- what version/revision should I use?
<bialix> the one as in the Karmic
<gustavonarea> ok, i'll downgrade it
<bialix> gustavonarea: ask in the bzr ML as well about fast-import issues. Author of fastimport is igc, he's in the AU timezone
<gustavonarea> bialix: good idea; thanks :)
 * bialix disappears
<maxb> gustavonarea: Have you considered using bzr-hg instead of bzr-fastimport?
<maxb> Also, I know there's a bug in bzr-fastimport concerning marks export/import. I mean to try to fix it at some point.
<gustavonarea> maxb: not really, although there's no special reason, it's just that fast-import seems like the recommended method. I just want to convert all our Mercurial branches to Bazaar once and get rid of Mercurial. Is bzr-hg suitable for this?
<maxb> I believe it is, though, I think it currently lacks support for importing mercurial tags properly. However, this should be trivially fixable afterwards even with a 10 line shell script, as the Bazaar revision-ids assigned are based on the hg hashes with a static prefix
<maxb> So basically you'd just turn the .hgtags file into a series of 'bzr tag' commands using trivial text manipulation
<maxb> One bonus with bzr-hg is that there's no need to manipulate marks files, nor reprocess the common history for every branch
<gustavonarea> i wouldn't mind doing that if everything else works. Do you know of any pointers to start with? I couldn't find documentation in the branch, and http://wiki.bazaar.canonical.com/BzrForeignBranches/Mercurial and http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-hg-projects.html don't offer much information
<maxb> And if you discover an extra hg branch later that was left behind, it will be easy to import
<hazmat> anyone know how to work around a pycurl cert error with bzr-svn .. ala http://gist.github.com/351996
<gustavonarea> maxb: it seems like I can simply do "bzr branch my-hg-branch bzr-branch" -- am I right?
<maxb> Yes, it really should be that simple :-)
<gustavonarea> maxb: whoa, I'll definitely give that a try then! Thank you
<maxb> The tags should be fixable post-import with:  cat .hgtags | while read sha tag; do bzr tag -r revid:hg-v1:$sha $tag; done
<maxb> Anyone: Is 'bzr qlog' totally broken on Lucid at the moment?
<MvG> Investigating qbzr issue from bug #544928 with current bzr.dev, I find BZR_PLUGINS_AT doesn't work for me: within the plugin dir, running ``BZR_PLUGINS_AT="qbzr@$PWD" ../bzr.dev/bzr help'' prints usage instructions and "error: invalid command 'help'". Same for any other command. Did I miss something, or is this a bug in this great new feature?
<ubottu> Launchpad bug 544928 in qbzr "qlog fails with a special combination of PyQt4 and Qt" [Critical,Confirmed] https://launchpad.net/bugs/544928
<MvG> Is there any other way to override a per-site qbzr setup?
<ctrlsoft> jam: hi
<ctrlsoft> hazmat: hi
<hazmat> hi ctrlsoft
<maxb> BZR_PLUGINS_AT?
<hazmat> hi jam, i was curious if you could send your loggerhead cache plans out to the bzr list
<ctrlsoft> hazmat: can you work around that error by using svn+https://
<ctrlsoft> hazmat: pycurl doesn't support self-signed certificates afaik
<jam> morning
<MvG> maxb: Yes, as documented in NEWS, from bug 82693.
<ubottu> Launchpad bug 82693 in bzr "want to run tests in a particular plugin without installing it" [Wishlist,Fix released] https://launchpad.net/bugs/82693
<jam> hazmat: I can. I was hoping that *somebody* would give feedback before I send it to the primary list
<hazmat> ctrlsoft, cool, thanks that did the trick
<ctrlsoft> jam: it looks like the inventory is the most significant slowdown in imports
<ctrlsoft> jam: InventoryDirectory.children in particular
<ctrlsoft> jam: is there anything I should/should not do?
<jam> ctrlsoft: 'most significant slowdown in imports'. Meaning when doing a conversion, the time spent seems to be in ID.children gathering
<jam> my guess...
<jam> any directory with > 200 children is going to page in all of the CHK pages
<jam> to get whatever subset it has
<jam> (one of the side effects of using 255-way hash mapping is that all children end up on random pages.)
<jam> Anyway, what are you doing with ID.children?
<jam> path2id checks?
<jam> id2path checks?
<ctrlsoft> jam: comparing the children between the base inventory and the contents of a new tree in git
<jam> ctrlsoft: you don't get a delta from git?
<ctrlsoft> jam: no, though I'm working on making dulwich produce a delta
<ctrlsoft> by comparing the base tree and new tree in git rather than comparing the base inventory from bazaar and the new tree from git
<ctrlsoft> that seems to have a *significant* impact
<jam> ID.children is known to be pretty bad in chk
<jam> as mentioned above
<jam> essentially, ID.children for a moderately sized directory will load the whole inventory
<ctrlsoft> jam: right, which is pretty bad in this case :-)
<ctrlsoft> I just changed the algorithm in bzr-git and now I can import 3k kernel revisions in 700 seconds
<jam> so, for bzr, the data is sorted by file_id
<jam> so you can generate the delta by file_id much faster than by directory
<jam> If you need to do it by dir, then it is going to probably be slow
<jam> Inventory.iter_changes(other_inv) should be pretty fast for CHK
<ctrlsoft> except I don't yet have other_inv, that's what I'm trying to create :-)
<jam> ctrlsoft: you just have a tree?
<jam> yeah, so the data layout in git is by path, the data layout in bzr is by file_id
<ctrlsoft> anyway, I'll try to eliminate more uses of ID.children - thanks for the hints
<jam> comparing the two is generally going to be O(tree)
<jam> so doing deltas in the same format whenever possible is a good idea :)
<ctrlsoft> yeah, looks like it :-)
<ctrlsoft> jam: so it's faster to do path2id(path) than parent.children.get(name) ?
<jam> should be
<jam> but I'm not positive if we've actually improved it
<jam> it also depends
<jam> if we've already loaded children, then obviously the latter is faster
<ctrlsoft> jam: but if I can avoid ID.children otherwise?
<ctrlsoft> jam: then path2id will be faster?
<jam> So we can answer path2id without having to load the actual inventory objects
<jam> I don't know if we actually *do* yet
<jam> but we have a index specifically on path => id
<bendj> The examples @ 'bzr ignore --help' provide two different options (http://pastebin.com/Taqi035Z) for the same goal ("Ignore .o files under the lib directory").
<bendj> Do those two _really_ do the same thing?
<maxb> One is a glob, the other a regular expression. I would imagine that is what the examples are demonstrating
<TresEquis> Python turns the glob into a regex under the covers for you
<bendj> maxb: ANy hints as to where the use of "RE:" is actually documented?  I'm searching the latest/en/user-reference/... docs, and have yet to find it.
<bendj> ah, nm ... under "Patterns" ...
<ctrlsoft> jam: thanks
<ctrlsoft> jam: removing all ID.children references sped up the imports a lot
<ctrlsoft> jam: the main bottleneck now is add_inventory_by_delta()
<jam> ctrlsoft: my main guess is the inefficiency is that we have do deserialize the old stuff repeatedly, since we get new CHKInventory objects that don't know about the old ones
<ctrlsoft> jam: well, I'm quite happy with the improvements so far
<ctrlsoft> jam: combined with some cache fixes this should bring down the kernel import time from > 4 months to ~5 hours :-)
<jam>  that is fairly significant :)
<idnar> heh
<jardern> Anyone have experience with TortoiseBZR on WinXP64?
#bzr 2010-04-02
<idnar> bzr: ERROR: No module named configobj
<idnar> is there some way to make that more verbose?
<idnar> ah, .bzr.log has a traceback
<lifeless> -Derror
<tct_> hi, bzr started crashing on me today when i tried to commit
<idnar> I guess bzr-fastimport is out of date wrt bzrlib, or something
<tct_> any ideas?  trackback is here: http://pastebin.com/aiUXNkWm
<lifeless> idnar: I think we stopped bundling configobj
<lifeless> idnar: fastimport should be importing the system configobj, if it wants to play with configobj directly.
<idnar> lifeless: yeah, this code tries to do "import bzrlib.util.configobj.configobj as configobj"
<lifeless> yeah, naughty.
<lifeless> tct_: most folk are on leave with easter
<lifeless> tct_: you might file a bug
<tct_> thanks, will do
<idnar> what... the heck is fast-import doing
<idnar> I suppose I should just create the destination myself
<lifeless> poolie: I <3 google - lmirrors pypi page is the first hit for 'lmirror' :>
<poolie> that's pretty quick
<vila> hi all !
<GaryvdM> Hi all
<reyman> hello guys
<GaryvdM> Hello reyman
<reyman> i have question about bzr, and i see anything about that in help  ...
<reyman> i'm working with launchpad, and i want to work in a decentralized workflow
<bialix> hi all
<reyman> i checkout a trunk branch, but when i try to duplicate in a local branch with branch command, bzr says me " trunk is not a branch" :/
<reyman> hi bialix
<bialix> reyman: I don't understand your problem
<bialix> maybe it helps if you pastebin shell session
<bialix> or example of commands
<reyman> i make first a "bzr checkout /myproject/trunk trunk" , a mirror if i understand correctly the help.
<reyman> then i want to work in decentralized workflow, users commit on local branch before mergin with human gate keeper on launchpad
<bialix> checkout is the checkout or bound branch. It's not exactly mirror
<GaryvdM> hi bialix
<bialix> you can convert your checkout to the simple branch with command `bzr unbind`
<bialix> hi GaryvdM !
<reyman> ok
<reyman> about mirror branch the help says : "To create a mirror branch, set-up a shared repository (if you havenât already) and then use the branch (or checkout) command to create the mirror"
<reyman> but why create a checkout branch, if i need to unbind after to duplicate the checkout with branch command
<reyman> it's impossible to make a "bzr branch trunk newTrunk" when trunk is a "checkout mirror"
<bialix> reyman: why it's impossible? it's not true AFAIK
<fullermd> No it's not...
<bialix> hi fullermd !
<AndrewLuecke> ello
<bialix> olle
<fullermd> lole?
<bialix> leol?
<AndrewLuecke> I hate to admit, I've been against Bazaar for a while, but now thinking of setting up a new revision control system.. Been comparing bzr and git.. Bazaar looks nice, but I'm just wondering if there are any updated benchmarks?
 * AndrewLuecke has a 1-2GB repo
 * bialix does not think bzr can beat git on such repo
<AndrewLuecke> Everyone seems to be saying Git is much faster, (and they both seem to have good features, with bzr more polished).. But the other benefits I see for bazaar seem to put it in the running
<AndrewLuecke> Yeah.. but I don't need it to beat all cases, but just not be much slower than SVN..
<fullermd> I doubt it's arguable that git will be faster.  But will git be pleasant, and bzr unpleasant?
<fullermd> Doubt you could say without trying.
<reyman> bialix: so ok it's possible, but i try and i don't understand why i fail with this command :s
<AndrewLuecke> well, been going through the features, addons, etc.
<bialix> reyman: pastebin please
<reyman> oki thx bialix
<bialix> reyman: also I'm not native english speaker it's hard to understand you what's wrong
<GaryvdM> bla - I don have my gpg key here.  going to pop in to work to get it. See you all later.
<reyman> i'm not native english too :] with bad bad bad english
<AndrewLuecke> from your opinions though, does Bazaar feel like it gets really slow?
<bialix> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<bialix> reyman: ^
<fullermd> Well, I've never used it with a 2 gig repo.  There are a lot of variables other than size that have huge effects on speed too.  It depends on shape of history, size and shape of tree, yada yada.
<bialix> AndrewLuecke: if you want to know what is slow, you can try to run benchmarks on Windows
<AndrewLuecke> yeah.. only prob is, I'm in Australia, so quota'ed internet.. Must save downloads.. Not sure I could run a good comparison (maybe a local one I guess, but not sure how useful that would be)
<AndrewLuecke> but anyway, if it was woefully slow, I guess there wouldn't be as many people here, as there are now..
 * AndrewLuecke put up with SVN for this long anyway
<bialix> one of my past coworkers said one day: the result of meterings is highly dependent on the methods of measuring.
<bialix> so mostly all benchmarks lies
<bialix> only your PC and the operations you're interested is make sense
<AndrewLuecke> yeah.. Normally I would stick the tree into both.. But hard to say
<AndrewLuecke> fact is, we don't know yet fully what is needed, because we are forking an open source project
<artagnon> What's the bzr equivalent of git reset --hard <sha1>?
<AndrewLuecke> meh.. fedge it.. maybe I will give them a proper test (technically, the code can be broken into 3 trees anyway, so each would only be 600MB anyway I guess. Most of its mozillas code I guess
<fullermd> artagnon: I believe that would be bzr pull --overwrite -r<abc>
<reyman> pff i delete all my branch, checkout and restart cmd, and it's ok ... duplicate checkout in another local branch is ok.. sorry for inconvenience.
<bialix> most likely bzr pull . --overwrite -r<abc>
<fullermd> Well, yeah.  My brain typed the period; not its fault if my fingers didn't comply   :p
<bialix> reyman: there were gremlins
<artagnon> fullermd && bialix: Got it, thanks :)
<bialix> artagnon: always happy to help
<artagnon> Huh? I just got a huge bunch of conflicts!
<fullermd> Did you have local changes?
<artagnon> Yeah :|
<fullermd> Mmm.  pull may try to merge them.  I can never remember if --overwrite affects that or not.
<fullermd> Well, git reset --hard blows them away too AFAIK, so you can just revert to get back to a pristine rev <abc> WT.
 * artagnon nods
<artagnon> so bzr pull . --overwrite -r<r> isn't the equivalent
<fullermd> Not quite.  pull ; revert (or revert ; pull) would be I guess.
<fullermd> git reset blurs the lines.  In bzr, pull affects the branch, and revert the WT.
<artagnon> ok, got it
<artagnon> what do I do now though? I just want to hard reset to HEAD and try all this
<fullermd> revert with no args will blat a pristine state of the current rev onto your working tree.  After the pull, that 'current rev' will be what you set for there, so just 'revert' should do it.
<artagnon> Ok, nice. Now bzr status indicates a lot of unknown files though- how do I get rid of them?
<fullermd> Mmm.  Probably a construction of bzr ls --someargs | xargs rm
<jszakmeister> artagnon: I haven't tried it before, but 'bzr clean-tree' is probably what you're looking for.
<fullermd> Probably  --unknown -R ?
<lifeless> rm `bzr unknowns`
<fullermd> Oh look, another ls bogusness I find in checking that...   how surprising.
<bialix> `bzr clean-tree` FTW
<reyman> in help there are a chapter "advanced layout", and the speak about the launchpad model, but when you use launchpad to host the code, you doesn't have choice with your layout for repository, no ?
<jszakmeister> Is it sound to pass a URL to bzrlib.config.LocationConfig()?
<artagnon> jszakmeister: works perfectly, Thanks :)
<jszakmeister> artagnon: you're welcome!
<defn> Hi all -- I have a branch, of a branch, of a "master" repository -- This branch is on a server.  How can I create a branch of my remote branch so I can work locally, and then push my commits into my the remote branch
<defn> so right now I have branch-foo -> branch-bar -> master, and i want to have branch-local --|--> branch-foo -> branch-bar -> master
<defn> does that make sense?
<GaryvdM> defn bzr branch server/master
<GaryvdM> defn: you will then have a master branch on your computer
<GaryvdM> defn: I think that it is easier than you are expecting it to be :-)
<defn> GaryvdM: :) thanks
<spirov92> hi people, I'm having problems commiting to a launchpad branch, is launchpad down or something?
<spirov92> ah, yes, it seems so
<defn> GaryvdM: so would it look like:  bzr branch user@remotehost:dir/of/my/branch
<GaryvdM> defn: maybe bzr branch sftp://user@remotehost/dir/of/my/branch
<GaryvdM> defn: how is the branch shared?
<defn> GaryvdM: im not sure im new to bzr
<defn> i have a branch in another user's branch, which is pulled into the master
<GaryvdM> defn: The branch can be shared over ftp, ssh(sftp), http, or anything that you can mount.
<defn> i have a dir with a .bzr/ dir in it, and then i created a branch named v1.0 in the same directory which has its own .bzr directory inside
<defn> that branch was created from the other user's branch
<defn> does any of what im saying make sense?
<defn> :)
<GaryvdM> defn: no, rather don't move the .bzr dirs arround yourself.
<defn> i havent touched the .bzr dirs
<defn> im getting "Not a branch"
<GaryvdM> defn: What are we trying to do again. I thought you were trying to get a branch from a server
<defn> bzr branch bzr+ssh://user@server/dev/repo/v1.0
<defn> GaryvdM: im trying to do local development of that remote branch, like so i can commit locally when im not on the LAN
<defn> and then when i get to work i can commit those changes
<GaryvdM> And what happens when you do bzr branch bzr+ssh://user@server/dev/repo/v1.0 ?
<defn> server does not understand bazaar network protocol 3, ... error: not a branch
<GaryvdM> Who created the branch? maybe they did not?
<lifeless> is bzr installed on the server?
<defn> lifeless: yes but it's an older version i think
<defn> 1.3.1
 * GaryvdM -> lunch
<defn> okay so here is the layout...
<defn> another user on the same remote server created a branch for me in his home directory. on that server i created a branch in my home directory by doing: bzr branch /home/otheruser/dev/repo/branch branch-name
<defn> okay i think i got it
<defn> i guess my next question is, now that i've got a local copy of my branch, how do i commit locally only, so i dont need to have access to the remote server at all times?
<luks> if you downloaded the brach using 'bzr branch', just use 'bzr commit'
<defn> and then how, when im on the lan, do i push those commits to the remote branch?
<defn> push?
<luks> bzr push
<luks> yes
<defn> okay cool
<defn> thanks everyone
<reyman_aw> i don't understand why i have "sproject.dev/trunk" and not "/trunk" when i make bzr checkout "bzr checkout http://bazaar.launchpad.net/~reyman64/sproject/sproject.dev"
<bialix> actually you should have only sproject.dev
<bialix> the last part of URL used by default as the directory name
<reyman_aw> yes i have only a branch sproject.dev in serie trunk
<nomatter001> hi
<reyman_aw> i want to make a human gate keeper flow, with a trunk only available for merge by me
<nomatter001> i have problems with qlog because of that error: https://bugs.launchpad.net/ubuntu/lucid/+source/qbzr/+bug/544928
<ubottu> Ubuntu bug 544928 in qbzr "qlog fails with a special combination of PyQt4 and Qt" [Critical,Confirmed]
<nomatter001> ubottu: exactly that problem, any whay to solve that?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<reyman_aw> ^^
<nomatter001> lol
<bialix> reyman_aw: you may want to push your branch as lp:~reyman64/sproject/trunk
<nomatter001> is there any way known to solve that problem
<bialix> nomatter001: downgrade the PyQt
<nomatter001> bialix: no other way?
<nomatter001> manual patch in pyqt/qbzr?
<bialix> GaryvdM working on this, he's away for lunch now
<reyman_aw> bialix: yes, with no confirmation for me, and restriction review for other push'er
<bialix> reyman_aw: lp:~reyman64/xxx is only writable by you
<bialix> reyman_aw: check this page and read https://code.launchpad.net/~reyman64/sproject/sproject.dev
<reyman_aw> ok thx bialix
<nomatter001> bialix: does it work with pyqt-4.7.0-2?
<bialix> reyman_aw: when I'm looking at your branch I see the following message: "You cannot upload to this branch. Only sebastien.rey  can upload to this branch. "
<bialix> GaryvdM: are you here?
<GaryvdM> nomatter001: Yes
<bialix> Gary the Wizard came to the room
<nomatter001> GaryvdM: ok thx
<reyman_aw> and, so i have sprojet.dev in my repository after checkout, but why there are trunk folder into, don't understand ..if i want to create a fix , i need to branch the sprojet.dev/trunk or sprojet.dev only ?
<bialix> reyman_aw: just advice: use english for the project description
<bialix> or at least english + french
<reyman_aw> ok bialix thx for advice, i translate later ;)
<bialix> reyman_aw: are you using Bazaar Explorer?
<reyman_aw> no
<reyman_aw> command line for understand :)
<reyman_aw> (try to understand ...)
<bialix> wait a sec, I'll try to reproduce
<bialix> bzr 2.1?
<reyman_aw> yes bialix
<reyman_aw> latest bzr on windows
<bialix> okay
<bialix> the same here
<bialix> reyman_aw: you have trunk directory in your branch
<reyman_aw> hum :/
<bialix> the sproject.dev is the checkout root
<bialix> do following:
<bialix> cd trunk; bzr mv * ../
<bialix> cd ..
<bialix> bzr rm trunk
<bialix> bzr commit
<reyman_aw> ok so i make noob mistake in my manipulation when i create a trunk folder , arg
<reyman_aw> thx a lot bialix, it's clear now :]
<reyman_aw> sorry for this noob inconvenience
<bialix> no problem
<bialix> reyman_aw: remember: bzr info is your friend when you lost in the bzr forest
<reyman_aw> ok thx for advice :)
<bialix> `bzr info` tells you what bzr object you have and where its root
<reyman_aw> i see yes
<bialix> reyman_aw: you can try Bazaar Explorer
<bialix> it provides some hints
<reyman_aw> ok
<bialix> back to your question about workflow
<bialix> you'd better create shared repo for local work
<bialix> bzr init-repo sproject
<bialix> cd sproject
<reyman_aw> i create a shared repo yes
<bialix> bzr checkout lp:sproject trunk
<bialix> the last command will create local checkout of your lp branch
<bialix> then if you need to create new feature branch you do: bzr branch trunk xxx
<reyman_aw> ok
<bialix> to merge your branch back to trunk do: cd trunk; bzr merge ../xxx
<reyman_aw> ok
<bialix> after merge you need to check the result, resolve conflict if needed, and commit
<reyman_aw> and if i want to propose merge on initial checkout trunk
<reyman_aw> i make this with launchpad interface?
<bialix> what it means?
<bialix> if you want to create merge proposal?
<bialix> or somebody else?
<reyman_aw> only ~reyman64 have the access of initial trunk, but if other want to create feature and want to merge,
<reyman_aw> yes bialix exactly
<bialix> usually to create merge proposal one have to push his branch to lp
<bialix> then do: bzr lp-open
<bialix> the latter command will open the branch page, like https://code.launchpad.net/~reyman64/sproject/sproject.dev
<bialix> there will be a button to create merge proposal
<bialix> and ~reyman64 will receive the mail about merge proposal
<reyman_aw> ok :]
<reyman_aw> perfect !
<bialix> then to merge the branch from lp you need to cd to shared repo sproject
<bialix> then: bzr branch lp:other-branch
<bialix> cd trunk
<bialix> bzr merge ../other-branch
<bialix> and commit as usual
<reyman_aw> bialix: thx a lot for this tutorial, there are no real tutorial for decentralized workflow :/
<reyman_aw> on launchpad
<bialix> reaaly?
<bialix> there is tutorials on Bazaar site
<bialix> reyman_aw: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/index.html
<reyman_aw> yes but, not really for launchpad, so i don't understand the layout branch for launchpad
<bialix> http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/using_bazaar_with_launchpad.html
<bialix> ask your questions, give us feedback
<bialix> send proposals to ML how the docs should be improved
<bialix> there was nice tutorial on arstechnica
<bialix> anybody has the link to that article?
<reyman_aw> ok ! i search on arstechnica
<reyman_aw> i have this review http://arstechnica.com/business/news/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars
<bialix> yes, that's it
<bialix> reyman_aw: what do you mean by "the layout branch for launchpad"?
<reyman_aw> bialix: in help there are a chapter " advanced layout"
<bialix> link please
<reyman_aw> ah the end :
<reyman_aw> http://doc.bazaar.canonical.com/latest/en/user-guide/shared_repository_layouts.html
<reyman_aw> -h+t
<reyman_aw> layout " Simple developer naming (project/joe/foo, project/barry/bar) "
<reyman_aw> this is not very clear for newbies
<reyman_aw> like me :)
<AndrewLuecke> Btw, has anyone tested both HTTPS and ssh, which was faster?
<AndrewLuecke> Actually, nevermind, I'll just use SSH
<bialix> bzr+ssh
<bialix> reyman_aw: yep, there is the picture of tree of folders
<bialix> reyman_aw: I think you don't need advanced things while you're newbie
<bialix> reyman_aw: in short about lp: it uses the simple naming scheme: lp:~USER/PROJECT/BRANCH
<reyman_aw> now i understand that the folder tree is a snapshoot of the launchpad ,no ?
<bialix> I'd say that doc should be improved
 * vila is stunned by bialix explanations, who needs doc after that ?
<reyman_aw> bazaar have a great doc, and bialix help a lot ! Perhaps a tutorial on "how participate" on real launchpad project for dub :p
<reyman_aw> make things more clear
<vila> reyman_aw: patches welcome ! :)
<reyman_aw> eheh
<AndrewLuecke> I'm correct in believing bzr_access only allows r/rw/nothing right? Not anything special thats per directory (unless I create many users).. That is correct right?
<vila> reyman_aw: I'm only half-joking here, at this instant, *you* have the clearer idea about what is missing...
<AndrewLuecke> nevermind.. doesn't matter anyway :P
<vila> AndrewLuecke: roughly yes, there was some discussion about going further but I can't remember it if was 1) with bzr-access, 2) with another script, 3) only discussed
<reyman_aw> yes, i'm pionner in my entreprise, so i probably make a tutorial for the other later :]
<vila> reyman_aw: keep notes !
<reyman_aw> and why not for communities
<AndrewLuecke> I think I heard somewhere vila, there is was ACL's, is that what you are refering to?
<vila> AndrewLuecke: not ACL as the OS ones, but yes, something about allowing more fine-grained control at branch level
<AndrewLuecke> ok
<vila> AndrewLuecke: but nothing *below* the branch level in case that's what you're after
<bialix> vila: the bug for 1st april: https://bugs.launchpad.net/bzr/+bug/553955 (unfortunately today is 2nd)
<ubottu> Ubuntu bug 553955 in bzr "bzr 2.1: commit incorrectly reports missing files as modified" [Undecided,New]
<AndrewLuecke> nah.. It was more of a theoretical.. But I guess it doesn't matter, as I'll only probably have 1 primary repository anyway I guess
<reyman_aw> i have a problem bialix, i delete the false trunk in my sproject.dev, make commit, but i have BZR ERROR: cannot lock dir : transport operation no possible : http does not support mkdir() ( ?? )
<vila> AndrewLuecke: I'm 80% sure someone has a working solution, I just can't remember the details (Alzheimer, etc)
<bialix> reyman_aw: because you did checkout from http branch, which is read-only
<reyman_aw> hmm
<AndrewLuecke> ok vila.. It will probably pop up anyway
<bialix> reyman_aw: do the following: bzr switch lp:xxx (where xxx is your lp branch)
<reyman_aw> ok
 * AndrewLuecke is still wrestling with debian anyway
<vila> bialix: naah, you can't delete foo.txt, that's not allowed
<bialix> AndrewLuecke, vila: there is ClueBzrServer project which I'm still planning to try out
<reyman_aw> thx bialix it's ok :)
<bialix> vila: seriously? %-)
<AndrewLuecke> cool
<vila> bialix: no :) 'bzr remove foo.txt' is so engrained in mind that I cannot encounter such a bug, checking
<bialix> phew
 * bialix used Windows Explorer, but don't say anybody
 * AndrewLuecke debates switching his server to ubuntu again
<vila> bialix: feel free to mark such bugs as confirmed and set an importance (I just did)
 * vila needs to reboot bbiab
<bialix> vila, come back
<GaryvdM> Bug 544928 Fixed.
<ubottu> Launchpad bug 544928 in qbzr "qlog fails with a special combination of PyQt4 and Qt" [Critical,Confirmed] https://launchpad.net/bugs/544928
<GaryvdM> bialix: Because it affects so many people, I'm going to release 0.18.5 now. That ok?
<bialix> GaryvdM: sure, please also put in the release my fix for backslashes
<GaryvdM> Yes
<bialix> GaryvdM: congratulations on the bug fix!
<bialix> I've planned to do 0.18.5 anyway tomorrow
<bialix> GaryvdM: you can leave it for me
 * GaryvdM grumbles about qt....
 * bialix grumbles about all new versions of all software
<GaryvdM> I'm developing a love hate relationship with qt.
<bialix> (excluding qbzr of course)
<bialix> or PyQT?
<vila> jam ?
<GaryvdM> vila: I'm loving BZR_PLUGINS_AT
<vila> GaryvdM: I'm glad you like it, but I wonder how you avoided bug #552922 though....
<ubottu> Launchpad bug 552922 in bzr "BZR_PLUGINS_AT can be fooled by os.listdir order" [Critical,In progress] https://launchpad.net/bugs/552922
<vila> GaryvdM: fix available at https://code.edge.launchpad.net/~vila/bzr/552922-plugins-at/+merge/22697
<bialix> wow, nice feature
<GaryvdM> vila: I don't know
<AndrewLuecke> woot.. I am such a fool.. Nobody cares, but its hard to explain the satisfaction you get when ssh actually authenticates properly
<vila> AndrewLuecke: You're not alone :-)
<vila> AndrewLuecke: about the satisfaction that is...
<vila> AndrewLuecke: nah kidding, I'm so a fool too :-P
<AndrewLuecke> serves me right for using 2 different texts to set up ssh (one told me that my home dir should be my repo, and I forgot I did that so clearly, authenticated keys wouldn't work)
<AndrewLuecke> ooh.. Import time.. Time to see how fast I can import from songbird's svn to prgmr
<vila> AndrewLuecke: 'ssh -v' is your friend too
<AndrewLuecke> it was a server side issue.. I thought I did the authorised keys thing wrong.. So dumb as I was.. I figured if I redid the same thing 5 times it would work..
<vila> AndrewLuecke: good policy, served me right for the last 20 years, I use 2 instead of 5 though :-D
 * vila kills more chicken
<AndrewLuecke> Speaking of chicken.. If I'm not here tomorrow, its because the chicken in the fridge I purchased 2 or 3 days ago wasn't safe anymore
<vila> tsk tsk, always sacrifice *live* chicken so you're sure they are fresh when you eat them...
 * AndrewLuecke needs to find out how big the SVN tree is his importing, he suspects it wont fit on his VPS
<AndrewLuecke> Nah.. no need
<AndrewLuecke> Danger is my middle name...
<AndrewLuecke> btw.. there is a broken link on: http://doc.bazaar.canonical.com/bzr.2.1/en/admin-guide/migration.html#subversion-conversion
<AndrewLuecke> it points to http://doc.bazaar-vcs.org/en/migration/foreign/bzr-on-svn-projects.html
<AndrewLuecke> which isn't found..
<vila> AndrewLuecke: please file a bug on lp
<AndrewLuecke> I assume we don't have access to edit that
<AndrewLuecke> How do I file a bug?
 * AndrewLuecke is joking...
<vila> AndrewLuecke: the admin-guide is part of the sources, so you can even provide a fix if you know the right url :)
<vila> doc/en/admin-guide/migration.txt
<AndrewLuecke> not sure yet.. Anyway.. priority #1 is to start tearing the SVN to pieces (because that might take a day or so)
<vila> sure, I'm just trying to help you find something to do while waiting for the import :-D
<AndrewLuecke> Haven't started the import yet.. I'm concerned about waking up tomorrow and finding my VPS full.. Trying to find out how big it is first..
<NfNitLoop> Hrmm, I remember there being some caveats in the difference between lightweight/heavyweight checkouts that don't seem to be mentioned on http://wiki.bazaar-vcs.org/CheckoutTutorial
 * AndrewLuecke wonders when google wave got proper extensions
<NfNitLoop> and I vaguely remember things like "rebase" sortof ... break in a heavyweight checkout.
<NfNitLoop> AndrewLuecke: "proper" extensions?   It's had extensions from the start.
<AndrewLuecke> yeah.. but now, it actually has some in the list.. not only 2 or 3 (lots of em)
<bialix> vila: can you help? It seems I found rather serious bug in bzrlib
<vila> April 2th, really 2th !
<vila> bialix: don't ask to ask :-)
<bialix> oh, it seems I understand
<bialix> bug about relative path to the master of light checkout
<bialix> rats
<bialix> it kills mew
<bialix> me
<vila> I think someone reported a bug about that recently or at least mentioned it on the ML or here
<bialix> I can work with light checkout at all if it uses absolute path to another windows drive!!!
<GaryvdM> bialix: Have you noticed a difference in qbzr startup time?
<GaryvdM> bialix: Have you noticed a difference in qbzr startup time?
<bialix> no, I havent
<bialix> o I havent
<vila> GaryvdM: it's twice as slow ?
<vila> GaryvdM: it's twice as slow ?
<bialix> no, I havent
<GaryvdM> :-( Sorry about the dup, I push up+enter, the wrong window had focus :-)
<bialix> we're joking
<bialix> relax
<GaryvdM> :-)
<bialix> :-)
<vila> :-)
<GaryvdM> no difference though?
 * bialix just hits the wall with relative paths
<bialix> GaryvdM: in which branch/revno?
<vila> bialix: I thought poolie may have landed a related patch recently but I can't find it....
<bialix> vila: I'm not sure
<vila> bialix: anyway if things have changed and broke your workflow, raise a bug
<GaryvdM> bialix: in trunk since rev 1229 (2010/03/25)
<bialix> vila: things are not changed I belivev, I've just found another use case when absolute paths are show stopper for me
<bialix> GaryvdM: oh, I'm often working/dogfooding with 0.18
<vila> bialix: haaa, then I may be I've got everything backwards and the discussion was about using relpaths instead
<bialix> GaryvdM: but no, I don't think I've noticed any highly visible improvements
<bialix> GaryvdM: do you have benchmarks?
<bialix> vila: relative paths will helps
<bialix> GaryvdM: when you'll finish with 0.18.5 can you look at my question in qbzr ML about qlog+colo?
<bialix> please
<GaryvdM> Sure, I have a half finished draft
<GaryvdM> Such a change will need quite a bit of plumbing work in qlog...
<ctrlsoft> bialix: did you see my reply?
<bialix> jelmer, is it you?
<bialix> ctrlsoft: no, I don't
<bialix> reply for what?
<ctrlsoft> bialix: your email about colo support in qlog
<ctrlsoft> s/qlog/qbzr
<bialix> ctrlsoft: no, is it recent?
<ctrlsoft> bialix: a couple of days ago I think
<bialix> I've sent my question just yesterday
<bialix> I don't see any your mails, ctrlsoft
<GaryvdM> ctrlsoft: can't see it either. Maybe got filtered by google groups spam filter.
<ctrlsoft> hmm :-(
<ctrlsoft> bialix: to summarize it; bzr 2.2 has support for colocated branches in its API
<bialix> I have to admit that google groups became worse in last weeks
<ctrlsoft> bialix: it would be nice if qbzr and bzr-colo supported that, that would also give you support for colocated branches in git repositories
<bialix> ctrlsoft: that sounds great
<bialix> can you CC your mail to bzr ML, please?
<bialix> ctrlsoft: you have joined to qbzr ML with your samba mail
<bialix> your mail have to arrive, I believe
<GaryvdM> bialix: For inno setup, should I us the unicode, or non unicode version? Does it make a difference to the output?
<GaryvdM> *use
<bialix> GaryvdM: currently I'm using 5.3.3 which is pre-unicode IIRC
 * bialix is just lazy to upgrade
<bialix> in short: I dunno
<GaryvdM> OK
<bialix> vila: is it new thing that push to another drive letter don't create working tree?
<vila> meh, I don't think so, are you sure you're not pushing into a --no-trees repo ?
 * bialix checks
<bialix> vila: info -v says: Create working tree for new branches inside the repository.
<vila> bialix: no idea then, but I don't recall any change in this area either
<bialix> okay, time for bug report
<bialix> hmmm, can't reproduce
<bialix> with simple branch I can't reproduce
<vila> bialix: kill more chicken
<bialix> what's that?
<vila> bialix: black magic against the gremlins
<bialix> oh, cool
 * bialix notes
<bialix> level-up!
<vila> :-)
<bialix> OIC, I'm pushing from colo workspace, which uses treeless branches and light co
 * GaryvdM checks if he is in the right channel....
<GaryvdM> bialix: oh - thats how bzr qlog sees the colo branches...
<bialix> GaryvdM: bzr qlog colo: ?
<GaryvdM> yeah
<bialix> vila: yes, I can reproduce
<GaryvdM> bialix: fyi: I get an error with the unicode version of inno. It went away when I installed the non unicode version...
<bialix> GaryvdM: ok, thanks for the info
<bialix> perhaps wine issue?
<GaryvdM> maybe wine related...
<GaryvdM> yes
<GaryvdM> http://pastebin.org/131345
<GaryvdM> btw - it rocks that I can now build the windows installer on ubuntu.
<bialix> strange
<bialix> indeed, rocks
<bialix> wine is cool
<vila> GaryvdM: you should 1) backup your HD, 2) wipe it clean 3) insall Ubuntu, 4) install a windows VM :)
<vila> bialix: you too :-P
<bialix> vila: :-P
<bialix> and who will report about windows bugs then?
<vila> bialix: you can still use windows in the VM :-)
<GaryvdM> vila: The problem is that I have allsorts of windows apps that I'm not sure If I have instalers for.
<vila> bialix: Some addictions just can't be cured
 * bialix prouds to be addicted
<vila> :)
<GaryvdM> vila: It would be cool if I could boot my existing windows installation in a vm...
<vila> GaryvdM: That will be a good occasion to cleanup :)
<bialix> I'm using windows also because there is a lot of PC games for my daughter
<bialix> (and sometimes for me)
<vila> GaryvdM: I've never done it, but I think it can be done
<GaryvdM> vila: I pritty much weened of it now. The last real thing that I need is to be able to run classic asp on linux.
<reyman_aw> bye all, and thx for the advice !
<GaryvdM> For maintenance.
 * bialix waves
<reyman_aw> exit
<vila> GaryvdM: just checked, VirtualBox can use raw host hard disk from a guest, either an entire physical hard disks or selected partitions
<GaryvdM> Oh cool - I'll try that...
<vila> GaryvdM: but if I had to try that, I'd make sure to have backups, just in case something weird happen like windows suddenly thinking that it's running on a new hardware because the video card is not the same anymore or something like that
<vila> GaryvdM: this is from chater 9.5 Advanced storage configuration in the vbox doc by the way
<GaryvdM> qbzr 0.18.5 code name Silver terminalia
<bialix> nice!
<vila> bialix, GaryvdM : Can you run python -c 'import paramiko; print paramiko.__version__' and tell me which version is shipped with bzr ?
<bialix> vila: no
<vila> hehe
<bialix> it's not easy with py2exe
<bialix> wait a minute
<bialix> vila: it seems 1.7.6 (Fanny)
<vila> bialix: cool, thanks
 * bialix was lazy to install depends plugin
<GaryvdM> vila: 1.7.6 (Fanny) (on lucid)
 * bialix eods
<bialix> bye all
<GaryvdM> bialix:
<vila> GaryvdM: yeah, I know, babune reports a test failing on lucid and so far I've got 1.7.4 passing on karmic and 1.7.6 failing on lucid, but maybe it's pycrypto instead
<vila> bignose: enjoy your week-end !!
<vila> too late :-/
<vila> and wrong nick :-(
<vila> sorry bignose that was for bialix
<vila> jam: ping, I seem to remember you mentioned something about paramiko/pycrypto on windows but I can't remember the details
<jam> hi
<vila> jam: something about either patching one package or the other or going with a workaround
<vila> yeah ! jam is here ! Good morning !
<jam> so paramiko uses a RandomPool from pycrypto IIRC
<jam> and
<vila> yeah, along these lines
<jam> 1) With older pycrypto and MS < Windows
<jam> it loops around time.clock() 100 times, with 15ms granularity (taking 1.5s to start)
<jam> 2) With MS Vista at least (sorry time.time()) granularity goes to 1ms
<jam> so it is only 100ms to start
<jam> 3) We can patch pycrypto to use time.clock()
<jam> 4) Newer pycrypto doesn't have the bug, but has completely deprecated RandomPool
<vila> right, but during the discussion I think it was mentioned another point about some, yeah that
<jam> so raises a warning that paramiko is using it
<jam> 5) So we have to patch paramiko to work around *that*
<jam> So at the moment, we stick with older pycrypto and patch it
<jam> We could upgrade to newer pycrypto and patch paramiko somehow
<vila> right, so across all our platforms, freebsd, gentoo and now lucid are failing because paramiko use RandomPool
<vila> (not 100% sure for lucid, but gentoo and freebsd now says: PID check failed. RNG must be re-initialized after fork(). Hint: Try Random.atfork()
<vila> with a traceback from crypto to paramiko
<vila> jam: ok, so patching paramiko seems to be the only viable alternative there, I'm EODing, but I'll file a bug first thing when I came back
<vila> bye all, have a nice week-end !
<vila> jam: just one last thing, when/where do we *require* paramiko ?
<jam> we have to have it for sftp support
<AndrewLuecke> night
<AndrewLuecke> and thanks
<jam> we *can* use it as an ssh agent instead of openssh
<jam> so bzr+ssh shouldn't require paramiko if you have openssh
<vila> jam: right, thanks for confirming
<psynaptic> hey guys
<psynaptic> is there a way to display just *my* commits
<psynaptic> I'm expected to provide a log of my work each day and it would be ideal if I could run something like bzr log -u email@example.com
<lifeless> bzr log -m email@example\\.com
<psynaptic> lifeless: doesn't seem to work on this server. is there a special requirement?
 * psynaptic pasted http://pastie.textmate.org/private/gepmld86ygjflga6qro3a
<psynaptic> this is what I tried
<lifeless> uhm, it might not search author/committer; file a wishlist bug
<psynaptic> ok, thank you
<lifeless> vila: ping
<bac> lifeless: can you tell me how to get a diff of the changes since a given revision MINUS the changes merged in from trunk?
<lifeless> uhm
<lifeless> make a temp branch
<lifeless> of that rev
<bac> yep
<lifeless> merge trunk to it
<lifeless> make a temp branch of tip
<lifeless> merge trunk to that
<lifeless> diff --old first-temp --new second-temp
<bac> i'd tried *most* of that.  let me try.  thanks
<lifeless> (this feeds into why looms and pipelines have things merged together)
<magcius> I'm having problems when pulling from a repo.
<magcius> bzr: ERROR: KnitPackRepository('local-repo') is not compatible with CHKInventoryRepository('lp-repo')
<magcius> different rich-root support
<ctrlsoft> magcius: the remote repository has more information than the local one, so the revisions can't be losslessly stored locally
<ctrlsoft> magcius: you might want to upgrade to a newer repository format
<ctrlsoft> ("bzr upgrade")
<magcius> ctrlsoft: um
<magcius> ctrlsoft: you should have a better error message, or do that automatically
<magcius> ctrlsoft: because it was an older version before, so when I try to pull it should try to upgrade
<ctrlsoft> magcius: I agree a better error message would indeed be a good idea, I think there's an open bug about that.
<ctrlsoft> magcius: we don't want to upgrade automatically because it will make the repository unreadable by older versions of bazaar
<vila> lifeless: pong
<lifeless> hai
<lifeless> bzrlib's HTTP transport
<lifeless> is it threadsafe?
<lifeless> and if I were to do a 'get' on it, does it buffer the full response still ?
<lifeless> vila: ^
<vila> hmm, I can't think of any part that shouldn't.
<lifeless> vila: persistent connection cache ?
<vila> pycurl buffers, urllib doesn't
<vila> the connection  is shared between the transports that use it, there is no global cache
<vila> lifeless: the only weak point is when the server and the client are in the same process but I don't think you care about that
<vila> and even there it's more a python bug than unsafe thread code
<vila> lifeless: when you do a get, the urllib transport try to make all reads goes to the socket without buffering (at least for the data, headers are a different story but again you should not care about that)
<magcius> can someone explain this though? "We identify revisions using sequential numbers per branch, not per repository."
<magcius> I thought branch was synonymous with repository?
<mkanat> magcius: bzr help init-repo
<luks> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<magcius> can bzr revision numbers theoretically get to 1.6.12.46.76.1.6.78/123 and so on?
<magcius> s:/:.:
<luks> seriously, read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs
<luks> short answer, no, they can't
<vila> magcius: no, they are either 123 or 123.456.789 i.e. one or three numbers
<magcius> wait, what?
<magcius> sorry, I'm a bzr noobie
<vila> magcius: yeah, luks gave you a very good url for that
<lifeless> vila: right, I don't care about that
<lifeless> vila: is there control over cache-control yet ?
<RumblePure> got an older revision, since that revision I have removed and created new files. How to restore the older revision?
<vila> lifeless: no, we explicitly disable the caching unconditionaly
<luks> RumblePure: bzr revert -r X path/to/file
<luks> if I understand correctly that you want to undelete a file
<lifeless> vila: yeah, I thought so
<lifeless> vila: is it at least in a function I could override ?
<vila> lifeless: see -urlib2_wrappers.AbstractHTTPHandler._default_headers
<magcius> How are the pieces stored on the disk? Is it pickle or something?
<luks> which pieces?
<parthm> hello all. i was looking at bug #518609
<ubottu> Launchpad bug 518609 in bzr "Unicode exception occurs by "version-info"" [Medium,Confirmed] https://launchpad.net/bugs/518609
<lifeless> vila: bug 120697
<magcius> luks: the files, the commit metadata
<ubottu> Launchpad bug 120697 in bzr "want a way to mark transport operations as cacheable" [Medium,Confirmed] https://launchpad.net/bugs/120697
<vila> lifeless: overriding AbstractHTTPHandler.http_request should be a good starting point
<parthm> it seems that the exception occurs due to log.add('message', message) in format_rio.py but message is already unicode
<parthm> http://pastebin.com/XP5VfTJt
<lifeless> hth debbian things its fixed, I dunno
<parthm> any ideas what the problem might be?
<luks> magcius: there are various repository and branch formats in bzr
<lifeless> parthm: it shouldn't be unicode
<RumblePure> luks: simple enough. thx for your help. :)
<vila> lifeless: yes I remember this bug
<magcius> luks: is there any documentation on them, if I wanted to, say, implement a bzr web viewer in PHP or Perl?
<luks> magcius: only the source code, I'm afraid
<vila> lifeless: especially comment #9 :)
<luks> but reading them directly is not going to be easy
<parthm> lifeless: oh. so does bzr store message as regular 8-bit strings?
<parthm> byte strings
<magcius> luks: ouch
<lifeless> magcius: bzr, like all VCS's, is a database.
<luks> magcius: bzr is more a vcs framework than a simple application :)
<lifeless> magcius: would you write a viewer for Postgresql or MySQL databases in PHP/Perl ?
<magcius> lifeless: it's been done
<luks> the interface (both user and API) was always more important than the file formats
<lifeless> magcius: well, its that order of complexity.
<lifeless> you need to implement the B+Tree index logic, groupcompress compression engine, pack file format, to have any hope
<lifeless> and then on top of that you can start implementing user visible things.
<lifeless> those three things are well documetned, in pydoc.
<luks> and hope bzr will not change it's default format in the next version :)
<magcius> lifeless: do you have a library written in something like C that I can get bindings to?
<lifeless> luks: that doesn't really matter, a given website can stay on any format it wants indefinitely.
<lifeless> magcius: you can call python from C; so our existing Python code is accessible from C.
<magcius> lifeless: um
<lifeless> and bzr is structured very cleanly as front-end and library.
<luks> lifeless: I assume if somebody invests time in writing a reader for the 2a format, they want to actively use it
<lifeless> there is also bzr-xmloutput, xml bindings for most commands.
<luks> and bzr doesn't tend to support old formats indefinitely
<parthm> magcius: loggerhead is a bzr web viewer written in python https://launchpad.net/loggerhead
<lifeless> luks: we still support the very earliest alpha formats
<magcius> parthm: yes, I've used loggerhead and seen it break thousands of time
<luks> lifeless: usually only for conversion
<lifeless> luks: its only the absolutely oldest ones (that couldn't even do networking or merge) that are readonly
<luks> you wouldn't want to use them
<lifeless> luks: !citation time, you're making FUD
<vila> magcius: bug reports and patches welcome :)
<luks> lifeless: :)
<luks> a little too serious? :)
<magcius> vila: I made a feature request a while ago: indentation lines or a left margin, it's awful reading Python code in Loggerhead because I can't tell where global scope is
<vila> luks: he's right, the test suite guarantees that and fully pass for every commit on mainline...
<magcius> vila: second, fix your URLs, I don't want to see %2F or whatever : is in my URLs. Third, I don't like how you have different URLs for reading files or trees. I should be able to change the URL to delete the filename and make it work.
<luks> vila: yes, I know they are fully working
<luks> vila: but they are inneficient
<vila> magcius: I didn't write loggerhead
<lifeless> luks: magcius have you filed a bug for that ?
<lifeless> sorry
<lifeless> magcius: have you filed a bug for that?
<luks> vila: and they get more inneficient as new formats get developed
<magcius> lifeless: I was told that both bugs already existed earlier
<vila> luks: well I surely the newer formats are more efficient
<lifeless> luks: they shouldn't be more inefficient than their intrinsic capabilities
<parthm> lifeless: you are right `log.add('message', message.encode('ascii', 'ignore'))` fixes the issue. but is this the right place to convert the message to ascii? or do i need to find out why the message is becoming unicode in the first place?
<lifeless> luks: we have removed unsafe optimisations that we used as a stopgap while preparing better formats
<vila> magcius: I don't clearly see how reading the low-level bzr data will help you there ?
<luks> vila: knits were getting alower along with packs development, the original packs were getting slower along with ...
<lifeless> parthm: I have no idea what you're doing, so I can't really answer that.
<lifeless> parthm: perhaps mail the list ?
<luks> vila: anyway, I never wanted to argue about this :)
<lifeless> parthm: unless vila has time to dig into this - I don't right now,s orry.
<luks> I only said that this would be a reason for me to not implement bzr's internal file formats
<vila> luks: I won't deny that but I won't say that the degradation were more important than the optimizations either
<parthm> lifeless: i will do that. thanks for the pointer on message being ascii.
<vila> luks: that's for sure :-)
<parthm> lifeless: mailing list is probably good :)
<lifeless> vila: so - http://launchpadlibrarian.net/10490569/120697.patch
<vila> lifeless: yup, still valid (still not usable as is but in essence that's what controls the caching)
 * vila giggles at the # Begin bundle, long time not seen :)
<lifeless> vila: I've suggested an API
<vila> lifeless: I'll happily review any patch you can come with :-P
<vila> lifeless: but roughly, caching packs/* and indices/* should cover at least 90% of the possible gains no ?
<lifeless> vila: yes
<lifeless> I don't plan to do that
<lifeless> I want caching in another project, dealing with large data sets
#bzr 2010-04-03
<johnf> Using fetch logic to copy between CHKInventoryRepository('file:///home/johnf/dev/packaging/bzr/ppa/.bzr/repository/')(<RepositoryFormat2a>) and CHKInventoryRepository('file:///home/johnf/dev/packaging/bzr/bzr_2.1.1-1/.bzr/repository/')(<RepositoryFormat2a>)
<johnf> Should that normally take ages and peg my CPU at 100%?
<johnf> console has - "Fetching revisions:Get stream source"
<lifeless> should take a couple minutes
<lifeless> if you don't have the X extensions it could take longer
<johnf> Does take 2 minutes
<johnf> autoppa and builddeb seem to be doing it. Never used to take this long
<johnf> maybe my extensions are missing
<johnf> nope I've got them
<lifeless> there isn't really a good reason to have two repositories there
<lifeless> bzr init-repo /home/johnf/dev/packaging/bzr
<johnf> Ahh I think I broke that at some stage
<johnf> do I need to recheck everything else out or does "magic" happen?
<lifeless> reconfigure --use-shared-repo or something like that
<johnf> thanks
<lifeless> otoh fetching a single rev should be near-instant
<johnf> lifeless: much better! Thanks
<offby1> I just tried to download bzr-explorer, by adding http://ppa.launchpad.net/bzr/ubuntu to /etc/apt/sources.list, and installing via aptitude.  But aptitude is refusing to install it: after downloading it, it complains that it's the wrong size.  Any hints for how to proceed?
<wgrant> offby1: You are probably behind a (perhaps transparent) proxy that is caching badly.
<offby1> not that I know of
<offby1> plain old DSL at home
<wgrant> offby1: What is the exact error message?
<offby1> hold on
<offby1> Weird, I can't select the text ...
<offby1> E: failed to fetch blahblahblah.deb: Size mismatch
<offby1> that shows up in a red "dialog box" in aptitude.
<offby1> I'll try the command line
<offby1> E: Failed to fetch http://ppa.launchpad.net/bzr-explorer-dev/ppa/ubuntu/pool/main/b/bzr-explorer/bzr-explorer_1.0.0final-0~bazaar1~karmic1_all.deb: Size mismatch
<offby1> I downloaded it by hand with "curl -O", and installed with "dpkg -i".  Let's see if I vanish in a puff of smoke ...
 * wgrant checks consistency.
<offby1> seems to work
<wgrant> offby1: The indices
<offby1> ?
<wgrant> ... match on disk.
<offby1> dunno what you're talking about, actually.
<wgrant> So it's probably a transparent proxy on your Internet connection.
<offby1> oh
<wgrant> Because the archive on ppa.launchpad.net is internally consistent.
<offby1> ok
<offby1> lemme md5sum the .deb; you tell me if it matches what you see
<lifeless> what is your ISP
<offby1> blarg.net
<offby1> 0b9dfdd8673dabb6e7cf8093b595df78
<wgrant> bzr-explorer_1.0.0final-0~bazaar1~karmic1_all.deb
<wgrant> Should be:
<wgrant> 61266149140843c5bfe91d91309cc24e
<offby1> uh oh
<wgrant> My copy of it matches that.
<wgrant> And the indices say that.
<wgrant> So your copy is somehow bad.
<offby1> crap
<offby1> dpkg --purge
<offby1> poo
<wgrant> Which means that it's not just normal bad caching; it's actually holding a corrupted copy of the file.
<offby1> well, thanks for checking.
<offby1> I wonder if there's some way I can identify the proxy
<lifeless> you can sometimes trace it using various 'whats my ip' style cgi scripts
<lifeless> or checking the returned headers of an http query
<offby1> aha
<offby1> headers sound interesting
<SamB_XP> yay firebug!
<Infl8ableSoulm8> Just recently was pointed towards the possibility of using bzr and was wondering if it would fit my use case...
<Infl8ableSoulm8> I'm in charge of updating configs, plugins, and plugin source code for 9 or so game servers (valve's srcds)
<Infl8ableSoulm8> 8 of them run on one windows box, and on of them runs on a linux box in a different location.
<lifeless> sure
<lifeless> it should handle that just fine
<Infl8ableSoulm8> there are three developers (myself included) and at least two other people who would be modifying the configs or source code for the plugins.
<Infl8ableSoulm8> and there would also be binary externsions for the plugin mod that we use
<Infl8ableSoulm8> basically, reading about bzr it looks like commits are sort of localish, but somehow there is a main branch?
<Infl8ableSoulm8> also, I have never really had any reason to use any sort of vcs before, so I'm basically stumbling around int he dark.
<Infl8ableSoulm8> I have a subversion repository<?> set up ont he linux box, but it's just a single project with everything in it.
<Infl8ableSoulm8> it would be much nicer to have a different project for each server
<Infl8ableSoulm8> but svn is way over my head.
<fullermd> Commits in bzr go onto whatever the branch in question is (which usually the local one)
<fullermd> Once made, you can copy the revisions out to any other related branch, in arbitrary topologies (a star with one 'central' branch and a lot of outlying branches is probably the most common, but not the only possible)
<Infl8ableSoulm8> so, say you have a few people who are collaborating on one source file for a plugin, does one person change something, commit, then another person update their local branch to further extend the work?
<Infl8ableSoulm8> and if so, where is the central branch located if there is no centralized server?
<fullermd> Well, there are a number of ways you CAN do it.
<fullermd> There can be a central server.  The distinction of the DVCS's versus the centralized ones is that there doesn't HAVE to be.
<fullermd> The simplest to grasp case is probably using bzr just like it were SVN or another centralized system.  You have one central branch somewhere, and everybody makes checkouts of it and works there.
<fullermd> Then all the commits go to the central branch, and if somebody else has commit'd, you have to 'update' to catch up before you can.
<fullermd> In this setup, you're basically all sharing a single branch.
<Infl8ableSoulm8> ahh, ok.
<fullermd> The opposite extreme is everybody having their own branch, and no central server.
<fullermd> In that case, to get Bob's changed, you have to merge from Bob.  To get Joe's stuff, you have to merge from Joe.
<fullermd> Sorta a full mesh.
<fullermd> (though you don't necessarily HAVE to merge from everyone individually; if Bob merges Joe's stuff, and then you merge Bob's, you get Joe's transitively)
<Infl8ableSoulm8> well, the central branch idea is the one that makes the most sense to me, since the idea is that they are all going to immediately be in use by the servers
<fullermd> That usually just doesn't scale for obvious social reasons past a very few people of course.  But it's viable technically.
<fullermd> What usually happens is somewhere in the middle.  e.g., everybody shares (either directly via checkouts, or indirectly via gatekeepers) one central branch, except that they also make new independent branches for "bigger" (hazily defined) changes.
<fullermd> But you can start out with a single central branch, then branch (haha) out from that later as you find reasons too.
<fullermd> You're not necessarily hooked in to the configuration you start out with.
<Infl8ableSoulm8> well, the person who pointed me this way claims that bzr is a lot easier to set up than svn...
<Infl8ableSoulm8> I have no idea how to even add a project to svn :/
<Infl8ableSoulm8> I walked through a crappy tutorial I found somewhere, and really don't understand it very well.
<fullermd> It is in a lot of ways.  Also more flexible in a lot of ways (and less flexible in some, though most would argue that those latter are bad ideas in the first place  ;)
<Infl8ableSoulm8> I just got it to work eventually.
<SamB_XP> it's true, bzr is a lot easier to set up ;-)
<fullermd> It's easier to start small&simple with bzr and then scale it up.  svn you have to start scaled up.
<Infl8ableSoulm8> well, I would like the idea of having the central server be on my linux box, with the main windows game server box pulling updates from the linux box.
<Infl8ableSoulm8> that way everything is available from two seperate datacenters
<Infl8ableSoulm8> well, I mean that the running copy is, anyway
<Infl8ableSoulm8> but I would also like to have a predefined directory structure that mirrors the structure of each game server
<Infl8ableSoulm8> so that I can browse through all the configs and plugins locally, and change a few things as need be, then commit, log into the windows box, and update
<Infl8ableSoulm8> and basically get rid of all the annoying filezilla/scp stuff I do now :P
<fullermd> Sure, you could do that with just having one big branch of the stuff on a central server, and checkouts of it in various places (the Win machine, your workstation, etc)
<Infl8ableSoulm8> sweet.
<fullermd> Note that with default ("heavy") checkouts, the full history is cached locally at each spot.  So you'll have N copies of all the data if you need it for recovery.
<Infl8ableSoulm8> so, when you go to set it up, how do users work?
<Infl8ableSoulm8> there are users that can commit, and other who are read-only, etc?
<SamB_XP> Infl8ableSoulm8: well, whatever you can do with unix permissions ...
<Infl8ableSoulm8> well, like svn has the webdav and ssh deals, but setting up a bunch of users and stuff is where things got hairy with svn.
<SamB_XP> (but there's no restriction of access to only PART of the tree)
<fullermd> bzr doesn't itself do any AAA.  That's all punted to higher (e.g., ssh) or lower (POSIX perms/ACLs) levels.
<Infl8ableSoulm8> what about restriction on a project-by-project basis?
<SamB_XP> that's pretty easy, yeah, as long as you manage them as totally seperate branches
<fullermd> Generally each project would be a separate branch.
<Infl8ableSoulm8> yeah
<fullermd> (in separate repos, since you can't effectively hard-limit access at a tigher granularity than that)
<Infl8ableSoulm8> because we run several different kinds of game server, and there may cmoe a time when people who have acess to Team Fortress 2 server configs will be a completely separate group of people from people who admin the Day of Defeat or Countrer-Strike servers, etc...
<Infl8ableSoulm8> ok, so I guess it's time for the classically windowsy question, is there a flashy simple GUI setup utility to get something like this set up for the central branch on ubuntu?
<Infl8ableSoulm8> I mean other thant he apt-get part... I can handle that just fine.
<Infl8ableSoulm8> I'm guessing not, if everything is dependent on user permissions :/
<fullermd> Well, a "central" branch is no different from any other branch.  That's fundamental; the concept of 'central' or 'leaf' is a totally social distinction.
<fullermd> So you put a branch somewhere, set perms on it appropriately, and tell everybody "that's the central branch"
<SamB_XP> the GUI isn't going to make it much easier, really
<SamB_XP> the only reason I use a GUI to make repos or branches is if I'm working in Windows and I don't have a command prompt open in the right place, really ;-)
<Infl8ableSoulm8> well, let me see...
<Infl8ableSoulm8> so I could just set up the 'client' or whatever you'd consider it, create a few directories and tell bzr that they are a certain branch
<SamB_XP> then it's easier to just pick the appropriate option of the shell menu rather than opening a cmd.exe, CDing to the appropriate directory, and THEN typing the command
<Infl8ableSoulm8> and then give people permission to update/commit?
<SamB_XP> yeah, basically
<SamB_XP> and what you call the 'client', I call 'bzr' ;-)
<Infl8ableSoulm8> right
<Infl8ableSoulm8> :)
<Infl8ableSoulm8> so I could just create a directory structure on my linux server in some user directory
<Infl8ableSoulm8> and set up a branch in a directory
<SamB_XP> well, you would want to use a group directory really
<fullermd> I'd recommend doing it as a throwaway and playing around with it a bit, to see what you'll be doing and how it fits.
<SamB_XP> that's a good idea, yeah
<Infl8ableSoulm8> so would each person with access to it need ssh access to the box?
<SamB_XP> if you play around a bit first, then you'll have more clue what you're doing ;-)
<fullermd> ssh access is the simplest choice, yes.
<Infl8ableSoulm8> hrmm.
<SamB_XP> is that a problem ?
<Infl8ableSoulm8> this is where not being much of a linux admin gets int he way.
<SamB_XP> ah, yeah ;-)
<Infl8ableSoulm8> well, I don't want to give a bunch of people basically shell access to my box.
<Infl8ableSoulm8> and I don't really understand chroot stuff.
<Infl8ableSoulm8> which is just a guess at one thing I'd need to know to lock things down for those usrs.
<SamB_XP> you don't trust unix permissions?
<Infl8ableSoulm8> no, the permissions are fine.
<Infl8ableSoulm8> I get that.
<fullermd> Well, you wouldn't necessarily have to use YOUR box as the "central" branch, would you?
<SamB_XP> true
<Infl8ableSoulm8> but I mean, if I give someone ssh access to my server, then they can fire up screen and irssi and idle irc or whatever.
<SamB_XP> and ?
<SamB_XP> (though there ARE ways to prevent that)
<Infl8ableSoulm8> I don't want them to be able to run random programs, but they obviously will need access to commands like cd or ls
<fullermd> Well, no, they'd only need to be able to run bzr.
<SamB_XP> that's true
<fullermd> They wouldn't be logging in to the box to work, they'd just be accessing the branch over bzr+ssh
<fullermd> They'd WORK on their OWN systems.
<Infl8ableSoulm8> right, so I need to figure out how to make it so a user can tunnel over ssh to use bzr, but not login to get a regular prompt
<Infl8ableSoulm8> or shell or whatever
<fullermd> I think there's some discussion in the docs about it, using key auth.
<SamB_XP> some kind of "allowed commands" setting for ssh...
<Infl8ableSoulm8> heh
<Infl8ableSoulm8> the docs say "Using SSH configuration options it is possible to restrict developers from using anything but Bazaar on the server via SSH, and to limit what part of the file system they can access."
<Infl8ableSoulm8> and that's it :D
<Infl8ableSoulm8> guess I have to browse the ssh docs :P
<luks> Infl8ableSoulm8: the usual way is using authorized_key to restrict access
<luks> bzr has a simple shell script in contrib/ that can be used in authorized_keys and gives you even more options
<Kamping_Kaiser> can i uncommit trunk-2 ?
<Kamping_Kaiser> i'd like to redo a change, and uncommiting it seems the easiest way to fix it up.
<fullermd> Technically, you don't uncommit a rev, you uncommit TO a rev.
<fullermd> So you can uncommit -2, by going to -3.
<Kamping_Kaiser> ah
<Kamping_Kaiser> all becomes clear. thanks.
<reyman> hello guys
<reyman> i have a question about repository, if i have two project on launchpad, i make 1 or 2 repository ?
<maxb> reyman: Usually 2 (just because there's no reason to put both in one), but multiple projects can share a repository if you really want
<reyman> ok thx maxb
<fullermd> Of course, on launchpad it's somewhat irrelevant, since you don't get to create repos anyway.
<lotia> how i do i get the revision number that the bisect plugin has switched to?
<fullermd> I'd guess either revno or revno --tree.  I'm not really sure exactly what bisect frobs.
<lotia> fullermd: thanks. revno doens't take into account the bisection
<fullermd> revno gives the revno of the branch.  revno --tree gives the revno of the working tree.  It's possible that bisect does its work without altering either one, so neither may help.
<fullermd> I'd guess there's probably a command in the plugin to have it tell you where it is, actually.
<MattCampbell> What's the status of nested trees?
<hazmat> jam, thanks for posting the ideas and implementation
<maxb> lotia, fullermd: bisect uses revert (because update -r didn't exist until recently), so the only place you'll be able to find the bisection revno is in whatever private metadata the bisect plugin is maintaining for itself
<lotia> maxb and any insight into where it does that?
<maxb> Sorry, no
<maxb> I never really used it seriously
<ianm_> when someone does a "bzr co --lightweight lp:luz", often a later "bzr update" will say they're at the latest rev, when in fact they're not-- any ideas as to why?
<ctrlsoft> ianm_: are you sure they didn't do a "bzr branch" rather than a bzr co ?
<ianm_> ctrlsoft: yes
<ianm_> often I did the original one for them
<ianm_> otherwise non-techies following website instructions
<ctrlsoft> ianm_: are they still bound to the correct upstream branch (bzr info should tell you)
<ianm_> hm I'll have to check that when I have access.  although the temporary solution has always been to do a fresh checkout, which does get the latest, making me think it should be bound to the correct branch
<lifeless> moin
<ctrlsoft> hey lifeless
<ctrlsoft> lifeless: Is it correct that Bazaar is updating ie.revision for a file but doesn't report that file in tree.iter_changes(parent_trees[0]) ?
<lifeless> sure
<ctrlsoft> the file wasn't changed as far as I can tell, why would it's revision attribute be updated?
<ctrlsoft> lifeless: (I'm relying on iter_changes() reporting all newly introduced (ie.file_id, ie.revision) tuples)
<lifeless> a merge
<lifeless> if two trees make the same change in parallel then their branches get merged
<lifeless> you'll get a no-change merge
<ctrlsoft> lifeless: ahh
<ctrlsoft> lifeless: thanks, I hadn't considered that
<lifeless> also if someone merges and does 'bzr revert file' or 'bzr revert .' you'll also see a no-change merge along one side
<ctrlsoft> lifeless: there's no way to search VF by sha1 is there?
 * ctrlsoft wonders why he asks a question he already knows the answer to
<jam> ctrlsoft: well, if it is the chk one there is :)
<jam> but no, you have to check inventories to find shas
<lifeless> CHK can tell you about no-change merges
<lifeless> but the regular tree interface can't
<mtaylor> help:
<mtaylor> I had some changes in a tree - I put them into a shelf
<mtaylor> then I did reconfigure-pipeline
<mtaylor> added a pipe
<mtaylor> tried to unshelve them
<mtaylor> and now I'm getting NotImplementedError: <property object at 0x7f41c87d5230>
<ctrlsoft> lifeless: How would I go about doing that for CHK?
<ctrlsoft> lifeless: I might implement a fast-path for CHK
<lifeless> ctrlsoft: check the fetch fast path
<lifeless> mtaylor: bug filing time
<mtaylor> lifeless: was afraid of that :)
#bzr 2010-04-04
<Infl8ableSoulm8> so, the version of bazaar in hardy is 1.3.0
<Infl8ableSoulm8> how do I make it use 2.0.x
<Infl8ableSoulm8> ?
<Infl8ableSoulm8> that or how do I cause the windows shell shortcuts use the the protocol 1.3 requires instead of the 2.0 version
<Infl8ableSoulm8> ?
<lifeless> add the bzr ppa on hardy
<Infl8ableSoulm8> bzr ppa on hardy contains 1.3.x
<lifeless> no it doesn't
<lifeless> see the bzr downloads page for instructions
<Infl8ableSoulm8> oh, weak.
<Infl8ableSoulm8> I forgot to apt-get update :P
<joda_bot> happy easter
<joda_bot> anyone here? :D
<Infl8ableSoulm8> so, can anyone familiar with TortoiseBZR tell me how to make it login to a remote respository as a different user than the one that is logged in on windows?  I would like to log in as a user on the linux box, but not as the user on the windows box.
<Infl8ableSoulm8> using bzr+ssh://
<wgrant> Infl8ableSoulm8: Tried bzr+ssh://user@host/path?
<Infl8ableSoulm8> yeah
<Infl8ableSoulm8> I mean that by default it is logging in as windows-user@boomheadshot.org instead of matt@boomheasdhot.org
<Infl8ableSoulm8> but it doesn't seem to really matter at this point.
<Infl8ableSoulm8> every time I commit something as one user, I can't update as a different user
<Infl8ableSoulm8> the files are created as being owned by user1:usr1 so I have to chown -R the whole repository again
<Infl8ableSoulm8> is it possible to set things up so all committed files are set 660 *:bzr ?
<Infl8ableSoulm8> oh, I see...
<Infl8ableSoulm8> user@
<Infl8ableSoulm8> hrm.
<Infl8ableSoulm8> that would work, but it would still require that the permissions on new files be set correctly.
<Infl8ableSoulm8> hrm... looks like sticky chmod is the winner :/
<edakiri> Does Bazaar or ancilliary tools have support for keeping  track of un-cherry picks (the revisions you do not want)?  Last I knew, it did not.  Does any DVCS? Vague neural impressions says, "Darcs might."
<edakiri> As I recall, you have to respecify the cherries or uncherries every time you merge with bzr, which is manually tedious.
<fullermd> No, it's not sticky.  It's setgid.
 * fullermd does the whole rant again.
<Infl8ableSoulm8> I called it 'sticky' because I found an email that referred to it that way
<fullermd> edakiri: Well, you can't have a revision without having all of its ancestors.  So, it's always THERE in the history.  But you can commit a reversal of the changes, and that will propogate forward fine.
<fullermd> (of course, if you then merge that branch into a branch where you WANT those changes, things get uglier)
<Infl8ableSoulm8> I have no actual idea what it was talking about.
<fullermd> Well, find the author of that email and kill them.
<fullermd> Well, OK, maybe that's a LITTLE over the top.  Take off at least 3 limbs, anyway.
<Infl8ableSoulm8> well, it actually was a chmod command.
<Infl8ableSoulm8> something like chmod 6774
<Infl8ableSoulm8> I am only used to using the three digit commands.
<fullermd> 0___4 on a dir would be bizaare.  Presumably it's more like 02775 or 02770.
<fullermd> You certainly don't need 04000 in there.
<Infl8ableSoulm8> well, if I had any clue what I was doing, I'm sure I would do it correctly.
<Infl8ableSoulm8> and it was a recursive command
<fullermd> On filesystems with SysV semantics, setgid on a directory causes files within that directory to inherit the dir's group.
<fullermd> (under BSD semantics, that's the default behavior)
<fullermd> setuid doesn't do anything in general.
<fullermd> You certainly do NOT want setuid/setgid on any of the _files_.
<Infl8ableSoulm8> well, it's letting me commit and update as different users without throwing errors, now.
<edakiri> fullermd: The case which turns ugly is exactly what the main thing desired for the D in DVCS: maintaining multiple branches which desire to keep different code variations.  So it is this case i am seeking a way to solve.
<fullermd> darcs is the only thing that might work for that, since it treats each change as an independent entity floating in space.
<lifeless> vila:   File "/usr/lib/python2.6/dist-packages/bzrlib/transport/http/__init__.py", line 132, in get
<lifeless>     return StringIO(response_file.read())
<lifeless> vila: thats urllib, and its buffering
<vila> lifeless: grr, yeah, someone put a FIXME there, in anger I presume, that means you need to override get(). You don't need to seek backwards right ?
<lifeless> vila: no, I have a 4GB+ stream to deal with ;)
<lifeless> vila: I'm calling _get for now.
<lifeless> vila: this will be breaking http smart server initial clones
<lifeless> vila: by breaking I mean 'this is why we are running out of memory'
<vila> lifeless: bzr is supposed to use readv() for packs so should not be affected
<vila> lifeless: or are you saying we *do* use get() ??
<vila> lifeless: I have to go *now*, be back in a couple of hours
<vila> lifeless: as hinted in the FIXME this *can* be fixed, bundle reader just needs to keep track of whatever it reads and give it back when needed instead of seeking backwards
<lifeless> vila: not packs
<lifeless> bzr+http
<lifeless> vila: actually, I think that case is clean
<lifeless> bye
<lifeless> vila: back yet ?
<vila> lifeless: wow, back ~3 minutes ago :)
<lifeless> are you aware of any 32 bit limitations in python socket/urllib on 64bit Ubuntu ?
<vila> no, and babune, as well as most its slave run with 64 bits OSes. I don't know how python is built there though
<vila> lifeless: any specific case ?
<lifeless> http://pastebin.ca/1856482
<lifeless> I hit ctrl-C when I was seeing no network traffic, and no error, on my test lmirror server
<lifeless> thats the traceback ont he client
<lifeless> I'm not saying that bzrlib.transport is necessarily buggy... but something strange happened *somewhere*
<vila> lifeless: weird, self._rbuf seems to be a StringIO() buffer, I fail to see how that could block, could it be that you were *very* unlucky on yout ctrl-C ?
<lifeless> vila: well,i ts more that I'm wondering why my server would suddenly halt
<lifeless> a 32 bit issue would explain it, if something somwhere has a counter and it wraps at 2G
<lifeless> or even at 4G
<vila> lifeless: it's an extrenal server right, not one in the same process as your http client ?
<lifeless> the stream is - let me just wget it
<lifeless> 4126895989 bytes long
<lifeless> du -s /tmp/t/music/
<lifeless> 2099976 /tmp/t/music/
<vila> IIRC bt.http.response will read by 500K chunks
<lifeless> is the amount writen to the output dir ont he machine I'm streamin to
<vila> lifeless: 2099976 is not a multiple of 512 * 1024, weird
<lifeless> its stuck, same place
<lifeless> client side si looping:
<lifeless> recvfrom(4, "", 524288, 0, NULL, NULL)  = 0
<lifeless> 100% CPU use :(
<vila> lunch time here,
<vila> you mean it loops *trying* to read but getting nothing ?
<lifeless> right
<lifeless> or
<lifeless> its looping with a zero length buffer
<lifeless> I'm going to check the params now
<vila> at least 524288 is 512 * 1024, so we are indeed respecting that
<lifeless> why deoes 512*1024 matter ?
<lifeless> oh, so I *know* that the server can send a 4G stream
<lifeless> because wget can get it all.
<lifeless> man recvfrom
<lifeless> 524288 would appear to be the length we're willing to receive
<lifeless> so that call is ok
<vila> yes, that  bt.http.response imposing that 512K to avoid memory errors
<vila> s/that/this/
<lifeless> I'm running it a gain with an assert in osutils.pumpfile
<lifeless> just incase its gotten a zero-length read or something silly organised
<lifeless> vila: http://mail.python.org/pipermail/python-bugs-list/2005-January/027258.html is int he sapce
<lifeless> hah! I think I know.
<lifeless> 32-bit squid build, I think
<lifeless> yeah
<lifeless> yup
<lifeless> gnight
<vila> lifeless: gnight, so the problem is solved for you ?
<lifeless> very sure it will be
<vila> ok
<lifeless> the client was using a 320bit squid build without -DLARGEFILE wor wahtever
<lifeless> I'll look into it more tomorrowish
<Annaa> http://tinypic.zapto.org/2kn4m8.png?t=1270382681 do my breasts look to big?
<fullermd> It must be hard to have a 320 bit build without LARGEFILEs...
<vila> Annaa: dunno about your breats, but your brain, definitely no
<vila> fullermd: naah, he emant really LARGE, like Annaa's
 * fullermd keeps waiting for you to type 'Anaaa'
<vila> bananaaaaa
<fullermd> Is that just a typo, or are you a sheep?  'cuz I've been thinking about making a new sweater...
<vila> I was thinking about some string search algorithm that mentioned banana as a useful test case :)
<jam> banana-rama mo-mana fee-fi fo fana, banaaana
<jam> morning vila and fullermd
<ferringb> so... random question, using bzr-svn, now trying to merge the work back (quite a few moves, bunch of modifications)... bzr-svn however seems to just be attempting to do a remove/add instead of a move
<ferringb> bit non optimal since history will be lost
<ferringb> any ideas?
<ferringb> curious, how would one go about pushing revs/history of a bzr branch into svn when there is no common ancestor?
<SamB_XP> ferringb: uh, carefully ;-)
<SamB_XP> you may wish to try it with a local toy SVN repo first
<ferringb> SamB_XP: or toy branches
 * ferringb figured it out
<ferringb> basically push to an empty location in svn
<ferringb> trickier was how to get revs from a bzr branch directly into svn w/ the history fully merged in (hacked that one, but it worked)
<goundy> Hi
<goundy> Guys, do you know a place where I can have a private bazaar repository for free ?
<goundy> (I need this temporary actually :))
<lifeless> any server you can sftp or ssh into
<SamB_XP> (or access as a filesystem -- say, a flash drive?)
<Infl8ableSoulm8> I will give you a free, private bzr repository for $100!
<Infl8ableSoulm8> oh.
<SamB_XP> I think he meant money-free rather than free-of-restrictions
<Infl8ableSoulm8> right.
<Infl8ableSoulm8> besides the fact that I'm a newb and no one would want to have their stuff hosted on my box to begin with :D
<SamB_XP> a Linux newb ?
<Infl8ableSoulm8> not so much a linux newb.
<Infl8ableSoulm8> I am pretty good with linux for desktop purposes.
<SamB_XP> goundy: what organizations are you affiliated with?
<SamB_XP> any?
<Infl8ableSoulm8> but all this security and permissions stuff that comes with running a server is kinda over my head at the moment.
<goundy> SamB_XP, nope... not yet actually that's why I'm looking for a quicky :Â°)
<SamB_XP> I thought maybe you had a school or something
<goundy> <Infl8ableSoulm8> I will give you a free, private bzr repository for $100!> Ohooo generous :p
<goundy> SamB_XP, I do have one, but my code isn't targeted to it
<SamB_XP> well, they often have CS departments, and those often have some way of getting a shell account...
<SamB_XP> another option would be to use one of those computers your mother wishes you'd just throw away as a *nix server
<fullermd> See, I thought about trying that once.  But getting *nix running on an Apple ][ is a bit of a challenge.
<goundy> SamB_XP, yeah, unfortunately the only machine my mum wishes I throw away is yet down :p
<SamB_XP> fullermd: lol
<SamB_XP> fullermd: I'm thinking college was a few years back for you, yes?
<fullermd> It wasn't THAT long ago!  It was just...  umm...  OK, shaddup.
<Infl8ableSoulm8> it could just be that their CS dept is that far back.
<fullermd> She does still wish I'd throw away the Apples, though!
<SamB_XP> it's only that I don't think people young enough to still be in college were old enough to have any control when any Apple IIs the family may have had would probably have been thrown out ;-)
<fullermd> Pah.  Slackers.
<SamB_XP> whu?
<SamB_XP> are you implying that more people your age should be getting PhDs or something ?
<fullermd> Actually, I acquired most of them from a school that was throwing them out (many, MANY years after they should've)
<SamB_XP> ah
<fullermd> Most of the people I went to school with who intended to get PhD's have them by now.
<SamB_XP> okay, that may throw off my reckoning ?
<fullermd> (and the remainder probably won't get them anytime soon)
#bzr 2011-03-28
<poolie> hi all
<spiv> Hi poolie
<poolie> hi spiv
<poolie> spiv i'm going to just try to get through some of my currently assigned bugs today:
<poolie> stale lock detection, automatic whoami, some others
<jaricanese7> Hey guys. Not sure if this has been asked before, but I can't seem to find an answer on the Internet
<jaricanese7> Why doesn't Maverick get Bazaar 2.2.2+ packages?
<poolie> jaricanese7, it will, it's just slowly passing through the sru process
<poolie> you can get an update now from the ~bzr ppa
<jaricanese7> Because I was doing some research, and I noticed I have Bzr 2.2.1
<jaricanese7> and 2.2.4 is already out
<jaricanese7> If the update takes a longer, there may not be a point since I assume Natty will come with Bazaar 2.3
<jaricanese7> I was hoping not having to use the PPA but I guess that'd what I'll have to do
<poolie> let me check
<jaricanese7> Just curious, is this something I can do?  As a community member, package this? Or only Bazaar developers can do this?
<spiv> Hmm, I'm not sure where the delays are atm.
<spiv> I don't think it's in packaging.
<spiv> But if not I'm not sure where, because bzr is one of the approved micro-release exceptions to the typical SRU process (https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions)
<jaricanese7> I see
<jaricanese7> That's weird
<poolie> it's with jelmer or me pushing on it
<poolie> or nagging for it to get uploaded
<poolie> you can ask on the bug for it, um
<poolie> my net connection here is very slow so i can't find it
<poolie> basically someone just needs to ask an authorized developer to upload it and to push it through that process
<poolie> spiv, i want to change lockdirs to return real objects for the lock info, not dicts
<poolie> should i
<poolie> - just break the api, and update in-tree callers
<poolie> - support just __getitem__
<poolie> - subclass UserDict?
<spiv> poolie: you could subclass dict
<spiv> Although I think any of those options is fine.
<spiv> Are there any out-of-tree callers in any of the common plugins?
<spiv> If there are and they only need e.g. __getitem__ support then that's probably the way to go.
<poolie> oh i guess just subclassing dict would be simpler
<poolie> it's a bit hard to grep for
<poolie> but i don't think any of them use it
<spiv> I'd probably just break the API then
<spiv> Assuming that it wouldn't be too hard for a hypothetical plugin that did use it to support both old and new APIs.
<poolie> no
<poolie> it shouldn't be
<poolie> wow, ben always surprises me
<poolie> why build a package and not even try to install it?
<fullermd> 'cuz it's really hard to install a package that isn't built.  So logically, the opposite of something really hard is something really easy; hence, !(install && !build) == !install && build   8-}
<poolie> i guess it would be like wrestling a pig to ask why
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> spiv: the branchmergeproposal creation error the package importer is having
<lifeless> I want to make sure that we're not talking past each other :)
<lifeless> AIUI it was crashing a lot
<spiv> It was crashing a lot due to a bzr bug
<lifeless> I think this is a bug in the API parameters being passed to LP
<lifeless> ah, ok, cool
<spiv> The bzr bug is fixed, and the fixed bzr deployed
<lifeless> sweet
<spiv> Now it is crashing with what appears to be bug 520412
<ubot5> Launchpad bug 520412 in Launchpad itself "fix review_types argument of the API's Branch.createMergeProposal method" [Critical,In progress] https://launchpad.net/bugs/520412
<spiv> Which judging from chatting with wgrant earlier today is probably due to the previously failing imports being relatively stale
<spiv> And thus there's some sort of divergence that the importer is apparently trying to make merge proposals about?  I think vila knows about that, I think it may have been a recent change
<wgrant> Two bugs that I see:
<spiv> I'm hoping to catch vila when he gets online to ask him about it
<wgrant> 1) The importer is calling the API incorrectly.
<wgrant> 2) The API is raising a ValueError and OOPSing, instead of doing something even slightly useful.
<lifeless> spiv: oh, ok - so what I am saying is valid
<lifeless> bug 520412 is 'lp crashes when given bad input'
<ubot5> Launchpad bug 520412 in Launchpad itself "fix review_types argument of the API's Branch.createMergeProposal method" [Critical,In progress] https://launchpad.net/bugs/520412
<lifeless> spiv: if I were working on this I would get the parameters being given to lp to be printed in my log, and then look
<lifeless> AIUI is the importer is saying something like
<wgrant> It's pretty clear what the problem is...
<lifeless> reviewers=[x,y,x], review_types=[1,2]
<wgrant> It's passing reviewers=[ubuntu_dev] without review_types
<vila> hi all !
<lifeless> it needs a review_types=[''] I think
<lifeless> spiv: I hope thats clearer/cleared this up
<lifeless> I'll check back in a while
<spiv> lifeless: well, it was pretty to *me* :P
<spiv> s/pretty/pretty clear/
<spiv> vila: read the last 10 minutes of backlog? :)
<vila> lifeless, wgrant, spiv : There are several patches for the p-i in the queue waiting on RT #<can't find it>
<vila> spiv: done
<vila> I was able to reproduce locally at one point, can try lifeless proposal
<vila> but we'll still need to deploy on jubany which is... hard these days :-/
<vila> ha, rt #44761, nothing happened since friday...
<spiv> vila: we need RT to update lp:udd on jubany?
<vila> spiv: read the ticket, the web server needs to be updated
<vila> spiv: and the importer restarted with care
<spiv> vila: I guess make sure poolie knows about it, it hasn't had a priority set yet
<vila> spiv: he knows, but he's not online now
<vila> spiv: also, the ValueError I see (locally) doesn't seem to be related to merge proposals so I may have been wrong above or we have more than one bug
<spiv> vila, wgrant: I notice there's a commented out line in the code to pass #reviewers=[ubuntu_dev.self_link], review_types=[""]
<spiv> vila: https://lp-oops.canonical.com/oops.py/?oopsid=1910A1064
<vila> spiv: commented where ?
<wgrant> spiv: Last I saw that wasn't commented out, and didn't have review_types=[""]
<wgrant> spiv: It was changed on 2011-03-03, IIRC.
<spiv> vila: just grep for createMergeProposal
<vila> spiv: not commented here (lp:udd)
<vila> spiv: where are you looking ?
<spiv> vila: http://bazaar.launchpad.net/+branch/udd/view/head:/import_package.py#L513
<vila> argh james_w pushed 8-/
<vila> spiv: anyway, given the commit dates, this has been deployed after we had the ValueErrors AFAICS
<spiv> vila: I don't know that recent changes to that currently commented out line have caused the problem
<spiv> vila: I do know that our call to createMergeProposal is incorrect
<vila> spiv: given the commit messages, it looks like james_w was working on this though
<spiv> vila: ok
<spiv> vila: so I'll just give gst-plugins-bad0.10 a kick, as that is the one named in the OOPS
<spiv> vila: if the current state has fixed the problem, as implied by james_w commit messages, it won't fail with that error
<vila> spiv: trying
<vila> spiv: don't forget to commit your delete_branch stuff by the way ;)
<vila> spiv: just got the oops (first attempt gave a blank page), right, I was talking about a list.remove(x): x not in list, ValueError, definitively different :)
<vila> gs-t-bad-plugins passed
<spiv> vila: yes, the ValueError here isn't seen by the package-importer, it happens in LP and show as a HTTP 500 to the client.
<spiv> vila: well, retry the rest I guess
<vila> spiv: already done
<spiv> Thanks
<vila> spiv: thanks to you and james_w ;)
<vila> haa, bad request again for kde-l10n-th
<vila> spiv: you confirmed HTTP 500 or did you mean HTTP 400
<vila> s/confirmed/confirm/
<vila> and s/$/?/ gee
<spiv> vila: 500
<vila> gobject-introspection finally passed, pfew
<spiv> vila: see bug 520412 for the LP bug an incorrect call to createMergeProposal triggers
<ubot5> Launchpad bug 520412 in Launchpad itself "fix review_types argument of the API's Branch.createMergeProposal method" [Critical,In progress] https://launchpad.net/bugs/520412
<vila> bah, I hate software that tells me: "Hey, your input is wrong, here is how to fix it".
<vila> JFDI !
<soren> vila: +1
<soren> "Remember: The URL you enter must end with a slash!"  Uh... Just add it, if I forget, mkay?
<spiv> vila: so long as there is 0 ambiguity about the fix, I tend to agree
<vila> well, it used to work before right ? If the list is of the right length with '' items, it's still a valid item right ? Just default to it then no ?
<vila> s/valid item/valid parameter/
<spiv> vila: nothing in LP has changed here lately
<spiv> vila: (that the bug number is in the 500000s gives a pretty strong hint about that)
<vila> right but the bug report also says: "On the other hand this behavior is different to the behavior of the web interface, where the review type argument is optional."
<vila> so there are some reasons to believe the behavior was desired
<spiv> Yes, it does, but that's unrelated to "it used to work before right"
<spiv> It's "the web UI gets it right, the API doesn't"
<vila> no idea about that, but I'd be surprised (choked?) that this went unnoticed in the p-i for so long...
<vila> anyway, if we can fix it in the p-i, we should
<spiv> vila: http://bazaar.launchpad.net/+branch/udd/revision/410
<ubot5> Error: Launchpad bug 410 not found
<vila> ubot5: +1 ;)
<spiv> vila: So, it's not that it was an old bug unnoticed
<spiv> vila: it's a new bug in udd
<spiv> vila: a few weeks old
<vila> :-(
<vila> spiv: thanks for the analysis...
<vila> spiv: and sorry for being so dense, I need more coffee ;)
 * vila notes: stop presuming that untested code works
<spiv> vila: no worries
 * spiv logs off for the day
<vila> spiv: one last thing: poolie is still having trouble with his ADSL modem right ?
<vila> 5 babune slaves failing on bzrlib.tests.test_revisionspec.TestRevisionSpec_date.test_yesterday
<vila> don't tell me, someone didn't fully get what DST is about ?
<jelmer> moin
<spiv> vila: yes
<vila> jelmer: hi !
 * jelmer waves to spiv and vila
<jelmer> spiv: Did you see my review request for ~jelmer/bzr/move-interbranch-fetch2 ?
<spiv> vila: down to 466 failures, hurrah
<vila> spiv: yeah ;)
<jelmer> spiv: Sorry this was necessary, my review of your fetch tags branch wasn't very good.  :-/
<spiv> jelmer: I have, haven't looked at it closely yet
<spiv> jelmer: I'm not sure that I like the more limited API.  I wonder about other options other branches might have.
<spiv> fetch_loom_thread?
<spiv> That sort of thing
<jelmer> spiv: API users wouldn't really know what to specify in that case though
<spiv> Although 'fetch' is a sort of weird thing to have on Branch in a sense
<jelmer> spiv: It seems reasonable to have Branch.fetch() as a convenience wrapper around Repository.fetch
<jelmer> spiv: yeah
<bialix> heya
<bialix> bonjour vila
<vila> fullermd: wow, 10072 freebsd patches since 2011-03-09 ? Should I worry or did I just miss some important news ?
<vila> bialix: _o/
<bialix> vila: we don't have a dedicated 2.4 branch yet, have we?
<vila> bialix: for bzr ? No. Not until 2.4.0
<vila> bialix: but the series exists already nvertheless
<bialix> ok, I need to put the news for my py2exe patch, I think I should wait till you cut out 2.4b1?
<vila> bialix: 2.4b1 *has* been cut, I still need to announce it though
<vila> bialix: until 2.4.0 we release from trunk
<bialix> hmm
<vila> bialix: https://launchpad.net/bzr/2.4/2.4b1
<ubot5> Error: Launchpad bug 2 not found
<bialix> vila: ok, I see the 2.4b2 section now. most likely yesterday I've used slightly outdated truk
<bialix> trunk
<bialix> vila: thank you
<vila> bialix: np
<bialix> oh yes, forgot to update my copy of bzr.dev, heh
<vila> fullermd: weird, ended up with .. 90 new ports/files only
<alexKeith> hi there
<alexKeith> i'm new to VCS and stuff
<alexKeith> yesterday bzr commands were working fine but today i get the following error
<alexKeith> bzr: ERROR: Connection error: while sending CONNECT xmlrpc.edge.launchpad.net:443: [Errno 110] Connection timed out
<alexKeith> does that mean my net connection in not proper or something else?
<jelmer> hi alexKeith
<jelmer> alexKeith: it looks like either an issue on your side or on Launchpad's side
<alexKeith> jelmer: in the application on the connection?
<jelmer> alexKeith: in the connection
<jelmer> alexKeith: I doubt it's an application issue if it worked ok earlier
<alexKeith> jelmer: hmmm... thanks for the suggestion.. will wait a few more hours
<lamont> so if I wanted bzr uncommit (either in a particular branch, or even machinewide if need be) to scream at the user and die horribly rather than uncommitting, is that trivial to do?
<Peng> I suppose you could write a plugin...
<Peng> I believe pygame is your best option for audio output. ;-)
<vila> lamont: 'bzr alias uncommit=logout' could be a start, but since this is stored (and read only from) bazaar.conf, it will affect only a single user
<alexKeith1> jelmer: found a 6 month old log on the same problem on launchpad channel...
<vila> lamont: aren't you after 'append_revisions_only' on the target branch instead ?
<alexKeith1> jelmer: though no solution is given
<vila> lamont: 'bzr alias uncommit=logout' could be a start, but since this is stored (and read only from) bazaar.conf, it will affect only a single user
<vila> ghaa, history editing fail
<vila> lamont: I meant 'bzr alias uncommit=I_HATE_YOU_DONT_DO_THAT' to take screaming into account
* 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: jelmer | 2.4b1 is officially out (ppa:bzr/beta needs love)
<lamont> vila: yeah - but I want it to affect the branch, not the user...
<lamont> rather, I want it to affect all users of the branch, not just the one
<vila> lamont: strictly speaking, uncommit is for the working tree, not the branch , hence append_revisions_only
<lamont> which I suppose gets back to the whole "zomg can't have scripts in the branch, because we'd insist on copying them when you branch and that'd be bad"
<lamont> vila: ah
<vila> but even that can be overridden with --push --overwrite (IIRC)
<lamont> so short answer is that there's no trivial solution to the administrative issue at hand
<lamont> and I suppose that's ok
<vila> lamont: I still don't clearly understand your problem :-/
<vila> lamont: I'm sure there is a valid use case here, I just don't get it (so far)
<lamont> vila: group of users who have become trained that bzr uncommit is perfectly reasonable, transitioning into a new use model where it is absolutely NOT reasonable, and still doing it sometimes
<bialix> who can talk with me about lp:branches and how they becomes bzr+ssh://b.l.n/+branch URs?
<vila> lamont: not reasonable because ?
<lamont> vila: because the branch is actually published to other machines
<vila> lamont: it breaks the shared branch history ?
<lamont> vi bzr pull in a cronjob
<lamont> via
<vila> ha right, then, yeah, append_revisions_only, so the users are gently nudged to *add* revisions (even to revert a silly change)
<lamont> vila:  and that's something I can set on the branch?
<vila> lamont: yes, in branch.conf
<lamont> oh, nice
<vila> we should really make it the default
<bialix> does launchpad plugin has any cheap way to decode +branch URL and extract the project name, instead of parsing the parts of URL in my code?
<lamont> I've been told that I should never edit branch.conf directly... what's the offically blessed way (and syntax) for setting this?
<lamont> mind you, I still frequently cat .bzr/branch/branch.conf rather than bzr info
<vila> lamont: 'bzr  config' ?
<lamont> bzr: ERROR: unknown command "config"
<vila> :-/
<vila> lamont: import from future ;  bzr config
<vila> lamont: so, without bzr config, you need to edit manually
<lamont> 2.2 or 2.3?
<vila> 2.3
<alexKeith1> jelmer: restarting solved the problem
<lamont> and I assume 2.3 still has the "momma knows best" belief of forcing me to have run bzr whoami?
<lamont> because breaking cronjobs is better than not breaking them, or some such
<alexKeith1> jelmer: i had changed the proxy settings after booting and then connected as i did a few hours before
<vila> lamont: and, when in the right dir, 'bzr config appen_revisions_only=True (http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/configuration-help.html)  should work
<alexKeith1> jelmer: so now i tried restarting and it worked
<vila> lamont: yes
<alexKeith1> jelmer: does this classify as a bug?
<vila> lamont: on the other hand, we heard you and poolie is working on fixing it ;)
<vila> lamont: should be in 2.4 (AIUI)
<lamont> vila: yay
<vila> bialix: the translation is done on lp, you have no way to emulate that
<vila> bialix: what's the need ?
<vila> bialix: jam has been playing with the xmlrpc code and should have the details in his hot cache ;)
<lamont> afk
<fullermd> vila: Sweep of MD5 checksums that touched files all over the place.  Kinda cosmetic/internals, so it doesn't have anything to do with needed upgrades.
 * vila happily shudders
<bialix> vila: we have a code in qbzr to automatically guess the project name based on lp URL
<bialix> vila: that code does not like +branch, and I don't like it either
<vila> bialix: just deleting it from the start should make your guesses as good as they were before
<bialix> vila: if I do `bzr branch lp:qbzr` then I got parent URL as bzr+ssh://b.l.n/+branch/qbzr
<vila> bialix: you know how to guess: bzr+ssh:/b.l.n/qbzr ?
<bialix> vila: if I do `bzr get lp:qbzr/0.20` then I got parent URL as bzr+ssh://b.l.n/+branch/qbzr/0.20
<bialix> vila: do you know how to create it?
<vila> create what ?
<bialix> that parent URL: bzr+ssh:/b.l.n/qbzr
<jam> bialix: that is the wrong parent, though
<jam> that path doesn't exist
<jam> +branch/qbzr does
<bialix> I've just showed you what bzr creates for different cases
<vila> bialix: I think it doesn't exist, that's why +branch has been created
<jam> bialix: +branch was specifically created to allow server-side expansion of lp: urls
<vila> bialix: so lp can redirect properly
<jam> To support private branches
<jam> etc
<jam> vila: no redirect
<jam> it maps the virtual fs to include those paths
<bialix> before it was always bzr+ssh://b.l.n/~team/project/branch
<jam> bialix: It was about 3-6months ago Launchpad switched
<vila> jam: yeah, redirect not in the HTTP sense, bzr+ssh is not HTTP anyway
<jam> because XMLRPC can't expand private branches
<jam> vila: sure, just mentioning that "cat +branch/bzr/.bzr/branch-format" is a valid thing to do in the VFS
<bialix> jam: I need a cheap way to extract project name from new urls
<jam> bialix: if you look at the new bzr.dev LaunchpadDirectory, you can see the basic rules
<jam> lp:ONE
<jam> ONE must be the project name
<bialix> will it work locally?
<jam> lp:ONE/TWO
<jam> ONE is the project name, TWO is the series name
<jam> not related to branch
<jam> though it maps to a branch
<jam> if there is a ~ then it must be a fully qualified path
<jam> lp:~user/PROJECT/BRANCH
<bialix> jam: I'm reading lp_directory.py but I don't see what can help me?
<jam> there are a few special cases for handling "ubuntu" and "debian"
<maxb> OR one/two is a distro/series
<maxb> nuh-uh, they are not special casea
<jam> maxb: one/two can only be distro/project
<bialix> jam: I need a way to extract project name from bzr+ssh://b.l.n/something
<jam> maxb: unless you can somehow branch an entire series
<jam> (lp:ubuntu/bzr, for example)
<jam> bialix: and you are trying to do it now that we have +branch syntax?
<maxb> jam: lp:one/two can be project/series or distro/series
<bialix> jam: right now I have to code this decoder logic directly into qbzr. if I can use some code from lp plugin then I will save my dude in the future when bzr/lp team will decide to change again
<maxb> um, no
<maxb> I mean...
<maxb> jam: lp:one/two can be project/series or distro/package
<bialix> jam: yes
<jam> maxb: sure. But how do you know it is a distro rather than a project? By having specifically listed distros that are encoded in the lp db?
<jam> which we can hint at, by just hard-coding the obvious ones
<jam> aka, special cased
<maxb> Ah, sure. Yes, the syntax doesn't tell you the type of pillar involved
<jam> bialix: so if I do "lp:~user/project/branch" that will still be expanded to "bzr+ssh://b.lp.net/~user/project/branch" (at least at the moment)
<jam> so you'll still want that logic
<jam> for everything else
<jam> bzr+ssh://b.lp.net/+branch/SOMETHING
<jam> I would treat it as:
<jam> parts = something.split('/')
<jam> if len(parts) == 1:
<jam>   project = parts[0]
<jam> elif:
<jam>   parts[0] in ( 'debian', 'ubuntu'):
<jam>  # punt for now
<jam> else:
<jam>   project = parts[0]
<jam> the debian/ubuntu rules are a bit complex
<jam> because you can have
<jam> ubuntu/bzr
<jam> ubuntu/natty/bzr
<jam> ubuntu/natty/bzr/branch
<jam> I don't think you can have 'ubuntu/bzr/branch'
<bialix> omg
<maxb> You can't have the 4-part one
<jam> (If you specify a branch, you have to specify the distroseries)
<jam> maxb: ah, you have to specify the user in that case as well?
<maxb> yes
<jam> in which case it becomes ~user/ubuntu/natty/bzr/branch
<maxb> I think there's a much simpler way to describe this:
<maxb> If it starts with a ~, then it's a fully qualified unique name starting with a user
<bialix> jam: all that stuff scaries me almost to death; may I file a feature request to add decoder into lp plugin?
<maxb> If it does not start with a ~, then the first component is a pillar (project/distro), with a reasonable hierarchy of aliases underneath it
<maxb> bialix: If all you want is a project name and you are willing to temporarily disregard distro package branches, then you just need to take the first component, unless it has a ~, in which case the second
<bialix> maxb: do you mean the case bzr+ssh://b.l.n/+branch/~user/ubuntu/natty/bzr/branch ?
<maxb> That is speaking about lp: URLs, of course. If you're working with bzr+ssh://b.l.n/ ones, then chop off that prefix, additionally chop off +branch/ if present, and stick a lp: on the front, then proceed as before
<bialix> maxb: no, this won't work for me
<maxb> why not?
<bialix> maxb: I need project name to create a push url suggestion as: lp:~user/PROJECT/new-branch
<maxb> yes?
<maxb> I just suggested a simple algorithm to get it
<bialix> yes, thanks, but I need project name
<vila> bialix: that's what maxb suggested: how to get the project name
<vila> bialix: presumably from the remember parent location
<bialix> yes, that's exactly my case
<vila> If you're working with bzr+ssh://b.l.n/ ones, then chop off that prefix, additionally chop off +branch/ if present, and stick a lp: on the front, then proceed as before
<vila> citing maxb^
<bialix> vila, maxb: before I always had only scheme://host/~user-id/project-name/branch-name/
<bialix> I don't need to stick lp: on the front
<bialix> today I see more cases:
<bialix> scheme://host/+branch/project-name
<bialix> scheme://host/+branch/project-name/series-name
<vila> bialix: we don't know what you had :) Just adapt, may be you just need to fake a 'bzr+ssh://bl.n/+branch'
<bialix> ok, that's enough
<vila> .. scheme
<vila> bialix: but keep in mind that you will always try to guess what is happening on a remote server and if things change there, you'll need to catch up anyway
<bialix> that was my initial question: can I use launchpad plugin to do this or not
<vila> same answer applis to the launchpad plugin: it guesses, unless it asks explicitely to lp (and even there I'm not sure it get the true branch)
<maxb> bialix: However, given the current URL structure, getting the project is trivial: Remove "bzr+ssh://bazaar.launchpad.net/". Remove "+branch/" if present. Remove "~user/" if present. Next component is the project or distro
<vila> bialix: are you trying to solve this problem in a server-agnostic way ?
<vila> bialix: because we only answered about the lp specifics so far
<vila> bialix: and it seems we are not all on the same page
<bialix> vila: I'm trying to solve this problem in qbzr-unrelated way
<vila> bialix: but in a lp-specific way ?
<bialix> I can live with the suggested way, but if I can use lp plugin for that I'd be happy
<bialix> vila: yes, for generic case we have different code
<bialix> I can point you to the real code, if you wish
<maxb> http://paste.ubuntu.com/586468/
<maxb> I have just typed up a quick refcard to the various URL forms ^^^
<vila> bialix: AFAIK, the lp plugin doesn't provide such a feature, but this sounds like a good one to add
<bialix> maxb: what should I use for distro/package then?
<vila> bialix: so file a wishlist bug and add a patch or a pointer to your implementation
<vila> bialix: if you want to propose a push location, you should probably respect dsitro/package
<vila> bialix: and in most cases *add* ~user if not already there as I think most users *can't* push to the official branch
<vila> maxb: isn't it ? ^
<bialix> maxb: qbzr intent is to provide suggestion for push of feature branch back to lp. so if one have lp:ubuntu/bzr what should be suggested URL for new branch?
<maxb> vila: Mostly not, no.
<maxb> bialix: lp:~user/ubuntu/current-ubuntu-development-series/bzr/somename
<bialix> vila, maxb: again, please look: if I have project-name, and I know local user name, then suggestion will be: lp:~user-name/project-name/new-branch-name
<maxb> Yes
<vila> and that's good for upstream branches (AIUI) not for packaging branches
<bialix> so? should I ignore any attempts to suggest URL for distro or not?
<maxb> 15:30 < bialix> maxb: qbzr intent is to provide suggestion for push of feature branch back to lp. so if one have lp:ubuntu/bzr what should be suggested URL for new branch?
<maxb> 15:31 < maxb> bialix: lp:~user/ubuntu/current-ubuntu-development-series/bzr/somename
<bialix> vila: http://paste.ubuntu.com/586468/
<bialix> DISTRO/SOURCEPACKAGE, DISTRO/SERIES/SOURCEPACKAGE, DISTRO/POCKET/SOURCEPACKAGE ?
<bialix> what will be "project-name" here?
<maxb> THERE IS NO PROJECT NAME
<bialix> what is "current-ubuntu-development-series"?
<maxb> The name of the current ubuntu development series
<maxb> natty, for now. Later it will be oneiric
<vila> bialix: PROJECTNAME ~= SOURCEPACKAGE (/me runs before maxb yells)
 * maxb wonders what kind of operator ~= is :-?
<vila> bialix: the difference is that a "project* can be the source for several packages
<vila> maxb: the handwavy version of = :D
<maxb> well, it could be, but yuck. It nearly never is
<maxb> (one project multiple packages, that is)
<vila> maxb: right, but in bialix case it would be what his code recognize as project name in the parent location
<vila> hence the hand wave
<maxb> Well, for bialix' specific use case it's more like PROJECTNAME ~= DISTRO/SERIES/SOURCEPACKAGE
<vila> maxb: oh ! Certainly ! (The handwavy operators are very welcoming operators ;)
 * maxb needs to step afk for a bit, back later
<bialix> I'm going to blacklist distro case, it drives me crazy. no need to yell, I'm not totally stupid, just a bit
<vila> :-D
<vila> the distro/series/sourcepackage is certainly hard to grasp
<bialix> distro can be only [ubuntu, debian], right?
<vila> bialix: so far, and AIUI, yes
<bialix> vila, maxb, jam: what I have in the end: http://paste.ubuntu.com/586484/
<jam> bialix: do you care to support "bazaar.qastaging.launchpad.net" and those variants?
<bialix> jam: should I?
<jam> it also looks like you aren't handling "lp:ubuntu/bzr" but that's up to you
<jam> bialix: none of those are long-term available (if you push data there, it gets wiped later)
<jam> people use it for testing
<bialix> jam: I don't understand how to handle distros case
<bialix> jam: that check for host has been written by Ian, I'll be happy to extend it if you teach me
<jam> well, it looks like he was trying to support "qastaging.bazaar.launchpad.net" but that isn't how it is actually spelled
<jelmer> jam: interesting to read that performance analysis...
<jam> bialix: http://paste.ubuntu.com/586487/
<jam> handles DISTRO and special launchpad servers
<jam> jelmer: the twisted stuff?
<jelmer> jam: yeah
<jam> jelmer: it is a bit tricky to dig in. For some reason Twisted is breaking cProfile/lsprof linking
<jam> so you see "A called B", but a *different* "B' called C"
<jam> works ok in text mode, but KCacheGrind doesn't give nice graphs
<jam> jelmer: I originally wasn't sure how much to pull on this, but it certainly yielded some interesting results
<jelmer> jam: Yeah, indeed. It looks like there is a lot of time to be gained here.
<jam> 30ms local operation becoming 500ms seemed like something worth poking at
<bialix> jam: thanks
<CaMason> can a bzr branch operate/exist without a working copy?
<CaMason> ah `bzr remove-tree`
<jelmer> yep
<jelmer> or, if you didn't want to create the tree in the first place: bzr branch --no-tree
#bzr 2011-03-29
<vila> hi all 1
<vila> every 1 ? :-/
<jam> morning vila
<jam> I'm actually 2, today
<jam> :)
<vila> :)
<spiv> vila: hi :)
<jam> hey spiv
<spiv> jam: I just made lp:~spiv/twisted/deferred-no-failure-tracebacks-by-default
<spiv> jam: the existing benchmarks on http://speed.twistedmatrix.com/ don't really exercise this case at all, so I'll probably try make one
<jam> spiv: you need a reasonable amount of state, which is probably the big 'bug'
<spiv> Right
<jam> because it scales based on your working depth, etc
<jam> which means isolated testing probably is quite fast
<spiv> I'd be interested to know how much that patch helps
<jam> but real-world use is bad
<jam> spiv: the proxy patch?
<spiv> Well, that one too :)
<jam> ah ^^
<spiv> But my patch to Twisted as well
<jam> I missed the link
<spiv> Because there's the odd spot (like t.w.xmlrpc.Proxy) that creates these Failures directly it might have less impact than hacking self.tb = None in Failure
<spiv> But maybe it's almost all of the cases we care about?  If it's not too much effort for you to test, please do :)
<jam> spiv: from all the discussions I've read on the bug, and grepping through the codebase, the tracebacks are pretty much never used
<jam> there is failure.printTraceback which only has 1 or 2 callsights
<jam> site
<jam> jelmer: feel better, buddy
<spiv> jam: right, I think so
<spiv> jam: although I expect e.g. unhandled errors in a deferred chain emit them
<spiv> jam: that's probably the most common case, and I think they'd probably be valuable there :/
<jam> spiv: I think they would be, but I also wonder if we could just leave 'self.tb' and not try to actually walk it
<spiv> jam: people using twisted often find it hard enough to track down where those are coming from as it is
<jam> I realize some global state may change, but is it enough to warrant?
<jam> spiv: I think an env var sort-of-thing is ideal here
<spiv> Leaving self.tb is probably a bad idea, because it basically is a memory leak
<jam> spiv: well ATM it leaves it until __getstate__ which seems ~ok
<jam> or the issue there is that __getstate__ happens before the traceback could be printed?
<jam> (because it has no errbacks ?)
<spiv> Well, when Deferred handles Failures it cleans them before leaving _runCallbacks
<spiv> So it at least avoids the expensive cleanFailure logic if there's another callback in the chain about to be run, because it might handle that failure (and turn the result back to a non-failure)
<spiv> We're especially badly hit I think
<jam> spiv: initial branch of your stacked branch was very unhappy. Lots of time in Repo.get_parent_map(). I killed it after 115s, and 'bzr branch lp:twisted' completed in 86s.
<jam> we should definitely look into that
<spiv> Because the codehosting VFS code is mostly building an async API on a sync API
<jam> sure
<spiv> So the common "d = getSomeDeferred(); d.addCallback(â¦); d.addErrback(â¦)" pattern will hit cleanFailure every time, because there's a result immediately
<jam> and since everything returns immediately, deferred has nobody to call
<spiv> Right
<spiv> jam: ouch, and weird
<spiv> jam: I guess keep the .bzr.log of that and we can look into it later
<spiv> Anyway, it's EOD for me
<spiv> Hopefully I've given you some stuff worth playing with :)
 * spiv -> afk
<spiv> Happy hacking!
<jam> spiv: have a good night
<lifeless> jelmer: typo in dulwich
<lifeless>         of head, then following theat will be the parents.
<bialix> hi
<bialix> I want to talk about very strange behavior of bzr in mixed windows/linux environment
<bialix> if I push from repository branch to other machine (different OS) then I got on the destination end repository branch with shared repository in the same directory where new branch created
<bialix> if I push from standalone branch then I got standalone branch on destination end
<bialix> it seems to not depend on whether I have on destination end real shared repo or not
<bialix> no, it depends
<bialix> sorry
<bialix> if destination end has no shared repository then I got this strange effect
<bialix> Bug #744893
<ubot5> Launchpad bug 744893 in Bazaar "bzr push from repository branch to location without shared repo creates weird sharedrepo+branch" [Undecided,New] https://launchpad.net/bugs/744893
<etenil> Hi there
<etenil> I created a tag in my branch, and when I try pushing it on my repo, nothing happens, it says "nothing to push". Am I doing something wrong?
<maxb> etenil: I think it will have pushed the tag anyway, but the message it gives only reports on revisions
<glob> greeting all; every time i commit to a bzr repo, i get a 'math range error'...
<glob> bzr: ERROR: Server sent an unexpected error: ('error', 'math range error')
<glob> however the commit is successful
<glob> local bzr is out of sync, and requires a 'bzr up' to make it happy again
<idky> Is there some way to use "vim -R -" as a default pager for `bzr diff`?
<etenil> maxb: ah thanks
<etenil> I'll make sure it has
<Kamping_Kaiser> idky: is that like 'view'?
<idky> Kamping_Kaiser: pretty much
<Kamping_Kaiser> bzr accepts PAGER=, but i dont think pAGER supports '-' in its commandlines
<Kamping_Kaiser> bzr-pager (the plugin) appears to hard code less as the pager value, so not sure how that works with PAGER either
<idky> Kamping_Kaiser: I just enter `bzr PAGER='view -'` then?
<Kamping_Kaiser> no, "PAGER='view -' bzr diff" causes bzr to throw up since it thinks it should read from stdin (over the -), not sure what the fix to that is.
<Kamping_Kaiser> but i will be interested to see what someone else says as the fix
<Kamping_Kaiser> i'm off to bed, i'll read up tomorrow :)
<Kamping_Kaiser> 'later all
<spiv> glob: wow, I'd love to see the server's log of that
<glob> i've asked the admin to eyeball the log, i don't have access
<spiv> glob: can you add '-Dhpss' to your command line to enable some more logging, and attach the resulting ~/.bzr.log to a bug report?
<spiv> glob: (and add anything you are able to discover about the server log)
<glob> ok, will do (net time i have to commit, it's a prod instance)
<glob> thanks :)
<spiv> glob: thanks
<spiv> glob: it'd also be good to know which version of bzr the server is running
<spiv> glob: (you can find out using the bzr-ping plugin from https://launchpad.net/bzr-ping if you don't know)
<glob> spiv, 2.3.1
 * jelmer waves
<jam> hi jelmer, feeling better?
<jelmer> jam: Yeah, much better. Still have a lingering headache so I think I'm going to do some trivial stuff that doesn't require much thought.
<knighthawk> is *anyone* using bzr-svn on Fedora? it seems *way* too hard to set up.
<jelmer> knighthawk: hi
<jelmer> knighthawk: it's not packaged?
<knighthawk> jelmer, I haven't been able to find one.
<jelmer> hmm, whohas doesn't report any either
<jelmer> knighthawk: isn't it just a matter of installing bzr and python-subvertpy and then just unpacking the tarball as ~/.bazaar/plugins/svn ?
<knighthawk> took out a branch. had to revert it then install docutils. now trying to install Subvertpy which doesn't have a rpm yet.
<knighthawk> so far can't install python-subvertpy
<knighthawk> found a src.rpm but running into an issue with rpmbuild on it.
<jelmer> centos apparently has packages
<jelmer> http://pkgs.org/package/python-subvertpy
<knighthawk> the weird thing is that make and make install seemed to work fine *without* subvertpy. but of course when I then tried to use it...
<knighthawk> thanks jelmer
<vanguard> I would like to push to a plain FTP, but it fails because of "Append/Restart not permitted". What can I do?
 * knighthawk hoping that I can run a centos rpm on a fedora 14 box
<knighthawk> trying to work with bzr-svn with a self signed certificate. don't know how to tell it to ignore the face that the certificate is self signed.
<jelmer> knighthawk: what error are you getting?
<knighthawk> ERROR: pycurl.error: (60, 'SSL certificate problem, verify that the CA cert is OK.
<jelmer> knighthawk: try using svn+https://
<knighthawk> will do jelmer thanks.
<knighthawk> thanks jelmer
<jelmer> you're welcome
 * jelmer gets some sleep
#bzr 2011-03-30
<yeban> what would be the bzr equivalent of 'git show'
<bob2> bzr diff -c asdfasdf
<bob2> for the common case
<yeban> bob2: I want to see the state of one particular file for a revision
<yeban> i did not know about -c though, thanks :)
<bob2> bzr cat -c asdfsd filename
<spiv> Bugs like bug 745083 are why I wanted to have catch-all try/excepts around calls to hooks on plugins.
<ubot5> Launchpad bug 745083 in Bazaar "UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'math range error') during commit" [Undecided,Incomplete] https://launchpad.net/bugs/745083
<yeban> bob2: its bzr cat -r not -c, thanks :)
<bob2> oops
<spiv> Yes, it would be a bit weird if 'bzr cat' took a revision range :)
<psusi> I just had a stuck lock on lp.  bzr help break-lock makes it sound like it is not safe if you don't first kill the process, but I can't do that on lp.  Is it safe, or not?
<spiv> psusi: the process that matters isn't the one on lp, but the client that took out the lock
<spiv> psusi: so if it's a stale lock because e.g. your connection dropped out while pushing to launchpad, then it's your own lock for a (local) process that's already failed, and you can break it completely safely.
<spiv> psusi: the lock info bzr shows you should help you see who took the lock out
<psusi> spiv, ohh... well I took it out, but on the lp server... I thought that meant that the bzr process running on the server is what was holding the lock, and it either is hung, or did not remove the lock when it died
<psusi> it lists a pid, which I took to be a pid on the server, not a local one
<spiv> psusi: in a sense the lock was created by the server process, but it's entirely on behalf of your local process
<spiv> (The pid is a pid from the server)
<psusi> spiv, right, but it is the server process that creates and clears the lock, so don't I need to be sure that process is dead?
<psusi> in fact, whether the process hung or somehow exited without clearing the lock is a bug isn't it?  even if I drop connection or ctrl-c my local bzr, the server side should clean up the lock before exiting shouldn't it?
<spiv> psusi: the lock lifetime is controlled by the client
<spiv> psusi: it can be legitimate for a client to lock and disconnect without unlocking
<spiv> (although that would be very unusual)
<spiv> psusi: the smart server protocol is stateless between requests, so the fact the connection went away doesn't imply that any locks that were taken should be dropped.
<psusi> hrm... that's weird
<psusi> why is it stateless?  I would think the protocol should be transaction based
<spiv> Partly so it can be carried over HTTP smoothly.
<psusi> why is http at all incompatible with a transaction based protocol?  send request, get reply is how http works... seems perfectly suited for a transaction
<spiv> And that's what we do.
<spiv> "Take lock" is one of those requests.
<spiv> The problem really is that we take multiple requests for things that in principle could be done in single requests.
<spiv> If you're curious about the sort of requests being made, add -Dhpss to your command line and look at the extra logging that adds to ~/.bzr.log
<jbowtie> So, I occasionally have an issue where revisions being imported from my external(tfs) repository end up as dead heads in the repository.
<jbowtie> I've tracked down and eliminated most of bugs in bzr-tfs that cause these.
<jbowtie> However, I have a (very large) existing repository where I need to splice in a single revision where it belongs in the branch history.
<jbowtie> I might be able to get away with merging it into the current branch, the plugin just follows the LHS currently as it only imports a single branch.
<jbowtie> What's the preferred method for dealing with dead heads in a way that won't affect the LHS ancestry?
<lifeless> ignore them?
<jbowtie> Most of the time I can get away with that, but not in this instance.
<jbowtie> I was thinking about trying to actually insert it into the revision graph for the branch, but worried that might have evil side effects.
<jbowtie> If I actually corrupt the repository I'm looking at working the whole weekend to re-import the trunk. Don't want that.
<ScottK> Make a backup copy first?
<jbowtie> ScottK: I can do that, I was just hoping someone had an informed opinion before I started doing open-heart repository surgery.  :)
<ScottK> My informed opinion is take a backup no matter what anyone says here about what your odds of success are.
<ScottK> About the bzr part, no idea.
<spiv> I don't understand how or why "splice in a single revision where it belongs in the branch history" is related to having dead heads in your repository.
<spiv> Or why you can't just ignore the dead heads?  By definition they have no impact of the ancestry, LHS or otherwise, of a branch.
<spiv> I think I must be misunderstanding what you're asking.
<jbowtie> spiv: so the actual revision graph is r1->r2->r3; the bug in the import process created the graph r1->r3 and r2 ends up as a dead head.
<jbowtie> spiv: I'm in the position where I want to correct the revision graph by hand.
<jbowtie> I could re-run the (now fixed) import process but that's a days-long affair.
<spiv> Well, all you can do there is generate a new r3', with a new revision ID, with the contents of r3 and a parent of r2.
<jbowtie> In other words, a merge, yes?
<spiv> No, just a regular descendant.
<spiv> i.e. r3' would have a parent list of [r2] to match the graph you desire.
<spiv> Merges create revisions with more than one parent.
<poolie> hooray
 * poolie is reconnected
<spiv> poolie: hurrah!
<poolie> only over 3G, but usable 3G
<poolie> vodafone was atrocious
<jbowtie> Oh, I see the difference. That ends up rebuilding the whole branch after r3 as well, though. Still, it's at least viable.
<poolie> i wonder if bzr push will be tolerable
<spiv> jbowtie: yes, it's rebasing
<jbowtie> Oh!  I never understood what rebasing was before! Now I get it!
<jbowtie> So maybe bzr-rewrite will solve my problem.  Thanks, this was extremely helpful.
<spiv> jbowtie: glad I could help :)
<poolie> wow, even lp and bzr are quite usable
<poolie> that's a remarkable improvement
<poolie> heh :)
<poolie> spiv were you going to file a bug about, um
<poolie> oh, explaining the likely hook or plugin for an error
<poolie> and something else too?
<spiv> The 'recent event' dict
<echo-area> "bzr merge -r b..a branch" (a < b) may result in unresolvable conflict on changed files between revisions a and b.  Is this desired?
<spiv> echo-area: what do you mean by "unresolvable conflict"?
<echo-area> spiv: I tried many ways, all of them failed to resolve the conflicts.
<spiv> From bzr's perspective all conflicts are resolvable, in the extreme by discarding the conflicting changes entirely with e.g. "bzr revert ."
<spiv> echo-area: can you pastebin the output of the bzr merge, or of 'bzr conflicts'?
<echo-area> spiv: The only way to resolve is by reverting all changes, and avoiding use of bzr merge.  A moment please, I'll show you bzr conflicts
<echo-area> spiv: http://pastebin.com/4X4g2RSM
<echo-area> spiv: Problem is that, file1 was added in revision 1, and bzr merge -r 1..0 tries to delete file1.
<echo-area> The conflict comes from revision 3, in which revision file1 was changed
<echo-area> (IMHO)
<echo-area> The only way to achieve what I want is to manually remove file1.  While in larger context this is not that handy
<spiv> echo-area: revert is not the only way to resolve that conflict
<echo-area> spiv: What is the other possible way?
<spiv> echo-area: it's certainly a conflict if the selected revisions attempt to modify a deleted file.
<spiv> echo-area: it's up to you what you think is the right resolution: the most common choice I think is to ignore the changes to the deleted file.
<echo-area> spiv: I tried that.  Paste come in a minute.
<spiv> In which case deleting that file1.THIS file and doing 'bzr resolve file1' or maybe 'bzr resolve file1.THIS' should work.
<spiv> Or even just 'bzr resolved --all'
<spiv> There's also 'bzr resolve --take-this' and 'bzr resolve --take-other', which you may find useful.
<vila> <cough> 'bzr resolve --all' is evil, it just deletes all known conflicts without any attempt to resolve them, it should be used as a last resort only (think throwing sea water on nuclear plants)
 * vila almost there
<spiv> vila: if that's what it takes to stop a meltdownâ¦ ;)
<echo-area> spiv: Hm.  Delete file1 and bzr resolve file1 worked.  Why does "bzr resolve" not work in that context?
<spiv> 'bzr resolve' only detects when you've resolved text conflicts (i.e. removed the <<<<<<< etc markers from a file)
<spiv> I think it'd probably be good to make it detect when contents conflicts like yours are resolved too.  File a bug :)
<vila> echo-area: 'bzr resolve' doesn't *yet* work in this context, as spiv said, only text conflicts are automatically resolved
<spiv> FWIW, "bzr help resolve" does explicitly say to use 'bzr resolve FILE' for contents conflicts, but I agree it's not very intuitive.
<vila> echo-area: 'bzr help conflict-types' gives a summary of what is supported so far
<echo-area> Okay.  I was unaware of various conflict types until now.
<spiv> Yes, the distinction between "contents conflict" and "text conflict" is something you're unlikely to grok just by seeing the words in your terminal occasionally.
<vila> echo-area: yeah, that's a bug, the conflicts should be better explained and these explanations should be easier to discover
<echo-area> spiv: But the bzr I'm using (2.3.1) does not explicit refer "content conflict" in bzr help resolve
<vila> echo-area: 'bzr help conflict-types' does
<spiv> Maybe "contents conflict" should be called "existential conflict" ;)
<spiv> echo-area: ah right, yes, in trunk too
<vila> 'content' is this context refers to an internal pov and is misleading for users
<spiv> echo-area: my mistake, although you could argue it implicitly suggests that.
<echo-area> vila: Reading that.  I was replying to spiv's message
<vila> echo-area: sure, no worries
<echo-area> Maybe we can make an explicit note on this in the user guide.  I'll try to make a patch later
<vila> echo-area: highly welcome !
<spiv> echo-area: that'd be wonderful, thank you
<vila> echo-area: see also http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution for what is cooking in this area
<echo-area> Okay
<vila> hmm, yeah, re-reading that, 'content conflict' may be better understood if it was named 'tree shape conflict'
<vila> that is, the merged trees disagree about an object kind: deleted, file, dir, symlink
<spiv> vila: or "file kind conflict"?
<spiv> vila: that's a bit less jargony
<spiv> vila: or, hmm
<spiv> vila: file/dir/symlink, that's "kind conflict", but deleted vs. modified is "status conflict"?
<spiv> vila: I think that's pretty consistent both with our internal terminology and the terms we expose to users at other times.
<vila> valentine : under his shower, will coming soon :)
<vila> :-D
<vila> spiv: well, IMHO, what is consistent is that most of our users are saying: 'wtf is a content conflict' :-)
<vila> but yeah, separating kind conflict and status conflict seems like a good idea
<spiv> vila: hehe
<spiv> vila: ok, I'll file a bug
<vila> the main issue is in the implementation which is hard to modify (see url above for some explanations)
<spiv> *nod*
<spiv> vila: filed https://bugs.launchpad.net/bzr/+bug/745491, please elaborate or disagree as you see fit :)
<ubot5> Ubuntu bug 745491 in Bazaar "âContents conflictâ is unclear to users, replace with âkind conflictâ and âstatus conflictâ" [High,Confirmed]
<spiv> echo-area: you may be interested in that proposal too (bug 745491), I'd be interested to hear if you think it would have helped you
<ubot5> Launchpad bug 745491 in Bazaar "âContents conflictâ is unclear to users, replace with âkind conflictâ and âstatus conflictâ" [High,Confirmed] https://launchpad.net/bugs/745491
<spiv> ubot5: yes yes we know
<echo-area> spiv: Okay, I'll follow that.
 * jelmer waves
<vila> spiv: done
<vila> jelmer: \o/ feeling better ?
<jelmer> vila: yup, thanks
<jelmer> vila: do you know if we're mumbling this morning?
<vila> jelmer: no, but given that poolie uses a 3G connection, I doubt he can mumble
<jelmer> ah, good point
<spiv> jelmer, vila: yes
<spiv> jelmer, vila: but skype, and we call poolie on pots
 * spiv -> afk
 * vila has no skype setup :-/
 * jelmer dusts off his skype setup
<echo-area> xb
 * vila finally remembered his skype login
 * jelmer waves to poolie
<jelmer> vila: for when do you have b2 planned?
<vila> jelmer: I keep the release dates up to date on lp, so: 2011-04-28 from https://launchpad.net/bzr/2.4
<vila> well, I *try* to keep them up-to-date ;)
<vila> jelmer, maxb : the ppa:bzr/beta needs love ;)
<vila> oh wait, I already said that in the topic ;-D
<maxb> yeah
<jelmer> vila: thanks
<maxb> I was actually just contemplating my notional compatibility layer for painless dh_python2 rebuilds for older series
<maxb> I think I've got an idea which should work:
<maxb> Rebuild python-defaults with 2.6.6-3really2.6.4-0ubuntu1 etc. versions, whilst adding a Depends: python-backport-helper
<maxb> Create a new package python-backport-helper which Depends: python-support, python-central, and installs a fake dh_python2
<maxb> Embed a table in the p-b-h package which maps sourcepackagenames to pysupport or pycentral following what they currently do, to avoid unnecessary transitions
<maxb> I think I'll have a go at implementing what I just said at lunch today
<jo-erlend> I have a project directory like /home/jo-erlend/devel/Projectname where my sourcecode resides. This thing about branches, how does that work? Should I move my files into a subdirectory like ~/devel/Project/trunk and work on the code from there and push to ~/devel/Project/1.0 when I reach the first major version, for instance?
<jo-erlend> as you can understand, I'm quite the beginner with this VCS thing. :)
<maxb> jo-erlend: In Bazaar, branches are modelled as separate directories on disk. So, yes, a .../trunk directory is a very reasonable thing to have if you expect to have multiple project branches side by side. However, marking versions seldom merits a whole new branch - there is a separate concept of tags for that.
<maxb> You can always branch from a tag later, if there is a need to create a maintenance branch for a released version
<jo-erlend> oh, ok. Then a tag is just a way to emphasize a commit?
<mr-russ1> tags have a danger on bzr at the moment, you can't push them if you delete them.
<jo-erlend> I didn't really understand that.
<mr-russ> jo-erlend: I would setup a shared-repository in ~/devel/Projectname and create a branch called trunk under that.
<mr-russ> jo-erlend: are you going to have a central storage location for your code, or just work from your home directory?
<jo-erlend> it's just me for now, but I'd like to be able to invite others later, if they're interested.
<mr-russ> I just added the following to bzr 2.4 docs.  http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/simple-setups.html?highlight=ssh%20restrict#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories
<mr-russ> that's how I have a setup others can use.
<mr-russ> but to start with a single branch setup.
<mr-russ> in your code folder, bzr init
<mr-russ> bzr add
<mr-russ> bzr commit
<mr-russ> .. code away ...
<mr-russ> bzr commit
<mr-russ> and you are using the revision control.
<poolie> hi mr-russ
<mr-russ> hi poolie.
<mr-russ> semi disturbingly, I'm starting to feel part of the family.
<mr-russ> just to work out how and if I could work for canonical...  Not programming python though.  I know zero python.
<jo-erlend> mr-russ: hmm. I'm reading a "mini-tutorial" on doc.bazaar.c-c and it sais something about a "saved parent location". Where is that set?
<jo-erlend> perhaps that's just the location I branched from?
<mr-russ> you don't need a parent, or saved parent.
<mr-russ> But it is where you branched from.
<poolie> knowing python helps
<poolie> but, ubuntu.com/employment :)
<poolie> jelmer, hi?
<poolie> o/ Riddell
<jo-erlend> ok. bzr stores diffs for text files, yes? What about binaries and other stuff that can't be diffed, does it make copies of those?
<Riddell> hi all
<poolie> jo-erlend, they're all stored using a binary diff format
<poolie> at that level, it doesn't care if they're text or not
<jo-erlend> hmm. Ok. So if I wanted, I could set my whole home directory under version control so I could skip back if I did something stupid?
<mr-russ> yes.
<poolie> yep
<poolie> but, a specific backup tool may be better
<poolie> i like duplicity and rdiff-backup
<jelmer> poolie: hi
<poolie> hey, jelmer
<poolie> i was just wondering if you had registered sessions for bzr at uds
<jelmer> not yet, I saw Alisons email earlier but hadn't figured out how to name the blueprints etc yet
<poolie> mm
<poolie> there is some scheme but i don't remember it, and for that matter it may have changed
<poolie> dholbach could probably help
<jelmer> I'll ask him - thanks for the reminder.
<poolie> np, thanks for doing it
<poolie> jelmer, can i just ask your bzr-colo recipe to build for maverick too?
<poolie> well, i _can_; will it break things though?
<jelmer> poolie: I'm not sure if it will work, as it uses dh_python2
<jelmer> poolie: dh_python2 is only available on natty I think, and we've disabled most other builds for maverick because the debian packages require dh_python2 at the moment. maxb has a plan on how to deal with this.
<poolie> ah, ok
<poolie> i should upgrade my laptop soon anyhow
<spiv> jam: hey, I've got an updated patch for Twisted, just running tests again before I push
<maxb> I intend to try to put that plan into practice today
<spiv> jam: it adds a noVars param Failure, so you still get tracebacks with files, line numbers and lines, but skips the locals and globals work.  It's about 10x faster rather than 16x on my crude benchmark, but is probably a good compromise.
<spiv> jam: stripping tracebacks entirely in maybeDeferred was starting to have wider test suite fallout in Twisted, mainly in Trial, but tracebacks are clearly desireable there :)
<spiv> jam: it's actually overall faster at running Twisted's tests than my original patch, presumably because it does fix maybeDeferred too
<spiv> jam: woah
<spiv> jam: I think I just saw that intermittent push issue you had, where the client spends ages doing get_parent_map rather than pushing
<spiv> Wow, that's weird, it's getting NotStacked back for my branch from the lp smart server
<spiv> But http://bazaar.launchpad.net/~spiv/twisted/deferred-no-failure-tracebacks-by-default/.bzr/branch/branch.conf looks pretty stacked to me!
<spiv> Oh, no, I just can't read a -Dhpss log, ignore me.
<spiv> I don't know why it's not working, though.
<poolie> bug pls :)
 * spiv works around it for right now
<spiv> poolie: yeah, definitely
<jam> spiv: it was 'bzr branch lp:a-stacked-branch' rather than getting the dev focus first
<jam> spiv: I was just starting to write some test cases, and found a few more edges
<jam> like "deferred.errback()" defaults to fail=None ,which calls Failure(none), which would also create a traceback
<jam> etc
<jam> spiv: so I'm happy to wait for wherever you want to leave off
<jam> I was a bit surprised to see "twisted.test.test_defer" rather than "twisted.internet.test.test_defer"
<spiv> jam: see my update to http://twistedmatrix.com/trac/ticket/5011
<spiv> jam: partly that's because originally there was only twisted.test, so old stuff tends to be tested in there
<jam> sure
<jam> I think the 16x vs 10x matches what I saw
<spiv> jam: and partly because defer.py really belongs in twisted.python not twisted.internet
<jam> where commenting out __getstate__ had a good benefit
<jam> but there was almost as much to be gained by not walking the frames in the first place
<jam> spiv: in which case Failure could depend on it :)
<spiv> I found on my crude benchmark I could squeeze out a few more percent by aggressively avoiding repeated x.y in Failure.__init__, etc.
<spiv> Which is a good sign, it suggests it's fast enough now for that sort of thing to be significant :)
<jam> sure
<spiv> jam: it would still be backwards, layering-wise
<jam> well, it is a debug flag
<jam> which should probably sit a lot higher than Deferred.debug
<spiv> Well, capturing more info in Deferreds is different to capturing more info everywhere
<jam> spiv: not if you are writing real twisted code :)
<spiv> Failures are sometimes used entirely outside the context of Deferreds
<jam> since Deferreds are everywhere
<spiv> e.g. the 'reason' param of connectionLost
<spiv> Deferreds only provide a way to do one-shot async calls
<jam> spiv: where, again, it doesn't really make sense to include a traceback
<spiv> jam: I agree
<spiv> jam: I don't think capturing that info is a good default
<spiv> But it's been the default for probably most of the lifetime of Twisted
<spiv> Which is over a decade old now
<spiv> So I think changing that default probably needs to be done cautiously to make sure it doesn't break people's code; Twisted is much pickier about backwards compatibility than most projects.
 * spiv -> dinner
<poolie> i wonder if we have any overall data on connection time
<jam> poolie: define overall data?
<jam> (we might have some information in the access logs, etc., but I'm not really sure what you are looking for)
<poolie> sorry, i meant, connection time 3 months ago vs now
<poolie> to lp
<jam> poolie: you mean other than the bzr ping graphs?
<poolie> ideally something measured from the real world
<poolie> i wonder if i filed that bug long enough ago to be useful
 * jam really is pleased with perf boost to lpstats
<jam> poolie: I wonder about just enabling 'debug_flags = hpss' on production, since the logs I've looked at give some really nice debug info
<jam> might be too big of a flood for real world, though
<jam> poolie: https://lpstats.canonical.com/graphs/CodehostingPerformance/20100331/20110331/
<jam> definitely shows it has been trending down recently
<jam> well very short term back up
<jam> but quite a bit down from last may
<spiv> jam: and less variable too, which is nice
<poolie> don't know if there's a very distinct trend
<poolie> i guess if you said "the worst experienced lag" that's gone from 7 to 4
<poolie> in what, seconds? really seconds?
<jam> poolie: yes, really 7+s just to get an ssh connection
<poolie> that's remarkable
<poolie> i would have guessed more of it was rtt
<poolie> so what else did we get done this calendar year that was good?
<AfC> time bzr missing bzr://... 0m3.042s
<jam> poolie: If I can get this rolled out into production: https://lpstats.canonical.com/graphs/CodehostingPerformanceStaging/20110101/20110331/
<AfC> time bzr missing bzr+ssh://... 0m6.747s
<jam> AfC: 'time ssh /bin/false' ?
<AfC> jam: 0m3.357s as expected
<jam> AfC: this is with openssh on both sides?
<AfC> yes
<jam> One interesting bit is that the twisted ssh service can actually connect faster than openssh
<jam> not sure the specific reasons
<jam> I know at one point ssh switched the default to do reverse dns lookups
<jam> and that made it a *lot* slower when the source didn't have a dns entry
<jam> because it would wait 2s to timeout, etc.
<poolie> mm
<poolie> it would be horrible if that's live
<jam> AfC: http://ubuntuforums.org/showthread.php?t=445677
<poolie> probably not
<jam> "UseDNS no"
<jam> Also "GSSAPIAuthentication No"
<jam> so it doesn't try to look up kerberos credentials
<AfC> jam: yeah, I'm across that one
<AfC> (wasn't complaining, just offering a few data points; I have bzr: and bzr+ssh: on the same trees)
<jam> AfC, poolie: "time ssh localhost /bin/false" is about 800-900ms here
<AfC> really? 0.310 Â± 0.040 here
<jam> Using '-v' seems to say the bulk of the time is right after: http://ubuntuforums.org/showthread.php?t=445677
<jam> ugh
<jam> debug1: Entering interactive session.
<jam> At least, that is where the terminal hangs for a bit before going to the next message
<spiv> poolie: earlier this year we installed python-gmpy on the codehosting server, speeding up Twisted's SSH crypto
<jam> spiv: after we fixed it not to bork the rest of the system :)
<jam> well, afterwards we fixed it :)
<jam> poolie: this is the list you are compiling for s-tatik?
<poolie> yup
<jam> poolie: loggerhead is now mostly actively maintained
<jam> poolie: package importer improvements. Quite a few big "100 packages no longer failing" etc.
<jam> looking here: http://package-import.ubuntu.com/status/
<jam> I see we're down to 476 failures, from a peak of ~3k
<jam> in mid January
<jam> AfC: well, technically that is a VM, since I don't yet run opensshd on my laptop directly.
<AfC> â zzz
<jam> poolie: my 'iter_entries_by_dir' change makes 'bzr co --lightweight gcc-linaro' go from 3m48s down to 1m5s on Ubuntu for me.
<jam> poolie: spiv's change to make 'fetch' transfer the revisions associated with tags
<poolie> nice
<thrope> when I try to bzr init in a directory on an ntfs partition mounted on linux I get a ERROR: Transport error: [Errno 1] Operation not permitted
<thrope> it is mounted in latest ubuntu with fuse
<thrope> so I can't use bzr over an smb mounted drive OR on a locally mounted ntfs drive
<jelmer> thrope: I think the number of system calls the fuse smb file system allows is pretty limited.
<jelmer> Have you tried with the kernel one?
<thrope> no
<thrope> don't want to mess about with it really - just using standard ubuntu settings
<thrope> just surprised to find another not that unusual situation where bzr fails completely and ungracefully
<poolie> there's a bug for it, which may have a workaround
<poolie> but, really it's a fuse bug
<poolie> thrope, https://bugs.launchpad.net/bzr/+bug/190725
<ubot5> Ubuntu bug 190725 in Bazaar "Bzr can't init branch on ntfs-3g filesystem" [Medium,Confirmed]
<idky> Did I see that correctly that one can write python scripts using a bazaar repo very easily?
<poolie> night all
<jelmer> idky: yep, it's fairly easy
<jelmer> g'night poolie
<idky> jelmer: hmm, that is another thing that makes me tend to bzr instead of git ... why are these decisions so hard? :)
<idky> and is there a way to put the output of diff or cdiff into a pager automatically?
<jelmer> idky: there's a bzr-pager plugin that can do that
<jml> hey
<jml> I think this bug is fixed
<jml> https://bugs.launchpad.net/bzr/+bug/301472
<ubot5> Ubuntu bug 301472 in Bazaar "need a way to uninstall a hook" [Low,Confirmed]
<jml> is it fixed?
<jml> hmm. maybe not.
<jml> what a pity
<jelmer> hmm
<jelmer> I'm hacking on hooks at the moment, might as well have a look at that one too
<jelmer> jml: would that help you?
<jml> jelmer: yeah, but only a little. there's a legacy monkey patch in lp/codehosting/__init__ that I'd like to remove.
<jml> (I had thought I could because it said "bzr 1.14" in the comments, but now I'm confused)
<jelmer> jml: I don't see any other way to uninstall hooks. Perhaps a patch was proposed but it never made it in?
<jelmer> Anyway, I'll have a look at adding an uninstall function.
<jml> jelmer: I think in bzr 1.13, Branch.hooks was a list, not a HookPoint
<jml> jelmer: so the way to remove hooks was to call 'remove' on that list.
<jml> and when we upgraded, we did the monkey-patch presumably to avoid the break in API as well as provide the now-missing functionality.
<jelmer> ahh
<spiv> Our test suite resets hook registrations between tests
<spiv> jam: I'd love to know why my second pushes to lp:~spiv/twisted/* branches are repushing all of history!
<spiv> i.e. push new branch, stacked and fine.  Commit again, push: find all the ancestry missing and push it all.
 * spiv tries with bzr 2.3
<spiv> That worked.  Regression :(
<jam> spiv: ouch. I wonder if it is something with the lp: redirect biting us again?
<spiv> jam: not sure, and it's too late in my night for me to find out
<spiv> jam: https://bugs.launchpad.net/bzr/+bug/745664
<ubot5> Ubuntu bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed]
<jelmer> jml: https://code.launchpad.net/~jelmer/bzr/uninstall-hook/+merge/55527
<jml> it looks as if Twisted can't use bzr-svn to maintain a mirror any more
<jml> because it requires more than 600MB of memory to do a pull
<jml> and they don't have that much on their servers
<jelmer> jml: Whoa; is the tree really that big?
<jelmer> and this is just an incremental pull?
<jml> jelmer: the history is pretty old
<jml> jelmer: not sure about the tree size...
<jml> /usr/bin/bzr svn-import -v --incremental
<jelmer> ah, svn-import
<jml> should they be doing something else?
<jml> oh, I guess that's a multi-branch thing
<jelmer> I was thinking bzr pull. there's a known issue with svn-import and memory usage that I still need to look into
<jelmer> perhaps this is a good excuse to..
<jml> jelmer: is there a bug number that I can point the Twisted folk at?
<jelmer> jml: bug 516999 IIRC
<ubot5> Launchpad bug 516999 in Bazaar Subversion Plugin ""Finding branches" step takes waaay too much memory" [High,Triaged] https://launchpad.net/bugs/516999
<jml> jelmer: thanks.
<jelmer> vila: hi
<vila> jelmer: pong ;)
<jelmer> vila: just looking at your devnote on configuration files
 * vila nods and fix more typos :)
<jelmer> vila: some of the bullet points at the bottom don't seem to be formatted properly
<vila> jelmer: I fixed some, try refreshing ?
<vila> argh, silly me, looking at my local copy ;-/
<jelmer> Under "user facing concepts"
<jelmer> and under "stack examples"
<jelmer> ah :)
<jelmer> vila: the sheer number of configuration files worries me a bit
<vila> jelmer: yup, fixed both
<vila> jelmer: well, have a look at the number of IOs we do today then ;)
<jelmer> I'm not entirely sure what to do about that; it seems like adding a project and a organization configuration file requires a particular workflow
<jelmer> vila: not just the performance, but also what it does to our UI
<vila> jelmer: that's one read per option, I want to reach one read by config file (lazily triggered on first read)
<vila> right, we'll have to dig into specifics then, we will be able to merge some plugin conf files into the existing ones
<jelmer> vila: when you say organization configuration file do you mean a system wide configuration file?
<vila> locations.conf is mostly used to defined defaults today, this feature will be supported by bazaar.conf itself
<vila> jelmer: yes, it could be /etc/bzr/xxx.conf
<vila> jelmer: but more precisely, *what* are you worries there ?
<jelmer> vila: something like /etc/bzr/bazaar.conf ?
<vila> yup
<jelmer> vila: or also /etc/bzr/canonical.conf ?
<jelmer> or /etc/bzr/samba.conf ?
<vila> hmm, I was thinking /etc/bzr/bazaar.conf
<vila> you could define samba.policy.* options there
 * fullermd . o O (/usr/local/etc...)
<jelmer> vila: In that case I think the naming in the devnote is a bit confusing
<vila> nothing definite there which may explain the confusion :)
<jelmer> vila: I think system configuration rather than organization configuration explains it a bit better, at least to me :)
<jelmer> vila: How would the project be defined for the project configuration?
<vila> both should addressed, I'm still not clear about the best way to dispatch options in files
<vila> not sure either about repoconf vs project.conf, many questions are related to the way these files are (or not) versioned and how they propagate
<vila> but I don't try to address that yet
<jelmer> vila: That's the main thing I noticed that is a bit worrying, looks like a great improvement over the current unclear system otherwise.
 * vila nods
<vila> So you're worrying about having too many files too put one option into ?
<vila> My main reaction was to write 'bzr config' and I now use it more than 'bzr info'...
<jelmer> vila: that (which makes it hard/confusing to decide which file to put the option into) and forcing a particular workflow on the user with a project.conf, where we don't have the concept of a project
<vila> ha, right
<jelmer> though since your concept of project is still a bit vague I'm not sure about that second objection
<vila> So, I separated read and write very explicitly because writing an option from bzrlib is the exception
<vila> The whole framework is targeted at allowing a user to specify defaults values where *he* see fit
<vila> and avoid having to duplicate such settings all over the place
<vila> project.conf is still nebulous, the idea is that you could describe where your trunk is, where to report bugs, etc
<vila> and have it propagated to all branches (with handwave:// transport ;)
<jelmer> vila: for example, is there really much value in having repository.conf when (as we've claimed) the repository is just the place where the revisions are stored, not a user-visible thing?
<jelmer> vila: it also limits the concept of a project; e.g. I currently have bzr-svn for which I probably want to apply the rules for the greater bazaar project and then a few specific bzr-svn ones
<vila> repo.conf may contain shared_storage so we can get rid of repository/shared_storage for example
<jelmer> vila: shared_storage is something repository-specific, I don't think we should inherit it in e.g. the branches below that repository
<vila> right, that's indeed a good example :)
<maxb> also default creation of trees setting
<vila> argh, the bzr-svn vs bzr I meant
<vila> jelmer: right, but you can define properties for branch created under various prefixes (reviews, bugs, trunk, release, etc)
<vila> I'm not advocating doing that though, just mentioning the ideas
<vila> I tried to find a scope greater than the current needs to ensure I wasn't reducing the needs too much,
<vila> Now. I don't intend to implement every file described there when the most asked for is tree.conf
<vila> but I want a config framework that can support them if we decide we need them
<vila> jelmer: if bzr-colo can be implemented with a branch.conf with sections instead of branches/ files hierarchy for example... I'd be delighted
<vila> jelmer: regarding branch.conf inheriting from repo.conf, *some* options could inherit, but certainly not all
<jelmer> vila: the problem with definining a repository.conf and a project.conf is that we'd limit ourselves to a very strict interpretation of those, I'd rather see a more flexible mechanism for inheriting configuration options
<jelmer> vila: yeah, I agree it'd be nice to collapse the branch configurations / last-revision files with the next format bump
<vila> jelmer: when (and if) you register an option, you can define *where* it is allowed
<jelmer> vila: I mean as a user
<vila> jelmer: there may even be a compatibility path that doesn't require a format bump...
<vila> what do you mean by 'more flexible' ?
<jelmer> vila: e.g. in my example of bzr-svn there isn't a single project that's relevant
<vila> Right, I agree on the conceptual level, but without specific options to think about, it's harder to come with good answers ;-/
<vila> social conventions (where is trunk, where/how should I send contributions, mailing lists etc) seem pretty clear to me as project specific and can't really be shared across project
<vila> also, with interpolation, you gain the ability to refer to the project with {project} which can be set in say, branch.conf but still referred to in project.conf
<vila> or overriden
<vila> jelmer: ben also mentioned including config files. There are trick issues there and I didn't mention them but that may also be a mean to consider
<jelmer> vila: a lot of those options could be shared across the various bzr subprojects I think
<jelmer> vila: include files sound like an interesting alternative
<vila> jelmer: one way to share across projects is to put them under the same path (in different directories of course)
<vila> jelmer: another way is to allow some config files to be defined and used at different levels in the hierarchy (ignore files for example)
<vila> so my proposal tried to mention the *possible* files and define a framework that will allow us to implement them if/when needed
<vila> I also wanted a simple design and I'm not sure it doesn't provide too much already ;D
<vila> these are just *dicts* damnit :D
<jelmer> :)
<vila> dicts of strings even
<vanguard> how can I convert a git repo to a bzr repo?
<jelmer> vanguard: "bzr git-import" command from the bzr-git plugin, or using bzr fastimport / git fastexport
<vanguard> hmm, bzr fastimport crashed, I reported it on LaunchPad, but it does not seem too good :-/
<awilkins> Is there anything for Bazaar that's like gitstats and shows things like commit time distribution
<awilkins> Something that just used git-fast-export format would be perfect, no?
<awilkins> I want to really rub it in for my management the stupid hours I've been working and commit logs are the best evidence
 * beuno doesn't know of any
<luks_> http://oxygene.sk/lukas/2010/03/punchcard-graphs-for-bazaar/
<awilkins> Muhahahah!
<awilkins> Hmm, do you have to pick a file?
<luks_> heh, I don't actually remember how does it work anymore :)
<luks_> ah, the filename is the generated png file
<awilkins> Ah
<awilkins> Hence "." doesn't work
<luks> it was really just a quick hack to see the stats for my pet projects
<awilkins> Might poke it a bit to take a list of aliases, etc
<awilkins> I have several aliases in this projects from committing on different machines with different WHOAMI, on SVN with a different username, etc
<awilkins> But it already reveals a nice set of spots for 0400, 2100, 2300 :-)
<luks> heh
<awilkins> My, that was a quick hack
<awilkins> Impressive
 * awilkins hacks it to use regex for the committer
<awilkins> Why the hell does one guy always commit at 0900 on thursday...
<awilkins> Many thanks, heavy ammunition, that is
<awilkins> luks, https://code.launchpad.net/~adrian-wilkins/+junk/punchcard-regex-committer (as if you needed help to write it...)
<luks> heh, I never noticed the wrong day abbreviations
<awilkins> Jus tgot them wrong myself ... overwritten that rev
<awilkins> Have to justify that my Thu / Fri working at home is productive
<awilkins> Biggest blob is 1000 Friday morning :-)
<awilkins> Can see all sorts of extra dimensions you might add to this
<awilkins> Colourize the blobs on average commit size, etc
<awilkins> But no time ... wanted to do some visualization software for financials at one point, voxel graphics for interest, etc, but never got around to even trying
 * awilkins has all sorts of fun with   for C in `bzr log --xml | xpath2 -q -e '//committer/text()' | sort | uniq` ; do bzr punchcard --committer $C $C.png ; done
<poolie> hi all
<jelmer> 'morning poolie
<poolie> hi there
<poolie> hey there
<poolie> did you get to talk to daniel, jelmer?
<jelmer> poolie: yep, thanks for putting us in contact
<poolie> so it's all set, or underway?
<jelmer> it's underway, should be done by tomorrow
<jelmer> Jorge also sent out an email with more details on e.g. the naming scheme later today.
<jelmer> (your yesterday)
<jelmer> wb poolie :)
<jelmer> did you see my reply?
<poolie_> yes, thanks :)
<poolie_> hi spiv
<spiv> Hi poolie, I'm not *quite* here yet ;)
<spiv> Good morning :)
#bzr 2011-03-31
 * maxb crosses fingers, declares a possible solution to dh_python2 backports, and waits for the build farm to get on with it
 * spiv wonders what's up with https://bugs.launchpad.net/bzr/+bug/745664
<ubot5> Ubuntu bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed]
<jelmer> maxb: what's your solution?
<maxb> jelmer: pretty much what I was outlining this morning
<maxb> shim packages that lead to dh_pysupport/central being invoked
<jelmer> maxb: ah, right
<jelmer> I hadn't expected you to actually've implemented it since then :)
<maxb> hmm, the web UI no longer permits copying packages to jaunty
<jelmer> does anybody still care about jaunty ? :)
<maxb> I think it might be time to officially drop ~bzr/ppa support
<jelmer> maxb: in favor of up to date distro packages and the daily builds?
<jelmer> maxb: I think that's sensible, though perhaps we should check with the people currently using it
<maxb> oh, I meant drop ~bzr/ppa support for Jaunty
<maxb> :-)
<maxb> err, what?! Really weird build failure from bzr-daily/maverick: https://launchpadlibrarian.net/67748861/buildlog_ubuntu-maverick-i386.bzr_2.4~bzr5744~ppa3921.3921~maverick1_FAILEDTOBUILD.txt.gz
<maxb> gcc errors compiling pyrex .c files
 * maxb has a look at loggerhead recipe conflict
<spiv> maxb: r5731 changed that code
<spiv> maxb: but the change seems to work on my maverick system
<spiv> maxb: although, huh
<spiv> maxb: I don't see the *_pyx.c files being regenerated in that buildlog
<spiv> maxb: shouldn't pyrex be run at some point?
<maxb> maybe
<maxb> but, puzzling why it should work on natty
<spiv> maxb: http://bazaar.launchpad.net/~debian-bazaar/bzr/unstable-2.4/files/head:/bzrlib/ appears to have stale .c files
<maxb> jelmer: Do you know why dulwich-daily is set to exclude karmic?
<maxb> spiv: The packaging branches usually pick up .c files from the previously imported tarball. It's normally OK. I guess we've found a situation where it is not
<spiv> maxb: it seems weird to me that we don't run pyrex at build time
<spiv> maxb: python-pyrex is even listed as a build-depends
<maxb> The bzr/daily PPA is doing quite a thorough job of saturating the PPA/i386 buildds right now :-)
<spiv> :)
<poolie__> maxb, wow
<poolie__> where is that shown?
<spiv> poolie: https://launchpad.net/builders I guess
<bignose> where is a good channel to ask about the âtesttoolsâ package?
<lifeless> here, #subunit #testtools
<lifeless> erm, the last is fiction
<lifeless> also #python-testing or whatever its called
<bignose> lifeless: okay, meet you there? :-)
<lifeless> bignose: ping me from whatever channel you choose ;)
<poolie> hi jam
<danielsh> last week I started storing my dotfiles in bzr
<danielsh> now I'd like one dotfile to different between my desktop/laptop
<danielsh> (different font size in the terminal emulator)
<danielsh> how can I do that?
<danielsh> if I change the config file on the laptop, then I can't seem to ignore that change on the desktop, any pull/merge requires a commit which then the laptop wants to pull,
<danielsh> lather, rinse, repeat
 * danielsh hopes his explanation is clear enough...
<jam> morning poolie
<poolie> hi danielsh
<danielsh> poolie: morning
<poolie> there's a few options
<poolie> one would be to make that file a symlink into a machine-specific directorie
<poolie> hi jam
 * danielsh (oh, forgot to say, I checked with the latest stable version before I /joined here.)
<danielsh> unfortunately the file is a plain .ini file, there's no easy way to do 'source `hostname`/foo.conf' or similar
<danielsh> as to storing all the different versions in the history everywhere,
<danielsh> that doesn't seem nice, I'm not sure where to start,
<danielsh> it offloads the problem of diverging changes to me, rather than to the tool,
<danielsh> I'm not sure that it scales well (think N machines),
<poolie>  how would you like it to work?
<danielsh> on laptop: edit file. commit.  on desktop: merge that commit while making an edit that the laptop won't try to pull.
<danielsh> end result: laptop has font size 11, desktop has font size 12,
<spiv> I think "have one master template, and then N local variations, and when the master updates help merge those updates into the local variations" is something bzr doesn't really cater to directly, but you could build on top of bzr.
<danielsh> and I can keep bzr push/pull between them
<danielsh> (and yes I may run into conflicts sometimes)
<spiv> In bzr terms these would all be separate branches
<poolie> so you want to make a "don't merge this" commit?
<poolie> yes, you could have a separate branch for stuff that is meant to be common
<danielsh> poolie: I'm not sure what is the bzr term for what I want.
<spiv> And when you update the master you'd then merge that into the local branches, but typically not merge the other way.
<spiv> I know there are tools like etckeepr that can use bzr, but I don't know if they cater to this specific use case or not
<danielsh> so in that case I'd have on each box two branches:
<danielsh> * the master branch (shared, identical everywhere)
<danielsh> * a local branch (only pulls from master, never pushes)
<danielsh> ?
<spiv> You wouldn't have to have a copy of master on each box, but it may be convenient to do so.
<poolie> correct
<poolie> merges from master
<spiv> But basically, yes.
<danielsh> Okay, I see.
<danielsh> I'd have to propagate changes from ~/.foorc to ~/master.bzr/foorc manually, though
<poolie> jam i wonder if i can just do without <BLANKLINE> or give an option to do without it
<poolie> i agree it is a bit ugly
<danielsh> (or cherry-pick them..)
<danielsh> spiv, poolie: thanks for discussion, I've learnt something :-)
<jam> poolie: yeah, something. I'm back to family time, now that everyone is waking up. Be back in about 2 hrs
 * danielsh will check out etckeeper, too.
<poolie> sure :)
<poolie> i was a bit surprised to see you
<lifeless> jam: I'm sorry if you feel unhappy about my backing out the lp-runs-loggerhead tests
<lifeless> jam: I hope I've explained well enough on the bug, but if not I'm happy to discuss further here
<poolie> jam, it turns out it is happy without the blankline markers
<vila> hi all !
<jam> hi vila
<jam> lifeless: I'd be happy to discuss it with you. I can see some of your points, but I have some of my own
<jam> right now, I have to finish moving out of the apartment, though
<jam> So maybe late tonight (early your morning, I think)
<vila> hey jam !
<spiv> jam: please do take up that push regression, that'd be great
<vila> jam: good luck with your move, don't break too many things ;)
<vila> jam: and enjoy your new place !
 * spiv â afk
<jam> thanks vila
<jam> have a good evening spiv
<jam> vila: I would enjoy it more if we had furniture
<jam> Customs has delayed it for 1 month so far, and are currently saying "you don't have proof that you didn't live in EU for 12 months"
<jam> so they want to charge us as though we are bringing it to sell, or something.
<vila> jam: naaah, give a try to a more zen-like attitude, just sell your stuff !
<jam> and by default, online statements only go back 12 months from today
<jam> which doesn't go back to Jan, 2010
<jam> vila: right. Of course, sleeping on hardwood floors is the real Zen challenge
<vila> jam: welcome to Europe :D
<lifeless> jam: ugh
<vila> . o O (Keeping the balance between sarcasm and true compassion is hard)
<poolie> hiya vila, jam
<vila> poolie: heya !
<lifeless> jam: sure, can chat whever
<jam> We could get a hotel room, but extended hotel room stays and 3-year olds don't go very well together.
<jam> we bought some air mattresses, but the people on the box must be midgets. I clearly overhang the end by about 30cm, and I'm not all that tall.
<jam> hey poolie
<poolie> :)
<vila> welcome to Eur... err already made that one, but there is a long tradition of jokes around here about US making bigger "things", looks like mattresses fit the category :D
<jam> vila: yeah. "Everything is bigger in Texas". I was actually a bit disappointed that things in Dallas weren't bigger. They just seemed US-sized. :)
<poolie> the cars were pretty big
<poolie> oh and the guns
<poolie> and the food
<jam> poolie: but not particularly bigger than elsewhere in the US
<jam> we have the statement *in the US* that "Everything is bigger in Texas"
<jam> I guess the Hats are usually bigger
<poolie> yeah, and Queensland is bigger than Texas :)
<poolie> vila, i may be just missing the point, but the config stuff seems eminently split-able
<vila> poolie: except for the deployment part...
<vila> may be *I'm* missing the point :)
<poolie> for instance we can add a better api without changing anything much else
<vila> the sore point is BranchConfig and its relationship with remote configs
<vila> so may be I should just start with GlobalConfig...
<poolie> why is it sore?
<vila> poolie: have a look at set_option (name, value, section=None) and _set_option(self, value, name default) and _set_option(self, section_name, option_name, value)
<vila> and the various classes involved starting from BranchConfig and including TreeConfig, TransportConfig BzrDirConfig
<vila> so while each of the proposed classes are easy to implement in isolation (that was the goal), using them requires to handle the transition path and while I know that it will be ok at the feature level, I fear some evil details when migrating from the existing files
<vila> one option is to use *new* file names, but this means updating the docs and our user brains (the later being far harder ;)
<vila> but neither being cheap
<vila> so I feel more comfortable landing the new features well tested but not used and *then* focus on the migration
<vila> my last failed attempt has been to address bug #491196 :-/
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/491196
<vila> the proposed design makes it trivial, but only after deploying the new design...
<poolie> hm
<poolie> i do kind of feel like it should be possible to have an api that stacks just the dynamic config on what we have now
<poolie> but i guess the proof is in actually trying to do it
<vila> yeah, I share*d* the feeling :-/
<vila> Have a look at ConfigStack in iconfig.py in lp:udd: I needed a ugly hack to get usable ConfigStack
<vila> same goes for expand_options, basically if I fear that going incremental will end up with a code full of hacks from the start when the goal is instead to get (hopefully) a clean implementation that will be easier to enhance
<vila> s/if I fear/I fear/
<vila>             if hasattr(c, 'get_user_option') and not hasattr(c, 'get'):
<vila>                 c.get = types.MethodType(compatible_get, c, c.__class__)
<poolie> i saw that
<vila> is the ugly hack I'm referring to: it injects a bound method
<poolie> what's the main motivation for expansions?
<vila> may be it's a useful technique to handle compatibility if we can find clearer helpers to use it, but...
<vila> push_location = lp:~{launchpad_unsername}/{project}/{nick}
<vila> bzr.xxx.action = {script} with {script} being 'ask' for interactive use and True/False otherwise
<vila> more generally sharing more default values
<vila> by allowing references
<poolie> and where does that get set?
<poolie> it just seems strange to add it before doing the other refactorings
<vila> expand you mean ? I'm already using 'bzr push `bzr config mypush`/`bzr nick`' quite often
<poolie> yeah, i meant internal expansion
<poolie> i'm not complaining
<poolie> it may sound like i am :)
<vila> well, more than quite often in fact, almost always
<poolie> i just cared more about -Ofoo
<vila> no no
<vila> hehe, mee too :D
<vila> oh, and expand is good for command templates or log templates as seen recently on the ml
<vila> the main limitation actually is the single config scope
<vila> which can't be addressed without ConfigStack
<vila> I'm pretty sure we also have as-yet un-triggered bugs when remote configs are involved
<vila> like: what if I define a bazaar.conf and a locations.conf on a server
<vila> do we have the same behavior between smart and dumb servers ?
<vila> I suspect nobody tried to fiddle with that so far ;)
<vila> and I'm in no hurry to open the can of worms ;)
<vila> but abentley raised 'control.conf' used by launchpad and.... that's another can of worms...
<vila> now, if you look at https://bugs.launchpad.net/bzr/+bugs?field.tag=config , we have 26 bugs there, most of them will be easy to address... if we had this new design
<poolie>  ok
<vila> but trying to address them *now* and finding the minimal path to get one them fixed... I failed
<vila> so I finally concluded that this was too hard and that I should try a different approach, hence the proposal
<vila> well, the 26 above does not include some more general ideas we've been talking about like getting rid of many constants in bzrlib, trying to handle bzr-colo in branch.conf instead of .bzr/branches, etc
<vila> on the other hand, I don't want to end up with a massive >2000 proposal either
<vila> so I tried to test-bed things in the package importer... only to realize that other issues were coming in the way there
<poolie> yeah
<poolie> i think this will fix things
<poolie> fix many bugs
<vila> oh, and I forgot about resolve default actions too for udd
<poolie> i am just desirous of smallers proposals along the way
<vila> +1
<vila> the plan is to propose the various classes, well tested, one by one
<vila> preparing the deployment as best as I can doing that
<vila> another sore point has been the infamously long review of doxxx regarding mergetools (which was also a motivating factor for expand)
<vila> as was abentley appendir proposal
<vila> (and still is since he's still blocked because we don't provide a solution for his need)
<vila> I'm reasonably confident that the proposed design *can* support additions for all known needs (so far) even if things aren't clear enough yet
<vila> The Store abstraction has enough constraints defined to propose tests reusable for daughter implementations, section selection should address various context definitions *without* forcing too much constraints (regexps, globs, path (relative or absolute)), Option definitions should provide an optional basis for online help
<vila> I don't think I invented too many new concepts there and I tried to think hard about trivial basis implementations
<vila> now I need some code to verify that the design is sound or I may as well keep thinking about it for years
<vila> oh, and an hidden assumption is also that we should get rid of all env vars (if only because they can't be easily used on windows or for guis)
<jam> vila: Windows works just fine with env vars "set foo=bar"
<jam> however, it is a bit hard to get to from Guis
<vila> jam: tell that to my mom...
<vila> I mean, for most users the workflow just never involves being able to 'set foo=bar'
<vila> they want something in a file
<vila> even 'bzr -Ofoo-bar xxx ...' won't work for them
<poolie> mm
<poolie> we should just define options that have an environment variable as a way to set them, but also a regular name
<poolie> anyhow, that's enough for me for today
<poolie> jam, thanks for the reviews
<poolie> i might add tests for some of them tomorrow
<poolie> i may be being a bit lazy
<vila> poolie: right, but what's the point of having both 'foo=bar bzr ...' *and* 'bzr -Ofoo=bar ...' ?
<poolie> things like <https://code.launchpad.net/~mbp/bzr/733136-lock_url/+merge/55706> where in other languages a compiler error would pick it up, i'm not sure how much it's worth adding a test
<poolie> vila, if we could handle everything through the second case i think the first would be unnecessary in almost all cases
<vila> poolie: +1, not worth the trouble to add a test
<poolie> it does have one advantage which is that it inherits
<vila> oh, good point
<poolie> ie you can set the plugin path in your .bash_env
<vila> may be -O should propagate to subprocesses ;D
<vila> plugin_path is trickier (as are some other options)
<jam> vila: other than being able to do "export BZR_FOO=bar" and have it valid for the lifetime of your session
<poolie> i mean you can set it in the shell and it will pass through emacs down to bzr
<poolie> for instance
<vila> I'm contemplating a [__init__] section in bazaar.conf :D
<jam> -Ofoo=bar doesn't persist
<vila> jam: sure, but that still doesn't work for windows newbies
<vila> i.e. the ones that don't know how to setup env vars for their session
<jam> vila: set works just fine, and if they are newbies they are (a) prob not on the command line, (b) not going to know about -Ofoo=bar either.
<poolie> anyhow
<vila> jam: indeed, but they still want to set some default values
<poolie> let's try to get there
<poolie> i'll try to comment on your api examples tomorrow
<jam> vila: I would hesitate to expect that there is someone who doesn't know how to set their env vars who also *does* know how to set -Ofoo.
<vila> ok
<jam> *my* point is just that "no env vars" isn't somewhere we actually want to be
<jam> we might want fewer
<jam> but I don't think that value is 0
<jam> poolie: have a good evening
<poolie> we want a way to have per-process settings that don't use the environment
<vila> jam: I'm not saying we should *not* support them, I'm saying that if one feature is available thru env vars *only*, then some users won't be able to use it
<poolie> that's the main reason people would add them today
<poolie> agree with that
<jam> (11:05:33 AM) vila: oh, and an hidden assumption is also that we should get rid of all env vars (if only because they can't be easily used on windows or for guis)
<jam> vila: which is what I was rebutting. It sounds like we agree
<vila> jam: yeah, re-read it with ... yeah
<vila> badly phrased
<vila> err, is 'phrased' english ? formulated ? expressed ?
<jam> vila: phrased or expressed
<jam> "we don't want to require users to use env vars"
<jam> would be a better way
<jam> vila: stuff like default plugin path, etc, certainly belongs in a config. Though being able to override it easily gets tricky
<vila> jam, poolie : Thanks for the constructive feedback anyway, I don't want to sound to defensive on this proposal. Just trying to make sure the ideas behind it aren't lost because I didn't explain them well enough
<vila> jam: yeah, I'm beginning to accept that even the plugin path and the config files should somehow be specified into a config file. But for bootstrap reasons, I'm inclined to restrict their use to bazaar.conf only (so far)
<vila> jam: and until then, I won't delete BZR_PLUGIN_PATH, BZR_DISABLE_PLUGINS and BZR_PLUGINS_AT :D
<vila> but these aren't the most pressing bugs either
<lifeless> vila: FWIW, wearing my user hat, I'd be much more interested in package importer stuff, or colocated branches, or build form branch, than config changes
<vila> lifeless: funnily enough, all of the mentioned areas will benefit from that by making changes easier to implement
<lifeless> vila: I've learnt to be wary of budgeting work on that basis; you may be entirely right, or it may be less than break even
<vila> lifeless: and you're damn right there
<lifeless> vila: The only thing I took away that would be easier would be a command line tool to set options, which didn't seem particularly relevant to $aforementioned
<vila> lifeless: bzr config foo=bar ?
<lifeless> yeah
<vila> lifeless: try bzr/2.3
<vila> with a bunch of limitations so far
<lifeless> what I mean
<lifeless> is I don't see the connection from that to e.g. the importer
<vila> bug #719888 and the hurdles to test locally
<ubot5> Launchpad bug 719888 in Ubuntu Distributed Development "package import on jubany/pepo should write logs to a dedicated and configurable log directory" [Medium,Fix released] https://launchpad.net/bugs/719888
<vila> or a better way to specify options for imports on a package, series, pocket basis
<vila> or the ability to specify post-merge resolve actions on a dir/file basis in a persistent way
<lifeless> uhm
<lifeless> these still don't seem connected
<lifeless> to config foo=bar
<lifeless> I'm not saying they aren't nice
<lifeless> I just don't understand the relevance
<lifeless> for instance
<lifeless> LP has configuurable log dirs
<lifeless> and doesn't have a tool to set config variables
<vila> we aim at making all options be specified either in a config file or from the command line
<vila> config files providing various ways to set default values for various contexts
<lifeless> you're describing a design
<lifeless> what problem are you solving
<vila> so either you set the option in a config file or you specify it from the command line
<lifeless> and how is that problem relevant to the importer
<vila> the losa want a way to decide where the log files are stored, the importer should respect that
<lifeless> [meta: I don't mean to criticise :- but I don't understand the links, and I suspect other observers also won't.]
<vila> the log dir was a hard-coded constant
<lifeless> vila: could they not just edit ~/.bazaar/bazaar.conf
<vila> lifeless: only if the code even try to look there
<vila> which it wasn't
<lifeless> ok, so perhaps if I now draw a comparison:
<lifeless> A: implement a system to do arbitrary config option setting
<vila> and still don't because there is no way to keep bazaar.conf in the same branch as the importer scripts (so far)
<jelmer> maxb: those bzr-git test failures are due to an old dulwich
<lifeless> B: Fix the packaging importer code to ask global config for theoption
<lifeless> vila: ~/.bazaar/bazaar.conf doesn't need to be in said branch, does it ?
<maxb> jelmer: Ah, hi. I wanted to ask you what you thought about migrating from cdbs to dh7 for dulwich and subvertpy
<vila> lifeless: if you keep a default value in the scripts, no
<maxb> jelmer: The motivation is that the current Build-Depends on cdbs is on a version only available in natty, and I REALLY do not want to backport cdbs
<lifeless> vila: I don't understand why a default value would be needed
<jelmer> maxb: Hmm, I thought I already did that
<lifeless> as in, config = GlobalConfig(); logfir = config.get_user_config('pkg importer log dir')
<vila> lifeless: to keep track of what options need to be defined
<lifeless> vila: you've just switched problem statements I think.
<lifeless> vila: you said 'the losa want a way to decide where the log files are stored, the importer should respect that'
<maxb> jelmer: Not for those two, apparently (dh_python2 yes, dh7 no)
<jelmer> maxb: ah, just not pushed
<maxb> jelmer: I love it when fixes are that easy :-)
<vila> lifeless: well, we start with a python file where a bunch of dirs are built from a common base and we want to get to the point where the production site can override them and the testers can also override them
<vila> lifeless: going there incrementally without a perfect knowledge of the scripts (which I haven't) requires some care
<lifeless> vila: let me ask a different way
<lifeless> how many constants did you want to change in the package importer
<lifeless> and/or how many constants did you see?
<vila> lifeless: so I didn't want to get rid of the relationships between these various dirs being entirely defined outside of the scripts
<vila> lifeless: roughly 20 say
<lifeless> really?
<vila> yeah
<lifeless> 20 *different unrelated log dirs* ?
<vila> nooo
<vila> there was one log dir that also contained the files served with apache
<vila> we now have to different base dirs for that
<lifeless> ok
<lifeless> so thats 2
<lifeless> how does that connect to 'config foo=bar'
<vila> lifeless: http://paste.ubuntu.com/587731/
<vila> part of icommon.py imported by all scripts
<vila> oh wait, let me add some lines there: http://paste.ubuntu.com/587733/
<vila> so, yes, the dirs are created unconditionally
<vila> but the log dir itself now contain two more dirs 'driver' and 'packages' which are create more lazily
<vila> create*d*
<lifeless> ok, but again
<lifeless> how does this connect to a command line tool to write config files to disk
<lifeless> it seems to me that:
<lifeless>  - using global config
<vila> err, modify a config file you mean ?
<lifeless>  - reading 2 or 3 values from there
<lifeless>  - and then putting them in as the relevant base dirs while you split things apart
<vila> right, that's the final plan
<lifeless> would meet the losa constraint
<vila> an incremental step has been to introduce pkgimporter.conf: http://paste.ubuntu.com/587734/
<lifeless> I feel like I'm not connecting on this
<lifeless> it must be frustrating you
<vila> no, no, go ahead, I appreciate
<lifeless> so I'll put it directly
<lifeless> it seems like a 2-3 hour direct and simple change
<lifeless> became a large scale software engineering problem
<lifeless> aka
<lifeless> overengineering
<vila> I can understand that
<lifeless> thats *perception*
<vila> but I didn't spent as much time in it as it may seem
<vila> I've been *thinking* about that for a long time, but I don't account my in-bed-thinking as work time ;)
<vila> now, for the package importer, the main issue is that I can't *test* properly such changes which means I need to be cautious when I introduce them
<lifeless> vila: the thing that is confusing
<lifeless> is that you say 'bzr config foo=bar' is connected to improving the importer
<lifeless> and I don't understand that at all
<vila> oh, sorry, no I was replying to 'can we set that from the command line'
<vila> for the package importer the issue is to keep such config options under control while allowing losas/testers to do their work without modifying scripts by nahd
<vila> hand
<lifeless> vila: ok; so why is that more complex than 'read the options from bazaar.conf'
<vila> and using bazaar.conf wasn't adequate
<vila> ha,
<vila> because I didn't want the definition and the (unclear yet) dependencies to disappear from the branch
<vila> so maybe it's overcautious rather than overengineering ;) But maybe both...
<lifeless> vila: so rather than leave the old value commented #was foo=bar\nfoo=config.get_user_option('pkg_importer_foo')
<vila> lifeless: keep in mind that I *learned* about which files were served over http while addressing the log issue...
<lifeless> you built a bunch of infrastructure
<evelyette> hi
<vila> which one ?
<lifeless> vila: well, the bzr config foo=bar that you mentioned
<lifeless> evelyette: hi
<evelyette> does bazaar have a plugin which scans for file modifications in certain folder and updates the tree automatically
<evelyette> kindda like inotify in linux
<vila> lifeless: oh no, that was already built, I didn't built it for the importer
<lifeless> evelyette: I think someone built something to do that (using inotify)
<evelyette> lifeless, I would very much like to use that: can you tell me more, maybe provide a link ?
<vila> lifeless: what I built for the importer is only iconfig.py (~80 lines) so locations.conf can be used to override pkgimporter.conf (which itself just build on top of config.IniBasedConfig
<lifeless> evelyette: sorry no, google can tell you all I can
<lifeless> evelyette: Its just a vague memory
<lifeless> vila: so to backtrack; you say that the package importer will be easier to write with the config overhaul; whats the connection ?
<lifeless> :)
<vila> http://paste.ubuntu.com/587734/
<vila> and then tester just have to override pkgimport.base_dir
<vila> and since I keep bumping into, damn why can't I just fu.. do it this way (in so many different places, the importer being the last one)... I thought the threshold was reached
<lifeless> I can see it being useful
<evelyette> btw: I just heard of bazaar and had to check it out. I've been using svn/git for now: so how is bazaar different from the svn/git, is it better?
<vila> lifeless: so, yeah, I try to keep it light and I'd like it to be easy and fast to implement, but I'm tired of working around the lack of it ;D
<lifeless> vila: fwiw I would just have kept the relative defn's relative and defined two variables in configs
<vila> evelyette: that's a big vague to be properly answered, especially if you want an answer applying to both svn and git which are rather different ;D
<evelyette> ok just git then
<evelyette> svn is crap :)
<lifeless> vila: by preference I mean - I find overly parameterisable code gets harder to maintain and permits config bugs
<vila> lifeless: yeah, and use makedirs instead of mkdir, but there is still the risk to create dirs in the wrong place etc
<vila> lifeless: indeed !
<vila> lifeless: which means the true and perfect solution is to re-design the importer scripts which I don't want to do ;)
<vila> lifeless: or at least not upfront, I'd prefer to go incrementally there even if I can't find a way to do the same for the new config design (or at least not as far as landing simple feature that requires a bit of infrastructure)
<lifeless> vila: well, you can treat the current structure as being only configurable to the extent you add it
<lifeless> vila: avoiding both a redesign and overly-configurable code issues
<lifeless> evelyette: git and bzr are similar in lots of ways
<vila> lifeless: yup, I'm learning the scripts design as I go
<lifeless> evelyette: key differences are: bzr tracks file identity, git tracks tree snapshots only; git has an index which is great for code review and confusing for everything else
<vila> lifeless: (and also collect relevant files like the crontab, the apache config and so on, too)
<lifeless> evelyette: bzr is written in C and python, git in C and perl
<evelyette> thanks
<evelyette> I've also installed bzg-gtk and qbzr  but there's no gui anywhere ?
<evelyette> I'm on gentoo btw
<vila> bzr-explorer
<vila> and try 'bzr qlog' in a branch
<evelyette> there is no such command
<evelyette> I don't have a branch
<vila> bzr-explorer is a plugin, 'qlog' is a command from qbzr
<evelyette> aha
<evelyette> does that plugin have tray as well ?
<evelyette> because that is what I really miss
<evelyette> and the inotify stuff, so the client automatically updates its stuff
<vila> well, qbzr provides a GUI for many operations on a branch, so you can't see it in action without a branch
<evelyette> yes I got that :)
<vila> bzr-explorer mostly relies on qbzr
<vila> 'have tray' ?
<evelyette> trayicon
<vila> you mean an icon .. ok
<vila> well, you alsmot always need to interact with some file on disk so a tray icon is not a high priority ;)
<evelyette> ah :)
<vila> when you say update, you mean update a working tree from a branch ?
<evelyette> I mean commit the working directory to master bzr server
<vila> hmpf
<evelyette> and the other way around
<vila> sorry
<vila> I don't know about many cases where you want to commit automatically (automatic messages being meaningless most of the time)
<evelyette> yes meaningless ... I don't need them
<vila> but nothing (nor nobody) can stop you to call 'bzr commit -m "auto"' from an inotify hook
<evelyette> I just want to sync
<evelyette> yes that's what I want ... is it already written or will I have to write it by myself
<vila> you probably need to write it, I don't know of an existing plugin to do that (bug google may know better ;)
<evelyette> does bazaar have any API I can use instead of "bzr commit -m "test""
<vila> keep in mind though that rsync or other backup tools may be more appropriate if you don't care about the history of the changes
<evelyette> yes I do care
<evelyette> just don't care about the -m option :)
<vila> bzrlib provides a python API but while this gives greater control this won't be as short as 'bzr commit -m "test"'
<evelyette> how are the plugins written, in bzrlib ?
<vila> on top of bzrlib, in python
<evelyette> so if I write that module in python, can I submit it ... and you'll keep it in the next versions of bazarr
<evelyette> because I would only like to write it once and have it available with bazaar installation, not by copying the .py files around
<vila> you can write a plugin without it being part of bzr core
<evelyette> yes that's what I mean
<evelyette> are you in charge of keeping that in plugins dir or whatever
<vila> the core carries only a few plugins, most of them are packaged independently for various platforms
<vila> s/most of them/most of the existing plugins/
<evelyette> cool
<evelyette> is there any good tutorial on bzrlib
<vila> like qbzr, bzr-gtk, bzr-explorer
<evelyette> http://doc.bazaar.canonical.com/plugins/en/plugin-development.html
<vila> yup, certainly a good starting point, have a look as existing plugins too, there are a lot of good practices that aren't documented in the url above
<jam> spiv: From what I can tell, bug #745664 is because your "fetch all tags" code also fetches all tagged revisions into a stacked branch.
<ubot5> Launchpad bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed] https://launchpad.net/bugs/745664
<maxb> I think it's likely to be what has caused my bzr-svn fetching of kdesupport to start taking aaaaages iterating tags too
<jelmer> maxb: are you fetching into a stacked branch?
<maxb> jelmer: no
<jelmer> maxb: I'm not sure I understand how it's related in that case
<maxb> abnormal amount of excessive work relating to tags, only occurring in bzr.dev, appearing at about the same time
<jelmer> maxb: bzr-svn was recently changed to fetch all revisions referenced by tags, as was bzr.dev
<spiv> jam: ah :/
<spiv> jam: and I think that bzr-svn import has some particularly bad tags
<jelmer> spiv: which bzr-svn import ?
<spiv> jelmer: twisted
<spiv> Actually, not so sure about the tag
<spiv> tags
<jelmer> ah, I see
<spiv> I know the set of branches was a bit confused (because they had some directories of branches inside branches/)
<spiv> At a glance there's only one tag that looks obviously wrong, 'releases', again I think that's a subdirectory of more tags in the actual svn repo
<spiv> But then, my local repo doesn't have the revision, neither I guess does the lp repo, so what are all the get_parent_maps about?
<spiv> tags that are ghosts on both sides should cause one get_parent_map with no result and then give up.
<spiv> So I wonder which revisions it is checking?
<spiv> And it's also weird that it doesn't happen on the initial push
<spiv> And the set of tags that aren't ghosts are the same in lp:twisted and locally
<spiv> (just 3 of them)
<spiv> jam: so, I'm still confused! :)
<vila> jelmer: try 'bzr qblame bzrlib/config.py' around like 285 (which is how I discover the issue)
<vila> jelmer: something seems wrong in the way you've done this merge :-/
<vila> jelmer: and yes, *I* am the one who forgot the pdb.set_trace() (though I doubt it can be triggered now)
<jelmer> vila: that looks weird indeed, I don't recall ever touching that much in bzrlib.config :-/
<vila> jelmer: you didn't, look at the file graph (click the line 285)
<vila> it's as if you cherry picked my changes
<vila> jelmer: no big deal, I'm just curious about how you end up with this and where the bug is
<vila> bzr ? wrong workflow ? In any case if *you* got tricked, many other can probably be to
<jelmer> vila: I never meant to take credit for your changes..
<vila> uneless you did something really exotic
<jelmer> I'm also not sure what's going wrong there
 * jelmer tries to remember what sort of workflow he was using there
<vila> hehe, no worries, anybody looking at the history will understand that anyway, just one step away
<vila> and my point is not about who to blame for a bug there ;)
<jelmer> heh
<jelmer> vila: I merged another branch which hadn't landed on mainline yet, perhaps that is related?
<vila> but your commit message says: 'merge bzr.dev' oooh, you mean, you merged my branch while it was processed by pqm ?
<vila> but then ... annotate is bogus ?
<vila> urgh, ha, wrong tool, qblame shows a weird graph if the nodes are opened, qlog should know better
<vila> jelmer: right, so revno 5676.1.4 revid:jelmer@samba.org-20110224160947-e7kqclxnjif28v5q says it merged bzr.dev but there is a single parent there
<vila> jelmer: cherry-pick ?
<vila> ovezealous cherry-pick ? ;D
<jelmer> vila: I never cherrypick from bzr.dev, perhaps there was some other magic I did that went wrong
<vila> jelmer: anyway, I've fixed the pdb
<jelmer> don't you mean pb ? :-P
<vila> jelmer: don't lose time on it, I was just curious
<jelmer> I'm curious about it now, too :)
<vila> lol, no, pdb as in 'import pdb; pdb.set_trace()'
<vila> left-over while debugging a nasty bug
<jelmer> Anyway, let's keep an eye on similar things in case it wasn't me screwing up a merge.
<vila> yeah, but a merge with a single parent... my bet is on some switch or something, a forgotten commit, a revert --forget-merge (doubtly)
<vila> http://babune.ladeuil.net:24842/job/selftest-osx-10.6/174/ and http://babune.ladeuil.net:24842/job/selftest-freebsd/
<vila> jelmer: what did you do ? Something bsd-hostile ? While resetting lazy hooks ?
<vila> jelmer: don't search, the root cause was a transient lp connectivity failure :D
<jelmer> vila: heh, ok
<vila> but I had a wtf moment when only freebsd and osx failed with the same 3 tests :D
<jelmer> vila: I guess that's what we get for connecting to lp from the testsuite >-)
<vila> jelmer: indeed
<jelmer> btw, if anybody has a chance to have a look at https://code.launchpad.net/~jelmer/bzr/more-lazy-hooks/+merge/55523 that'd be great; it would mean I can land / propose for merging several other branches
<vila> jelmer: seems pretty mechanical, will feel better if tests pass on all platforms (running)
<vila> jelmer: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-hardy/84/testReport/junit/bzrlib.tests.test_branch/TestHooks/test_constructor/
<jam> spiv: I'm still a bit confused myself. But it looks like the initial push pushes up something ~ correct. But then subsequent pushes see "you are missing basis inventories for these extra revisions you pushed"
<evelyette> hi
<evelyette> how can I start qbzr module ?
<evelyette> btw: is these something in bazaar that enables me to have centralized overview on all of my bazaar's repositories ... I'll have more of them on the same computer (an overview over these would be great to have), but an overview over all of the repositories over all of my computers would be great
<evelyette> it can be tunneled in ssh or something secure
<evelyette> is that possible ?
<evelyette> or a better question: does such a tool exist
<vila> qlog accepts several branches as arguments, some of them can be remote
<evelyette> well I need more than just a log ...
<vila> I have no idea what you call an overview :D
<evelyette> let's say: for now I would only like to know where the gits are located
<evelyette> so I don't miss some repository when backing up
<vila> gits ? Did you planned to ask the question in #git ? Anyway, if you need to find where you created branches, there is no such tool to find them for you (except for find(1)). Finding the branches you defined in a given repository is different, 'bzr branches' will tell you.
<evelyette> sorry ... not gits
<evelyette> bazaars
<vila> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief briefly defines the most often used words in bazaar (it often helps people coming from different backgrounds so we all refer to the same objects)
<vila> but out of the blue, if you have no idea where your branches are (or need to check where they are), a '.bzr' directory is generally a good indication
<vila> but I've never heard about a tool to give an overview of all branches (launchpad.net kind of answer the need but it's more than a tool)
<vila> well, unless you count bzr-explorer which (AIUI) helps you keep track of your branches by defining bookmarks and even providing a view with all of them, but you still have to define them to start with
<maxb> "All version control objects existing on this computer" does not feel like a useful categorization to me. Why do you care?
<maxb> For the backup scenario, that's not what you want - there's little point backing up local copies of open source software
<evelyette> it's not open source
<evelyette> I would like to have let's say 3 bzr repositories on my computer ...
<evelyette> but I have to keep track what are their locations
<vila> repositories or branches and/or working trees ?
<evelyette> I guess working trees
<vila> why do you need to keep track of where they are ?
<evelyette> if someone else joins the group I have to provide them with a link like ssh://bazaar/repo in order to checkout
<evelyette> so I have to know the path on the remote system of where the bazaar working tree is
<vila> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<evelyette> I just read that
<vila> it's very rare to have working trees on servers
<vila> especially when all people need to share are branches
<vila> and you can have a working tree (wt) on a client and the branch on the server
<evelyette> yes that's what I want
<vila> depends on your workflow
<evelyette> sorry for confusion
<evelyette> so I have to know the location of a branch on the server
<evelyette> that's what I want to keep track of
<vila> hmmm, I'm still confused, I have hundreds of branches on my computers organized in several hierarchies and that's good enough to keep track of all of them, what are you searching for exactly ?
<evelyette> how do you keep them organized
<evelyette> let's say I have a repositories (branches - whatever) of a project A, B, C ... so they are totally different projects...
<vila> ~/src/<project> and under that 'trunk' for.. the upstream trunk branch, and them subdirectories named bugs, reviews, experimental, integration, releases, packaging and branches below that or even more subdirectories
<evelyette> and I create the branches on a remote server in locations /tmp/A, /tmp/B, /tmp/C, and then completely forget about hwo I've set them
<evelyette> so then after a year I would like to checkthem out (pull from them or whatever), but since I forgot the paths where I've set them, I cannot
<vila> hmpf
<vila> bzr log <url> ; bzr info <url>; will give you some hints, but a tool can't replace organization ;)
<evelyette> that's true
<evelyette> I just want to check that I'm not doing something stupid, and overcomplicating things
<evelyette> so the projects are fine the way I described them, I just have to remember the urls
<evelyette> the paths to them
<vila> well, use a well defined name space and make evolve with your needs, define one you can reuse with several projects
<evelyette> I think I'm just gonna create a new folder and have all the bazaars branches in it
<evelyette> for ALL of the projects
<vila> host:/<project>/<zero or several meaningful dir names>/branch_name
<vila> have a look at http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/
<vila> or even http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/distributed_intro.html
<evelyette> thanks
<evelyette> can you also tell me how can I start bazaar explorer
<vila> bzr explorer
<evelyette> I tried, it gives me error
<evelyette> s
<vila> 'bzr help explorer'
<evelyette> http://paste.pocoo.org/show/363233/
<vila> meh, file a bug against your distribution, something is borked there
<vila> I don't use bzr-explorer myself so I don't know exactly which versions are compatible with which, but clearly there is a problem there
<vila> bzr-explorer uses qbzr which itself relies on Qt and there is a version mismatch here
<jelmer> "time bzr ls" on a small bzr tree -> from 0.404 in 2.3 now down to 0.207 in bzr.dev
<vila> \o/
<jelmer> mainly due to plugins being able to register their stuff more efficiently (this is with 35 plugins loaded)
<vila> worth the tedious work !
<jelmer> (for the pedantic, those numbers are in seconds)
<vila> elapsed times too then ;)
<jelmer> :)
<jelmer> the other two remaining heavy imports that we should be able to avoid on normal runs are the xml modules and knit repositories
<vila> jelmer: what is your timing with 'bzr ls --no-plugins' ?
<fullermd> 'knit' includes knitpack, I presume?
<jelmer> vila: 0.185s
<jelmer> fullermd: yes, that's how it gets imported (the 2a repository class is based on the knitpack repository class)
<jelmer> vila: I get a similar number (0.003 or something like that more) for 2.3
<vila> jelmer: worth a small summary on the mailing list so plugin authors get an insight about what lazy loading is about (INHO)
<vila> meh M
<fullermd> pack-0.92 you mean?
<jelmer> fullermd: pack-0.92 instead of which one?
<fullermd> You said '2a'
<jelmer> vila: good idea
<jelmer> fullermd: Yes, I mean '2a' too :)
<fullermd> So, ANY repo format (well, excluding weave :p) requires loading the knit stuff?
<vila> for some value of stuff...
<jelmer> fullermd: and for some value of requires
<vila> C & C !
<vila> damn, never laugh while drinking, or rather drink and *then* read IRC
 * fullermd falls over, battered and bruised from the tag-teaming.
<jelmer> :P
<vila> :)
<jelmer> fullermd: so, because of the way imports are structured at the moment any non-weave format ends up triggering the import of bzrlib.knit (and its dependencies)
<jelmer> lifeless, hi
<lifeless> hi
<jelmer> lifeless: did you see my last comment to lp:~jelmer/bzr-search/lazy-xml
<jelmer> ?
<lifeless> just been busy
<lifeless> we've had a couple of very disrupted weeks in lp land
<jelmer> lifeless: np, I'll ping again a bit later
<jelmer> I'm not in a hurry :)
<jelmer> lifeless, (also, kudos on the performance improvements... it's becoming a joy to use lp)
<rodrigob> hello people in the IRC channel
<lifeless> jelmer: cool; I can't take much credit - cast of thousands :)
<rodrigob> the channel seems very silent, is it here where I can ask weird questions ?
<lifeless> just ask:)
<rodrigob> I am using bzr with cruisecontrol.rb for automated integration of a web application
<rodrigob> I have discovered that cruisecontrol.rb has a bug
<rodrigob> because it assumes that the bzr versions will only increase with each commit
<rodrigob> but when merging branches
<rodrigob> the version can increase or decrease
<rodrigob> so the question is
<rodrigob> is it there a way to make bzr always make the version number increase ?
<rodrigob> or put in a different way
<lifeless> there is an option you can set in the branch's branch.conf
<rodrigob> ahh
<lifeless> its in bzr help configuration
<rodrigob> branch.conf ?
<lifeless> .bzr/branch/branch.conf
<jelmer> lifeless: aren't you supposed to be the architect ? ;-)
<lifeless> jelmer: yes, which means I get to point and guide and take no credit :)
<rodrigob> which option should it be ?
<rodrigob> append_revisions_only ?
<rodrigob> if I had revision 400
<rodrigob> and after merge I am at revision 350
<rodrigob> how can I get to revision 401 ?
<rodrigob> (without loosing modifications, obviously)
<lifeless> rodrigob: cd or switch to the trunk, merge the source branch commit
<lifeless> merging into a branch never rewinds the revno
<lifeless> its only when you push from another branch with different left-hand-path that that happens
<lifeless> yes, append_revisions_only is the option
<rodrigob> what is left-hand-path ?
<lifeless> rodrigob: every commit has a list of parents - a merge has 2 (or more), regular commits have just one
<lifeless> the left hand path is the path through the parents of each commit, following the left hand side only
<rodrigob> ok I see
<rodrigob> I do not get the
<rodrigob> "rodrigob: cd or switch to the trunk, merge the source branch commit"
<rodrigob> I am at the trunk
<rodrigob> at revision 350
<rodrigob> and before it was 400
<rodrigob> when looking at
<rodrigob>  bzr log -l15 -n0
<rodrigob> I see multiple merges in the last versions
<rodrigob> what can I do
<rodrigob> to get to 401
<rodrigob> instead of 351 ?
<rodrigob> I know my problem is weird
<lifeless> its straight forward
<rodrigob> but I am kinda lost with this
<lifeless> I need to run though - sorry!
<lifeless> perhaps jelmer is still around and can help out
 * jelmer wakes up
<jelmer> lifeless: thanks for not pointing the lp devs in the wrong direction >-)
<jelmer> ttyl
<rodrigob> ttyl ?
<jelmer> talk to you later
 * jelmer reads up on rodrigob's question
<jelmer> rodrigob, hi
<jelmer> rodrigob: you'd like to redo the merge so it will be r401 rather than r351?
<rodrigob> yep
<rodrigob> how could I do such re-merge ?
<vila> amazing, I never saw the guy asking the question bringing the one would will answer in his disconnection...
<vila> . o O (Where are they gone ?)
<poolie> hi all
<mr-russ-work> morning.
 * maxb ponders hardy backport of debhelper
<spiv> Hi all
#bzr 2011-04-01
 * jelmer waves
<jelmer> maxb: I wonder if it would make sense to add these to a separate PPA
<jelmer> surely we're not the only ones facing these backport issues?
<jelmer> at least, I wouldn't mind using your backports in the subvertpy and dulwich PPA's
<maxb> Conceivably. Though especially where debhelper is concerned, I'm aware I'm not caring about things like changes concerning udev rules and kernel modules, because I know the backport only needs to work for bzr stuff
<poolie> hi spiv
<spiv> Hi poolie.
<spiv> The patch to make Twisted's error handling is inching closer to approval.
<poolie> oh good
<mgz> did maxb's issue with my pyrex change not updating his C files get resolved the other evening?
<spiv> mgz: doesn't look like it: https://code.launchpad.net/~bzr/+recipe/bzr-daily
<mgz> okay, I understand that page now, confusing.
<mgz> 'successful' is a lie, cog-and-stop-sign is truth.
<mgz> so, setup.py needs fixing somehow...
<mgz> or that script is bypassing our setup.py somehow? the log makes no sense to me, the only pyrex mentions are from apt, but is something went wrong with recreating the C files there should be a note printed
<mgz> what does `dh_auto_build --buildsystem=python_distutils` do?
<poolie> i'm going to flush out some underway patches and then go back to colo/ui3
<poolie> mgz, good point about testtools matchers
<poolie> that exists in the testtools we use on pqm so i'll rework my patch to do that
<spiv> mgz: IIRC, it appears it is getting the .c files from the debian packaging branch, and not regenerating them
<spiv> mgz: I don't know why it doesn't run pyrex though, it even build-depends: python-pyrex, and it would seem like a sensible thing to do
<mgz> spiv: I'm trying to work out how that's happening, our setup.py should print a log message if it's not running pyrex
<mgz> I may just file a bug and leave it for someone who knows debian better.
<poolie> thanks for the review mgz
<poolie> re bug 746859
<ubot5> Launchpad bug 746859 in Bazaar "Daily builds not updating Pyrex generated C source" [Undecided,New] https://launchpad.net/bugs/746859
<poolie> this is very strange
<poolie> i don't think we commit the c files
<poolie> how can they be out of date?
<mgz> poolie: re review, I think your code was actually a bit cleverer than the testtools way, I'll file a bug against them for the UDIFF thing.
<mgz> as that also helps my complaint about unreadable output.
<mgz> re bug, the thing is there's a pyrex file, and a c file, that need to be in sync after the commit.
<spiv> poolie: the recipe merges in lp:~debian-bazaar/bzr/unstable-2.4, and that contains the C files
<mgz> I think the daily builds start from a tarball.
<mgz> or... what spiv said.
<mgz> so, there's another bug about the start point being wrong perhaps, but I don't see why the build doesn't update the pyrex generated files
<spiv> I'm pretty sure this is some sort of hangover from 'debs start with a source tarball and then add packaging goo', although I'm unclear on the precise route between that fact and this problem :)
<spiv> It may be something like the timestamps of the .c files on disk in the checkout/build area aren't older than the .pyx files, so the build stuff thinks they are up to date.
<poolie> i agree it seems to make sense to have udiff and ellipsis on by default
<poolie> you can file for that
<poolie> the matcher thing seems a bit too java-ish
<poolie> something more concise is probably possible
 * mgz agrees with the java-ish-ness
<mgz> oh, I take it back the not working, testtools does do the right thing, I just mistyped my example
<poolie> REPORT_UDIFF gives you a diff when it fails
<poolie> i think it's normally on in doctest
<poolie> but not throug this api
<mgz> provided you remembered to put newlines in the example, apparently.
<mgz> it's certainly easier to read, it's probably a good default.
<poolie> mgz i don't think testtools defaults to the right thing
<poolie> or not in the version i have
<mgz> no, it defaults to nothing, but I thought it ignored the report flag entirely (because I'd not supplied a multiline example)
<mgz> in other words, ignore me!
<poolie> spiv, what's the easiest or most python way to just make a random object that has an attribute
<poolie> i see you can no longer assign to instances of object()
<spiv> Easiest: random_obj = type('Random', () {})
<spiv> Most pythonic probably involves actually using the class statement :)
<poolie> !
<spiv> Er, a missing comma, but you get the idea
<poolie> is () {} a typo?
<poolie> oh, i thought that was real magic :)
<spiv> :)
<spiv> For values of âeasiestâ equalling âcan be done inside an expressionâ, anywayâ¦
<poolie> nice, thanks
<bob2> collections.namedtuple yo
<poolie> mm true
<poolie> but i think there you need to separately create the class and then the instance?
<poolie> also it's probabyl not in 2.4
<poolie> hi
<Peng> You can create a namedtuple class and instance in one statement, though.
<Peng> err, expression
<poolie> namedtuples(...)(...)
<poolie> like that?
<spiv> Right.  Actually, that's sort-of true for my suggestion as well.
<bob2> ah, 2.4 support, forgot about that :)
<poolie> yours is nice
<spiv> Except that classes are also random objects that can have attributes.
<poolie> type('FakeFoo', (), dict(thing=1))
<spiv> Whether you then instantiate the class is a separate questionâ¦
<poolie> spiv you should do https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/54958 for jelmer sometime
<poolie> not necessarily right now
<poolie> i wonder if we could get a clean lint
<poolie> it would catch some things
<spiv> I regularly use pyflakes (the branch of it that understands lazy_import) on stuff I'm working on
<vila> hi all !
<poolie> hi there vila
<fullermd> ETOOENTHUSIASTIC
<vila> :)
<poolie> vila did we ever get a fix for the bad rendering of options like '--1.14' in ReST?
<vila> poolie: not that I know of
<poolie> hi jam?
<vila> poolie: regarding config, I realize I haven't been clear about what I meant when saying 'implement all this design'
<poolie> jam i just wondered why you answered https://answers.launchpad.net/bzr/+question/151218
<vila> poolie: the option registry is not needed yet (its main point is displaying help) and registring there is optional otherwise and anyway
<vila> poolie: also, reaching the point where a Store guarantees minimal IOs is not needed yet either since we don't do that today and anyway I'd like some measurements in place before starting to implement it
<poolie> i think the next steps are deciding on the api
<vila> poolie: so what I meant was: I'd implement Section (read-only and write), Store and Stack and minimal implementations for the existing global, location and branch config files
<poolie> and the closely related thing of working out where they'll be held to avoid repeatedly reading them
<vila> even that can wait since it's an optimization vs what we have today
<vila> so yeah, deciding on the api
<vila> poolie: so, which part of the api poses problem ?
<vila> poolie: hehe, just read bug #746993 :)
<ubot5> Launchpad bug 746993 in Bazaar ""bzr help configuration" looks awful" [Medium,Confirmed] https://launchpad.net/bugs/746993
<vila> poolie: also, you can do self.skip(reason) instead of raise TestSkipped(reason)
<vila> poolie: ping ?
<poolie> hi
<vila> poolie: so, which part of the api poses problem ?
 * poolie looks
<poolie> vila, i think getting it from a registry is a bit strange
<poolie> ah
<poolie> we need to know who will hold, and gc, the objects
<vila> 'it' ? config ? option ?
<poolie> i guess the branch or whatever is supposed to get one when it's first created
<vila> yeah
<poolie> shoudl we talk here or mail?
<vila> as you see fit, here may be more effective though
<vila> err, efficient ?
<vila> both ? :D
<poolie> i'll answer mail first
<vila> ok
<vila> ping me then ;)
<poolie> why did you want "config.regsitry.get('bazaar', location)." ?
<vila> I think I said "didn't" in the mail but there are two cases:
<vila> if you have an already known bzrdir (branch, wt, etc), this should be used as it will already grab the relevant sections in bazaar
<vila> but there could be cases where you don't have a bzrdir, so selection the relevant sections from bazaar should still be possible
<vila> how stacks are built are still a bit unclear but some rules should already be pretty clear: command-line options, os.environ and bzrlib-defined default values should appear in the stack around the sections from the config file
<maxb> jelmer: Hi. Do you think it is worth updating ~bzr/ppa with bzr-git snapshots that you put into sid, or should the PPA be left on the latest release?
<vila> maxb: did you mean ~/bzr/beta ?
<poolie> ok, so it seems like moving things that currently construct configs to instead get a .config_stack from their object would be good
<maxb> vila: That would be the *other* thing we could do
<vila> maxb: putting snapshots in ~bzr/ppa sounds... weird. I thought we agree about using only official releases in stable, now I realize that ppa *always* define a release but you get my point (I hope)
<vila> poolie: right, that's part of the deployment in my mind
<vila> poolie: but *that* could be done with a minimal implementation
<poolie> vila, i think it could be done by just lifting out some common code today
<poolie> imbw, it may be more complicated
<poolie> in particular i guess we'd have to make sure it did not cause more io
<poolie> maxb, vila, fwiw i think shipping snapshots there is fairly ok
<poolie> ubuntu ships snapshots of some projects
<vila> poolie: well more IO than one IO by read and by write will be hard :)
<vila> poolie: in LTS ? And they get updated ?
<maxb> In this specific case, I'm operating on the basis that "If Jelmer thinks the snapshot is good enough for unstable/testing, I'm happy with it being in the PPA" :-)
<poolie> yes, in LTS
<poolie> presumably they get updated by patches, rather than by updating to new snapshots
<maxb> or not updated at all :-)
<poolie> vila, specifically, i want to make sure that if there is a case where at the moment we don't read a remote branch.conf, this change should not cause us to start doing so (and thereby doing one more rt)
<poolie> it's not a blocker just something to watch
<vila> poolie: +2
<poolie> in other news i would love if you, or someone, would fix bug 344013
<ubot5> Launchpad bug 344013 in Bazaar "bzr resolve should automatically resolve conflicted directory deletion" [High,Confirmed] https://launchpad.net/bugs/344013
<poolie> seems like it ought to be really easy!
<vila> poolie: as a workaround: bzr.transform.orphan_policy=move
<vila> poolie: I don't think it's easy :)
<vila> or I wouldn't have proposed orphans ;)
<poolie> nb this is (i think) the specific case where i've just rm -r'd the directory
<poolie> is it really hard to notice that?
<vila> no, what is hard is to extend the automatic resolution properly
<vila> (from memory)
<vila> and that may also be related to a single object being involved in several conflicts
<vila> imbw
<poolie> yes, i can imagine it might need some infrastructural work to the resolution machinery to make it possible to express this
<vila> poolie: you should try bzr.transform.orphan_policy too, since it's off by default and it triggers rarely when on, I got almost no feedback there
<vila> poolie: it's active here and on babune
<poolie> what do i set it to?
<vila> <vila> poolie: as a workaround: bzr.transform.orphan_policy=move
<poolie> ok, set
<vila> bzr help bzr.transform.orphan_policy
<vila> NIY :D
<poolie> i was just going to say that :)
<vila> joke aside, I'm not sure about how this should work from the command line
<vila> just DWIM ?
<poolie> i'll file a thing for it
<poolie> https://bugs.launchpad.net/bzr/+bug/747050
<ubot5> Ubuntu bug 747050 in Bazaar "want per-configuration-variable help" [Medium,Confirmed]
<vila> poolie: thanks !
<vila> poolie: http://paste.ubuntu.com/588152/ 'their configuration' ?
<vila> poolie: is that: a Store needs to know where its lockdir is or some other config option specific to the lock dir ?
<poolie> per-lockdir configuration
<poolie> eg, whether to automatically steal apparently dead locks
<vila> ha
<poolie> people probably don't want to actually set this per lockdir, but they might well want it per location
<vila> right, there is a chicken and egg issue there as config files needs a lock to access the file
<vila> so, yeah, probably something global but per-location
<vila> which can't be specified in the config file obviously
<vila> unless we special case bazaar.conf
<vila> >-/
<jam>  poolie: I responded before I finished reading the rest of my email
<poolie> ah i thought that was probably it - you were reading it in non-threaded mode or something
<poolie> i wondered a bit if there was a mail delay as has happened in the past
<poolie> jam, vila, is there a technical distinction between a checkout and a bound branch in bzr?
<vila> hehe, I'd say: you can't unbind a lightweight checkout ?
<vila> I never use checkouts, I only use branches, sometimes bound.
<poolie> ok, so the difference is that a lightweight branch has a 'reference' type branch inside it, rather than a bound branch
<vila> I'd love to replace looms/pipelines with colocated branches and integrate switch/up-thread/pump into core.
<poolie> me too
<vila> me too on branches or replacing ?
<poolie> i also would love to do that
<poolie> i mostly use colo branches, with some regular branches (in a repository), and occasionally checkouts
<vila> and adding colocated support via branch.conf should also be doable without a format bump by duplicating last-revision (or even last-loom (hmm, tricky one ;)) from some 'current' definition in branch.conf
<vila> that was a shameless plug ;)
<poolie> hm
<poolie> what is this to accomplish?
<vila> what ? branch.conf ? Replacing .bzr/branches
<poolie> oh, to put them all into that file rather than in the .bzr/branches sub directory?
 * vila nods
<vila> This will probably requires versioning branch.conf
<poolie> i don't know if that particular file is the right place
<poolie> we can have others
<vila> which raises the issue of conflicts there and how to resolve them
<vila> which can be somehow addressed by having a Store that revert to the last valid committed version (up to the empty file) if a parse error is encountered
<vila> that won't cover all cases but should ~work
<vila> but enough blue-skying ;)
<poolie> hm
<poolie> i'm wondering how we reconcile having a repository directory (containing branches etc) vs bzr-colo putting the repository just into the single bzrdir
<vila> forget about it and just use whatever repo is used by the branch ?
<poolie> so, don't create a repository when the colo is set up?
<poolie> that could work
<vila> yup
<vila> If we trust our fallback repos implementation to be robust, I'm also wondering whether we shouldn't start thinking about repos as a stack of read-only repos and one mutable one
<vila> ooooh, come on vila, stop with the shameless plugs will you ?
<poolie> hm, where?
<poolie> ?
<vila> well, in most cases we want one repo where we commit but we'd still like to find revisions wherever they are (think having lp as a repo fallback)
<poolie> right, that could be useful
<vila> or a local mirror or a ~/.bzr repo as a last resort before requiring a network connection
<poolie> i think some searches will be slower if there are many of them
<vila> yup
<vila> we need a better graph support including optimized queries across the network
<vila> but each repo should be able to maintain a cache of which revisions are known in each pack file, we can get rid of python bloating such caches by having a C implementation restricted to just a hash with revision-IDs as keys which should still be small enough
<vila> so that shouldn't be an obstacle to start thinking about such repos at the conceptual level
<vila> I'm not really introducing new concepts as far as the data model is concerned here, only new ways to use the existing ones
<poolie> it could be good
<poolie> i don't think it's very high up the stack
<poolie> i mean, i don't think adding multiple fallbacks is very urgent compared to other things
<vila> hmm, I think we already handle multiple fallbacks (but only for stacking), what we don't provide is a way to configure them
<vila> but yeah, not a top priority so far
<poolie> i'm wondering if we can deprecated bound branches
<poolie> just have checkouts with branch references
<poolie> there's a lot of old mail about this of cours-e
<poolie> good night all
<vila> poolie: g'night ! (but gimme my bound branches back ;)
<spiv> jelmer: it's nice to see a patch that adds to test_import_tariffs :)
<jelmer> spiv: Thanks :)
<jml> hey
<jml> I'd like to switch to using colo for launchpad hacking
<jml> please help me
<jelmer> jml: I don't have any experience using bzr-colo myself, but "bzr help colo-tutorial" should help
<jml> jelmer: ok, thanks.
<jam> vila: another "Welcome to Europe" for you. We did manage to get our furniture today. Everything made it in, except we couldn't get our Queen-size (150cm) box springs upstairs. (Neither through a window, nor through the stairway)
<jam> So now we have to go out and buy split box springs
 * vila bangs head on desk
<vila> jam: wecome back here :-}
<vila> welcome ggrr
<vila> jam: try futon ?
<jelmer> maxb: wrt your question this morning; I don't think it necessarily makes sense to upload snapshots to the beta PPA, it seems that if we're ok with doing that we might as well use the nightly builds
<jelmer> euhrm, daily builds
<vila> jelmer: I've got a test_tariff failure locally, probably a plugin, how to you debug that ?
<vila> found: builddeb
<vila> jelmer: fixed in trunk, thanks ;)
<vila> jelmer: don't bother answer my out-dated questions for bugs you already fixed :D
<jelmer> :)
<vila> jelmer: I still have failures with bzr-hg tip though ;)
<jelmer> vila: you mean test import tariff fails if you load bzr-hg ?
<vila> no no, different failures (re-running)
<jelmer> ah
<vila> AttributeError: 'HgRemoteRepository' object has no attribute 'lookup_foreign_revision_id'
<vila> AttributeError: 'HgLocalBranch' object has no attribute 'generate_revision_history'
<vila> etc
<vila> jelmer: urgh, 103 failures 654 errors
<vila> ./bzr tss -s bt.test_import with hg: ran 3 tests, 1 failure (bzrlib.foreign)
<vila> meh, not hg 8-/
<jelmer> vila: Oh, there's bound to be plenty of those. The per_branch, per_repository and per_workringtree tests don't work against the foreign formats yet, that's still a WIP
<vila> ok
<vila> bah, typo in the env var name, *no* tariff test failure when hd is disabled
<jelmer> vila: when *hg* is disabled ? :)
<vila> jelmer: yes, the test fails for hg, pass when hg is disabled, well bzr-hg of course ;)
<jelmer> vila: I suspect we may have to remove bzrlib.foreign from the blacklist, all foreign plugins import from it
<vila> I thought you put it there to ensure proper lazy loading ?
<jelmer> no, it was added when the test was initially written (presumably without any foreign plugins loaded)
<vila> ha ok, then I won't object if you remove it
<vila> well, if this can't be used to check for lazy loading that is ;)
<jelmer> vila: bzrlib.foreign is imported to access the foreign vcs registry
<vila> ... which reminds me that when I looked at the tests I was thinking: "Gee, we certainly need to explain why we blacklist these modules..."
<vila> jelmer: hehe, back to putting all registries in their own separate file are we ? :D
<jelmer> vila: None of these has ever changed either way afaik
<vila> jelmer: .. which doesn't mean that more comments will hurt ;)
<jelmer> vila: Shouldn't we rather explain why things are not blacklisted though?
<vila> jelmer: that was a general remark, don't take for you ;)
<vila> yeah, both will help people encountering failures for this tests
<vila> test
<vila> but may be just adding more tariff tests will render that useless
<jelmer> yeah
<jelmer> vila: MP proposed :)
<vila> jelmer: approved
<jelmer> vila: fwiw I have two more MPs up that add more entries to the blacklist :)
<jelmer> vila: thanks for the review
<vila> jelmer: I think *adding* doesn't need review, pqm will block and babune will double-check
<vanguard> how can I "checkout" a previous commit without uncomming the previous history?
<vila> .. if a problem arise
<jelmer> vila: Well, add a lazy import and then add to the blacklist
<jelmer> vanguard: "bzr branch -r<revno> thebranch newcopy-at-revno"
<vanguard> jelmer: okay, that sounds expensive ...
<jelmer> vanguard: You're asking about checking out a new copy - do you just want to reset the current tree?
<vanguard> jelmer: I just want to take a look at the work I did back then, basically for bisecting and stuff
<jelmer> vanguard: bzr revert -r<old-revno>
<vanguard> jelmer: I do not want to base new work on it
<vanguard> jelmer: but that will kill everything I did since that revision!?
<jelmer> vanguard: it will only reset the working tree - you can go back by running "bzr revert" after that again
<vanguard> jelmer: ah, okay, I see. Thanks!
<vila> vanguard: if your working tree is clean (no uncommitted changes) revert is fine
<jelmer> alternatively, you could export just that revision to a directory "bzr export -r<revno> /tmp/wt-at-revno"
<vanguard> okay, that sounds good.
<vila> vanguard: alternatively, if you can read diffs, bzr qlog/bzr qblame can also be used
<vanguard> vila: that might work for some cases, but if I need to build a previous version again, that will not help me
<vila> sure
<jml> I think running 'bzr colo-ify ../devel' inside a Launchpad working tree might have been a bad idea.
<jml> hah
<jml> *after* a very lengthy process I am told: bzr: ERROR: '/home/jml/src/launchpad/stable/' is already a lightweight checkout.
<james_w> jelmer, hey, was there a decision on https://code.launchpad.net/~jelmer/bzr-builddeb/fix-bz2-repack/+merge/54991 ?
<james_w> does someone want to take a look at https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/libxklavier/natty-201103311620/+merge/55787 and https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/glib-networking/natty-201103311614/+merge/55785 see if they are legitimate, and if not avoid doing it for similar situations in future
<james_w> plus https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/gst-plugins-bad0.10/natty-201103311110/+merge/55730
<jelmer> james_w: hey
<jelmer> james_w: Not yet, I'm planning to have another look at it today.
<james_w> jelmer, great, thanks
<maxb> james_w: Hi, since you're around, did you see the thread on bazaar@ on whether bzr-builddeb should aim to be able to function and/or run tests on an old distroseries that predates source format 3.0 support in dpkg?
<james_w> maxb, I did
<james_w> maxb, and I agree with both of you :-)
<james_w> hardy shouldn't have a lot of effort put in to it
<james_w> but the majority of the code and tests should be fine to work without the new features
<james_w> or is there something fundamental that requires the new version?
<maxb> only that 'bzr selftest' currently won't pass on hardy
<maxb> (for builddeb)
<maxb> So, perhaps have the tests in question require dpkg >= whatever?
<jelmer> maxb: that seems reasonable
<james_w> maxb, add a dpkgv3 feature and require it in those tests?
<james_w> I think that would be fine
<james_w> but I agree that hardy isn't a particularly important platform for a developer tool
<jelmer> "Ran 35295 tests in 21.551s"
<jelmer> Is it me, or does 21 seconds seem longer than it actually is?
<vila> jelmer: can I have some of your hardware ? I'd *love* run 35.000 tests in 20 secs
<jelmer> :)
<jelmer> have a good weekend everyone :)
<james_w> you too jelmer
<vila> jelmer: enjoy your week-end !
<jam> vila: you to
<jam> too
<vila> jam: and you too ;)
<vila> jam: hope you find a suitable bed ;)
<jam> vila: well, we still have the matress (which fit), just not the box springs
<jam> and we have our couches if necessary
<eridu> I keep getting a "KeyError: No such TDB Entry" after trying to check out an SVN repo, even after deleting ~/.cache/bazaar/svn -- how could I figure out what's going on? ~/.bzr.log doesn't seem to be helpful.
<maxb> eridu: Hi, do you have a traceback from ~/.bzr.log? That would usually help debug the issue?
<maxb> erm, lose that last ?-mark
<eridu> maxb: yeah, it's on launchpad, lemme grab the link
<eridu> maxb: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/747633
<ubot5> Ubuntu bug 747633 in bzr (Ubuntu) "bzr crashed with KeyError in get_revision_paths()" [Undecided,New]
<eridu> maxb: https://launchpadlibrarian.net/67919275/BzrLogTail.txt -- I can upload the rest of it if you want
<maxb> hmm
<maxb> Is the source repository public or private?
<maxb> oh, I see in the bug
<eridu> yeah
<maxb> OK, well, this is kind of cheating, but you could try uninstalling the python-tdb package, and seeing if the SQLite-backed cache provides better diagnostics :-)
<eridu> sure
<maxb> The other thing that could be interesting would be to modify /home/tedks/.bazaar/plugins/svn/cache/tdbcache.py to catch the KeyError and report what the revnum it is looking for is
<eridu> well, it seems to be working without python-tdb
<eridu> oh, no, it gives me this error: bzr: ERROR: A Subversion remote access command failed: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for
<eridu> that's odd, I thought that bug was fixed in bzr-svn 1.0.4
<maxb> for ..... ?
<eridu> for the path to the repo root
<maxb> hmm
<maxb> You could consider trying bzr 2.3.1 and bzr-svn 1.0.4+bzr3475 from the ~bzr ppa if you think it may have been fixed after 1.0.4
<eridu> sure
<eridu> upgrading now, though apt is holding back bzr and bzrtools --should I expect that?
<eridu> with tdb, I get the same error, with bzr-svn 1.0.5dev (reported by bzr plugin)
<eridu> ...and I get the same error with sqlite
<maxb> hmm, ok
<eridu> upgrading bzr to 2.3.1 doesn't help either
<eridu> it looks like this bug: https://bugs.launchpad.net/bzr-svn/+bug/409668
<ubot5> Ubuntu bug 409668 in Bazaar Subversion Plugin "accesses repository root" [Low,Fix released]
<ianm_> I have a local bzr repo (made with 'bzr init') that I'd like to move into a launchpad.net hosted project, can I bring it in with the commit history?
#bzr 2011-04-02
<mr-russ> ianm_: a push should do it.
<thomi> Hi - I've just posted bug #747958 - and a patch that I think fixes the issue, along with a small app that demonstrates the issue. I'd be most grateful for any feedback on this.
<ubot5> Launchpad bug 747958 in Bazaar "values given to make_log_request_dict are overridden" [Undecided,New] https://launchpad.net/bugs/747958
<vila> thomi: your patch is small enough that it seems obviously correct, so:
<vila> argh, he's gone
<johan> how do I merge two commits together and reorder them (like git rebase --interactive) ?
#bzr 2011-04-03
<sina_> beginner question: what is bzr's equivalent of "git checkout COMMIT" and "git checkout master"?
<sina> hello, what is the Bazaar equivalent of 'git checkout X' and 'git checkout master'?
<LeoNerd> Er... bzr checkout URL presumably..?
<sina> I need to examine an old revision of the code, how is that down it bzr?
<sina> *how is that done in bzr?
<LeoNerd> -r123
<LeoNerd> or whatever the revision number
<sina> bzr checkout -r123?
<LeoNerd> -rtag:SOME_TAGNAME
<sina> bzr checkout -r1 --> "File exists .bzr"
<sina> (sorry I'm very new to bzr)
<LeoNerd> Oh... in an already checked-out directory..?
<LeoNerd> revert
<LeoNerd> Or checkout in a new dir.
<sina> LeoNerd: that worked! thank you!
<LeoNerd> cd ..; bzr co -r123 existindir newdir
<sina> LeoNerd: that is very helpful :) how would you revert back to the latest revision?
<LeoNerd> bzr revert
<LeoNerd> Or maybe  revert -r-1
<LeoNerd> Negative revision numbers count backwards from head
<sina> LeoNerd: that's a nice shortcut
<LeoNerd> Highly useful
<LeoNerd> -c is also useful; represents a change rather than a revision.. -c 10 is the change committed at 10; i.e. between -r 9 and -r 10. Useful for diff, etc..
<LeoNerd> bzr di -c-1   # last committed change
<sina> LeoNerd: very useful, I'm trying to learn about the dev progress of an opensource project by reading its revisions step by step, so that's definitely going to help!
<LeoNerd> Yup, can be handy
<LeoNerd> Hopefully the project lays tags periodically, perhaps on releases and so on... I tend to do that..  bzr tags  should list them
<LeoNerd> Can be useful points to compare between
<sina> LeoNerd: yes, it does (the project is Zim)
<sina> LeoNerd: when/how often would you tag revisions?
<LeoNerd> Well, about 90% of my bzr work is Perl modules for CPAN; so I create a tag per numbered release
<sina> LeoNerd: I see...
<sina> LeoNerd: thank you for your useful tips, it helped to speed up my bzr learning progress :o)
<LeoNerd> :)
<sina> how would you look for a file in all revisions?
<LeoNerd> How do you mean?
<sina> I mean searching all revisions to find a file (for current revision I just do find -name "x")
<LeoNerd> What do you mean "to find a file"...
<sina> e.g. I want to see what revisions have a file named "setup.py"
<LeoNerd> Oh.. well presumablly all of them since it was added.. no?
<sina> is there any way to find out when (in which revision) it was added?
<LeoNerd> Something like "file history"..?
<LeoNerd> I forget quite; it's not a query I usually make. Prettysure it exists, though
<sina> ah yes, I searched for it, it's "bzr log filename" (the file must exist in the current revision)
<LeoNerd> Ahhyes
<poolie> good morning
<poolie> hi jelmer
<jelmer> 'morning poolie
<poolie> hey there
<jelmer> poolie: I went through the bfbip LEP the other day to see if there were any requirements that hadn't been addressed yet
<jelmer> poolie: It seems like the main thing that's not well defined yet is the security requirements
<poolie> perhaps we should have a u-d-d or u-d thread about that?
<poolie> or, perhaps make some more concrete proposals in the lep first
<jelmer> poolie: related, I wonder if it would make sense to split bfbip up into bfbia (build from branch into archive) and bfbip  (build from branch into primary)
<poolie> the first meaning building eg into a ppa, but with no recipe?
<jelmer> yep, basically - just being able to say from an API call "please build this revisions from this branch into that archive"
<poolie> and then the second would be mostly about just the policy change of letting it go into the primary archive
<poolie> that makes sense to me
<poolie> thanks for looking at this more
<jelmer> glad to be able to work on this :)
<jelmer> I'll gather thoughts and send an email to u-d-d this week
<poolie> ok
<poolie> i'm going to do another pass over the user documentation today
<poolie> both to pick out nits, and for larger changes
<jelmer> ah, cool
<jelmer> poolie, Is all the documentation under https://wiki.ubuntu.com/DistributedDevelopment/Documentation or is there more?
<poolie> ah i actually meant the general bzr documentation
<poolie> but yes
<poolie> hm, there might be some more in a separate packaging guide (draft?) by barry, that's integrating some of this
#bzr 2012-03-26
<kbulgrien> wow.  Personally, I am not a fan of commit whole workspaces at once.  That means bad checkin comments.  And when I am the guy that debugs other's work, I hate bad checkin comments and large commits.
<lifeless> kbulgrien: you can commit less than the whole
<lifeless> kbulgrien: its merely a default
<lifeless> kbulgrien: however, all of (git, hg, bzr) share this assumption that you want whole tree versioning
<poolie> kbulgrien, there's also some support for per-file commit messages
<poolie> it's not generally used though
<poolie> kbulgrien, i'm in favour of people making small changes and then committing the whole change
<poolie> when people commit only part of the changes to their tree
<poolie> there's a good chance that what they committed was never actually compiled or tested as a whole
<kbulgrien> I've just traditionally been the guy who had to fix other people's stuff.  Normally its not the author that cares about commits.
<poolie> i think you need a new tradition :)
<poolie> and maybe a water pistol
<kbulgrien> Perhaps.  It'
<kbulgrien> s a job.
<kbulgrien> Water pistol. hmm. never thought of that.  maybe a super soaker.
<kbulgrien> But then that doesn't work when the other guy isn't around anymore.
<poolie> that's true, what's done is done
<kbulgrien> as far as defaults on operating on the whole tree goes, that's not necessarily something I feel is worth getting bent out of shape about.
<kbulgrien> Not that there is much worth getting bent out of shape about, but...
<kbulgrien> its an expression.
<fullermd> Nono, it's _best_ when they're not around any more.  That way they never expect it!
<fullermd> For me, I was glad to get the full-tree action by default.  Took some getting used to, but still.
<fullermd> Look over my old CVS commits, you'll find way too many "Whoops, here's the rest of some recent change that didn't get committed 'cuz I wasn't high enough in the tree"
<poolie> yep
<kbulgrien> won't happen for me.  If I don't know what I'm committing, I don't have any business committing, IMO.
<fullermd> Typing "cd ../../../../../.. ; cvs diff ; cvs ci" gets old real quick.
<fullermd> I tried for a while having a whole separate freakin' xterm that always stayed in the root of the checkout so I could do my diff's and ci's from there.  It was just too stupid though.
<kbulgrien> people think fast is fast, but its usually not. slow (careful) is faster than fast.
<kbulgrien> I see it all the time.
<fullermd> True, but stupid tools are slower than slow.
<kbulgrien> :-)
<kbulgrien> And some discussions are like tarpits ;-)
<lifeless> fullermd: pushd $(cvsroot .);cvs diff -Nrup; popd
<lifeless> fullermd: where cvsroot is something you can write
<fullermd> Things that make committing less convenient tend to make you less likely to commit.  And that leads to way worse commit logs   ;)
<kbulgrien> hmph.
<kbulgrien> Discipline is discipline.
<kbulgrien> :-)
<fullermd> And eventually to the guy whose every commit log is "It's 4:30 on Friday, here's this week's work".  And then there's yelling, and screaming, and discharge of firearms inside city limits, and lawsuits, and...
<fullermd> That really slows things down.
<kbulgrien> That's a management problem.
<fullermd> Not any more   8-}
<vila> hi all
<vila> hey poolie
<poolie> hi there vila
<poolie> vila, we can have a chat whenever you like
<vila> poolie: see pm ?
<mgz> morning all!
<poolie> hi mgz
<Riddell> hello former colleagues, would anyone like to a peer performance review for me?
<mgz> less of the former
<mgz> maybe vila or jelmer would like to
<mgz> well, I'd like to, but am less useful.
<vila> mgz: hey !
<vila> Riddell: As long as it doesn't require any comment about driving, no problem ;)
<Riddell> vila: :)
<|_emming> hello, could anyone help me out with bzr basics?
<|_emming> which command do I use to just display the current revision of a remote branch?
<jelmer> hi |_emming
<jelmer> |_emming: bzr revno <url>
<|_emming> I tried that but it somehow does not work and always keeps telling me "not a branch"
<jelmer> |_emming: what sort of URL are you specifying, and what's the full error?
<|_emming> ah it works now, thank
<|_emming> just forgot to specify which branch to look at (stable/testing)
<mgz> hm, it seems like bugs 839426, 958551, and 963161 are all basically bug 663593
<ubot5> Launchpad bug 839426 in Bazaar "bzr crashed with UnicodeDecodeError in write_revision_to_string(): 'ascii' codec can't decode byte 0xe2 in position 4759: ordinal not in range(128)" [Undecided,Expired] https://launchpad.net/bugs/839426
<ubot5> Launchpad bug 958551 in bzr (Ubuntu) "Crash while committing" [Undecided,New] https://launchpad.net/bugs/958551
<ubot5> Launchpad bug 663593 in Bazaar "String inputs should be clearly defined and validated in commit builder" [Low,Confirmed] https://launchpad.net/bugs/663593
<jelmer> ah, hmm
<mgz> but what I don't get is why this new form is only showing up now
<jelmer> bzr-builddeb's commit hook?
<mgz> they're all on bzr-builddeb 2.7.0dev
<mgz> the fix is in 2.7.8
<mgz> but... why the run of recent reports with the different traceback?
<mgz> wait, linked the wrong bug
<mgz> maybe from oneric-proposed picking up a newer bzr version?
<mgz> but there not being a corresponding builddeb backport?
<jelmer> ah..
<mgz> bug 853664 fixes it I think.
<ubot5> Launchpad bug 853664 in bzr-builddeb "tries to decode debian/changelog as ascii, and fails when it's not" [Medium,Fix released] https://launchpad.net/bugs/853664
<mgz> hm, maybe I should have duped against the original bug and opened an ubuntu task for Oneiric?
<jelmer> mgz: I think that'd be the most sensible thing
<mgz> not that I'm sure backporting dev stuff is really the right thing, we expect everyone doing this to switch to Precise shortly right?
<jelmer> yes
<jelmer> (to both questions)
<vila> anyone knows a way to *change* a root-id ?
<vila> bug #965403 took me off-guard :)
<ubot5> Launchpad bug 965403 in Bazaar "all bzr plugins use TREE_ROOT as their root-id as does bzr itself" [Undecided,Confirmed] https://launchpad.net/bugs/965403
<jelmer> vila: I know how to do it programmatically, but not from the cli
<jelmer> vila: perhaps we should have a (hidden) 'bzr refresh-file-id' command?
<vila> jelmer: it's a delicate issue as I'm not sure you can still merge branches with different root-ids then
<jelmer> vila: you can, but you get conflicts when the other branch has added files
<jelmer> those conflicts can be resolved though
<jelmer> I have a few projects (especially packaging branches) where that's the case
<vila> hmm
<vila> I seem to be able to work around my issue by join'ing twice
<jelmer> whu?
<vila> (and some more hackery)
<vila> I created an empty branch to get a new root-id, join bzr-webdav into that, moved files, joined the resulting branch into bzr
<jelmer> ah, right - that's another way of changing the root id
<vila> oh, committed --unchanged after 'bzr init' to make sure jion won't get the webdav root-id ;)
<vila> yeah
<vila> at least in this use case, I won't ever try to merge this branch back into lp:bzr-webdav
<jelmer> vila: any chance of a quick review of https://code.launchpad.net/~jelmer/bzr/2.5-config-help-topics/+merge/99372 ?
<vila> jelmer: EOD'ing, but I will PP as hell tomorrow, I swear :)
<jelmer> nevermind, you already merged it :)
 * jelmer should've updated his 2.5 branch
 * vila blinks :)
<jelmer> that's the help topic fix for config options
<vila> yeah, merged long ago no ?
<jelmer> ah, actually - no
<jelmer> I'll let you look at it tomorrow
<jelmer> have a great evening :)
<mgz> ah, it's not in 2.5.1? the bug is wrong?
<mgz> and 2.6b1 isn't active any more...
 * mgz does some juggling
<jelmer> mgz: it's not fixed in 2.5 yet, only in 2.6b1
<vila> jelmer: make sure it doesn't trigger the doc building error for sphinx ?
<vila> jelmer: not sure they are related but ~worried
<vila> jelmer: bah, I'll check it myself tomorrow, don't worry
<jelmer> vila: I'm not sure why the two would be related?
<jelmer> works for me :)
<vila> jelmer: I don't remember the details 'make dosc-sphinx' ?
<jelmer> no, that's a different issue
<jelmer> this is 'bzr help branches'
<vila> ok
 * vila really off ;)
<mgz> ha, its great when writing some silly trivial test... and it actually fails because of a bug
<dakira> Hi. I just pulled an ubuntu source package using bzr (bzr branch lp:ubuntu:precise/package) and fixed a bug. I already pushed a private branch to launchpad (lp:~me/ubuntu/precise/package/fix). Do I just propose this for merging now, or is the process for ubuntu packages different?
<diodor> hi
<diodor> is there a way to create a branch from a subdirectory of a branch?
<poolie> hi all
<mgz> hey poolie
<mgz> must be time for me to descend
<poolie> ah, probably
<poolie> yeah that is pretty late
<poolie> you're on dst now?
<wgz> poolie: yep
<poolie> sleep well, i'll see you tomorrow
<jelmer> 'evening wgz, poolie
<poolie> hi there
<mwhudson> :(
<poolie> ?
<mwhudson> jelmer: what does "AssertionError: Invalid sha for <Commit bea9a47ad0d16bcfbe30b73f78730e351e25a881>: fc4e5248d29cf7264481cbff82343eade5fcc2ca" in a failing import mean again?
<mwhudson> jelmer: it's killing https://code.launchpad.net/~vcs-imports/notmuch/trunk
<jelmer> mwhudson: most likely that it's an import with a merged tag in it
<mwhudson> ah
<jelmer> which is a new thing in git
<jelmer> mwhudson: there's an open bug against dulwich/bzr-git/launchpad about it
<mwhudson> i thought git forbade new things :)
<jelmer> that I've been working on - it affects a fair few imports
<mwhudson> jelmer: how can i tell if that's the case on the git side?
<jelmer> mwhudson: git cat-file -p <commit-id>
<jelmer> mwhudson: it doesn't really forbid it, but it requires you preserve those fields
<jelmer> mwhudson: dulwich does this, but bzr-git doesn't round trip them properly (since it doesn't know about them)
<mwhudson> mergetag object 9325cae5f46e543aedb790cfe62a4faabcba949c
<jelmer> yep, that's it
<mwhudson> ok
<jelmer> should be fixed soon :)
<mwhudson> cool :)
<mwhudson> anything i can do to help?
<mgrandi> hello
<poolie> o/
<mgrandi> are there any plugins or planned features to have nested trees in bzr?
<mgrandi> like svn does i guess
<poolie> yes, i think the best at the moment is bzr-scmproj
<mgrandi> what doe scm stand for? oo
<mgrandi> o.o*
<poolie> software configuration management?
<poolie> there is also some work towards built in nested trees
<mgrandi> oh
<mgrandi> that just seem like it would be nested trees, probably why my google came up empty
<jelmer> mwhudson: some help testing would be great once it's done
<jelmer> mwhudson: also, you should get a more appropriate error with lp:bzr-git
<mgrandi> im just getting tired of extracting source releases of a library and then copying them over to a source tree i have and then updating =P would be nice to have it automated and just do update or something
<idnar> what project should I report a bug against if I want to complain about lp-propose-merge?
<mgrandi> might just be the bzr project
<mgrandi> i dont see a bzr-launchpad page on launchpad
<jelmer> idnar: yep, just the bzr project
<idnar> okay, thanks
<idnar> filed bug #965759 in case anyone else watching is as terminally curious as I am :)
<ubot5> Launchpad bug 965759 in Bazaar "lp-propose-merge has poor error reporting" [Undecided,New] https://launchpad.net/bugs/965759
<jelmer> idnar: hmm, that looks like a dupe
<jelmer> bug 704606
<ubot5> Launchpad bug 704606 in Bazaar "launchpad.branches.getByUrl() doesn't support properly urlencoded URLs" [Medium,Triaged] https://launchpad.net/bugs/704606
<mgrandi> but the idea of that it should also say the underlying error so its easier to debug =P
<idnar> hmm, maybe I was a little unclear
<idnar> although I'm pretty sure #704606 isn't actually related to either of the error messages in my report
<idnar> but I'm just complaining that it's impossible to tell what operation actually caused the error messages
<idnar> not any of the specific error messages, those were just examples to show how hard it is to figure out what went wrong
<mgrandi> that should be pretty easy
<mgrandi> you just have the original error message + the exception that originally got called
<mgrandi> unless there is some standard on how error messages should look that im not aware of
<idnar> I believe the first error message was actually caused by having submit_location set to something not on launchpad (at least once I fixed that, it stopped happening)
<idnar> (not really sure what caused the second one about diverged branches, I reran the same command later and it worked without me apparently changing anything; I think it may just have been Launchpad's bzr mirror catching up too slowly or something)
<mgrandi> hmm maybe
<idnar> (the last thing I did to the branch I was submitting before trying to run bzr lp-submit was a push --overwrite)
<idnar> anyhow yeah, not directly relevant to my actual bug report
<jelmer> idnar: bug 704606 is the cause of the second bug in your bug report
<ubot5> Launchpad bug 704606 in Bazaar "launchpad.branches.getByUrl() doesn't support properly urlencoded URLs" [Medium,Triaged] https://launchpad.net/bugs/704606
<jelmer> sorry, the first
<idnar> huh, okay
<idnar> I don't really understand why urlencoding would have anything to do with it
<idnar> the URL would have been something like file:///home/mithrandi/code/blahblah without any + signs or anything like that
<idnar> oh it might have had a . in it
<jelmer> ah, oh
<jelmer> so it's just the same error message but a different cause
<jelmer> never mind me then :)
<idnar> okay :)
#bzr 2012-03-27
<ritz> heya, ppa:bzr/daily  are these experimental packages ? How often do they break ?
<spiv> Daily ;)
<mgrandi> by nature daily packages are ...breakable
<ritz> hehehe :)
<spiv> Well, *usually* they are just fine, of course
<ritz> usually sounds good :)
<mgrandi> im sure its not garuenteed
<ritz> thats fine :) , as long as the fix comes in a week
<spiv> The test suite of bzr's trunk always passes, that's enforced by an automatic process, so there's a limit to how horribly bad it can be :)
<ritz> until then bz reports :)
<ritz> sweet, thanks :)
<spiv> You probably do want to be ready to rollback to the latest proper release in case of emergency, though
<poolie> o/ spiv
<ritz> I was unable to find bzr-colo in any ther ppa, and I like when things break infrequently
<ritz> spiv, naa, I have couple of VMs setup with stable branches
<spiv> And very occasionally if you have slightly different dailies on a smart server vs. smart client you might be get odd problems you would never see when using releases
<mgrandi> isn't colocated built in now?
<spiv> Hey poolie.
<poolie> mgrandi, it's a different format to bzr-colo
<poolie> (not drastically and they will be convertible but they are different)
<mgrandi> ah
<poolie> and i would say bzr-colo is a little more polished
<ritz> hmm, another question
<ritz> $ bzr branch lp:ubuntu/gtk+3.0
<ritz> Most recent Ubuntu version: 3.3.20-0ubuntu1
<ritz> Packaging branch version: 3.1.8-0ubuntu5
<ritz> Packaging branch status: OUT-OF-DATE
<ritz> How does one switch branch ?
<mgrandi> bzr switch?
<ritz> mgrandi,  seems to be http://package-import.ubuntu.com/status/gtk+3.0.html#2011-07-25%2009:43:52.029711
<ritz> from a short read of http://developer.ubuntu.com/packaging/html/udd-getting-the-source.html
<mgrandi> i do not know what that means :<
<ritz> neither do I, filing a bz
<mgrandi> yeah
<mgrandi> maybe one of the developers can figure out what that means
<mgrandi> but for now i must be heading off, bedtime, night
<poolie> https://www.youtube.com/watch?v=o9pEzgHorH0 - thanks lifeless, that's pretty awesome
<vila> hi all
<poolie> hi vila
<lifeless> poolie: de nada
<poolie> vila, did you get the link? you should watch it too, some time
<vila> I'm watching right now :)
<mgz> morning!
<poolie> hi there mgz
<vila> mgz: _o/
<mgz> where are we with timezones?
<vila> spread ?
<poolie> i'm still utc+11 til next weekend
<poolie> did you all go to summer time?
<poolie> i wonder if jelmer will be around?
<vila> I did this week-end
<mgz> hm, need to find a way of disabling video if we're going to use hangouts starting at 9
<mgz> or I'll murder my bandwidth allowance.
<ritz> mgz, rip out the webcam ?
<ritz> rmmod <module> ?
<fullermd> To say nothing of having to wear pants.
<mgz> the problem is downloading video from other people, not uploading :)
<vila> wearing pants is still relevant
<poolie> mgz, it varies over the day?
<mgz> yeah, it uses more units from 9-6 which has generally been a nice feature because I just schedual downloads for the middle of the night,
<mgz> and don't have to live with the silly hard caps other providers use
 * mgz wonders if fullermd has been in the US for too long, or if he often goes commando
<vila> I think he just uses a floating TZ
<vila> . o O (There is probably a joke related to drowning...)
<poolie> :)
<poolie> hm
<poolie> so are you two expecting our call to start now? or in 40m?
<vila> now
<vila> I haven't checked jelmer's TZ though
<mgz> I was expecting not to know, so set alarm for the earlier time
<poolie> :)
<poolie> ok, someone double booked me for the next hour
<vila> seems to be the same as me
<poolie> hm
<mgz> ...which didn't actually go off till just now, because phone still had the wrong time, but I woke up anyway
<mgz> so, shall we go now, can catch up jelmer when he surfaces?
<lifeless> gggggggg/win 48
<poolie> i'll take that as a yes :)
<poolie> ok let's do it
<lifeless> poolie: http://primeradiant.com/ may interest you
<poolie> lifeless, http://pitchfork.com/reviews/albums/13009-wavering-radiant/ :)
<lifeless> poolie: heh, so actually it was the narrower link I posted in #launchpad-dev
<lifeless> thats really interesting
<jelmer> hi mgz, poolie, vila
<poolie> hi there
<jelmer> Google calendar has our meeting listed as being in 17 minutes
<poolie> yeah, tz changes are annoying
<poolie> i think i had it in my tz
<jelmer> I think it must've been in ours - unless .au had a TZ change this weekend
<jelmer> we went from UTC+1 to UTC+2 this weekend
<poolie> we're changing next weekend, for bonus confusion
<poolie> jelmer, how about now?
<jelmer> poolie: works for me
<mgz> hm, how much of a massive rewrite of setup.py should go into 2.5
<mgz> I guess I'll do the minimum there and move things around on dev only
<jelmer> what are you fixing?
<mgz> well, directly, installation of .mo files,
<mgz> but the collected cruft of distutils hacks too
<jelmer> mgz: minimum in 2.5 seems most sensible, indeed
<mgz> it's still going to break things, I bet...
<vila> then dev first to stabilize I'd say
<mgz> you want installers or not vila? :)
<mgz> this is blocking 2.5.0-2 and 2.6b2
<mgz> *b1
<vila> 2.6b1 I hop... right :)
<vila> yeah, I want installers :)
<mgz> I could do another translation-less release
<mgz> but that's is bit lame.
<vila> but nothing forbids you to use local branches (tagged appropriately if you think it's worth it)
<vila> ha, no, remote setup makes that awkward right ?
<mgz> I've been doing manual merges
<mgz> but you just gave me an idea that could save that pain
<vila> in any case, if you're cleaning up setup.py you've already got +0.5 from me ;)
<mgz> no reason I can't commit a change to bzr-windows-installers that points the build at some other branch
<vila> good, I'll take credit for that then ;)
<vila> indeed
<vila> mgz: 'translation-less' ?
<mgz> no .mo files.
<mgz> okay, 2.5 branches up, will propose inasec when I have some food
<vila> mgz: did 2.5.0 had .mo files ?
<vila> mgz: if not, I won't object to dropping them from the whole 2.5 series and debug the remaining issues in the 2.6 one (as far as windows is concerned)
<vila> jelmer: see my pms ?
<wgz> my laptop screen appears to have died...
<jelmer> ouch :(
<mgz> and it's working again
<mgz> clearly giving it a bit of a rest while I had lunch was enough
<DktrKranz> Is it possible to define per-branch hooks? Documentation only explains about ~/.bazaar/plugins, which are executed for every branch.
<LarstiQ> DktrKranz: plugings can you use configuration to decide wether to act
<LarstiQ> DktrKranz: so for example bzr-email will not do anything unless the right option is set for the branch
<gnuoy`> mgz, afternoon, do you have anything you could throw at bzr pqm ?
<mgz> I shall look sir.
<gnuoy`> thanks, I hoping its less broken
<mgz> I have sent https://code.launchpad.net/~jelmer/bzr/2.5-config-help-topics/+merge/99372
<mgz> http://pqm.bazaar-vcs.org/ shows it building at least, we'll see how well it does.
<jelmer> that's a lot further than it got earlier
<gnuoy`> I think its fixed now
<mgz> is the test output slightly different or am I misremembering?
<mgz> looks like it's working at any rate.
<jelmer> thanks gnuoy`
<jelmer> gnuoy`: what was it, in the end?
<gnuoy`> ok, it was fun...
<gnuoy`> jelmer, when dchroot-run was moved to cupuasso
<gnuoy`> it was modified to use schroot not dchroot
<gnuoy`> and the command that lists locations was converted to an schroot command
<gnuoy`> only it had a small typo in it
<gnuoy`> which only becomes apparent when there is more than one chroot
<gnuoy`> so the addition of the second chroot with the existing bug broke it
<jelmer> aha
<jelmer> gnuoy`: thanks again, much appreciated :)
<gnuoy`> np, sorry it was bust
<mgrandi> hiya.
<mgz> jelmer: what versions of bzr-git and bzr-svn and deps do you want in 2.6b1?
<mgz> ...I'll go with the tags as for 2.5.0 for now, don't want to risk trunks
<mgrandi> and hi mgz
<mgz> and hi to you too mgrandi
<mgrandi> any more work on the dump i sent you?
<mgrandi> we have like a bazillion problems with fastimport now i forget what we are working on atm
<mgz> yeah...
<mgrandi> the dump was more just to see where the memory is going
<mgrandi> aka the original problem
<mgz> so, working out what accounts for the other chunk of memory was one thing
<mgrandi> and i think ive found a problem with bzr-git
<mgz> I had an idea we had the whole revision graph
<mgz> but don't remember the details
<mgrandi> what do you mean?
<mgrandi> 'had an idea'
<mgz> it seemed from poking things that lots of objects came from a graph cache with no apparent cleanup mechansim
<mgrandi> ah
<mgrandi> i dont know much about the bzr internals so you would be the expert there =P
<mgrandi> but, when i was trying ot test other git repos, i keep running into problems, mostly because git can tag files and other things
<mgrandi> and depending on the arguments given to git fast-exported, those can be exported (the tag) but the 'revision' (mark) that it refers to is not there, so that is making bzr fast-import die
<mgrandi> and i dont think that the arguments that bzr fast-import-from-git are enough to make sure that those don't get exported
<mgrandi> so i dont know if the solution is to just make it so you 'have to run git fast-export with these arguments' or to make the bzr fast-import code more resiliant to these kind of things
<mgz> well, presumably the latter, but can you do a minimal reproduction?
<mgz> make a trivial git repo with the problem, and get fast-import failing with it?
<mgz> that would then be a way in to fixing the issue.
<mgz> there are various other issues with new-fangled git things that are starting to get used
<mgrandi> yeah i can try that
<mgrandi> cause apparently 'any' git object can be tagged
<mgrandi> but then git fast-export filters out some of these, but leaves the tags, and its all very confusing
 * jelmer waves
<jelmer> mgz: what problem did you find with bzr-git?
<mgrandi> jelmer, it seems to be a problem when git tags.. a file
<mgrandi> and the arguments that are used in git fast-export, you can end up with a tag that has a mark/revision that isn't present cause git fast-export doesn't export it
<mgrandi> or something
<mgz> jelmer: I'm just thinking of the bug reports on signatures and things, which are mostly code-import rather than fast-import related
<jelmer> mgrandi: I'm not sure I follow - how is that related to bzr-git?
<mgz> jelmer: what I need from you is whether you have guidance on what versions of bzr-git and bzr-svn and deps need to be in 2.6b1
<mgrandi> is it bzr-git that handles the git fast import stuff? or is just fastimport
<jelmer> mgz: that's a good question
<mgrandi> if its just fastimport then ignore me
<mgrandi> =P
<jelmer> mgrandi: yes, that's bzr-fastimport
<jelmer> mgrandi: you can't tag files in bzr so it seems reasonable that that results in an error
<jelmer> mgz: trunk should be most appropriate in both cases
<jelmer> let me run the tests to see if there is anything missing
<mgrandi> yeah, but the question remains whether fastimport should handle that or should just assume that git fast-export should be run with the correct arguments
<jelmer> mgrandi: I think it would be reasonable for it to warn and skip
<jelmer> rather than falling over entirely
<mgrandi> yeah, thats easy enough for me to add since i have the line where its failing at home.
<mgrandi> and we still have that timezone thingy
<jelmer> right
<jelmer> mgrandi: well, patches welcome :)
<mgrandi> yay!
<mgrandi> what should happen with the invalid timezone
<mgrandi> just make it use +0000?
<jelmer> either that or what github does, which is just add the additional hours to the date
 * jelmer is mostly focussed on bzr-git these days, rather than bzr-fastimport
<mgrandi> ah
<mgz> jelmer: okay, and dulwich, subvertpy? leave on current revs?
<jelmer> mgz: subvertpy yes
<jelmer> mgz: for dulwich I think trunk would probably make more sense
<mgz> okay
<mgz> okay, buuuuilding
<DonDiego> hello
<DonDiego> when i uncommit i see messages like
<jelmer> maar hi DonDiego
<DonDiego> bzr pull . -r revid:diego@biurrun.de-20120327184815-t9xoi7ln0uuuwplh
<jelmer> s/maar//
<DonDiego> where are those commits stored?
<jelmer> DonDiego: they're in the repository
<DonDiego> i need to restore a commit :)
<DonDiego> jelmer: yes, that much is obvious, but how do i access and find them?
<jelmer> DonDiego: "bzr heads" will look for revisions that don't have any children
 * DonDiego tries
<DonDiego> nah, it's not there, that commit is lost i guess
<jelmer> DonDiego: You're looking for revid:diego@biurrun.de-20120327184815-t9xoi7ln0uuuwplh ?
<jelmer> DonDiego: bzr dead --dead-only
<DonDiego> what version of bazaar do i need for the "dead" command?
<DonDiego> i have 2.4.1 here
<jelmer> sorry, 'bzr heads --dead-only'
<DonDiego> oh, that could be it
<DonDiego> jelmer: i owe you $beverage
<DonDiego> or a flattr if you prefer and are into this newfangled stuff
<DonDiego> jelmer: thanks a million
<jelmer> heh, that's okay; glad it works for you
#bzr 2012-03-28
<kishor> hello
<kishor> i have gone through the documentation and considering my inexperience in the version control, i am finding it extremely difficult to understand the manuals.. I want to setup a central repository hosted on our ubuntu server... I am using bazaar-explorer as the team works both in ubuntu/windows ... any leads/links/directions will be highly appreciated
<vila> hi all
 * vila upgrades, bbl
<vila> doh, one of those *painful* upgrade :-/
<mgz> morning
<vila> mgz: morning ! Thanks for the installers !
<vila> mgz: I'm fighting with the last unity upgrade right now (lost my most used shortcuts :/)
<mgz> I did get to go to bed in the end...
<jml> hey guys, we have a couple of branches for udd that we'd like to see land soon:
<jml> https://code.launchpad.net/udd/+activereviews
<jml> (the 'stormify' and 'postgres' ones in particular)
<vila> given the backlog we already have on bzr and udd, I'm afraid we won't get to them shortly :-/
<jml> vila: we have patches for udd that date from mid-December, can we swap the recent patches with them in the patch queue?
<mgz> I looked at the db changes mps and the diffs didn't scare me
<mgz> am fine with approving them if you guys deploy it and chase up if things break
<mgz> jml: for instance, storm does not seem to be on jubany
<jml> mgz: ok. I'll have to talk with the team about that. Taking on responsibility for another service isn't a thing to do lightly.
<jml> mgz: although it's not out of the question either.
<mgz> I didn't mean for ever, just in response to james_w saying "care should be taken rolling this out"
<jml> how is udd trunk controlled? pqm? tarmac? manual test runs?
<mgz> the code looks fine to me, just can't commit to spending days debugging deployment issues
<mgz> dunno. manually, I belive.
<vila> jml: udd trunk is tested by deploying on jubany :-/
<jml> vila: heh
<jml> vila: you don't have anything that runs the test suite before landing changes to trunk?
<vila> oh yes we have ! We call them devs :)
<jml> vila: ok, thanks.
<jml> I'm just wondering whether we should schedule some work so that jubany's udd is run more like other Canonical services.
<vila> sounds fair
<vila> from the top of my head, we need branches for udd/bzr/bzr-builddeb, packages from -cat, and some settings for apache, start/stop gracefullty the importer itself and.. lp setup (credentials and ssh key)
<vila> ha, and the pgimport.conf which would probably be removed from the udd branch or something
<vila> ha crap and the crontab of course, anyway part of it is already documented in READE_DEPLOYMENT and the rest would have to be found while changing the deployment process :-}
<jml> yeah
<jml> we could probably puppetize that pretty easily
 * jml touches wood
<jml> the fab thing that landed already demonstrates what an automated deployment process could look like.
<vila> fab ?
<jml> vila: it's yet-another-Make replacement. if you run 'fab deploy-to-ec2' after doing some set up with keys and stuff, you'll get an ec2 instance with udd running on it.
<jml> vila: it's quick-and-dirty, but I needed something to test the binary package scan mode before I asked for it to be deployed on hadar.
<vila> fabric ?
<vila> yeah, fabric
<jml> yeah.
<jml> I'm looking forward to precise in the DC so we can charm up things like this
<jml> how can I set up my locations.conf for colo so that I can push branches to lp:~jml/$PROJECT/$BRANCH_NAME automatically
<jelmer> jml: for colocated branches or bzr-colo, the plugin?
<jml> jelmer: colocated branches
<jelmer> jml: afaik we don't have anything for that yet - possibly we should add a special config variable for that
<jelmer> (name of the current colocated branch in the current directory)
<LarstiQ> {nick}?
<jelmer> ah, that's a good point
<jelmer> that would usually work, unless you manually set branch nicks
<jml> jelmer: I guess append_path might work?
<jml> hmm, no, because it's not part of the path
<jml> jelmer: I guess if nick is set you would want to push to lp:~USER/PROJECT/NICK anyway
<LarstiQ> jml: and nick should default to colocated branch name now afaik
<jelmer> jml: yep, that should work though
<jml> LarstiQ: as in it does, or as in someone ought to make that the case?
<jelmer> jml: nick will default to the colocated branch name if no nick was manually set
<jml> nice
<LarstiQ> jml: as in let me check if that is in 2.5
<jml> LarstiQ: it is, I think.
<jml> is nick not available in the config?
<LarstiQ> jml: it is available as {nick} I think?
 * jml tries
<jml> push_location = lp:~jml/pkgme-binary/{nick} doesn't seem to expand.
<LarstiQ> jml: feh
<jelmer> vila: ^
<vila> yeah, nick is one of the few options not migrated yet
<vila> but {basename} works otherwise (at least for regular branches)
<jml> vila: what's basename?
<vila> the last part of the branch path, so ~/src/bzr/integration/trunk -> trunk
<vila> ~/src/bzr/trunk -> also trunk
<LarstiQ> hmm
<LarstiQ> vila: it does not seem to get expanded, but maybe I'm not setting it correctly
<vila> supporting {nick} will be nice (there was some pending discussion about changing when nick is updated related to master branches that I lost track about and was seen as a pre-requisite to the migration)
<vila> LarstiQ: it's not linked to an option so it can't be expanded
<vila> s/not linked//
<LarstiQ> vila: `bzr config 'push_location=lp:~/project/{basename}'; bzr push` => bzr: ERROR: Option basename is not defined while expanding..
<LarstiQ> vila: aha
<vila> LarstiQ: basename is a "magic" option that can only be set in locations.conf
<vila> so, correction, s/the last part of the branch/& when used in a locations.conf section/ :-/
<LarstiQ> check
<vila> it doesn't make a lot of sense to define it in branch.conf where it will always have the same value
<vila> and defining push_location in locations.conf is not a super idea either as it means it overrides whatever you put in branch .conf
<vila> so, lacking a defaults.conf, I currently defines mypush=lp:~vila/bzr/{basename} in my [/home/vila/src/bzr] section and then
<vila> bzr push `bzr config mypush`
<vila> mgz: ping
<mgz> poing
<luke-jr> Is it possible to get bzr to give me a 3-way diff of conflicts (HEAD, common parent, and merge source)?
<mgz> giving --show-base to merge puts in the base revision for content conflicts
<mgz> which you or your tools can probably interpret
<mgz> for funny things like move/delete conflicts that's no help
<mgz> remerging specific files with that flag added should sometimes help
<mgz> you can also configure an external merge tool
<luke-jr> can I make it default? :D
<mgz> yeah. where is that actually documented...
<mgz> http://doc.bazaar.canonical.com/beta/en/user-reference/configuration-help.html#bzr-mergetool-name
<luke-jr> might close https://bugs.launchpad.net/bzr/+bug/562669 then ;)
<ubot5> Ubuntu bug 562669 in Bazaar "merge should show base always, or at least configurably" [Medium,Confirmed]
<luke-jr> â¦ but I don't have an external tool :|
<luke-jr> I just want --show-base
<jelmer> luke-jr: bzr alias merge='merge --show-base'
<luke-jr> thxâ¦ guess I can deal with the conflicts manually
<luke-jr> (cmdline conflicts, mentioned in that bug)
<vila> jelmer: ping
<jelmer> vila: pong
<vila> jelmer: see pm ;)
<jelmer> btw, did you see my email about bundling plugins?
<mgz> have we got any tests for the bzrlib.transform progress display?
<mgz> ...I guess I'll just post a simple fix and worry about pains like that later
<vila> jelmer: yes, marked unread-need-to-answer
<vila> jelmer: by the way, I've seen the gtk ghost progress bar once this morning
<vila> mgz: hmpf, will be fun to add, no I don't think we have any
<converge> I wish to get the 6.1 version of this repository, can someone help me ? https://code.launchpad.net/~openerp-commiter/openobject-addons/trunk-extra-addons
<LarstiQ> converge: `bzr branch lp:openobject-addons/6.1` will get it
<converge> LarstiQ: thanks
<LarstiQ> converge: np
<poolie> hi all
#bzr 2012-03-29
<vila> hi all !
<LarstiQ> hey vila!
<mgrandi> hi
<poolie> o/ vila, larstiq
<vila> poolie: hey !
<mgz> morning
<poolie> hi mgz
<mgz> hey poolie
<vila> mgz: hey !
<mgz> canonical as a company name makes for some funny phrases
<mgz> I like "non-canonical copyright holders" from jelmer's email
<jelmer> mgz: :)
<jelmer> there's a company in the CIFS/SMB world called "LikeWise"
<mgz> ehehe, that's hillarious
<jelmer> also the cause of very amusing conversation sometimes
<mgz> private bug 968065 is a dupe of bug 894195 maybe?
<ubot5> Error: Launchpad bug 968065 could not be found
<ubot5> Launchpad bug 894195 in bzr-git (Ubuntu) "bzr crashed with TypeError in smart_add(): __call__() takes at least 5 arguments (1 given)" [Medium,Fix released] https://launchpad.net/bugs/894195
<jelmer> mgz: yes
<jelmer> mgz: marked as such
<mgz> hm, fun conflicts merging up from 2.4 to 2.5
<jelmer> feature flags related?
<mgz> not obviously, no
<mgz> ...some of it is find_format, so that will be.
<jelmer> the 2.4 changes there should be discarded
<jelmer> let me know if there's anything I cna help with
<mgz> so, I kill the find_format methods?
<jelmer> let me check..
<jelmer> mgz: the custom find_format that's being introduced in Branch, WorkingTree and Repository, yes
<jelmer> mgz: they're inherited from BzrFormat in 2.5
<mgz> ah, I think I understand this bzrlib.errors conflict now
<mgz> okay, that's got it I think, just ParseFormatError added is right.
<mgz> wait, now there are two...
<mgz> okay, drop the one without the format param.
<mgz> hm. both forms are used.
<mgz> bzrdir.extract_format_string has:
<mgz> raise errors.ParseFormatError(lineno=lineno+2, line=line, text=text)
<jelmer> bzrdir.extract_format_string shouldn't be in 2.5
<mgz> okay
<jelmer> that's merely a convenience function for the way features are handled in 2.45
<jelmer> *2.4
 * mgz re-eyes the diff for other additions
<mgz> okay, that's nearly sane now
<jelmer> mgz: any news on the new windows installers?
 * jelmer had another person hit the bzr-svn incompatibility
<mgz> posted them (late) the other evening when I said I was building them and bugged you about plugin versions
<mgz> translations are a little borked, but actually not quite as borked as I thought they were going to be,
<jelmer> ah, cool
<mgz> bzr-svn and bzr-git versions should all be happy.
<mgz> how do you spell cyrillic...
<mgz> I can't get close enough to make greping /etc/.../words work
<mgz> goooogle
<mgz> wait, that is how you spell it.
<mgz> I was sure I'd get a "Did you mean..."
<mgz> ...I didn't use -i
<mgz> and it's captialized >_<
<mgz> I'm not sure what the 'Cyrillic's' entry is about
<jelmer> mgz: can you mention when you've uploaded new windows binaries in https://bugs.launchpad.net/bzr-windows-installers/+bug/950751?
<ubot5> Ubuntu bug 950751 in Bazaar Windows Installers "Update broken with bzr-svn 1.1.2" [High,Fix released]
<didrocks> hey jelmer
<didrocks> jelmer: I just noticed something which puzzled me using bzr buildder
<didrocks> from this change: https://code.launchpad.net/~jelmer/bzr-builddeb/auto-apply-quilt/+merge/87555 all quilt patches are applied when bzr bd-do or bzr bd by bzr
<didrocks> however, there is no trace in the build log about them
<didrocks> not sure if run_quilt() is eating the output
<didrocks> (as you quilt push -a -v)
<didrocks> or it's because of the quiet parameter :)
<didrocks> but I think that you can wonder if the new added patch is applied (did you bzr add? add it to debian/patches/series)
<didrocks> (in fact, it just happened to me ;))
<mgz> jelmer: done
<jelmer> didrocks: you should see the output during the source package build
<jelmer> mgz: thanks!
<didrocks> jelmer: hum, just tried again and I don't
<didrocks> jelmer: I'm in merge mode if that can be of importance
<jelmer> didrocks: what's the build?
<didrocks> jelmer: just pushed the branch: lp:~compiz/libcompizconfig-backend-gconf/ubuntu
<jelmer> didrocks: I'm curious about the launchpad build log specifically, or was this using a local build?
<didrocks> jelmer: just the local build, the launchpad build log is fine and dpkg-source shows that it's applying patches
<didrocks> jelmer: just talking about bzr bd here (merge mode only related, maybe?)
<jelmer> ahh
<jelmer> you said bzr-buildder, which is a typo that can be read in two ways :)
<didrocks> ah? ;)
<didrocks> bzr builddeb? :)
<jelmer> I thought you were talking about bzr-builder, which also does quilt applying
<didrocks> ok, sorry for the confusion :-)
<jelmer> as far as I know run_quilt() shouldn't be eating the output
<jelmer> I'll try your branch
<didrocks> thanks ;) seb128 confirmed as well
<didrocks> (on another branch)
<didrocks> it's not a big deal, just puzzling until you know
<jelmer> yep, I can reproduce it too
<jelmer> it's a bug, we're returning the output to the caller, who ignores it
<jelmer> I'll file a bug and subscribe you
<didrocks> jelmer: excellent, thanks :-)
<vila> jelmer: why did you resubmit lazy-registries ? I can't reply anymore to the previous one, I don't have access to the intermediate diffs inline... it just makes my reviewer's life harder for ... what ?
<mgz> there are plusses and minuses
<jelmer> vila: I'd merged bzr.dev in between
<jelmer> vila: this refreshes the diff
<vila> ok, I think I see the minuses :) Tell me about the plusses :)
<vila> the diff is always refreshed
<vila> and the intermediate ones leave reviewers the choice of either checking them or re-review the whole
<jelmer> sorry :-/
<vila> resubmitting just make that impossible on both :-/
<vila> it may be a bug (or two) against lp that the 'reply' buttons are not there anymore (in both proposals) and neither are the diffs but :-/
<jelmer> vila: it's mostly a force of habit I guess, sorry
<vila> no worries, I thought I mentioned it anyway in case you could do that less often ;)
<vila> It's true that it's the way to go in some cases but in general I find it more disruptive and only ask for it (or do it) when the discussion is long and the proposal change enough to be worth creating a new one
<vila> (and also when I foobar the target ;)
<vila> jelmer: I find that merging  bzr.dev just before submitting leves the proposal cleaner. It's not always viable though.
<vila> jelmer, mgz: Is it only me or does clicking the proposal status button always display a new page now ?
<mgz> vila: check your js error log? you get a new page for changing the status when js is off.
<vila> . o O (js error log ??? kids these days...)
<vila> where the hell do I find that ?
<vila> wow indeed bunch of warnings there (~40 or something at least)
<vila> bah, the log in chronological order, most recent entries *last* ;_;
<jelmer> vila: do we really need a test for lazy_register_filter_stack_map when deprecating it ? That function didn't have any tests to begin with..
<jelmer> hmm, I guess it's not the hardest test to write, though
<vila> right, that was a bug :) Adding a test now will less costly than wondering in 6 months when deleting the function: where is the test ? Why isn't there one ?
<vila> exactly
<jelmer> vila: I'm not sure I understand why the test is necessary though?
<vila> because that's a good rule ? And easy to remember ? ;)
<jelmer> vila: I don't think that's a good rule for deprecated code
<fullermd> If you just outright delete it now, you avoid the issue  8-}
<jelmer> vila: if you're worried we'll spend time looking for tests when we remove the function in 6 months, can't we just add a comment ?
<vila> jelmer: I think the other review where I mentioned the issue was a better context but I can't remember which one it was
<vila> jelmer: saying 'there is no test for that ?', fair enough :)
<jelmer> vila: great :)
<jelmer> vila: thanks for the reviews!
<vila> hehe, I'm not done yet :)
<jelmer> ooh, even better :)
<mgz> vila: still online?
<vila> mgz: not for long :-/
<mgz> so, the future has been laid out
<fullermd> Sweet.  Got some stock tips for me then?
<mgz> sell.
<fullermd> Shoot, I could tell you that without laying out any future...
<mgz> ...being in the UK makes for depression at the moment
<mgz> it's sunny though.
<mgz> tortoise is happy.
<fullermd> ITYM "on earth".
<fullermd> It's sunny here too.  I hate it.
<mgz> I therefore deduce that you are not a tortoise.
<fullermd> D'oh.  You saw right through my shell game.
<fullermd> According to the thermometer hanging outside my window, it's 102 degrees.
<vila> no sun here
<fullermd> Of course, it goes way high, hanging in the sun.  TWC says only 77.  Still way too zarking hot for March.
<fullermd> Bodes ill for the summer.  I may have to hibernate for 5 months or so.
<vila> hehe, poor tortured meters...
<fullermd> Should get over 80 today.  And for most of the next 10 days, by the forecast...
<fullermd> vila: Are you waiting for anything from me on that date: bug?
<vila> remind the number ?
<vila> I think I was waiting for some confirmation
<fullermd> What, you want me to actually THINK now too?
<fullermd> bug 964171
<ubot5> Launchpad bug 964171 in Bazaar "date:today in log broken in 2.5+" [Undecided,Incomplete] https://launchpad.net/bugs/964171
<vila> well, you're not a troll, so hot temperatures shouldn't be a problem for your brain ;)
<fullermd> You had one reply that seemed to ask something I couldn't quite figure, but then another that seemed like you saw it and had some idea about fixing it.
<pmatulis> how do i revert a committed change?
<pmatulis> i already pushed this to l/p
<jelmer> pmatulis: "bzr merge -rNEWREV..OLDREV ." to unapply the changes between OLDREV and NEWREV
<jelmer> then "bzr commit -m 'Explain why'"
<pmatulis> jelmer: i'll try it, thanks
<fullermd> Colloquially, what you do is more "reverse" it.
<vila> fullermd: yeah, well, I was investigating and had a crash and lose track of this particular bug, thanks for the heads-up
<fullermd> Well, stop investigating bugs while you're driving!   :p
 * SamB wishes bzr would make some kind of effort to check locks for freshness ...
<jelmer> SamB: on the local machine, and with current versions of bzr it will
<fullermd> Yeah, 's nothing worse than stale lox...
<SamB> define "current"
<lifeless> fullermd: low
<fullermd> No, that's cows, not salmon   :p
<SamB> ... know a good way to tell mutt to delete all messages with bodies identical to the one I'm looking at?
<pmatulis> jelmer: so if i have revisions 9, 10, 11, and i want to blow away 10 i would do 'bzr merge -r9..11 .' ?
<fullermd> Don't think there is one.  If there's a sufficiently distinctive sufficiently short phrase in it, you could tag on it.
<lifeless> pmatulis: bzr merge -r 11..10 .
<fullermd> No, 10..9, if you want to get rid of 10.
<lifeless> bah
<lifeless> yes
<fullermd> (you're undoing the 9..10 change)
<pmatulis> fullermd: ah ok
<SamB> hmm, it looks like to upgrade bzr to the sid version I need to uninstall bzr-hg :-(
<mgz> SamB: current=2.5, but you can also enable it with a config option on older bzrs
<SamB> mgz: that's funny, I *had* 2.5 ...
<SamB> ... is there a way to disable these "Doing on-the-fly conversion" warnings ... ?
 * mgz double checks the lockdir code
<mgz> SamB: `bzr config --scope=bazaar locks.steal_dead=true`
<mgz> seems it didn't get flipped for 2.5 after all.
<SamB> thanks
<mgz> best way to lose the conversion warnings is to upgrade both sides to 2a
<mgrandi> hello
<mgz> hey mgrandi
<mgz> and how are you this evening?
<mgrandi> well, still morning for me haha
<mgrandi> spent all of yesterday at work trying to fix a problem where my universities wifi wasn't authenticating me >.>
<mgz> that's always joyous
<mgrandi> it was, even more since there is a wonderful layer of redtape and the left hand doesn't know what the right is doing, so pretty much impossible to talk to the people who can actually figure out whats going wrong
<mgrandi> and the 'public' wifi means i can (barely) only use a web browser, and some webpages don't work on that, but its fixed nwo
<mgrandi> HOWEVER, i was wondering, if there are any ways to test like...the integrity of a branch, unit tests or something, because i want to see if this bzr plugin for some IDE still works (it was last updated in early 2011)
<SamB> bzr has no magical knowledge of what the code in a branch is supposed to do ...
<mgrandi> i meant was
<mgrandi> the actual branch
<mgrandi> not what's inside of it
<SamB> you just want to check that it's not corrupt?
<mgrandi> yeah more or less. to see if the plugin works and isn't going to corrupt any repositiories i have
<SamB> "bzr check" does some stuff ...
<mgrandi> i knew of that, just wondering if there was anything else
<mgz> so, if the plugin itself has tests, you can run those
<mgrandi> it doesn't seem to have tests
<mgz> generally with `bzr selftest -s bp.PLUGINNAME`
<mgrandi> well its not a bzr plugin
<mgrandi> its a plugin for a IDE that interacts with bzr, somehow (haven't looked at it indepth yet)
<mgz> okay, not having tests is bad
<mgz> but in general, just make sure you mirror the branch you're working on somewhere else as well?
<mgrandi> yeah
<mgz> the main plus of dvcs is you have backups on everyone else's machines
<mgrandi> yeah
<mgrandi> it 'looks' like its just calling the bzr executable
<mgrandi> ShellCommandService.getInstance(project).execute(hgFile.getRepo(), "revert", Arrays.asList("-q", "--no-backup", hgFile.getRelativePath()));
<mgrandi> so i'll research it more.
<poolie> hi all
<jelmer> g'morning poolie
<poolie> hey there
#bzr 2012-03-30
<vila> hi all !
<mgz> morning all
<vila> mgz: hey !
<vila> mgz: pm'ing
<ggherdov> hi all. is the Hudson page for the bzr project publicly available ?
<ggherdov> Do you have an URL
<ggherdov> ?
<vila> ggherdov: http://babune.ladeuil.net:24842/
<ams_cs> jelmer: ping
<ggherdov> vila: great. thx
<mgz> ho hum hum.
 * vila hears Santa Claus, waits for gifts
<mgz> though I have a beard currently, I lack the hat.
<vila> I don't require a hat to accept gifts ;)
<Riddell> cor
<Riddell> so mgz jelmer and vila will be fighting it out for a management payrise? :)
<mgz> fighting it out to avoid it, I think
<mgz> the news is... not yet finished Riddell, there'll be some more announcements...
<mgz> and not on anything apart from internal lists, so no leaking :)
<Riddell> oh look a shiny thing over there!
<mgz> oo, shiny!
<mgz> they were just doing the wasteland on the radio, while I was cooking lunch
<mgz> somewhat apt.
<hazmat> hi folks, has something about bzr's interaction with lp changed recently..
<hazmat> this for example used to work on a machine with no lp login..
<hazmat> bzr branch lp:~fwereade/juju/warn-ignored-constraint
<hazmat> but now in addition to the lp login message.. it errors with
<hazmat> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~fwereade/juju/warn-ignored-constraint": no supported schemes
<rawr> probably bug 854713
<ubot5> Launchpad bug 854713 in Bazaar "InvalidURL "no supported schemes" resolving missing branch without launchpad login" [Medium,Confirmed] https://launchpad.net/bugs/854713
<hazmat> rawr, that's the cause, thanks
<vila> mgz: mumble ?
<mgz> sure, will just get coffee
<vila> good idea, doing the same (for once)
<jml> does lp-propose have a default file it looks in to populate the MP initial description?
<jml> I'd like to build my review cover letter as I go, if possible.
<james_w> jml, I think it has a hook that does it, there's a lpreview_body plugin or something that would be an example I think
<SeriousRay> Hey there. I'm trying to connect to a remote repository via SFTP/FTP. However bzr explorer automatically assumes my username on the remote repo to be the same as the one on my local machine. Now there is this authentification file, however apparently I can't to find any documentation on what to write there.
<fullermd> Try putting the username in the URL.
<SeriousRay> Ok thx. It semi worked. I had to specify the password in the url aswell :S.
<SeriousRay> When i specified only the username it gave me an exception error.
<SeriousRay> ook seems like it was caused by me specifying only the username in the previously named config file.
<SeriousRay> once i deleted it i could also only specify the username.
<SeriousRay> specifying only the username in the authentification config doesn't work neither.
<mgrandi> hallo
#bzr 2012-03-31
<hazmat> what's the state of bzr colocation support in core?
<hazmat> from the rel notes it would appears its in 2.5
<jelmer> hazmat: there is basic support for it in 2.5
<jelmer> hazmat: it's not yet really polished, and we haven't really advertised it for that reason
<hazmat> jelmer, thanks
<Pikkachu> how to deactivate and how to change location of bazaar log instead?
<Pikkachu> how to deactivate or how to change location of bazaar log?
#bzr 2012-04-01
<pikkachu> how to change location of bazaar log, or better, deactivate it
<hsn> i have project in 6 branches. every branch contains part of project tree. Is there some simple way to merge them together with history?
<LarstiQ> hsn: like having doc/ and lib/ in separate branches? In that case, `bzr join` might be what you want
<astraljava> Hi gang, I'm not using gnome-keyring on my system (Ubuntu Studio precise), so when I'm running `bzr launchpad-login $user`, I'm getting a warning about gnome-keyring not being able to connect to socket. I found a bug #906452 about it, but no solution (just speculation about an open bug on bzr-gtk, which I couldn't find).
<ubot5> Launchpad bug 906452 in bzr (Ubuntu) "console launchpad-login warns about gnome-keyring in Precise" [Low,Triaged] https://launchpad.net/bugs/906452
<astraljava> I know it's just a warning, but I'd rather not see it. :) What are my options?
<hsn> LarstiQ: yes, that is right, doing it now. very usefull
<hsn> I submitted bug report. bzr join screwed my repo - https://bugs.launchpad.net/bzr/+bug/971054
<ubot5> Ubuntu bug 971054 in Bazaar "Checkout of joined branches fails" [Undecided,New]
<jelmer> hsn: was any of the two branches created with bzr-git?
<hsn> no. just one was in old format
<hsn> if i do bzr update -r 1 ... -r 2 ... etc then it works to get good checkout
<hsn> also bzr revert & bzr update builds tree ok
<poolie> hi all
#bzr 2013-03-25
<hrw> hi
<hrw> is 'bzr lp-propose-merge' supposed to work?
<mgz> --help?
<hrw> sure, but such http://pastebin.com/WWYauQbV backtrace on lack of arguments?
<hrw> same when called with upstream branch given as argument
<jpds> Well, that looks like a problem with your preferred browser.
<hrw> jpds: firefox?
<mgz>   File "/usr/lib/python2.7/webbrowser.py", line 489, in register_X_browsers
<mgz>     register(browser, None, Chrome(browser))
<mgz> NameError: global name 'Chrome' is not defined
<mgz> that's either a bug in your copy of python 2.7 or a bad interaction with lazy import
<mgz> python issue 17541
<hrw> mkey
<mgz> python -c "import webbrowser"
<mgz> feel free to downstream that to ubuntu
<hrw> ok
<mgz> for now, you can probably downgrade your local copy of python
<hrw> or just open browser
<hrw> https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1159737
<ubot5> Launchpad bug 1159737 in python2.7 (Ubuntu) " Importing `webbrowser` module gives NameError in Python 2.7.4rc1 " [Undecided,New]
<hrw> feel free to confirm
<mgz> thanks hrw
<hrw> mgz: thanks for help
<hrw> I will probably not be hit by that again knowing amount of times I use bzr ;)
<hrw> have a nice day fellows
<maxb> Does anyone know how to deal with bzrlib objects hanging on to transports which then get closed by the server due to inactivity?
<maxb> I have a feeling this is what is causing most of the socket.error failures on the UDD importer
<mgz> hm, tickles a vague memory
<vedic> Hi, I am getting this error when I try to push to remote server. bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
<vedic> I was able to push to remote server earlier but then I have made changes to both the server (local and remote) and committed the changes in both. Now when I push the from local to remote, he shows error
<vedic> My local repo is upto date and that is what I want it to stay on remote as well
<jelmer> vedic: hi
<vedic> Hi
<jelmer> vedic: you can discard the changes on the remote server by running 'bzr push --overwrite'
<vedic> jelmer: It says:  bzr push --overwrite
<vedic> bzr: ERROR: No push location known or specified
<jelmer> vedic: you would still need to specify the remote location
<vedic> jelmer: it says This transport does not update the working tree. See 'bzr help working-trees' for more information
<jelmer> vedic: that's because you have a working tree in the remote location
<jelmer> vedic: as the warning says, see 'bzr help working-trees' for more infiormation
<vedic> jelmer: Should I use remove-tree
<jelmer> vedic: either that or 'bzr update'
<vedic> jelmer: Ok, I did bzr remove-tree on remote location it did remove but few directories are not empty and it didn't remove. bzr update is giving error
<jelmer> vedic: 'bzr update' will no longer work if you removed the working tree
<vedic> jelmer: opps
<jelmer> vedic: it's correct there are still files there, you've only removed the working tree, not the rest of the bzr files
<vedic> jelmer: so can I push to remote location?
<jelmer> vedic: with --overwrite, yes
<vedic> jelmer: ok, I did and now I have updated files in remote location with bzr checkout
<vedic> jelmer: Thank you
<vedic> jelmer: I would like to understand these things. Any tutorial you suggest? Online docs?
<jelmer> vedic: I think the main bzr docs have some background
<vedic> ok
#bzr 2013-03-26
<quicksilver> is there a commandline way to say "list the files which were modified in versions X..Y" ?
<quicksilver> the info from bzr log -v, but just the files changed
 * quicksilver opts for bzr diff -rX | egrep '^===' |  awk -F\' '{print $2}'
<fullermd> stat takes -r
<quicksilver> ah, that would have worked
<quicksilver> thanks :)
<ggherdov> Hi all. This is the kind of questions that, when I'll be able to answer it w/o a blink, I'll consider myself good at version control. You have the situation shown in this picture http://imgur.com/AqeYP4H , where both Tigger and Winnie fork from a repo; Tigger adds file X ; Winnie likes it and merges Tigger's branch; Winnie doesn't touch file X anymore; Tigger continues working on file X;
<ggherdov> at a given point, they both converge (are merged) to the original repo. Question: is this a conflict, or the algorithm is smart enough to understand that Tigger has the most updated version?
<beuno> ggherdov, these are text files, yes?
<ggherdov> beuno: yep
<beuno> ggherdov, so it'll try and do a clean merge if the changes are on different lines
<beuno> and if not, conflict
<beuno> you get to resolve and decide what wins manually
<beuno> I'm pretty sure bzr has no sense of time in merges
<beuno> (timestamps are computer-specific)
<ggherdov> beuno: so you say that bzr would rise a conflict? (yes, line "boo" is changed to "baloo") I see.
<ggherdov> i'll check and see
<beuno> ggherdov, there was no change to "boo" in the winnie branch
<beuno> so when merging in, it shouldn't overwrite it
<ggherdov> beuno: exactly (sorry I was afk for a lil while)
#bzr 2013-03-27
<frathgeber> jelmer: i found this answer from 3 years ago saying there is an option `bzr diff --format=git-am`: https://answers.launchpad.net/bzr/+question/106814
<frathgeber> has that since been removed?
<frathgeber> i'm using bzr 2.6.0~bzr6573.6287~ppa4050~precise1 and bzr-git 0.6.9+bzr1613~ppa131.1471~precise1
<frathgeber> another more recent answer from you (https://answers.launchpad.net/bzr/+question/204262) seems to suggest it has
<jelmer> frathgeber: Hi
<jelmer> frathgeber: you need the bzr-git plugin
<frathgeber> jelmer: i have bzr-git 0.6.9, but it complains about not knowing --format=git-am (--format=git works)
<jelmer> frathgeber: ah, I think you want 'bzr send --format=git-am'
<frathgeber> jelmer: send doesn't seem to like that format either: bzr: ERROR: Bad value "git-am" for option "format"
<frathgeber> jelmer: my real question is acutally this, wondering if you might have an idea? http://stackoverflow.com/q/15660467/396967
<frathgeber> i was just thinking we might be able to circumvent the problem with exporting a patch series
<frathgeber> jelmer: according to `git help send` the valid format options are 2 and 4
<jelmer> frathgeber: bzr send --format=git perhaps?
<jelmer> frathgeber: if that doesn't work either, then you are probably running a version of bzr or bzr-git that is too old
<jelmer> frathgeber: for general imports from bzr to git, you can also use "bzr dpush" to create the git branch
<frathgeber> jelmer: jep, bzr send --format=git seems to be supported but crashes: i suspect in the version of bzr-git the send command is not compatible to bzr 2.6.0dev3
<frathgeber> jelmer: re dpush: this will first convert the bzr branch to a bzr-git repository via dulwich i assume? and then push to a git remote?
<frathgeber> presumably this will require using dpush to initially populate the git repository? what about dpushing multiple bzr branches? will they maintain the correct ancestry relationships also over on the git side?
<jelmer> frathgeber: dpush is easiest when you are pushing to a local git repository
<jelmer> frathgeber: dpushing multiple bzr branches will have related ancestry
<jelmer> frathgeber: you'll have to create a local git repository and an (empty) branch in it before you can dpush to it
<frathgeber> jelmer: ok, thanks. so the result is equivalent to using bzr fast-export | git fast-import?
<jelmer> frathgeber: no, it's a different history from what fast-export/fast-import would create
<frathgeber> in what way?
<jelmer> frathgeber: there are likely subtle differences in the way the git commits are created
<frathgeber> ah, ok. so the revision DAG will be the same but the SHA1s?
<jelmer> frathgeber: yeah, the SHA1s will be different
<frathgeber> can i dpush to a bare git repo?
<jelmer> the ancestry graph should have the same shape; bzr dpush preserves the shape that it had in bzr, I'm not entirely sure about fastexport/fastimport
<jelmer> frathgeber: yes, though there needs to be an empty branch in that repo
<frathgeber> how do i create an empty branch?
<frathgeber> jelmer: wouldn't the branch normally only be created when i push to the bare repo for the first time?
<jelmer> frathgeber: "bzr init /path/to/git/repo" should do it, assuming the git repo already exists
<jelmer> frathgeber: "bzr dpush" was designed mostly to contribute to existing git projects from bzr
<jelmer> ideally it would indeed create new branches too, but I never got around to implementing that
<frathgeber> ok
<frathgeber> so if our base is the bzr repo, we export to git and then make changes on the git side, we should be able to sync them back to bzr, but only if we have *the same* bzr-git repo that was created for the conversion. is that approximately correct?
<frathgeber> jelmer: created by dpush i mean. and this repo will have different bzr commit ids than the "original" bzr branches, so the original bzr repo and the bzr-git repo will appear (to bzr) to not share any history, right?
<jelmer> frathgeber: basically, yes
<jelmer> frathgeber: "bzr dpush" will update your local bzr repository to only have data that can be represented in git
<jelmer> frathgeber: and will basically have the same contents as the result of "bzr branch /path/to/your/git/repo /clone/in/bzr"
<frathgeber> jelmer: yep, that makes sense and was what i assumed it would do
<jelmer> frathgeber: you can use --no-rebase to preserve the original bzr repository. in that case, "bzr pull /path/to/new/git/repo" will give a "diverged branches" error
<frathgeber> ok
<frathgeber> jelmer: unfortunately that means that it probably won't help in our use case: the main problem i'm describing in http://stackoverflow.com/q/15660467/396967 is that we 1) export bzr -> git 2) filter the git repo (strip some files from history)
<jelmer> frathgeber: dpush takes care of step 1, filtering the git repository can be done independent of that
<jelmer> frathgeber: do you care about working in git and bzr?
<jelmer> I thought you just wanted to do a one-off migration to git?
<frathgeber> jelmer: yes, so far there's no problem. but now we want to be able to migrate further branches over to the filtered git repo while preserving their ancestry
<frathgeber> jelmer: yes, it's a one-off migration
<jelmer> frathgeber: that should work fine, as long as you do the filtering in a way that's consistent
<jelmer> (i.e. so the same filter command on the same commit generates the same result commit with the same sha1)
<frathgeber> jelmer: i *think* that's the case. however i'm still not sure how that would work in practice: would whoever wants to import another branch have to repeat steps 1) and 2) on their branch and then push?
<jelmer> frathgeber: yes
<jelmer> frathgeber: another option is to just do the import and then just have a commit on trunk that removes the problematic directory
<jelmer> you could always rewrite the repository history in the future to strip out those large files
<frathgeber> jelmer: yes, but that would require every contributor to get a fresh clone of the rewritten history, pay attention to not accidentally push from an "old" clone etc. that's why we rather do it in the conversion process
<frathgeber> jelmer: the bzr -> git migration will require that anyway, so we'd rather do it now and be done with it
<frathgeber> jelmer: however we don't necessarily want to import *everyone's* branches because some of them might well be dead/dormant. so we'd rather have a safe and easy to use migration path for our collaborators/contributors and their branches
<jelmer> frathgeber: I would argue that that's mostly a git question; if you have multiple related branches, can you run a filter command that will keep consistent identity for the commits they have in common
<frathgeber> jelmer: yes, git filter-branch can do that. i'm starting to think that maybe we can't get round importing everyone's branches all at once and run the filtering afterwards
<frathgeber> that seems to me to be the only safe option
<frathgeber> jelmer: would the git smart server help? bzr serve --git?
<jelmer> frathgeber: I don't see how it would. whatever you do, the filtering is the issue - not the importing from bzr
<jelmer> frathgeber: bzr can create consistent git commits for a particular bzr repo
<jelmer> s/particular bzr repo/bzr repo with the same history/
<jelmer> if two people run bzr dpush on seperate branches of your project and they each have revision X in bzr then they will both end up with revision X' (with the same SHA1) in git
<frathgeber> ok, i think the same is true with fast-export
<frathgeber> jelmer: yes, i agree the filtering is the issue. i was hoping i could maybe integrate the filtering in the export pipeline i.e. bzr fast-export | filter | git fast-import
<frathgeber> and ideally combine that with writing marks files on both end to save having to redo the work for every branch (but only ex/import missing commits)
<frathgeber> i was looking at git_fast_filter which appears to be designed for that purpose: https://github.com/maxandersen/jbosstools-gitmigration/tree/master/git_fast_filter
<frathgeber> but it can only deal with git fast-export streams, it chokes on bzr fast-export streams
<jelmer> frathgeber: even with --plain?
<frathgeber> seems so, yes
<jelmer> frathgeber: how does it fail?
<frathgeber> it dies on this line: https://github.com/maxandersen/jbosstools-gitmigration/blob/master/git_fast_filter/git_fast_filter.py#L720
<jelmer> I doubt you can reuse marks files in this case btw, because the marks file was generated for a slightly different stream than the resulting stream after the filter
<frathgeber> jelmer: yes, i was thinking about that: there might be revisions disappearing because they only touch stripped files
<frathgeber> jelmer: it chokes on this line in the fast-export stream: "M 644 inline .hgignore" (which doesn't match the regex pattern)
<frathgeber> jelmer: but as you say, it's potentially unsafe anyway even if i could get it to work. i'm more and more leaning towards importing all branches before filtering
<clyon> Hi. I have a problem with bzr on the gcc repo in launchpad.
<clyon> bzr revno lp:~christophe-lyon/gcc/4.8-disable-peeling2
<clyon> bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {svn-v4:138bc75d-0d04-0410-961f-82ee72b054a4:trunk:196812} because its ancestry shows a ghost at {svn-v4:138bc75d-0d04-0410-961f-82ee72b054a4:trunk:196812}')
<clyon> bzr --version
<clyon> Bazaar (bzr) 2.5.1
<clyon>   Python interpreter: /usr/bin/python 2.7.3
<clyon> The host is running Ubuntu 12.04 (x86_64)
<clyon> How can I fix this?
<fullermd> Is it just a remote issue?
<clyon> Sorry, what do you mean by remote?
<fullermd> I mean, does it happen only when you try to revno the branch on lp, or does it happen when you have the branch locally too?
<clyon> Only remotely.
<fullermd> Ghosts have always been a fruitful source of bugs.  So I wouldn't be surprised if there were one hiding in the twisty details of whatever RPC calls revno makes on remotes.
<clyon> From another host running bzr 2.1.4/python 2.6.5, it works
<fullermd> Probably that version is old enough that it's really "dumb" about how it goes about doing a remote revno.
<clyon> Too bad. What can I do? (I don't know how that mirroring of GCC works, from svn to bzr)
<fullermd> Probably not much; it sucks having a history with ghosts, so if that's avoidable it would be good.  But it's often not.
<fullermd> It IS a bug in bzr that revno fails in that way (I mean, it would be a bug blowing up all over the place, but it's _definitely_ a bug that it blows up in remote but works locally)
<fullermd> So it's worth filing a bug on.  Or fixing yourself, but that'll take time and knowledge of what are probably some of the uglier bits of bzrlib.
<fullermd> Since it's fairly well localized, it's probably a relatively tractable bug at least.
<clyon> How can I workaround it? It's used in our validation script, which monitors the bzr database...
<fullermd> Mmm.  Well, you can try decorating things to not use the smart methods.  Calling directly to the HTTP URL would work, or I think a nosmart+bzr+ssh (or is it bzr+ssh+nosmart?).  Have to bypass the lp: directory service, but that's easy enough.
<fullermd> If it fits, better would be to have a local branch mirror and revno against it.
<clyon> OK. I have to read the doc about nosmart :-)
<fullermd> Looks like it's nosmart+b+s:
<fullermd> % bzr info bzr+ssh+nosmart://localhost/nonexistent
<fullermd> bzr: ERROR: Unsupported protocol for url "bzr+ssh+nosmart://localhost/nonexistent"
<fullermd> % bzr info nosmart+bzr+ssh://localhost/nonexistent
<fullermd> bzr: ERROR: Not a branch: "nosmart+bzr+ssh://localhost/nonexistent/".
<LarstiQ> that revno error happens with bzr.dev too
<clyon> bzr revno nosmart+bzr+ssh://launchpad.net/~christophe-lyon/gcc/4.8-disable-peeling2
<clyon> ssh: connect to host launchpad.net port 22: Connection refused
<fullermd> Nah, the branch URL is a little different.
<fullermd> If you've got a local mirror of the branch, you can just grab the URL from it.
<fullermd> Or I think...
<fullermd> Yeah, you can do a "bzr info lp:whatever" and get the full URL from that.
<clyon> Indeed.
<clyon> bzr revno nosmart+bzr+ssh://bazaar.launchpad.net/~christophe-lyon/gcc/4.8-disable-peeling2
<clyon> 122393
<clyon> Thanks!
<fullermd> Actually, now that I think about it, I think you can 'nosmart+lp' even.  That's simpler.
<clyon> Confirmed!
<fullermd> Worth filing a bug en passant anyway, just for doc purposes.
<clyon> OK, I will do it.
<clyon> Just reported as #1161018
<fullermd> bug 1161018
<ubot5> bug 1161018 in Bazaar "bzr revno fails on ghost ancestry" [Undecided,New] https://launchpad.net/bugs/1161018
 * fullermd waves at vila.
#bzr 2013-03-28
 * xnox just saw commits by "Arch Librarian <arch@canonical.com>"
 * xnox slowly backs away
<mgz> if you cross the arch librarian, he will set is sub librarians on you
<xnox>  /o\
<Sebboh> So, here's what I've done so far (approximately).  apt-get install bzr; bzr checkout bzr+ssh://blah-blah foo; cd foo; bzr --help; bzr status  ...And then it told me that like, all the files were modified.  So then I immediately joined here to complain about this, rather than like, google it.  What exactly should I google here?  "bzr doesn't act as I expect"? :/
<Sebboh> Do we have some local definition of 'modified'
<beuno> Sebboh, so
<beuno> what is modified in them?
<Sebboh> I *just* checked them out.  omg, maybe it's permissions.  I checked out into a filesystem that doesn't support permissions.  Does bzr consider permissions changes to be modifications?
<beuno> yes
<beuno> that's why I ask
<LeoNerd> Ooh.
<galaxyAbstractor> Hey, I am trying to push something to launchpad, but all I get is "bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; [Error 2] The system cannot find the file specified". Anyone knows what's up? How is that missing file related to not being able to connect to the host?
<beuno> bzr diff will tell you
<galaxyAbstractor> (I can ping the host just fine and connect to it trough putty)
<LeoNerd> If the permissions of the files on disk don't match what bzr thinks they should be, then yes.. that will count as a difference
<Sebboh> I'm reading back over my messages in here, and I'd like to apologize for my tone.  I'm trying to quit cigarettes... :(
<fullermd> I have a friend who had a plan for that.
<fullermd> His theory was that you shouldn't fight it.  Anytime you want a cigarette, just go ahead and eat one.
<Sebboh> lol
<mgz> galaxyAbstractor: so`ssh -vv YOURLPUSERNAME@bazaar.launchpad.net` gets you through to the now shells message? then look in your log for the full traceback and pastebin it, `bzr version` tells you where to find the log
<galaxyAbstractor> mgz http://pastebin.com/J5xm3Kra
<mgz> pants
<mgz> galaxyAbstractor: run the same command again with BZR_PDB=1 set in the environment,
<mgz> then when you're dropped into the debugger,
<galaxyAbstractor> and then?
<mgz> hit 'u', then 'p orig_error', then 'p argv' and double check that the first item in argv actually exists on disk
<galaxyAbstractor> oh, where is plink.exe supposed to go? I have it in my downloads folder but maybe I had to put it somewhere else? The guide didn't really say anything about that
<galaxyAbstractor> I would assume that's the issue?
<galaxyAbstractor> This is what I get http://i.imgur.com/xldx8DM.png
<mgz> I set the full path to plink in BZR_SSH
<mgz> so, C:
<mgz> er...
<mgz> BZR_SSH=C:/Program Files/putty/plink.exe or whatever
<galaxyAbstractor> oh, the Create ssh key said that value should be only "plink" so that's what I put https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<galaxyAbstractor> I feel quite stupid about that
<mgz> it can be only plink, but then it must be on your path
<mgz> I can edit that page to be clearer
<galaxyAbstractor> yeah, it works now, thanks
<mgz> ace
<galaxyAbstractor> is plink optional tho? Seems like I'm the only one in class that used plink, and it works fine for everyone else without it
<mgz> ...that page is so confusing...
<mgz> I use plink, various other people use paramiko (a python ssh library) that we bundle with the all-in-one installer
<galaxyAbstractor> Most only did the pageant step tho
<greggypoo> hi - I'm a long-time rcs user who recently learned git and I love git, and I am forced to use bazaar for a certain project, and I am finding it awkward, I am always running into "surely this is easy and will sort itself out like it does in git," but it always turns out to be clunky and slow and difficult instead.  but i'm super ignorant of bazaar (and pretty ignorant of git if it comes down to it)
<greggypoo> so what i'm looking for is a flame war between a seasoned git user and a seasoned bzr user, i think if i could read such a thing it would honestly help me understand bzr better
<greggypoo> any ideas :)
<mgz> just read the user docs, from core concepts onwards?
<maxb> greggypoo: I'd suggest just asking about specific issues here. There are plenty of people who can help you find equivalent bzr concepts to git ones
#bzr 2013-03-29
<greggypoo> ok here's the workflow i'm aiming for.  i check out a bzr project from launchpad, branch it to make my changes, and then start hacking on my extensive set of changes..
<greggypoo> after commiting several changes, i discover an unrelated bug, so i fix it, and that is its own commit
<greggypoo> what is the proper way to make a "pull request" or what-have-you to ask upstream to incorporate my bugfix but not worry about my other changes yet?
<SamB_> greggypoo: can you do that in git either?
<greggypoo> it's trivial in git but i have no idea how it is done in practice, i'm a total newbie to github for example
<greggypoo> if i had to dance around upstream requirements in git, i would just make yet another branch and cherry-pick my bugfix into it
<greggypoo> i keep thinking i must fundamentally not understand bzr, because i think that making a new branch in bzr is expensive
<lifeless> greggypoo: you put it in its own branch; making a branch is cheap.
<lifeless> greggypoo: however you need to either be using bzr-colo or have setup a shared repo for yourself locally.
<lifeless> for it to be ultra cheap
<greggypoo> when i made my first branch, it copied 400MB of history.  i think "shared repo" is probably what i needed to hear, though.
<greggypoo> thanks
<greggypoo> thanks again - shared repository truly does answer the vast majority of my complaints with bzr
<mgrandi> <3
<greggypoo> ok, i can live without this, but...is there anything like "git add -p" ?  it shows you the diffs one at a time, and asks if you want to make it part of the next commit
<mgrandi> there is sort of something like that
<mgrandi> there is bzr qshelve that will show the hunks
<mgrandi> and then you can 'shelve them' if you dont want to commit them at this moment
<mgrandi> there is probably something similiar in command line form
<mgrandi> or a plugin
<greggypoo> thanks, bzr qshelve makes sense...i've been using regular shelve as a stopgap
<mgrandi> its the same thing as git (more or less since bzr doesn't have the 'index')
<mgrandi> it would be nice to have a plugin do it for you using shelve
<mgrandi> (aka shelve temporarily -> commit your selected changes -> unshelve)
<mgrandi> bzr help shelf1
<mgrandi> whoops
<mgrandi> i have 'shelve1' (from a plugin
<mgrandi> it seems to have an interactive mode
<greggypoo> ok, and hopefully the last one :)  how do branches ever get deleted?  i have pushed an lp:~myusername/project/branchname ..does that branch just magically disappear once the "proposed merge" is accepted?
<mgrandi> they dont get deleted unless you delete them, but if they are merged then you can delete them since the changes are present in the branch that you merged into
<mgrandi> (on launchpad)
<greggypoo> locally I used rm -rf to delete an unneeded branch, how would i delete it remotely on launchpad?
<mgrandi> i would presume through the website somewhere
<greggypoo> ok thanks :)
<mgrandi> alternatively you don't have to delete it as it would take up very little space, since it shares the commits with the merged branch
<greggypoo> yup, just didn't see it on the first glance, it was on my screen :)
<greggypoo> i just didn't want to be the guy that cluttered up the project view on launchpad
<mgrandi> im not exactly sure how lp works, i think branches of a project that you don't own go into your own directory
<mgrandi> like launchpad.net/~markgrandi/bzr/something
<greggypoo> yeah, it puts my name on it, but there's a view that shows all of the personal branches together
<mgrandi> ah
<mgrandi> i wouldn't worry too much about that, even github has that to an extent =P
<greggypoo> everything i know about git i learned on my private server, so it is a little bit of a learning curve to try not to look like an idiot when submitting things on github or launchpad
<mgrandi> they are more or less the same
#bzr 2013-03-30
<commandoline> hi, I've just done a bzr commit -m "commit message" while I had deleted some files inside my repo. Then, I did bzr uncommit because I forgot to pull from launchpad first. It gave an error containing the file name of one of the files I deleted, and now all files are the same as in the latest rev. of the bzr branch. In other words: all my changes are gone. Does anyone know how to recover them?
<commandoline> (if possible?)
<commandoline> (I'd like to give the error message, but I did a bzr log in the meantime in my panic, so the scrollback is gone :()
<commandoline> http://paste.ubuntu.com/5662203/ <- .bzr.log relevant entries.
<commandoline> the pull modifies the files I changed (most importantly: modules/org/openteacher/websiteGenerator/websiteGenerator.py)
<commandoline> also opened: https://answers.launchpad.net/bzr/+question/225506
<maxb> Hmm, so was the preceding commit successful?
#bzr 2013-03-31
<commandoline> maxb: quite late to answer, but the preceding commit was succesful, yes.
<commandoline> (trying the instructions now that were given inside the launchpad question I opened yesterday)
<commandoline> and got my data back with that instructions. :D Thanks anyway.
#bzr 2014-03-24
<Chocobo> Is there anything I can do you speed up an initial branch from launchpad?  It is SO slow.  I can checkout the Linux Kernel in git in less time than it takes to branch a relatively small project.
#bzr 2014-03-25
<mgrandi> do i have any testers for my windows installer of bzr 2.6?
#bzr 2014-03-27
<zyga> good morning
<jelmer> hey zyga
<zyga> jelmer: hey :)
<jelmer> zyga: are you still working on bzr3?
<zyga> jelmer: I still have that on my todo list, probably after trusty is out I will have much more time for it
<jelmer> zyga: ah, ok
#bzr 2015-03-28
<LeoNerd> GAHHH
<LeoNerd> ONCE AGAIN  bzr up  did not abort on diverged history but instead made a merge
<LeoNerd> How do I a) unfuck this, and b) stop it EVER doing it again?
<LeoNerd> I do not *EVER* want  bzr up  to merge. if there's divergant history I want it to complain, so that I can rebase
<Spads> LeoNerd: so bzr up kind of *is* merge
<LeoNerd> Yes. I don't want one
<Spads> so why did you run bzr up, exactly?
<LeoNerd> I want it to bring me in new non-divergent history, or abort if there is
<Spads> are you doing a bzr checkout?
<LeoNerd> It's a checkout yes
<Spads> is there a reason you're doing that instead of bzr branch?
<LeoNerd> Because most of the time I'm online and therefore I want to use the central server
<Spads> the semantics of bzr checkout are there to support people who are uncomfortable with anything but SVN, near as I can tell
<Spads> everyone else just uses bzr branch
<Spads> and does pull/merge/push
<Spads> a pull will abort on divergent history
<Spads> up is basically "merge from where I checked out to" and that is basically all it is
<Spads> s/ to//
<LeoNerd> Ah; maybe I should just use pull then..?
<Spads> I think so
<Spads> you'll need to branch first
<LeoNerd> Nah
<Spads> your checkout has no repo basically
<LeoNerd> pull :bound == up, give or take
<Spads> yeah
<Spads> see this conflict detection is a repo opration
<Spads> mostly
<Spads> so it's about two repos communicating
<Spads> (I think)
<Spads> so a branch will have a local repo
<Spads> and can thus negotiate the conflicts correctly
<Spads> but if pull :bound works, then do use it!
<Spads> but divergent history vs :bound doesn't make sense to my mind
<Spads> history only exists in branches
<Spads> not checkouts
<Spads> checkouts defer history to the bound branch
<LeoNerd> I only really get divergent history if I was offline on my laptop, like on a train
<LeoNerd> As happened here
<Spads> if you're doing work offline on your laptop, you want to branch locally
<Spads> unless this is something pathological like a repo with 44G of history or something
<LeoNerd> Hrm? A checkout is a branch
<Spads> not really
<LeoNerd> bzr co == bzr branch + bzr bind
<Spads> hm
<LeoNerd> It's not a _lightweight_ checkout.. it still has a local branch
<Spads> ahhhh
<Spads> okay sorry
<Spads> yes, I was thinking lightweight
<LeoNerd> :)
<Spads> so yeah, see if pull :bound has the right semantics for you
<LeoNerd> Oh, Ialready know it does. I just keep forgetting to do that
<Spads> heh
<LeoNerd> ((You only need :bound the first time; it'll remember afterwards)
<Spads> bzr pull --remember is handy when you get those wrong
<Spads> maybe bzr alias up="pull :bound" would help :)
 * Spads does that on his one heavyweight checkout
 * Spads has been using bzr since 2006 or so, and could swear that bzr co used to do lightweight checkouts
<LeoNerd> Mm... I don't think it ever has done
<LeoNerd> Though that might be a configurable option
<Spads> iinteresting
<Spads> TIL
<fullermd> Your problem isn't using 'up', it's using 'ci --local'.  I still maintain that its existence is a bug   :p
#bzr 2016-03-29
<calier> What is the default recommened branch type for starting a project?
<LeoNerd> branch type?
<calier> http://bluehome.net/~csh/pics/branch-type.png
<LeoNerd> ... I have no idea what that refers to... Nor what that graphical tool is
<LeoNerd> Also you might want to read the tooltips, as the text there suggests
<LeoNerd> Maybe that will be informative
<calier> i just used the default
<calier> LeoNerd: it is Bazaar Exlporer, it was made for bazaar
#bzr 2017-03-28
<naveed> has anyone packaged bzr 2.7 for rhel6?  Are there any srpms around?
<naveed> or perhaps the srpms from the original epel release?
#bzr 2017-04-01
<LeoNerd> Is it somehow possible to 'bzr ignore' all the symlinks in a given directory?
<LeoNerd> I have a mix of symlinks and regular files, all called *.c
#bzr 2018-03-26
<gour> evening, any news about possible breezy release in the foreseeable future?
<gour> btw, pypi page says: "Users can choose between our command line tool and our cross-platform GUI application.", so I wonder which GUI app is meant here?
<jelmer> gour: hi
<jelmer> gour: we had a weekend of hacking, and made some good progress
<gour> good
<jelmer> gour: we're waiting with any kind of release until we've got a Python3 port
<gour> how many tests are still failing?
<jelmer> on Python3, at least ~10k
<jelmer> I don't think number of tests failing is necessarily a good indicator of progress though
<jelmer> we're down to a handful of test failures (out of >2000) for git format support
<jelmer> and those are icky tests rather than actual bugs in brz-git
<gour> that's great...i'm looking/waiting for brz to have smooth interoperation  with git(hub) projects
<jelmer> gour: Martin is going to send some sort of summary to the mailing list
<gour> jelmer: ok. wishing you all the best to push brz out!
#bzr 2018-03-27
<gour> jelmer: is brz-git going to be integrated into brz with 3.0 release?
<jelmer> gour: hopefully
<gour> jelmer: that will be great!
<gour> and i'm eagerly awaiting to use it
<mgz> jelmer: send our hacking day report to the list
<mgz> *sent
<mgz> that was a statement, not a command :P
<gour> will '--fixes' in brz get support for some more trackers like github/lab?
<mgz> gour: it already supports whatever, it's stored as a url
<mgz> see `brz help bugs`
<mgz> can add some more default mappings pretty easily
<gour> ok, have to re-install brz 1st
<jelmer> gour: thanks :)
<jelmer> eh
<jelmer> mgz: thanks :)
<jelmer> gour: for git commits, we'd have to work out where to store that information though - presumably somewhere in the commit message
<jelmer> e.g. a line with "Bug-Fixed: git://github.com/foo/bar/issues/42" ?
 * gour is installing brz/brz-git from the trunk
<gour> jelmer: how should be brz-git plugin properly named locally?
<jelmer> gour: "bzr branch lp:brz-git ~/.config/breezy/plugins/git"
<gour> jelmer: what has happened with ~/.bazaar ?
<jelmer> please note that remote git operations are still flaky because they have had less testing
<jelmer> gour: it's moved to ~/.config/breezy
<gour> thumbs up
<gour> any hint on this one: https://pastebin.com/cfTLPYsk
<gour> i installed trunk version of brz & dulwich
<mgz> gour: if you run with BRZ_PDB=1 and then import dulwich in the debug session,
<mgz> is it from the location you think it should be?
<gour> mgz: pls. excuse my ignorance, but how i'm supposed to get into debug session?
<gour> i simply want to init a new repo and then create few branches within
<mgz> something seems wrong with the install, it's complaining about a variable that dilwich has had for a good while
<mgz> anyway, off now, jelmer may have better ideas later
<gour> now i executed under bash shell and 'import dulwich' does work within debug session
<jelmer> gour: are you sure this is the trunk version of dulwich?
<jelmer> gour: what does "pydoc dulwich.repo.COMMONDIR" say?
<gour> jelmer: no Python documentation found for 'dulwich.repo.COMMONDIR'
#bzr 2018-03-28
<gour> morning
<gour> my problem from yesterday was due to old version of dulwich - i did brz lp:dulwich not being aware that new version lives in git repo elsewhere
<gour> is there any gui working atm with brz?
<gour> bzr-git serves those who want to "use Bazaar as their VCS client on projects still using Git as their VCS tool", but I wonder about vice versa, iow. what about those who want to primarily use Bazaar as their VCS and occasionally export their repo to git(hub)?
<gour> what is trade-off in using git format for branches in comparison with brz's native 2a format?
 * gour just created shared repo
<jelmer> gour: converting back and forth between the different formats regularly is going to be slow
<jelmer> I'd recommend just using the git format if you're going have to eventually push to github
<jelmer> That way you can also easily fall back to just using git while bree
<jelmer> breezy is pre-beta
<jelmer> s/breezy/brz-git/
<gour> jelmer: and what if i'd mostly work in brz and just want from time to time export (theme for static site generator) new release to the git format so it can be linked by the upstream project?
<jelmer> gour: why do you want to use the bzr format locally?
<gour> jelmer: i assume that 'native is better' ?
<jelmer> gour: with the new brz-git, both formats are equally native (though the git format is obviously less well tested)
<gour> jelmer: ok, what about git formats and shared repo, that does not work together and one has to use branch per repo with git?
<jelmer> gour: git formats don't support shared repositories
<gour> ok, as i thought :-)
<jelmer> you can use git-style multiple branches per repository (colocated branches)
<gour> via plugin?
<jelmer> no, natively
<jelmer> admittedly colocated branches are still in a rough state too
<gour> ohh, didn't know that was merged into the core
<gour> now found it as 'development-colo' format
<jelmer> gour: you don't need development-colo, it works with the default format
<gour> jelmer: where can i read about that?
<jelmer> gour: I don't think we've documented it anywhere yet, it's not in a state yet where I'd recommend using it
<gour> jelmer: does it resemble http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html ?
<jelmer> gour: no, it's unrelated to that
<jelmer> You can see some of it in action when running brz in an existing git repo
<jelmer> E.g. 'brz branches' will list all branches
<jelmer> And 'brz switch' allows switching between them
<gour> just cloned some repo from the github to compare sizes and 'du' shows the same size
<gour> that's cool
<gour> is there any workable gui for brz which can be recommended for not-so-savvy users?
<fullermd> I've gotten along reasonably well using bzr for a project and git-bzr-ng to schlep up a mirror on github.
<gour> fullermd: that's nice to hear...my current VCS for private stuff is Fossil, but I anticipate that brz will become my favorite one enabling me to inter-operate with git(hub) projects
<gour> what is the use of cheap branching in git when working with branches, especially with remote ones, is so convoluted...
<jelmer> gour: there's no functioning UI at the moment
<jelmer> there's lp:qbrz, but it hasn't been updated for the latest round of API changes in Breezy
<LeoNerd> Has bzr-rewrite disappeared from debian?
<jelmer> LeoNerd: yes
<LeoNerd> Hmm.. Isee
<gour> does extmerge work with brz?
<jelmer> gour: none of the existing bzr plugins work with breezy, though some (like extmerge) are probably easy to port
<gour> jelmer: thanks
#bzr 2018-03-30
<cary-elvis> .-.            .-.
<cary-elvis> /   \          /   \
<cary-elvis> |   _ \        / _   |
<cary-elvis> ;  | \ \      / / |  ;
<cary-elvis> \  \ \ \_.._/ / /  /
<cary-elvis> '. '.;'    ';,' .'
<cary-elvis> './ _    _ \.'
<cary-elvis> .'  a __ a  '.
<cary-elvis> '--./ _,   \/   ,_ \.--'
<cary-elvis> ----|   \   /\   /   |----
<cary-elvis> .--'\   '-'  '-'    /'--.
<cary-elvis> _>.__  -- _.-  `;
<cary-elvis> .' _     __/     _/
<cary-elvis> /    '.,:".-\    /:,
<cary-elvis> |      \.'   `""`'.\\
<cary-elvis> '-,.__/  _   .-.  ;|_
<cary-elvis> /` `|| _/ `\/_  \_|| `\
<cary-elvis> |    ||/ \-./` \ / ||   |
<cary-elvis> \   ||__/__|___|__||  /
<cary-elvis> \_ |_Happy Easter_| /
<cary-elvis> jgs .'  \ =  _= _ = _= /`\
<cary-elvis> /     `-;----=--;--'   \
<cary-elvis> \    _.-'        '.    /
<cary-elvis> `""`              `""`
<cary-elvis> L0DE AND CHRON FROM #LRH & L0DE RADIO HOUR (IRC.EFNET.ORG) WANTED TO SAY HAPPY EASTER!!
<cary-elvis> camako gour mgz markong fifr[m] LeoNerd pjdc jelmer Keltia james_w irsol djinni` fullermd_ Peng verterok ubot5 fmccann vila charles wgrant erry anthonyf thomi bpierre nopf nicoulaj ubuntulo1 rweir_ CHYC quicksilver Peng_ ggherdov m1sc yena elmo mthaddon ajmitch jam superfly alexlist catern
#bzr 2018-04-01
<H1P87Yhexa-> âââââââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  vdibrt: irsol ubuntulo1 anthonyf âââââââââââââââââââ
<H1P87Yhexa-> âââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  hmmbiqzwv: mgz yena jelmer ââââââââââââââ
<H1P87Yhexa-> ââââââââââ HAPPY APRIL FLOODS DAY BROUGHT TO YOU BY iÑÑ.sÑÑÐµÑÐ¸ÐµÑs.Ð¾Ñg ÑÐ½Ð¸ sÑÑÐµÑÐ²Ð¾wl  idekekbhuj: mgz quicksilver Peng_ ââââââââââââââ
