#bzr 2007-11-14
<hugh> hi, any bzr gurus out there
<dato> hugh: it's better to just ask your question, and wait until somebody who knows is available to answer it
<hugh> ok; I temporarily renamed a directory using mv (i.e. not using bzr), and then later I did a commit; bzr decided I intended to remove the dir
<hugh> directory
<hugh> so, I've tried to use revert to bring the directory back
<hugh> but, I get an error message
<jml> hello
<hugh> bzr: ERROR: Path(s) are not versioned: py/coe/signalprocessing
<jml> I've recently been talking to people interested in using bazaar. One question they asked was whether it had a command to totally rebuild the working tree.
<jml> something like bzr revert, except that it removes all files not in version control, even ignored ones.
<hugh> so, how do I bring back a directory that bzr decide to remove
<jml> hugh: bzr revert perhaps?
<hugh> two of asking about revert at the same time!
<hugh> no, revert didn't work, said: bzr: ERROR: Path(s) are not versioned: py/coe/signalprocessing
<jml> hugh: oh, I've just read your full explanation.
<jml> hugh: one thing you could try is 'bzr uncommit' (if moving the directory was something you did in the most recent commit)
<dato> hugh: do this
<dato> hugh: let's say the commit where the directory was accidentally removed was 123
<dato> bzr merge -r 123..122 .
<jelmer> jml: clean-tree ?
<jelmer> that can remove ignored files
<hugh> ok data, thank, I thought that might be the recommended route
<hugh> I'll give it a try
<jml> jelmer: awesome.
<dato> hugh: better mv out the directory first
<dato> hugh: bzr will restore it
<hugh> oh, I have the moved dir, I just want to restore it with its history rather than re-adding it; I'll be careful
<jml> jelmer: I guess the exact thing they would want is 'bzr revert && bzr clean-tree --ignored --unknown --detritus
<quicksilver> hugh: or, just branch locally
<quicksilver> hugh: bzr branch foo foo-clean
<quicksilver> hugh: foo-clean will have a rebuilt working tree, with no ignored files etc
<hugh> I think you mean jml
<jml> quicksilver: oh yeah, good point.
<dato> jml: you want "bzr revert; bzr clean-tree"
<dato> (clean-tree is provided by bzrtools)
<dato> hugh: oh, you could run bzr uncommit indeed, if it was the last revision.
<dato> (and it wasn't pushed anywhere)
<jml> dato: clean-tree doesn't delete ignored files by default.
<quicksilver> hugh: sorry.
<quicksilver> jml: I did indeed mean jml :)
<dato> jml: well, delete-tree --ignored --unknown ?
<jml> dato: :)
<mwhudson> hm, bzr branch would be the right answer if tree building was faster
<kaaloo> Hi again, I just fixed a small bug in the bzr-email plugin when using smtp.gmail.com.  I published my branch on launchpad.  Is that enough to get my changes reviewed and hopefully going into trunk if there are no issues ?
<mwhudson> kaaloo: probably best to mail the bazaar list i'd think
<kaaloo> ok thanks, I just sent out an email to Robert, but I'll do so next time
<schierbeck> jelmer: ping
<jelmer> schierbeck, pong
<schierbeck> jelmer: are you acquainted with the ancestry tree drawing code of the viz?
<jelmer> schierbeck: no, not at all
<schierbeck> darn
<schierbeck> i'm investigating whether it's feasible to refresh the graph when new revisions are available, or if i have to redraw the entire widget...
<jelmer> garyvdm is the person you'd want to talk to
<schierbeck> yeah, but i haven't seen him on the channel recently
<schierbeck> refreshing the viz is crucial if we want to pull and push from within the viz
<schierbeck> hell, the current compact-view-toggle is just a hack that forces destroys the treeview, then creates a new one
<schierbeck> *-forces
<jelmer> I think that's acceptable for now
<jelmer> even when we start doing push/pull from viz
<lifeless> jml: clean-tree can do it, combine the two is straight forward. Or you could write a plugin trivially.
<jml> lifeless: thanks.
<lifeless> well back to bed for a bit
<lifeless> meh
<lifeless> I'm awake
<lifeless> abentley: ah, the summary is a link, and thats why I didn't notice it as something to copy n paste from
<lifeless> jam-laptop: how goes dirstate-merge?
<jam-laptop> ok, i was benchmarking your patch after a merge of dev showed me just how slow things had gotten
<lifeless> :)
<lifeless> the feedback that its radically faster for you is interesting
<lifeless> how many packs do you have?
<jam-laptop> 11
<lifeless> cool
<jam-laptop> sorry, 13 after testing
<ubotu> New bug: #162702 in bzr-email "Does not use bzrlib.smtp_connection" [Undecided,New] https://launchpad.net/bugs/162702
<ubotu> New bug: #162707 in bzr "bzrsvn: permission denied on win32" [Undecided,New] https://launchpad.net/bugs/162707
<lifeless> jam-laptop: ping; can we have a short skype chat ?
<jam-laptop> lifeless: how about after 30 minutes?
<lifeless> I'm spinning on reconcile designs
<jam-laptop> k
<lifeless> so essentially blocked until I validate an approach
<lifeless> 30 minutes is fine; earlier is better. (But I do mean short)
<jam-laptop> I'll ping you as soon as I'm ready
<lifeless> thanks!
<jam-laptop> by the way, the discard_merge_parents is causing the 'b' directory to disappear
<jam-laptop> I'm not sure why yet
<jam-laptop> it is claimed to be present in this
<lifeless> ohkies
<lifeless> the b array, or the entry for b in the root array ?
<jam-laptop> the entry for b in the root array
<lifeless> blech
<jam-laptop> before: p [[(z[1][0][0],z[0][:2]) for z in a[1]] for a in self._dirblocks]
<jam-laptop> [[('d', ('', ''))], [('a', ('', 'a')), ('d', ('', 'b')), ('a', ('', 'rootfile'))], [('r', ('a', 'b'))], [('f', ('b', 'b'))]]
<jam-laptop> after: p [[(z[1][0][0],z[0][:2]) for z in a[1]] for a in self._dirblocks]
<jam-laptop> [[('d', ('', ''))], [], [], [('f', ('b', 'b'))]]
<lifeless> 'I shall not write untested helper functions' * 500
<jam-laptop> It is a bit hard to parse
<jam-laptop> but that is the status in this tree
<jam-laptop> followed by the path
<jam-laptop> for each directory block
<jam-laptop> and you can see that the root dirblock still exists, as does the 'a' and 'b' dirblocks
<jam-laptop> but the root dirblock is now empty
<jam-laptop> lifeless: I'm logging into skype now
<lifeless> jam-laptop: thanks!
<jam-laptop> now we just need to figure out why you woke up at 3am :)
<jam-laptop> if it was an issue of you already being awake, I think most of us would understand, but just waking up....?
<lifeless> jam-laptop: 4am today :)
<lifeless> jetlag
<lifeless> veryt tired at 9pm
<lifeless> so went to sleep
<lifeless> 7 hours later
<lifeless> tada I'm awake :)
<jam-laptop> I forgot about the daylight savings time switchover
<jam-laptop> lifeless: found it... man is it weird
<jam-laptop> you have a call for
<jam-laptop>                 for pos, entry in enumerate(block[1]):
<jam-laptop> ...
<jam-laptop>                     if len(deleted_positions) == len(block):
<jam-laptop>                         del block[1][:]
<jam-laptop> do you see the bug?
<jam-laptop> (len(deleted_positions) == len(block[1]))
<lifeless> fark
<lifeless> great catch
<jam-laptop> so, what is a good way to test that
<lifeless> dirstate specific test I think
<lifeless> setup a failure and call discard directly
<jam-laptop> yeah, that is what I was thinking
<jam-laptop> maybe have a few permutations of tests for _discard_merge_parents
<lifeless> 05:42 < lifeless> 'I shall not write untested helper functions' * 500
<jam-laptop> lifeless: speaking of which ['I shall not write untested helper functions'] * 500 is probably better
<jam-laptop> or at least put a '\n' at the end
<lifeless> rofl
<geekfish> hello everyone
<geekfish> I was wondering if there is anyone here who can help me with something
<lifeless> try asking the question :)
<geekfish> I need version control for a project of mine, I'm working together with another person. We were searching for possible solutions and I found the "partner" workflow.
<geekfish> I just can't figure out how one can practicaly make this work :/
<lifeless> well, what have you tried so far?
<geekfish> well, I haven't tried anything specific, I'm a little lost
<geekfish> sorry if this sounds too general
<geekfish> (and if my english isn't totaly correct)
<lifeless> got a url to whats confusing you?
<lifeless> your english is better than my french
<jam-laptop> I'm pretty sure he is talking about http://bazaar-vcs.org/Workflows
<jam-laptop> Probably explicitly: http://bazaar-vcs.org/Workflows#head-55f80fdd1cfe8503703241ae491839c943327000
<geekfish> hm, yes, that's where I found it
<lifeless> wow thats a confusing document
<lifeless> I mean, I know this stuff but the pictures are hard to interpret
<geekfish> my problem is that I don't understand the way you can synchronize
<lifeless> we should like to the tutorials, or have more detail there.
<jam-laptop> time to reboot... :( bbiab
<lifeless> geekfish: bzr push to publish your work somewhere your other person can access, and they use bzr merge URL + bzr commit, to sync
<lifeless> time for some food, I'll be back in about 15; try reading the tutorials they will give you details on using bzr
<lifeless> the workflow is about organisation not specific commands
<geekfish> hm, yes, I understand
<geekfish> I suppose I'll have to search most of it by myself
<geekfish> thanks :)
<igc> morning all
<lifeless> hi
<lifeless> igc: so I'm going to nag you about doing some code too
<igc> lifeless: I'm working on bug 6700 right now
<ubotu> Launchpad bug 6700 in bzr "bzr diff -r 10..20 http://foo" unsupported" [High,Confirmed] https://launchpad.net/bugs/6700
<igc> hope to have a patch out today
<lifeless> igc: woot!
<lifeless> if you want to chat about it, I'd be delighted to
<igc> thanks - I'm right so far. Made lots of progress yesterday
<wam> Hi, I couldn't find the cvs-like workflow explained in commands. Is bzr commit; bzr push - and on the other end bzr pull the equivalent to cvs commit, cvs update?
<lifeless> wam: if you want cvs workflow, just use the commands cvs has -
<lifeless> checkout; commit
<wam> lifeless: ah - the commands are on the arrows ;) Ok - understood now. Thanks ;)
<wam> I'm using it for a year now and meanwhile it's the only vcs I'm using. I even could encourage other peope to move to bzr. Right now I'm having to use other workflows due to customer's wishes. Thanks for that great software ;)
<wam> With which software did you create the graphics? Which iconsets are these? http://bazaar-vcs.org/Workflows
<lifeless> probably inkscape and tango
<lifeless> jam-laptop: I think with a little horizontal extraction we could have just one lru class and two helpers
<lifeless> with less duplication
<jam-laptop> probably
<lifeless> jam-laptop: anyhow, I've put it up, same fileids.
<lifeless> it looked good enough to merge to me
<jam-laptop> I was trying to make the check fairly fast
<lifeless> so if you want to +1 I'll push it in.
<flacoste> hello, anyone can tell me how to resurrect a directory?
<flacoste> several revisions ago, I incorrectly removed a directory while doing a merge
<flacoste> so uncommit is impractical here
<flacoste> i want to say "please add back that directory as if I had never touched it"
<jam-laptop> flacoste: bzr revert
<flacoste> jam-laptop: i thought that revert only removed changed in the working dir
<jam-laptop> flacoste: 'bzr revert -r -10 directory'
<flacoste> hmm, the help says Revert files to a previous revision.
<jam-laptop> should do what you want
<flacoste> right, thanks a lot!
<jam-laptop> for whatever -r before you removed it
<flacoste> any quick thought on how I could find that out?
 * igc food
<flacoste> bzr log <path-to-removed-directory> tells me that the Path does not have any revision history
<lifeless> hgrep would help :)
<lifeless> flacoste: bzr log -v | less
<lifeless> flacoste: look for the path you want
<lifeless> flacoste: or use bzr ls -r path and do bisection
<flacoste> lifeless: thanks bzr log -v worked
<abentley> quicksilver: Cart actually uses loggerhead as its source viewing library.  It's coming along quite nicely, I think.  Once I'm done with schema changes, I plan to release it.
<lifeless> abentley: it's still taking most of your hacking time ?
<abentley> lifeless: No, sadly.  I don't seem to get as much hacking time as I used to.
<abentley> What's the current schedule for the next version?  I'm trying to decide whether it's worth trying to implement rich-root, no-subtree formats.
<lifeless> poolie knows more than I
<lifeless> I think though that as its 1.0 its better not to rush through to such a thing; 1.0 should be a matter of polish not of changing default formats
<abentley> If I did it, it would be non-default, but at least the knit version would not be flagged experimental.
<lifeless> I'd really like to get the patch from LarstiQ
<lifeless> LarstiQ: btw, where is your branch; I don't care if its not finished at the moment noone else can collaborate on it
<lifeless> AIUI subtrees are usable with that patch.
<abentley> lifeless: Well, the last time I put it up for review, no one did.
<abentley> And it's quite a lot more involved than introducing a new format.
<lifeless> abentley: yah, it was a bad time
<lifeless> at least for me I was under a tad of pressure
<abentley> The point being that, although it would be awesome to get it merged, it's a lot more work to get ready and to get merged.
<abentley> And pragmatically, we can't afford to keep making svn converts use an experimental format.
<lifeless> I worry that we will have holes in our rich root no-subtrees stuff, because we only really test all or nothings
<abentley> Well, that's reasonable.  Obviously, I'll add it to the repository_implementation and interrepository_implementation tests.  Any suggestions what else I should do?
<fullermd> I thought there was some discussion a while back about making subtree capability a branch flag or something, rather than a repo format.
<abentley> fullermd: Yeah, and the outcome was that we should make it be determined by the working tree.  I said I'd do that.  I didn't.  I'd rather mess with repo formats than dirstate.
<fullermd> Sounds like a good choice to me.  Dirstate likes jumping out at me and going "boogieboogieboogie", and I'm not even poking at its innards with a knife.
<lifeless> abentley: I don't see that you'd have to touch dirstate
<tanderson> Does bazaar support any type of virtual accounts for authenticating users that are doing commits or must they be system accounts? (I'm a subversion user, but the bazaar project looks really interesting to me so I'm doing some research to see what I would do to convert my svn repos)
<abentley> tanderson: Bazaar supports any authentication system that you can set up with ssh, ftp or (with a plugin) WebDAV.
<abentley> Certainly there are ftp and WebDAV servers that allow you to set up authentication that's not based on system accounts, and I believe there are SSH/SFTP servers that do the same.
<tanderson> abentley: That is great.  I know that I can do virtual accounts with my FTP server but I've never looked into doing this with ssh/sftp
#bzr 2007-11-15
<ricosecada> Hi. I am just in the process of migrating from cvs to bzr. I have a debian server just running sshd. On cvs I normally just specify a CVSROOT variable which points to the server, and after doing an init on the server it is set up. I can't seem to figure out, if its possible to run bzr the same kindda way?
<fullermd> Well, there's no CVSROOT equivalent; the concept doesn't map.  But you get a CVS-like workflow using checkouts.
<fullermd> You just have to specify the full remote URL when you do the checkout.
<ricosecada> fullermd, do I have to specify the url when I do commits as well then?
<Odd_Bloke> ricosecada: No, your branch will remember where it is checked-out from.
<fullermd> No, any more than you need to specify the module or have $CVSROOT set when you do a CVS commit.
<ricosecada> since the server is running ssh, what would the complete command look like?
<ricosecada> with the url
<fullermd> bzr+ssh://server/path/on/server/   (or sftp:// if you can't get bzr running on the server)
<ricosecada> aah :-)
<lifeless> e.g. bzr checkout bzr+ssh://server/path/on/server/
<fullermd> Hm.  That reminds me; we have a bug open for "No ~ on bzr+ssh", right?
<lifeless> yes
<fullermd> That's one of the sort of things I'd put on the "rough edges that 1.0 shouldn't like" list.
<fullermd> Little and rather piddly stuff, but it makes you frown.
<ricosecada> do I need to specify the BZR_REMOTE_PATH anywhere?
<lifeless> only if bzr is not in the usual place
<tanderson> So if I want to start a new project using bzr I can store my project in a location accessible via my webserver to allow anyone to do a checkout via bzr http://... right?
<lifeless> yes
<lifeless> though anonymous users will usually use bzr branch
<tanderson> I see
<ricosecada> are there any specific packages needed to use bzr with ssh?
<lifeless> ricosecada: install the recommends:
<ricosecada> lifeless, I did. I can do a checkout from the ssh server fine now, but when I try to commit I get this bzr: ERROR: exceptions.AssertionError: end of file reading from server
<tanderson> And if a developer wanted to work on this project and did an initial checkout/branch via bzr http://....  I would need to install the webdav plugin to allow them to commit back to http:// right?
<ricosecada> looks like a bug
<lifeless> ricosecada: hmm, there are some bugs open
<lifeless> ricosecada: its likely the permissions error bug, we mis-represent a permissions error sometimes
<ricosecada> and I was just beginning to enjoy this :-)
<lifeless> ricosecada: you could try sftp:// with the same url; it might give a better diagnostics
<ricosecada> I'll try that
<ricosecada> lifeless, it works fine with sftp
<ricosecada> no errors
<fullermd> What version do you have on the client and server sides?
<ricosecada> on the client 0.91.0 on the server 0.11.0
<fullermd> Wuff.
<ricosecada> I am running debian testing on the client and stable on the server
<ricosecada> but its ok when its working with sftp
<fullermd> I think 0.11 supported bzr+ssh (though it was brand new then).  But it didn't support dirstate-tags branches, which I guess you have.
<fullermd> sftp doesn't use bzr on the server side at all.
<abentley> ricosecada: For bzr+ssh compatibility, I'd recommend something much more recent.  That support has been evolving rapidly lately.
<ricosecada> I will perhaps upgrade the bzr packages on the server
<ricosecada> one more question, I have been searching for the variables like $author$ and $id$ to insert in the files. would someone mind pointing me in the direction to doc on that?
<fullermd> That's filed under "keyword expansion".  Support doesn't exist yet.
<ricosecada> ok
<ricosecada> I upgraded bzr on the server - no bugs now
<lifeless> ricosecada: fullermd failed to mention 'bzr version-info --help'
<lifeless> ricosecada: this is in many ways technically superior - its simpler, works with binaries as well as sources, etc.
<ricosecada> ok
<ricosecada> I am running 0.91 on both server and client now
<ricosecada> I do miss the keyword expansion though
<fullermd> Hm.  That reminds me, I should rewrite some scripts to use revision-info
<lifeless> ricosecada: we have no moral objection to it, and will eventually do it for folk that want the bad ol' days :)
 * fullermd is one who wants the bad ol' days   ;)
<ricosecada> :-)
<fullermd> WAG'ing from the current active lists, I'd be surprised if we saw it before next summer at the earliest.
<fullermd> Probably farther out than that.
<lifeless> abentley: I find working with [NULL_REVISION] rather than [], to be quite annoying. As we have None to represent 'not here', all it really means is that [] is *never* used
<abentley> lifeless: Well, in theory it would be used for get_parents(NULL_REVISION)
<lifeless> abentley: I'm not saying NULL_REVISION shouldn't exist. just that having end-of-graph be coerced to it is extra typing and logic
<lifeless> I appreciate NULL_REVISION having to exist to differentiate unpassed parameters (None), and NULL_REVISION itself.
<lifeless> anyhow, I may be wrong, there may be some point where it turns out to be useful, so I'm using it.
<jelmer> abentley: btw, any particular reason Repository.get_parents() uses self.get_revision(x).parent_ids rather self.revision_parents() ?
<jelmer> my guess would be that revision_parents() is intended to be deprecated, but it's not marked as such (yet)
<lifeless> jelmer: I think you'll find knit and pack repos have a different get_parents, and also see Repository.get_graph.
<abentley> lifeless: Well, I was thinking two things: 1. the graph is more accurate with NULL_REVISION in it.  2. I've seen what a pain it is when we don't use NULL_REVISION enough, so let's try erring on the other side.
<jelmer> lifeless: Still, it would be nice to have a fast default implementation
<lifeless> jelmer: for jbof repositories, get_revision.parent_ids is fast
<lifeless> jelmer: there really is no well defined 'fast' :)
<jelmer> lifeless, revision_parents() will always be faster I imagine, as it is more specific
<jelmer> since the information it returns is a subset of the information returned by get_revision()
<jelmer> *faster or same speed
<lifeless> sure I guess
<lifeless> just saying, check around a bit
<lifeless> if you come to a conclusion, send a patch
<jelmer> sure, will do
<abentley> jelmer: frankly, I don't remember.  I may have been thinking that for weave repos, the implementation just needed to be correct, not fast.
<lifeless> abentley: if so, revision_parents has the same constraint though; also weaverepo.py can handle that. (Not critiquing, just noting)
<abentley> Oh, what about ghosts?  Weaves don't record ghost parents.
<lifeless> a weave will return [NULL_REVISION] when it shouldn't
<abentley> Sounds like a bug.  Do you know where it is?
<lifeless> my point is that weaves can't tell [] from [NULL_REVISION]
<lifeless> so they can't choose to return [] instead of [ghost], so any mapping will just preserve the defect
<lifeless> you have to go out to the real data to tell; and if you do that you can return [ghost] correctly anyway
<abentley> Are we talking about jelmer's thing or your thing?
<lifeless> my thing
<lifeless> sorry for adduing confusion
<abentley> The implementation of get_parents for weaves does hit the real data.
<Peng> bzr.dev reconcile took 356 minutes wall-clock time, 305m user time and 44m sys time.
<lifeless> Peng: yah
<lifeless> Peng: newer one is nearly done
<lifeless> I have _generate_text_key_index written
<lifeless> just need to hook in the LRU cache
<lifeless> damn its not too shabby
<lifeless> 2K/36K done
<lifeless> -no cache-
<lifeless> 4K
<lifeless> ok, I'm out for the day. damn 4am starts :)
<lifeless> I'll send this in for review but not merge.
<lifeless> 80M memory usage
<Peng> vs. 7 GB?
<Peng> Or whatever it was?
<lifeless> this is bzr.dev
<lifeless> so you were seeing how much yesterday?
<lifeless> 6.5K
<lifeless> 8K
<lifeless> 12K
<Peng> Didn't you mention that it used like 7 GB of virtual RAM?
<lifeless> that was launchpad
<Peng> Oh.
<lifeless> I'm testing that now
<lifeless> it's using 88M
<Peng> Ooh, bzr check is almost done.
<Peng> Wow.
<Peng> Umm.
<Peng> There are MORE inconsistent parents since running reconcile.
<lifeless> okies, I'm happy with this.
<Peng> Well, I made another commit, so that's probably that.
<lifeless> Peng: using what bzr version ?
<Peng> bzr.dev.
<lifeless> thats bizaare
<lifeless> bzr.dev won't create inconsistent parents
<Peng> Hee, 19,996 unique file texts.
<Peng> Well, the increase is probably because I made another commit.
<Peng> But reconcile definitely didn't help.
<lifeless> not if you committed using bzr.dev
<Peng> Oh, I didn't commit using bzr.dev.
<Peng> I only used bzr.dev for reconcile and check.
<Peng> Wasn't bzr.dev's check supposed to fix this?
<lifeless> do you mean reconcile?
<lifeless> and I thought you converted to packs. ...
<Peng> I still had the knit version around.
<Peng> So I ran reconcile on it.
<lifeless> ok
<Peng> And it didn't help.
<lifeless> well bzr.dev reconcile is meant to correct mismatched texts, but IIRC it keeps unreferenced and unused texts around just in case.
<Peng> I can successfully push, so I should just keep all of the messed up parent stuff?
<lifeless> with packs? I'd keep a backup of the knit repo just-in-case. Until I can have you run a native reconcile I'm just a tad cautious is all.
<Peng> I'm planning to keep a backup of the knits.
<lifeless> ciao
<Peng> This is making my head hurt.
<lifeless> ignore it
<lifeless> use the packs
<lifeless> enjoy the packs
<lifeless> and don't delete the knit copy for now:)
<Peng> Uh-huh.
<Peng> "Don't worry about the errors. Have fun. But don't delete your backup." I'm so confident. :P
<lifeless> they are a trivial defect 99.99% of the time
<lifeless> the only place we *know* to be affected by the non-trivial case is bzr.dev, from the bad ole weave days
<lifeless> another day or so and a clean pack reconcile should be available
<lifeless> and I'll get you to run that
<Peng> Okie-dokie. :)
 * igc lunch
<abentley> Am I correctly understanding that we have no general way of fetching between repositories whose serializers differ?
<lifeless> none hooked up commitbuilder is probably the closest thing
<lifeless> that was one of its intents
<abentley> Hmm.  Bundles can do it, though.
<abentley> I'm having trouble parsing "none hooked up commitbuilder"
<lifeless> i ,but
<abentley> I beg your pardon?
<lifeless> none hooked up, but commitbuilder is probably the closest thing
<lifeless> i starts insert mode in vim ;)
<abentley> Gotcha.
<abentley> I would think it's cheaper to deserialize and reserialize than to run through CommitBuilder.  But I guess CommitBuilder handles the case where more than the serializer differs.
<lifeless> right;  AFAIK we have no cases where the serializer is the only difference
<lifeless> (today)
<ricosecada> Hi. How does bzr handle binary files?
<AfC> ricosecada: uh, correctly?
<ricosecada> Afc, and how is that?
<fullermd> I was gonna say "with heavy leather gloves and 4 foot tongs"...
<Peng> Wow. The local repo that I converted to packs is a 225 MB .pack file. But when pushing it, it's a bit less than 200 MB. That's a lot of space wasted by revisions I had uncommitted.
<AfC> Whoa. `bzr viz` in bzr-gtk 0.92.1 is _really_ sexy
<ricosecada> Does bzr allow one to checkout a single directory with a repos?
<Peng> Nope.
<Peng> I don't think any of the DVCSes do. It would be a little tricky.
<ricosecada> Some of them does: http://better-scm.berlios.de/comparison/comparison.html#work_on_dir
 * Peng has fun deleting gigabytes of data.
<lifeless> lol
<lifeless> ricosecada missed that all of those that said yes, were not (D)VCS
<lifeless> Peng: ?
<Peng> I had a bunch of copies of everything from when I converted from bzr to hg. I just deleted most of them.
<Peng> Well, anyway, the pack version of that other repository is working fine, not that I've done much of anything with it.
<Peng> One commit.
<fullermd> Well, when I was a kid, my parents told me that if I could keep the bike balanced all the way to the mailbox, I could keep it balanced for any distance.
<fullermd> So by that logic, if it worked for one commit, it'll never fail   :]
<Peng> Ack. Duh, compressing a tar of compressed stuff doesn't help much...
<Peng> Well, it saved 4 MB.
<Peng> Out of 1.2 GB.
<fullermd> Not bad.  I've got a whole hard drive that would save...
<Peng> Wait, way more than that.
<Peng> 60 MB.
<Peng> Anyway, unless p7zip can extract things *really* fast, that's not really worth it.
<Peng> At least I can save a bunch of inodes.
<abentley> jelmer: initial version of a rich-root repo format is here: http://code.aaronbentley.com/bzr/bzrrepo/rich-root
<quicksilver> abentley: thanks. We're playing with it.
<quicksilver> abentley: certain amount of yak shaving was involved in getting the rights versions of python and stuff, but that's computers for you.
<Peng> Hey, I just pulled ~30 new changesets from bzr.dev and it only took like 10 seconds. How did that happen?
<lifeless> no idea
<fullermd> I'd guess you already had most of 'em.
<fullermd> Actually, with that timing, near all..
<Peng> Ohh. You're right.
<Peng> All of them were already in the repo because I had just pulled another branch.
<ig1> night all
<mwhudson> can someone here explain what's required of a progress bar?
<Kinnison> Ideally, indicate what's going on, progress evenly and monotonically giving a good indication of the amount of time consumed/remaining rather than number of tasks
<mwhudson> ah, i was imprecise
<mwhudson> i meant expected from a bzrlib point of view
<mwhudson> i need to provide an alternative implementation, and wonder what methods i need to provide
<Odd_Bloke> mwhudson: Checkout bzrlib.progress
<Odd_Bloke> *Check out
<Odd_Bloke> It has a base class and a number of implementations.
<mwhudson> i guess i can just inherit from DummyProgress and override everything
<mwhudson> gar, raising exceptions that hide other exceptions is pretty rude
<howari> ls -la
<jam-laptop>  .
<jam-laptop> ..
<jam-laptop> foo
<jam-laptop> bar/
<jam-laptop> howari: any other files?
<Odd_Bloke> :D
<jelmer> abentley: Cool, I'll have a look
<sbalneav> Hello.  I'm using bzr, and all of a sudden, I'm getting an error trying to do a commit.  Is there a pastebin for this channel?
<sbalneav> !pastebin
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<sbalneav> perfect
<sbalneav> http://paste.ubuntu-nl.org/44622/
<sbalneav> Seems to be complaining that the branch is read-only.
<sbalneav> Permissions are fine.  However, it's on an NFS mounted home dir.  Might that be the problem?
<jelmer> sbalneav: you appear to be committing over http - is that intentional?
<jelmer> it doesn't know how to send commits to the master branch using http
<sbalneav> ah, wait.
<sbalneav> maybe I did a bzr checkout instead of a branch?
<jelmer> ah
<sbalneav> Might that be it?
<jelmer> That would explain it
<sbalneav> durr
 * sbalneav facepalms
<jelmer> you can unbind from the master branch using "bzr unbind"
<jelmer> hey Szilveszter
<phanatic> hey jelmer
<sbalneav> ok, then just push back later with bzr push sftp://?
<jelmer> yup
<sbalneav> perfect.
<jelmer> or bind to that branch using "bzr bind sftp://" and it will automatically push when you commit
<sbalneav> ah, even better.
<sbalneav> one of these days my bzr-fu will get to the point where I'm not so helpless :)
<jelmer> sbalneav: well, I admit the error you got when committing to the checkout wasn't very helpful
<sbalneav> Nah, makes sense now that I look at it.  I was simply panicky after doing 1/2 hour of work :)
<sbalneav> Didn't know about the bind tho'.  That's a nice tip.
<jam> jelmer, sbalneav: that error has been improved in 0.91 or 0.92 to not give the ugly traceback
<jelmer> jam: ah, nice
<jam> now you get a single line error:
<jam> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ebzr/bzr-cvsps-import/trunk/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<jam> It isn't perfect, but it does make it a lot more obvious
<sbalneav> Yeah, working fine now after the bind.
<sbalneav> jelmer, jam, thanks muchly.
<sbalneav> Cheers!
<jam> happy to help
<nelius> is it possible to push a branch to a samba share?
<nelius> on a local fs it works, but on a samba share i get : bzr: ERROR: [Errno 5] Input/output error
<jelmer> nelius: Sure, if you've mounted that share locally
<beuno> nelius, absolutely, it's the same as pushing locally
<jelmer> nelius: How have you mounted the share, and what is the server running?
<nelius> my client is osx, i mounted is as smb:// from finder
<nelius> the server runs samba 3 on sun os 9
<jelmer> I'm not sure how much of the POSIX extensions are implemented in OS X's smb implementation at this point
<jelmer> nelius, Can you run with BZR_PDB=1 set and see what function is failing?
<nelius> jelmer: please advice, how do i set BZR_PDB=1?
<jelmer> it's an environment variable
<nelius> jelmer: btw this mornig i mailed that bzr selftest fails from macport
<nelius> jelmer: http://paste.uni.cc/17598
<jelmer> nelius: hmm, odd
<jam> I would rather just see the output from ~/.bzr.log
<jam> rather than BZR_PDB=1
<jam> I think jelmer was actually  wanting "bzr -Derror ..."
<jam> which prints the traceback to the screen
<jam> BZR_PDB=1 puts you into the debugger to interactively figure out what is going on
<jelmer> yeah, ~/.bzr.log would've worked too
<jelmer> though this helps us somewhat too
 * jelmer first thought would still be to blame Mac OS X's smb implementation
<jam> Well, it tells us that writing to a file descriptor is failing for some reason
<jam> Which does sound like a problem with smb://
<jelmer> it would be interesting to see if this also breaks with a Linux client
<nelius> if i try again and again, in some cases bzr enters the "Fetch phase 0/4" but in most cases it breaks just after i hit enter
<nelius> i'll paste the .bzr.log after the current try failed
<nelius> http://paste.uni.cc/17599
<jam> weird, it seems capable of copying the file texts up, but when we try to start pushing revisions
<jam> it fails at the signature file
<jam> you know what, though, we are probably creating the file with 0 bytes of data
<jam> So that the file exists, but doesn't hold anything
<jam> nelius: can you try this patch: http://paste.uni.cc/17600
<nelius> jepp, i'm trying... the fech phase takes really long... pleas hold the line
<nelius> argh...  it failed, but in a new file: /opt/local/lib/python2.5/site-packages/bzrlib/atomicfile.py(97)write()
<nelius> want a log?
<nelius> http://paste.uni.cc/17601
<lnxtech> If I want to setup a smart server that will be accessed via bzr:// does it use the local accounts of the server?
<vila> lnxtech: no it will use the account it is run from
<vila> you should use bzr+ssh for now if you want authentication
<lnxtech> vila: thanks.
<lnxtech> Also,  Is it possible to push/commit to two separate locations at the same time?  I want to have a bazaar repository for my projects at work, but I also want to mirror to my external server so I can work from home and what not
<vila> lnxtech: you want bound branches, look at 'bzr help bind'
<lnxtech> vila: thanks again
<jam> nelius: sorry about the delay, it looks like the same bug. We are creating a file and writing a 0-length string to it, and that is causing a failure
<jam> nelius: http://paste.uni.cc/17602
<jam> use that and the earlier patch
<jam> nelius: I filed bug 162930 for your use case
<ubotu> Launchpad bug 162930 in bzr "Bazaar tries to write 0-length strings to files" [Undecided,New] https://launchpad.net/bugs/162930
<ubotu> New bug: #162930 in bzr "Bazaar tries to write 0-length strings to files" [Undecided,New] https://launchpad.net/bugs/162930
<ubotu> New bug: #162931 in bzr "`bzr check` incorrectly reports about inconsistent parents" [Low,Confirmed] https://launchpad.net/bugs/162931
<vila> lnxtech: you may want to track progress on bug #126911, but don't hold your breath
<ubotu> Launchpad bug 126911 in bzr "Smart server has no built in authentication" [High,Triaged] https://launchpad.net/bugs/126911
 * vila dinner
<jam> mmmm.... food
<dato> hm. what was the recipe to merge two unrelated branches?
<dato> I just want to merge a branch containing one file into another.
<bialix> bzr merge -r0..-1
<dato> ah, thanks.
<dato> I was trying -r 0.. only
<bialix> if you supplied only one rev merge try to merge up to this revision
<bialix> so you actually did merge -r0..0
<lifeless> moing
<lifeless> adsl--
<jelmer> hey lifeless
<jelmer> I think that was the first time I see you actually disconnect from IRC :-)
<lifeless> I didn't. My ISP disconnected *me* :)
<jelmer> :-)
<lnxtech> When you run bzr init-repo does it default to using --trees or --no-trees?
<lifeless> trees
<lifeless> on bzr 0.9x and above
<lifeless> this is the same as '--init' creating a tree
<lifeless> so we felt it was more predictable
<lnxtech> If I'm wanting to create a shared repo to hold several projects it is generally recommended to use trees or no-trees?
<lnxtech> or is it personal preference?
<lifeless> personal preference
<lifeless> if you are working within the repo, trees is handy
<lifeless> if the repo is somewhere else, and you're using it like a svn or cvs repo, no-trees is better on disk space
<lifeless> jam: ping
<jam> lifeless: pong
<lifeless> jam: my stack of patches is growing alarmingly
<lifeless> jam: could you review e.g. find_text_key_references ?
<jam> sure
<lifeless> its not in BB for some reason
<lifeless> but it is on the list
<lifeless> abentley: ^ btw, that may be me misuing bzr send; I sent in a cherry pick to get the right diff for _generate_text_key_index
<igc> morning
<lifeless> hi
<lnxtech> lifeless: Why is no-trees better on disk space? (I've been reading through the documentation about this but for some reason I can't seem to get my head around the differences)
<dato> lnxtech: because it doesn't contain the trees. :)
<lifeless> say your source code is 100MB extracted on disk
<lifeless> and say you have 10 branches
<dato> lnxtech: you normally use --trees for the repository at home, and --no-trees for what you publish on your webserver.
<lifeless> our branch metadata is a few hundred bytes.
<lifeless> so with disk cluster overhead thats, oh, 200K for 10 branches.
<lifeless> and 1G for 10 working trees.
<sabdfl> lifeless: very cool perspective from Gerry, huh?
<lifeless> absolutely
<lifeless> Ian said about my reply: 'That's what I love about you Rob' - always to the point. :-)'
<glyph> hello!  let me preface this by saying that I am not trolling
 * jml waves
<glyph> I am about to recommend bzr to someone
<glyph> or rather, I'd like to
<glyph> but a hard requirement for them is sensible GUI tools for Windows clients, where tortoiseSVN has set a baseline for "reasonable"
<glyph> erm sensible
<glyph> is there such a thing for bzr yet?
<poolfool> glyph: http://bazaar-vcs.org/TortoiseBzr
<glyph> the other thing that this particular recommendation hinges upon is "asset" (large binary file) management
<lifeless> what does that mean
<glyph> lifeless: I'm not sure that I can give a good answer, because it's large and sprawling, and I am not an artist myself, but "this stuff: http://www.softimage.com/products/alienbrain/" is probably a good approximation
<glyph> lifeless: the person I am talking to is a game developer who needs a single version control system for all the art associated with the game as well as the code
<glyph> lifeless: they also need to give their (non-technical, windows-using, and somewhat obnoxious) publisher access to the code as it is developed, hence the GUI requirement
<lifeless> wowser
<glyph> everything has problems
<lifeless> anyhow
<glyph> AlienBrain is ... unsuitable for code
<lifeless> (the wowser was me looking at the alienbrain page)
<lifeless> bzr versions binaries fine
<lifeless> if they are /huge/ it will eat memory
<lifeless> and really big may thrash/error. We have a plan there.
<glyph> lifeless: is 200MB "huge"?
<lifeless> if you have 600MB of ram, no.
<lifeless> I think 3 times is our current peak
<lifeless> it might be 4 time
<glyph> hmm
<glyph> lifeless: if you were doing a checkin that touched 6 200MB files would you need a gig and a half of RAM or only 600M?
<glyph> erm I mean 4G
<lifeless> one base copy, one current copy, do a diff, generate a zip store
<lifeless> glyph: each file is done serially, 600M
<glyph> lifeless: that's on commit, right?  any issues with update?
<glyph> maybe I mean "pull"
<lifeless> in non-merge cases we'll extract the new text (200MB) and write to disk
<lifeless> in merge cases we'll extract 3 copies to do a 3-way merge and write a new one to disk, until it trips the binary flag. so 800MB peak.
<glyph> that's pretty hefty, but probably not a problem
<glyph> these artists have ridiculous machines
<lifeless> but I wouldn't expect artists to be trying to merge these files, that would bad.
<lifeless> binaries and merging. eewww.
<glyph> it's apparently not uncommon to have a 64bit windows box with 16G of RAM
<glyph> lifeless: actually that is the major feature of alienbrain, it does merging on things like photoshop and 3d studio max files
<glyph> lifeless: by having plugins for the appropriate programs which visually display the differences
<hugh> hi folks, I've been using bzr for a couple of months, after having used svn for a long time
<hugh> I'm still having trouble getting robust mental models of the entities in the bzr world
<glyph> (one day, when I have a billion dollars and nothing better to do, I am going to make bzr do that.  starting with Python, and "emacs" as the "appropriate program" to have a plugin for.)
<hugh> Could someone patiently explain to me the difference between a branch and a checkout?
<LeoNerd> A checkout contains copies of the actual files, that you can work on
<LeoNerd> A branch simply stores history
<lifeless> glyph: we can do that if someone writes the code; merging is already pluggable
<hugh> Ok, thanks; so what is the difference between a checkout and a working tree?
<LeoNerd> Other RCSes call it a "working directory" or a "workspace" or a "working tree" or similar
<lifeless> hugh: checkout is more about workflow - working like CVS and svn. working tree is as LeoNerd says.
<hugh> OK; the documentation repeatedly refers to a checkout as a thing rather than a process; this has been confusing.
<lifeless> hugh: it is - 'bzr checkout' creates a checkout
<lifeless> a checkout is a thing which is geared to act as a drop-in replacement for cvs or svn
<hugh> my point exactly, 'a checkout' a thing rather than a process...
<lifeless> its a thing to support a process :)
<hugh> is a checkout a thing that is any different from the working tree?
<lifeless> a working tree is a component of a checkout
<lifeless> a working tree is also present when you have a branch with a tree, so that you can edit and commit in the branch
<hugh> ok; what else are components of a checkout?
<igc> hugh: A new User Guide is coming that tries to help explain the concepts up front. See http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html for progress to date.
<lifeless> a checkout has one of two additional components: Either a 'branch pointer' that points to a branch somewhere else. We call this configuration a 'lightweight checkout'.
<lifeless> hugh: or it has a 'bound branch', which is a regular branch with a configuration setting that makes commits/pushes/pulls etc to it also be applied to a remote branch.
<lifeless> we call that a 'heavyweight' checkout, because you have all the history of the project locally so they take more time to create, and more disk space
<hugh> ok, so the lightweight checkout is more like the svn view of things, whereas the heaveyweight checkout bring in bzr's ability to keep the
<hugh> entire branch history locally
<lifeless> right
<lifeless> lightweight checkouts have minimal offline capability; heavyweight checkouts have comprehensive offline capability
<lifeless> many people don't use checkouts at all, just regular branches. It really depends on your team workflow and needs.
<lifeless> if you are a solo developer, you can ignore checkouts.
<hugh> so the different checkout variants each get you a working tree, but with more or less support for offline capabilities
<hugh> no I'm working with several folks sitting in different states
<hugh> we're only rarely at the same site at the same time
<hugh> so we have an 'official' repository, and one guy who's more bzr savvy keeps one or more other branches.... that mirror the official repo
<hugh> the basic model of: modify files, do local commits, do a push   more or less makes sense, it's when things go wrong that I get confused
<glyph> lifeless: that's great to hear
<hugh> and then I go look at the man page for the 70th time and try to solidify my mental picture of what's happening :-)
<beuno> hugh, if you're going to be doing local commits, I believe branching makes more sense the checkouts
<glyph> lifeless: It looks like tortoisesvn isn't quite there yet, although it's getting close
 * glyph reluctantly recommends SVN plus a bunch of horrible Apache configuration
<hugh> I think I have a local branch (but am not sure). I do local commits and then push later
<beuno> when using checkouts, local commits are normally an exception (have to add an extra parameter), but when branching out, it's local by default, and you send the changes off with "push
<beuno> " when needed
<hugh> yes, I must have a local branch
<beuno> hugh, sounds like bzr branch is what you want
<beuno> unless lifeless proves me wrong  :D
<lifeless> glyph: ah well.
<lifeless> beuno: I think you're right
<lifeless> checkouts are when you want to be in lockstep with other people
<lifeless> have a look at the Workflows wiki page
<beuno> hugh, using checkouts for that kind of workflow won't break anything, just make it a bit more uncomfortable as you will have to be adding an extra parameter every time
<lifeless> beuno: extra parameter ?
<beuno> lifeless, --local?
<lifeless> oh right; when you want offline
<beuno> (when using checkouts)
<lifeless> anyhow, my advice is -
<beuno> he was saying he does local commits until he wants to send it off to the parent branch
<lifeless> if you are used to cvs or svn, use the cvs and svn commands - bzr checkout, bzr commit, bzr merge, bzr branch REMOTEURL to create a new branch then bzr checkout that URL
<lifeless> if you are not used to cvs or svn, do not use the checkout command at all until you are comfortable with regular branches
<jml> how can you use an external diff util w/ bzr?
<jml> there's a diff option option, but not a diff cmd option.
<beuno> jml, you can use aliases for that
<jml> how?
<dato> jml: I *think* there is a plugin
<beuno> jml, http://doc.bazaar-vcs.org/latest/en/user-guide/using_aliases.html
<lifeless> jml:  it will automatically use gnu diff if the options are not supported in bzr
<beuno> wait, the example isn't there
<lifeless> jml: also there is a diffutils plugin
 * beuno looks for the example of using different diff utils
<beuno> wasn't there one laying around that used meld?
<lifeless> I thought diffutils did that
<lifeless> meld is in my ep2006 talk slides
<igc> jml: the diffutils plugin is great
<igc> I use it in combination with meld all the time
<YGingras> I see that mercurial uses bzr's diff3, anyone knows if it have been factored out from either rev control system?  I'd need 3-way merge in Gazest, a wiki I'm working on
<igc> bbiab
<lifeless> YGingras: you could just import bzrlib :)
<YGingras> lifeless is it exported in a way that I can use it without a bzr repo?
<lifeless> yes
<YGingras> will bzr easy_install cleanly on most plateforms?
<YGingras> I see C extentions: probably not
<lifeless> they are optional
<lifeless> and
<lifeless> won't affect loading the diff3 stuff you need
<YGingras> so, in Merge3.__init__(self, base, a, b), base, a and b are paths?  I thought those were rev-ids or something
<hugh> lifeless: beuno: others: thanks for your feedback; this is helping me a lot; catch you later
<YGingras> ok, I see it: list of lines
<YGingras> lifeless: how does it compares with gnu diff3?
<beuno> hugh, anytime  :D
<lifeless> YGingras: they are texts
<lifeless> Merge3(['line\n',
<lifeless> 'line2\n'], [], [])
<lifeless> for instnace
<YGingras> lifeless: sounds good, I think I'm going to use it.  Will you guys be mad at me if I end up repackaging it yet another time? :-)
<lifeless> mad? no. Think its a bit pointless and that you miss out on improvements; yes.
<YGingras> of course I'm going to watch for improvements but this file seems really stable ;-)
<lifeless> I'm surprised more of the vcs infrastructure isn't usable for you; wikis and branches have lots in common
<YGingras> lifeless: I use some bits from mercurial for finding LCA, I probably go hunting in bzr an hg again when I implement new features
<lifeless> well
<lifeless> I was meaning more about history storage
<lifeless> e.g. using a pack repository object directly, no commit or inventory objects though
<YGingras> lifeless: that questing comes often.  I don't know how you do it precisely in bzr but interface offered by drcs is typically for a whole repo while most wiki acitons are for a single file
<YGingras> it's easy to roll my own branch on a single file that to call bzr in  a pipe to branch the repo everytime someone hits the edit link
<lifeless> YGingras: using the library its easy to use the core storage facilities to do what you need
<lifeless> I wouldn't have mentioned it if it wasn't trivial
<YGingras> lifeless: I can't count the number of persons who mentioned calling git in a pipe like it was trivial
<lifeless> meh
<lifeless> I wouldn't call a pipe level interface trivial
<lifeless> libraries are so much better
<YGingras> "use git: git is super fast => your wiki is going to be uber fast"
<lifeless> anyhow, the point is that you don't need whole-tree operations; and bzr's core doesn't force you to use whole-tree operations in the sort of scenario you are talking about
<YGingras> lifeless: that's really interesting, I'll have a serious look at it
<lifeless> In particular I'm thinking of PackRepository's text index / mapped knits layer
<lifeless> you could use the path to the wiki page as the key
<lifeless> so this does not give you 'a wiki you can bzr branch', it just gives you a db that supports annotate and other such things as built in primitives
<YGingras> lifeless: how would it scale across multiple webhead?  I recall some obsure performance issues on NFS
<lifeless> uhm
<lifeless> packs should be fine on nfs
<lifeless> granular locking during data insertion
<lifeless> no need for oslocks
#bzr 2007-11-16
<schierbeck> jelmer: hi
<jelmer> schierbeck: hi
<schierbeck> shit, i'm high as hell
<schierbeck> these two american dudes are subverting me
<schierbeck> they managed to get hold of a bong
<schierbeck> now they're trying to take it out on me
<schierbeck> sorry about the rant
<Peng> .........
<abentley> lifeless: Was it just delayed or am I confused?
<jelmer> Peng: ... indeed
<lifeless> abentley: was what delayed?
<abentley> find_text_key_references
<lifeless> I sent it in first
<abentley> Okay, I was confused earlier, and thought I needed to look for [MERGE] _generate_text_key_index
<abentley> It appears I haven't received any email about find_text_key_references
<Peng> Gack!
<Peng> First time I try to push the pack repo, and I get an error!
<abentley> lifeless: Okay, found it.
<abentley> It got marked superseded.
<abentley> Which is my bug, not your fault.
<Peng> bzr: ERROR: Could not understand response from smart server: ('error', "<bound method KnitPackRepository.leave_lock_in_place of KnitPackRepository('chroot-1082717612:///path/to/.bzr/repository/')>")
<Peng> Woah! bzr serve is still running.
 * Peng pokes lifeless.
<Peng> Seems it's a NotImplementedError.
 * Peng wanders off.
<Peng> server's .bzr.log: http://paste.pocoo.org/show/10721/
 * Peng wanders off.
 * Peng pushes over sftp.
 * Peng wanders off.
 * beuno is playing around with bug #162264 and woders if "Transfer phase" isn't better then "Fetch phase" considering it uses the same for push/pull. Hacking around to display different things for each seems like an overkill
<ubotu> Launchpad bug 162264 in bzr "Push progress bar shouldn't say "Fetch..."" [Undecided,New] https://launchpad.net/bugs/162264
<lifeless> Peng: I have a faster reconcile patch -> list
<lifeless> Peng: pack reconcile on monday I hope
<Peng> What about this traceback?
 * Peng wanders off.
<YGingras> I'm playging with bzrlib.merge3, I don't get the same merge as GNU diff3.  Anyone can tell what kind of differences to expect?
<igc> YGingras: I believe our merging is based on Codeville's merge algorithm which is a bit more intelligent
<YGingras> igc: you don't seem to have the "|||||||" section when there is a conflict
<YGingras> any way to change the labels?
<igc> I'm not sure if it's packaged separately to "bzrlib.merge3" or just included within it. abentley can tell you the details
<igc> no idea sorry
<YGingras> ok, I found the lables
<poolie> YGingras, you can get that with --show-base i think
<YGingras> print "".join(m.merge_lines(base_marker="|||||||"))
<YGingras> this gets me more or less the same stuff
<YGingras> poolie: I'm integrating with the API only, I don't use bzr (yet?)
<abentley> YGingras: diff3 and merge3 used in that way don't minimize conflicts, because minimizing conflicts destroys the correlation between the base and the conflicted region
<YGingras> abentley: but the diff is much easier to read
<YGingras> maybe try without base and call with the base when there are conflicts anyway
<YGingras> that should be done on a hunk by hunk basis
<YGingras> humm I won't sleep early tonight
<abentley> No, you're not getting what I mean.
<abentley> showing the base will not cause a merge to conflict when it would otherwise not conflict.
<abentley> But it will make the conflict regions longer than they have to be.
<YGingras> oh
<abentley> btw, long time no see.
<YGingras> so, the only non-crap solution is visual side-by-side?
<YGingras> abentley: indeed : )
<abentley> Visual side-by-side will have the same issue if you're showing the base.
<YGingras> abentley: but you can hightlight what is a conflict and what is context with the base
<YGingras> kdiff3 has a not too confusing color code
<abentley> Well, just be aware that in some places you'll have the base in conflict with THIS and OTHER, while THIS and OTHER are in harmony.
<abentley> Personally, I'll take a merge3 with minimized conflicts over side-by-side any day.
<YGingras> abentley: this is for a wiki, most of the time this should be easy to merge anyway but I plan full-namespace branching later on: this one will require good merge and conflict resolve gui
<abentley> Yes, a colleague pointed out your wiki.
<YGingras> abentley: you mean with the makers?
<YGingras> since I force long lines spliting, markers are no too bad
<abentley> I'm not sure what you mean.
<abentley> Are you asking what I mean by merge3?
<YGingras> it was the complete hell when I allowed one line per para
<YGingras> abentley: yes
<YGingras> I mean, by merge3 you mean merge with conflicts makers?
<abentley> by merge3, I mean the kind of merge output that Bazaar gives by default.
<abentley> Yes, with conflict markers.
<YGingras> and without the base
<abentley> Right, and with conflict reduction enabled.
<abentley> So that only lines that differ between THIS and OTHER can conflict.
<YGingras> abentley: asside from the fact that GNU diff3 defaults to show the base, any note worthy differences in the acutal merge?
<YGingras> can diff3 even hide the base?
<abentley> We use a sequence matcher that finds the longest common subsequence, instead of the longest common substring.
<abentley> YGingras: Sure.  Remember Arch?
<YGingras> yes
<YGingras> It used diff3?
<abentley> Yes.
<abentley> I don't remember the exact commandline it used.
<YGingras> I'll dig the source
<YGingras> thanks for the pointers
<abentley> No problem.
<YGingras> I keep you posted, bzrlib will be the fallback if I can't find diff3, or should it be the other way around?
<abentley> I think either is a worthy choice.  We didn't want a dependency on diff3, so we built our own.
<YGingras> the magic spell is: diff3 -E -m my.txt base.txt your.txt
<YGingras> can I know if there was a conflict or do I have to parse the merge?
<YGingras> oh, it's "base, my, your", not "my, base, your".  No wonder I didn't get the right merge...
<YGingras> but the command line is "my, base, your".  You guys are playing tricks to the API users? ; )
<YGingras> and you flipped it the otherway around for merge_lines()
<fullermd> Just making sure you're paying attention   ;)
<YGingras> would you merge a patch straightening this up a bit?
 * YGingras imagine the havok
<YGingras> is this the right error message: exceptions.TypeError: sequence item %zd: expected string, %.80s found
<YGingras> anyone sees what I did wrong: http://pylonshq.com/pasties/553
<YGingras> seems to be a proble with workingenv
<YGingras> virtualenv seems to be just fine
<lifeless> YGingras: we'd definately consider a patch making things more clear in the api
<poolie> ok, i'm signing off
<YGingras> lifeless: that will silently break all existing code
<lifeless> YGingras: we have good support for versioning API's. See our developers documentation and the symbol_versioning module.
<lifeless> poolie: night!
<lifeless> poolie: I don't have transport to john's thing ...
<poolie> and therefore you're wanting transport, or you're not going?
<YGingras> lifeless: I'll see what it involves.  What do you prefer? (my, old, your)?
<lifeless> it could go either way :)
<lifeless> YGingras: I haven't looked closely enough at the situation to tell why its unclear.
<lifeless> YGingras: e.g. maybe it just needs a better docstring, or - whatever.
<YGingras> lifeless: the order change gratuitouly from one call to the other
<YGingras> I'd pick one order and stick to it
<lifeless> YGingras: that sounds fair to me
<YGingras> instead of requiring to read the docstring for every single method call
<lifeless> anyhow, I don't have an opinion
<lifeless> on the 'right' order yet
<lifeless> I think left/right/base makes most sense
<YGingras> (my, old, your) is easier to remember, there is a mnemonic
<YGingras> but I forget what is was... : \
<lifeless> because 2-way is left/right only
<lifeless> so this makes three-way an extension
<lifeless> OTOH for diff you have old/new so base/left/right might be better
<lifeless> :)
<lifeless> no help at all I realise :)
<YGingras> "diff3 MINE OLDER YOURS" "
<YGingras> You can remember the order of the arguments by noting that they are in
<YGingras> alphabetical order.
<YGingras> "
<YGingras> ok, the mnemonic is crap
<lifeless> I'm off for family time
<lifeless> ciao
<YGingras> later
 * igc food
<Peng> lifeless: Now that packs are in bzr.dev, is your repository branch abandoned?
 * Peng wanders off.
<lifeless> Peng: no, it has various not-yet-merged improvements
<TeXitoi> hi
<TeXitoi> bug: try this:
<TeXitoi> pinot@pc-pinot:~/tmp$ mkdir ThÃ¨se
<TeXitoi> pinot@pc-pinot:~/tmp$ cd ThÃ¨se/
<TeXitoi> pinot@pc-pinot:~/tmp/ThÃ¨se$ bzr init .
<TeXitoi> pinot@pc-pinot:~/tmp/ThÃ¨se$ echo foo > bar
<TeXitoi> pinot@pc-pinot:~/tmp/ThÃ¨se$ bzr add .
<TeXitoi> added bar
<TeXitoi> pinot@pc-pinot:~/tmp/ThÃ¨se$ bzr commit
<TeXitoi> bzr seems unable to commit in a directory with non-ascii character.
<LeoNerd> Works for me
<TeXitoi> LeoNerd: devel or last stable version?
<TeXitoi> I have debian's 0.92.0
<beuno> TeXitoi, what error are you getting?  traceback?
<LeoNerd> Bazaar (bzr) 0.92.0.candidate.1
<TeXitoi> yes
<LeoNerd> From debian/unstable
<beuno> maybe it's bug #63324?
<ubotu> Launchpad bug 63324 in bzr "exceptions.UnicodeEncodeError: 'ascii' codec can't encode character" [Medium,Confirmed] https://launchpad.net/bugs/63324
<beuno> or #77533
<beuno> bug #77533
<ubotu> Launchpad bug 77533 in bzr "bzr crashes with invalid filenames" [Low,Confirmed] https://launchpad.net/bugs/77533
<TeXitoi> http://pastebin.com/m60424600
<LeoNerd> http://paste.leonerd.org.uk/?show=1866  <== output from my successful run
<LeoNerd> What's $LANG set to..? Mine has en_GB.UTF-8
<TeXitoi> see the pastebin
<TeXitoi> fr_FR.UTF-8
<beuno> TeXitoi, you're not running Cygwin, are you?
<TeXitoi> no
<TeXitoi> debian testing
<TeXitoi> It work with bzr ci -m "bla" but not with bzr ci
<TeXitoi> LeoNerd: try
<TeXitoi> echo foo > bar
<beuno> TeXitoi, would you mind filing a bug with all this information?
<TeXitoi> bzr ci
<LeoNerd> Ahh... yes
<TeXitoi> beuno: If you think the bug is not yet reported, sure
<TeXitoi> Mmm
<LeoNerd> edit_commit_message_encoded() in the stack trace
<LeoNerd> Whereas, ci -m "message"  doesn't
<beuno> TeXitoi, it does sound like an unreported bug, yes
<TeXitoi> I need to create a lanchpad account for that?
 * TeXitoi hates creating accounts
<beuno> I might be wrong, but the worst that can happen is it gets marked as a duplicate
<beuno> TeXitoi, it's a one time thing  :p
<TeXitoi> beuno:<troll> I know, but I don't like to use non free software</troll>
<TeXitoi> I'll ask a friend that have an account
<beuno> TeXitoi, I can file it for you, I'll try and reproduce it here
<beuno> TeXitoi, I can reproduce it perfectly, I'll file it now
<TeXitoi> nop
<beuno> TeXitoi, nop?
<TeXitoi> or it will be duplicated
<beuno> oh, you're filing it already?
<TeXitoi> A friend is doing the bug report
<vila> I think it's bug 84403
<ubotu> Launchpad bug 84403 in firefox "Firefox crashes unexpectedly  (dup-of: 73536)" [Undecided,Incomplete] https://launchpad.net/bugs/84403
<ubotu> Launchpad bug 73536 in firefox "MASTER Firefox crashes on instant X server shutdown" [Medium,In progress] https://launchpad.net/bugs/73536
<vila> ghaa I meant 84043
<vila> ghaa I meant bug 84043
<ubotu> Launchpad bug 84043 in bzr "commit fails to invoke external editor in non-ascii directory" [Medium,Confirmed] https://launchpad.net/bugs/84043
<beuno> vila, that sounds about right
<vila> traceback looks pretty similar
<vila> please add a comment inside that bug instead of creating a new one if it's still possible
<vila> Oh, and the obvious work-around is to not use accented letters in the directory name (TeXitoi)
<TeXitoi> vila: I know ;-)
<vila> TeXitoi: ok, just wanted to be sure. I'm pretty sure I've seen the subject discussed recently so rest assured that the problem is taken care of
<TeXitoi> vila: are you sure that it must be a comment to that bug?
<TeXitoi> it seems closer, but the trace is much longer in my case
<vila> the important part is the end so if they match you can be pretty sure it's the same root cause, if you're unsure file a new bug but mention the old one so that anyone fixing one will not miss the other
<TeXitoi> ok
<TeXitoi> it will be a comment
<TeXitoi> or not finaly, but with ref : https://bugs.launchpad.net/bzr/+bug/163123
<ubotu> Launchpad bug 163123 in bzr "Crash when repository is in a directory with non ascii characters" [Undecided,New]
<ubotu> New bug: #163123 in bzr "Crash when repository is in a directory with non ascii characters" [Undecided,New] https://launchpad.net/bugs/163123
<YGingras_> lifeless: so, did you find enlightenment on the right order in your sleep?
<jam-laptop> YGingras_: lifeless is in Australia, so won't be online for another couple hours
<jam-laptop> (he just got back, so he may still be jetlagged and come online a bit earlier than usual)
<jam-laptop> YGingras_: you were here yesterday talking about using the code for a wiki, right?
<YGingras_> jam-laptop: oh, I'll wait a bit then : )  Yes, I do use the code in the wiki now
<jam-laptop> By the way, while git may be fast, I found that spawning it in a pipe isn't all that, at least I was working on a converter, and spawning it 16 times to set up a branch put data in, etc was quite slow
<jam-laptop> the 'git fast-import' stuff was pretty quick, though
<jam-laptop> So it might just be process spawn overhead on this machine
<jam> YGingras_: I can try to help. I'm not sure what the "right order" you are talking about (I don't see it in your earlier conversation.)
<jam> what wiki is it, by the way
<YGingras_> jam, in merge3.py, many function calls take the 3 params (mine, old, yours)
<YGingras_> jam: but they keep changing the orger
<YGingras_> order
<YGingras_> so, we think that a bit of uniformito might help
<YGingras_> jam: Gazest: http://ygingras.net/gazest
<jam> well, if you use our code, can you at least put up our name on the About section :)
<YGingras_> jam: sure : )
<jam> in merge3.py I only see 2 places that a user would call
<jam> Merge3(base, a b)
<jam> and Merge3.merge_lines()
<jam> Though I agree that merge_lines(name_base, name_a, name_b) would probably be better
<jam> I think it is expected that you would explicitly call the parameters
<jam> so
<jam> merge_lines(name_base='foo', name_a='a', name_b='b', ...)
<jam> In which case you can supply them in any order.
<YGingras_> jam: the command line interface has yet another order
<jam> YGingras_: the command line order is because that is what diff3 and other tools expect
<jam> so better to be compatible
<jam> that way you can be a 'drop-in' replacement
<jam> But I think "base, mine, other" is probably a more logical layout
<jam> I suppose we could go either way
<jam> though  if we call them 'a' and 'b' it is a bit odd
<jam> 'a', 'base', 'b'
<jam> If they were renamed it would probably be okay
<jam> I think we generaly use
<jam> THIS, BASE, OTHER
<YGingras_> jam: no order is really good and mnemonic but the diff3 one has been with us for so long that we assume it
<jam> which makes it clearer anyway.
<jam> I think the problem is calling them 'a' and 'b' doesn't give you a hint about them
<YGingras_> jam: yeah, a rename would probably be in order
<jam> hmm... it seems like python merge3.py isn't really meant to be a diff3 substitute
<jam> since it always annotated
<jam> annotates
<jam> probably more for Aaron (who wrote the code) to see what was going on
<YGingras_> the api is ok
<YGingras_> I do merge = list(m3.merge_lines(MY, YOUR, OLD, MARKERS[0], MARKERS[2], MARKERS[-1]))
<YGingras_> which gives me mostly the same stuff as diff3 -E -m
<jam> right
<jam-lapto> YGingras_: when going to pages like http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/hist?rev_id=6
<jam-lapto> How do you populate the 'rev_id' ?
<jam-lapto> At least it seems like you are using the number 6, but there are only 3 revisions
<jam> silly chat program...
<jam> anyway, When you look at: http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/rev/6
<jam> it says that it might differ
<jam> but it seems to be the most up-to-date version
<jam> jam-lapto: YGingras_: when going to pages like http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/hist?rev_id=6
<jam> [10:50am] jam-lapto: How do you populate the 'rev_id' ?
<jam> [10:50am] jam-lapto: At least it seems like you are using the number 6, but there are only 3 revisions
<jam> [10:51am] You are now known as jam.
<jam> [10:51am] jam: silly chat program...
<jam> [10:51am] jam: anyway, When you look at: http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/rev/6
<jam> [10:51am] jam: it says that it might differ
<jam> [10:51am] jam: but it seems to be the most up-to-date version
<jam> I was trying to go to the history page to see what the current version is
<jam> and it was pretty unclear
<jam> that I was already at the most recent
<YGingras__> jam: just wave me when abentley and lifeless are around; we'll see if a patch is really in order
<jam> sure
<jam> I'm guessing that our "maintain backwards compatibility" general rule will outweigh the benefit of renaming... but maybe not
<YGingras__> "?rev_id=6" is an artefact of Routes memory
<YGingras__> I'm using Routes as the dispatcher and it recalls stuff so I can do "< a href=%s..." % url_for(action="edit")
<YGingras__> and forget about the other params
<YGingras__> but once in a while, it recalls too much and that clutters the URLs
<YGingras__> jam: yeah I'm not sure about the patch either but lifeless seems to imply that you have a super flexible versionning system that will brevent any breakage
 * YGingras__ shrugs
<jam> its more about having people like you who might be using it outside of the scope of our little project :)
<jam> and not wanting to cause you grief because of arbitrary parameter renaming
<YGingras> I hate my ISP
<YGingras> jam: did by remarks on routes memory made it through?
<jam> YGingras: "that sometimes it remembers too much" yes
<jam> YGingras__: but once in a while, it recalls too much and that clutters the URLs
<YGingras> good : )
<vila> jam: ping
<jam> hi vila
<vila> hi :) I just run the bzr test suite and get 31 errors related to gtk (up to date from  http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/)
<vila> but if I run bzr test-gtk I got: Ran 63 tests in 2.896s
<vila> I thought test-gtk was running all gtk tests >-/
<vila> by the way they all failed with:  'int' object is not callable
<vila> with a traceback ending with:  file_label = gtk.Label(_('Files'))
<vila> Does that ring a bell or should I investigate ?
<vila> hmmm, I smell a gtk initialization pb again...
<vila> hmm, I bet cmd_gselftest.run taking care of sys.getdefaultenconding() may have something to do with it...
<vila> jam: bzr selftest --no-plugins works and bzr selftest gtk works too :-) They just can't agree when running together.
<jam> vila: something is overwriting _
<jam> and gtk sets it as a builtin
<jam> I'm guessing that we have code which does
<jam> _, foo, bar = ...
<lifeless> hmm
<lifeless> import gtk
<lifeless> import builtins
<vila> In the global name space ?
<lifeless> del builtins._
<vila> :)
<lifeless> import __builtin__
<lifeless> >>> import __builtin__
<lifeless> >>> import gtk
<lifeless> >>> __builtin__._
<lifeless> Traceback (most recent call last):
<lifeless>   File "<stdin>", line 1, in <module>
<lifeless> AttributeError: 'module' object has no attribute '_'
<lifeless> >>> print _
<lifeless> Traceback (most recent call last):
<lifeless>   File "<stdin>", line 1, in <module>
<lifeless> NameError: name '_' is not defined
<jam> yeah, I'm not seeing where it is actually triggering yet
<jam> it might be gobject or pango
<jam> pango is pretty likely
<lifeless> >>> import pango
<lifeless> >>> __builtin__._
<lifeless> Traceback (most recent call last):
<lifeless>   File "<stdin>", line 1, in <module>
<lifeless> AttributeError: 'module' object has no attribute '_'
<lifeless> >>> print _
<lifeless> Traceback (most recent call last):
<lifeless>   File "<stdin>", line 1, in <module>
<lifeless> NameError: name '_' is not defined
<lifeless> >>>
<jam> I don't see anything in the bzr-gtk code which is doing it
<jam> maybe it is a side effect of creating a window?
<jam> I'm trying to find it
<lifeless> it gets put in builtins right ?
<lifeless> bleh
<jam> as near as I can tell
<lifeless> ok try this
<jam> it certainly isn't being put into the local namespace each time
<lifeless> create a fake module
<jam> (Pdb) _
<jam> <bound method NullTranslations.gettext of <gettext.NullTranslations instance at 0x31b9968>>
<lifeless> put that in sys.modules
<lifeless> jam: check in __builtin__
<jam> (Pdb) import __builtin__
<jam> (Pdb) __builtin__._
<jam> <bound method NullTranslations.gettext of <gettext.NullTranslations instance at 0x31b9968>>
<jam> yep
<jam> it is in __builtin__
<vila> jam: don't add pdb to the equation
<lifeless> anyhow, put a module which is a regular object with setattr hooked to pdb
<vila> import gettext
<lifeless> in sys.modules['__builtin__']
<jam> I'm pretty sure that gettext doesn't do it automatically
<jam> but I'll check that too
<lifeless> it will need to hold a reference to the original __built__
<lifeless> and answer getattr from that
<lifeless> if you do that, then when gtk setattrs _ on __builtin__, it should trap
<lifeless> and you can get a backtrace
<lifeless> woot, my string.find bug has been fixed
<lifeless> so in about 5 years we can use it
<lifeless> http://bugs.python.org/issue1259
<lifeless> later, wow calls
<vila> later, dinner with friends calls :)
<vila> jam: I'll read the log if you find any fix or work-around (not urgent anyway)
<jam> vila: sure, I'm trying to track it down
<jam> but yeah, having a __builtins__._() is not a great way to do i18n
<jam> but it also means we should change our code base to avoid the '_' object
<jam> lifeless: have fun
<jam> It seems, though, that doing __get_attribute__ seems to cause problems with __import__ not being found :(
<jam> still looking
<vila> What about using 'i18n' instead of '_' ?
<jam> I would be happy enough with that, it just isn't the standard 'gettext()' way
<jam> and it just happens that gettext conflicts
<jam> with a common python idiom
<jam> of using '_' as a "I don't care about this" variable
<jam> (and as a last action variable)
<vila> yup, perl heritage :)
<jam> trying to wrap __builtin__ I'm still getting "has no member __import__" ...
<jam> which breaks everything
<jam> hmm.. it seems to have triggered by the time plugins have imported
<jam> which is *before* gtk should be imported
<jam> maybe in 'gettext.install('olive-gtk')' ?
<jam> yep
<jam> gettext.install does bad things
<jam> vila: 'grep -rnI "\<_\>" bzrlib' shows it being used in quite a few places in our codebase
<jam> dirstate.py
<jam> fetch.py
<jam> and a few others
<Zenom> If we have 3 programmers constantly working on the same project (for instance a new project) and we are a kind of jack of all trades, can bzr still help us ?
<beuno> Zenom, absolutely, it does the same (and more) as other VCS
<Zenom> beuno: i guess my concern is like 2 of us could be working on the same code
<Zenom> i am worried about merging changes appropriately etc
<Zenom> and the time it takes to merge all these changes or reviewing them
<beuno> Zenom, you will have to do it eventually, so it's probably best if you have a VCS
<beuno> we work on the same files here all the time
<beuno> and rarely have conflicts
<Zenom> we use svn now bu we are  tired of like "hey billy are you in index.py"
<Zenom> lol
<beuno> and when we do, they are easily resolved in 1 or 2 minutes
<Zenom> how often are you guys committing your changes?
<Zenom> to the main repo?
<beuno> Zenom, it varies, but I tend to commit and push every time I finish a specific task
<beuno> logical blocks of changes
<beuno> sometimes I commit for a while and then send
<Zenom> so you would commit to local branch, then push the  changes to the main repo for review
<beuno> but I try yo keep it to the least amount of time possible so we don't diverge as much
<jam> Zenom: well, you could use a checkout so that the push is automatic
<beuno> Zenom, yeap, I do bzr branch
<jam> I usually commit 10+ times per day ...
<beuno> work locally, then push when needed
<Zenom> i guess no matter what there still needs to be communication
<jam> you could work locally, commit, and then merge your changes back into trunk
<Zenom> ie., im going to fix the connection bug or whatever
<beuno> we have a different workflow here (web development), so I think, between all the projects, I commit close to 50 a day, and push 15-20 times
<Zenom> so that others don't try and correct the same bug i am assuming
<jam> Zenom: yah, Bazaar can't solve social issues, but it does make it easier to resolve some conflicts
<beuno> Zenom, yes, but that is out of the scope of bzr, although if you read the commits you might have an idea of what is going on
<Zenom> do you guys typically have 1 package maintainer?
<Zenom> or just let anyone push to trunk
<beuno> Zenom, here, we let everyone push to trunk
<jam> Zenom: The Bazaar project has about 10 people that can push to trunk, but all pushes go through a Patch Queue Manager
<jam> which forces the test suite to pass before it accepts anything
<beuno> (here == my office, not bzr development)
<Zenom> right
<Zenom> i want to try something as i hate the situation with svn (ie, when no internet, on a plane etc)
<jam> which works very well for having a stable trunk
<jam> Zenom: with bzr-svn you can give Bazaar a try
<Zenom> but i worry about some of our programmers who don't know squat but how to click commit :)
<jam> and still push your changes back into svn
<beuno> you can always revert changes, so I don't mind going over to someones desk and kicking them in the face for deleting my file  :p
<Zenom> interesting, we want to give it a shot gonna mess with it a bit now
<Zenom> are there any mac osx guis for bzr?
<beuno> Zenom, as jam proposes, bzr-svn can work for you, with checkouts and using --local when commiting you can have both workflows, and choose the apropriate one as needed
<Zenom> well i have this need to use everything how it is intended
<Zenom> and i would like to have a more distributed environment
<jam> well, for people who need it, they can have just a checkout of 'trunk'
<Zenom> my concern was mostly with interaction with merges, but i guess its no different, i could commit, someone could checkout and break my code
<jam> so that "just commit" works
<beuno> Zenom, sounds like bzr is a perfect match  :D
<jam> and then for people who want more distributed
<jam> they can do local branches, etc.
<Zenom> ok so for a beginner at bzr what is the way you guys suggest?
<beuno> Zenom, people will be able to break your code no matter what. Unless you use seperate branches and merge with each other to make sure before sending to trunk
<Zenom> just look at the tutorial and go for broke?
<Zenom> beuno: true, i guess really its no diffferent in that sense
<beuno> Zenom, yeap, you should get used to it very quickly
<Zenom> if it breaks it needs to be fixed or revert back
<beuno> the only times I end up manually fixinf merges is when two of us edit the same line, which isn't that often. bzr is pretty smart about merges
<beuno> the patch queue manager workflow jam proposed isn't a bad idea either
<beuno> you can write up some tests to ake sure nothing breaks trunk before committing to it
<beuno> lifeless, you wouldn't happen to bored, would you?   we're trying to figure out how you guys do a wierd merge in bzr.dev for our XML tests, but we're out of ideas
<beuno> (or anyone else for that matter)
#bzr 2007-11-17
<keescook> I've been browsing docs, but I haven't found mention of client-side hooks.  does such a thing exist?
<keescook> e.g. I'd like to have a pre-checkin hook that runs a script (say to verify syntax, etc)
<beuno> keescook, plugins?
<beuno> installed locally
<beuno> you can wrap around the commit/push command
<beuno> and make it do whatever magic you need
<jam> keescook: there is a precommit hook
<keescook> hmm... but that won't follow the repo for branchers?
<jam> look in bzrlib/branch.py
<jam> for BranchHooks
<jam> should describe the list of hooks
<jam> I think there might be another documentation in doc/*
<jam> keescook: the precommit fires after we have built up all the commit information
<jam> but just before the branch is updated
<keescook> jam: so follow http://bazaar-vcs.org/WritingPlugins and use precommit ?
<keescook> (there isn't a PQM on the client side?)
<keescook> jam: hm, there isn't a precommit listed in class BranchHooks(Hooks):
<jam> keescook: what version of bzr do you have
<keescook> hm, looks like 0.90.0 ... one sec
<jam> it looks like 0.90 doesn't have pre_commit
<jam> it was introduced in 0.91
<keescook> cool, 0.92 installing now...
<keescook> (I've been waiting for kernel/lrm in hardy before doing a full-blown dist-upgrade)
<keescook> sweet, yup, pre_commit.  :)
<keescook> http://bazaar-vcs.org/WritingPlugins could use some updating.  ;)
<jam> keescook: looks like, one of the problems with doing monthly releases
<jam> lots of stuff changes every month
<keescook> hehe
<jam> and you really need a full documentation audit each time
<keescook> I will write up a plugin for "pre commit test"...
<keescook> jam: do you have any examples of plugins using hooks?  There's nothing in bzrtools that calls install_hook
<jam> keescook: bzr-email
<jam> lp:bzr -email
<keescook> jam: cool, thanks.
<keescook> jam: is there a way to abort the checkin if a hook fails?
<jam> raise an exception
 * jam => baby time, be back lateer
<Odd_Bloke> Stop.
<Odd_Bloke> Baby time.
<jam> Odd_Bloke: you can't touch this
<fullermd> Gaah.
<fullermd> You'll both be receiving a bill from my therapist...
<jam> fuller time
 * fullermd dons his parachute pants.
 * keescook hammer-slides out of frame
<ubotu> New bug: #163266 in bzr-pqm "pqm-submit returns "Connection timed out" error and traceback" [Undecided,New] https://launchpad.net/bugs/163266
<Peng> Oooh. I didn't know bzr check might use a gig of RAM.
 * Peng swaps.
 * Peng watches the mouse cursor skip across the screne.
<Peng> screne?
<Peng> Usually lag goes the other way.
<Peng> Oh good, it's done.
<Peng> lifeless: Is your pack-repository.knits branch abandoned now?
<Peng> Hmm. Loggerhead and paramiko both had a couple inconsistent parents.
<lifeless> Peng: that branch? yes, no need to update it at the moment as everyone with bzr 0.92 or new can read it
<lifeless> Peng: you might try my faster-smaller reconcile patch, to do check.
<lifeless> same logic, so check will use less ram
<Peng> lifeless: So it's not abandoned entirely, just for the moment?
<lifeless> right
<lifeless> repository is actiove
<lifeless> *active*
<lifeless> the knits version is just lagging as theres not much point to it just now
<Peng> (I'm upgrading everything to packs, and I'm rm -rfing old things too.)
<arj> hi
<arj> my machine crashed while commiting. I still have the changes but now bzr says that the repo is locked for at least 5 minutes
<arj> is there anything I can do to be able to commit again quicker?
<dato> arj: `bzr break-lock`
<arj> thanks
<gnomefreak> is there a way to fix Unable to obtain lock file:///home/gnomefreak/nobinonly/lightning-sunbird-0.7%2Bnobinonly/.bzr/repository/lock its held by me in my gutsy chroot but i dont have a process for it nor do i have gutsy chroot open
<Verterok> gnomefreak: try with `bzr break-lock`
<gnomefreak> Verterok: ok ty
#bzr 2007-11-18
<cr3> how can I recover an old file which has been bzr removed from the repository at some point?
<cr3> nevermind, found it with diff -r
<lnxtech> Has anyone gotten bzr-gtk to run on OS X Leopard?  I'm trying with both the built in python and also from macports but I haven't gotten it to work yet
<sabdfl> lifeless: hi
<lifeless> sabdfl: hola
<sabdfl> hey lifeless
<sabdfl> thanks for the answers
<lifeless> morning y'akk
<abentley> jelmer: ping
<juh> Hi, I cannot push anything to the repos on my server
<juh> using bzr locally works
<juh> is there a tutorial who to set up bzr on a server?
<lifeless> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<lifeless> you don't need bzr on the server if you are using sftp or ftp
<lifeless> if you are using bzr:// e.g. bzr+ssh:// then you need a bzr on the server, we try to be network compatible release to release.
<juh> lifeless: thanks I think that it works now somehow
<woei> I'm having some problems with the bzr-gtk (0.92.1) on a netbsd-4 (python2.4) machine. Python dumps core because it gets sent SIGSEGV: http://pastebin.com/d48960808
<woei> base bzr runs flawlessly however
<lifeless> woei: interesting; I would guess its a python-gtk bug
<woei> lifeless: ok, I'll try updating pygtk to 2.12 (it's at 2.10.6 now)
<pattern> i'm about to write a little script to get version information from bazaar in the form that perl modules expect (ie. versions of the form "X.Y.Z", where "X", "Y", and "Z" are all integers), and would like some input from anyone with more experience with bazaar on whether i'm going about this the right way...
<pattern> bazaar seems to number its revisions with a single number... which is fine... my idea is to just tag a revision i'm about to release with something like "myproject-X.Y.Z"
<pattern> unfortunately "bzr version-info" does not specify which tag a version has
<pattern> so i'm thinking of grabbing "revno" from "bzr version-info" and then searching for it in the output of "bzr log"
<pattern> if it finds a tag matching the regex: "\w-\d\.\d\.\d" (ie. "word-digit.digit.digit") it'll use the "digit.digit.digit" part for the version number
<pattern> otherwise it'll keep looking down the list of revisions until it finds such a tag and use that
<pattern> i know this is kind of ugly and hackish, but i don't know what else to do
<lifeless> bzr revision-info will give you the unique revision id of your tree
<pattern> isn't that the same as the "revno:" line in "bzr version-info" ?
<lifeless> no, its a guid
<lifeless> 'bzr tags' will list the tags you have
<pattern> yes, but that doesn't tell me which tag the currently checked out working tree has
<pattern> i suppose i could just use the top-listed tag
<pattern> and assume i'm working with the newest revision
<pattern> but that might not always be the case
<lifeless> uhm
<igc> morning
<lifeless> I thought tags listed the tag
<lifeless> revno/revisionid
<lifeless> hi igc
<igc> hi lifeless
<pattern> as i understand it, "bzr tags" lists all the tags for the branch
<pattern> but i'm interested in just the tag for the revision of the branch that i have checked out
<pattern> so i think i'm going to have to search through the output of "bzr log" for that
<lifeless> pattern: there may be no such tag
<pattern> yes
<pattern> in which case i guess i'll have to use the newest tag for any older revision
<pattern> as i need to set my $VERSION to something
<lifeless> and I'm saying that looking for bzr revision-info in the output of bzr tags is the fast way to do that if you don't want to use python
<lifeless> pattern: but if you just want to specify 'the current tree', the guid from bzr revision-info is all you need
<lifeless> perhaps I'm not understanding what you are trying to do
<pattern> well, "bzr revision-info" just gives me a single digit... i need to get a version in the form of "X.Y.Z" (where each of "X", "Y", and "Z" are digits)
<lifeless> pattern: I don't know why you need that, and revision-info doesn't give a digit, it gives a revno and revid; the revid is the unique part
<lifeless> e.g.
<lifeless> bzr revision-info
<pattern> so i think the way to get that is to manually set a tag for the version i want (ie. "myproject-1.0.2")
<lifeless> 2939 pqm@pqm.ubuntu.com-20071024231045-lquhgsz9513gn2l4
<pattern> the reason i need that is because perl modules are usually numbered in that way
<lifeless> the 'pqm@pqm.ubuntu.com-20071024231045-lquhgsz9513gn2l4' is the right thing to use to refer to this commit in a guaranteed manner
<lifeless> pattern: perhaps if you start from the top; I'm really confused
<pattern> ok...
<pattern> i'm writing a perl module... perl modules usually have a $VERSION (version string)
<pattern> $VERSION is used internally by the standard makefiles that compile and package up the module, and for module naming
<pattern> and they're usually in the form "X.Y.Z" (where each of "X", "Y", and "Z" are digits)
<pattern> usually that $VERSION lives in the code itself
<lifeless> ok
<pattern> but i don't want to mess with the code manually.. because i might make a mistake and get $VERSION out of sync with the actual revision in bazaar
<lifeless> so why not just append .0.0 to what bzr supplies ?
<pattern> well, releasing new major numbers (the first digit) is usually frowned upon unless you've made massive changes (ie. that require a reconfig, and/or API/format-changes, etc)
<lifeless> or do
<lifeless> 0.bzrrevno.0 ?
<lifeless> or 1.0.bzrrevno ?
<pattern> and then how do i increment the first and last digits?
<pattern> or whatever digits bzrrevno doesn't account for?
<pattern> it just makes much more sense to tag the release manually
<lifeless> well, increment them whenever you want to
<pattern> but have it in sync with the revision in bazaar
<pattern> so i can check out the branch based on that tag
<lifeless> but if you do want to use bzr tags, sure, using log and looking back for a tag will work, though you will get the same VERSION for different commits until you tag a new version
<pattern> yeah, that is a problem
<pattern> i'm going to have to give it more thought
<pattern> or maybe i could just tag every revision
<pattern> as X.Y.bzrrevno
<pattern> and when i do releases just use X.Y.0
<lifeless> which is the same as not tagging
<lifeless> and using x.y.bzrrevno all the time except for releases
<pattern> well, then if there's no tag on a version i'd need to search through earlier log entries for tags to know what X.Y is
<lifeless> ssure
<pattern> why not just tag every revision?
<pattern> i could probably write a script to do it, using the previous value of X.Y, and allowing an override
<lifeless> seems redundant and needs more work
<lifeless> I'd just tag once, and look that up
<pattern> it's too bad "bzr version-info" doesn't tell me the tag of the current revision
<pattern> then i wouldn't need to search "bzr log" for it
<lifeless> but as discussed there may be no tag
<lifeless> unless you've tagged every time
<pattern> right
<pattern> which is what i think i'm going to do
<lifeless> certainly, please do file a bug about it not providing the tag
<pattern> well, then maybe there should be a "bzr tag-info" :)
<i386> lifeless: http://confluence.ts.wikimedia.org/display/main/Home
<pattern> though, i think that while "bzr version-info" is providing all sorts of other info on that revision (such as the date and branch), it might as well provide the tag as well
<lifeless> pattern: sure; file a bug :)
<pattern> will do :)
<lifeless> i386: :)
<i386> lifeless: :)
<pattern> actually, "bzr log -r `bzr revno`" will accomplish pretty much the same as what having "bzr version-info" report the tag would do
<pattern> and "bzr log -r `bzr revno` | grep tag" to get the tag itself
<pattern> it's still a bit hackish... but seems to work
<lifeless> you can use 'bzr log -r -1'
<pattern> ah
<pattern> nice :)
<pattern> "bzr log -r -1 | grep tags | sed 's/^tags: //'"
<pattern> now to write a little script that does that before running a commit, and then automatically tagging the newly committed revision with X.Y.revno (where X.Y comes from the previous tag, and revno is the current revision)
<pattern> and when i want to increment X.Y i'd do so manually instead of running that script
<pattern> or maybe give the script an override option
<lifeless> its this complexity I don't like about tagging every commit
<lifeless> you wouldn't have to wrap commit if you only tagged releases
<pattern> well, it's either that or having to search through multiple log entries for the last tagged revision before the revision i'm working on now
<pattern> both ways entail additional complexity
<pattern> at least if i tag every revision, then i'd instantly know the X.Y version number of every revision by simply looking at the log for that revision
<lifeless> so one is prone to failing if you forget to use your wrapper
<lifeless> the other isn't prone to failing at all
<lifeless> shrug, its up to you :)
<pattern> there's no "bzr alias", eh?  :)
<lifeless> you can alias commit to give you options and so on, but not to run a shell script - your shell's alias can do that
<pattern> but shell aliases only alias the first word on the command line
<lifeless> a precommit hook could do what you need too, though noone has actually wired up the glue for precommit hooks just yet - we've been waiting for a use ase
<pattern> so i'd need to create a "bzrcommit" alias
<pattern> which, as you point out, i might forget to type
<pattern> but, if i do forget to type "bzrcommit" and type "bzr commit" instead, the next time i type "bzrcommit" or the next time i run make my "bzrcommit" script or the scripts in the makefile could warn me about not seeing a tag for the current revision
<pattern> and i could also have a script that goes back and adds any missing tags
<pattern> that would be trivial
<pattern> of course, doing that would involve searching through the output of "bzr log"
<pattern> so maybe instead of creating a wrapper for "bzr commit" i should create a wrapper for "bzr log" instead
<pattern> well, one other advantage of tagging every revision is that i could always check out a given revision via its tag, which would include the X.Y version number... and that would make more sense than just using the revno alone
<lifeless> I worry that you will run into scaling problems with tags
<lifeless> they're not geared for thousands of them
<pattern> hmm
<lifeless> and you're really just duplicating our existing infrastructure
<lifeless> which is why x.y.REVNO is IMO superior, for non-releases
<lifeless> you can 'bzr branch -r REVNO' as well
<pattern> or "bzr branch -r tag:X.Y.REVNO", right?  :)
<lifeless> yes, but thats redundant
<lifeless> so there is no gain; thats my point
<pattern> the gain is in a more intuitive user experience when looking for a given X.Y.REVNO version
<lifeless> still; if you feel you need to, it will work, it will just incrementally slow down your push/pull operations
<lifeless> couldn't you just add a VERSION_ID to the perl script
<lifeless> which is the GUID ?
<pattern> well, it needs to be in the X.Y.Z format, which is the standard
<lifeless> thats even easier in terms of getting the code for that version, and more robust against things like uncommit
<lifeless> no, you miss my poin
<lifeless> use VERSION for the build stuff
<lifeless> use VERSION_ID for the bzr GUID, as ancilliary data
<pattern> i don't understand
<lifeless> you seem to have several use cases
<pattern> could you explain what VERSION_ID and GUID are?
<lifeless> case 1) provide a machine generated version number for each build; which will be semi-human-readable
<lifeless> case 2) provide a way for users to obtain the source code
<lifeless> VERSION_ID would just be a perl variable
<pattern> and that would be different from VERSION ?
<lifeless> the GUID is what is returned by 'bzr revision-info', e.g. pqm@pqm.ubuntu.com-20071024231045-lquhgsz9513gn2l4
<pattern> how is using GUID better than the output of "bzr revno" ?
<lifeless> it does the correct thing when people uncommit
<pattern> and, more importantly, how do i get a proper X.Y.Z formatted version number for the perl VERSION variable?
<lifeless> it works in any branch of the project regardless of merge history
<pattern> ah
<lifeless> the guid is the underlying database id
<pattern> well, that makes things more complicated
<lifeless> for the Z component, I'd use the bzr revno, as you don't plan on uncommitting in your mainline, or even just lookup your last actual build you released, or use a timestamp (e.g. Z is seconds-since-epoch)
<pattern> maybe i could just append an md5sum of GUID :)
<lifeless> md5's have a-f in them
<pattern> yeah, i was joking
<lifeless> if thats permitted, just using the guid directly :).
<pattern> i think perl users would flip if they saw a 30 digit number in their version string
<pattern> and it's not permitted
<pattern> i don't think
#bzr 2008-11-10
<lifeless> back
<grettke> Hi guys. I see 1.9 was just released. There is a RC1 build for Windows, think that should I hold off until the 1.9FINAL is distributed, or is RC1 good enough for now?
<spiv> grettke: I don't think there are many changes in 1.9 vs. 1.9rc1, the rc1 build is probably ok.
<spiv> That said, I'd expect the final build to be done pretty soon.
<spiv> So if you're unsure, maybe just wait a day or tow.
<spiv> "two", rather.
<grettke> spiv: I see. Thanks.
<lifeless> there was a regression in rc1
<lifeless> fixed in 1.9
<lifeless> I suggest waiting
<fullermd> Gaah.  There's no way to shut off color in shelve anymore?   :(
<grettke> lifeless: Good to know. Will do.
<lifeless> fullermd: file bugs
 * fullermd is so doing.
<lifeless> fullermd: I assume you're looking at the new shelve
<fullermd> Yah.
<grettke> What Bzr-web integration tool do you guys prefer: loggerhead or bzrweb?
<lifeless> loggerhead
<jelmer> hmm, upgade is recursive now?
<lifeless> doggymenz: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
<lifeless> bah
<lifeless> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
<lifeless> I love the comment "Not necessary since entire project is replicated locally" under 'web interfaces' for some scm's
<lifeless> epic fail
<fullermd> Is that sorta like "branch support not necessary 'cuz we have a cheap copy"?   :p
<poolie> "merge support not necessary because branching is impossible"
<poolie> :-)
<lifeless> ah, svn?
<poolie> actually rcs
<lifeless> didn't rcs have branches?
<lifeless> I'm sure it did
<jonoxer> Is there any way to enforce an arbitrary policy on encountering a conflict, such as automatically picking whatever is the latest file regardless of what is in them?
<jonoxer> The problem is we have a bunch of binary files being generated in working copies, and they get committed (they need to be) but them always conflict
<jdong> ooh add me to the wishlist of an evil-downstream-plugin too!
<jonoxer> s/them/then
<jonoxer> What I'd like to do is have a rule like "when merging, if any file has an extension of .blah then use whichever is most recent"
<jonoxer> As an example, a typical use-case might be images in a source tree. They may be replaced from time to time, but bzr then sees them conflicting
<lifeless> jonoxer: yes; write a merge plugin. I *think* the infrastructure is sufficient unto the task
<lifeless> jonoxer: note that bzr should only see a conflict when there are concurrent changes in two branches to one file - and when that happens 'most recent' is not defined
<lifeless> jonoxer: unless you trust the clock on your developers machines
<jonoxer> lifeless: Ah, I see, so in a situation where the binary has changed in *both* branches then it will conflict. That makes sense
<lifeless> jonoxer: and if its only changed in one branch it won't conflict ever (unless there is a local uncommitted change, but thats really a psuedo-branch anyhow)
<lifeless> jonoxer: are you encountering conflicts - is this a concrete issue, or a hypothetical?
<jonoxer> lifeless: concrete, but it's partly because of the way we're using it that I'm sure you didn't think about when designing it...
<lifeless> jonoxer: guaranteed. I was just saying to poolie last night that users are insane :)
<jonoxer> In this scenario we have a bunch of developers working on Flex web apps, which have source trees of .mxml and .as files but each time the IDE builds the project it compiles .swf files in the tree. These are necessary for the app to run, but are somewhat transient: they can simply be regenerated if necessary, but the situation we're trying to avoid is having to regenerate every single one every time, hence them being committed
<lifeless> jonoxer: ah right, but the ide is insane and does it anyhow :P
<lifeless> jonoxer: and I bet it puts a datestamp in the file, so identical inputs -> different outputs
<jonoxer> lifeless: yep, I'm pretty sure that's part of the problem
<lifeless> jonoxer: right, with auto-creation and spurious changes you'll get spurious conflicts
<lifeless> jonoxer: now, the question is, can you programmatically tell these two cases apart:
<jonoxer> lifeless: I've tried suggesting to the devs that we should just exclude all the .swf files from being committed, but was met with a hail of nerf balls and staplers and lunchboxes
<lifeless>  a) I added a file and the .swf has to change
<lifeless>  b) a spurious change has occured
<jonoxer> lifeless: in this case it should be enough to simply tell which has the later creation date, and pick that one
<lifeless> or to rephrase - what is the impact on correctness in your app if your auto-resolved chooses the wrong .swf (or if in fact neither .swf is correct because both branches changed things that require it to be recreated)
<jonoxer> lifeless: not much at all. Worst case is to delete the swf and tell the IDE to regenerate it
<lifeless> jonoxer: back to the a/b question, concurrency is hard - let me expand the scenario:
<lifeless>  a) I add a file and the .swf has to change, monday 4pm
<lifeless>  b) you just regened and committed before you went home, monday 5pm
<jonoxer> lifeless: yes, I see: in that case the latest .swf won't actually be the one required. I don't think we can avoid that situation entirely
<jonoxer> lifeless: I don't think it matters a huge amount, though.
<jonoxer> lifeless: It just needs to have *a* copy of the binary, and if it's not quite the latest one that's generally OK
<jonoxer> The problem ATM is that the app ends up broken because neither version of the .swf ends up in place
<jonoxer> lifeless: hmm, maybe I could make it work in a brute-force way using a script that can be run after a merge, and it finds conflicting .swf files and makes an arbitrary decision and resolves the conflict automatically
<lifeless> jonoxer: thats likely the easiest way; as I say though there is a merge plugin capability
<jonoxer> Wouldn't always pick the best one (as you pointed out about concurrency) but it would make the app "work"
<lifeless> jonoxer: should be reasonably straight forward to do a merge that looks for these files (and if not, file a bug :))
<jonoxer> lifeless: thanks for the pointers. I'll have a look at the merge plugin interface and see if I can understand it
<rocky> i'm trying to understand... how is it possible that i create a local init folder with old 0.92 repo format and then i push it to a server that is using a shared repo of --1.9 that the new branch that i just pushed ends up with 1.9 repo format on the server?
<rocky> i'm having a hard time wrapping my head around that
<rocky> it seems sooooo different from the way the svn server stuff works which i think is part of the reason i'm having difficulty grasping it
<lifeless> rocky: 'server is using a shared repo of --1.9'
<lifeless> rocky: so the branch created in the repo uses the repo
<rocky> so this is really possible because the remote branch and the local branch are actually two separate branches with their own repos that just happen to keep getting synced up?
<grettke> Hi guys. What is the approach for backing up repos? I've got a shared repo that has all of my mainline branches in it. Is it simply a matter of doing a file system backup?
<lifeless> rocky: uhm
<rocky> lifeless: you can probably tell by my questioning that i'm simply "not getting it"
<lifeless> rocky: actually you got it fine I think
<lifeless> rocky: I'm on a phone call, and I typed what I was saying
<rocky> lol ok ;)
<grettke> that wasn't the correct terminology...
<thumper> lifeless: are you in brisbane?
<lifeless> thumper: no
<rocky> i think i'm going to write a very minimalistic bzr http server that has r/w access and just uses the standard wsgi/http transport thing from bzr plus some common authentication/authorization middleware
<lifeless> rocky: should just be a case of enabling apache auth
<lifeless> rocky: the web server is already wsgi; and supports r/w access
<rocky> right
<kumi> which one should be faster: bzr+http:// or http:// ?
<lifeless> kumi: http:// at the moment, but we're working on bzr+http
<kumi> Cool
<rocky> lifeless: well ... part of what is missing say compared to svn is authz support ... giving people access to just certain branches... that's currently not possible with just apache+bzr/http
<lifeless> rocky: true; otoh you can setup multiple repositories much more easily, which is likely why there is not that much pressure to address this
<kumi> I'd love bzr serve to have some basic auth capability like svnserve
<lifeless> there's some stuff been happening towards that, as wrapper scripts
<lifeless> thumper: I'm not in brisbane - too under the weather
<kumi> Really? Do you have a link?
<thumper> lifeless: get well dude
<lifeless> kumi: it was on the list in the last week
<rocky> lifeless: i'm not sure what point your last comment was making, how is setting up multiple repos make there be less pressure?
<kumi> thanks
<lifeless> rocky: setup a repo per group of access rights
<rocky> lifeless: oh... using different <Location> directives in apache conf with different auth settings you mean?
<lifeless> rocky: that, and additional physical repositories
<lifeless> rocky: its a distributed database, there is no need for all branches to be in the same repository
<rocky> well ... you see the problem is that now that i'm finally grokking some of the other stuff... knowing how to piece some of that stuff together is a little more natural ... but as i was trying to wrap my head around this essentially what i wanted was authorization control using "bzr serve" like kumi just asked for
<rocky> so the only way any of this stuff makes sense is if you have a good understanding of how bzr repos/branches work and you don't try to compare it to svn
<lifeless> sadly, that is true. svn really is a very different beast for a system administrator
<rocky> perhaps bzr needs a "recipe" site where there are little recipes for admins on how to setup apache + bzr + auth and stuff like that
<rocky> the fact is... most of the admins i know would rather send stuff like this through http instead of using ssh/sftp
<kumi> lifeless: I'm afraid I can't find the wrapper script discussion in the mailing list @ https://lists.ubuntu.com/archives/bazaar/2008q4/thread.html
<rocky> lifeless & kumi: this bzr http server i'm talking about is essentially what kumi is asking for i think
<kumi> I'm actually looking for a way to run bzr serve as standalone or inetd (like svnserve)
<kumi> ...with some kind of authentication
<rocky> right, that's what i'm talking about writing
<kumi> right now I have fwknopd protecting the port, but that's a hack
<lifeless> kumi: so why are you using bzr: and not either bzr+http or bzr+ssh ?
<rocky> is it possible to write a bzr plugin that exposes the plugin info using an egg entry point instead of having to put your plugin into one of the special bzrlib/plugins places?
<lifeless> rocky: there isn't any code in bzr to handle eggs
<lifeless> rocky: if eggs can honour the normal python behaviour of modules and packages it will just work
<lifeless> rocky: if they can't, it won't, unless someone contributes a discovery mechanism for eggs to bzr itself
<rocky> i think a discovery mechanism would be required, preferably one that utilized egg entry points ... but such a thing could be written as a bzr plugin in the classic style
<rocky> so a plugin that allowed egg plugins
<lifeless> kumi: revno: 3813 in trunk -   Add contrib/bzr_ssh_path_limiter. (Andrew Bennetts)
<lifeless> rocky: sure, just have a plugin which when loaded looks for eggs and loads them.
<lifeless> rocky: note that all bzr plugins need to be loaded into the namespace cleanly - bzrlib.plugins.NAME
<rocky> well, a plugin which looked for all eggs that provided a particular bzr entry point
<rocky> lifeless: that's a silly requirement btw ;)
<lifeless> rocky: rather than rehashing old ground, may I say that it works very well for us, allowing code reuse and simple configuration and deploymeny
<rocky> sure and that's fine, i'm not saying discontinue the old way... just that cleanly working with eggs would help new python developers "get into" the plugin system easier
<lifeless> we discover plugins using file system introspection and get the files to look for from python itself, so if eggs looked like packages and modules it would Just Work
<rocky> does bzr understand the notion of a namespace package?
<lifeless> bzrlib.plugins is one
<rocky> good
<lifeless> dunno if eggs will know it is, we write to python's core behaviour
<rocky> so bzr just iterates over the list bzrlib.plugins.__path__ for all paths ?
<lifeless> yes
<lifeless> I recommend reading bzrlib.plugin
 * rocky reads
<rocky> i think the main problem with an egg in this case is that it's packages won't get auto-imported which means they'll never get added to bzrlib.plugins.__path__ without some sort of kickstart
<rocky> but i also see that bzrlib.plugin is actually setting (wholesale) bzrlib.plugins.__path__ which would worry me
<rocky> and all of this would definately mean that zipped eggs wouldn't work
<lifeless> so we set __path__ to pickup plugins from various places
<lifeless> if there is a standard for getting a preset __path__ we can look at integrating that
<lifeless> but what (I think) I said the other day basically applies: the bzr developers don't use eggs, someone interested in egg support needs to step up and collaborate
<lifeless> we're not hostile to it
<rocky> right -- a very sensible attitude
<kumi> lifeless: thanks, that wrapper script isn't going to work for me though (it's for SSH)
<kumi> wow, actually I just discovered /contrib/bzr_access
<kumi> this looks exactly like what I'm looking for
<kumi> It uses the command= directive in .ssh/authorized_key to restrict access only to bzr, and bzr_access.conf to control user/group-level access
<lifeless> yes
<lifeless> ssh auth is much more secure than anything we'd be likely to write
<poolie> lifeless: so it looks like commit is actually failing in my current copy of your branch
<lifeless> much better to reuse that than invent a new auth protocol
<poolie> i'm hoping an update will fix it
<kumi> That's perfect for me, the reason why I couldn't use bzr+ssh:// was because of the hassle involved in creating a chroot jail and all that
<lifeless> kumi: oh no, you don't need a jail :)
<kumi> :)
 * kumi is happy
<lifeless> poolie: it's working for me
<poolie>   File "/home/mbp/bzr/repository-iter-changes/bzrlib/commit.py", line 701, in _report_and_accumulate_deletes
<poolie>     deleted_ids = set(self.basis_inv._byid.keys()) - \
<poolie> AttributeError: 'CHKInventory' object has no attribute '_byid'
<poolie> it seems a bit odd it would be calling that
<lifeless> poolie: are you using a MemoryTree?
<poolie> yes, i'm using BranchBuilder
<lifeless> poolie: basis_inv would have to be a CHKInventory for that to break; and AFAIK thats only the case with a MemoryTree
<lifeless> righto, yes thats broken
<lifeless> doing a full set difference is...bad anyhow
<poolie> yes, it's a bit odd in commit
<lifeless> its the fastest code we could do at the time; given its expecting a regular inventory
<poolie> you're saying because if it was a dirstate tree it would use the basis tree from the dirstate?
<lifeless> uhm spiv had a workaround I objected to; but perhaps a similar thing would get you past this
<lifeless> yes, dirstate trees have the basis tree from the dirstate
<poolie> i'm inclined to add an explicit method that returns all file ids
<poolie> at the moment that's meant to be done by iter(inv) but that is a poor idea
<lifeless> yah
<lifeless> otoh
<poolie> vila observes that we shouldn't add O(n) methods
<poolie> so perhaps should fix commit now
<lifeless> vila is right
<poolie> otoh at the moment we do have a method, it's just poorly named as __iter__
<lifeless> otoh, commit is not broken for production use, for this project
<lifeless> as this project is about historical trees
<poolie> 'this project' = split inventories?
<lifeless> yah
<lifeless> I would be inclined to tweak commit to use __iter__ *for now*
<lifeless> or even do an isinstance
<poolie> vila says 'robert just added _report_and_accumulate_deletes'?
<poolie> really?
<poolie> it looks kind of old
<lifeless> if instance(basis_inv, Inventory): byids else: set(iter(basis_inv))
<lifeless> set(by_id) is _really fast_ we don't want to lose that
<poolie> lifeless (probably gone): so it looks like we need CHKInventory.apply_delta
<thumper> poolie: hi, is spiv with you?
<poolie> hi, yes he is
<poolie> do you want him?+
<lifeless> poolie: why?
<lifeless> poolie: (but sure, that should be easy enough, just hoist it up to the base class, test etc)
<lifeless> or reimplement, making it into a dict delta
<lifeless> which would be best
<thumper> poolie: yeah, I'm talking with him about some weird hpss push problem with stacked branches
<poolie> lifeless: regarding apply_delta, i think we want to change code so that it's not counting on mutating existing inventories
<poolie> iow apply_delta should be deprecated in favour of create_by_apply_delta
<lifeless> poolie: ack
<lifeless> poolie: please, on the isinstance, trust me
<poolie> if it's important i'd like to at least add a comment saying so
<lifeless> poolie: set(dict.keys()) is slower than set(iter(dict))
<poolie> ok
<lifeless> erm
<lifeless> *faster*
<poolie> hm
<poolie> in that case i wonder if building two whole sets and subtracting them is actually faster
<poolie> but the whole thing should be able to be removed
<lifeless> I spent well over a month of my life profiling and tuning commit
<lifeless> I assure you that the current code in that part of commit, with dirstate trees, is vulnerable to slowdowns by 'obvious' changes and minor perturbations
<poolie> nice
<lifeless> sorry, I'm not meaning to get snippy
<poolie> np
<poolie> i take your point and thanks for the warning
<poolie>            # the older Inventory classes provide a _byid dict, and building a
<poolie>             # set from this directly is substantially faster than even getting
<poolie>             # a set of ids from the inventory
<lifeless> as a comment? sure
<lifeless> I'd say
<lifeless> "from the keys of this dict"
<lifeless> because thats the critical thing - set(dict) ~= set(iter(dict)) < set(dict.keys())
<poolie> s/</>/?
<poolie> yay perl :)
<lifeless> set(dict) is roughly the same speed as set(iter(dict)) and both are significantly slower than set(dict.keys())
<poolie> oh, measuring goodness not time
<poolie> iswym
<lifeless> we don't want someone going 'the call to keys() is unneeded, I'll just clean it up here'
<poolie> sure, that's why i want a comment
<lifeless> right, I'm agreeing
<poolie> no point discussing this and then doing it over and over
<poolie> me too :)
<lifeless> I'm saying your comment needs to say 'keys' in it :)
<poolie> i see
<poolie> that's kind of a bug in python if set(dict) is evaluated as set(iter(dict)) when the other would be faster
<poolie> well, 'bug' might be too strong
<lifeless> feature clearly
<lifeless> but this is what I mean by obvious cleanups
<lifeless> semantically set(dict) == set(dict.keys()), but performance wise they are rather different
<poolie> i'm going to do the isinstance on both of them
<lifeless> what will the fallback be then?
<poolie> do you want me to send a new patch just for this, or just keep it in my branch?
<poolie> http://pastebin.ubuntu.com/69911/
<lifeless> new patch would be good; we can review it and send it to trunk
<lifeless> yah, looks good to me, bb:approve
<poolie> oh i guess this can actually go in to trunk now
<poolie> ok
<lifeless> wait a sec
<lifeless> damn python, things keep changing ...
<lifeless> robertc@lifeless-64:~$ python -m timeit -s "f = dict((str(num), str(num + 1)) for num in xrange(50000))" "set(f)"
<lifeless> 100 loops, best of 3: 15.9 msec per loop
<lifeless> robertc@lifeless-64:~$ python -m timeit -s "f = dict((str(num), str(num + 1)) for num in xrange(50000))" "set(f.keys())"
<lifeless> 10 loops, best of 3: 23.3 msec per loop
<lifeless> robertc@lifeless-64:~$ python -m timeit -s "f = dict((str(num), str(num + 1)) for num in xrange(50000))" "set(iter(f))"
<lifeless> 100 loops, best of 3: 17.2 msec per loop
<lifeless> so set(f) is appearing to be the fastest thing now
<lifeless> sometimes I hate python
<lifeless> looks like any change here will need solid reprofiling
<lifeless> <garh>
<AfC> Robert: "sometimes I hate python". I'm going to write that down, I think
<poolie> i'm pretty sure the whole thing can be removed since we _should_ have this data from iter_changes
<lifeless> my advice would be the isinstance, with the comment tweaked to advise that we were cautious in the lack of time to profile
<lifeless> poolie: but we aren't using iter_changes yet
<lifeless> poolie: I mean, I agree in principle; but today it isn't the case that we can use iter_changes trivially
<poolie> sorry, i meant from _populate_from_inventory
<lifeless> igc did a patch which came close
<poolie> which seems to know about deletions too
<poolie> but i don't want to look closely into it now
<poolie> i might ask ian about that this week
<poolie> afc, familiarity breeds contempt (amongst other things) :)
<lifeless> we didn't have an answer for iter_changes during commit of a merge
<lifeless> and
<lifeless> having two code paths was very concerning to me at least, for this particular bit of code, commit is kinda critical
<lifeless> now, I think I have an answer for iter_changes and merges, but its very different to what igc had been putting together
<lifeless> I'll drop a mail to the list
<poolie> if you like, it's not immediately in our queue
<poolie> for now, vincent and i are going to make inventory stuff more CoW, maybe deprecating methods that aren't
<poolie> btw "i hate python" reminds me of http://lambda-the-ultimate.org/node/510
<poolie> actually not precisely that but i can't find the precise link
<poolie> >> I suspect that the best thing a GC can provide is a predictable performance model that programmers can understand and use.
<lifeless> poolie: where is apply_delta being used btw
 * poolie pops stacks
<poolie> in commit i think
<poolie> calling update_basis_by_delta; the default implementation of that calls it
<poolie> the non-dirstate case again
<lifeless> hmm
<lifeless> the basis can't be updated in a memorytree anyhow
<lifeless> poolie: I'd be inclined to override update_basis_by_delta on MemoryTree
<lifeless> poolie: avoids the issue entirely, and faster too
<thumper> yay for `bzr info -v` not taking ages and counting disk size
<kumi> bzr_access works, yay
<poolie> yay
<kumi> If I branch from serverA to serverB, both branches can either pull or push to each other, correct?
<poolie> correct
<kumi> awesome
<kumi> I just upgrade from 0.92 to 1.9-rich-root. This is blazing fast
<poolie> that's great!
<poolie> what are you storing?
<kumi> A small website
<kumi> I'm not sure if rich-root was the right choice, I didn't find any info about it
<kumi> just that it's advised for bzr-svn
<thumper> kumi: rich root will become the defacto standard sometime in the (hopefully) near future
<hno> thumper: What is rich-root about?
<thumper> hno: rich-root formats store extra information about the root directory, sorry I don't know much more than that
<thumper> bzr-svn needs to know more about the root
<thumper> it is also required for nested-tree support (I believe)
<thumper> I don't know what in particular it needs either
<hno> doesn't say much..
<thumper> no
<kumi> anything that gets us closer to nested trees is A-OK
<kumi> in my book
<hno> Found this in the bzr-1.0 news: New rich-root and rich-root-pack formats, recording the same data about tree roots that's recorded for all other directories. (Aaron Bentley, #164639)
<jszakmeister> jelmer: you around?
<_tsatbic_> I've got a question about the selftest. I installed bzr-1.9 from source. I installed on "CentOS release 5 on x86_64" and on "Debian release 4.0".
<_tsatbic_> I run selftest on both systems and do not know how to interpret the results.
<_tsatbic_> I've got 873 tests skipped, 2 and 4 failures, 1 error and 12 and 15 known_failure_count
<_tsatbic_> the word FAILED is written in capital letters
<gnomefreak> how would i remove a pending merge?
<beuno> gnomefreak, bzr revert --forget-merges
<gnomefreak> thanks
<rocky> jelmer: new bzr-svn issue for you... or perhaps you can show me what i'm doing wrong -- http://cluebin.appspot.com/pasted/2603
<jelmer> rocky, that's bug 293440
<ubottu> Launchpad bug 293440 in bzr "Cannot commit to bound svn branch: "invalid property value 'branch-nick' for None"" [High,Fix released] https://launchpad.net/bugs/293440
<rocky> oh good, it's no just me
 * rocky looks for a work around
<rocky> jelmer: so essentially this is a bzr 1.9 bug ? (do you know if it's been applied to the bzr 1.9 branch?)
<rocky> err... if the fix has
<jelmer> there's a proposed patch attached
<jelmer> no, it hasn't made it in yet
 * rocky unbinds and pushes
<jelmer> a workaround is to set a nickname locally I think
<rocky> oh i've never set a branch nick name before, didn't know there was such a thing
<rocky> jelmer: what i've been working on is  http://pypi.python.org/pypi/ClueBzrServer
<jelmer> rocky, ah, nice
<jelmer> rocky, any plans to integrate loggerhead?
<rocky> jelmer: not currently, but honestly i had no plans to do anything so who knows ;)
<rocky> if loggerhead is just another wsgi app it should be pretty straight forward
<jelmer> it is, afaik
<rocky> course the real reason i'm working on this is to hook it up to the full ClueMapper suite which is basically a way of managing multiple trac instances with multiple (currentlly svn only) repos
<rocky> but i figured it's useful outside the ClueMapper suite
<rocky> kumi: is http://pypi.python.org/pypi/ClueBzrServer something like what you were looking for last night?
<jelmer> rocky, can you perhaps announce cluebzrserver on the bazaar list?
<jelmer> rocky, I suspect there are more people interested in this sort of thing
<kumi> rocky: yeah, the convenience factor with your tool seems high
<kumi> although I went with contrib/bzr_access
<rocky> kumi: my tool supports ldap auth :)
<rocky> jelmer: yeah i should subscribe to bazaar list
<rocky> jelmer: which list?
<rocky> users/developers i guess
<jelmer> bazaar-list@lists.canonical.com
<jelmer> there's just one list, nothing specific for developers or users
<rocky> jelmer: you put a bad link in http://bazaar-vcs.org/BzrForeignBranches/Subversion for 0.4.15
<jelmer> rocky, thanks, fixed
<rocky> jelmer: do you know if loggerhead 1.6 works with bzr 1.9 ?
<jelmer> rocky, don't know
<jelmer> rocky, I think so
<rocky> it's a pretty straightforward app, wsgi and the like
<rocky> jelmer: btw, it's almost certainly not possible to have bzr-svn setup properly as an egg because the "location" of the plugin is very important for bzr and that can't be controlled via egg
<jelmer> rocky, ah, ok
<jelmer> rocky, in that case, it won't work for any of the bzr plugins
<rocky> jelmer: exactly
<rocky> i discussed that with lifeless a bit last night, basically the conclusion is that nobody that's really interested in eggs is working with bzr code
<rocky> but they would probably welcome a patch
<rocky> i might have a swing at it one of these days... set it up so plugins can be defined via egg entry points (that also means an egg can contain more than one bzr plugin)
<jelmer> yeah, I agree it would be good to have support for eggs
<jelmer> even though I use them myself
<jelmer> even though I *don't* use them myself
<rocky> jelmer: if i'm going to start pplaying with trac 0.11 and bzr 1.9 ... which trac-bzr branch should i look at?
 * rocky thinks experimental might be his best bet
<jfroy|work> yeah, I've had issues in the past where plugins would be installed as eggs and essentially not be loaded
<jfroy|work> Ideally Bazaar should publish some guidelines or boilerplate distutils code to help plugins authors distribute their plugins in a manner compatible with easy_install, such that users could install plugins through their OS's package manager, through running setup.py (from a source distribution or a bazaar branch or checkout) and through easy_install.
 * jfroy|work is reminded of the sad, sad state of Python package installation
<rocky> jfroy|work: atm it's simply not possible to do what you suggest with eggs/plugins without modifying bzr somehow to look up egg entry points
<rocky> basically the way bzr plugins works now works *against* how eggs work
<jfroy|work> Yeah, I know.
<rocky> in fact, anything that relies on __path__ works *against* eggs
<jfroy|work> I don't think we should support eggs necessarily
<jfroy|work> Just make sure easy_install / setuptools never install Bazaar plugins as eggs
<rocky> i don't think that's possible either ;)
<rocky> easy_install will try to install any distutils-activated tarball/directory
<rocky> it should be pretty straightforward to write a standard bzr plugin that enables plugins via eggs
<jfroy|work> lol
<rocky> so a meta plugin of sorts
<jfroy|work> that's so ... meta, yeah
<jfroy|work> :)
<rocky> but either which way, i can understand if nobody is interested enough in eggs to implement any of this, but nobody should be opposed to it either ;)
<jelmer> rocky, the trunk
 * rocky switches to trunk
<jelmer> rocky, experimental is the branch used for Debian experimental
<jelmer> it's basically trunk with a debian/ directory
<rocky> jelmer: so lp:trac-bzr then?
<jelmer> rocky, yep
<rocky> jelmer: where does bzr+debug logging typically go? i don't *think* i'm seeing it in console when i turn on trac debugging
<jelmer> ~/.bzr.log
<rocky> really? i'm not seeing *anything* there
<LarstiQ> right user?
<rocky> yeah, this is a test environment i'm running right now all running under my personal user account
<rocky> ah i kind of see what's going on here ... if i try browsing to a branch that is empty, i get an error ... (<p class="message">No node MyProject/trunk at revision current:</p><p>You can <a href="/pm/p/testbzr/log/MyProject/trunk?rev=current%3A&amp;mode=path_history">search</a> in the repository history to see if that path existed but was later removed</p>)
<rocky> whoops, didn't realize that was going to be so much
<rocky> but if i add a file to that branch, it views fine
<LarstiQ> does it need to have files, or revisions? Ie, ci --unchanged on an empty branch.
<rocky> it shouldn't have to, but i mean trac shouldn't be reporting an error when it doesn't
<rocky> jelmer: i'm still running into bizarre commit issues .... i just did the following:
<rocky> 1) bzr co https://somesvnproject/trunk svnproject-trunk
<rocky> 2) bzr branch svnproject-trunk svnproject-mybranch
<rocky> 3) changed some files in mybranch
<rocky> 4) committed files in my branch
<rocky> 5) bzr push https://somesvnproject/branches/mybranch
<rocky> and after doing all this, the changes i made actually get committed back to trunk and my remote branch dir is empty
<rocky> am i doing something stupid again?
<jelmer> rocky: can you show me the svn log output from that particular revision?
<rocky> well, doing a push did two svn commits
<rocky> one commit created the empty branch folder, the second commit updated the files in (incorrectly) trunk
<rocky> lemme dig up the revs
<rocky> jelmer: what "svn log" output are you looking for?
<LarstiQ> that sounds familiar
<jelmer> rocky: so mybranch didn't exist before?
<rocky> jelmer: no it did not
<jelmer> rocky, the last few revisions
<jelmer> rocky, use "bzr svn-push" for new branches - bug 127945
<ubottu> Launchpad bug 127945 in bzr "Integrate creating new branch functionality into standard push/branch" [High,In progress] https://launchpad.net/bugs/127945
<LarstiQ> jelmer: if it helps, I had svn mkdired a branch dir, bzr pushed to it, and got what was in trunk (instead of my diverged branch) in there
<rocky> jelmer: you can see what i did with http://projects.serverzen.com/pm/p/cluemapper/timeline where the last two revs is where i backed things out
<jelmer> rocky, LarstiQ: please file a bug
<rocky> jelmer: looks like using svn-push did the right thing ... so i guess it was just that i wasn't using the push properly
<rocky> due to that bug you mentioned
<LarstiQ> jelmer: noting it down to do first thing tomorrow when I'm back at that repository
<rocky> jelmer: the bzr ancestry property here http://projects.serverzen.com/pm/p/cluemapper/browser/ClueMapper/branches/rocky-bzr is crazy ;)
<jelmer> wow, yeah :-)
<jelmer> LarstiQ, thx :-)
<jfroy|work> OK, time to try bzr-svn again
<jfroy|work> With the awesomely tortured svn repository
<jfroy|work> jelmer: http://pastie.org/311636
<jelmer> jfroy|work, please use 0.4, not trunk
<jfroy|work> I'm pretty sure I need 0.5's more flexible repository layout support
<jfroy|work> Is 0.4 TOT viable?
<jelmer> jfroy|work, TOT?
<jfroy|work> top of tree
<jfroy|work> sorry :/
<jelmer> yeah, 0.4 should work fine
<jelmer> I've pushed a fix for trunk as well for the issue you mentioned
<jelmer> but running trunk on production stuff is asking for trouble..
<jfroy|work> before I kick off the next command, what debug flags would be useful to you?
<jelmer> it depends on the error
<jfroy|work> Alright, here goes
<jfroy|work> Running on revision 1755
<jfroy|work> blank config (no subversion.conf, no cache)
<jfroy|work> whoa
<jfroy|work> it worked
 * jfroy|work is very impressed.
<jelmer> cool :-)
<jfroy|work> tip of the hat
<jfroy|work> I tried two different branches in that common repository of hell, both checked out fine
<jfroy|work> (two different projects)
<jfroy|work> w/o to commits and merging, what is the proper sequence of way such that each commit made in bazaar will be a separate commit in Subversion?
<jfroy|work> IIRC given trunk, a checkout of a svn branch, and trunk-dev, a Bazaar branch of trunk, you should not from trunk merge trunk-dev, as that will yield one svn commit for the merge (with all the changes merged from the branch).
<jfroy|work> I think pushing from trunk-dev into trunk does the trick, merging trunk into trunk-dev before pushing.
<jfroy|work> Or is that bad?
<jelmer> jfroy|work, yeah, basically - only things that are in the mainline of hte bzr branch end up in svn
<jelmer> jfroy|work, merging trunk into trunk-dev won't work, since that changes the mainline in svn
<jfroy|work> Right, and a merge is a single item with a hierarchy of changesets below it coming from the other branch
<jelmer> jfroy|work, you may want to look at the bzr-svn FAQ
<jelmer> 'morning thumper
<jfroy|work> jelmer: not sure I understand that FAQ item :p I'm not well versed enough in DCVS theory to really understand what it is saying
<jfroy|work> My short question is: what's the best practice to stay out of trouble, in general
<jelmer> use bzr rebase
<jelmer> is the simplest answer there
<jfroy|work> I've never used that :p
<jelmer> it replays the revisions unique to trunk-dev on top of trunk, basically
<jelmer> so you keep a linear history (no right hand side stuff)
<jfroy|work> So I see
<jfroy|work> So would, inside trunk, rebase ../trunk-dev amount to pushing from trunk-dev to trunk, provided they have no diverged?
<jfroy|work> *not
<jfroy|work> **not diverged
<jelmer> yes, with newer versions of bzr-rebase
<jelmer> older versions will just yell at you and tell you to use "bzr pull" instead :-)
<jfroy|work> lol
<jfroy|work> I see
<jfroy|work> right, a pull would do that
<jfroy|work> The issue is when the branches have diverged, I suppose.
<jfroy|work> Ideally, I want a workflow where I have a checkout of trunk from subversion, with a set of work branches.
<LarstiQ> isn't renase ../trunk-dev the wrong way around?
<jfroy|work> I want to be able to pull changes from trunk into those work branches periodically to keep up with trunk, and push changes from those work branches into the svn trunk branch when appropriate.
<jelmer> LarstiQ, yes, you usually spell it with a "b" :-P
<jfroy|work> LarstiQ: yes I just noticed that
<thumper> hi jelmer
<jfroy|work> you rebase inside trunk-dev, onto trunk (or by default the parent branch)
<jelmer> jfroy|work, rebase will allow you to do that
<LarstiQ> jelmer: :P
<jfroy|work> So the workflow is basically, from the work branches, bzr merge ../trunk
<LarstiQ> jelmer: I meant rebasing svn trunk on top of bzr diverged seems off..
<jfroy|work> To pull changes that have been committed to Subversion's trunk
<jfroy|work> And bzr rebase from those work branches to send those changes to trunk
<jelmer> jfroy|work, no, the other way around
<jelmer> jfroy|work, bzr rebase to pull in changes from svn trunk and bzr push to make changes go into svn trunk
 * jfroy|work is hopelessly confused now.
<jfroy|work> Ahh, gotcha.
<jelmer> sorry
<LarstiQ> now I am confused.
<jfroy|work> No it's entirely my fault :p
 * jfroy|work casts confuse on #bzr
<LarstiQ> jfroy|work: well, jelmer's explanation confuses me.
<jelmer> LarstiQ, which bit, specifically?
<LarstiQ> jelmer: bzr rebase pulling in changes from svn
<jelmer> LarstiQ, if you have a feature branch, you can "bzr rebase" on top of the svn trunk
<jfroy|work> right, it basically will find the changesets in the current branch that are not in svn trunk
<LarstiQ> jelmer: right, but I understand that as running from the feature branch with trunk as argument.
<jfroy|work> Then alter the history of the current branch to the top of svn trunk, and replay the identified changesets.
<jelmer> LarstiQ, yes, that's correct
<jfroy|work> yup
<LarstiQ> jelmer: ok, unconfused then.
<jelmer> jfroy|work, correct
<jfroy|work> Which means that after that, the branches will not have diverged.
<jelmer> jfroy|work, correct
<jfroy|work> And you can either either push to svn trunk or pull from svn trunk
<jfroy|work> *And you can then either
<jfroy|work> Which will happily send changes to subversion
<LarstiQ> it will mean anything depending on your old revisions will miss them
<jfroy|work> *send the changes
<jfroy|work> LarstiQ: hum?
<LarstiQ> jfroy|work: if you branch the feature-branch to 'dependant', rebase the feature-branch on top of trunk, doing a pull in 'dependant' will mention divergence
<jfroy|work> right
<jfroy|work> you'll have to chain rebase down the branch children
<jfroy|work> rebase feature on trunk, rebase dependent on feature, etc
<LarstiQ> yeah, or pull --overwrite
 * LarstiQ nods
<LarstiQ> if you actually have changes
<jfroy|work> Isn't --overwrite evil?
<jfroy|work> :p
<LarstiQ> jfroy|work: I consider it less evil than rebase :)
<jfroy|work> jelmer: but your advise is that rebase is the best way to go, with respect to bzr-svn, correct?
<jelmer> IFF you need to keep the mainline history intact, yes
<jfroy|work> *advice
<jfroy|work> Merging feature into trunk will work as well, correct?
<jfroy|work> Or will there be issues with that, beyond the single commit to Subversion for the entire set of changes merged in.
<jelmer> no, that should work ok
<jfroy|work> Your FAQ mentions you can merge into a checkout of trunk, or rebase on trunk
<jfroy|work> OK
<jelmer> be sure to use bzr-svn 0.4.15, btw
<jelmer> (or the 0.4 branch)
<jfroy|work> I am using 0.4.16dev0
<jfroy|work> Oh, BTW
<jelmer> that's recent enough :-)
<jfroy|work> I noticed that 0.4.15 reports as 0.4.15dev0
<jfroy|work> When I installed the bzr 1.9 Mac OS X 10.5 package this morning
<jelmer> yeah, I forgot to set "final"
<jfroy|work> I built the bzr-svn package for that
<jfroy|work> OK
<jfroy|work> Wasnm
<jelmer> but it didn't seem worth it to release a 0.4.15a or 0.4.16 just for that
<jfroy|work> For a moment I was worried I somehow built from an outdated source distribution...
<jfroy|work> Anything important in 0.4.16 over .15?
<jfroy|work> In other words, should I tell people to install 0.4.16 on top of .15 right now?
<LarstiQ> it seems to me .16 is not released yet?
<jelmer> yeah, 0.4.16 isn't out yet :-)
<jfroy|work> jelmer: http://pastie.org/311689 :|
<jelmer> jfroy|work, that's a known bzr bug - bug 293440
<ubottu> Launchpad bug 293440 in bzr "Cannot commit to bound svn branch: "invalid property value 'branch-nick' for None"" [High,Fix committed] https://launchpad.net/bugs/293440
<jfroy|work> I see
<jfroy|work> So basically, no bound branches for now
<jfroy|work> jelmer: everything seems to be working fine
<jelmer> cool
<dwt> Hey guys, I'm getting a ERROR: bzrlib.errors.KnitCorrupt when updating from a svn host
<dwt> all the while bzr check is sure that nothing is wrong with the repository
<dwt> could someone advise on how to track this down further?
<jelmer> dwt: Hi
<jelmer> dwt, what version of bzr-svn ?
<dwt> jelmer: Evening!
<dwt> 1.9 I installed
<jelmer> but what version of bzr-svn?
<dwt> just a second
<jelmer> 0.4.15 contains a fix for this
<dwt> bzr-svn 0.4.15
<dwt> thats what my NEWS file says at least
<dwt> is there a better way to get the version of bzr-svn?
<jelmer> dwt, please try removing ~/.bazaar/svn-cache and doing a clean checkout
<dwt> :-/
<dwt> Thats going to take about 6 hours
<LarstiQ> ouch
<dwt> Is there a shortcut?
<james_w> abentley: hi, would you have a few minutes to help debug this issue with autopacking stacked branches?
<abentley> james_w: No, because I'm debugging an issue with autopacking stacked branches.
<dwt> I mean, I don't really need the history
<dwt> I'd love to just get the last 100 revisions or something like that
<james_w> abentley: heh, fair enough :-)
<dwt> if possible
<jelmer> bzr-svn 0.4 has some experimental support for stacked branches, but will still have to figure out the file ids and thus analyse all revisions
<dwt> by the way: whats the easiest way to find out at what revision my checkout exactly is?
<jelmer> dwt, bzr revno or "bzr version-info"
<dwt> jelmer: thanks!
<jelmer> dwt, is this a public repository?
<dwt> yes
<dwt> svn://svn.adiumx.com/adium/trunk
<dwt> jelmer: I just updated to the latest version of the stable-branch and am trying it again from there (from the news file this seems to be "bzr-svn 0.4.16  UNRELEASED"
<dwt> )
 * LarstiQ nods
 * dwt :)
<dwt> Uh wow!
<dwt> it got throuth it!
<dwt> YES!
<dwt> :)
<dwt> (Sorry for the cry of joy. :)
<jelmer> dwt, :-)
<dwt> (Just for the record: my git-svn import of that same repository still dies on a bug in the git 1.6.0.2 that ought to be fixed only in 1.6.0.3 ;)
<dwt> but which I still can't verify
<dwt> Ah well. Have a nice day! (On with my work on adium)
<jelmer> There's no open bugs wrt importing svn repositories in bzr-svn atm
<jelmer> Not sure whether that's just because there are none or because people don't report them..
<jelmer> dwt: :-)
<fullermd> As long as nobody reports bugs, there aren't any.
<dwt> :)
<fullermd> Ergo, all bugs are user-inflicted.
<dwt> Well, it works for me now - though I'm using the unreleased version
<jelmer> 0.4.16 doesn't contain any changes that could influence this that aren't in 0.4.15
<dwt> great
<dwt> so it seems I've not been on the correct checkout of 4.15 -
<dwt> Must be that I've updated too early from the stable repo
<dwt> (about satturday)
<jelmer> ah, yeah, it was fixed later than that I think
<dwt> damn. :)
<lifeless> moin
<lifeless> james_w: perhaps I can help, once I have caffeinated
<james_w> lifeless: I'm sure you could
<lifeless> james_w: so, while I hunt down caffeine, can you describe whats up
<james_w> just pulling up the bug number
<james_w> bug 288751
<ubottu> Launchpad bug 288751 in bzr "bzr push returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<lifeless> ok, so thats autopackin related? cool - I know abentley is fixing that; I thought you might have another case
<james_w> I'm with gmb and he just hit it, so I wanted to grab some information while there were live branches
<james_w> yeah, it sounds like Aaron is on it
<lifeless> try bzr pack <target branch>
<abentley> lifeless: It depends which autopacking bug you mean.
<abentley> lifeless: We've got plenty of them.
<lifeless> oh :(
<lifeless> I thought there was just one left
<abentley> lifeless: No, there are at least three.
<lifeless> grah
<lifeless> so, stab in the dark, ifyou disable spiv's smart verb, do they go away?
<abentley> lifeless: No.  Codehosting is on 1.7, so it doesn't support the smart verb.
<lifeless> ah, true enough
<lifeless> must caffeinate, brb
<james_w> ta-da!
<gmb> lifeless: Morning. I has pastebins for you
<gmb> lifeless: https://pastebin.canonical.com/11006/ (Traceback)
<gmb> lifeless: https://pastebin.canonical.com/11007/ (bzr.log)
<james_w> from what I have been able to discern, when it does the autopack it can no longer find some text compression parents in the combined indices.
<james_w> in this case there were two missing parents, from two different file ids
<james_w> both file ids were modified in the revisions being pushed
<james_w> the missing parents were from a while ago, September and June.
<james_w> the missing parents were the last revisions to modify the files in question though
<james_w> though both were revisions merged by PQM
<lifeless> abentley: is the one james_w is talking about the one you are investigating ?
<lifeless> james_w: so the question is 'why' - we're not meant to ever delta compress across repository boundaries; its not safe.
<lifeless> so either there is another bug elsewhere allowing that to happen (plausible), or we are dropping some index that matters at autopack (less plausible)
<abentley> lifeless: it sounds like #288751, which I will do, but not what I'm working on.
<lifeless> james_w: if you're interested in helping, writing a little script to open a repo, and scan all its indices for missing compression parents would be good
<lifeless> abentley: ok, I'll chase it a little to clarify it, but will get back to the inventory stuff once its clear
<abentley> lifeless: I don't recall any requirement that delta compression avoid revision boundaries.
<abentley> s/revision/repository
<james_w> lifeless: but would that help? It seems like it is at the autopack stage, so analysing the repository before may not tell us anything.
<lifeless> the discussion may have happened on irc
<lifeless> james_w: it will tell us if that theory is false
<james_w> lifeless: true
<lifeless> and if it fails to disprove the theory, we can continue looking for falsification - or even confirmation :>
<lifeless> abentley: the discussion may have happened on IRC. I'll look for a list message; I'm fairly sure there are docstrings mentioning it.
<lifeless> abentley: the reasoning I recall was : to allow smart servers to always be able to operate on their repository contents, without requiring third-party connections (like e.g. site-to-site ftp)
<abentley> lifeless: Well, it wouldn't surprise me at all if your first commit to a stacked branch was all deltas.
<thumper> spiv: ping
<lifeless> abentley: bzr should not delta (unless the basis revision was pulled across)
<abentley> lifeless: I am certain that the smart server attempts to access remote repositories, because it gets a publickey error
<lifeless> abentley: ugh; thats definitely not what was intended
<lifeless> abentley: 'doc/developers/overview.txt' has prose about this
<lifeless> under the 'Stacked Repositories' section
<lifeless> and, <3 bzr-search
<lifeless> which found this immediately after I failed with google :)
<abentley> So, perhaps commit honours this contract and push doesn't.  But something is rotten.
<poolie> hello lifeless, abentley, james_w
<abentley> poolie: hi
<james_w> hi poolie
<thumper> hi poolie
<thumper> poolie: abentley and I are trying to track down the source of the hpss push problem we are seeing
<abentley> thumper: I seem to be reproducing it at last.
<thumper> abentley: \o/
<abentley> thumper: What was the bug number again?
<lifeless> abentley: ack
<lifeless> abentley: do you have a stack trace of the server side op that is trying to make a connection? (I'm curious about why anything would be trying that)
<abentley> lifeless: Not at present, but it's not hard.  Just mirror a stacked branch off launchpad, change its stacked_on URL to a remote one, and push into it.
<lifeless> abentley: ah, so you're using your local bzr version at that point - I bet that that is the autopack kicking in
<lifeless> spiv should be around in about 20 minutes
<beuno> if this is bug 288751 we're talking about, I suspect it's autopacking as well
<ubottu> Launchpad bug 288751 in bzr "bzr push returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<lifeless> beuno: we're talking about a cluster
<thumper> abentley: I don't know if I had a bug number for this one
<thumper> abentley: oh, hang on
<abentley> thumper: That one ended with Revision X not present in KVF.  I'm running check on my mirror of trunk.
<thumper> abentley: I think it is this one: https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/293679
<ubottu> Launchpad bug 293679 in bzr "1.9rc1 can't push to Launchpad" [Undecided,Invalid]
<thumper> abentley: bug 293679 is the one that takes ages
<ubottu> Launchpad bug 293679 in bzr "1.9rc1 can't push to Launchpad" [Undecided,Invalid] https://launchpad.net/bugs/293679
<abentley> lifeless: There is also bug 295350.
<ubottu> Bug 295350 on http://launchpad.net/bugs/295350 is private
<abentley> lifeless: That one is a regression from 1.8, and affects HPSS only.
<lifeless> ok
<james_w> gmb: please run http://people.ubuntu.com/~jamesw/check-packs.py at your leisure
<james_w> gmb: "python check-packs.py lp:~gmb/project/whatever-you-called-that-branch"
 * spiv waves
<lifeless> spiv: is the autopack verb aware of stacking?
<lifeless> spiv: (does it ensure it doesn't get a parameterised repository)
<spiv> thumper: pong
<spiv> lifeless: Hmm.
<lifeless> spiv: if its a method on repository, it should be fine, but it if opens (on the server) the repo via branch... then it won't be ;)
<spiv> lifeless: the server-side simply calls repo._pack_collection.autopack()
<spiv> Ok, it should be fine then.  It doesn't open it via the branch.
<lifeless> ok
<spiv> Also, I'm not sure if the client would even invoke it for a stacked repo, the behavior of InterPackRepo.fetch probably avoids it.
<lifeless> spiv: then it will autopack over the wire
<spiv> Right.
<thumper> spiv: can you skype quickly?
<spiv> thumper: ok, just a moment.
<spiv> thumper: I'll just go grab my headset
<w00t_> hi, i've got a very tricky vcs problem, and i'm wondering whether perhaps bzr can do some insane tricks to help me solve it, but i'm not sure :) does anyone have experience with messing around with imports/conversions and so on? involves subversion, and to a large extent git as well.. :P
<w00t_> essentially, i imported a damaged svn repository which i didn't have commit into git, and did lots of my own hackery, now they want to replaced their damaged svn repo with a fresh one cloned from mine.. with git, though, this will involve nuking all the historical timestamps and authors on the commits (new repo, clone with git-svn, use remotes to rebase the entire old repo onto the new svn repo & dcommit), which is horrible, and i'd like to avoid 
<w00t_> (yes, I'm well aware this is insane
<w00t_> )
<lifeless> whats damaged in the repo?
<w00t_> about 200 revisions are untouchable, literally
<fullermd> Well, it's in svn  ;)
<w00t_> i had to import around them using git-svn
<w00t_> fullermd: definitely so. unfortunately, not everyone has seen the light yet, so I have to try work with them in a way that won't drive either of us insane :-)
<lifeless> so, you could fastexport to bzr, then bzr push into a new svn repo; this will preserve timestamps and authors AFAIK
<w00t_> do you have some docs I can read? :)
<lifeless> you can obviously test with a svn repo on your own machine
<lifeless> install bzr-svn
<lifeless> and there is the bzr svn faq and docs on the wiki
<w00t_> (this will also probably involve me learning/using bzr instead of git, which I've wanted to do for ages)
<w00t_> is 'fastexport' a bzr plugin also?
<lifeless> yah
<lifeless> well
<lifeless> there is git-fastexport
<lifeless> and bzr fastimport
<w00t_> ah
<w00t_> of course.. i'm having a blonde day! :)
<lamalex> does anyone here use the emacs vc-bzr mode?
<lifeless> lamalex: I think vila does
<lamalex> vila: ping?
<w00t_> lifeless: bzr fast-import and bzr fastimport both don't seem to exist.. is it likely to be in some external package? (I'm using ubuntu with bzr+bzr-svn packages installed, can't see any that look relevant)
<jelmer> w00t_, fastimport/fastexport != bzr-svn
 * w00t_ scratches his head
<lifeless> w00t_: you need bzr-svn to push to svn, and fastimport is separate
<lifeless> http://bazaar-vcs.org/BzrFastImport
<w00t_> ah! lovely
<w00t_> let me give that a whirl
<vila> lamalex, sry, not vc-bzr yet :-/
<vila> lamalex, but ask your question anyway :)
<lamalex> i was wondering if anyone knew the minor-mode to commit
<lamalex> i can't find it lol
<bob2> what do you mean?
<lamalex> so i do
<bob2> C-x v v invokes the commit editor
<lamalex> M-x vc-<TAB> and nothing looks like commit
<lamalex> lemme try that
<lamalex> is there a guide anywhere?
<bob2> C-h i -> emacs -> version control
<lamalex> oh right, emacs has help
<lamalex> I'm new to emacs also
<lamalex> a recent vim convert
<lamalex> I LOVE it, but it's got a curve for sure
<bob2> the point of vc is that it works similarily (*) for all vc systems
<bob2> * which is not terrible useful for things other than cvs
<w00t_> lifeless: the import is running now, thanks! let's see how this goes.. so, next I guess I'll need to figure out how to use bzr-svn to push to an empty SVN repo? (or can it create one I wonder)
<lifeless> w00t_: jelmer can advise better than I; but I imagine it is just (after creating the svn repo) bzr svn-push svn://path/to/repo/trunk
<lifeless> w00t_: (svn-push is needed for the first push of a branch to svn)
<lamalex> bob2: so it's not useful for bzr?
<lamalex> i saw there was a dvc mode when i googled bzr emacs
<bob2> depends what you want to do and which version of emacs
<lamalex> emacs 22.2, and basically i want to commit, and see diffs from a bzr tree
<lamalex> merge
<lamalex> basic vcs stuff I suppose
<lamalex> but ive never used any ide+vcs before
<lamalex> i usually just have two shells open
<lamalex> so im intrigued by this
<bob2> iirc trying to commit multiple files in emacs 22 will do multiple commits, which is a bit useless
<bob2> merging, no idea, diffs should be fine
<lamalex> meh ill just stick with the cli :(
<bob2> should be greatly improved in a recent cvs snapshot
<lamalex> too bad, coulda been pretty cool
<w00t_> lifeless: hmm. I shall try that then
<lamalex> bob2: in an emacs snapshot, or a vc-bzr snapshot
<bob2> lamalex: both
<vila> lamalex, vc-bzr is file-oriented, dvc is tree oriented, you should try dvc
<w00t_> lifeless: ERROR: Not a branch <--- I assume that means I need to 'bzr update' like the fast-import process mentioned
<lifeless> w00t_: run 'bzr branches'
<w00t_> I see all my branches listed there :)
<lifeless> w00t_: the not a branch error most likely just means you are in a dir that isn't itself a branch
<w00t_> the dir it mentions as not being a branch is a subdir of my .bzr: /project/.bzr/branch/ actually
<lifeless> w00t_: was 'project' listed in the output of bzr branches?
<w00t_> no, project isn't a branch name, it's the name of the project
<lifeless> right
<lifeless> so project isn't a branch :)
<w00t_> hmm, all bzr commands (log etc) seem to give the same error
<lifeless> cd to one of your branches
<w00t_> uh
<w00t_> ...oh.
 * w00t_ rm -r and reimports to remove a lot of mess from assuming that .bzr worked the same way as .git :P
<lifeless> w00t_: where git has 'refs' we have 'branches', each of which is a dir with its own tags and head; the historical data (gits 'objects') lives in .bzr/repository
 * w00t_ nods
<w00t_> I got too used to one working directory
<lifeless> you probably have something like projects/.bzr/repository, and then projects/branchX/.bzr/branch
<lifeless> working directories are maintained with metadata in .bzr/checkout
<lamalex> vila: with dvc i still couldn't find how to commit, but I forgot about C-h
<lamalex> so I'll try that
<lifeless> you can mix and match these as needed
<w00t_> lifeless: hmm, that is a little confusing :)
<w00t_> I'm sure I'll get used to it
<lifeless> w00t_: e.g. - git-like - bzr init-repo --no-trees .; bzr init trunk; bzr checkout --lightweight trunk working
<lifeless> will give you a branch 'trunk' and a single working dir 'working'
<lifeless> then bzr branch trunk feature will make a new branch feature
<lifeless> and (in working) 'bzr switch feature', 'bzr switch trunk' etc etc
<bob2> lamalex: C-h m gives you help for all active minor or major modes
<w00t_> lifeless: hmm, what does the --lightweight on checkout do?
<lifeless> but because these things are separate, you can decouple them further - you can have the repository on a central server, for svn-alke behaviour, or, well - there are lots of useful ways to use it
<lifeless> w00t_: it just tells bzr that 'working' should not be a branch itself
<w00t_> branches and branches and branches, oh my :)
<lifeless> w00t_: 'bzr checkout foo bar' will create a branch of foo in bar, and 'bind' it to foo, so that commits to bar are immediately pushed to foo
<vila> lamalex, once you have a dvc-diff or dvc-status buffer commit is 'c'
<lifeless> w00t_: --lightweight is useful when both foo and bar are local, because you don't need a spare copy of the history
<lifeless> w00t_: if foo was on a remote server, you'd want a mirror of the history for performance
<w00t_> that is really quite nifty for tossaway branches that you want to share commits with another branch
<w00t_> does unbind (and a bunch of commits) and a later re-bind push those commits to the origin?
<lifeless> bind won't immediately push
<w00t_> hm
<lifeless> it might not be able to if someone else has pushed to the origin
#bzr 2008-11-11
<lifeless> so its simpler to explain to say that bind just sets the flag
<lifeless> if someone else has pushed, after binding, do 'bzr update; bzr commit'
<lifeless> which will merge, and commit, keeping your local commits as a merge to the new origin tip
<bob2> vila: is vc-bzr still developed, or has dvc subsumed it?
<lifeless> if you want to do a fast-forward push, just bzr push url
<w00t_> fast forward?
<lifeless> w00t_: oh, using a git term; just a normal push :)
<lamalex> vila: bob2 do either of you actually use dvc?
<bob2> lamalex: no
<lifeless> ok, going full screen hacking; I'll check back here from time to time - just don't expect fast turnaround on questions for a while ;)
<vila> bob2, AFAIK dvc is still developed and vc is still developed, I *hope* vc-bzr is kept in think, I'd love to find the time to play a bit with some vc-bzr/pymacs/bzrlib approach... but don't jold your breath
<vila> lamalex, I use dvc daily
<lamalex> vila: is there a relevant section of your .emacs i could take a look at?
<vila> sure, but what are you after more precisely ?
<bob2> vila: evil but clever
<bob2> have to incorporate ropemacs into that somehow
<vila> ropemacs ?
<lamalex> vila: i want to be able to just do C-c v c (or something) and have it commit, maybe another command to push, merge, diff, all from inside emacs
<bob2> refactoring dealy, along the lines of bicycle repair man
<lifeless> bob2: oh, can I orphan brm then?
<vila> lamalex, I think the default binding is C-x V (not 'v')
<lamalex> shouldn't a mode show up when I do M-x dvc-<TAB> though?
<lamalex> I don't see anything
<bob2> lifeless: dunno if it has any vim integration yet
<bob2> lamalex: did you load it?
<vila> lamalex, ha ! You're right... but you're wrong :-/
<lamalex> lol
<lamalex> good old emacs
<vila> lamalex, try dvc-status when in a file under bzr control and see
<lifeless> bob2: there is ropevim
<bob2> huzza
<lifeless> http://rope.sourceforge.net/
<lamalex> that opens a new buffer
<vila> lamalex, or try dvc-diff
<lamalex> so do I type a commit message in that?
<vila> lamalex, no wait
<lamalex> ok yah now i see bzr status
<lamalex> so i do -x  c
<vila> no
<vila> :_
<vila> :)
<lamalex> gr
<lamalex> lol
<lamalex> sorry ;)
<vila> try dvc-diff first
<lamalex> ok
<vila> lamalex, sry. I prefer to drive you a bit around so you get a taste, but we'll get to commit fast enough
<w00t_> lifeless: hmm. so i'll have to push each branch seperately?
<vila> dvc-diff is my prefered "mode" but when some files are not yet under bzr control they don't show up, you need to use dvc-status for that
<lamalex> ok so im in dvc-diff
<lamalex> /now/ Do C-x V c?
<vila> now, dvc-diff buffers are indeed in a specialized diff-mode mode
<vila> no :)
<vila> just 'c'
<lamalex> ok so c takes me too a buffer with a commit message
<lamalex> how do I accept that message
<vila> should open a dvc-edit-log-mode buffer when you add your
<vila> C-c C-c
<w00t_> lifeless: heh, I'm now getting bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<lifeless> w00t_: yes, most pushes in bzr are single branch (branch is the basic user object folk work with)
<vila> lamalex, and now you *must* refresh your dvc buffers :-/
<lifeless> jelmer: if you're around, can you offer some hints here, I don't know enugh about bzr-svn's guts to predict what is best for w00t_
<w00t_> (when trying to push to the empty svn repo)
<w00t_> lifeless: ok, thanks, I do appreciate your help and patience
<lamalex> ah ha
<w00t_> I'll wait around to see if jelmer has a few moments :)
<lamalex> hmm how do i refresh the buffers?
<lifeless> jelmer: he is trying to convert a full git repo to svn (preserving datestamps) by fast-export to bzr, then bzr-svn pushes to a new svn repo
<jelmer> w00t_, lifeless: Hi
<w00t_> hey there! :)
<jelmer> w00t_, You can't push to the root of the repository, you probably want to push to /trunk
<jelmer> w00t_, if you would like to push the merged revisions as well, use --merged
<w00t_> jelmer: aha! a bit of a confusing error message :)
<w00t_> hmm, merged revisions.. can you elaborate on that a bit for me?
<vila> lamalex, all in all, there rough edges in dvc (lack of doc being one) but diff-mode is very useful as quick way to navigate into your current modifications and reverting/applying them at will (so be sure to look C-C C-c and C-c C-a in these buffers)
<jelmer> w00t_, merged revisions are revisions which are not on the mainline
<jelmer> w00t_, the revisions shown indented when running "bzr log"
<w00t_> hm
<w00t_> oh, I see
<w00t_> revisions that occured on another branch
<lamalex> vila: thanks for your help
<vila> lamalex, you're welcome
<lamalex> at the very least the diff and commit will be useful
<lamalex> is there a way to push quickly?
<jelmer> w00t_, Does that help?
<w00t_> jelmer: hmm.
<w00t_> jelmer: it went through a lengthy import process, and then:
<w00t_> bzr: ERROR: Prefix missing for branches/merged; please create it before pushing.
<jelmer> w00t_, please create the "branches" directory in the svn repository
<w00t_> jelmer: hmm, that also imported, but didn't preserve committer name/timestamp -- i guess that is wishful thinking then
<jelmer> w00t_, it can, but you have to set an extra option
<w00t_> ..oh.. what do I do after creating that directory? just try push again?
<lifeless> poolie: btw, for the tree logic, I'm allowing mutable nodes internally for now, to get it up and running.
<jelmer> w00t_, yep
<jelmer> w00t_, (newer versions of bzr-svn will do that for you)
<jelmer> w00t_: to keep properties, set "override-svn-revprops = svn:date;svn:author"
<w00t_> hm
<w00t_> where do I set that? I imagine there is some kind of either repo or user-level config
<jelmer> yeah, ~/.bazaar/subversion.conf
<w00t_> thanks!
<w00t_> i shall try experiment with this some more tomorrow
<w00t_> it looks promising :-)
<jelmer> cool :-)
<w00t_> for now, bed for me
<w00t_> thanks for your help lifeless and jelmer :-)
<poolie> lifeless: hey, want to catch up sometime?
<jelmer> lifeless, Could it be that PQM doesn't support ftp:// either atm ?
<lifeless> jelmer: absolutely; different machine, firewalled
<jelmer> lifeless: Ah, ok. I'll just fall back to http for now - thanks
<lifeless> poolie: so what I was trying to say was - there is create_by_apply_delta already, but it and apply_delta have (I think) usefully different behaviours. Changing stuff where it makes sense to use create_by_apply_delta - +1. Avoiding having apply_delta - more trouble than it's worth I think.
<adeel> is it possible to add/update a file to a bzr repo, without checking out the entire tree?
<lifeless> spiv: care to join #gnome-bzr on gimpnet
<lifeless> adeel: using the bzrlib api, yes, but not using the regular commands
<adeel> lifeless, can you clarify how that'd work?
<lifeless> adeel: you'd create a MemoryTree object from the branch tip, make your changes, and commit the MemoryTree
<adeel> my situation is this...i work on multiple projects but not all at once , and carrying around the full repo for each project isn't viable at this moment, so i was wondering if it was possible to add/update files without a fulll checkout
<adeel> lifeless, is that procedure documented anywhere?
<lifeless> adeel: yes, in the bzrlib programming documentation
<adeel> lifeless, one last question, does bzr support overlays?
<lifeless> adeel: but I don't think its what you need; you want something like views, which is proposed but not finished
<lifeless> I don't know precisely what you mean by overlays; I'm guessing you don't mean the 1980's programming model for loading libraries on CP/M and DOS
<adeel> heh, no...i meant overlays in the svn sense
<lifeless> I don't know what they are
<adeel> or multiple working copies at the same time
<lifeless> uhm, clearly we support that, or people couldn't ever work on more than one project
<lifeless> or do you mean co-located ina single directory?
<adeel> yes, in a single dir
<lifeless> no
<lifeless> you can nest working copies
<lifeless> but you can't colocate multiple working copies at a single dir
<adeel> good to know, i can work around that
<adeel> thanks for the help
<AfC> What is "CHK"?
<lifeless> content hash key
<robsta> hi
<robsta> is there a(n easy) way to run bzr from the ppa with bzr-svn?
<robsta> it says "bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~intrepid1 is to be installed"
<siretart> robsta: yes. mkdir ~/.bazaar/plugins ; bzr get lp:bzr-svn/0.4 ~/.bazaar/plugins/svn
<robsta> oh, thanks, guess i'll wait for the deb, then
<siretart> OTOH, it would be nice if the ~bzr PPA would have updated packages for bzrtools and bzr-svn, though.
<w00t_> jelmer: hmm, it seems the setting to preserve committer/timestamp didn't seem to take effect, or is it supposed to be in some subsection of subversion.conf
<w00t_> jelmer: hmm, I really don't know what I've done wrong
<w00t_> jelmer: I set override-svn-revprops like you mentioned, I tried changing it to comma seperated like your FAQ mentions, I tried moving it to bazaar.conf like the FAQ mentions, I enabled the revprop hook and made it executable.. nothing seems to not mangle time/author info :(
<g0nzal0> hullo everyone
<g0nzal0> I've just updated my Ubuntu to Intrepid
<g0nzal0> I have PPA repositories configured
<g0nzal0> and corrected them accordingly
<g0nzal0> which updated bzr to 1.9
<g0nzal0> so
<g0nzal0> now I get
<g0nzal0> bzr: ERROR: Version mismatch
<g0nzal0> when I issue "bzr status"
<poolie> g0nzal0: any other information?
<g0nzal0> or "bzr diff somefolder/somefile"
<g0nzal0> poolie: such as? I'm totally lost here :(
<poolie> is that the only error message it prints?
<poolie> how about if you try "less ~/.bzr.log"
<g0nzal0> well, a warning about bzr-svn is also printed
<poolie> ok
<poolie> i think this means bzr-svn is out of date in the ppa
<g0nzal0> $ bzr diff surveygen/views.py
<g0nzal0> bzr-svn is not up to date with installed bzr version 1.9.
<g0nzal0> There should be a newer version of bzr-svn available.
<g0nzal0> bzr: ERROR: Version mismatch
<poolie> and does it just stop there?
<g0nzal0> yup
<Kinnison> jelmer: What's the state of bzr-git these days?
<verterok> 'morning
<g0nzal0> poolie: whoa ~/.bzr.log has a Traceback!!!! :)
<g0nzal0> poolie: http://dpaste.com/89976/
<g0nzal0> poolie: removing bzr-svn (I didn't really used it much, will reinstall it if needed) did the trick, thanks!
<poolie> ok
<poolie> it should be updated soon
<Spoob> hey
<Spoob> when i try to push the newst version that error message comes: Permission denied (publickey).
<Spoob> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<Spoob> whats the problem?
<Odd_Bloke> Spoob: Are you trying to push to Launchpad without having set up a public key on Launchpad?
<Spoob> Odd_Bloke: i already set my ssh key in launchpad
<Odd_Bloke> Spoob: Well, apparently not. ;)
<Odd_Bloke> Can you use ssh to Launchpad?
<EarthLion_> hey how can i push a specific file from revno x?
<EarthLion_> i don't want to revert
<EarthLion_> i just want to get in into a serparate folder
<Spoob> Odd_Bloke: how can i try it?
<Odd_Bloke> Spoob: 'ssh bazaar.launchpad.net', maybe.
<Spoob> Permission denied (publickey). :S
<Spoob> how can i register the to bzr?
<Odd_Bloke> EarthLion_: 'bzr cat -r<REVSPEC> <FILE>' will show you the contents of <FILE> at the given revision.
<Odd_Bloke> Spoob: You haven't set your public key up properly, it would seem.
<Spoob> Odd_Bloke: i already did it, im sure, https://launchpad.net/~spoob
<EarthLion_> Odd_Bloke: thank you so much :)
<Odd_Bloke> EarthLion_: No worries.
<Odd_Bloke> Spoob: Well, your SSH client isn't using the key, I guess.
<Spoob> how can i set bzr up to my ssh key?
<Odd_Bloke> Spoob: You don't need to set bzr to use your SSH key, you need to set up your SSH client to use your SSH key.
<Odd_Bloke> Then bzr should work fine.
<Odd_Bloke> Spoob: Try 'ssh bazaar.launchpad.net -vv', that'll give you more output.
<awilkins> Don't you need the username so it knows which authorized_keys to check?
<Odd_Bloke> Hmm, yeah, but I'm guessing there'll be a message about not even finding a public key.
<Odd_Bloke> Spoob: Try 'ssh <username>@bazaar.launchpad.net'.
<Spoob> Odd_Bloke: yeah now it works, really thank
<Odd_Bloke> Spoob: And you're able to push properly?
<Spoob> yeas, but now i cant my files here https://code.launchpad.net/~spoob/+junk/main :P
<Odd_Bloke> Spoob: Have you added the files and committed your changes?
<Spoob> yes
<Spoob> but i do it again now
<Spoob> ah now it works thanks!
<jelmer> w00t_, hi
<w00t_> jelmer: morning! :)
<jelmer> Kinnison, it can import from local git repositories, though it's a bit slow
<Kinnison> :-(
 * Kinnison prods someone to keep doing the svn mirror for now
<jelmer> w00t_, if you use the latest revision from the 0.4 branch, there's a separate command-line option
<w00t_> jelmer: i'm using ubuntu's packages.. :(
<Steven1> hi
<Steven1> i'm running intrepid, is there a way to enable nautilus integration?
<chevdor> yes
<Steven1> chevdor: how? i've not been able to find anything useful, and the readme file of bzr says it was packaged without nautilus integration
<chevdor> Steven1, i don't remember, but it works here on my pc so I probably found a solution... I just followed the docs, can't tell u more
<chevdor> Steven1, but it is not fully usable yet i'd say, it's on its way :)
<Steven1> chevdor: thanks, i was just curious :P i think i'll wait a little, command line works well :)
<chevdor> Steven1, it is moving fast though, check out in a few weeks
<Steven1> ok, thanks, is there any chance to see loggerhead packaged?
<jelmer> Steven1, there's a package in Debian experimental that will hopefully make it into jaunty
<Steven1> nice
 * rocky has given up on relying for bzr-connected pkgs in ubuntu ... always out of date
<jelmer> w00t_, what did you set in subversion.conf exactly?
<w00t_> jelmer: one moment
<w00t_> I tried both:
<w00t_> override-svn-revprops = svn:date, svn:author
<w00t_> and: override-svn-revprops = svn:date;svn:author
<w00t_> in subversion.conf as well as bazaar.conf (your FAQ said to use that, at least..)
<jelmer> w00t_, in the section for the repository you're pushing to?
<w00t_> jelmer: ah. no, does it need to be?
<jelmer> w00t_, yeah
<w00t_> jelmer: how can I get a section created before I push, then? it seems to only create one after I've started the push
<w00t_> (also, is the comma or the semicolon version correct?)
<jelmer> w00t_, The section name is the repository UUID (svn info <path-to-repository>)
<w00t_> hmm and how may I retrieve the uuid?
<jelmer> w00t_, it's printed by "svn info <path-to-repository>"
<w00t_> jelmer: okay, I shall give it a go. which should I use, comma or semicolon?
<rocky> so is bzr-hg essentially dead?
<jelmer> rocky, yeah
<jelmer> w00t_, Not sure, actually; I *think* it's semicolon
<rocky> that's too bad, i wanted to mirror a hg branch in bzr to make it easier to work on
<rocky> jelmer: don't suppose you have a pattern (or know of one written up on the web) for managing a bzr branch for a piece of software that uses a foreign non-supported vcs ? (essentially no vcs i guess)
<jelmer> rocky, no, sorry :-/
<hno> rocky: If there is no VCS then import their releases, and do your work on a separate branch merging from the vendor branch.
<rocky> hno: right, i guess the hard part is determining what changed between vendor releases and applying just that into my separate branch
<rocky> oh wait
<rocky> hno: mind elaborating on the import-into-vendor-branch part?
<hno> rocky: bzr does that for you.. just import as-is into the vendor branch..
<jelmer> w00t_, any luck?
<rocky> hno: so import the first release as a vendor branch... and then when another release comes out extract it on top of the old vendor branch and do a add/commit ?
<hno> rocky: Yes.
<rocky> hmm
<hno> and do your own work on a separate branch, using bzr merge to bring changes over from the vendor branch.
<rocky> right
<rocky> awesome thanks
<rocky> that's the sort of pattern i was looking for
<hno> rocky: this pattern works with any VCS supporting merges...
<rocky> hno: sure, i've just never had to do anything like this before ;)
<w00t_> jelmer: kind of caught up in an emergency.. sorry
<rocky> jelmer: another bzr-svn issue...  http://cluebin.appspot.com/pasted/3002
<jelmer> whoa
<rocky> jelmer: btw, when i do a branch like that, does it download all the rev info for the entire remote svn repo ?
<rocky> i hope not, because that svn repo is HUGE and hosts many many projects
<jelmer> yes, it downloads the metadata for all revisions (not the contents)
<rocky> that repo has 75k revisions :(
<jelmer> it's a one-time operation though
<jelmer> and it's quite fast (looks like it's only a couple of minutes here)
<rocky> ah cool
<rocky> jelmer: btw if you do fix that bug i just pasted and it's a simple fix i'd like to apply it against my working bzr-svn
<jelmer> rocky, can't reproduce that here
<jelmer> rocky, can you remove the svn cache and try again ? Are you running the 0.4 branch?
<jelmer> rocky, did you use earlier versions of bzr-svn with this repository?
<rocky> jelmer: i'm using 0.4.15 release tarball ... and i don't believe i've ever used this with the repo, but i can remove my svn cache
<rocky> jelmer: but if you look at my paste you can see it is initializing the svn cache for that repo
<rocky> so that makes it seem like it's "from scratch"
<jelmer> hmm, right
<jelmer> are you out of disk space perhaps?
<rocky> 2gb free
<rocky> not enough?
<jelmer> yeah, that should be plenty
<jelmer> can you try again, just in case?
<jelmer> would be really weird if it did work, but it does work here
<rocky> i'm trying again
<rocky> i deleted the specific cache dir
<rocky> running a lot faster than i expected actually.. already through 14k revs
<rocky> (last time i ran it under emacs eshell which meant i wasn't getting status info)
<rocky> jelmer: when you ran it, did you run it against python2.5 or python2.6 ?
<rocky> it just blew up again
<jelmer> 2.5
<rocky> i'm using 2.6 which probably comes with a diff sqlite3 version which could be the difference
<jelmer> can you try with 2.5 perhaps?
<rocky> hrm, would have to rebuild my environment
<rocky> jelmer: it's a lot further along now with py2.5
<jelmer> if it does turn out to be python2.6, please file a bug
<jelmer> I'll be back in a couple of hours
<w00t_> jelmer: does this look correct, then? (emergency over ;-)) [33d11fd1-86b3-441f-987f-5b8a439e6865]
<w00t_> locations = file://localhost/var/git/public/crazyshit/a-s
<w00t_> override-svn-revprops = svn:date, svn:author
<w00t_> (excuse language, that really is the dirname, should have thought first)
<jelmer> w00t_, yeah, that looks ok
<w00t_> right, I shall give it a go then
<jelmer> alternatively, you can just set it to "True"
<jelmer> instead of "svn:date, svn:author"
<w00t_> hmm, that sets all properties I assume
<w00t_> bzr: ERROR: Unable to set revision property svn:author.
<w00t_> I guess that means my hook is wrong
 * w00t_ investigates
<jelmer> yeah, that would indeed suggest the hook is wrong
<w00t_> jelmer: yeah, that messed up the metadata on the first commit - but worked on the rest, so I guess we're on to a winner now! :)
<jelmer> cool :-)
<w00t_> jelmer: if I might make a suggestion -- would it not make sense to default this setting to on?
<jelmer> The first one would've been incorrect because it adjusts the properties after you push the commit
<jelmer> (and after the first commit you got that warning)
<w00t_> *nod*
<w00t_> I understand why it messed that up, I shall do another import to fix it
<jelmer> You can also just adjust the first revision manually
<w00t_> (*sigh*, this has to be like the 99th time I've recreated this repo now :-))
<w00t_> oh. I didn't know that..
<jelmer> (svn propset --revprop -r<rev> <name> <value>)
<w00t_> now I guess I need to read up on bazaar so I can use it properly :-)
<jelmer> w00t_, There are very few actual SVN repositories out there that allow changing the svn:date and svn:author, that's why it's not enabled by default
<w00t_> jelmer: oh. good point!
<rocky> jelmer: turned out to be specific to py2.6 ... i'll setup a bug report here when i get a chacne
<jelmer> rocky, thanks
<w00t_> elmer: (though a param to svn-push would perhaps work too?
<jelmer> w00t_, there is a parameter to svn-push in the 0.4 branch :-)
<w00t_> jelmer: oh! fantastic
<w00t_> now I'll just have to wait until ubuntu picks it up... :-P
<jelmer> jaunty should have it..
<w00t_> ah.
<w00t_> good, because I'll probably be running it when it hits alpha
<Peaker> I'm looking at https://zooko.com/badmerge/concrete-good-semantics.html -- and it makes a convincing argument that a 3-way merge loses interesting information
<abentley> Peaker: Bazaar supports more types of merging than just 3-way.
<Peaker> abentley: what advantage does 3-way have over looking at all the intermediate revisions?
<abentley> Peaker: It's faster and easier to understand.
<Peaker> correctness over performance? :-)
<Peaker> I don't know if it is easier to understand, if a newbie is facing a conflict that would not be there if the merger looked at all available information, its probably harder for the newbie to understand
<abentley> Peaker: It is.  We have experience with peoples' reaction to weave merge conflicts, and they can't tell what's going on.
<abentley> With 3-way, you can look at the different versions and see why it's doing what it's doing.
<abentley> When there are N versions, that's essentially impossible.
<Peaker> abentley: I see
<abentley> Peaker: Also, Zooko is not presenting a case that causes conflicts.  Situations where 3-way produces conflicts but weave merge would not are rare, except for criss-cross merge.
<Peaker> abentley: zooko says its worse, you get no conflict, but a wrong merge silently
<Peaker> abentley: square was renamed and a new square function was written, and the merge takes the new square to be the old..
<abentley> You were talking about "a newbie facing a conflict".
<Peaker> oops, my bad ;)
<Peaker> I guess its a newbie getting a wrong merge
<abentley> Peaker: Yes.  No merge will ever be perfect.  The best defence is a test suite.
<Peaker> abentley: does weave introduce confusing conflicts that 3-way doesn't?  If not, what was confusing about its merges?
<abentley> Peaker: I don't think it produces them more often, but when it does, they may be more confusing.
<abentley> Because they are caused by information that you can't see.
<Peaker> you could see the whole 2 diff paths side-by-side, rather than 2 big patches side-by-side?
<abentley> Peaker: I don't understand the question.
<Peaker> abentley: you said its based on information you cannot see, why not show it?
<Peaker> the information is all the intermediate revisions, right?
<abentley> Peaker: The information is the graph of revision history and the annotation of the lines, and the resulting status of the lines.
<gauthierm> Has anyone here used bzr-svn?
<jelmer> yep :-)
<bob2> lol
<yml> I am trying to port some of the modif done in a bzr repo to a git repo. I try to use something like bzr export <git_folder> <bzr_branch>
<gauthierm> I exported an svn repository and made several hundred changes in bzr. I now have svn commit access. Is it possible to replay my bzr commits as svn commits?
<mDuff> gauthierm, being able to push to svn repositories is one of bzr-svn's big bullet points, though I haven't used it personally.
<yml> bzr is telling me that : bzr: ERROR: [Errno 17] File exists: '<git_folder>/'
<mDuff> yml, you're not trying to keep history, just move a snapshot? export to a new directory, rsync from that into the git folder.
<yml> mDuff: ok that will do I was looking for a --overwright option
<yml> mDuff: but what you propose seems to be a workable solution
<jelmer> gauthierm, if the history is linear (no merge commits) you should be able to just use "bzr push"
<yml> mDuff: Do you know the option on top of your head to overwrite with rsync
<mDuff> yml, rsync -ra source_dir/. dest_dir/. should do that by default.
<yml> I try rsync <exported_branch> <my_git_folder>
<mDuff> yml, the /. is there for a reason.
<mDuff> yml, same with the -ra
<yml> ok
<yml> mDuff thank you for your kind assitance
<gauthierm> jelmer: Yep, its linear. Do I just point to hte svn repo in the bzr push command?
<jelmer> gauthierm, yes
<gauthierm> nice
<gauthierm> jelmer: bzr says the braches have diverged and I should merge. The merge command says my .bzr repository is not compatible with the svn repository.
<gauthierm> It's worth mentioning that I did a clean export of the code (no svn info) before starting my work in bzr.
<jelmer> gauthierm, ah, so the original branch wasn't created using bzr-svn ?
<gauthierm> jelmer: nope. I used svn export and then bzr init.
<mDuff> ...oh; that's not good.
<jelmer> gauthierm: In that case, it's not so easy to push your changes into svn
<gauthierm> hmm.. is it impossible or just more difficult?
<mDuff> gauthierm, well, you can write a script that reapplies as patches one-at-a-time; with a bit of elbow grease, nothing's *impossible*
<gauthierm> Is there any example of doing that sort of thing online?
 * mDuff would probably make a new branch, created *with* bzr-svn, and transfer patches onto that; safer than trying to apply straight to the real svn repo.
<gauthierm> agreed
<mDuff> gauthierm, does your branch include renames, move operations, or the like?
<gauthierm> mDuff: Yep. Quite a few.
<mDuff> ...hrm; that makes things trickier.
<gauthierm> Trickier in the get-patch, apply-patch sense?
<mDuff> gauthierm, hmm -- looks like the fastimport stream format is name rather than arbitrary-ID based; you *might* be able to use the bzr-fastimport toolchain to move revisions between the branches, but YMMV, some-assembly-required.
<gauthierm> So if I did this correctly from the start, how would it work?
<mDuff> gauthierm, if you'd used bzr-svn to check out from the svn repo in the first place, and there hadn't been changes made to the repo in the meantime? You'd run "bzr push svn://whatever" and it'd Just Work.
<mDuff> ...at least, that's my understanding.
<jelmer> yeah, that's right
<adeel> anyone mind helping me think through a repo layout?
<hno> adeel: can try
<adeel> hno, thanks...i'm pretty much trying to setup a central repo for personal & project files over windows/mac/linux on 3 different machines
<hno> ok.
<adeel> in svn, i would have used the svn:external feature, which would let me create multiple repo profiles that i could check out for a semi-custom tree
<adeel> where svn:externals has this functionality: http://svnbook.red-bean.com/en/1.0/ch07s03.html
<adeel> i recall reading about a 'meta-repo' for bzr, but can't seem to find any meaningful documentation on it
<hno> adeel: Do you really really want a split repository where some parts is hosted here and some parts there?
<adeel> hno, well all my project files should be separate from my personal ones...because i'll need my project files on the 3 different os's, but i don't need the . files in windows but i do in mac/linux, nor do i need the Library folder in linux/windows but i do in Mac
<adeel> hno, i was hoping not to have multiple repo's, but 1 common repo between them all, and each is in it's own top level dir
<Peng_> What's the difference between bzr+http and http? Why are they different?
<hno> Peng_: bzr+http is the bzr smart http server, with bzr extensions. http is plain http file serving.
<adeel> hno, i was thinking of using 10.2.1.2 as the layout....http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#choosing-a-shared-repository-layout
<adeel> or 10.2.1.1
<Peng_> hno: I know that. I mean that "http"'s smart server auto-detection behaves differently from bzr+http.
<Peng_> BTW, "bzr branches" is *really* inefficient over a smart server, heheh.
<Peng_> Haha, it made like 500 requests.
<Peng_> To scan a fairly small directory tree.
<Peng_> ...Seriously, there were like 5 branches there.
<adeel> hno, any thoughts on the layout?
<LarstiQ> Peng_: I assume it's trying to to a vfs tree walk?
<Peng_> LarstiQ: Probably.
<Peng_> s/Probably/I guess/
<Peng_> Why does walking...64 directories take 500 requests though?
<Peng_> (And why do I have 64 directories there anyway?)
<LarstiQ> I don't know the answer to that, but I do know 'branches' is horribly inefficient over http (or other transports without a reliable listdir)
<Peng_> Does bzr+http should have a reliable listdir?
<adeel> apparently not
<hno> adeel: Never needed to do anything like that.
<LarstiQ> Peng_: no
<Peng_> Wait...is the mailing list at lists.canonical.com or lists.ubuntu.com?
<LarstiQ> Peng_: bzr+http is supposed to not use vfs methods when it can. But I doubt there is a `Repository.branches` verb.
<adeel> hno, well from the bzr doc's, it says i can get similar functionality with nested trees, so i might give that a shot...but right now i'm still 1 step behind that...i'm still not sure how to setup the repo right...do i init-repo with or without trees?
<LarstiQ> Peng_: I'd guess canonical, but both hosts have resolved to the same thing in the past iirc
 * LarstiQ needs to start learning section numbers by haert
<Peng_> They're different hosts ATM.
<Peng_> s/hosts/IPs/
<hno> adeel: Without generally if it's a shared repository accessed remotely..
<adeel> hno, and what does that result in practice? the --without-trees option just adds the blank dir without any of the subdirs to a repo?
<hno> adeel: Yes, only the .bzr control files.
<hno> adeel: actual content only stored within bzr.
<adeel> and the benefit of that is?
<abentley> jml: Quick talk?
<jml> sure.
<jml> voice?
<LarstiQ> adeel: not storing things you're not using.
<abentley> jml: yah
<adeel> LarstiQ, i'm still unclear on that....i can understand using that when checking out a repo, but why would i do that when creating a repo, unless i was trying to nest branches or something?
<hno> adeel: With a shared repository you have the checkout in your working directories, not the repository. In a non-shared repository the repository and working directory is the same.
<adeel> i never knew RCS's could be so confusing....svn seems trivial compared to bzr at this point
<adeel> hno, can you clarify the 'you have the checkout in your working directories, no the repository' for me? i think i'm interpreting it wrong
<LarstiQ> adeel: well, in the case of a repository on a remote server you don't do any actual work on, it's purpose is publishing/archiving branches.
<LarstiQ> adeel: you will never edit files or merge things there. So you don't need a working tree.
<adeel> LarstiQ, yeah, i get that
<adeel> ahhh, ok; so where does bzr store the files on the repo then?
<hno> adeel: It stores them in the bzr repository. Located in the .bzr folder in the directory you specified to init-repo
<Peng_> Oh, I bet I understand why. "bzr+http" uses the smart server for VFS operations, while "http"...doesn't.
<Peng_> That probably makes http more efficint.
<hno> Peng_: Do "http" ever use the smart server?
<Peng_> hno: Yes.
<Peng_> hno: "http" has automatically probed for .bzr/smart since 1.4rc1.
<LarstiQ> adeel: the files are stored as history, just like svn would.
<adeel> LarstiQ, so is there a preferred layout for a shared repo in bzr? i was thinking of doing multiple TLD
<adeel> LarstiQ, true, but svn also stores the files/revision history in either a bdb or flat file structure, i'm not sure how bzr stores it...seems like flat files
<LarstiQ> adeel: personally, I have one repository per project, and a reasonably flat namespace within
<adeel> LarstiQ, does that add a lot of overhead?
<Peng_> adeel: No.
<LarstiQ> adeel: nope
<adeel> the only reason i ask, is that i expect to have multiple common files in some of the projects & personal files
<adeel> and instead of having duplicate files everywhere, just have the common file projects be branches
<haaseg> I must be doing something wrong  - I can't get any of the team context menu options to be active up in bzr-eclipse
<LarstiQ> adeel: that could make sense, yes.
<adeel> LarstiQ, i'm still having trouble wrapping my head around what bzr calls branches and whatnot...even though i've read the user guide/intro materials a few dozen times
<haaseg> anyone using bzr-eclipse?
<hno> Peng_: Right. I get your original question now.
<LarstiQ> adeel: branches are the major units you work with with bazaar.
<adeel> LarstiQ, yeah, i've figured that much out...i guess a lot will get cleared up when i actually start doing work with it
<LarstiQ> adeel: I sure hope so :)
<adeel> otherwise i'll just be back here bugging everyone =cp
<LarstiQ> adeel: one branch versions a set of files/directories together as a logical unit.
<LarstiQ> adeel: that's ok :)
<adeel> LarstiQ, so each branch has it's own revision numbers, correct?
<LarstiQ> adeel: correct
<adeel> ok, so it seems like i'm going to do the nested style repo....
<adeel> with a nested repo, i can still do --local commits if i choose to, correct?
<haaseg> So...  what I guess I don't understand with all the branches - what is the trunk?
<adeel> haaseg, it depends on what style of a repo you have
<adeel> you don't necessarily have to have an explicit trunk it seems
<adeel> haaseg, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#choosing-a-shared-repository-layout might clarify a few things
<haaseg> thx adeel
<adeel> np
<mfoniso> When trying to commit changes using the command 'bzr commit -m "comment" filename', I get the following error -  bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Estefanlsd/%2Bjunk/source-switcher/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<mfoniso> can anyone please tell me what I'm doing wrong?
<w00t_> is there a way to rename a branch?
<lifeless> 'mv foo bar'
<lifeless> mfoniso: you've checked out a branch over http; launchpad doesn't run an http write-demon, so you can't commit to it there
<w00t_> lifeless: really that easy? hah, awesome
<lifeless> mfoniso: also, unless you are stefanlsd, you're trying to commit to someone else's branch
<lifeless> mfoniso: you can: convert your checkout to a branch (bzr reconfigure --branch), or you can 'bzr switch' to a writable url (but as I'm guessing its not your branch you'd need to make a branch first, doing the reconfigure is probably best)
<lifeless> mDuff: btw
<lifeless> mDuff: are you still doing that huge repo project?
<mDuff> lifeless, no -- that was my former employer; I bailed out of there around January or so.
<lifeless> ok. I was going to mention that the 1.9 format would be a significant upgrade
<lifeless> good basic data types for the win
<PeanutHead> Hey everyone, hopefully you guys can help me, I'm new on Bazaar, I already created my branch, commit my changes, and i'm trying to creat a patch to send by email, but the command send -o fix.patch is not working
<PeanutHead> the error msg that pops up is: bzr: ERROR: No submit branch known or specified
<PeanutHead> I have no idea what is wrong since I'm inside my brach directory
<mDuff> PeanutHead, provide as an extra parameter the branch which you want to submit changes relative to
<PeanutHead> mDuff, my branch is at the folder src, so I would have to write the send command like this: command send -o fix.patch src
<PeanutHead> ?
<mDuff> PeanutHead, src is what you have that you want to submit, not where you started from, right?
<lifeless> PeanutHead: 'send -o fix.patch BRANCH_YOU_MADE_YOUR_BRANCH_FROM'
<PeanutHead> src is the directory where I started my branch
<PeanutHead> lifeless, BRANCH_YOU_MADE_YOUR_BRANCH_FROM means branch nick??
<mDuff> PeanutHead, it isn't the branch that the upstream people you're submitting your patch to have, though, right?
<mDuff> PeanutHead, when you did your initial "bzr branch", you provided a remote URL to someone else's system, I'm assuming; that URL is probably what you want to use here.
<PeanutHead> no.. i didnt provide an URL
<PeanutHead> mDuff, I'm using it locally and then I'm supposed to send the changes
<lifeless> PeanutHead: how did you get your local branch
<PeanutHead> lifeless, bzr init
<PeanutHead> lifeless, bzr add
<lifeless> PeanutHead: and the person you want to send these changes to, they are already using bzr?
<PeanutHead> lifeless, bzr commit -m "msg"
<PeanutHead> lifeless, yeah he is using
<mDuff> PeanutHead, ahh -- you should have made your branch by branching their remote branch, not by running a new "bzr init"
<lifeless> PeanutHead: so, what you have done is start a branch new project in bzr, rather than work on his project; you need to do 'bzr branch HIS-BRANCH LOCAL-PATH'
<lifeless> then cd LOCAL-PATH
<lifeless> make your changes
<lifeless> bzr commit -m 'MSG'
<lifeless> and then 'bzr send'
<PeanutHead> lifeless, let me try
<mfoniso> lifeless:thanks for the suggestions... it turns out I have to upload my ssh keys to launchpad, but it won't accept the ones I have which were supposedly created using a vulnerable ssh suite. And I'm having problems upgrading to the fixed ssh suite. I'll just leave it for later. I'm going to sleep
<lifeless> mfoniso: gnight
<PeanutHead> lifeless, it is asking for an email address.. should I simply add an email address?
<lifeless> PeanutHead: of the person you want the changes sent to, yes
<PeanutHead> C:\Documents and Settings\David Nemer\workspace\Projektarbeit\src>bzr send ../src dmerge@gmail.com
<PeanutHead> bzr: ERROR: No mail-to address specified.
<PeanutHead> lifeless, still says that no email is specified
<lifeless> PeanutHead: 'bzr send HIS-BRANCH'
<lifeless> PeanutHead: no other parameters
<lifeless> PeanutHead: no other options
<PeanutHead> lifeless, I guess it works now! thanks so much for your help
<PeanutHead> mDuff, thank you too man
<poolie> hi lifeless
<poolie> net is flakey
<lifeless> the hi poolie1
<lifeless> was mailing jam
<lifeless> poolie1: if jam can run up skype that would be better voice quality
<Pieter> igc: did you see the fastimport patches?
 * jml does a thing he hasn't done before
<poolie1> lifeless: i was wondering about calling this new format 'mesh' to continue the theme
<lifeless> mesh?
<jdong> that's a neat buzzword :)
<poolie1> knit, weave, mesh
<poolie1> i think it needs some short non-acronym name
<thumper> is there a way to reconfigure a shared repo with trees to be a shared repo without trees?
<jml> yes
<jml> (or maybe no)
<jml> but probably yes.
<thumper> jml: thanks, but I really want a command to run
<jml> no, I can't see an option.
<abentley> thumper: touch .bzr/repository/no-working-trees
<jml> thumper: if you are trying to switch over to a "shared repo without trees + lightweight checkout" layout, I wrote a plugin to do just that.
<thumper> abentley: oh, nice integrated command then :)
<Odd_Bloke> That seems like something that should be 'reconfigure'able...
<abentley> Odd_Bloke: indeed.
<jml> thumper: https://code.edge.launchpad.net/~jml/+junk/bzr-establish -- the code is pretty bad.
<thumper> jml: I'm sure it is awesome
<Odd_Bloke> jml: Some of the docstrings are wrong. :)
<jml> Odd_Bloke: all part of the fun :)
<Odd_Bloke> :D
<jml> thumper: your confidence overwhelms me :P
<Odd_Bloke> Anyway, I should avoid getting sucked into that, as I have work tomorrow. D:
<mDuff> btw -- I've been working with git recently; one of the (few) things I like about its UI is the ease of working with branches. Have helpers been added to bzr while I wasn't paying attention (read: anywhere in the last few years) to offer similar terseness in addressing different branches within the current project's repo? "bzr switch" appears to do The Right Thing, for instance, but I don't see a way to do something similar with "bzr branch" w
<mDuff> ithout specifying a full path to the repo; likewise for ease of deleting old branches, checking branch status (ie. listing which are merged/unmerged)...
<poolie1> only in a very limited way with switch
<poolie1> there was a recent thread
<lifeless> mDuff: there is a plugin that lists branches that can be deleted/merged
<lifeless> jml: ^ was it yours?
<poolie1> i think having easier access to branches would be good; otoh having branches simply at urls is good
<jml> lifeless: yes.
<jml> bzr-removable
#bzr 2008-11-12
<poolie1> jml, interesting: i just did bzr push --remember -Dhpss --stacked bzr+ssh://bazaar.launchpad.net/~bzr/bzr/brisbane-core
<poolie1> and it made it stacked on the public location of the parent branch, not on lp:bzr as i expected
<jml> poolie1: right. so what I normally do, as advertised on the Launchpad blog, is just bzr push lp:~bzr/bzr/brisbane-core
<jml> poolie1: bazaar's default stacking policy feature takes care of the rest
<jml> poolie1: use --stacked essentially overrides our stacking policy
<jml> s/use/using/
<poolie1> interesting
<poolie1> and bzr now defaults to stacked
<jml> poolie1: only if there's a stacking policy on the other end.
<jml> poolie1: which there is in this case
<poolie1> that may not be so great til bug 288751 is ixed
<ubottu> Launchpad bug 288751 in bzr "bzr push returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<jml> poolie1: then bug 288751 needs to be fixed.
<ubottu> Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<poolie1> indeed
<poolie1> aaron sent what seemed like a reasonable plan
<abentley> poolie: I'm not actually sure how to tackle 288751.  I'm somewhat against disabling the current behaviour, because I suspect there are hundreds or thousands of afflicted branches.
<rusty> Hi all!  Anyone interested in 'bzr upgrade' failures?
<abentley> poolie: I'd rather bless the current behavior.  A subsequent format could be stricter.
<poolie> rusty, yes
<abentley> poolie: A groupcompress format would be stricter anyhow.
<rusty> bzr: ERROR: Revision {[('_info.30342-20080814081531-zlq95k6nqflx7n8y-1', 'dinesh@dinesh-laptop-20080814081712-cckpecc9m4vao31v')]} not present in "<bzrlib.knit.KnitVersionedFiles object at 0xa3f474c>".
<rusty> poolie: 1.6.1 from my upgrade yesterday to 8.10.
<rusty> poolie: what do you need?
<poolie> rusty: i suspect this is bug 288751 we're just talking about
<ubottu> Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<poolie> it'd be useful if you add the 'bzr info' results on that to that bug
<rusty> Domo aragato, ubottu.
<poolie> abentley: do you want to talk here or on mail?
<poolie> so the main question is just what server-side autopack should do
<abentley> poolie: No, it's larger.
<abentley> poolie: The main question is "should we permit text deltas across stacked repositories"?
<poolie> so i basically agree with robert that we should not be generating them
<poolie> s/basically//
<rusty> poolie: bzr info?  After failure or before?  Output not interesting.
<abentley> poolie: There's no server-side autopack involved here.
<poolie> does it say it's stacked on something?
<rusty> poolie: no...
<abentley> poolie: Fine, but we've already generated many stacked branches.  They are probably afflicted.  How should we deal with them?
<abentley> AFAICT, robert wants bzr to fail if it encounters them.  I am more inclined to keep existing branches working.
<rusty> poolie: It's a very vanilla tree I think.  And just not that complicated.
<poolie> rusty: i would suggest that you make a backup, run bzr reconcile, bzr check, bzr upgrade
<poolie> if that does not fix the problem, file a bug, and if the code is public attach a tarball of it
<rusty> poolie: OK, I'll try that now.
<rusty> poolie: yes, good news is this is all public.
<poolie> insert before those instructions, move backup.bzr back in place
<rusty> poolie: woot!  I blew up reconcile!  Do I get a prize??
<poolie> yes :/
<poolie> abentley: so perhaps we could do a query on lp for branches that are stacked, and then look at if they have text deltas across repositories
<rusty> I will report a bug and attach the 4MB tarball of the whole repo.
<poolie> thanks
<poolie> for reporting it, and sorry for the incovenience
<rusty> poolie: heh, I've filed 6 KDE4 bugs in the last 12 hours... this is nothing :)
<jml> poolie: how would that influence the decision?
<poolie> heh
<jml> also, we don't record all instances of stacked branches, only branches stacked on other branches also in/mirrored on Launchpad.
<abentley> jml: because of the bzr+ssh bug, no one would want to stack their launchpad branches on something else.
<jml> abentley: that's comforting.
<ryanakca> why do I get this with any bzr command? http://paste.ubuntu.com/70759/
<poolie> so if it's only happened on the particular branches were lp recommends stacking, then it's more reasonable to do a one-off fix
<poolie> ryanakca: because the gtk plugin (or something related) is assuming you have a desktop running
<poolie> but i would guess you're running it from a text or ssh session or similar
<poolie> i think this was fixed in a later release
<poolie> https://bugs.edge.launchpad.net/bzr-dbus/+bug/199513
<ubottu> Launchpad bug 199513 in bzr-gtk "gcommit crashes: ERROR: dbus.exceptions.DBusException" [Low,Fix released]
<ryanakca> poolie: could it be qctBzrPlugin? Its the only one without a description... the rest: http://paste.ubuntu.com/70761/
<jml> poolie: so, I don't see the # of affected branches as being a factor.
<jml> poolie: either you break them and provide a script (or whatever) to fix them, or you accommodate them and fix the underlying issue in a new format.
<rusty> poolie: OK, filed bug 297024.  That should keep you off the streets for a bit longer :)
<ubottu> Launchpad bug 297024 in bzr "bzr reconcile crashes" [Undecided,New] https://launchpad.net/bugs/297024
<ryanakca> poolie: nevermind, thats what it is...
<poolie> jml, that's basically true - if it turned out to be just one or two it would be more reasonable to say 'just remirror them'
<ryanakca> poolie: or what I thought it was. Still there. What can I do? If I go --no-plugins, it disables the svn plugin as well... but I need the svn plugin to checkout / svn->bzr...
<poolie> ryanakca: can you upgrade?
<poolie> or otherwise remove the gtk or qt plugin
<jml> poolie: I seriously doubt it's 1 or 2
<ryanakca> poolie: I can't see any of them installed... I removed qct, which is a qt one... but, I still get it... all of my plugins are in the above paste.
<jml> poolie: when spm gets back, he can tell us which branches are stacked. I'll need more bzr expertise to get a test for the other bit.
<poolie> ryanakca: reckon the 'dbus' one might have anything to do with it? ;-)
<abentley> jml: You should be able to repurpose Packer._check_references to do that.
<lifeless> abentley: or james-w's script
<abentley> lifeless: I didn't see that one.
<lifeless> abentley: its attached to one of the bugs
<jml> abentley: everything about that except the pronoun sounded great :)
<abentley> jml: Y'all should be able to repurpose Packer._check_references to do that?
<jml> abentley: "one should be able to..."
<jml> poolie: fwiw, we're looking at 300+ stacked branches on LP
<jml> well, the list of branch ids is at https://pastebin.canonical.com/11067/. Let me know if you need a hand writing the script :)
<awmcclain> Why aren't new branches I push group writable? Am I missing some umask for bzr?
<abentley> awmcclain: are you using sftp?
<awmcclain> bzr+ssh
<abentley> awmcclain: There's no bzr-specific umask.  What does "ssh $HOSTNAME umask" report?
<awmcclain> 0022
<abentley> awmcclain: So your remote host umask is set to disable group write.
<awmcclain> Ah. I figured it was a system configuration. I'll go look up ssh and umask.
<adeel> what's the easiest way to create a central branch and commit data to it? the user-guide isn't very clear on it
<Peng_> Wait...can anyone log into pastebin.canonical.com?
<lifeless> Peng_: anyone can authenticate
<Peng_> Oh.
<lifeless> adeel: once you have your code locallly; bzr push CENTRAL BRANCH
<lifeless> adeel: then 'bzr bind CENTRAL_BRANCH' to make that into a checkout, and other people can do 'bzr checkout CENTRAL_BRANCH'
<adeel> lifeless, so does that work if the central repo is local to my system? that is, i want the repo to be stored at /foo, but right now, the contents of the files are at /bar
<Peng_> You're right, I can /authenticate/. I just don't have permission to access anything. ;P
<poolie> for some reason bzr builddeb is not following its .bzr-builddeb/local.conf
<lifeless> adeel: yes
<adeel> lifeless, interesting...thanks for the info...and btw, if you know who maintains the user's guide on the bzr website, they might need to update/clarify it
<lifeless> adeel: file a bug with whats unclear please
<adeel> lifeless, sure
<adeel> also, what transports are enabled by default for bzr? sftp? http? ssh? etc
<lifeless> everything that the libraries for are on your system
<adeel> there a way to find out which ones are?
<lifeless> the deb packages depend on enough to have ftp/http(but not webdav)/ssh/bzr/filesystem/sftp work
<lifeless> adeel: bzr help urlspec
<adeel> ah, i'm on gentoo, so the deb packages don't help =cp
<adeel> thanks for the tip
<poolie> lifeless: what i'm saying is
<poolie> if you push to lp/bzr, you may also hit the stacking issue
<lifeless> oh sure
<lifeless> but I have ways and means for that "{
<lifeless> :P
<lifeless> poolie: can you do me a favour
<lifeless> poolie: push to lp:~bzr/bzr/brisbane-core, the branch you have?
<lifeless> it won't stack
<poolie> it's runnig
<lifeless> http://paste.ubuntu.com/70801/
<lifeless> igc: /srv/conversions/manganese on tungsten
<lifeless> igc: 136Gb, knock yourself out
<fullermd> You can't mix manganese and tungsten!
<lifeless> fullermd: not mixing. layering
<fullermd> Stacking?   ;)
<abentley> lifeless: Do you know why pqm would treat bzr+ssh://bazaar.launchpad.net/%7Eabentley/bzr/1.9-launchpad/ as a Baz1 branch?
<poolie> abentley: it tends to treat anything it doesn't understand as a Baz1 branch
<poolie> i would guess that you've hit 288751 and therefore lp is not republishing it over bzr+ssh
<poolie> oh
<poolie> in fact, that's the simpler answer, it probably just can't ssh to launchpad
<poolie> you need an http url
<abentley> poolie: I merged something via SSH yesterday evening.
<abentley> poolie: We use PQM with the launchpad codebase and that's confidential, so we use SSH for it.
<poolie> ok
<poolie> nevermind that then, though i thought it used to fail
<spiv> abentley: because it's not a branch? https://code.edge.launchpad.net/~abentley/bzr/1.9-launchpad/
<poolie> i can't access it over ssh eithre
<spiv> Random guess: you uploaded in 1.9 format, but Launchpad doesn't understand 1.9 yet.
<abentley> spiv: bzr info reports "Standalone branch (format: 1.6)"
<poolie> abentley: so then i'd come back to my statement that it's affected by 288751
<spiv> Random and wrong guess :)
<lifeless> poolie:
<lifeless>             # Performance with commit was profiled extensively, and it found that
<poolie> i pasted a reproduction sample to that bug btw
<lifeless>             # using the keys of the Inventory._byid was faster at the time. We
<lifeless>             # want to move away from doing this, but until careful profiling
<lifeless>             # is done, we're preserving the old behaviour.
<lifeless>             # <lifeless, poolie>
<lifeless> abentley: if it can't access the branch it will fall back to considering it a baz branch, which is not as probable
<poolie> i'd say "using the keys ... (rather than eg building a set from the key iterator)"
<poolie> i think you need to be a bit specific
<poolie> otherwise it's like the billboards in qld saying "motorcyclists beware"
<poolie> beware what, bats?
<poolie> i was also thinking that it might have been better to do a getattr() rather than isinstance
<poolie> it's more to the point of what we're trying to switch on
<abentley> poolie: That only happens on autopack, but perhaps the mirroring process is autopacking.  That would be #280595 actually.
<poolie> i posted a reproduction example
<poolie> it may be on the wrong bug strictly speaking
<abentley> lifeless: So it looks like the failure is because of a problem mirroring it.
 * abentley sells all his computers and buys a spaghetti farm.
 * fullermd will show his support by buying bulk spaghetti.
<igc> night all
<poolie> abentley: i have some ideas on 288751, nothing really conclusive yet
<poolie> there is a check Packer._check_references that's meant to stop this but does not
<lifeless> (Pdb) self.source.get_inventory('sp1r-monty@donna.mysql.com-20000829163832-06287')['sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4']
<lifeless> InventoryFile('sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4', 'bk.txt', parent_id='sp1d-docs-ncsbsqrhxzflos6d2mrwgql4b7a7gacv', sha1='b5a47ca433f25aac932844515415ef43209ae017', len=3087, revision=sp1r-monty@donna.mysql.com-20000829163832-06287)
<lifeless> (Pdb) self.target.get_inventory('sp1r-monty@donna.mysql.com-20000829163832-06287')['sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4']
<lifeless> *** KeyError: 'sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4'
<lifeless> seems to be scaling well:
<lifeless> Commits: 1665
<lifeless>                       Raw    %    Compressed    %  Objects
<lifeless> Revisions:       6202 KiB   0%      1921 KiB   5%     1665
<lifeless> Inventories:    27210 KiB   1%     14446 KiB  43%    29953
<lifeless> Texts:        1520391 KiB  97%     16477 KiB  50%    11401
<lifeless> Signatures:         0 KiB   0%         0 KiB   0%        0
<lifeless> Total:        1553804 KiB 100%     32844 KiB 100%    43019
<jelmer> looks promising
<lifeless> the compressed size inventories are still just 'gzip' rather than deltas
<lifeless> which is why it is ~50% smaller and thats all ;)
<fullermd> Do you have a feel for how much difference there is to be made there?  'nother factor or 2, or 10?
<lifeless> well
<lifeless> we write ~20 nodes per commit
<lifeless> of those, I guess its one leaf per changed inventory entry at worst
<lifeless> and a leaf is quite compressible - its 4K of line orientated binary
<lifeless> foo\x00bar\nquux\x00gam\n
<lifeless> so, if we change say 200 bytes per 4K page, thats say 300 bytes with headers as a delta, or 150/200 as a gzip delta
<lifeless> down from 2K
<lifeless> so yeah, 5% of repo size compressed would be worth aiming for
<fullermd> Awesome.
<fullermd> (seeing the inventories compress to just barely smaller than the texts offended my intuition of what relative magnitudes should be.  Made me wonder if my intuition was completely cracked.)
<lifeless> seeing it at 96% offended me
<fullermd> Well, inventories are important; why shouldn't they get plenty of bytes!
<asabil> hi all
<jelmer> hey asabil
<asabil> did anyone write a plugin to submit merge requests directly to bundle buggy ?
<jelmer> asabil: how do you mean? Afaik bundle buggy only accepts merge requests via the mailing list
<asabil> I would like to make my team mate use bundlebuggy
<fullermd> Well, one could setup BB with a direct mail address, and just make send default to that address.
<asabil> but getting them to use a mailing list, and setting their mails would be a big hassle
<fullermd> I don't remember if there's already support for setting a default send address or not; that make take a little plugin-fu.
<jelmer> yeah, you can set a default send address
<jelmer> child_submit_to =
<LarstiQ> asabil: they can use `bzr send`
<asabil> I am thinking about exposing some rpc over http, and add a bzr command to directly submit a merge request
<asabil> yes, but they need to setup a mail program I guess ?
<fullermd> I thought send could just spawn off an editor and `sendmail`-submit it itself.
<fullermd> (of course, that assumes the rest of the system is properly setup for mailing, which I always assume but may not be valid in your neighborhood)
<asabil> I don't think that's the case unfortunately
<LarstiQ> it can also use smtplib iirc, useful for hosts without an mta
<asabil> so basically I would just setup bundle buggy, and create an email address for it
<asabil> and then configure bzr send to use smtplib ?
<fullermd> Yah.  [AFAIK] it just gets email; seems to usually be done by subscribing it to a ML, but could just as easily be mail sent right at it.
<lifeless> asabil: yah
<lifeless> asabil: I'm sure more can be done, but thats the current state-of-play
<asabil> okidoki, thanks a lot
<asabil> one last question, how do I configure bzr send to use smtplib ?
<jszakmeister> jelmer: Thanks for taking care of that corruption bug.
<jszakmeister> Looks like there's one more with the branch nick stuff... but it sounded like 1.9.1 was going to have a fix for that.
<jelmer> jszakmeister: yep
<lifeless> asabil: its in the configuration help
<asabil> bzr help send | grep smtp gives nothing
<strk> ERROR: Your shelved patch no longer applies cleanly to the working tree!
<strk> now what ?
<strk> I shelved changes in a brach because I selectively patched trunk with some of the changed
<strk> then merged the updated trunk into the branch again
<strk> and now was willing to unshelv, expecting the already-found patches to become non-changes
<strk> but I get that error above...
<lifeless> strk: that version of shelf works with simple patch(1) behavour
<lifeless> strk: just supply --force
<lifeless> bzr's next release has a better shelve that should do what you were expecting
<strk> ok, --force did it, produced some .rej but I'm fine with them, seem to be the patches I didn't want to apply anymore cause already applied in trunk
<strk> how to clean the shelf now ?
<lifeless> bzr shelf list
<lifeless> bzr shelf delete (thing to delete)
<strk> great, thanks
<luks> asabil: bzr help configuration
<asabil> thanks
<rocky> any here use cmd-line bzr with emacs? trying to get sensible status info to show up but it seems to be killing emacs
<abentley> asabil: In terms of receiving patches, bundle buggy just scans a directory containing messages.  Whether it's personal mail or from a mailing list shouldn't matter.
<abentley> asabil: bzr help send describes the "editor" mail client, which uses smtplib.
<asabil> okidoki, thanks for the input abentley
<strk> how can I compare two branches ?
<strk> the ideal outpu for me would be the same you'd get with 'status' (a summary of diffs) and the possibility to know more about something
<Odd_Bloke> strk: Try using "-r branch:<PATH>".
<strk> to status ?
<strk> bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction on KnitPackRepository('file:///home/src/gnash/avm2/.bzr/repository/')
<strk> write ?! it was bzr status -r branch:../bzr/trunk/
<Odd_Bloke> strk: That sounds wrong.  What's in ~/.bzr.log?
<luks> that should be fixed in recent bzr
<fullermd> That's a long-standing bug.
<Odd_Bloke> Ah, OK, I'd never seen it before.
<luks> 1.8 probably
<strk> this is Bazaar (bzr) 1.3.1
<fullermd> https://bugs.launchpad.net/bzr/+bug/144421
<ubottu> Launchpad bug 144421 in bzr "Using branch: revspec in stat blows up" [Undecided,Fix released]
<strk> uhm... diff branchA/file1 branchB/file1 # no diffs
<strk> branchA$ merge ../branchB # nothing to do
<strk> branchB$ merge ../branchA # conflicts in file1
<strk> any idea ?
<strk> seem the real difference in the conflict marker is just the amount of spaces used for indentation
<strk> questions are: 1) why 'diff' doesn't care ? 2) why merge in the two directions is different in catching that ?
<strk> uhm, on a closer look, there's really NO difference in the two files, so diff(1) is right
<strk> why does merge gets that conflict then ?
<Odd_Bloke> Hmm, I seem to have accidentally Planet Bazaar.
<Odd_Bloke> The whole planet.
<fullermd> "This sentence no verb"
<Odd_Bloke> (http://img165.imageshack.us/img165/189/1218062796760xd1.jpg)
<dobey> uhm
<dobey> riiiiiight
<strk> lol
<strk> Odd_Bloke: I'm laughing as a kid
<strk> silly stuff
<Ursinha> Odd_Bloke, LOL
<rocky> jelmer: hey... when i do a push of a revision back to a svn branch to a repo with 75k revs it does the "determining revisions" dance like 3 times ... each time it takes about 4sec or so
<_tsatbic_> Hi there ...
<_tsatbic_> I've got a type in a commit's message, is it possible to rename the message even after several other commits have been made?
<beuno> _tsatbic_, no, commits are immutabl
<_tsatbic_> thanks
<gary_poster> Hello.  Does anyone happen to have a buildbot hook for bzr (i.e., one that pings a buildbot master when a change is commited) that they would be willing to share?  Neither Google nor buildbot.net seem to show such a beast.
<jelmer> gary_poster: Hi
<gary_poster> hi jelmer
<jelmer> Afaik there isn't anything like that yet
<gary_poster> jelmer: ok thanks.  here I go then, I guess ;-)
<eyda|mon> is there anyway to get bzr to show me the relative paths of files when doing bzr st instead of the full path?
<eyda|mon> (a la git)
<rockstar> abentley, is a revid usually just <email-address>-<timestamp>-<randomness> ?
<beuno> rockstar, I think there's a sha1 hash in there somehow
<beuno> something related to the actual contents of the revid
<abentley> rockstar: Yes, the revids bzr itself generates are that.
<beuno> but that may be somewhere else
<abentley> beuno: There is nothing related to the actual contents of the committed tree in the revid.
<abentley> beuno: You may be thinking of revision testaments, which are used with GPG signing.
<rockstar> abentley, great.  That makes my job so much easier.
<beuno> abentley, I'm actually thinking of a hash that makes sure that the revision hasn't been changed
 * rockstar prefers that Old Testaments.  No GPG sig, but lots of funny stories.
<abentley> rockstar: importers like bzr-svn often do not follow bzr's practice.  The only requirement is that they be random.
<abentley> beuno: That's what testaments are for.  There's also a SHA hash in the revision XML.
<abentley> but it's a bad idea, and not reliable.
<beuno> abentley, the sha is what I was thinking of
<beuno> why is it not reliable?
<beuno> because of upgrades and such?
<abentley> Yes, format upgrades will update the inventory XML without necessarily updating the SHA1.
<beuno> gotcha, thanks for the explanation\
<abentley> beuno: Or at least that was the case.  It should be fixed in recent bzrs, but old revisions won't be fixed.
<abentley> lifeless: ping
<lifeless> abentley: just waking up
<lifeless> abentley: what can I do for you?
<abentley> lifeless: What causes PQM to die on "not enough arguments for format string"?
<lifeless> I think thats a new one
<abentley> lifeless: I'm not sure if you're aware, but bzr 1.9 has API changes that are incompatible with loom trunk.  Launchpad wants to use bzr 1.9.  So I'm trying to land lp:~abentley/bzr-loom/stuff on bzr+ssh://bazaar.launchpad.net/~Elaunchpad-pqm/bzr-loom/trunk
<abentley> lifeless: But it died with the aforementioned error.
<abentley> lifeless: A silent failure, not an email failure.
<rockstar> How do I get the config of a branch, if I have a setting for a branch in my bazaar.conf
<jelmer> rockstar: you mean something like Branch.open(url).get_config() ?
<rockstar> jelmer, does that return a bzrlib.config.Config object?
<jelmer> It returns a BranchConfig object, but that's based on a Config object IIUC
<rockstar> I thought I wanted BzrDirConfig, but BranchConfig looks better.
<jelmer> BranchConfig reads from .bzr/branch/branch.conf, locations.conf and bazaar.conf (not sure in what order)
<lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 534, in do_merge
<lifeless>     self.log_with_status(logger, merge_line)
<lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 428, in log_with_status
<lifeless>     self.branch_spec_handler.status.line(message % args)
<lifeless> TypeError: not enough arguments for format string
<lifeless> abentley: its a bug; let me have brekkie and I'll try to track it down
<abentley> lifeless: thank you.
<jfroy|work> :sigh: loggerhead has almost no documentation :|
<evarlast> it has source!
<evarlast> python is very readable, that is how I got lh running :)
<jfroy|work> I know, I know.
<jfroy|work> But I always look for the easy way out.
<jfroy|work> *easy way out first :p
<jfroy|work> Seems odd that they are pushing to move to serve-branches
<NfNit|oop> Hmm, is there not an option to create a branch w/o a working copy?
<jfroy|work> It seems a lot less flexible than the config file.
<dobey> NfNit|oop: bzr branch lp:foo bar
<dobey> or you mean create a branch on the server?
<NfNit|oop> a branch without a checkout.
<NfNit|oop> it's ok, I'll just branch then remove-tree
<verterok> NfNit|oop: if you have repository created with --no-trees, the branch is created without tree
<jfroy|work> bah, I can't make heads or tails of how to use --user-dirs with an Apache proxy
<NfNit|oop> verterok: right, I'm in a shared repo, but I've got trees for some branches, and wanted to create a branch as a sortof temporary tag to compare against some other revision.   Didn't really need to create a working tree for it.
<verterok> NfNit|oop: I don't think they can be mixed :/
<luks> NfNit|oop: you can compare against remote branches
<NfNit|oop> verterok: Well, I just did `bzr remove-tree`... so I hope they can be mixed. :p
<NfNit|oop> luks: Yeah, but that's slower than doing it locally. :p
<verterok> NfNit|oop: sure, but you must do a remove-tree :)
<NfNit|oop> verterok: mkay, that's fine. :)   I was just surprised at its absence.
<verterok> NfNit|oop: indeed
<abentley> NfNit|oop: If you really want to, you can create the branch over bzr+ssh (or sftp, ftp whatever your workstation has running).  Branches created over remote protocols don't get working trees.
<lifeless> jfroy|work: its less flexible in some ways, but its a lot easier for most folk to deploy
<lifeless> jfroy|work: the user-dirs thing is instead of using apaches' userdir mapping facility-> if you want host/~foo to be served by loggerhead
<lifeless> verterok: they should be mxable
<BrentH> Hi, I'm having problems with the initial brnach setup of Bazaar. Any bored volunteers? <g>
<BrentH> er branch
<lifeless> BrentH: sure, whats up
<BrentH> well, I'll give you the mini-background.
<BrentH> I've setup a project on Launchpad, and put ateam on the project...the problem is getting the initial code onto Launchpad
<lifeless> BrentH: what vcs is it in at the moment?
<BrentH> I'm an IT person, but Bazaar and Launchpad have made me feel really dumb. lol
<BrentH> it's not - brand new.
<lifeless> assume that its at /src/foo
<lifeless> cd /src/foo
<lifeless> bzr init
<lifeless> bzr add
<lifeless> bzr commit
<lifeless> bzr push lp:~$TEAM/$PROJECT/trunk
<BrentH> I should clarify - it didn't exist before...right now the initial code is only two files. The code is on a Win installation of Bazaar.
<BrentH> when I push it, I'm getting "error not a branch"
<lifeless> BrentH: have you run the commands I listed above?
<BrentH> yes. all were successful until the push
<lifeless> are you running push from within the directory?
<verterok> lifeless: yes, it's just I expressed it wrong (choosed poorly my words), what I meant was that a share repo can't create branches without tree if it's not a --no-trees repo.
<lifeless> abentley: I see the issue with pqm I think; the branch has % in it
<BrentH> ok, 1st problem solved...maybe
<BrentH> here's the thing...
<BrentH> I desire a directory under foo called new.   So foo/new...
<abentley> lifeless: Heh.
<lifeless>  File "/home/pqm/pqm/pqm/__init__.py", line 787, in run
<lifeless>     line='merge %s %s' % (self.from_branch, self.to_branch))
<lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 534, in do_merge
<lifeless>     self.log_with_status(logger, merge_line)
<lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 428, in log_with_status
<lifeless>     self.branch_spec_handler.status.line(message % args)
<BrentH> does it make a difference where I eventually deploy it? (I want to deploy to a virtual website dir)
<lifeless> BrentH: 'mkdir new'
<lifeless> BrentH: 'bzr add'
<lifeless> BrentH: 'bzr commit'
<abentley> lifeless: Looks like some pretty intentional string interpolation to me ;-)
<BrentH> I just now realized I had to commit from within "new"
<BrentH> duh
<lifeless> abentley: I'm only guessing at this point, but it seems plausible
<BrentH> but it gave me an auth error
<BrentH> ...on the password error
<BrentH> is it the same password as the private key?
<lifeless> BrentH: on push?
<BrentH> lifeless:yes
<lifeless> yes, it's your private key passphrase
<BrentH> lemme try again...
<BrentH> bad auth type again
<lifeless> can you show the exact error please
<lifeless> if its more than a couple of lines paste it on http://paste.ubuntu.com/
<BrentH> why do I sometimes need to use my screen name, and other times my full name?
<lifeless> for launchpad urls, its always the display name
<abentley> lifeless: I would interpret "display name" as "Aaron Bentley"
<abentley> lifeless: I've re-submitted without the %.
<lifeless> oh
<lifeless> BrentH: the short-name-with-no-spaces
<BrentH> first-last
<lifeless> abentley: thanks, I'll file a bug on pqm re this
<BrentH> 1sec
<BrentH> when I do the commit, it tries to use first-last instead of BrentH (scrn name)
<BrentH> don't know if that is the issue or not...
<BrentH> I'm using it to teach a class project, and thought this might be a cool way to do it
<lifeless> BrentH: the commits record email addresses as a globally unique committer identifier
<lifeless> the BrentH for url's on launchpad is just what launchpad has chosen to use as account names.
<BrentH> I set my email addy in cmd pmt
<BrentH> BrentH was the screen name I chose on launchpad
<BrentH> guess that doesn't matter
<BrentH> question: will this be too cpmplex for community college students to use for a one-off 1 month project?
<BrentH> yeesh...sorry about that
<lifeless> BrentH: not your fault ;)
<lifeless> BrentH: it should be fine IMO, there are only a few steps to basic usage
<BrentH> ok. should I email you acct un/pw to take a look?
<lifeless> BrentH: why? (I'm not sure what you're asking)
<BrentH> wasn't sure what be the easiest to troubleshoot
<BrentH> er what would be...
<BrentH> drat....brb
<lifeless> BrentH: is there still something wrong though?
<lifeless> bug 279381 is the one got you abentley
<abentley> Oh, did ubotu go away?
<lifeless> netsplit
<lifeless> 10K users gone :P
<abentley> lifeless: readdir?  Colour me confused.
<lifeless> abentley: https://bugs.edge.launchpad.net/pqm/+bug/297381
<ubottu> Launchpad bug 297381 in pqm "string interpolation fail" [Medium,Triaged]
<lifeless> transient dyslexic chaos reigned
<BrentHat> lifeless: hi
<NfNit|oop> BrentHat: hi
<BrentHat> ok, the distractions are gone. :)
<lifeless> BrentHat: hi
<BrentHat> I should have a block of time now if you can help
<lifeless> BrentHat: are you still having some problem?
<BrentHat> lifeless: yes, at the auth, even though I think it is the correct pw
<lifeless> BrentHat: can you paste the exact thing you see please
<BrentHat> C:\Documents and Settings\Brent\My Documents\windsortoastmasters.org\new>bzr pus
<BrentHat> h lp:~windsortoastmasters/windsortoastmasters/website
<BrentHat> Connected (version 2.0, client Twisted)
<BrentHat> SSH brent-hathaway@bazaar.launchpad.net password:
<BrentHat> Authentication type (password) not permitted.
<BrentHat> bzr: ERROR: Connection error: Unable to authenticate to SSH host as brent-hathaw
<BrentHat> ay@bazaar.launchpad.net Bad authentication type (allowed_types=['publickey'])
<lifeless> BrentHat: bzr doesn't know/have access to your private key
<lifeless> BrentHat: have you setup a private key and uploaded it to launchpad?
<lifeless> jml: also, why don't we support the users passphrase on b.l.n ?
<BrentHat> ok, makes sense. I uploaded a key to launchpad
<jml> lifeless: historical reasons.
<jml> lifeless: spiv may have a better notion of the history.
<BrentHat> lifeless: so does that mean each user has to work at a dedicated location, because of the key?
<lifeless> jml: I was there :) I don't think we ever had a good reason, just that we were not going to use the system db.
<lifeless> BrentHat: no, they can carry the key around with them
<lifeless> BrentHat: what you upload to launchpad was half the key
<jml> lifeless: then why ask me.
<BrentHat> lifeless: ok.
<lifeless> jml: because its your baby *now* :)
<lifeless> jml: and if you think its reasonable, I'll file a bug
<lifeless> BrentHat: its like a lock+key; the 'public key' is the lock, the 'private key' is the bit you carry around yourself and never give to someone else.
<NfNitLoop> BrentHat: Or, they can work wherever, then pull & push when they get to wherever their key is.
<BrentHat> I see my public key has been added at https://launchpad.net/~brent-hathaway/+editsshkeys
<BrentHat> so how do I assoc. the private key with bazaar?
<lifeless> BrentHat: I don't know windows well enough; sorry
<lifeless> one of the folk that use windows should be around in about 40 minutes
<lifeless> or it might be documented in the user guide
<BrentHat> there also aren't any .config files either tat I could find
<jml> lifeless: it's semi-reasonable, it won't get done any time soon
 * jml on a call that's demanding concentration.
<BrentHat> I'll try rtfm again then, lol.
<BrentHat> ok, since I have a bunch of "wrong" branches made at launchpad, is there a way to delete them at the site list?
<eyda|mon> is there anyway to get bzr to show me the relative paths of files when doing bzr st instead of the full path?
<lifeless> eyda|mon: not yet
<lifeless> BrentHat: go to the branch web page; there is a delete button there
<BrentHat> lifeless: it says the branch hasn't been imported yet. I don't see any button, but no biggie.
<BrentHat> lifeless: yay, found the conf files
<BrentHat> lifeless: there is a file called: ssh_host_keys   do I replace that file with my private key, and rename it to that?
<lifeless> BrentHat: no
<lifeless> BrentHat: you should put your private key in that directory
<BrentHat> lifeless: public, too?
<lifeless> doesn't matter
<BrentHat> grrr, no dice - same error
<lifeless> what file name does your private key have?
<BrentHat> privatekey.ppk
<poolie> hello lifeless, all
<BrentHat> hi poolie
<BrentHat> lifeless - should I recreate another set of keys?
<lifeless> BrentHat: no
<lifeless> BrentHat: try renaming the file to 'id_dsa'
<lifeless> hi poolie
<BrentHat> k
<lifeless> poolie: BrentHat here has some issues with lp auth on windows; is jam there ?
<BrentHat> lifeless: same
<BrentHat> thanks for the help, btw
<eydaimon> lifeless: plans for it though?
<eydaimon> lifeless: I end up doing bzr st; bzr diff ... then the path is all wrong :/
<eydaimon> lifeless: and I do that a lot
<lifeless> eydaimon: yes, plans for it
<eydaimon> good :)
<lifeless> eydaimon: 'bzr root' may help
<eydaimon> hmm, maybe. I'll keep that in mind. thanks
<BrentHat> authentication.conf:
<BrentHat> [Launchpad]
<BrentHat> host = .launchpad.net
<BrentHat> scheme = ssh
<BrentHat> user = brent-hathaway
<jfroy|work> is there a way to show a branch's public_url in Loggerhead?
<jfroy|work> There's no indication, as far as I can tell, to let people know from a loggerhead page how to branch the branch.
<jfroy|work> how to branch -> what URL to use to branch or checkout the branch
<beuno> jfroy|work, no, but if you file a bug, that can happen
<beuno> patches are also welcome!
<jfroy|work> Sounds good
<poolie> abentley: are you still around?
<poolie> want to talk about bug 288751
<ubottu> Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<ja1> BrentHat: do you have Pageant running?
<lifeless> BrentHat: rename the id_dsa file back to what you had it called before
<BrentHat> no, running only Tortoise Bazaar....
<jam> BrentHat: ok, you generated your .ppk file using putty, though right?
<jam> well, "puttygen"
<BrentHat> ok, renamed
<BrentHat> yes, thru putty
<jam> I'll give the quick rundown
<jam> if you load your .ppk file into puttygen
<jam> in the top box it has: "Public key for pasting into OpenSSH authorized_keys file"
<jam> which has some text
<jam> starting with "ssh-rsa"
<poolie> lifeless: anyhow let's talk here
<jam> you want to select that string, and copy and paste that into launchpad
<poolie> was just going to say i had some progress towards 288751, i wondered if aaron would come back to it but i guess not
<jam> BrentHat:  http://launchpad.net/+me/+editsshkeys
<poolie> i think you read my incremental patches?
<jam> https://edge.launchpad.net/people/+me/+editsshkeys
<jam> sorry
<BrentHat> jam: yup
<jam> ok, then once you have that uploaded
<jam> you need to either run Pageant and load the key manually
<jam> Start/Programs/Putty/Pageant
<jam> to start it
<jam> and then right-click and say "add key"
<jam> browse for the .ppk
<jam> add it
<BrentHat> i did that b4 - uploaded the public
<jam> Unfortunately, putty & pageant require you to add the keys manually on each boot
<jam> You'll probably also want to set Pageant up to start automatically
<jam> (I just copy the shortcut to Start/Programs/Startup)
<jam> BrentHat: feel free to ask me to clarify any of the steps
<BrentHat> ah, cool, 1 sec
<jam> BrentHat: I think there is another way that you can do it, so that bzr & paramiko can find the key without you running pageant
<jam> let me poke around for a sec
<BrentHat> ok, in the meantime, I'll try the commit again.
<jam> ok, if you load your key back into PuttyGen
<BrentHat> er: I'll try the push again
<poolie> [merge] NewPack constructor takes a PackCollection rather than a bunch of it's attributes <http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081112091450.GA7227%40sourcefrog.net%3E>
<BrentHat> Woo-hoo!!!! Auth successful!
<jam> Under "Conversions/Export OpenSSH key"
<jam> you can use that to create the "id_rsa" file
<jam> and put it in $HOME
<jam> which is typically
<jam> Documents and Settings/<username>
<jam> or Users/<username> (on Vista)
<BrentHat> not seeing conversions/export
<jam> BrentHat: In "PuTTYGen" ?
<BrentHat> ohhhh lol
<jam> In the menu, I have "File, Key, Conversions"
<BrentHat> got it! <g>
<BrentHat> I saved it in the 2.0 dir - with the other key - correct?
<jam> Not in the 2.0 dir
<jam> in "C:\Documents and Settings\<username>\id_rsa"
<jam> as the full path to the file
<BrentHat> k
<BrentHat> ok, done - should I test, and if so....how? lol
<BrentHat> yay, much happier now.
<BrentHat> ah geez, I just noticed there's till an error:
<arjenAU> poolie: morning - so you're in my town today?
<BrentHat> C:\Documents and Settings\Brent\My Documents\windsortoastmasters.org\new>bzr pus
<BrentHat> h lp:~windsortoastmasters/windsortoastmasters/website --use-existing-dir
<BrentHat> Connected (version 2.0, client Twisted)
<BrentHat> Authentication (publickey) successful!
<BrentHat> Secsh channel 1 opened.
<BrentHat> Using default stacking branch /~windsortoastmasters/windsortoastmasters/main at
<BrentHat> bzr+ssh://bazaar.launchpad.net/%7Ewindsortoastmasters/windsortoastmasters/
<BrentHat> Connected (version 2.0, client Twisted)
<BrentHat> Authentication (publickey) successful!
<BrentHat> Secsh channel 1 opened.
<BrentHat> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~windsortoastmasters/w
<BrentHat> indsortoastmasters/main/".
<BrentHat> further proof I am *newbie clueless*
<BrentHat> ok, so there is one bazaar branch listed as lp:~vcs-imports/windsortoastmasters/main and another listed as lp:~windsortoastmasters/windsortoastmasters/website
<BrentHat> and a third with a series of lp:windsortoastmasters series: trunk
<BrentHat> I'd like to do whatever is going to be the easiest, and I don't know which to delete from the site (although I do not see a delete button as lifeless had mentioned...drat)
<BrentHat> thanks jam for the help so far!
<jam> BrentHat: just a sec
<arjenAU> poolie: blip
<poolie> hello arjenAU
<arjenAU> poolie: so, in my town today was that right?
<poolie> yes, we are
<poolie> we're in the city
<poolie> would you like to meet, maybe for lunch?
<arjenAU> poolie: pm
<BrentHat> which timezone is everyone in?
<arjenAU> GMT+10
<BrentHat> I'm GMT -5
<BrentHat> It's cool that people from this project hang out IRL
#bzr 2008-11-13
<lifeless> GMT+11\
<jonoxer> Is it possible to use 'bzr diff' or 'bzr log' on a directory, rather than an entire branch or a single file?
<bob2> yes
<BrentHat> well, I am getting closer, so I thank you - hopefully I can make use of it properly before next week.
<jonoxer> bob2: maybe I didn't explain enough. Doing 'bzr log blah.d' shows just changes to the dir itself, not anything within it. With svn I can do "svn log blah.d" to get a log with all entries touching files in that directory
<Peng_> jonoxer: Right. I don't think there's anything you can do about that.
<jonoxer> Peng_: Ah, OK. Thanks
<bob2> jonoxer: hrm, sorry, I thought it did work for log.  certainly does for diff.
<jonoxer> bob2: No problem, I'm sure we can work around it. It's a bit of a problem in our release infrastructure at the moment because we build several hundred .deb packages from one source tree, and the changelogs are automatically pre-populated with entries from log entries for the particular directory for the module
<bob2> ah, neat
<Peng_> If you need to, I'm sure you could manage something with bzrlib.
<Peng_> Or send a patch to add a "--recursive" option to bzr log or something. ;)
<jonoxer> Peng_: I hadn't thought of that, I'd just been talking to one of the infrastructure guys about making a wrapper script that gets log entries for all files in a directory and intelligently merges / sorts the results, but that'll be kinda nasty
<Peng_> jonoxer: Won't that miss any files that have been deleted?
<lifeless> poolie: network loss?
<jonoxer> Peng_: yes, true
<jelmer> lifeless, that patch was indeed just for review, but you didn't give me any ! ;-)
<lifeless> jelmer: coming
<lifeless> poolie::
<poolie> mm?
<lifeless> python -m timeit -s "import bzrlib.branch
<lifeless> b = bzrlib.branch.Branch.open('.')
<lifeless> b.lock_read()
<lifeless> rh = b.revision_history()
<lifeless> rev1 = rh[200]
<lifeless> rev2 = rh[201]
<lifeless> " "inv1 = b.repository.get_inventory(rev1); inv2 = b.repository.get_inventory(rev2); list(inv1.id_to_entry.iter_changes(inv2.id_to_entry))"
<lifeless> 2.41 sec per loop
<lifeless> (first cut)
<poolie> ok, nice
<lifeless> also iter_changes isn't quite an entire diff
<lifeless> its just the selection of unique content in both sides
<lifeless> 2.4 seconds per revision in log -v would clearly be unacceptable; until this is hooked into e.g. diff though its a bit cumbersome to lsprof
<lifeless> back
<lifeless> ok
<lifeless> thats fixed :)
<lifeless> 10 loops, best of 3: 51.5 msec per loop
<lifeless> mtaylor: around?
<lifeless> real    1m55.129s
<lifeless> user    1m48.015s
<lifeless> sys     0m3.708s
<lifeless> bug 297457
<ubottu> Launchpad bug 297457 in bzr "bzr breaks Windows open/close dialogs in other applications" [Undecided,New] https://launchpad.net/bugs/297457
<lifeless> fun!
<Leefmc> Question: I have an issue where i am going to need to integrate with SVN.. and i really dont want to. Its not my call however, so i was hoping Bzr had some good ways to integrate with Svn. Allowing me to put out svn patches, merge patches, etc. Is this possible, and not painful, in Bzr? Or should i just dedicate and fully use Svn?
<bob2> bzr-svn
<lifeless> real    16m21.006s
<lifeless> user    15m27.894s
<lifeless> sys     0m2.828s
<Leefmc> bob2: Yea i saw that on google, but before researching a ton and finding it to be a painful, non-workflow-friendly, and generally poor experience, i wanted to ask about it.
<Leefmc> bob2: Is it indeed a decent workflow? Will it be horrible?
<bob2> it does what you asked, and lots of people seem very happy with it
<lifeless> time ~/source/baz/repository/bzr log -v -r -10..-1
<Leefmc> bob2: Ok thank you
<lifeless> the new format figures are:
<lifeless> real    1m55.129s
<lifeless> user    1m48.015s
<lifeless> sys     0m3.708s
<jonoxer> bob2: it basically lets you use bzr to talk to svn repos, so you can use bzr as a direct replacement for the svn client and still do local branching etc-
<Leefmc> jonoxer: Was that directed at me?
<jonoxer> Leefmc: oops, yes, sorry (and sorry bob2)
<Leefmc> jonoxer: Awesome, thanks.
<Leefmc> jonoxer: I was really worried, because i dont think i can go back to SVN heh
<Leefmc> jonoxer: Im addicted to distributed development :o
<abentley> poolie: Hi.  Did you still want to talk?
<poolie> hey
<poolie> not necessarily
<poolie> i'm planning to keep going with bug 288751
<ubottu> Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<poolie> so if you'd done something on it i wanted to make sure we didn't overlap
<poolie> i think i have a pretty good handle on it with other people here
<abentley> poolie: I haven't done anything on it.  I'm happy for you to continue working on it.  I'll look into the mega-slow-push bug instead.
<abentley> poolie: That is, after I get bzr-1.9 landed in rocketfuel.
<spiv> abentley: that appears to be at least partly bug 294479
<ubottu> Launchpad bug 294479 in bzr "Vast number of round-trips pushing stacked branch" [Undecided,Confirmed] https://launchpad.net/bugs/294479
<spiv> Although there's definitely too much history being examined via get_parent_map
<abentley> spiv: I found unreasonably large packs in the uploads directory of failed push attempts.
<spiv> what was the extension?
<abentley> spiv: .pack, IIRC.
<abentley> spiv: Case in point: bzr+ssh://bazaar.launchpad.net/%7Ethumper/launchpad/code-review-multiple-team-reviews/
<abentley> I moved the upload packs into backup.bzr.
<abentley> because that's the only directory it allows us to create.
<spiv> Right :)
<spiv> Or you could move it anywhere under .bzr...
<lifeless> poolie: so, this failing test you have, where can I grab it?
<lifeless> poolie: I have CHKInventory.iter_changes(CHKInventory) in basic form, need the interface tests to keep fleshing it out ...
<spiv> abentley: I don't think I can see the hostetd version of that directory
<lifeless> spiv: hitchhiker/
<spiv> lifeless: I see the mirrored version via bzr+ssh, not the hosted version, because I don't have write access to ~thumper's branches.
<abentley> spiv: Are you a member of Bazaar Experts?  If so, you can see hosted versions.
<abentley> spiv: Of anyone.
<spiv> I don't think I am, but maybe I should be.
<spiv> Nope, I'm not.
<poolie> lifeless: http://sourcefrog.net/tmp/20081113-brisbane-branchbuilder.diff
<abentley> spiv: Well, here's the money shot: uploads contained 8.8M dum57tlbe0ig0xna38tj.pack but packs only contained 2.1K 62f49775a9349c7b4b78bb3f1483b3f9.pack
<spiv> Hmm.
<spiv> How big is the working tree?
<abentley> spiv: It's launchpad.
<spiv> There was a merge of trunk in the new revisions, I think?  So maybe it was transferring a fulltext for every file that was touched, even by a merge revision.
<spiv> Even though those text versions were probably identical to ones already present in the stacked on branch?
<spiv> I believe stacking tends to transfer full texts (because even stacked pack collections should not have delta parents that do not exist in the collection), but generally it doesn't transfer many texts because only a small part of the tree is modified.
<abentley> spiv: It seems possible.
<abentley> spiv: At this point, I am not sure how much stacking honours that requirement to not have deltas between repos.
<abentley> spiv: It doesn't obey it 100%, because that's what poolie's fixing.
<spiv> Right.
<poolie> abentley: at the moment i'm changing the checks to also insist that inventory parents are there ; we only do it for texts atm
<abentley> Are you sure that this is the right approach?  It seems to me that even if we remove the dependency on the remote repo for modified files, we'll still need it for unmodified ones.
<abentley> And in both cases, we're retrieving fulltexts from it.
<poolie> 'this' meaning not having cross-repository-boundary deltas?
<poolie> yes, i am pretty sure
<poolie> firstly it's how that format is defined to work, it's just not always enforced
<poolie> but also, consider the case where the underlying repository has been upgraded and so the inventory deltas are no longre applicable
<abentley> poolie: You mean if the stacked-on repository deltas change?
<lifeless> abentley: no, if the stacked on repository representation changes
<lifeless> abentley: e.g. if the stacked on repository is upgraded to chk-inventory, how can we upgrade the stacking repository ?
<abentley> lifeless: Well, how do you deal it even if there are no deltas?
<lifeless> you reconstruct the inventory in the stacking repository, convert to a chk inventory, and write it out to the upgraded stacking repository
<abentley> lifeless: So it seems like you could use a similar approach, and then apply the deltas to it.
<lifeless> abentley: how would you apply a text delta though?
<lifeless> abentley: note that what I described did not need to access the stacked on repository
<abentley> So we have text deltas in the stacked repo and chk in the stacked on?
<abentley> generate the CHK inventory, convert to XML, serialize, apply deltas.
<lifeless> abentley: that seems rather more complex than just asserting that we won't text-delta across repository boundaries
<abentley> lifeless: If you've got an XML repo stacked on a CHK repo, you're going to have to do that for inventories anyhow.
<abentley> For the revision only present in the stacked-on repos.
<abentley> We already do this kind of thing when applying bundles, after all.
<lifeless> abentley: no, you don't have to do it if you have no deltas crossing repo boundaries
<lifeless> we're talking line-deltas, not inventory deltas
<abentley> How are you going to support Repository.get_inventory_xml on a repo that's stacked on a CHK repo?
<lifeless> abentley: I imagine it will have to do what bzr-svn does (serialise using an arbitrary xml serialiser)
<lifeless> abentley: but that shouldn't be called at all often
<abentley> lifeless: So you already need most of the complex code anyway.
<lifeless> abentley: I'm not sure why that makes it more desirable
<abentley> lifeless: Anyhow, none of this applies to texts, which never change representation.
<lifeless> abentley: they don't yet; what about the big-files discussions we've been having
<lifeless> well, I guess you can get a flat form out if needed
<lifeless> I still don't see it being feasible making it desirable; it sounds like you think its desirable to have deltas point across repository boundaries?
<abentley> lifeless: iter_files_bytes is compatible with big-files.
<abentley> lifeless: I think that smaller repos and faster pushes are a win, and I think the cross-format case is an edge case.
<lifeless> abentley: cross-format is one case; its not the only way things can/will go pear shaped
<lifeless> git has excellent network performance - its users swear by it - and it *never* sends a delta in a network operation unless the basis is also being sent at the same time.
<abentley> lifeless: Fair enough.  I'm starting to fade.  Another time perhaps.
<lifeless> ok, sleep well
<lifeless> you get snow yet ?
<abentley> lifeless: Not here.  We got some at the epic.  g'night
<lifeless> vila: bzrlib/tests/intertree_implementations/__init__.py
<vila> I'm there
<lifeless> see how PreviewTree is hooked in?
<vila> end of load_tests ?
<lifeless> CHKInventory trees don't have a specific InterTree subclass - like PreviewTree
<lifeless> yes
<lifeless> so we need to do the same thing that is done for PreviewTree - we want to append a permutation for CHKInventory
<vila> meh
<lifeless> ?
<lifeless> vila: so, InterTree is the class that implements Tree.iter_changes(other_tree)
<lifeless> vila: CHKInventory.iter_changes(CHKInventory) is the guts we want to use when someone does RevisionTree.iter_changes(RevisionTree) when both revision tree objects have a CHKInventory
<lifeless> vila: intertree_implementations has the interface conformance tests that enforce correct behaviour of tree.iter_changes(tree)
<vila> ham yes, that's the part I was missing
<lifeless> vila: so the goal is to have a scenario, with RevisionTree[with CHKInventory].iter_changes(RevisionTree[with CHKInventory])
<lifeless> vila: my mega-hack causes the guts I wrote to be used, but there is nothing testing that the guts meet the upper level interface (and I know they don't for e.g. specific-file diffs etc)
<vila> right, so first thing is looking at test failures (if any)
<lifeless> vila: first thing is getting the tests to run against the code :)
<lifeless> vila: second thing is looking at test failures
<vila> so the *actual* tests don't use your mega-hack or they do ?
<lifeless> vila: they would, IF they ran with a pair of trees that were both RevisionTree[with CHKInventory]
<lifeless> vila: which is why we need to add another entry to the parameterisation list
<vila> yeah, so tell me, because with 5 parameters for the permutation I have large chances to choose a wrong combination :)
<lifeless> vila: ok, well we had the diversion to make it clear to you :)
<lifeless> vila: is the reason why - and the goal - clear now ?
<vila> lifeless, reason and goal yes,
<lifeless> ok, cool
<lifeless> so, the how
<lifeless> the parameters are - name, optimiser class, tree format to use for the basis tree, tree format to use for the working tree, converter to use to convert trees from working trees to test trees
<vila> what is a test tree ?
<lifeless> it is a tree for testing with, as opposed to a tree that we use to build up the shape of the tree
<lifeless> e.g. to test dirstate we need a DirstateRevisionTree as the basis
<lifeless> but a dirstate revision tree is immutable
<lifeless> so we use a mutable tree to construct the content the DirstateRevisionTree should have, and then we call a converter which does a commit and returns the basis tree - a DirstateRevisionTree
<vila> oh, so test trees are really the basis trees
<lifeless> (waiting for ack when you have absorbed this - look at the code in bzrlib/tests/intertree_implementations/__init__.py bzrlib/tests/intertree_implementations/test_compare.py and bzrlib/tests/tree_implementations/__init__.py
<lifeless> vila: they are the trees used for the test; different scenarios will use different converters
<vila> ok
<vila> So the first permutation added could be RevisionTree[with CHKinv] against another RevisionTree[with CHK] or are theses test already done elsewhere ?
<lifeless> that is exactly the permutation we need to add
<vila> pfew, i wasn't totally lost then :0)
<lifeless> no, they are not tested elsewhere, thats the point of this exercise to get them tested :)
<lifeless> I have a partial patch for you ...
<lifeless> interesting, it found bugs in the current behaviour of InterTree(RevisionTree, RevisionTree)
<lifeless> vila: http://paste.ubuntu.com/71227/
<lifeless> vila: this is *nearly* what you need to get going
<lifeless> vila: what it doesn't do correctly yet is to use a --development3 format rather than a --default format
<lifeless> vila: shorter version
<lifeless> http://paste.ubuntu.com/71229/
<vila> sooo, i need a mutable_trees_to_chk_trees helper ?
<lifeless> no
<lifeless> we just need to make make_branch_and_tree generate --development3 formats
<lifeless> though we *could* do it by having a different helper
<lifeless> vila: rev 3771
<lifeless> vila: running ./bzr --no-plugins selftest CHK chk_map -1
<lifeless> vila: so, you have the code ? :)
<lifeless> the problem generally isn't *sending* the packets out to the internet
<lifeless> its generally that the server is sending a big reply, with DF set, and then either a) the ISP not sending ICMP-WF to the server, or b) a firewall at the server end filtering the ICMP-WF
<spiv> lifeless: we were seeing it both on a large get_parent_map request, but also on a large append.
<lifeless> setting MTU works because it sets a starting point for the MTU negotiation that is below the actual MTU and thus even though DF is set it never triggers
<poolie> right
<poolie> so it's not just the maximum his client will send, but it's also advised to the server
<lifeless> right
<vila> grr, too small screen, just catching up
<spiv> And append requests have small replies, so it appears that in this case sending packets was the problem.
<poolie> i wonder if his mac os has a firewall installed that filters the virtual nic
<lifeless> spiv: could well be; could be the VM environment, or hotel, or lots of things
<lifeless> poolie: ;)
<spiv> Yeah.
<poolie> that might account for it being just him
<poolie> or bad luck
<lifeless> its a twitch-smell for me now though - hanging network, pmtud blackhole.
<poolie> according to wp, ethernet is 1500 mtu
<poolie> i think there are 40 octets of wrapping
<spiv> lifeless: right, me too
<vila> well, no firewall on the mac, but the VM is NATed...
<lifeless> poolie: ethernet frame size is 1500 IIRC
<lifeless> I'm going to check though, cause I thought it was 1512/1514 physically
<poolie> there's 1500 of payload, 14 header, 4 trailer, and i think also a lower-level prelude
<lifeless> ah yes 1520
<lifeless> that number rings large bells
<lifeless> so yes, 1500 MTU at the ip layer
<poolie> ah ok, the client's mtu gets put into the mss option of the tcp syn packet
<lifeless> vila: pulled ?
<vila> :-/ Neither pull nor missing seems to work anymore :-(
<lifeless> !
<vila> eeerk, john and spiv were right, just network slowness 8-(
<lifeless> awesome
<vila> lifeless, here we are... ./bzr selftest --no-plugins -s bt.intertree CHK failing a lot :) Yum
<lifeless> lsprof is saying that seek is 20% of st -r -2..-1
<lifeless> vila: ok
<lifeless> vila: we have 40 minutes to pair on this
<vila> 46/60 failures :)
<vila> lifeless, ok, I;m at tree.py line 866
<vila> for the first failing test which is intertree_implementations/test_compare.py(130)test_content_modification()
<lifeless> vila: ok, so its starting to go down my fast-path ;P
<vila> yup, in iter_changes now (the CHK version)
<lifeless> vila: so, its expected back 'a', and its getting 'a', 'b', and 'c' all modified
<lifeless> ah no
<vila> no it expected nothing
<lifeless> its expected an empty list for the unchanged set
<vila> there a re two things I don't understand
<vila> 1) iter_changes shouldn't return unchanged items...
<vila> 2) iter_changes shouldn't return unchanged items...
<lifeless> 'include_unchanged=True' -> iter_changes returns unchanged items
<vila> :)
<vila> ha, ok
<lifeless> but, is include_changed true in this case?
<vila> is that a parameter for iter_changes ? Cause there is no such param there :)
<lifeless> vila: it is a parameter for Tree.iter_changes
<lifeless> remember CHKInventory.iter_changes is *incomplete*
<vila> should I add that parameter then >
<lifeless> if it was finished you wouldn't be looking at these tests:)
<lifeless> well
<lifeless> you should figure out what is going wrong
<vila> sure, no problem
<lifeless> I would start
<lifeless> by not running TestCompare
<lifeless> ./bzr --no-plugins selftest IterChanges.*CHK
<lifeless> will give you lower level tests
<vila> lifeless, ok, I take notice :) I'll play a bit more with that one, just to become familiar with the stack, and switch to iTerCHanges.*CHK just after :)
<vila> include_unchanged is indeed false
<lifeless> TREE_ROOT being included is likely going to be visible, because currently CHKInventory doesn't know that its a non-rich-root/rich-root
<lifeless> my poor machine, thrashing so bad fetching mysql revs
 * vila knows the mysql make my machine trash feeling :)
<lifeless> ok, autopacking is not really an issue here -
<lifeless> 1637.168  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x143e5d0>, which has 16 pack files, containing 14041 revisions into no more than 10 packs.
<lifeless> 1674.764  Auto-packing repository %s completed
<LarstiQ> string interpolation yay
<lifeless> 30s, not ideal, but nothing compared to the 16K that have gone by
<lifeless> LarstiQ: yah, forgot a mutter param, fixed in the tree
<stub> I think https://bugs.launchpad.net/bzr/+bug/258349 is WONTFIX
<ubottu> Launchpad bug 258349 in bzr "Special character "Ã" cannot be used in the commit message." [Low,Triaged]
<Kamping_Kaiser> isnt that $EDITORs issue?
<Peng_> It's INVALID, not WONTFIX, though the issue with the wording on the WindowsDownloads page is legitimate.
<Peng_> (Well, I'd call it INVALID. I don't know what the usual Bazaar policy is. But not being able to use Unicode when your charset is set to ASCII si not a bug.)
 * Peng_ goes back to being /away
<tga> hello
<tga> I'm having a bit of trouble with `bzr ignore`
<tga> I want to add the current dir to bzr, but without the /bin and /obj subdirs.. bzr init, bzr ignore /obj, bzr ignore /bin, bzr add *
<tga> this also adds all the stuff under /bin and /obj
<tga> I also tried bzr ignore bin, without the /
<tga> hah, right, `bzr add`, without the *
<tga> thanks for the inspiration :)
<bob2> '*' gets expanded by your shell to all (most of) the names in the dir, bzr's ignore list only affects implied names
<tga> yeah, I figured it out after trying to bzr ignore obj/* and getting a long list of stuff in .bzrignore
<awilkins> Anyone know how to make urllib ignore a proxy?
<awilkins> Specifically, on win32 where there are IE proxy settings I wish to ignore them and go direct.
<awilkins> Is there a value of the HTTP_PROXY environment variable that will produce this behaviour?
<eleftherios> Switching from subversion to bzr (and it feels like a joy), when I push changes to a dir on the server (it's a web app) I get the warning, This transport does not update the working tree of: sftp://<URL>. I pushed the branch up there using bzr push --create-prefix sftp://<URL> as per http://bazaar-vcs.org/BazaarForWebDevs. What is it exactly with the warning?
<Odd_Bloke> eleftherios: So in bzr there are three objects you need to be aware of.  The repository, where revisions are kept, the branch, which is essentially a location and a pointer to a revision in a repository, and a working tree, which is a physical representation of a branch.
<Odd_Bloke> What 'bzr push' gives you is a repository and a pointer at that URL to the correct revision in it.
<Odd_Bloke> What it doesn't do is give you a physical representation of the contents of that revision.
<Odd_Bloke> Which, in essence, means that people will be able to branch from that URL but won't see the contents of the revision.
<Odd_Bloke> (Won't see the contents of the revision when they look at that URL).
<Odd_Bloke> Am I making sense?
<eleftherios> Hm
<eleftherios> Odd_Bloke: No, I can't say I understand. :-/
<Odd_Bloke> eleftherios: For example, http://bzr.daniel-watkins.co.uk/wnpp-bg/ is a branch without a working tree.
<Odd_Bloke> If you point your browser at it, you can't see anything.
<Odd_Bloke> But if you 'bzr branch http://bzr.daniel-watkins.co.uk/wnpp-bg/', you'll get a bzr branch.
<Odd_Bloke> So 'bzr push' puts all of the data there, but doesn't check it out.
<Odd_Bloke> I'm not being very clear, sorry.
<eleftherios> so if I push rev5 there, it will have the data but will stay in say, rev3? (Which was the original rev when I did the bzr push --create-prefix)?
<Odd_Bloke> eleftherios: No, it will update the branch to point at revision 5.  But if there is a checkout there, the contents checked out will still be those of revision 3.
<eleftherios> Now I am even more confused!
<Odd_Bloke> eleftherios: Sorry, I'm over-complicating this.
<eleftherios> What have I done wrong? I went into my clean project directory, I did bzr init, then bzr add, then bzr commit -m "xxx"
<eleftherios> then I pushed that on the server with bzr push --create-prefix ...
<eleftherios> and I am updating the server with bzr push
<Odd_Bloke> You have a branch, which is a series of revisions.  You also have a checkout of that branch, which is where the work happens.  When you do that 'bzr commit', bzr takes the changes from the working tree, creates a new revision and updates the branch.
<eleftherios> the branch and the checkout of the branch are the same dir at the moment
<Odd_Bloke> Essentially, yes.
<eleftherios> I had foo/ I got in there and did bzr init && bzr add && bzr commit -m
<eleftherios> I would like to have something like foo/branches foo/trunk foo/tags but I am not sure this is the right way to use bzr
<Odd_Bloke> eleftherios: It's not. :)
<eleftherios> so I just use bzr branch foo foo.newbranch and work like that
<Odd_Bloke> Yes.
<eleftherios> ok, so what else do I need to know? :-)
<eleftherios> and what is that warning I get?
<Odd_Bloke> That warning is just saying that push updates the branch (i.e. stuff in .bzr) but not the working tree.
<Odd_Bloke> Because updating the working tree is more complex, and you don't want it happening automagically.
<eleftherios> what is the working tree Odd_Bloke? :-)
<eleftherios> I am reading through http://bazaar-vcs.org/SharedRepositoryTutorial now...
<Odd_Bloke> eleftherios: It's the files you see that aren't in .bzr.
<Odd_Bloke> It's created from the files within .bzr.
<eleftherios> Odd_Bloke: the files that I see that aren't in .bzr?
<eleftherios> Odd_Bloke: what are these files then?
<awilkins> Your files that you are versioning?
<eleftherios> the actual project files then
<awilkins> Yes
<eleftherios> foo/baz.py etc. But these do get pushed and updated when I do bazaar push
<awilkins> It doesn't update those over a push via certain remote protocols because it's i) more complex than pushing revisions ii) costly in terms of bandwidth
<eleftherios> I get the warning, yet the files do get pushed and updated though...
<awilkins> eleftherios: Are you basing your assertion on the output of `bzr st` in the remote branch?
<awilkins> eleftherios: If the files are being updated it would seem that the message is in error and needs fixing (either so that the behaviouir is correct again or that the message is fixed)
<eleftherios> awilkins: I actually see the changes on the server
<awilkins> You are pushing via sftp://  ?
<eleftherios> I change foo/baz.py in the local branch, I commit, I push and then baz.py is updated on the server too
<eleftherios> awilkins: yes :-)
<awilkins> eleftherios: Are you running some kind of push-and-update hook?
<eleftherios> This transport does not update the working tree of: sftp://<URL>.
<awilkins> eleftherios: And what method are you using to look at foo/baz.py after you push?
<eleftherios> awilkins: yes, I have installed the plugin push-and-update as per http://bazaar-vcs.org/BazaarForWebDevs
<awilkins> eleftherios: Right, what that does is use ssh to execute "bzr up" on the branch after it pushes
<awilkins> eleftherios: Push is not aware of this, so it still gives you the warning
<eleftherios> awilkins: oh here we are, I then get running "ssh <user>@<domain> bzr update "/path/on/my/server"
<eleftherios> I see
<eleftherios> ok, so now, the shared repositories are just directories where the actual project files are stored only once and shared between branches?
<eleftherios> or something like that?
<eleftherios> "Each branch will share the repository for its revision storage."
<awilkins> Yes
<eleftherios> Ok, I get it now :-) So its benefit is that you use less disk space, any other benefits?
<awilkins> This means you can create additional branches with minimal resource consumption ; standalone branches would copy the entire set of revisions
<awilkins> Faster, obviously
<eleftherios> awilkins: but no difference in merging etc
<awilkins> eleftherios: No
<eleftherios> (because that was my pain with bloody svn)
<eleftherios> awilkins, Odd_Bloke thank you very much :-)
<awilkins> `bzr switch` becomes more useful with shared repos
<Odd_Bloke> eleftherios: No worries.
<awilkins> Specifically, a no-trees repo from which you check out working trees
<eleftherios> I need to read up on trees etc
<tga> what exactly is the difference between trees and no trees?
<eleftherios> Not everything is clear in my head yet
<tga> yeah, me too
<awilkins> no-trees means that the repository is just that - a repository of branches that have no working files, just revisions and metadat
<eleftherios> and by the way, I know Trac has a bzr plug-in but is there another similar tool for bzr guys?
<eleftherios> awilkins: and where do the working files go?
<tga> ah, so a no-trees repo alone is useless
<tga> you need the actual files
<awilkins> Yes, you use your no-trees repo and make a lightweight checkout from one of the branches in it
<awilkins> A lightweight branch is the closest Bazaar gets to an SVN working copy (although it's ligher, no pristine copy of the files therein)
<eleftherios> awilkins: thank you
<awilkins> eleftherios: Loggerhead is a Bazaar branch viewer, but I don't think there is anything that covers all the bases that Trac does for Bazaar yet
<eleftherios> awilkins: anything in the works maybe?
<eleftherios> ugh, built on TurboTears
<lifeless> eleftherios: there is a bzr-trac plugin for trac
<lifeless> and also abentley's embryonic cart; now abandoned I think
<LeoNerd> I tried bzr with trac.. it's paaaaainfully slow
<eleftherios> oh is it
<eleftherios> It would be nice if someone made something with modern technologies, like Pylons + SQLAlchemy fron-end project management thingy for bzr
<LeoNerd> Well, I don't think this is bzr related... even the non-bzr parts were slow.
<eleftherios> oh ok
<LeoNerd> so I've now given up on that and am working on some integration with my existing web framework. 'cept that's all in perl, so I'm having fun using perl's Inline::Python :)
<eleftherios> :-)
<Peng_> What uses TurboGears?
<Peng_> Loggerhead doesn't.
<Peng_> FWIW, Redmine supports bzr, but I don't know how well.
<lifeless> lh isn't really that tg centric
<lifeless> its just wsgi
<Peng_> It's not tg at all.
<eleftherios> Peng_: that's what the site writes => "The primary difference is that loggerhead is built on top of TurboGears." At http://www.lag.net/loggerhead/
<eleftherios> That's where I based my comment :-)
<Peng_> eleftherios: It used to be TurboGears, but they moved to Paste a few months ago.
<eleftherios> Awesome :-)
<Peng_> eleftherios: Also, https://launchpad.net/loggerhead is its current home.
<eleftherios> Peng_: running it now, looks really nice
<thrope> which version of loggerhead do I use for bzr 1.9?
<thrope> is the 1.6.1 release OK?
<thrope> is there any documentation for installing loggerhead?
<thrope> also is there any documentation for installing bzr on centos - the repositories suggested on the web page only have 1.3
<thrope> i am having trouble installing celementtree since it conflicts with elementtree which yum depends on
<ushimitsudoki> is there a way to stop bzr from asking for a passphrase when I "bzr push lp:"?
<Peng_> ushimitsudoki: SSH keys?
<ushimitsudoki> Peng_: I guess i don't know how to automatically allow bzr access to my ssh keys - I think that is what i am after
<Peng_> ushimitsudoki: What OS are you on?
<ushimitsudoki> Peng_: ubuntu 8.10
<Peng_> thrope: FWIW, installing Loggerhead for me was just "unpack and run serve-branches". (I should set up the init script!)
<thrope> I'm having trouble installing celementtree on centos
<Peng_> celementtree conflicts with elementtree? Your packager is wrong.
<thrope> oh well
<thrope> centos is really a pain
 * Peng_ waves an Ubuntu flag. :P
<Peng_> ushimitsudoki: I'm sure bzr is finding your ssh keys, then, if you have them set up properly (~/.ssh...). Have you put your public key on Launchpad?
<ushimitsudoki> Peng_: yes i have it on launchpad, it's just when i push up a revision to launchpad, i have to "Enter passpharase for key '/../.../id_rsa'
<Peng_> ushimitsudoki: Oh.
<Peng_> ushimitsudoki: That's because you put a password on your SSH key. Run ssh-agent if you don't want to have to enter it constantly.
<ushimitsudoki> Peng_: ah thank you i will check that out
<Peng_> ushimitsudoki: If you're on Ubuntu, it should be running already. Run "ssh-add", enter your password, and there you go.
<Peng_> (Well, it's running already for me..)
<ushimitsudoki> Peng_: and you appear to be correct, sir! Thanks much!
<Peng_> :)
<thrope> Peng_: unfortunately the centos people tell me that they do conflict (celementtree and elementtree) and it appears to be impossible to have them both on the same system
<thrope> and since yum (the package manager) requires elementtree - it doesnt seem possible to intall bzr on centos
<Peng_> I have both installed on my Ubuntu system right now, and the universe hasn't imploded, so I daresay it's possible.
<Peng_> thrope: You don't *need* cElementTree for bzr. ElementTree is enough; it's just slower.
<Peng_> (A lot slower. But bzr would still /work/.)
<Peng_> thrope: BTW, do you have Python 2.5?
<thrope> no its 2.4
<thrope> I thought 2.4 was OK?
<hmeland> 2.4 is OK, but 2.5 comes bundled with cElementTree.
<lifeless> 2.4 is ok
<Peng_> Yeah, what he said.
<lifeless> as hmeland says
<lifeless> thrope: the centos people are wrong :P
<lifeless> thrope: celementree is a C extension for elementttree, it's not standalone
<thrope> actually I found this on the celementtree page "Note that some distributors have included cElementTree in their ElementTree package."
<thrope> so I'm hoping its in there and that explains the conflict
<Peng_> thrope: Run "python -c 'import cElementTree'" to check.
<thrope> doh, how obvious
<thrope> yes it seems to be there
<lifeless> hmm
<lifeless> I need to get bzr-search CHKInventory enabled
<thrope> is it ok to use loggerhead 1.6 releas with bzr 1.9, or should I pull the trunk
<lifeless> thrope: should be fine
<lifeless> thrope: but its been a while since lh released, so if you have trouble grab the trunk
<lifeless> yay finally, revno 2K of mysql with a split-inv repo
<Peng_> This may be a stupid question, but would bzr-search benefit from btrees?
<thrope> of course centos doesn't have simpletal or paste
<lifeless> it only took 22254 seconds
<Peng_> Hmm..does "bzr branch" copy over search indexes too? Should it?
<lifeless> Peng_: yes; I have a alpha branch with that; I need to implement a helper/subclass for -s support
<lifeless> Peng_: it doesn't, it shouldn't
<Peng_> Heh, okay. Why not?
<lifeless> indexing is fast :>, network is expensive
<Peng_> Ah.
<lifeless> seriously, I'm seriously proud of index performance
 * beuno is reminded we need an "auto-index" feature for bzr-search in LH
<lifeless> beuno: I still don't think that that is a LH issue
<Peng_> Please make such a feature optional. Indexing large branches kills me VPS.
<beuno> Peng_, yes, completely optional
<Peng_> Err, my*
<lifeless> Peng_: yes, your memory issues :P
<Peng_> lifeless: :(
<lifeless> Peng_: btrees help there; also ratcheting down the batch size
<beuno> lifeless, who else would handle indexing the branches LH serves?
<Peng_> beuno: I wrote a little script and run it occasionally.
<lifeless> Peng_: split inventories will reduce the benefit to large batch size too, which means I can reduce it and your memory issues will be reduced
<lifeless> Peng_: you know bzr auto-updates an index once it has it
<lifeless> beuno: well; I think there are several factors; just running lh on a branch isn't enough to say to me, the user wants this indexed.
<lifeless> beuno: bzr could do with a policy on what to auto index, for folk that dont use lh
<beuno> lifeless, sure, I want it to be a flag for server-branches, like  --auto-index or something
<lifeless> beuno: barry tried bzr-search today; claimed to be deleting grep afterwards :)
<beuno> heh, I can sure understand that!
<lifeless> beuno: once an index is created, all write operations add to the index
<Peng_> How much RAM does it take to index a copy of bzr.dev?
<beuno> lifeless, yeah, I know that much, it's just the initial indexing that's a PITA
<lifeless> Peng_: one sec, I'll see
<Peng_> Ehh, I can check myself.
<thrope> I get ImportError: No module named pkg_resources with loggerhead
<beuno> however, if it could be done in bzr-search, maybe that would work as well
<lifeless> beuno: and I think the last thing we want is to make a web ui do an initial index
<lifeless> beuno: much better to have the first bzr push leave the server indexing after the client disconnectes
<beuno> ok, that's true
<lifeless> [for instance]
<beuno> then I'll rephrase: /me is reminded he has to look into adding an auto-index option to bzr-search   :)
<lifeless> beuno: that would be nice
<beuno> yeah, I've been wanting to contribute a few more things to bzr-search, I have a tomboy note with 'em somewhere
<beuno> anyway, off to barry's for more planning on taking over the world (of open source)
<beuno> bbl!
<Peng_> "tomboy note"?
<lifeless> beuno: show him lh w/bzr-search
<lifeless> Peng_: desktop notes
<beuno> lifeless, yes, I've been luring him in so we add it to code.python.org/loggerhead
<lifeless> beuno: right, its just now he's seen search in CLI :)
<beuno> lifeless, yes, that was me luring him in  ;)
<Peng_> "desktop notes"? As in a scrap of paper, or a piece of software I don't know about?
<lifeless> beuno: also ...
<beuno> Peng_, software
<Peng_> OK :)
<lifeless> 09:10 < barry> lifeless: i just heard about that yesterday and haven't had time to try it yet :)
<beuno> sudo aptitude install tomboy
<lifeless> 09:10 < barry> lifeless: but i'm eager to fill that cup of awesome
<lifeless> 09:15 < lifeless> barry: do it!
<beuno> lifeless, yes, I was behind that!
<lifeless> Peng_: a desktop organiser
<lifeless> beuno: well, good work :)
<beuno> lifeless, I'm your biggest fan  ;)
<lifeless> Peng_: wiki-like, but not html display, gtk window display
<fullermd> I glanced past tomboy the other month.  Looked vaguely interesting.
<beuno> fullermd, you should be in sales
<fullermd> I know.  It's a gift of mine.
 * beuno -> barry's
<thrope> does auto_publish_folder in loggerhead recurse? Ie can I just point it to ~/bzr and it will pick up ~/bzr/project/brancha for different projects and branches
<thrope> where does configobj come from?
<thrope> oh got it
<lifeless> thrope: best to use 'serve-branches' rather than logger.conf
<lifeless> serve-branches DoesTheRightThing
<thrope> lifeless: but I want to go through apache
<thrope> can I still use serve-branches
<Peng_> thrope: Yes
<jbl1> Hello all, would anyone be able to tell me if the concept of "branch locking" is applicable to bzr? Documentation search revealed nothing.
<lifeless> jbl1: what do you mean by that concept ;P
<jbl1> well, in some cases under CVS, you could create a file called 'cvs.lock' in the repository, which would revent any further commits to it, essentially locking the branch
<jbl1> revent=prevent
<Peng_> jbl1: You can't do that in bzr.
<Peng_> I guess you'd just chmod it read-only?
<w00t_> hmm. I used bzr fast-import to import a repo, and I seem to have no checked out files in my branches, is there a way I can populate them so I can use it as a working copy?
<Peng_> w00t_: "bzr co"
<jbl1> Yeah I considered that permissions option as well, looks like thats the way to go
<w00t_> Peng_: but that would involve another copy off this, wouldn't it?
<Peng_> w00t_: Run "bzr co" in the branch. That'll create a working tree.
<w00t_> nope. it tells me '.bzr' in that branch already exists
<Peng_> w00t_: Just "bzr co"? No other arguments?
<w00t_> Peng_: yes
<Peng_> ...Huh.
<Peng_> w00t_: Oh. It says that if there already is a working tree.
<Peng_> w00t_: Try bzr up and bzr revert.
 * Peng_ shrugs
<Peng_> That's a bad error message. :\
<w00t_> bzr up worked
<w00t_> and gave me a tree
<jelmer> beuno, is there some easy way to run loggerhead inside of apache/
<jelmer> ?
<beuno> jelmer, yes, something about pastedeploy
<beuno> which should be in the README
<jelmer> ah, thanks
<Peng_> If you want it to run at the / of a domain, you probably don't even need that.
<jelmer> Peng_: Why would that be different?
<Peng_> If you want to run it at e.g. /bzr/loggerhead/, you need the Paste Deploy PrefixMiddleware stuff so it knows how to treat that part of the path.
<Peng_> Otherwise, whether or not you're proxying to it from something, you don't.
<lifeless> jbl1: you can also lock the branch, but thats considered a transient state, not a long term state
<Peng_> And it's easy to break locks anyway.
<Peng_> Well heck, if you have write access, no locking can stop you...
<Peng_> But anyway..
<jelmer> Peng_, with mod_proxy you can also have it rewrite the URLs, etc
<jelmer> I'd just like to keep this as simple as possible
 * Peng_ shrugs
<Peng_> PrefixMiddleware is very simple.
<lifeless> jelmer: serve-branches --prefix=/bzr/loggerhead
<lifeless> jelmer: thats all
<thrope> I'm having a lot of trouble getting loggerhead to work through apache ssl
<thrope> both with config file and with server branches
<thrope> is there any documentation for that?
<thrope> witht he config file I got as far as the front page (project list) but with serve-branches I can't get anything (just get not found)
<thrope> I am running /serve-branches --port=8999 --prefix=/bzr /home/robince/bzr/pyentropy/tests/
<thrope> and it works directly
<thrope> but not through the apache proxy
<lifeless> thrope: details needed about what '~not works' means for you
<thrope> where I have <Location "/bzr"> ProxyPass http://127.0.0.1:8999/  ProxyPassReverse http://127.0.0.1:8999/
<thrope> well at the moment with serve-branches I get a not found error
<thrope> although the request shows up in the serve-branches stdout debug
<lifeless> 404?
<thrope> 127.0.0.1 - - [13/Nov/2008:15:07:11 +0100] "GET . HTTP/1.1" 404 - "-" "Mozilla/5.0 (Macintosh; U; I...
<thrope> yes
<lifeless> at https://host/bzr/ ?
<thrope> yep
<thrope> but the 404 is coming from serve-branches not from my apache
<lifeless> sure
<lifeless> uhm
<lifeless> the . is suspicious
<thrope> going directly works
<fullermd> Yah.  "GET ."?
<jelmer> lifeless: Yeah, I know about standalone. I'd like to run it from inside of apache, preferably as app
<lifeless> jelmer: well, launchpad runs it as standalone with proxypass
<lifeless> jelmer: so its the most heavily deployed variant
<thrope> Ok - I changed location to /bzr/ instead of /bzr in apache and now get 301 not found instead
<thrope> 127.0.0.1 - - [13/Nov/2008:15:09:52 +0100] "GET / HTTP/1.1" 301 - "
<lifeless> jelmer: you can wire up mod_python to wsgi - there are recipes on the net, even in the bzr docs I think, but - well shrug.
<thrope> so the changes divert doesn't seem to be working
<lifeless> thrope: ah
<lifeless> I think I know your problem :P
<lifeless> /home/robince/bzr/pyentropy/tests/
<lifeless> is that a branch
<lifeless> or a subdir of a branch
<thrope> yep
<thrope> it is a branch
<lifeless> is it in a shared repo ?
<thrope> yes
<lifeless> try serve-branches repo-root
<thrope> lifeless: hmm - it seems to work now but I don't have any css or images
<thrope> and a lot of the links are to 127.0.0.1
<thrope> instead of being rewritten
<lifeless> thrope: workaround, add the --host option
<thrope> i already have --host=127.0.0.1
<lifeless> oh
<thrope> since I want to restrict access to localhost
<lifeless> remove it then
<lifeless> erm
<edreamleo> Hello All. Bzr broke after updating ubuntu. I don't see recent bzr versions in the synaptic package manager.  Reinstalling older versions fails. How can I install the latest?  Thx.
<lifeless> apache is meant to add headers with the external host I thought
<lifeless> thrope: anyhow, beuno should be back online soon; ping him, he's a maintainer
<thrope> it is the same withit removed
<lifeless> its 2am for me :P
<thrope> ok thanks
<Peng_> edreamleo: Ubuntu has a "bzr" package. For something newer, you could use https://launchpad.net/~bzr/+archive
<edreamleo> Peng_: the bzr package is 1.4rc1-1~bazaar1~gutsy1, but iirc I'm using hardy heron.  This seems weird to me.
<Peng_> edreamleo: Check /etc/apt/sources.list. Maybe you still have some references to gutsy?
<edreamleo> Peng_: Thanks.  That's probably it.
<edreamleo> Peng_: Yes, I see lots of references to hardy in /etc/apt/sources.list  I'm no ubuntu expert.  Can I delete the file, or must I edit it?
<Peng_> Um. Deleting it sounds like a really bad idea.
<Peng_> If you want apt to work.
<edreamleo> apt would be good :-)
<Peng_> You can look at /etc/lsb-release to see what version of Ubuntu you run.
<Peng_> Then fix up your sources.list.
<Peng_> If that's the problem in the first place. I'm not really an Ubuntu guy.
<edreamleo> Peng_: At present I'm running hardy.  But I see from the bzr web page that ubuntu is up to intrepid.  Maybe I'll install intrepid first.  Anyway, thanks for your help.
<Peng_> If your system is brokenish, I doubt throwing an upgrade at it will help.
<edreamleo> Oh.  I just see I've been confused.  sources.list is correct: it has references to hardy, which is indeed what I am running.  But the package manager is only giving me access to gutsy files.  So that appears to be the immediate problem.
<dobey> you probably have a gutsy ppa in sources.list.d/ somewhere, and that version is newer than what comes on hardy
<dobey> i don't remember what comes on hardy though
<dobey> intrepid has 1.6.1
<Peng_> Hardy has 1.3.1, apparently.
<edreamleo> dobey: I have a half memory of modifying some "magic" file like sources.list.d several months ago in order to upgrade bzr at that time.  I should have made a note of what I did, but did not.  How can I find such a file?
<dobey> edreamleo: sources.list.d is a directory
<Odd_Bloke> edreamleo: What is in /etc/apt/sources.list.d/?
<dobey> edreamleo: grep for "gutsy" in the files there, or in /etc/apt/sources.list should give you the errant file
<dobey> Peng_: that would explain the "gutsy" file
<edreamleo> The sources.list.d directory contains 3 files, all starting with edgy-universe.list
<thrope> lifeless: well turns out theres a fairly serious bug in loggerhead: https://answers.launchpad.net/loggerhead/+question/45503 have to hard code the host in to the source to get it to create the urls correctly
<thrope> but the good news is its working now
<edreamleo> dobey:  Yes.  2 of the three files contain gutsy rather than hardy: edgy-universe.list.distUpgrade and .edgy-universe.list.save.  I'm wondering about the 'edgy' prefix.  Should I edit the dubious files or delete them all?
<Peng_> edreamleo: The filename doesn't matter. You should edit the files.
<edreamleo> Peng_  Thx.  Will do.
<dobey> if they are .distUpgrade and .save, they probably aren't being used any more anyway
<dobey> you probably had the package installed before you upgraded, and it wasn't upgraded because it was already newer
<dobey> ie, there was nothing to upgrade
<edreamleo> Oh my.  My ubuntu system is looking pretty hosed.  I can't uninstall bzr because of broken packages, like the Epiphany browser(!) and trying to fix the broken packages fails.  Arrrgh.  apt-get install bzr says bzr is already the latest version, and gives gibberish about evolution.
<edreamleo> One moment.  Buried in the blah blah blah as a hint to do apt-get -f install.  I'll try that.
<edreamleo> No.  'apt-get -f install' fails with the same errors as when trying to fix broken packages
<edreamleo> Hmm.  The failures are in Python 2.5: I'll try messing with python...
<rocky> jelmer: how does bzr-svn deal with authentication? i mean can it reuse svn authentication credentials in the standard svn locations ?
<jelmer> rocky: yes
<rocky> very strange, i'm trying to do a push into a svn repo where i know i have write access... and it's reporting back a 401 auth error ... if i put my credentials into the url directly https://someuser:somepass@wherever   it works fine
<jelmer> are you on Mac OS X or Windows perhaps?
<rocky> nope, ubuntu
<jelmer> does it work if you use svn+https:// rather than https:// ?
<jelmer> rocky: ^
<rocky> jelmer: yes it does
<rocky> and i just installed pycurl too and discovered it was having a problem with my self-signed cert which also went away when i did svn+https://
<rocky> i think you need to undeprecate svn+https ;)
<jelmer> I think https:// in bzr needs to be fixed :-)
<w00t_> does bazaar have a web frontend that isn't trac? also, if anyone knows of a guide for how to get bzr:// up and running on debian/ubuntu, that'd be lovely, google isn't being too helpful! :)
<jelmer> w00t_: "bzr serve" should get bzr:// up and running
<jelmer> w00t_: another web frontend is loggerhead - https://launchpad.net/loggerhead
<w00t_> jelmer: but can that be done from the system level? also, which projects does that then serve
<w00t_> I'll look at loggerhead, ta
<jelmer> w00t_: you can specify the directory it should serve
<w00t_> jelmer: ah, that's good
<w00t_> jelmer: it's not possible to start it via xinitd or something?
<jelmer> there's no init script distributed at the moment, if that's what you mean
<w00t_> *nod*
<w00t_> that would have come in handy
<w00t_> but regardless
<thrope> w00t_: if you plan to run it behind apache look at this: https://answers.launchpad.net/loggerhead/+question/45503
<thrope> I've spent quite a bit of time today trying to get it to work
<thrope> it has to be the root directory (ie its own vhost, won't redirect correctly to www.com/bzr
<thrope> and you need to manually edit the source as per that link to have links generated correctly
<thrope> (but that is only if you want to run it behind apache - which I do for ssl, user auth etc.)
<w00t_> thanks for the tip, I'm not sure what I'll be doing yet :)
<Peng_> I don't have any of those problems, but I use Lughttpd.
<Peng_> Err, s/Lu/Li/.
<Peng_> Maybe it's some sort of Apache mod_proxy oddity?
<skipm> help - bzr novice here
<thrope> Peng_: I don't think so - its nothing to do with apache, loggerhead doesn't generate the correct links... everything is http://127.0.0.1:8080/stuff once you get past the first page
<thrope> maybe it is apache... Idont know really
<Peng_> thrope: Yeah, but what if Loggerhead doesn't like the headers Apache sets or something?
<Peng_> Anyway, it's just a wild guess.
<Peng_> skipm: Go on?
<thrope> well I got it working now anyway with vhost and the hack from that question
<thrope> I just think its a shame the .conf file is being deprecated for the serve-branch becuase the config file seems a lot more sensible to me
 * Peng_ uses serve-branches.
<skipm> i wanted to "checkout" the latest ipython release.  I couldn't figure out how to tell what tags were available so I executed
<skipm> bzr branch lp:ipython
<skipm> cd ipython
<skipm> bzr tags
<skipm> rel-0.9.1 is the latest, so I tried
<skipm> bzr update -r tag:rel-0.9.1
<skipm> no joy
<skipm> I couldn't figure out how to accomplish this basic task so I simply blew away my first checkout and
<skipm> am now executing
<skipm> bzr branch -r tag:rel-0.9.1 lp:ipython
<skipm> There must have been a better way, right?
<Peng_> skipm: 'bzr revert -r tag:rel-0.9.1' is the best thing to do.
<Peng_> update probably should support a -r argument, but it...doesn't.
<skipm> thanks.  switching branches hardly seems like "revert"ing.  I would never have thought to check that command
<thrope> skipm: it's not really switching branches - in bzr branch = directory, so the ipython checkout is a single branch. The tag is just a label for a specific revision, so you are reverting to that revisition rather than switching branches (it is part of the same history that the head of the trunk is on)
<thrope> skipm: I agree it's a bit confusing but just trying to show there is some logic to it
<skipm> thrope: thanks for the explanation - makes a little more sense now
<thrope> skipm: although its still a bit messy becuase the revert leaves uncommited changes in the working tree
<thrope> so it might be neater to checkout the tagged revision so you have a clean copy
<thrope> ie ipython is the dir with the trunk branch in it
<thrope> then  bzr co -r tag:rel-0.9.1 ipython/ ipython-0.9.1
<thrope> means you have a checkout at the correct version in ipython-0.9.1
<thrope> and can continue to keep the trunk up to date
<skipm> thrope: i'm not really wanting to develop, just use version control commands to get specific revisions/releases
<thrope> skipm: I think the checkout might still be easier... if you reverted then you would have trouble when you came to update
<EarthLion> hey how can i roll back to a previous revision?
<Peng_> EarthLion: "Roll back"? To revert your working tree to a previous revision, use "bzr revert -r 123".
<mfoniso> what's the correct syntax for  "bzr push bzr+ssh... "
<Peng_> "bzr push bzr+ssh://user@example.com/some/path/relative/to/root"?
<mfoniso> ok, lemme try that
<Peng_> (/and/not/your/home/dir)
<mfoniso> I keep getting this: "ssh: connect to host launchpad.net port 22: Connection timed out"
<mfoniso> when I run "bzr push bzr+ssh://mfoniso@code.launchpad.net/~mfoniso/source-switcher/devel"
<Peng_> mfoniso: It's bazaar.launchpad.net, not code.launchpad.net.
<Peng_> mfoniso: Also, you could use lp:~mfoniso/source-switcher/devel as a shortcut.
<mfoniso> hmm..  I see
<mfoniso> Peng_: I get the following error when I do that: "Permission denied (publickey). bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)"
<Peng_> mfoniso: I dunno. Have you uploaded your public key to Launchpad?
<mfoniso> yeah
<LarstiQ> right user, right key?
<mfoniso> LarstiQ: yes... I think so
<mfoniso> Peng_:if I used the lp: shortcut, what would the full command be?
<Peng_> mfoniso: "bzr push lp:..."
<mfoniso> when I do that it complains about not being able to push via http
<Peng_> mfoniso: "bzr launchpad-login mfoniso"
<w00t_> my gosh, bzr branch on an svn branch takes a long time
<mfoniso> ok, thanks that's what I needed to do. Unfortunately I'm still stuck at with the public key error
<w00t_> jelmer: hmm, if someone else mirrors my bzr-svn imported branch, are they able to use bzr to keep it up to date themselves?
<Peng_> w00t_: Yes.
<w00t_> excellent!
<lifeless> mfoniso: are you on windows?
<mfoniso> lifeless:nope, ubuntu
<lifeless> mfoniso: the most likely thing is that you either are not using the correct lp usercode, or you haven't uploaded your public key
<mfoniso> phew... I hope I get this fixed soon... uploading my key was serious hassle, but I finally got launchpad to accept it...
<mfoniso> and now I'm stuck at this. :-(
<mfoniso> I'm fresh out of options
<mfoniso> what do you mean when you say "...lp usercode"?
<lifeless> mfoniso: what is your lp usercode
<lifeless> lp == launchpad
<mfoniso> but what do you mean by 'usercode'?
<mfoniso> do you mean the unique id provided during registration?
<lifeless> yes
<mfoniso> than I'm really out of options, cos that's what I'm using..
<lifeless> mfoniso: what is your lp usercode though
<mfoniso> well, the error message points to the public key, I just can't see what's wrong with it
<mfoniso> lp usercode is "mfoniso"
<lifeless> mfoniso: so this  https://edge.launchpad.net/~mfoniso is you ?
<mfoniso> should be... lemme see...
 * mfoniso waits for his slow connection
<mfoniso> lifeless:  yes, that's me
<lifeless> ok
<lifeless> and you have run 'bzr lp-login mfoniso' ?
<mfoniso> yes
<mfoniso> and that ran without incident
<lifeless> ok
<lifeless> please run 'ssh -vv mfoniso@bazaar.launchpad.net false'
<lifeless> and pastebin the output
<mfoniso> ok
<w00t_> ugh, i interrupted a bzr branch halfway through by accident, is there any way to resume rather than restarting the process?
<mfoniso> lifeless: what's the "false" for?
<lifeless> mfoniso: just tells it what command to run on the server
<mfoniso> ok
<mfoniso> lifeless:http://www.pastie.org/314097
<w00t_> from reading up, 'bzr pull' looks like a reasonable candidate for resuming, but i'm subsequently told that my branch ..is not a branch
<lifeless> mfoniso: it looks to me like you have done something funny in your ~/.ssh/ directory
<lifeless> mfoniso: you said you had trouble uploading your public key, could you enlarge on that
<w00t_> this seems quite strange, and annoying, is there a way to work around it? or am I going to have to set this whirring for another 3-5 hours
<dobey> w00t_: i think you want get, not pull
<lifeless> w00t_: if you did bzr branch... and it got interrupted, cd to the branch dir, run 'bzr init', then 'bzr pull URL'
<dobey> pull ~= svn/cvs update
<lifeless> dobey: get is a synonym for branch
<w00t_> lifeless: thanks, i'll give it a go
<mfoniso> when I tried to upload my keys, lp complained that my keys were compromised due to a vulnerability in the ssh suite used to create it...
<mfoniso> I created new keys and tried but kept having the same problem
<mfoniso> at some point, I noticed something...
<lifeless> mfoniso: that means that the new keys you created had the same problem, or you werenot uploading the new keys
<mfoniso> ï»¿the ssh key is something like so "ssh-rsa AAAAB3...."
<lifeless> mfoniso: well, thats what a public key gets encoded like
<lifeless> mfoniso: there are two files for every key
<mfoniso> when pasted in lp, the text after the ssh-rsa was on a new line from the "ssh-rsa", it looked as though it was being wrapped, but on a hunch
<dobey> no it should look like 3 lines when you paste in lp
<mfoniso> I had a hunch the copy and paste may have messed with it (inserted a newline maybe), so I backspaced and hit spacebar, and launchpad accepted it
<lifeless> mfoniso: ok, your hunch was probably ok
<lifeless> mfoniso: now, did you create the new keys on the same machine you are using right now ?
<mfoniso> yes
<lifeless> as the same user
<mfoniso> yes
<mfoniso> ï»¿in fact, I don't mind going over the process again
<mfoniso> just to be sure,
<lifeless> nono, thats fine
<mfoniso> ok
<lifeless> what file did you copy the public key from to upload to launchpad
<lifeless> (full path to it please)
<mfoniso> /home/mfoniso/.ssh/id_rsa.pub
<lifeless> ok
 * w00t_ wonders if it is really resuming
<lifeless> I'm going to ask you to look at your id_rsa file. DO NOT SHOW ME THE CONTENTS
<lifeless> (its your private key)
<lifeless> but we need to make sure its intanct
<lifeless> the first three lines of it should be something like this:
<lifeless> -----BEGIN RSA PRIVATE KEY-----
<lifeless> Proc-Type: 4,ENCRYPTED
<lifeless> DEK-Info: DES-EDE3-CBC,8B36D5AFB68087BC
<mfoniso> ok
<mfoniso> that's what it is
<mfoniso> except for the part after "DEK-Info:  DES-EDE-CBC,"
<lifeless> ok
<lifeless> can you run 'ssh-add ~/.ssh/id_rsa'
<mfoniso> ok
<mfoniso> I ran that, entered the passphrase, and got "Identity added: /home/mfoniso/.ssh/id_rsa (/home/mfoniso/.ssh/id_rsa)"
<lifeless> now try the ssh ... false command again
<mfoniso> ok
<mfoniso> I get a similar message as last time
<lifeless> permission denied(publickey) ?
<mfoniso> yes
<lifeless> ok
<lifeless> it seems to me that the ssh key you uploaded does not match your id_rsa file
<lifeless> there are several possibilities
<lifeless> a) your id_rsa.pub and id_rsa file were generated seperately
<lifeless> b) you uploaded a different id_rsa.pub file
<lifeless> c) something has been altered since creation
<mfoniso> hm...ok, how about I delete the current keys, recreate and upload?
<lifeless> sure, if you're not using them elsewhere
<lifeless> rm ~/.ssh/id_rsa
<lifeless> and ~/.ssh/id_rsa.pub
<mfoniso> yup
<lifeless> in lp delete the current key
<mfoniso> just recreated, uploaded, and running that command again (the ssh  command ending with "false")
<mfoniso> I get the same error
<lifeless> mfoniso: did you get an error about being created by a vulnerable ssh?
<lifeless> and/or did you edit the text in  the upload window at all?
<mfoniso> yes I did, edit the text that is
<lifeless> ok
<lifeless> delete the key, try without editing the text
<mfoniso> ok
<lifeless> delete it on lp I mean
<mfoniso> yup
<mfoniso> yeah, I get that message about the key being vulnerable
<lifeless> ok
<lifeless> can you pastebin the same thing you're pasting in the lp key upload box ?
<mfoniso> ok
<lifeless> mfoniso: also please run 'ssh-vulnkey ~/.ssh/id_rsa'
<mfoniso> lifeless: http://www.pastie.org/314151
<mfoniso> ssh-vulnkey says: "Unknown (no blacklist information)... "
<lifeless> mfoniso: ok
<lifeless> mfoniso: your editing is removing an A from the front of the key
<lifeless> mfoniso: this makes it look like a different key
<lifeless> mfoniso: and so you can't login
<lifeless> mfoniso: your ssh is still vulnerable
<lifeless> mfoniso: do you have 'security updates' turned on ?
<Peng_> If you have ssh-vulnkey, doesn't that mean you're using a modern enough OpenSSL/OpenSSH?
<lifeless> Peng_: no, it means you have ssh-vulnkey
<Peng_> :P
<lifeless> these are the two keys: first is what was pastebinned, second was what lp had
<lifeless> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwUF9kcG18g4d4+LZaBxZy18on2mq3a14fFxHQOnkVMVA3OOLVj6b3KoHqxM5LfDYJRce4kbN0L8Nbe7Usk87Ru434rSFSKHZQuAVH079rM9ayrMk7h/hmGrevW1iAXn5MMAK2VEQUyY+sUGrKmyshoOSBHrh9IkD1Lk/HCgzrqNXYqO7ZyGoyFGBnJypSpZHCyTFNOxUa2g07BJqbXd9RY9yCYZQNLH21guhI36vNBWM6DfU4/xRfUAs5PWyIyHZJQJVv3nncdAlBf200KNJpcQxVlVFJEwkhax07HxIpOXGCV/Dg1cBQJCHXGvFmP39tXP92UltaxLB5u+EbMvQEw== mfoniso@xanax
<lifeless> ssh-rsa AAAB3NzaC1yc2EAAAABIwAAAQEAwUF9kcG18g4d4+LZaBxZy18on2mq3a14fFxHQOnkVMVA3OOLVj6b3KoHqxM5LfDYJRce4kbN0L8Nbe7Usk87Ru434rSFSKHZQuAVH079rM9ayrMk7h/hmGrevW1iAXn5MMAK2VEQUyY+sUGrKmyshoOSBHrh9IkD1Lk/HCgzrqNXYqO7ZyGoyFGBnJypSpZHCyTFNOxUa2g07BJqbXd9RY9yCYZQNLH21guhI36vNBWM6DfU4/xRfUAs5PWyIyHZJQJVv3nncdAlBf200KNJpcQxVlVFJEwkhax07HxIpOXGCV/Dg1cBQJCHXGvFmP39tXP92UltaxLB5u+EbMvQEw== mfoniso@xanax
<mfoniso> lifeless: I suppose that would mean the security sources are uncommented in /etc/apt/sources.list?
<lifeless> mfoniso: just use synaptic
<mfoniso> ok
<lifeless> settings - repositories - updates - important security
<lifeless> make sure that that option is ticked
<lifeless> then in the main window hit the reload button
<lifeless> I'll bet it wants to update openssh etc
<lifeless> possibly openssl; I don't recall where the exact bug was
<Peng_> The exact bug was in OpenSSL, so both should be upgraded.
<mfoniso> you are probably right, some security stuff wasn't enabled
<mfoniso> and after "reload" it's getting a bunch of stuff
<mfoniso> lifeless: while I wait for that to complete, a question:
<mfoniso> from your fine detective work, it's obvious I was uploading a wrong key (having inadvertently deleted and "A" from the key)
<mfoniso> so why did "bzr launchpad-login mfoniso" not give an error?
<lifeless> mfoniso: two possible reasons
<lifeless> one is that it might not be possible to tell a slightly damaged public key; I haven't read the format details
<lifeless> the other is the lp may be checking for known gotchas but not checking it really is a public key
<lifeless> I think the former is more likely
<mfoniso> I'm not sure I follow, but I have the impression it uses the public key to match against my private key when I run that command.
<mfoniso> if that's the case, then the login should fail cos what it had wasn't my public key
<mfoniso> ok, my updates are going to take quite sometime, my connection isn't terribly fast
<mfoniso> hopefully with the new ssh suite, I'll get a proper key and this problem will go away.... forever.. never to return...
 * mfoniso is very hopeful
<eleftherios> I have been bzr pushing to a remote server and after an interruption I can no longer push, I get a message that is locked. I deleted the info file under .bzr/branch/lock but now it just hangs. ANy ideas?
<Peng_> eleftherios: "bzr break-lock $the_url"?
<lifeless> eleftherios: don't manually change things under .bzr; you'll upset things
<lifeless> eleftherios: as peng says, 'bzr break-lock url-you-were-pushing-to'
<eleftherios> let's hope that the deleted info file won't matter
<Peng_> eleftherios: Nah, that was part of the locking procedure, so it shouldn't have done any harm. But you should do it properly.
<eleftherios> Peng_: it just hangs for ages...
<w00t_> man oh man, this import is *slow* :/
<eleftherios> bzr break-lock returned fine
<eleftherios> but the push just hangs
<eleftherios> no messages
<eleftherios> Peng_: ah here it is, an error message at last: bzr: ERROR: Could not acquire lock "LockDir(<url>)"
<lifeless> eleftherios: what precise file did you delete
<eleftherios> .bzr/branch/lock.info
<eleftherios> .bzr/branch/lock/info
<lifeless> eleftherios: ok, make sure there are no other files in .bzr/branch/lock/
 * eleftherios is checking
<eleftherios> there are two dirs: czwk9moldm.tmp  held
<eleftherios> shall I delet them?
<lifeless> yes
<eleftherios> ok
<eleftherios> it worked, thank you Peng_ and lifeless :-)
<Peng_> Should break-lock be more accepting of, well, broken locks?
<lifeless> Peng_: maybe; or check should report or something
<lifeless> Peng_: OTOH its not naturally occuring
<meuserj> the latest bzr-gtk is supposed to have nautilus integration turned on by default... but it doesn't seem to be working for me...  bzr 1.9, bzr-gtk 0.95.0, python-nautilus 0.5.1
<meuserj> is there anything I need to do to enable it?
<mfoniso> lifeless: I've updated my openssh suite and now have new keys (not subject to the previous vulnerability)
<mfoniso> the problem's been solved - I've uploaded the key yo LP, and pushed my code across. :-)
<mfoniso> thanks a lot for your effort and patience
<mfoniso> you too Peng_
<mfoniso> thank guys, I really appreciate it
<abentley> spiv: around?
<lifeless> mfoniso: no problem, happy to help
<Peng_> mfoniso: That's great that it's been worked out. Don't forget to run security updates in the future. :)
<mfoniso> Peng_: will do
<lifeless> beuno:
<lifeless> beuno: is there glue around to lsprof loggerhead for a single page request?
<beuno> lifeless, I don't think so, but rockstar was working on exactly that during the epic if IIRC
<lifeless> rockstar: ^ yo, dude.
<lifeless> beuno: is there some function that is called and contains the entire request?
<lifeless> beuno: cause, if you can point me at that, I can whip it up in about 5 minutes
<Peng_> There might be information about profiling Paste somewhere.
<beuno> lifeless, since mwhudson added streaming to it, I lost track of how that part worked
<beuno> maybe in loggerhead/app/__init__.py?
<beuno> are you planning on fixing our memory leaks?  :)\
<lifeless> beuno: no
<lifeless> beuno: but nice try
<lifeless> beuno: I want to know the impact of split-inventory on loggerhead
<lifeless> so I can make sure it will be suitable/give you advance warning|do any changes needed to work well with it
<beuno> ah, it's great you would do that
<beuno> there is quite a bit of the code that interacts with bzrlib that we want to change (it's part of what leaks memory)
<rockstar> lifeless, I have a profiling branch, yes.
<rockstar> The Paste profiling middleware isn't great...  :(
<rockstar> So I wrote one that uses cProfile, and spits it to a log file.
<lifeless> rockstar: where's the brinanch, I'll rip the guyts out and use lbzr's pofiling code
<lifeless> mucho nico
<lifeless> excuse my typing, thashing machine right now
<lifeless> *thrashing8
<rockstar> beuno, I have a block of time this weekend that I'll be fixing the memory leaks that we know about for loggerhead.  herb would really like this fixed.
<lifeless> bah.
<rockstar> lifeless, how did you get non ascii characters in there?
<beuno> rockstar, so not tomorrow?
<beuno> I'mm be flying around and recovering from jetlag this weekend  :/
<rockstar> beuno, probably not.
<beuno> I'll
<rockstar> beuno, PQM closes tomorrow, so I'm busting ass to get stuff in.
<beuno> rockstar, yeah, i did that dance today
<rockstar> lifeless, https://code.edge.launchpad.net/~rockstar/loggerhead/dev-tools
<rockstar> lifeless, I'd be interested in the results.
<rockstar> lifeless, especially if you can land it soon, so I can use it this weekend.
<spiv> abentley: I'm around now
<rockstar> Odd_Bloke, re: bzr-laconica -- I'm relatively familiar with the API, if that helps.
<abentley> spiv: On a call.  Catch you later
<spiv> abentley: ok
<Odd_Bloke> rockstar: Cool.  It's trivial to do with python-twitter (i.e. "x = twitter.Api(username='foo', password='bar'); x.NewStatus('message')").
<rockstar> Odd_Bloke, yea, it's similar.  I think I might take a stab at it soon (I've been thinking about it for a while)
<Odd_Bloke> rockstar: I was going to do it earlier, but python-twitter has tests which I'd want to ensure were testing correctly for laconi.ca as well.
<Odd_Bloke> I'm actually incapable of submitting a patch upstream which doesn't include tests (assuming the project already has tests).
<Odd_Bloke> I hold bzr developers collectively responsible for that.
<rockstar> Odd_Bloke, :)
<lifeless> http://paste.ubuntu.com/71472/
<lifeless> poolie: ^ ja1
<lifeless> :^
<lifeless> spiv:^ etc
<lifeless> poolie: ja1: spiv: vila: igc:
<poolie> hello Odd_Bloke
<Odd_Bloke> poolie: Hi. :)
<igc> morning
#bzr 2008-11-14
<lifeless> vila: TestCompare is a level higher than TestIterChanges
<lifeless> look at TestIterChanges
<vila> lifeless, Yup, I'm on IterChanges, does test_file_rename suits you ?
<lifeless> ok
<lifeless> jml: ping
<jml> lifeless: pong.
<lifeless> is launchpad-bazaar 'just the server side code' or 'stuff for launchpad-bazaar'?
<lifeless> (I'm asking because IMO launchpad plugin bugs belong in launchpad-bazaar; I think poolie has been treating it that way too)
<jml> lifeless: I think it should be just the server side code.
<jml> lifeless: and I *thought* I'd already said so to both you & poolie
<lifeless> jml: Ok. Can you make this more clear on project pages etc
<jml> although maybe not as clearly / officially / permanently as I ought
<jml> lifeless: will do.
<lifeless> jml: e.g. https://edge.launchpad.net/launchpad-bazaar it entirely unclear, though it is a wonderful mission statement
<lifeless> it just doesn't help me understand what bugs/questions are relevant there :)
 * jml sends an email to a person
 * thumper feels like he needs a PR person sometimes
<poolie> hello thumper
<lifeless> bam bam
<thumper> hi poolie
<lifeless> vila: how are you going?
<vila> trying to understand what is *in* the heap in CHKMap,iter_changes
<lifeless> vila: ok; do you suspect a bug in that later?
<lifeless> *layer*
<vila> so far, yes.
<lifeless> vila: it should be trivial to examine whitebox style - left = dict(map1.iteritems()), right = dict(map2.iteritems())
<lifeless> then you can say deleted_keys = set(left) - set(right)
<lifeless> and new_keys = set(right) - set(left)
<lifeless> and (a little more work needed)
<lifeless> unchanged = set([key for key in set(left).intersection(set(right)) if left[key] == right[key]])
<lifeless> changed = set(right).intersection(set(left)) - unchanged
<lifeless> and you can do this from within a debugger in CHKInventory.iter_changes, before the loop
<lifeless> and compare it to
<lifeless> list(self.id_to_entry.iter_changes(basis.id_to_entry))
<lifeless> vila: ^
<vila> ack
<lifeless> poolie: http://www.google.com.au/search?q=launchpad+bazaar+password+authentication&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
<lifeless> my google-fu is strong
<vila> right, so since the tests is about renaming a single file unchanged shouldn't be empty
<vila> right, so since the test is about renaming a single file unchanged shouldn't be empty
<lifeless> vila: 'changed should not be empty'
<lifeless> ?
<vila> changed is empty too
<lifeless> vila: keep poking it for a little bit, I'll just flush my cache
<vila> I really meant unchanged shouldn't be empty, there is a directory and a file inside it that are used in the test but not concerned by the rename itself
<lifeless> vila: ok
<vila> so may be the bug occured before, when the map were built
<lifeless> vila: note that unchanged is not reported by iter_changes
<vila> so may be the bug occured before, when the maps were built
<lifeless> vila: so its the dict comparison that would show them as unchanged
<vila> lifeless, sure, I used it as the simplest communication vector, eye-grepping left and right told me that before
<lifeless> vila: you can also do self[self.path2id['dir'] etc to check
<vila> in left: (('b-id',), 'dir: b-id\x00root-id\x00b\x00vila@scythe-20081114004115-p86lzmmfsqqie2a3')
<vila> in right: (('b-id',), 'dir: b-id\x00root-id\x00b\x00vila@scythe-20081114004115-oh1ijsqf60ht5rzs')
<vila> is the latest part a rev-id ?
<vila> that's the crux of the problem, there is no difference between the twosm yet iter_changes saw them as different
<lifeless> vila: yes, the end is the revision_id
<lifeless> they are different
<lifeless> but perhaps inv.iter_changes is not meant to report these differences
<lifeless> ah yes
<lifeless> in CHKInventory.iter_changes
<lifeless> if there is no change at all, but the revision is different, just continue
<lifeless> rather than yielding
<lifeless> so
<lifeless> if not changed_content and parent[0] == parent[1] and name[0] == name[1] and executable[0] == executable[1]:
<lifeless>     continue
<jfroy|work> jelmer: I'm getting a weird failure trying to branch a bzr branch whose parent is a Subversion branch
<jelmer> jfroy|work, what's the error?
<jfroy|work> bzr: ERROR: Revision {svn-v4:be02940b-5f7b-422b-ba6c-1eb93f4884eb:<path>:7882} not present in "6604@be02940b-5f7b-422b-ba6c-1eb93f4884eb:<path>".
<jfroy|work> It's strange not because it is happening per se, but it's happening if I try to branch the the branch in a different repository
<jelmer> jfroy|work, this is what the warning in bzr-svn trunk is about..
<vila> lifeless, that fixed some failures 17 failures out of 36 :)
<jfroy|work> The source branch is in shared repository A, and I can branch it in that repository fine. But if I try to branch in repository B, it fails with that error.
<jelmer> jfroy|work, the output of bzr-svn trunk can change, breaking some core assumptions made in bzr
<jfroy|work> Right, I used trunk for a brief while some time ago.
<jfroy|work> But I am not right now.
<jelmer> the same key refers to slightly different contents in bzr apparently
<jelmer> jfroy|work, one of the revisions you're fetching was apparently imported using trunk
<vila> lifeless, so, out of the 19 remaining failures, most need either specific_files filter  or include_unchanged or want_unversioned implemented
<vila> 3 sounds like bugs in CHKInventory.inter_changes about missing/renamed files. I'll look into them first
<lifeless> ok
<lifeless> commit and push first
<lifeless> small steps
<jfroy|work> jelmer: OK sorry, had to take care of something
<jfroy|work> I checked out the svn branch in repository B just fine.
<jfroy|work> So basically, I should re-branch the svn branch in repository A
<jfroy|work> And indeed, I might have done the initial checkout in repository A using bzr-svn trunk.
<poolie> ok i'm going back to 288751 now
<poolie> i might push my bzr branch of that and get some user testing
<funkychicken818> hey i am running bzr on my windows box and i created a project on my linux box and i am getting the error Not a branch
<funkychicken818> i a connecting via ftp
<lamalex> is there any documentation on setting up a server to be able to push to and pull from?
<lifeless> lamalex: yes, in the users guide
<lamalex> yah, i just found it
<lamalex> my google-fu was failing me, but now i got it
<lifeless> vila: how are you progressing?
<vila> lifeless, :) You always ping just when I want to ask you a question :)
<lifeless> its the chip implanted in your brain
<lifeless> I get a flashing red LED here
<vila> lifeless, haaa, I thought it was tobacco craving...
<vila> so, for bzrlib.tests.intertree_implementations.test_compare.TestIterChanges.test_missing_and_renamed
<vila> CHKMap,iter_changes knows nothing about the missing file renamed and transformed into a directory and I don't understand if that's the bug
<lifeless> so
<lifeless> this may need special casing in the test
<lifeless> RevisionTree.iter_changes(RevisionTree) can never have 'missing' files :)
<vila> you mean something like in test_only_in_source_and_missing (just below) ?
<lifeless> vila: yes
<lifeless> only on tree2
<lifeless> erm
<vila> sure
<lifeless> *thinks*
<lifeless> yes
<lifeless> tree12
<lifeless> *2*
<vila> well, in the permutation we added, we want only the tests that use two revision trees and we don't want tests that need one or two working treees (as tests about missing files are)
<vila> do you agree ?
<spiv> ~.
<lifeless> vila: one working tree will be fine
<lifeless> vila: because the existing dirstate<->workingtree needs one revision tree
<lifeless> vila: so the new if block should be tree2 only
<vila> I added         if not tree2.path2id('directory'): for test_missing_and_renamed
<lifeless> cool
<vila> my question was more about why we encounter these failing tests and a general rule I can apply for the other ones :)
<lifeless> vila: yes, I agree
<vila> test_only_in_target_and_missing for example needs kind of the same test for the same root cause, the change ends up being a 'missing' one that can be represented in our case
<vila> and instead of duplicating that block, I'll do a helper named file_id_is_missing(path) that will raise TestNotApplicable, agree ?
<vila> file_id_cannot_be_missing_in(path, tree)
<lifeless> how about
<lifeless> not_applicable_if_missing_in(path, tree)
<vila> deal
<lifeless> self, path, tree actually :P
<lifeless> hmm, unless it needs to be a function, then path, tree is fine :>
<vila> yeah, yeah, don't worry :)
<lifeless> jam: spiv: - there are two cases I think, xml->chk, and chk->chk
<lifeless> the former hits interdiffering
<lifeless> so fetch.py should just find the nodes only-in the interesting inventory maps
<lifeless> I suggest a new method on chk_map to support this; similar to the iter_changes one
<lifeless> because it has the same problems with when-are-duplicate-keys-encountered
<lifeless> it probably wants to take two sets though, not two objects
<jam> right
<lifeless> a naive implementation (use iterchanges, discard some data) is probably easy to get going, and will let the interface be settled
<lifeless> in terms of layering
<lifeless> hmm, actually, I'll comment later
<lifeless> other than to say I agree its not a CHKMap method
<a_c_m> how can i run bzr as the nobody user ("bzr commit" is being spawned by a exec() command from php)
<lifeless> a_c_m: bzr doesn't particularly care
<lifeless> a_c_m: just make sure your permissions etc allow it to do what it needs :>
<a_c_m> lifeless: i think they are, but i think bzr is expecting a .bzr directory in the users home folder
<a_c_m> which being the nobody user, it doesn't have
<a_c_m> anyway to bypass that check?
<lifeless> a_c_m: it needs a ~/.bazaar, and a ~/.bzr.log it can write too
<lifeless> you'll need them available in whatever account it is running as
<a_c_m> right, so how do i create / fake that, as a the nobody user ?
<a_c_m> who doesnt have a home directory ?
<bob2> 'nobody' shouldn't own any files
<lifeless> a_c_m: well, my advice would be to not run bzr as 'nobody'
<a_c_m> right, but i dont have that option really
<lifeless> nobody isn't meant to have write access anywhere, so asking bzr to do something your system is almost certainly setup to prevent won't end well
<lifeless> a_c_m: why don't you have an option?
<bob2> use sudo to run a trivial shell script that can only commit the required stuff
<a_c_m> the bzr statement is being kicked off by apache
<lifeless> a_c_m: so? tell apache what user to use
<a_c_m> i think i've worked out a way around it
<a_c_m> apache user == nobody
<lifeless> awesome
<lifeless> some one just mailed me asking how to login in  latin on intrepid
<bob2> haha
<lifeless> I'll need to fix it again I suspect :P
<lifeless> perf testing this children thunk
<lifeless> I expect satisfactory results, because the design makes sense to me :)
 * lifeless has no ego, really
<flacoste> is there a bzr-svn ppa?
<flacoste> or any way to get a bzr-svn to go with bzr 1.9 package?
<flacoste> i'm on hardy, btw
<lifeless> ugh
<lifeless> Inventory.apply_delta mutates the inventory entries it is passed
 * lifeless fixes
<lifeless> flacoste: not sure
 * flacoste thinks i might be better to use bzr-svn as a branch
<Peng_> Woah why is Loggerhead using half my RAM?
<Peng_> (That would be more dramatic if I wasn't running it on a $20 VPS. :P )
<poolie> lifeless: so at the moment "_fetch_uses_delta" determines "include_delta_closure" but they're not really the same thing
<jml> Peng_: *probably* a bug in Bazaar's logging. The Launchpad Code team are looking at it.
<jml> (it's one of our dozen #1 priorities)
<Peng_> It was only 200 MB. I was surprised because it almost doubled in 6 hours.
<Peng_> (doubled *to* 200 MB, I mean)
<Peng_> jml: Logging leaks RAM?
<jml> Peng_: uhh, I meant "something in getting a revision log". I haven't been following the details of the discussion.
<lifeless> spiv: jam: just pushing a tweak to allow inv._make_delta(inv), which unsurprisingly improves fetching from dev3 to dev4 dramatically
<Peng_> jml: Oh!
<Peng_> Hey look, it dropped 4 MB of RAM.
<Peng_> Anyway..
<cafuego> How do I increment the version no of a repo to an arbitrary integer?
<Peng_> You, uh, don't?
<AfC> cafuego: while `/bin/true` ; do bzr commit --unchanged ; done
<Peng_> Or that.
<AfC> cafuego: that outta do ti. :|
<cafuego> AfC: ta
<lifeless> cafuego: <why>?
<AfC> [notice the subtle "ti" mimicking the reversed "fi" that ends a shell if block, clearly I was playing on that instead of just saying "outta do it". Yup. Uh huh]
<cafuego> Peng_: I'm setting up bzr for a piece of software that's at rev 12. I'm missing v1 and 2, but would like the commits match the version number (it's a single php file)
<cafuego> AfC: if you 'sudo rmmod sjh' the problem should go away ;-)
<AfC> cafuego: uh, Peter, can I politely suggest that you're on completely the wrong track?
<cafuego> Yes, you can.
<AfC> cafuego: as for your task at hand, why not just use tags?
<cafuego> That sounds like more work ;-)
<AfC> [sooner or later you're going to have more than one commit : "version" and you'll be screwed anyway, hence my suggestion expressed a moment ago]
<cafuego> AfC: No, that work would be done ona  dev branch, not on trunk.
<AfC> cafuego: or, do what everyone else does, and have the version embedded in a file somewhere and ignore it from there.
<cafuego> AfC: I'll merge those into trunk and a single revision, thus keeping it in sync.
<mlh> while true; do something; done
<mlh> no need - in fact you shouldn't backtick it
<AfC> mlh: I was in a channel the other day where someone had the nick 'something'. The conversation went to Who's On First" in a real hurry.
<mlh> hah
<AfC> mlh: Ah yes. I knew that. In fact, that's what my fingers typed, and then I second guessed myself. Thanks
<mlh> while I'm on a roll ... :-)
<mlh> true is faster than /bin/true, being a builtin (I think) and : might be even faster
<AfC> mlh: it is a builtin, yes
<AfC> $ help true
<lifeless> I don't knows on third
<vila> lifeless, just pushed handling specific files for iter_changes
<lifeless> sweet
<cafuego> right, done, excellent.
<poolie> lifeless: like http://pastebin.ubuntu.com/71665/
<poolie> unfortunately now i understand it i can't think of a better way to explain it :)
<jml> spiv: want some sad news?
<jml> Using saved push location: bzr+ssh://bazaar.launchpad.net/...
<jml> No new revisions to push.
<jml> HPSS calls: 19 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x12aeed0>
<jml> HPSS calls: 6 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x142e550>
<jml> HPSS calls: 7 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x1444090>
<lifeless> poolie: why line 23/24 ?
<lifeless> http://paste.ubuntu.com/71472/
<spiv> jml: not as bad as I'd fear ;)
<jml> spiv: if I had to call Tim 32 times to find out I had nothing to do, I'd be upset. :)
<jml> hmm. you could probably make a parlour game out of protocol design.
<poolie> jml :-)
<spiv> jml: I noticed recently how many times waiters at restaurants come up to your table to find out that everything is fine.
<poolie> varies per country and restaurant
<jml> spiv: polling sucks
<poolie> lifeless: it's not a big deal, it just seems like it's a class property not an instance one
<jml> poolie: I'm semi-serious though.
<lifeless> poolie: formats are instances :)
<lifeless> how does lh want patches? branches? bb? lp merge-proposals
<lifeless> ?
<poolie> jml, i know
<cafuego> spiv: i noticed they all did that in adelaide, not so much in melbourne.
<poolie> lifeless:  i think through lp
<lifeless> jml: ^^ lh above is loggerhead
<jml> lifeless: I don't know for sure. I think bb.
<jml> lifeless: I merely hang out with a bunch of people who care about loggerhead :)
<vila> lifeless, yeah for getting rid of make_inv_delta !!
<rockstar> lifeless, did you happen to hack on that profiling for loggerhead.
<lifeless> rockstar: thats why I'm asking
<rockstar> lifeless, oh, I hadn't read backlog.
<rockstar> Submit a merge proposal.
<lifeless> ok
<lifeless> I've only just started now
<lifeless> but the day is close to halt() so getting the facts straight
<lifeless> rockstar: I was planning on writing the profile to request_serial.callgrind in the working dir
<rockstar> lifeless, there's something going on with stderr.  I couldn't capture it properly.
<rockstar> I wanted to put the profiling data into the HTTPResponse, but it never really worked right.
<lifeless> rockstar: ok, well I don't :)
<lifeless> rockstar: should I preserve yours, or just alter it to suit?
<rockstar> lifeless, alter to suit.
<lifeless> rockstar: the reason I don't, is that it would force buffering and be a race condition,FWIW
<rockstar> lifeless, oh, I'm fine with that.  In fact, if I could get more detail in a log, then I'd rather have that.
<lifeless> what is the getattr('close' thing all about ?
<rockstar> lifeless, no idea.  I haven't touched that branch in two weeks.  I was probably in the middle of scheming something.
<lifeless> ok
<lifeless> and self.lock?
<rockstar> lifeless, threading thing.
<lifeless> yah, just climbed into the base class
<lifeless> fugly
<rockstar> lifeless, indeed!
<lifeless> most of it has to do with buffering.
<lifeless> overly clever fools.
<rockstar> Yea, I figured I could have removed much of that code.
<lifeless> also,  it will buffer badly; list.extend is not the fastest thing in the world
<lifeless> I particularly like their use of inline methods
<poolie> lifeless: this is the basic approach to instert_records:
<poolie>                 # We can insert the knit record literally if either we already
<poolie>                 # have its basis OR the basis is not present even in the
<poolie>                 # fallbacks.  In the latter case it will either turn up later
<poolie>                 # in the stream and all will be well, or it won't turn up at
<poolie>                 # all and we'll raise an error at the end.
<lifeless> rockstar: just adding save to disk, then will be done
<lifeless> poolie: not quite right. I think:
<lifeless> poolie: ah, never mind me, thats fine
<lifeless> poolie: I was thinking that it may make fulltext things it doesn't need to; that we could (should?) insert it literally always, if we dno't have its basis then at the end, copy the basis in as a full text.
<lifeless> (from the fallback repo)
<lifeless> poolie: butperhaps this is over complicated
<poolie> i thought about that too
<poolie> however, it seems like you may end up with more data
<poolie> because you'll get a fulltext plus a delta rather than just one (perhaps larger) fulltext
<poolie> there are various possibilities, like if you get a lot of direct children of a fulltext that's in the fallback repo
<lifeless> thats true; OTOH we won't ever turn a ft into a delta, so perhaps more data here is better for when its merged to the trunk repo.
<poolie> it would have been better to just copy it
<poolie> true
<poolie> so it does seem more complicated because you have to recurse back in to the fallback repo to get the delta closure...
<lifeless> (that's kindof a flaw itself, but we're working with what we have today ;P)
<lifeless> poolie: so, your text is fine; we both thought about and discarded the same thing
<poolie> ok
<poolie> so i have that approach working
<poolie> insert_records is a bit complex i'm going to see if i can refactor that
<poolie> but it is passing now
<lifeless> rockstar: I can has kcachegrind love
<lifeless> 26% in simpletal
<lifeless> expandInline
<lifeless> ok, not bzrlib. yay
<lifeless> something silly is logging gif content to stdout
<lifeless> oh, thats me
<lifeless> whats all this /static stuff ?
 * lifeless thinks loggerhead trunk is broken
<lifeless> (assuming this is close to trunk)
<lifeless> anyho
<lifeless> w
<lifeless> rockstar: its done
<vila> lifeless, only 2 failures left for ./bzr selftest --no-plugins -s bt.intertree IterChange.*CHK
<lifeless> vila: congrats
<pygi> morning folks
<poolie> hello pygi
<poolie> lifeless: so now some of the effort tests in test_knit are failing
<pygi> hey poolie, how's it going? :)
<lifeless> poolie: push one in, the other pops out
<poolie> ?
<lifeless> commenting on bug fixing in general
<poolie> oh, right
<lifeless> rockstar: around?
<poolie> woo!
<poolie> bug 288751 is dead, i think
<ubottu> Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751
<poolie> and probably all its brothers
<lifeless> poolie: congrats!
<vila> lifeless, no more failures :)
<vila> lifeless, pushed to bbc
<lifeless> vila: vcool
<vila> lifeless, I kept all the hacks in the same place so there will be a single place to de-hack :)
<vila> lifeless, TestCompare tests passing too
<igc> night all
<poolie> night
<visik7> hi
<visik7> good morning
<visik7> at least here :P
<visik7> I need to remove some files that lives in my history that are HUGE and when I mean huge I mean 600mb  that is not anymore in the tree and they are present only for 1 revision
<visik7> is there a way ?
<visik7> jquery
<visik7> ops
<eleftherios> :-)
<splodge> Is there a command akin to 'switch' for branches - i.e. created with 'branch' not 'switch'?
<splodge> I haven't found anything so far and wonder if the only way is to delete my local branch and issue the branch command again for the one I want?
<hmeland> Maybe "pull --overwrite", depending on exactly what you mean by "akin to".
<splodge> Which is a bit of a shame because the branches contain lots of similar code
<splodge> Maybe overwrite will work. I'll take a look
<splodge> Perfect! Thanks.
<hmeland> Also, you could create a shared repository above the branch, and "bzr reconfigure" the currently --standalone branch into a --use-shared branch.
<splodge> I'll take a look into it, thanks.
<jbl1> I'm using bzr v1.3.1 from Ubuntu 8.04 LTS right now.  I planning on sticking with the latest bzr available in ubuntu for production use, because it gives me a good indication of how stable that version of bzr is, and how backward compatible it might be in the event of an upgrade.  Does anyone see any problems with this, or should I be trying to stick to the latest version of bzr off the website?
<AfC> Sorry, what gives you an indication of "stable for production use"?
<AfC> You should most certainly be using the latest release of Bazaar if you are able. That's where the bug fixes are.
<awilkins> Yes, the enormous test suite is far more reassuring than a slow creep of revision numbers
<ikarus2k> hello everyone. I was wondering, could Bazaar be used within a design department? That would mean large files (10-300MB), autoversioning would be nice...
<awilkins> It wouldn't be advisable
<awilkins> It's not suited to large files
<awilkins> Have you considered ZFS?
<awilkins> It wouldn't provide iron-clad-forever versioning but it would give you a considerable cusion
<awilkins> *cushion
<ikarus2k> ... ZFS -> the file system? does it store previews (1-step) versions?
<ikarus2k> ah, the copy-on-write feature, thnx alott
<ikarus2k> k , thnx bye
<visik7> I need to remove some files that lives in my history that are HUGE and when I mean huge I mean 600mb  that is not anymore in the tree and they are present only for 1 revision
<hiperlink> Hi all, I'm in linux and tried to install the vimdiff plugin (copy to ~/.bazaar/plugins/vimdiff (there are README and __init__.py)), making the .py executeable, but when I do 'bzr plugins' it's not listed.
<hiperlink> what am I missing?
<Odd_Bloke> hiperlink: Look in ~/.bzr.log, it might tell you.
<hiperlink> @Odd_bloke as I'm not a python programmer, I'm not good at interpreting this: http://gist.github.com/24890
<Odd_Bloke> hiperlink: If you 'cd ~/.bazaar/plugins', 'python -c "import vimdiff"', what happens?
<hiperlink> ImportError: "No module named vimdiff"
<hiperlink> oh I got it, accidentally I moved the __init__.py to plugins/ not into plugins/vimdiff/.
<hiperlink> Anyway: thanks for your help
<Odd_Bloke> Yeah, that'll do it.
<hiperlink> now it works.
<hmeland> visik7: Your best bet is probably to branch the revision just before the giant file was introduced (revision N), and then use the "rebase" plugin to re-create revisions N+2... on top of revision N (i.e. skipping revision N+1).
<visik7> :/
<hmeland> This means that the revisions N+2... will have their revision-id change, so any branches off the un-rebased revision will become stale/still include the giant file.
<beuno> lifeless, you filed to merge proposals with the same commits, except for a last one. Any reason for that?  to land them separetly?
<cr3> if I pushed a commit but then I want to revert that commit in order to make little commits, how can I revert without removing those files that were added?
<cr3> maybe I could do a bzr revert -r1; bzr diff -r1..2 | patch?
<cr3> err, 2..1
<cr3> nevermind, all figured out now
<army> hi ,bzr-svn do not wok , i installed bzr-svn with macports,
<army> bzr checkout svn+http://www.prestashop.com/publicsvn/trunk/ shop-trunk The svn+ syntax is deprecated, use http://www.prestashop.com/publicsvn/trunk/ instead. - [                                                        ] copying revision    0/4815
<army> stay in this screen about five minute,
<Odd_Bloke> army: Are you sure it's not doing anything?
<Odd_Bloke> Just because it's not reporting progress doesn't mean it's not doing anything (unfortunately).
<army> ? yes ,no reporting progress,
<army> Initialising Subversion metadata cache in /Users/army/.bazaar/svn-cache/6e0da8f0-d90d-0410-b14f-823b0ad1652c   bzr: ERROR: plugins is already versioned
<davidstrauss> If you have a checkout with local commits, how can one commit, say, a single file to the bound branch? We get "ERROR: Selected-file commit of merges is not supported yet" right now.
<vadi21> Hi, I have a question about the bzr notification - it's only giving me notifications when I commit. Is that it's supposed behaviour? I thought it would notify me when others committed.
<LarstiQ> vadi21: which notification and which others?
<vadi21> LarstiQ: when I commit locally, it pops up a notification. But not when someone else commits to a repository I'm involved with.
<LarstiQ> vadi21: if you're in a lan setting with others using bzr, they'd have to send out notifications, and you listening to that, to be notified.
<vadi21> Oh.
<vadi21> Can I make it notify me of launchpad notifications?
<LarstiQ> I'm not aware of launchpad notifications?
<LarstiQ> could be some feature got introduced without me noticing
<vadi21> Ah nevermind then, just thought that would be more useful. Thanks for your explanation
<LarstiQ> vadi21: for launchpad branches, you could hook it up to rss of course
<vadi21> Yeah
<LarstiQ> vadi21: but if we're talking about the same notification thing, that is not what it was originally written for
<dobey> yeah i don't really get why bzr-gtk does notifications anyway
<LarstiQ> dobey: how so?
<Odd_Bloke> dobey: It's intended to tie into the bzr-dbus stuff, so you can get notifications whenever someone on the network commits.
<dobey> LarstiQ: i don't really need to see a notification of when i commit, or when i pull new revisions
<LarstiQ> dobey: right, that's not the primary usecase
<dobey> Odd_Bloke: that makes sense, but notifying for local commits/pulls is rather annoying
<abentley> spiv: ping
<davidstrauss> If you have a checkout with local commits, how can one commit, say, a single file to the bound branch? We get "ERROR: Selected-file commit of merges is not supported yet" right now.
 * beuno realizes he's committed random messages to Loggerhead
#bzr 2008-11-15
<ia> hello, everybody. could someone, please, give me link to good manual for setting up bzr server to work with it via bzr:/-protocol?
<jfroy|work> quick question: how do I get the revno of the working-tree?
<jfroy|work> I'm trying to find a regression by checking out old revisions of a branch, and I want to confirm the revno of the current working tree
<verterok> jfroy|work: revision-info?
<jfroy|work> That seems to give me the latest revno of the branch
<jfroy|work> e.g., gives me the revno of bzr log -r -1
<jfroy|work> when a bzr st outputs a message stating my working tree is out of date
<verterok> jfroy|work: according to bzr help  version-info, it shows revision info of the tree
<verterok> jfroy|work: you could do bzr update to get your tree up to date
<jfroy|work> indeed, thanks
<jfroy|work> no that's just the thing, I'm doing a regression analysis, and I wanted to make sure my tree was out of date (at a specific revision)
<n[ate]vw> I'm trying to install bzr 1.9 on my web host, but getting a build error due to missing Python.h
<n[ate]vw> How do I use this --allow-python-fallback that it recommends?
<n[ate]vw> or where do I find an older version?
<verterok> jfroy|work: maybe you can use lightweight checkouts to have different revisions of the tree around
<verterok> n[ate]vw: I not an expert, but it looks like your server don't have the development files of python (headers, etc)
<n[ate]vw> yeah, I'm assuming that's the problem, but the error diagnostic makes reference to this python fallback option
<verterok> n[ate]vw: if it's a debian based distro, I'n sure a simple: apt-get install python-dev should solve the problem
<n[ate]vw> but then I get "error: option --allow-python-fallback not recognized"
<n[ate]vw> it's a shared host, so no can do
<verterok> hmm, what version of python?
<n[ate]vw> 2.5.1
<jfroy|work> verterok: version-info worked fine
<verterok> jfroy|work: great! :)
<jfroy|work> Although indeed, I am getting a bzr exception when trying to checkout if a tree already exits
<jfroy|work> I have to remove-tree, then co again, with a different revno
<verterok> jfroy|work: you could  do the co in different dirs :)
<jfroy|work> I don't really care to keep multiple trees
<jfroy|work> I mean, I could, I suppose
<jfroy|work> But I'm playing a game of "is it this one?"
<verterok> hehe, ok.
<verterok> n[ate]vw: could you pastebin the error?
<verterok> and the command you are using?
<n[ate]vw> verterok: http://pastebin.com/d61571c59
<n[ate]vw> (original command was 'python setup.py install --home ~/sw')
<verterok> n[ate]vw: you could simply drop the source there, and bzr should "just work" (mileage may vary)
<n[ate]vw> that's true, forgot about that option
 * verterok bbiab
<Leefmc> Question: I am attempting to branch a googlecode project via bzr-svn, and although bzr-svn is downloading the branch information (such as commit logs), it is not actually downloading any code.. Any thoughts as to why?
<luks> it's not downloading the code at all (ie, the process has finished and no code was downloaded)?
<Leefmc> luks: Correct
<luks> that's weird
<luks> how do you check that?
<Leefmc> is "bzr branch  http-addy-to-trunk" the correct command?
<Leefmc> erm, minus a space, heh
<Leefmc> luks: By looking in the directory and seeing zero code
<luks> in most cases, yes
<luks> Leefmc: what does `bzr info` say?
<Leefmc> lemm rebranch it, one sec
<luks> I think you just have a branch without a working tree
<Leefmc> ohh thats right
<luks> which `bzr checkout .` should fix
<Leefmc> i forgot, if theres no working tree bzr wont show you code
<Leefmc> that always trips me out. heh
<luks> hm, I wonder why?
<Leefmc> My minds all fluxxed from bzr-svn hybrids heh.
<luks> bzr doesn't show you the code, your shell does
<Leefmc> luks: Well, i ment that bzr physically hides the code, does it not?
<luks> Leefmc: no
<Leefmc> Oh well, maybe thats not the problem then.. lemme bzr info
<luks> all bzr is interested in is the .bzr directory (in most cases)
<luks> the working tree matters only if you try to e.g. commit
<Leefmc> i dont wanna paste it all, so what are you looking for specifically? there is a shared repository, a repository branch, and a parent related branch
<Leefmc> but the branch, only has one directory in it, .bzr. The file system has zero code in it
<luks> try bzr checkout .
<luks> or bzr log
<luks> if bzr log list something, you just want to add the working tree
<Leefmc> luks: Ah, you confused me before (or rather 4am with no coffee, confused me, more than likely)
<Leefmc> luks: So bzr _does_ actually hide the code if you have no working tree
<luks> Leefmc: it doesn't hide it, it simply doesn't exist
<Leefmc> ie, without a working tree, code is not visable on the file system
<luks> Leefmc: you can't hide something that doesn't exist :)
<luks> well, that's obvious
<luks> but the working tree is not hidden
<Leefmc> luks: Well it must exist somewhere on it, because you can essentially download it from bzr when you checkout
<luks> Leefmc: no, bzr only knows the data to generate it
<luks> but it doesn't exist in the form of actual files
<Leefmc> luks: Ah, well imo it still exists within bzr then haha, but now were splitting hairs :)
<Leefmc> luks: Yea
<Leefmc> luks: Anyway, thanks
<Leefmc> luks: Have you delt with bzr-svn much?
<luks> I wonder how did you get into this situation, though
<Leefmc> luks: No working tree?
<luks> yes
<luks> it's not the default option
<luks> do you have a repository created with `bzr init-repo --no-trees` or something?
<Leefmc> luks: Its my workflow of choice, coming from git (gawd, i really do need coffee). I prefer to have many test branches, and one working one on the file system so i never jump around in my IDE. So i have --no-trees defined in my shared repo
<luks> Leefmc: that's what surprises me, if you know enough to use the --no-trees option, I would have expected you know how to create a checkout :)
<Leefmc> luks: I do, i just forgot that bzr hid (or rather, didnt make visable, however you wish to lookat it :o) the code within
<luks> or at least non-existance of the checkout would not confuse you
<luks> well, you _told_ it to do that
<Leefmc> Its been a couple months since i've used bzr, so it confused me ;)
<luks> so that should be the expected behavior
<Leefmc> well, 4am and no coffee too haha
<luks> ah :)
<Leefmc> luks: Actually i told it "--no-trees", and really i had forgotten why i used it, aside from the fact that it allowed me to achieve my desired workflow.
<Leefmc> So i told it "--no-trees" and i forgot i was telling it "--dont-give-me-any-visible-code" :o
<luks> heh
<Leefmc> anyway, i really do need coffee. Thank you for your patience.
<GaryvdM> Hi - Is there a way to suppress warnings in bzr.
<GaryvdM> My client is using bzr-upload. It tries to set chmod's, but my client is using a IIS server for her site, so we get a warning for each file that it can't set the chmod.
<GaryvdM> I would like to suppress these warning, as they are not a problem in this case.
<LarstiQ> GaryvdM: I'd file a bug on bzr-upload
<GaryvdM> Ok - It is a todo in their code.
<LarstiQ> or fix it yourself if it's not too much trouble :)
<gour> hi, anyone interested for some benchmark results (doing bzr's vs. gits' fast-import from darcs), take a look at https://bugs.launchpad.net/bzr-fastimport/+bug/232177
<ubottu> Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New]
<gour> and i'm bit disappointed that bzr couldn't finish task in more than 5hrs which git did in 20mins :-(
<leefmc> Question: I accidentally made a checkout into a no-tree branch. How can i remove the checkout from that directory without harming the branch?
<LarstiQ> leefmc: `bzr remove-tree`
<leefmc> LarstiQ: Thank you.
<leefmc> Wasn't sure if any of those would harm my branch, etc.
<pygi> I know its saturday, but would anyone here be so kind to help me assemble a TOC?
<mkanat> kiko: NASA used PRACA for the first time, live, for the Endeavour shuttle launch yesterday. :-)
<mkanat> kiko: They use bzr for that, too. I think they use bzr as much as they can for their internal projects, now, actually.
<mkanat> At least, at Ames HCI.
<mkanat> kiko (and poolie, etc.): I have a little news article that's going to go live about PRACA on bugzilla.org. Maybe you could get them to make a little statement about bzr, too. They're pretty fond of it. :-)
<kiko> mkanat, wow, no way! is that serious?
<mkanat> kiko: Yeah! :-) http://www.bugzilla.org/news/#praca
<mkanat> kiko: They started using it because I use it for ES projects.
<mkanat> kiko: But bzr is super-convenient for them because there's SO much merging involved in what they do, and there's also a LOT of branching.
<kiko> you are the man
<kiko> that's a really cool story
<mkanat> Thanks! :-)
<kiko> let's try and get some news out on monday
<mkanat> kiko: Okay. Do you want me to put you in touch with the people at Ames who use bzr?
<kiko> yes, if you could forward an email to me I'll do the rest
<mkanat> kiko: Okay.
<kiko> nasa, how about that
<mkanat> :-)
<lamalex> does anyone know who the loggerhead maintainer is?  Does he/she hang out in here at all?
<lamalex> I submitted a bug with a patch a few nights about but there's been no activity on the bug
<lamalex> s/about/ago
<pygi> lamalex, I think its Michael Hudson
<pygi> not sure
<jelmer> lamalex, yeah, Michael Hudson (mwh) or Martin Albisetti (beuno)
<lamalex> jelmer: pygi: thanks
#bzr 2008-11-16
<slangasek> jelmer: hi, is there any workaround for bug #210705?  I seem to be stuck in a corner trying to do a merge of the Debian grub svn branch
<ubottu> Launchpad bug 210705 in bzr-svn "bzr-svn forgets relationship (dup-of: 130372)" [Undecided,New] https://launchpad.net/bugs/210705
<ubottu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Fix committed] https://launchpad.net/bugs/130372
<slangasek> jelmer: hmm, n/m, it just took me forever to guess the right syntax :(
<slangasek> well, no; it let me merge but it did it wrong, so
<slangasek> jelmer: right, so I'm still stuck in the corner then
<kumi> If I branch lp:bzr/1.9, how then do I easily upgrade to lp:bzr/1.10, when it comes out?
<kumi> I assumed mainline would have the releases tagged, but no such thing
<LarstiQ> kumi: what is your intent? When I branch a specific release, I want it to stay that way.
<LarstiQ> kumi: and for the rest, I just use bzr.dev
<kumi> I'm installing on Windows, not planning on committing anything to my local branch. Just wondering if there's an easy upgrade path when the next official release comes along
<LarstiQ> kumi: you could `bzr pull lp:bzr/1.10`
<LarstiQ> kumi: or just use the windows installer?
<kumi> Thanks, I'll try the first.
<jelmer> slangasek: Hi
<kumi> jelmer: how can I unregister tbzr?
<kumi> installed from source, by the way
<kumi> I did python shellext\python\tbzr.py, and I would like to reverse that
<jelmer> kumi, Sorry, I'm not familiar with the latest versions of tbzr..
<kumi> Oh sorry, I just saw that others took over tbzr
<kumi> my bad
<visik7> hmeland: are you here ?
<visik7>  I need to remove some files that lives in my history that are HUGE and when I mean huge I mean 600mb  that is not anymore in the tree, they are introduced at revision 4 and removed at revision 8
<visik7> I'm playing with rebase but I really dunno how to do it
<EarthLion> hey how can i commit and ignore 1 specific file?
<kumi> I think the -x or --exclude switch will do that
<kumi> you can permanently ignore a path with the "bzr ignore", or by editing the .bzrignore file
<EarthLion> odd bzr: ERROR: no such option: --exclude
<EarthLion> googled it and there are references to it
<kumi> bzr help ci
<LarstiQ> EarthLion: what version of bzr are you using?
<EarthLion> Bazaar (bzr) 1.5
<LarstiQ> -x got introduced in 1.6
<EarthLion> ah that would be why
<kumi> :)
<mrooney> Hm, I can't seem to do an export in Windows with bzr 1.9 / py 2.4
<mrooney> "We must have one of fcntl, pywin32, or ctypes available to support OS locking."
<mrooney> Is that expected?
<LarstiQ> I'm afraid so.
<LarstiQ> mrooney: so either use python2.5+, or intall pywin32 or ctypes next to 2.4
<mrooney> Okay, and there's no installer for py2.6 right?
<mrooney> I am only using it for 2.4 because I have that and 2.6 on my system and didn't want to install 2.5 just for bzr
<lifeless> mrooney: I recommned using the bzr binary installer
<mrooney> I was going to but it is 14 megs
<mrooney> and my download speed seems to be 19k
<mrooney> LarstiQ: pywin32 seems to have done the trick, thanks!
<mrooney> doing stuff on windows is rather unpleasant, I am only using it to test my cross-platform app's compatibility with windows
<LarstiQ> mrooney: k
<jelmer> any chance somebody could have a quick look at my foreign branch RFC? I'm not looking for extensive review, just general comments as to whether it's acceptable to have this sort of thing in bzr core
<jelmer> https://lists.ubuntu.com/archives/bazaar/2008q4/049564.html
<kumi> Is bzr bundle deprecated?
<kumi> It doesn't show up in bzr help commands
<mwhudson> kumi: yes, 'bzr send' is the newer better thing
<kumi> thanks
<slangasek> jelmer: heya
<jelmer> slangasek, hi!
<jelmer> slangasek, What are you trying to do exactly that's being prevented by branching schemes?
<slangasek> jelmer: I'm trying to merge from svn://svn.debian.org/svn/pkg-grub/grub/trunk into my local copy of lp:~ubuntu-core-dev/grub/ubuntu
<slangasek> jelmer: and it's not working; so possibly I did something which botched the history
 * jelmer tries to reproduce
<slangasek> jelmer: I've tried using both svn://svn.debian.org/svn/pkg-grub/grub/trunk and svn://svn.debian.org/svn/pkg-grub/grub/trunk/debian, without success either way
<jelmer> slangasek, what's the error you get?
<slangasek> jelmer: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
<slangasek> (specifying a merge base revision doesn't help, either :)
<lifeless> jelmer: I plan to look it over
<slangasek> jelmer: hmm, if I specify just "svn://svn.debian.org/svn/pkg-grub", it's thinking some more
<slangasek> but afk now for dinner
<jelmer> slangasek, thanks, I'll see if I can reproduce that here and how we can fix it
<jelmer> bon appetit
<jelmer> lifeless, thanks
<pygi> jelmer, lifeless: what are the chances that you could join me in gobby session, and help write a TOC for bzr book thingy? :)
<pygi> I'll take that as a no :p
<lifeless> mwhudson: yo, loggerhead profiling branch for you
<mwhudson> lifeless: also 100 million emails
<lifeless> mwhudson: I'm wondering about the internal structure of paste vis-a-vis concurrency and profiling
<mwhudson> lifeless: interesting, but can i talk to you about this some other time?
<lifeless> mwhudson: Sure. btw, I'm on leave from wednesday.
<mwhudson> ok
<lifeless> mwhudson: oh, rockstar already merged the branch; I still want to talk though, at your convenience
<jelmer> pygi, perhaps it's a better idea to bring it up on the list
<jelmer> pygi, and maybe have a look at the existing docs
<pygi> jelmer, yea, I wanted to post it on the list after I have something ready
<lamalex> mwhudson: are you one of the loggerhead maintainers?
<mwhudson> lamalex: i am
<lamalex> have you had a chance to look at https://bugs.launchpad.net/loggerhead/+bug/297930
<ubottu> Launchpad bug 297930 in loggerhead "When browsing revisions, next should go up, previous should go down, numerically" [Undecided,New]
<thumper> sounds reasonable to me
<lamalex> indeed
<lamalex> i was really suprised by the current behaviour, and it's basically a two line fix
<thumper> I hadn't even noticed...
<lamalex> heh ;)
<lamalex> it was driving me crazy one day so I went and patched it
<lamalex> I run a loggerhead instance on my server so I can get to my school files quickly, and keep them versioned
<lamalex> and for some reason I end up switching between versions a lot
<mwhudson> lamalex: i hadn't, mainly becuase i've been on leave for the last two weeks :)
<lamalex> ;)
<lamalex> mwhudson: well that's a valid reason
#bzr 2009-11-09
<bialix> GaryvdM_work: hi
<bialix> GaryvdM_work: quick question: how's grouping in qcommit/treewidget supposed to work?
<bialix> if I have 2 changed files in one directory they're not grouped into folder, is it intended?
<bialix> GaryvdM_work: here is http://imagebin.ca/view/xZhU_h.html
<GaryvdM_work> bialix: if there are more than 4 file, it's grouped
<bialix> hmmm
<bialix> IMO 3 is better
<bialix> ok, anyway, thanks for answer
<GaryvdM_work> bialix: The const for that is in lib/treewidget.py line 116
<GaryvdM_work> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/head%3A/lib/treewidget.py#L116
<bialix> aha, thanks
<GaryvdM_work> You can see from my comment that I was thinking about making a config option for it
<GaryvdM_work> bialix: If you change it, or make it configurable, you will need to adjust the tests.
 * bialix want qbug dialog to send bug reports to LP from command-line without browser, sigh, dreams-dreams
<bialix> GaryvdM_work: ok, not now
<gour> hiya, i'd like to try using bzr hg plugin in order to push/pull to the hg project using hg forest extension. is it possible to achieve it?
<bialix> gour: it seems pull you can, but push not yet
<bialix> what's special about forest extension?
<bialix> we have similar thing in bzr: scmproj plugin
<gour> bialix: forest try to solve something like svn's externals, i.e. nested repos
<gour> let me check that plugin
<bialix> scmproj aims the same
<bialix> but I've designed it to be VCS agnostic, though current implementation supports only bzr
<gour> that's ncie to hear
<bialix> gour: why you don't use hg directly?
<gour> bialix: i've flakey internet conenction (mobile 3g) and running 'hg fpull' often fails forcing me to run 'hg recover' in subrepos, so i hope bzr might be more robust network-wise
<bialix> ah, that's possib;e
<bialix> ah, that's possiblke
<bialix> rats
<bialix> ah, that's possible
<gour> :-)
<bialix> gour: so the problem in builtin hg pull?
<bialix> or fpull does something bad behind the scene?
<gour> bialix: well, it should just traverse all the subrepos and full from 'em
<gour> bialix: i'll try scmproj and see how it works
<bialix> full? pull?
<bialix> gour: feel free to ask about scmproj, I'm the author and docs is not complete
<gour> s/full/pull
<gour> ok, i'll report back. bbs
<bialix> ok
<bialix> is it public project?
<gour> bialix: yep, tryton.org
<bialix> gour: it's a big project
<bialix> it seems you need bzr-hg in the end anyway
<gour> yeah...just wonder if i could organize repo in such a way to be able to pull in one swing
<bialix> GaryvdM_work: found critical regression in qcommit: https://bugs.launchpad.net/qbzr/+bug/479068
<ubottu> Launchpad bug 479068 in qbzr "qcommit crashed if there is removed files" [Critical,New]
<GaryvdM_work> :-(
 * bialix back to 0.15
<GaryvdM_work> bialix: Bug 479068 seems to be windows only
<ubottu> Launchpad bug 479068 in qbzr "qcommit crashed if there is removed files" [Critical,New] https://launchpad.net/bugs/479068
<GaryvdM_work> It's beeing caused by the icon for removed items.
<gour> huh, now i read about bzr' nested tree...
<gour> considering that hg has forest which is supposed to be replaced with subrepos (not clean how it will look like), it seems that with 2.x release bzr is greatly reducing any possible gap with, at least, hg...git is anyway too complicated
<GaryvdM_work> gour: note that nested tree is not complete yet.
<gour> GaryvdM_work: ahh...what is missing?
<gour> still, chosing bzr over hg is very promising now
<GaryvdM_work> gour: I'm not exactly sure, but I think there is a working implementation, but it has not been merged to bzr.dev due to design concerns.
<gour> GaryvdM_work: i see there are 'join' and 'split' commands in 2.0
<GaryvdM_work> gour: Status of nested trees: http://bazaar-vcs.org/NestedTreeProgress
<gour> thanks
<bialix> GaryvdM_work: but you fix it in one go with another bug
<GaryvdM_work> bialix: Yhea - it's not windows specific.
<bialix> thanks
<bialix> is it correct to write in NEWS about: Fixed compatibility with PyQt 4.4.
<bialix> GaryvdM_work: ^ ?
<GaryvdM_work> bialix: With newer pyqt (4.6) you don't have to return a QVarent, but with 4.4, and 4.5 youdo
<bialix> it's nice of course
<GaryvdM_work> bialix: Yes I should update NEWS - I'll do that later
<bialix> I'm do it now
<GaryvdM_work> bialix: Any ideas on bug 479093
<ubottu> Launchpad bug 479093 in qbzr "Treewidget: Can't revert from the context menu on windows" [Critical,Confirmed] https://launchpad.net/bugs/479093
<bialix> one sec
<bialix> GaryvdM_work: does it occurs for any tree?
<bialix> I'd say we keep read lock over tree and then trying to run operation which required write_lock
<bialix> on Windows locks even within process are exclusive
 * bialix knows everybody tired to hear this, last itme maybe: OSLMD
<bialix> GaryvdM_work: steps to repsoduce, please
<bialix> GaryvdM_work: steps to reproduce, please
<GaryvdM_work> bialix: all trees for me
<GaryvdM_work> bialix: are you using tbzr?
<bialix> no, why?
<bialix> "all trees for me" -- what it means?
<GaryvdM_work> bialix I am using tbzr - maybe it is due to tbzr
<bialix> GaryvdM_work: btw, about building installer without TBZR, do you figure out what need to be disabled?
<GaryvdM_work> bialix: I have not looked yet.
<bialix> ping me when you'll be about this
<GaryvdM_work> bialix: ok
<bialix> I'll guide you
<GaryvdM_work> thanks
<bialix> (but don't try to ping me at 3am -- unlikely I'll be up all night) :-)
<bialix> GaryvdM_work: btw, do you have any opinion on my new command logging? I hope it's not irritating
 * bialix personnaly found it useful to see what's going on behind the scenes as debug tool
<GaryvdM_work> bialix: I like the idea - but when used without --ui-mode - to goes away so quickly, I can't see it.
<bialix> Yep, that's problem
<GaryvdM_work> bialix: if no --ui-mode, maybe write to stdout
<bialix> we can emit it to terminal perhaps
<bialix> right
<GaryvdM_work> yes
<bialix> :-)
<bialix> ok, I'll do it soon
<bialix> I'm not sure about length at which I should it truncate
<bialix> right now it's 128 chars, maybe I need to make it configurable via qbzr.conf
<GaryvdM_work> bialix: It would also be cool if you could have a console in explorer/qmain that shows everything that you have done, that you can also use as a shell.
<GaryvdM_work> like dolfin - I'll find a screen shot of that...
<bialix> yeah, luks said something like that about qmain
<bialix> when I've asked him why for there is blank area at bottom
<bialix> GaryvdM_work: I'm still under high pressure on my work, should finish the milestone this week
<bialix> I hope next week I'll have some free time for qbzr
<GaryvdM_work> bialix: cool.
<bialix> I want to dedicate some time to finish and merge all merge proposals we have for very long time
<GaryvdM_work> sigh, my current job is boring - I'm battling to focus on work :-(
<bialix> after *that* discussion in bzr ML I see it's not fair whinning for bzr devs while we have long standing backlog in our
<GaryvdM_work> qbzr is my escape :-)
<bialix> :-)
<bialix> do you want that I'll stop distract you now? ;-)
<bialix> GaryvdM_work: and we desperately need good test suite, because it's hard to find regressions without running some edge cases
<GaryvdM_work> bialix: Yes - and after reading fullermd's mail , I think just finishing of other people work is not to bad (like I did with Craigs qlog multi select)
<bialix> yeah
<bialix> I'm mostly tear between bugfixing of existing code and review others code
<bialix> no time for my own ideas at all :-(
<bialix> our beloved core devs sprinting in Brisbane again?
<GaryvdM_work> jml: Are their any public notes of what you guys are talking about that the sprint?
 * bialix waiting while Matthew Revell will get interview with Gary about Qbzr :-)
<GaryvdM_work> bialix: http://rudd-o.com/en/linux-and-free-software/a-cursory-look-into-kde-4-file-management-dolphin-beta/the-traditional-konsole-terminal-panel.jpg
<GaryvdM_work> bialix: http://kubuntuforums.net/forums/index.php?topic=3099210.0
<bialix> GaryvdM_work: cool
 * bialix wanna such thing for windows
<bialix> GaryvdM_work: I can reproduce the bug with lock even w/o TBZR
<GaryvdM_work> bialix: oh
<bialix> GaryvdM_work: any chance you keep tree locked after you load it
<bialix> in treewidget?
<GaryvdM_work> bialix: I don't think so.
 * bialix trying to run with -Dlock
<bialix> ghaa!
<bialix> OSLMD! OSLMD! ODLMD!
<bialix> GaryvdM_work: http://pastebin.com/d41c45c26
<bialix> suspicious place is tree_write_locked method trying to obtain read lock
<bialix> GaryvdM_work: any bells?
<GaryvdM_work> am
<GaryvdM_work> bialix: I'll going to try specifically taking a write lock.
 * bialix has added log to bug
<GaryvdM_work> bialix: Fixed :-)
<bialix> it was quick
<bialix> really
<GaryvdM_work> bialix: this was the fix.
<GaryvdM_work> http://pastebin.com/d60f4032c
<bialix> GaryvdM_work: :-D
<awilkins> qbzr question : what's the dag-flavoured tree widget?
<awilkins> And is there one for Java?   :-)
<GaryvdM_work> awilkins: we just use a std QTreeView, but we have a custom item delegate which renders the dag, and we implement the expanding and collapsing our selfs
<awilkins> GaryvdM_work, that's pretty much what I figured I'd end up doing
<GaryvdM_work> awilkins: May I ask, what for?
<awilkins> Tree control for SNOMED-CT, a polydimensional DAG
<awilkins> As in there is basically one main axis of traversal but there are also others
<awilkins> SNOMED-CT is a health ontology
<GaryvdM_work> awilkins: if using qt, there are bits you can reuse
<bialix> does anybody knows the tool for windows to easily draw DAGs? I need prepare illustrations to my articles about bzr
<bialix> something like these sexy graphs there http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html
<GaryvdM_work> awilkins: and if you are rendering bzr log in another toolkit, there are also bits you can use
<awilkins> GaryvdM_work, I'll be using Java (either Swing or SWT) but I suspect there will be at least some logic I can reuse
<GaryvdM_work> awilkins: feel free to ask if you need any pointers arround the code.
<mrevell> bialix, That's a great idea ;)
<bialix> mrevell: :-D
<GaryvdM_work> :-O
<bialix> lol
<GaryvdM_work> bialix: Maybe look at http://www.graphviz.org/ , but not as nice as what ever created http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html
<bialix> no, dot is not nice, it require many manual tuning to get what I need in the order and layout I need
<bialix> I mean WYSIWYG tool
<GaryvdM_work> bialix: It seems igc has used inkscape to draw toughs graphs [http://bazaar.launchpad.net/~bzr/bzr-migration-docs/trunk/annotate/head%3A/en/_static/merge-with-parent.svg]
<GaryvdM_work> bialix: I think we can learn from http://www.understated.co.uk/2008/how-we-write-launchpad-announcements/
<bialix> GaryvdM_work: thanks, it's interesting (about announcements)
<bialix> I need to look at Inscape, never saw it in action
<bialix> GaryvdM_work: btw, you're missing summary in your announcement/NEWS
<GaryvdM_work> Sorry
<bialix> np
<bialix> I said this solely in the context of Relevant there http://www.understated.co.uk/2008/how-we-write-launchpad-announcements/
<bialix> btw GaryvdM_work, you don't need to send announcement to ru_bzr, because you're not member; I'm forwarding announcements myself anyway
<GaryvdM_work> Bialix: ok
<bialix> GaryvdM_work: so what about Bug 479093? Do you forgot to push or do you want me to test it first?
<ubottu> Launchpad bug 479093 in qbzr "Treewidget: Can't revert from the context menu on windows" [Critical,Confirmed] https://launchpad.net/bugs/479093
<GaryvdM_work> bialix: ah - push failed
 * GaryvdM_work rebases
<GaryvdM_work> bialix: pushed now
<bialix> thx
<bialix> GaryvdM_work: working OK, thx, NEWS?
<GaryvdM_work> ok
<bialix> interesting is it possible to teach bzr to understand recursive cbzr call, like: bzr bzr qci
<GaryvdM_work> bialix: I think qsubprocess will do that
<bialix> it was half/joke
<GaryvdM_work> bzr qsubprocess "qsubprocess qci"
<LarstiQ> do those arguments keep being passed on?
<GaryvdM_work> bzr qsubprocess "qsubprocess 'qsubprocess qci'"
<GaryvdM_work> LarstiQ: yes
<LarstiQ> GaryvdM_work: yay:)
<GaryvdM_work> and I think if you bencode it, you can do more than 3
<bialix> lol
<smartgpx> GaryvdM_work: I think I've caught a problem with qbrowse in qbzr 0.16.0 - do you want to know about it here or as a bugreport on lp?
<GaryvdM_work> smartgpx: Bug report is better - other wise I'll forget
<smartgpx> OK
<bialix> smartgpx: check the latest reports, today is bug day
<smartgpx> Thanks - it was Bug #479068
<ubottu> Launchpad bug 479068 in qbzr "qcommit crashed if there is removed files" [Critical,Fix released] https://launchpad.net/bugs/479068
<fullermd> bialix: Oooh, bug day?  Do you need help adding bugs?   8-}
<bialix> fullermd: yes, please!
<smartgpx> wrt Launchpad. Is it possible to UNsubscribe from bugs in which I no longer have an interest?
<GaryvdM_work> smartgpx: #launchpad
<bialix> smartgpx: yes
<maxb> abentley: Hi. I filed a couple of MPs against bzrtools over the weekend. Is that sufficient or should I also be emailing the bzr ML?
<abentley> maxb: that's sufficient.
<maxb> thanks
<dash> jelmer: is the wizard in?
<dash> I have an svn repo where a branch was deleted and a new one was created with the same name
<dash> i would like to get a bzr branch containing the branch that was deleted.
<jelmer> dash: hey
<jelmer> dash: easiest way to do that is to create a new branch that is a descendent of the disappeared branch
<jelmer> dash: alternatively you can use svn-import --all and then use bzr heads --dead
<dash> ah.
<dash> i wondered if 'bzr get <url> -r svn:12345' or whatever would do it
<dash> but apparently not
<jelmer> dash: no, that won't work
<jelmer> dash: perhaps we can support something like -rsvn:trunk@12345 though
<dash> jelmer: i'll just svn cp for now
<dash> no big deal. :)
<dash> thanks again
<jelmer> np
<RenatoSilva> verterok: I want to use bzr-eclipse :(
<verterok> RenatoSilva: hi
<RenatoSilva> verterok: hi man, please please apply the patch :D
<RenatoSilva> verterok: or tell me how to build a jar for bzr-java-lib :(
<verterok> RenatoSilva: I'm really sorry about that...I wasn't able to find the root cause but I'm still getting test failures
<verterok> RenatoSilva: just "mvn package" in bzr-java-lib
<verterok> RenatoSilva: I can build bzr-eclipse with you'r patch applied if that's ok with you
<RenatoSilva> verterok: the patch was for bzr-java-lib, iirc bzr-eclise wasn't chnaged
<RenatoSilva> verterok: also for xmloutput, but this one I think you're merged all the work
<verterok> RenatoSilva: I know, but I can build a bzr-eclipse zipped update-site so you can use that
<RenatoSilva> verterok: also I would need redstone xml-rpc fixed, not sure how to do it though
<verterok> RenatoSilva: do you have a patch for it?
<RenatoSilva> verterok: an update site with the patched version? it would be really nice :)
<verterok> RenatoSilva: this hudson instance is running in my desktop, so the uptime (and bandwidht) is quite bad: http://steppenwolf.selfip.net/hudson/
<verterok> RenatoSilva: I have a win32 slave in order to test all components in windows and linux
<RenatoSilva> verterok: bug 388300, last comment
<ubottu> Launchpad bug 388300 in bzr-xmloutput "Encoding problems in xmloutput: non-ascii URLs and ascii decoding of non-ascii strings" [High,Confirmed] https://launchpad.net/bugs/388300
<verterok> RenatoSilva: I have a branch that includes your patch + some fixes for win32 (only for the tests), http://steppenwolf.selfip.net/hudson/job/bzr-java-lib-xp%20%28encoding%20and%20tests%20fixes%29/changes
<verterok> RenatoSilva: you can check the failing tests there ^
<verterok> RenatoSilva: actually, here: http://steppenwolf.selfip.net/hudson/job/bzr-java-lib-xp%20%28encoding%20and%20tests%20fixes%29/10/console
<RenatoSilva> verterok: the test errors were not happening before the patch? isn't it related to the patch needed for redstone lib?
<verterok> RenatoSilva: ok, so we need a patched redstone-xmlrpc?
<verterok> RenatoSilva: don't know, let me check
<RenatoSilva> verterok: see the bug 388300, lte me give you the exact comments....
<ubottu> Launchpad bug 388300 in bzr-xmloutput "Encoding problems in xmloutput: non-ascii URLs and ascii decoding of non-ascii strings" [High,Confirmed] https://launchpad.net/bugs/388300
<verterok> RenatoSilva: I'm looking at it and also the xmlrpc patch in sf
<RenatoSilva> verterok: comments 18-22
<RenatoSilva> verterok: the redstone lib always declares the xml as utf-8, but does not decode/encode the actual xml data with that same encoding
<verterok> RenatoSilva: I can patch redstone xmlrpc and use a patched version in bzr-eclipse if that's what we need
<verterok> RenatoSilva: I'll apply your patch to redstone and fire a new buil/testrun as soon I get home today
<RenatoSilva> verterok: linux developers (including them) don't notice the problem because utf8 is the default system encoding in Java
<RenatoSilva> verterok: I think the patch in the LP bug (read encoding from a config) is better than the one there in SF (hard-coded)
<RenatoSilva> verterok: http://launchpadlibrarian.net/28683665/xmlrpc_fix.diff
<verterok> RenatoSilva: yes, or even accepting the value in the XmlRpcClient constructor
<GaryvdM> Hi RenatoSilva
<RenatoSilva> GaryvdM: hi
<RenatoSilva> verterok: contructor? let me see
<GaryvdM> RenatoSilva: I wanted to explain something to you yesterday, but your rebooted to quickly
<GaryvdM> RenatoSilva: All though you can't work with a checkout on a NTFS dir from linux, you can work with the branch
<RenatoSilva> GaryvdM: I didn't do a checkout
<GaryvdM> RenatoSilva: So you can branch to a linux drive, work there, and when you are done, push back to the branch on the ntfs drive.
<GaryvdM> RenatoSilva: A branch has a checkout by default, unless you say --no-tree
<Adys> Is the lack of expansion of the ~ character on bzr+ssh a known bug?
<RenatoSilva> GaryvdM: in windows, bzr diff returns nothing. I just go into the dir in Ubuntu, and bzr diff returns a lot of permission changes. Not sure what to do or how things should be, maybe the way Linux deals with NTFS should change
<GaryvdM> RenatoSilva: maybe working tree is a better word than checkout
<RenatoSilva> GaryvdM: hummmm, like bzr branch /ntfs /reiserfs, then bzr diff won't show any diff? then when I'm done I push to the original branch, and everything will be ok?
<GaryvdM> Yes
<RenatoSilva> verterok: wow there's a test there that took 39 years to run o.O
<GaryvdM> RenatoSilva: the reason that it guesses +x is so that you can execute files.
<verterok> RenatoSilva: heh
<fullermd> Adys: 2.1 should support it.
<RenatoSilva> GaryvdM: because ntfs does not have anything similar to +x, I see
<verterok> RenatoSilva: looks like a silly bug in a hudson plugin
<RenatoSilva> GaryvdM: it seems to me that it's really just that bzr should be aware about ntfs partitions, and ignore the +x bit
<RenatoSilva> verterok: funny at least :)
<GaryvdM> yes - not sure if that is possible.
<RenatoSilva> GaryvdM: why not use -x for all files, then +x for .exe, .bat and all executable extensions. I think it's a better approach
 * fullermd looks around his *nix system for 'executable extensions'...   :p
<RenatoSilva> GaryvdM: I don't know even if any permission change in ntfs partitions should work
<RenatoSilva> fullermd: ntfs partitions are not originally from *nix
<GaryvdM> RenatoSilva: It doesn't. If you set it to -x, it just goes back to +x
<RenatoSilva> fullermd: they're likely to contain windows stuff
<RenatoSilva> GaryvdM: hum, so the point is not even about the +x, but that all the permission stuff is completely irrelevant
<RenatoSilva> GaryvdM: I think maybe ntfs driver could use the partition metadata, or some meta file, to manage the permissions, separate from the windows ones. Or maybe create some adaption between them
<RenatoSilva> GaryvdM: hum adaption would not be possible,  I think it's no sense. It should be a separate permission management, but stored in the partition itself. It would be nice
<RenatoSilva> verterok: Guillermo iirc bzr-java-lib passes all the tests here, or maybe 1 or 2 fail, but because of '\' x '/' (I've reported a bug about it)
<bialix> sprinters start running
<RenatoSilva> verterok: when I click the test links I get a timeout
<verterok> RenatoSilva: yeap, me too :(
<verterok> RenatoSilva: looks like there's something worng with the apache config
<verterok> RenatoSilva: I'm trying to fix it ATM
<vila> hello bialix, no not yet, I'm up early cause I couldn't sleep :-/
<bialix> hi vila
<bialix> you're in Brisbane again?
<vila> yup
<RenatoSilva> verterok: so let me understand, there's bzr-java-lib, and bzr-java-lib + my-changes, and bzr-java-lib +my-changes + your-changes-to-my-changes?
<bialix> understand
<fullermd> Sleep is for wimps anyway.
<verterok> RenatoSilva: nope, only bzr-java-lib and bzr-java-lib + my changes + your changes
<vila> where I can sign to be a wimp ?
<verterok> RenatoSilva: but I can setup a job for your branch
<verterok> RenatoSilva: once I fix the apache issue :/
<RenatoSilva> verterok: but why sin't my-changes there in LP, only in your local server?
<fullermd> Pshaw.  You start sleeping, next thing you know you'll be expecting to eat too.
<vila> oh ! Good idea, didn't have dinner yesterday, I should go out and find some breakfast :)
<RenatoSilva> verterok: that tool, hudson is for continuous integration, right? Not very familiar with that, my co-workers don't even do unit testing you know
<verterok> RenatoSilva: https://code.edge.launchpad.net/~verterok/bzr-java-lib/encoding-and-test-fixes
<verterok> RenatoSilva: ^ my changes + your changes
<verterok> RenatoSilva: yes, I have a winxp slave so I don't have to run the tests manually in windows ;)
<GaryvdM> bialix: for lp:~craighewetson/qbzr/qrevert, command line files - no longer work - I try figure out a way to get arround this.
<RenatoSilva> verterok: ok, so at the same time I was doing fixes separate from trunk, you were doing too, ok. So which test failures were due to trunk, to your changes, to mine, and to our? Do you have this data?
<verterok> RenatoSilva: my changes are just test fixes (the / vs \ thingy in windows)
<verterok> RenatoSilva: but let me setup you branch (wihtout my changes) as a hudson job so we have some real data :)
<RenatoSilva> verterok: well iirc the \x/ was the only test failures, if you fixed them then trunk + your changes should pass all the tests, mine will break because of \x/ which is fixed only in your branch
<bialix> GaryvdM: ok
 * bialix trying to merge patches for bzr-explorer
<bialix> why ubottu don't provide handy links for lp branches?
<RenatoSilva> verterok: yes the \x/ is with bzr-java-lib: bug 399000
<ubottu> Launchpad bug 399000 in bzr-java-lib "Test failures on Windows" [Medium,Confirmed] https://launchpad.net/bugs/399000
<luke-jr> any way to get irclogs.ubuntu.com edited?
<RenatoSilva> verterok: taking a look at http://steppenwolf.selfip.net/hudson/job/bzr-java-lib-xp%20%28encoding%20and%20tests%20fixes%29/org.vcs.bazaar.client$bzr-java-lib/10/console
<RenatoSilva> verterok: I think it may be encoding problem
<RenatoSilva> verterok: maybe with the redstone lib
<spirov92> hi, i
<spirov92> oops
<verterok> RenatoSilva: yes, now that you pointed me the patch, it might be
<spirov92> i'm embedding a checkout of module1 inside of project1, how can I make bzr upload upload the module too?
<RenatoSilva> verterok: if you can debug, just check redstone's XmlRpcClient, see if the patch is apllied to it
<spirov92> god bless bash, i found a way: for file in $( find . -name .bzr ); do bzr upload -d $file $path/${file%/.bzr}; done;
<verterok> RenatoSilva: http://steppenwolf.selfip.net/hudson/job/bzr-java-lib-xp%20%28encoding%20fixes%29/ws/bzr-java-lib/target/surefire-reports/
<verterok> RenatoSilva: those are the test results of your branch :)
<RenatoSilva> verterok: asks user/pwd
<verterok> RenatoSilva: yeap ;)
<spiv> Good morning.
<jelmer> spiv: moin
<Amything> hey, I'm a lone developer scared of complicated version control :) looking for some help... my situation is...
<Amything> I have installed Bazaar, I want to have master copy of my project on a mapped network drive, and I want to work on my project on my local hard drive
<dash> sounds reasonable
<Amything> I have my files on the network drive at h:\www, do I initialize a project there then?
<dash> 'bzr init'
<Amything> I was hoping to do this with the GUI :)
<Amything> should I go to console?
<dash> which gui?
<Amything> Bazaar Explorer
<dash> ah. never used that, sorry.
<Amything> ok, I would really like you help anyway, I'll use console
<GaryvdM> click on start new project in bzr explorer
<GaryvdM> and then Initialize
<Amything> ok done
<GaryvdM> And the browse and select h:\www
<Amything> ok done
<GaryvdM> plain branch
<Amything> ok
 * GaryvdM notes that bzr qinit has changed!
<GaryvdM> and ok
<Amything> ok its working...
<Amything> hmm maybe I should have added my huge image directory to the ignore list
<GaryvdM> You will still have a chance to do that
<Amything> ok great
<RenatoSilva> Amything: bzr init just inits the repo, your repor does not contain anything yet
<RenatoSilva> Amything: you have to bzr add, to add all of them, or bzr add files/dirs
<GaryvdM> Then you go to "Open an existing location"
<Amything> ah ok
<GaryvdM> and open
<Amything> its still doing something
<RenatoSilva> Amything: bzr ignore <pattern> to ignore your images
<Amything> ok finished
<RenatoSilva> Amything: are you sure you don't want to version control your images? They won't be in your repo
<Amything> they come and go quite rapidly in my testing, wont that slow things down?
<Amything> lets just try it
<Amything> better safe than sorry
<GaryvdM> Amything: I version my images for the websites that I do.
<dash> if you have rapid change of large binary files, you might want to find something other than bzr to manage those with.
<Amything> yeah I have several thousand images in there
<dash> but it probably depends on what "rapid" and "large" mean :)
<GaryvdM> Amything: go to "Open an existing location"
<GaryvdM> and click on open
<Amything> Searching for that one still
<Amything> ok got it
<RenatoSilva> thousand images? what's that?
<Amything> its bunch of company logos
<Amything> and pictures of there location as well
<GaryvdM> Amything: tell me when you see "Working tree is up to date at revision 0."
<Amything> before doing "Open existing locatoin" ?
<Amything> I have:  Working tree differs from revision 0.
<Amything> in my www(H:/) tab
<GaryvdM> Good, now click Commit
<Amything> ok
<Amything> write message and ok?
<GaryvdM> Tick "Show non-versioned files"
<Amything> looks good
<Amything> see my fiels
<Amything> files
<GaryvdM> And tick the files you want to add.
<GaryvdM> And you message can be something like "Initial Commit"
<Amything> Will all subfolder come along?
<GaryvdM> Oh yea, that can be painfull
<GaryvdM> Cancel the commit dialog
<GaryvdM> and go into add
<GaryvdM> That is better at adding whole dirs.
<Amything> ah ok
<Amything> working...
<GaryvdM> You can add from commit, but it's only good for odd single files.
<Amything> ok
<RenatoSilva> Amything: you should not ignore the images just because they're many and/or big
<Amything> yeah I inclued them
<GaryvdM> Amything - so you can choise not not add your images from the add dialog
<RenatoSilva> Amything: but because they are not part of your versioning, and I suspect they are
<GaryvdM> you dont have to ignore them
<Amything> taking some time
<GaryvdM> RenatoSilva: It's easy with bzr-explorer/qbzr to not add a dir without ignoring it.
<GaryvdM> RenatoSilva: but lets say you don't want to add *.pyc file - that should be done with ignore
<RenatoSilva> GaryvdM: either ignored or unknown, I mean he wants to ignore the images
 * Kilroo1 sighs.
<Kilroo1> I really need to try to set up a Windows build environment.
<RenatoSilva> GaryvdM: and I suspect he should not ignore (no bzr add / bzr ignore)
<GaryvdM> Amything: Normaly things like add are very quick, but I think they are slow for you because you are doing this on a network drive.
<Amything> ok
<Amything> its around 400 meg as well
<GaryvdM> RenatoSilva: No - Thats what I'm saying - He does not need to ingore the images folder, just not add it.
<RenatoSilva> GaryvdM: what I mean is that maybe he shoud add them
<Amything> maybe I should cancel and just not add it while we do this?
<GaryvdM> Ok
<GaryvdM> Amything: Do you have the same dir on you local drive?
<Amything> yes
<RenatoSilva> Amything: could you explain what is your sofware and the relation with your imgs?
<GaryvdM> Amything: Lets frist create the branch on you local drive, and then push it to the server
<GaryvdM> *first
<Amything> I'm exporting images from a database binary field into my filesystem
<GaryvdM> Then they def should not be versioned
<Amything> yeah I will just do that when I go live I think
<Amything> so I will cancel right?
<GaryvdM> yes
<Amything> and close the www(H:/) tab and delete the .bzr files?
<GaryvdM> Amything: are you on windows or linux
<Amything> windows
<GaryvdM> oh h: - windows
<GaryvdM> Amything: yes
<Amything> ok done
<Amything> and repeat with local
<GaryvdM> Cool - Do the sames steps on you local folder.
<RenatoSilva> Amything: does your software rely on any expected value for the images?
<Amything> not really
<RenatoSilva> Amything: that is, there should be an image called abc in dir xyz, and the image should be a dog or a mail icon etc
<RenatoSilva> Amything: if not, then what's the relation bewteen your sofware and the imgs at all
<Amything> they are just used on a web page with img tag, no big deal if they are missing
<RenatoSilva> and what does this have to do with your sofware at all?
<Amything> when I go live I need to deploy these images to the server, but in testing they dont play any role
<RenatoSilva> your software is the web site?
<Amything> yes its a php project
<RenatoSilva> ah ok
<Amything> Committing...
<Amything> Finished
<GaryvdM> Much quicker local
<Amything> Still get "?  Working tree differs from revision 1."
<Amything> what could that be
<GaryvdM> What do you see if you click "Diff"
<Amything> No changes found
<Amything> still shows msg after refresh
<Amything> ah ok its the directory I skipped
<GaryvdM> Dose it say anything under "Working tree differs from revision 1"?
<Amything> yes
<Amything> Unversioned (1)  ?
<Amything> ?  finna/files
<Amything> which is my skip folder
<GaryvdM> Ok - thats ok
<Amything> cool
<GaryvdM> Hmm - now the folder that you want to keep this branch, allready contains the file.
<GaryvdM> That is going to cause conflicts when you try push there
<Amything> I see
<GaryvdM> I may be eaiser to push do a different place.
<GaryvdM> *do=>to
<Amything> so now when I work on my project locally and make a change I'm happy with, I commit it and the push it to the network drive correct?
<GaryvdM> yes
<Amything> you think the files folder will be in the way of this?
<GaryvdM> Or just push there (h:\www), and then do del h:\www\*.moved /s
<GaryvdM> Amything: no, this is just something you have to overcome initialy
<RenatoSilva> what kind of partition is your network dirve?
<Amything> hmmm its a Windows 2000 server, not sure about the details
<GaryvdM> RenatoSilva: that won't matter. Different to what you were doing
<RenatoSilva> GaryvdM: that would matter if it was Netware :P
<Amything> how do I push to the network drive?
<Amything> console?
<RenatoSilva> bzr push <target>
<GaryvdM> RenatoSilva: Ok - I see
<GaryvdM> Amything: Collaborate -> Push
<GaryvdM> Or F6
<RenatoSilva> GaryvdM: bug 452625
<ubottu> Launchpad bug 452625 in bzr "No such file errors in Netware filesystems" [Undecided,New] https://launchpad.net/bugs/452625
<Amything> pushing... :)
<GaryvdM> Amything: Sorry - I must go to bed. It's 1:47 in the morning
<Amything> ok thanks for all the help, save me a bunch of time
<Amything> thanks again
<GaryvdM> Pleaser
<GaryvdM> Amything: once you have pushed, you will probably get lots of duplicate conflicts.
<Amything> yeah I was getting some errors, trying something now
<Amything> had the old files there, so I'm deleting them now
<Amything> start with empty directory
<GaryvdM> Ok - that will work as well.
<GaryvdM> Ok night.
<Amything> gn
<Amything> bzr: ERROR: [Errno 22] Invalid argument
<Amything> hmmmmmm
<Amything> try using cmd line
<Amything> same
<Amything> hmm works locally
#bzr 2009-11-10
<Amything> cant push to the network drive at all
<maxb> I am considering trying to convince my workplace to use bzr. One question I don't have an answer for: How do people manage nice browsing and display of branches of a project, if they don't have it in a site which presents a shiny UI like Launchpad?
<bob2> loggerhead!
<james_w> poolie: do you have the admin password for the udd list?
<arjenAU> hmm
<arjenAU> ahoy gurus
<arjenAU> I aborted a bush to lp. now tells me locked, suggested using break-lock. but the url given does not work
<arjenAU> bzr: ERROR: Unsupported protocol for url "lp-46129552:///~maria-captains/maria/5.1.39-oqgraph/.bzr/branch/lock"
<arjenAU> hmm if I use the regular bzr+ssh url I can break it. just the display is wrong. i'll file a bug on that
<arjenAU> https://bugs.launchpad.net/bzr/+bug/250451 existing/confirmed problem it seems. few months old though
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock for smart-server branches" [High,Confirmed]
<spiv> maxb: use loggerhead
<spiv> maxb: or am I misunderstanding you?
 * maxb has been playing with it.... it's a start
<spiv> arjenAU: yes, bzr break-lock lp:~maria-captains/maria/5.1.39-oqgraph, it is an old bug but kinda hard to fix for various reasons
<maxb> It doesn't seem entirely amenable to putting multiple projects under a directory tree without mentioning each project explicitly in the config
<lifeless> maxb: bzr serve --http /path/to/root
<lifeless> maxb: will Just Work
<arjenAU> spiv: well I just specified the actual push url, you don't have it available lowlevel?
<RenatoSilva>  how to find the revision that has introduced a particular change?
<RenatoSilva> e.g with bzr log -p | grep 'particular-change' I can get the -change and +change, but I don't know what revision
<RenatoSilva> it's abit boring to bzr log -p > file, and browse it
<bob2> bzr blame
<bob2> depending on what you mean by 'particular change'
<bob2> (bzr blame will show the last time each line was altered)
<arjenAU> RenatoSilva: you can also do bzr log -p pathname for a particualr file.
<RenatoSilva> bob2: no I don't want annotation, I would have info just about the last rev that introduced the line
<RenatoSilva> arjenAU: ok, less boring
<arjenAU> RenatoSilva: yep. easy to /search, then you see which rev, and then you can just do -p on that -r to see everything to do with it and such.
<arjenAU> well that's how I'd do it. there are so many commands but people tend to pick a few that work for them.
<arjenAU> I love log -p.
<RenatoSilva> would be nice if qbzr allowed to search the changes, like a bzr qlog -p or so
<arjenAU> RenatoSilva: maybe bzr glog or one of the other gtk commands.
<RenatoSilva> arjenAU: ok using it with eclipse ide, I do a search like (<change>|revno), so I get the changes highlighted, and jsut need to click the annotations to know the underlying revno
<RenatoSilva> revision 19!
<arjenAU> well there ya go. enjoy
<RenatoSilva> it would be really nice to have something like bzr search
<RenatoSilva> $bzr search 'xyz'
<RenatoSilva> rev 23: +xyz
<RenatoSilva> rev 42: -xyz
<RAOF> RenatoSilva: Are you aware that there _is_ a bzr-search plugin?
<RAOF> I don't think the output is as you described, though.  Let's see...
<RenatoSilva> RAOF: I'm afraid it's not
<RAOF> Also, my version of bzr-search seems to fail on everything I try.  Whoops.
<versatiletech> can I push to a local directory instead of connecting to a remote server?
<bob2> sire
<versatiletech> ?
<RenatoSilva> sure
<RenatoSilva> bzr push <dir>
<versatiletech> nice
<versatiletech> I'm starting to really like bazaar for its simplicity
<versatiletech> so far it's much friendlier than svn
<RenatoSilva> sometimes I guess the bzr command for doing what I want
<RenatoSilva> because the command is sort of obvious or natural
<versatiletech> yeah
<RenatoSilva> I guessed bzr ignored for example, just typed and worked :)
<versatiletech> lol
<versatiletech> what's the opposite of bzr init?
<mwhudson> versatiletech: rm -rf .bzr
<versatiletech> k
<versatiletech> mwhudson: is there only one .bzr directory in the root folder of the bzr project?
<mwhudson> versatiletech: yes
<mwhudson> (it's not like .svn)
<versatiletech> beautiful!
<versatiletech> I love that!
<versatiletech> that's one thing I hated about svn
<wgrant> IME, the worst bit about having .svn/s everywhere is that it makes it impossible to grep for things.
<mwhudson> well
<mwhudson> harder
<lifeless> ack
<lifeless> or bzr search
<RenatoSilva> does bzr search plugin return revisions?
<ChrisMorgan> I have Python 2.5 installed and am on Win32; which version of Bazaar should I be installing, the standalone one or the Python 2.5 one?
<offby1> Newbie time: I did "bzr branch svn+ssh://...", and in that new directory, made an edit and committed it.  I then figured I needed to do "bzr push" to get the change into my subversion repository, but that command said "bzr: ERROR: No push location known or specified.".  What am I misunderstanding?
<offby1> hm, may have figured it out: I just tried "bzr push svn+ssh://...", and that seemed to work
<offby1> in other words, it didn't assume that I wanted to push to the same place from which I branched
<bob2> yes
<offby1> gotcha
<offby1> gotta say, bzr is a _lot_ slicker than I remembered.
<offby1> tolerably fast, too
<offby1> thanks.
<thumper> :(
<thumper> crash
 * thumper checks the ppa
<maxb> Does anyone know for a brief summary of pipes vs looms, to help me figure out which one I might want to use?
<maxb> Hmm. I just got a "no such revision" error running bzr rebase - is there any way to track down in what context the not-found revision-id was referred to?
<lifeless> maxb: pipes do not version the set of pipes; loom versions the set of threads. pipes has a more mature UI I suspect
<thekorn> hi there,
<thekorn> in the old online docs of bzr there was a page which describes a setup for a coding sprint
<thekorn> does anyone of you know where it moved?
<lifeless> gnight
<maxb> What is the status of bzr-rebase? I was trying to get it to work, and found it seems fairly broken if your history isn't perfectly linear
<jelmer> maxb: broken in what regard?
<maxb> I think I hit bug 446075 followed by bug 266897
<ubottu> Launchpad bug 446075 in bzr-rewrite "NoSuchRevision in _iter_inventory_xmls running bzr rebase" [Undecided,New] https://launchpad.net/bugs/446075
<ubottu> Launchpad bug 266897 in bzr-rewrite "bzr-rebase loses merges" [High,Triaged] https://launchpad.net/bugs/266897
<maxb> Unfortunately, the combined effect is sufficiently a showstopper that I can't use rebase at all
<maxb> Perhaps rebase should issue a health warning if it's being run on a history it doesn't know how to handle?
<jelmer> I'd rather just fix the bug
<spirov92> hi guys, how do I make bzr remember sftp passwords? I tried ~/.bazaar/authentication.conf but it didn't work
<bob2> don't do that
<bob2> setup ssh keys
<spirov92> bob2: how is that done?
<bob2> are you on windows?
<spirov92> nope, linux
<spirov92> ~/.bazaar/authentication.conf <<<does that look like windows? :)
<bob2> ssh-keygen ; ssh-copy-id remotehost ; get a beer
<bob2> oh right
<bob2> guess not
<bob2> also https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<smartgpx> bialix: good morning. do you have a moment re. qbzr please?
<bialix> good afternoon, ask
<smartgpx> OK. trivial spelling error in the qci gui in lib\commit.py. I've corrected it on a local branch and generated a proposed patch. How do I submit the patch - email to a dev, or push back to LP?
<bialix> any way is good
<smartgpx> so can I email it to you so you can mentor my approach please?
<bialix> most of the time people push to LP and then do merge proposal
<bialix> if you e-mail, please e-mail to the qbzr list
<smartgpx> this is only a single-character change, but it's a good exercise with the tools for a newbie
<smartgpx> qbzr doesn't have a ML
<bialix> really?
<bialix> smartgpx: http://groups.google.com/group/qbzr
<bialix> sign in and you can send mails as in usual ML
<smartgpx> no - not really - yes, as you say, just realised it's on Google. Not mentioned on qbzr page at LP.
<bialix> yep
<bialix> there is no way to specify external ML on LP
<spirov92> bob2: i don't understand something...this describes how to set up my key with launchpad, but I'm actually using sftp and bzr upload to upload a site to the server. How do I set that up?
<smartgpx> I can't see how to attach a file with the Google interface - do I include the patch as plain text in the message body?
<bob2> spirov92: generate key
<spirov92> bob2: i did
<bob2> spirov92: ssh-copy-id user@remotehost
<bob2> spirov92: grab beer
<bialix> smartgpx: just send mail to qbzr@googlegroups.com
<spirov92> bob2: did that, still asking for user@remotehost's password
<bob2> spirov92: ssh to remote host, 'ls -ld ~/.ssh ~/.ssh/authorized_keys'
<bialix> smartgpx: you need to join the group first, select "not sending mails" if you don't want to get mails from ML
<bialix> smartgpx: but you can send your mails anyway
<spirov92> bob2: -rw-------  1 webmaster webmaster   58 Nov 10 14:54 /home/webmaster/.ssh/authorized_keys
<spirov92> bob2: also, drwx------  2 webmaster webmaster 4096 Nov 10 14:42 /home/webmaster/.ssh
<bob2> spirov92: perhaps your admin disabled it
<spirov92> bob2: in /home/webmaster/.ssh/authorized_keys it says "The agent has no identities."
<bob2> oh
<bob2> heh
<bob2> on localhost, 'ssh-add', then 'ssh-copyid remoteuser@remotehost'
<bob2> er ssh-copy-id
<spirov92> bob2: seems to work now, thanks a lot :)
<bob2> no worries
<bialix> smartgpx: you mail arrived, I'll answer later, OK?
<smartgpx> bialix: it was 'broken' -gvdm has replied. OK for now thanks.
<Amything> just started to use bazaar, does it make sense to use it to version control mysql database with it?
<SamB_XP> Amything: not very much sense, I think
<SamB_XP> don't those tend to be rather large ?
<SamB_XP> and ... non-textual?
<SamB_XP> Amything: what about the database do you want to version control ?
<SamB_XP> Amything: you may find http://ask.metafilter.com/85982/Is-there-a-MySQL-version-control-system-or-something instructive. It doesn't have anything to do with bzr specifically, but it seems to give reasonable advice on the subject ...
<hackter> hi !
<hackter> I have a python module contained in a package of several modules versionned with bzr
<smartgpx> is there anyone in who understands rich-root-formats and how to stop them causing me grief?
 * bialix raises a hand
<hackter> I would like to move that python module in its own project, versionned separately
<bialix> hackter: use fastimport plugin and fast-import-filter command
<hackter> is it possible to do that and keep all history of my python module ?
<hackter> bialix: hum ok, thank you :)
<bialix> smartgpx: I have success of using format1 plugin
<smartgpx> bialix: bzr branch lp:qbzr local_branch  - creates branch with branch format 7, repo fmt Packs6.
 * bialix don't remember what 7 and 6 means
<bialix> can you show me output of bzr info please?
<bialix> smartgpx: perhaps you want to use bzr branch --standalone lp:bzr xxx
<smartgpx> if I then bzr branch local_branch feature_branch then the feature branch is branch fmt 7 with repo fmt 2a
<bialix> smartgpx: are you using shared repo in 2a format?
<smartgpx> and then I can't merge back from modded feature into local!
<smartgpx> these are simply the defaults chosen by BzrExpl.
 * bialix trying to reproduce w/o format1
<bialix> ouch
<bialix> can you file a bug please against explorer?
<bialix> and provide exact sequence steps to reproduce?
<bialix> smartgpx: ^
<smartgpx> format1 isn't listed on http://bazaar-vcs.org/BzrPlugins
<smartgpx> bialix: Ok - so I'm not just being dumb... ?
<bialix> yep, it's not listed
<bialix> smartgpx: I dunno what's going on, but I can try to reproduce and check if there is bug in explorer
<bialix> plugin is here https://code.launchpad.net/~bialix/+junk/format1
<smartgpx> bialix: it might be that I am accepting the hint from BE to put the feature branch in a shared repo. I'll try as a plain branch..
 * bialix nods
<bialix> smartgpx: for standalone branches I can't reproduce your problem, even w/o my plugin
<bialix> but I'm not using BE for testin
 * bialix trying with explorer
<bialix> smartgpx: ok, I see
<bialix> smartgpx: so you trying to branch via BE, it recommends you to create shared repo, and by default it suggest using 2a format (2.0 default)
<bialix> that's a problem
<bialix> problem in BE
<bialix> smartgpx: we may want to upgrade qbzr trunk to 2a soon, can't say for sure when
<bialix> smartgpx: som I'd recommend you to do following:
<smartgpx> bialix: it's OK making feature_branch as a plain branch.
<smartgpx> Your description is nearly correct - BE recommends shared repo then just creates it as 2a
<bialix> 1) create shared repo in 1.9 format via BE: Init -> Shared repo -> Format: other -> 1.9
<bialix> 2) branch lp:qbzr into this shared repo
<bialix> 3) branch inside this shared repo won't bother you with recommendations for creating shared repo
<bialix> 4) ... prpfit?
<bialix> 4) ... profit?
<bialix> rats, don't like when typo ruins joke (c) vila
<Amything> SamB_XP: sry late reply but thanks :)
<smartgpx> bialix: thanks for your help - branch is up at lp:qbzr and Merge Proposal issued
<bialix> smartgpx: good!
<stefano-k> some days ago I started a question about qbzr translation... after my connection gone down...
<stefano-k> i'm translating qbzr in Italian.. but I have no idea how to translate bzr commands and terms (e.g. commit, bind, branch, working tree, push)
<bialix> stefano-k: I'd suggesting to look into transaltions for bzr-gtk and/or for similar hg/git tools
<bialix> stefano-k: also useful to look into svn books translated into Italian and check there
<bialix> stefano-k: ping
<stefano-k> bialix: thanks :-)
<stefano-k> so.. there are no specific guidelines for qbzr
<bialix> stefano-k: you need consistency
<bialix> it's very hard to translate DVCS terms to any language != English
<bialix> I had the same troubles with Russian translation
<bialix> in the end we setup glossary at ru_bzr group and decided on the desired variants for terms translations
<bialix> although several terms almost impossible to translate
<bialix> e.g. push
<bialix> there is just nothing the same short and expressive in Russian for this term
<bialix> English is much more compact and technical language
<bialix> stefano-k: you might start with "mechanical" translation, and then improve it based on feedback of other Italian spoken people
<stefano-k> in the other hand, you  can translate "push", but after you lose the term for the bzr documentation
<bialix> how's that?
<bialix> when we translate documentation to Russian we're also using the same glossary
<bialix> that's why I'm talking about consistency
<bialix> we have a proverb in Russian: it can be ugly but it should be the same across all places
<bialix> (this is rough translation)
<bialix> evening GaryvdM
<GaryvdM> Hi  - Is there a way to rebase a rev from a 2a branch to a 1.19 branch?
<GaryvdM> Hi bialix
<jelmer> GaryvdM: not using the rebase plugin at least
<stefano-k> but if you read the bzr reference, you have "push" command
<GaryvdM> Ah - smartgpx - you are here
<GaryvdM> And I see bialix had allready point out that you submitted your branch in the 2a format.
<smartgpx> Garyvdm: are you saying that what is currently on lp:~smartgpx is in the wrong fmt?
<smartgpx> I didn't pick up on bialix saying that
<GaryvdM> bialix: What are your thoughts about https://code.edge.launchpad.net/~craighewetson/qbzr/qrevert/+merge/14626 re pending merges causes all files to be checked
<bialix> GaryvdM: sorry, have not looked yet
<bialix> will try later
<bialix> GaryvdM_: sorry, have not looked yet; will try later
<GaryvdM_> Hi smartgpx: sorry - I only saw your question now in the log. My irc is in lossy mode :-(
<bialix> smartgpx: your branch on LP in 2a format
<bialix> smartgpx: that's one https://code.launchpad.net/~smartgpx/qbzr/qcommit_typo
<bialix> please delete it, then push again
<GaryvdM_> smartgpx: yes - I could not pull you change because the format is incompatable
<bialix> GaryvdM_: we need to upgrade to 2a soon, IMO
<GaryvdM_> bialix: How about now?
<bialix> I'm busy at work, if you want to do it -- I'll be happy
<smartgpx> Well, this newbie contributor is getting confused and demotivated.
<bialix> smartgpx: please don't!
<bialix> your change is small enough, we can apply it via diff+patch
<GaryvdM_> smartgpx: It seamed like you wanted to learn, but if you want me to I'll do it for you :-)
<smartgpx> (Can't help being confused.. I;ll shelve the demotivated...)
<smartgpx> I do want to learn. But there seem to be some artificial barriers. (ref. IGCs mail about community effort.)
<bialix> smartgpx: I'd blame bzr-explorer who made you drive into wrong direction
<bialix> but we just need to upgrade qbzr trunk to rich-capable format anyway, sooner or later
<GaryvdM_> bialix: do we maybe need to give some notification?
<bialix> according to official migration doc we don't need to delete old poor-roots trunk, jhust adding new branch in rich-roots and switch branch for trunk series
<bialix> so, we should send notification after we done
<smartgpx> No. BE by default made it impossible to merge back even on my own machine. But having kept the fmt such that I could mege back to the local branch I still PUSHed back in 2a. (Is the problem possibly the fmt that LP uses for a new PSUH?)
<smartgpx> PSUH -> PUSH
<GaryvdM> smartgpx: When you push to lp, it will have the same format as your local format, by default
<smartgpx> locally the branch I PUSHed is WT fmt6, Branch fmt7, repo Packs 6
<GaryvdM> smartgpx: If that is the case, maybe try pushing it again. to a new location in (like lp:~smartgpx/qbzr/qcommit_typo2)
<GaryvdM> smartgpx: I'm going to upgrade our branch now, so you don't have to worry about this.
<GaryvdM> smartgpx: I'll merge your change after I've upgraded.
<smartgpx> Garyvdm: my branch on lp is already gone
 * bialix bbl
<smartgpx> Garyvdm: right, pushed again using bzr cli this time, and proposed for merge
<GaryvdM> smartgpx: I've merged it.
<GaryvdM> smartgpx: Thanks for the fix. (My spelling is really bad :-()
<smartgpx> Garyvdm: so was the fmt right this time? (if so it points to an issue with BE, no?)
<GaryvdM> smartgpx: Yes the format was correct.
<GaryvdM> smartgpx: Are you sure that you did not push it from a different (upgraded) branch?
<smartgpx> Garyvdm: so if I push the same branch again with BE to a fresh destination can you check the fmt, please?
<GaryvdM> Sure
<smartgpx> (actually, it will probably be qpush that is the suspect.) here goes...
<smartgpx> right - its on ....qcommit_typo3
<smartgpx> Garyvdm: do you need a merge proposal, or will that confuse other players?
<GaryvdM> smartgpx: That was also in the correct format. (see https://code.edge.launchpad.net/~smartgpx/qbzr/qcommit_typo3)
<GaryvdM> smartgpx: no - don't do a merge proposal
<GaryvdM> You can see the format near the bottom
<GaryvdM> it is "Packs 6 (uses btree indexes, requires bzr 1.9)"
<GaryvdM> Bye
<RenatoSilva> verterok: hi
 * smartgpx tries an action message
<rehanift> Hello, is it safe to use a 2.0 bzr client with a 1.0 server?
<beuno> rehanift, yes, although not super recommended
<rehanift> ok, so it will not start using the new format? other user's who use 1.0 bzr clients will not be affected?
<LarstiQ> rehanift: if you branch a 1.0 branch into a 2.0 repository, it will upgrade
<LarstiQ> rehanift: but that is not related to version of servers or clients
<rehanift> so if I do a "checkout" with a 2.0 client from a 1.0 branch, it will keep the remote 1.0 branch format intact correct?
<LarstiQ> rehanift: yes, as long as you don't check out into a 2.0 repository
<LarstiQ> rehanift: if you don't use shared repositories, then the format will always be the same
<rehanift> ok, great
<rehanift> thank you so much
<mtaylor> is there a _good_ way to get the diff of just the changes in revision 1186.6.1 ?
<asabil> bzr diff -c 1186.6.1 ?
<mtaylor> (in other words - how do I know what the parent is so that I can fill in X in -rX..1186.6.1
<LarstiQ> mtaylor: -c
<mtaylor> really? cool
<LarstiQ> mtaylor: otherwise, use -r before:1186.6.1..1186.6.1
<mtaylor> LarstiQ: double cool--- both are good to know
<LarstiQ> mtaylor: (lifted from `bzr help revisionspec` btw)
 * mtaylor hides in corner
<LarstiQ> no no, I knew where to look for that :)
<mtaylor> revisionspecs are very flexible - which is nice... but also has that whole complex thing going on
<LarstiQ> yeah
<phoenixz> Hi there, the location where my bzr branch should push to has changed.. How do I update this change in myh branch?
<user234234> is this the right place to ask questions related to problems with Bazaar?
<phoenixz> user234234: Yes
<user234234> I am running into a weird error which I can't figure out. While trying to branch my launchpad project, I get the following error:
<user234234> "Error while executing branch,  [Errno 2] No such file or directory: u'C:/daga/workspace/cogmod2/.bzr/checkout/limbo/new-4/aux.py'-"
<phoenixz> user234234: but if you want an answer, you do have to ask your question..
<user234234> this happens both with command line and using an plugin for eclipse
<user234234> I am using windows 7
<user234234> I tried to run a virtual windows xp on the same computer and then it works fine
<rar> phoenixz: bzr push --remember /new/location
<user234234> also running ubuntu on another machine lets me branch this project fine
<user234234> I have googled this error, but cannot find any related cases
<user234234> any help would be appreciated
<rar> stick the bit of bazaar.log related to that operation somewhere we can see it?
<rar> sorry, .bzr.log
<rar> not sure where it'll be on 7, bzr version should tell you though
<user234234> ok, that took a little while to find
<user234234> Tue 2009-11-10 21:30:52 +0000
<user234234> 0.063  bzr arguments: [u'checkout', u'lp:~joachim-degreeff/cogmod2/0.2.0']
<user234234> 0.078  looking for plugins in C:/Users/user/AppData/Roaming/bazaar/2.0/plugins
<user234234> 0.078  looking for plugins in C:/Program Files/Bazaar/plugins
<user234234> 0.219  encoding stdout as sys.stdout encoding 'cp850'
<user234234> 1.514  bzr-svn: using Subversion 1.5.6 ()
<user234234> 3.152  falling back to default implementation
<user234234> 3.152  failed to load system host keys: [Errno 2] No such file or directory: 'C:\\Users\\user/.ssh/known_hosts'
<user234234> [ 3932] 2009-11-10 21:30:56.207 INFO: Connected (version 2.0, client Twisted)
<user234234> [ 3932] 2009-11-10 21:30:57.142 INFO: Authentication (publickey) successful!
<user234234> [ 3932] 2009-11-10 21:30:57.190 INFO: Secsh channel 1 opened.
<user234234> 6.958  creating repository in file:///C:/0.2.0/.bzr/.
<user234234> 6.989  creating branch <bzrlib.branch.BzrBranchFormat6 object at 0x01ED3F50> in file:///C:/0.2.0/.bzr/
<user234234> 7.176  Using fetch logic to copy between RemoteRepository(bzr+ssh://bazaar.launchpad.net/~joachim-
<user234234> degreeff/cogmod2/0.2.0/.bzr/)(<RemoteRepositoryFormat>) and KnitPackRepository
<user234234> ('file:///C:/0.2.0/.bzr/repository/')(<RepositoryFormatKnitPack1>)
<user234234> 7.176  fetch up to rev {jdegreeff@b110-pbb116-20091110113205-94b1c062ota3le8b}
<user234234> 7.910  opening working tree 'C:/0.2.0'
<user234234> 7.956  Traceback (most recent call last):
<user234234>   File "bzrlib\commands.pyo", line 842, in exception_to_return_code
<user234234>   File "bzrlib\commands.pyo", line 1037, in run_bzr
<user234234>   File "bzrlib\commands.pyo", line 654, in run_argv_aliases
<user234234>   File "bzrlib\builtins.pyo", line 1336, in run
<user234234>   File "bzrlib\bzrdir.pyo", line 1609, in create_workingtree
<user234234>   File "bzrlib\workingtree_4.pyo", line 1473, in initialize
<user234234>   File "bzrlib\transform.pyo", line 2147, in build_tree
<user234234>   File "bzrlib\transform.pyo", line 2240, in _build_tree
<user234234>   File "bzrlib\transform.pyo", line 2307, in _create_files
<user234234>   File "bzrlib\transform.pyo", line 1138, in create_file
<user234234> IOError: [Errno 2] No such file or directory: u'C:/0.2.0/.bzr/checkout/limbo/new-4/aux.py'
<user234234> 7.956  return code 3
<user234234> thats it
<user234234> any ideas?
<LarstiQ> user234234: no, that looks weird
<LarstiQ> user234234: (in the future, please don't paste that amount directly to the channel, but use a pastebin service)
<bialix> windows cannot create file with names conataining con, lpt, com and aux
<LarstiQ> oh
<LarstiQ> aux.py
<LarstiQ> right :/
<user234234> sorry
<rar> ha! that one went right past me.
<rar> alexander's is right, you need to call the file summat else.
<user234234> really, that's all?
<rar> yup.
<user234234> but why did it work on windos xp I wonder
<bialix> maybe this file is new?
<user234234> no, it has been there all the time
<rar> it might be silently failing on xp.
<bialix> I can't create such file on my xp
<rar> yeah, run `bzr diff` in the branch on xp
<rar> it'll tell you the file src/aux.py has been removed
<user234234> ok, could be
<user234234> I'll try to rename it and see if this solves the problem
<user234234> thanks for the suggestion!
<rar> I wish bazaar would tell you if a branch was valid on a given filesystem namespace
<rar> not that I often need to put code in places that only accept 8.3
<bialix> hmm, I forget, is there any way to set append_revisions_only property on remote branch w/o hitchiker?
<user234234> indeed, the file aux.py is missing in the folder on XP, so that must be the problem
<user234234> cheers for pointing it out
<hno> How do I get information about pending merges in the current working directory? I.e. revisions being merged and their log messages.
<mwhudson> hno: bzr st -v
<mwhudson> hno: has that and some other things
<hno> mwhudson: Does nothing for me.. same output as bzr st
<hno> Bazaar (bzr) 1.18.1
<lifeless> hno: what does bzr st output
<mwhudson> hno: then i suspect you don't have pending merges?
<lifeless> pastebin ftw
<hno> modified: [list] unknown: [list]
<lifeless> if thats the lot, you have no pending merges
<hno> I have. And .bzr/checkout/merge-hashes lists them..
<lifeless> hno: why do you think you have pending merges
<hno> because the changes I have in the tree is from a "bzr merge -c... /path/to/other/tree"
<lifeless> thats a cherrypick merge, it doesn't get recorded
<lifeless> you don't have pending merges.
<hno> gah.
<hno> why are they recorded in merge-hashes?
<lifeless> so that bzr revert knows whether it has to make a backup or not
<hno> so this means I won't get the changelog history of cherrypick merges references in the commit either?
<lifeless> thats correct
<hno> Is there any plans on fixing cherrypicks to be more of a proper bzr operation?
<hno> I mean with this level of tracking we have nothing to build on in bzr to improve compared to the manual merge tracking process we currently use for Squid.
<hno> getting the cherrypicked revisions recorded would help that a lot..
<lifeless> hno: yes, there are plans. No timeline
<hno> do you know how others are tracking backporting of changes to earlier branches?
<hno> with bzr..
<lifeless> they do merge -c, then commit with a clear message
<hno> and relying on manually keeping track of what has been backported just as we do..
<hno> with a risk of pairing mismatches..
<hno> Another related question: Is it possble to prerecord a log message while working on the tree, so it's available on commit? If so then I could script what we need in the log message so that it can be extracted properly by the change tracking..
<bob2> bzr help commit -> -F
<hno> then I need to script commit as well... was more hoping for something what would get automatically added to the log message template on bzr commit..
<lifeless> hno: its possible via a plugin
<hno> lifeless: An existing one, or by writing a new one?
<lifeless> there are existing ones, they may not match exactly what you want
<hno> hopefully at least good enough as starting point.
<bjp_> this the right channel to ask a loggerhead question?
<hno> lifeless: where can I find the existing ones?
<lifeless> the plugins page lists them all
<lifeless> bjp_: yes
<lifeless> s/all/many/
<hno> lifeless: Not obvious to me which ones of those may be related to this...
<lifeless> let me have a look
<bjp_> alright, I currently have loggerhead.conf to auto-publish a directory, and am serving it with apache.  This works fine and generates URLs like: server/foldername/branchname.
<bjp_> I can access the branches fine, but the auto-generated links at the top of the page link to server//branchname
<bjp_> so clicking on them goes to an invalid url
<bjp_> it's not a serious issue, just annoying, I was wondering if I'm missing something in my .conf file
<lifeless> AIUI loggerhead.conf is seriousl deprecated
<lifeless> mwhudson: ^
<bjp_> really? what else would you use?
<lifeless> bjp_: bzr serve --http <path>, or serve-branches [-- options here] <path?
<lifeless> hno: sorry, doesn't seem to be a matching plugin these days, I thought there was one
<hno> lifeless: ok.
<hno> lifeless: thanks anyway.
<bjp_> lifeless: what about for using the daemon?
#bzr 2009-11-11
<lifeless> bjp_: those are daemons
<bjp_> so will configuration file support be dropped eventually? it seems like it has a lot more options than just serve-branches
<rar> hmpf. okay, I now see how to fix it, but still not sure *why* r4781 broke my code
<rar> ah, now I do. before stopTest was being run before the final finally, which replaces the TestCase __dict__ and now it's being run afterwards
<rar> not the easiest diff in the world to read.
<bjp_> what is causing this? : Unsupported configuration: PasteDeploy not available, but loggerhead appears to be behind a proxy.
<lifeless> bjp_: you haven't installed python-paste-deploy
<lifeless> rar: sorry :)
<lifeless> what was syour code doin that this has broken
<rar> replacing a test with another one, but  keeping the original test around for later
<maxb> If a svn repository has switched from one layout to another during its lifetime, is it likely to completely confound even bzr-svn's sophisticated mappings?
<lifeless> rar: ?!
<rar> you also fixed the never-not-applicable bug though, so I could remove my workaround for that
<lifeless> maxb: I don't know - give it a go
<maxb> Well, it's dumping crash reports at me :-)
<lifeless> maxb: file bugs ;)
<maxb> against the mindset of people who rearrange their svn repositories? :-)
<lifeless> yes:)
<rar> basically it's a thing for raising a test result without having to run the test, as some of them blow up in violent, suite-destroying ways
<lifeless> rar: I am totally confused; is there code I can see?
<lifeless> I don't understand how a test can destroy a suite
<rar> well, test_breakin_harder likes hanging the process
<lifeless> it should be a lot more robust nowadays, I hammered on it recentl.
<rar> and there are some others that blow the stack on ironpython, and I've yet to track down what exactly is making jython die
<bjp_> ic
<rar> at any rate, it's a hack, but a useful one for the moment
<lifeless> rar: oh, you're working on other vms - cool
<jelmer> maxb, it shouldn't cause a crash at least, at most it should cause your history to be thinner than you would expect
<rar> anyway, the rev is fine, it just meant I needed to discover attrs_to_keep (understanding all of bzrlib.tests is... not a one sitting thing)
<lifeless> rar: I still don't get why you need to poke at that level
<rar> well, another for instance, currently if any of the test modules has an import that fails, the whole test run stops
<rar> some of the test modules import bz2 or signal or something, that other imps don't have
<lifeless> file a bu on that please
<lifeless> (the test suite not running)
<rar> I'm not really sure it's a bug, and the best fix I have has issues
<lifeless> I'd still like a bug :)
<lifeless> taggest selftest
<rar> the bits of this that aren't nasty workarounds I will try and get in
<rar> anyway, monkeypatched in a bit so it registers as a kind of failure instead, eg:
<rar> http://float.endofinternet.org/temp/bazaar_j_noncpython_bt.test_#bt.test_smart
<rar> (and the wide red bars just under that)
<thumper> is there a way to add a new file with the history of an existing one?
<thumper> for example having one file that you are breaking into two?
<thumper> or is that not possible?
<RAOF> thumper: You mean something like "bzr cp old new", right?  I'm fairly sure that's not (yet) supported, but is something that might be worked on at some point.
<thumper> RAOF: thanks
<spiv> jml: the room is open, btw
<naoki> Hello.
<naoki> Is there any plan to translate help strings? (ex: bzr help, bzr help commit, etc...)
<SuperMMX> does the bug #375013 fixed?
<ubottu> Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013
<mwhudson> SuperMMX: no
<SuperMMX> mwhudson: thanks, just asking
<mwhudson> SuperMMX: np, i understand it's trickier than you might thing
<mwhudson> *think
<bialix> Hi GaryvdM
<bialix> GaryvdM: I won't mind if you rename trunk2a
<GaryvdM> bialix: Ok - I'll do that now.
<bialix> wait a sec
<bialix> GaryvdM: I've just replied to your mail
<bialix> I have concern re stacked btanches.
 * GaryvdM goes to read it
<bialix> GaryvdM: does they will re-stack automatically?
<bialix> should we upgrade lp:qbzr/0.14 as well?
<GaryvdM> poor roots - lol
<GaryvdM> bialix: I think that stacked branches on launchpad will automaticly point to the renamed branch.
<GaryvdM> But I'll try double check
<bialix> poor roots (c) fullermd
<bialix> GaryvdM: ok, perhaps we just need to try and if things going wrong we need to rename them back
<GaryvdM> yes
<GaryvdM> bialix: But I'll try find out anyway before I make the change
<bialix> ok
<bialix> GaryvdM: I've sent mail to luks and ask about admin rights for you
<GaryvdM> Thanks
<bialix> let's increase bus factor ;-)
<GaryvdM> bialix: renaming trunk did break the stacked branches, so I reverted it.
 * GaryvdM => lunch
<bialix> GaryvdM: can you write it in mail please, so our beloved core devs will be aware of this problem?
<bialix> bon appetit
<GaryvdM> yes - I will.
<RenatoSilva> verterok: hi, we had a big blackout here, sorry
<RenatoSilva> verterok: I worked in the test failures, so I improved the code: http://bazaar.launchpad.net/~renatosilva/bzr-java-lib/encoding-fixes/revision/206
<RenatoSilva> verterok: tests are all ok here, both in mvn and eclipse: http://img195.imageshack.us/img195/2136/testsok.png
<RenatoSilva> verterok: would be nice if you merge rev206 in your branch to test in your environment
<GaryvdM> RenatoSilva: I was reading the irc log, and I saw that you said it you be nice if qlog has a search function.
<RenatoSilva> GaryvdM: yes
<RenatoSilva> GaryvdM: it has, but not for what I want
<RenatoSilva> GaryvdM: it does not search in the actual changes
<GaryvdM> RenatoSilva: Ah - It does integrate with bzr-search. Install that, index your branch, and it will also search in the file content. :-)
<RenatoSilva> GaryvdM: file content or file changes?
<GaryvdM> Um - not sure. Same as what bzr-search does. I think content.
<RenatoSilva> verterok: also, your hudson server successfully built the bzr-java-lib-xp (encoding fixes) :)
<RenatoSilva> GaryvdM: what I want is for example bzr search "print 'hi'", then get all the --revisions-- which have added or removed such a line
<GaryvdM> RenatoSilva: I see. - Please will you log a bug in bzr-search for that.
<RenatoSilva> GaryvdM: you are a bzr-search developer?
<GaryvdM> No - but I'm getting in to it.
<GaryvdM> I've submitted my first merge proposal.
<GaryvdM> RenatoSilva: lifeless is the author. If you read the comments in the code, you will see that he was thinking about that idea.
<bialix> GaryvdM: have you looked at https://code.launchpad.net/~craighewetson/qbzr/tag_from_qlog/+merge/13096 ?
<RenatoSilva> GaryvdM: bug 480684
<ubottu> Launchpad bug 480684 in bzr-search "Return matching revisions" [Undecided,New] https://launchpad.net/bugs/480684
<thrope> hi - is it possible to add something to .bzrignore to ignore symlinks
<bialix> thrope: nope
<thrope> ok thanks
<rar> presumably a precommit hook could filter them out though
<bialix> yep, but you need to explicitly ignore them then
<hno> Is there some way to subscribe to early notifications when a new version have been uploaded to launchpad?
<bialix> new version of what?
<hno> bzr
<bialix> there is bazaar-announce ML, not sure it will serve you well in the case of "early" notifications
<hno> No, that's late.. want to get notified when the release is available for download so I can push it to the Fedora updates-testing repository, ready to be pushed out as an update when the update is formally announced.
<bialix> I'm monitoring main bzr ML for the messages like this: bzr 2.0.x gone gold
<bialix> you need to ask for core devs maybe they can suggets something or improve their process
<hno> for example 2.0.2 was uploaded to launchpad a week ago, but not yet announced.
<hno> Guess I need to do the same..
<sivang> hi all
<sivang> I want to swipe my whole office to use bzr
<sivang> should I setup a bzr server on my machine to poeple could branch my code and push code to it ?
<sivang> I don't want a central repository
<sivang> I see on the docs there's no special need for a server, but everybody here is used to svn
<sivang> so..
<awilkins> sivang, Why not peruse http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html and see about persuading them that way?
<sivang> awilkins: I'd rather have bzr working for me, show them how easy it is and then be accepted without too much persuation
<awilkins> sivang, I'm using bzr on a few projects that still use SVN servers ; you can demonstrate all the advantages without divorcing yourself from the SVN server
<sivang> awilkins: right, I will read now the documentation about this
<sivang> awilkins: where the general guidlines and starting documention for bzr ? is James Black still working on docs ?
<smartgpx> sivang: try http://bazaar-vcs.org and then use the Documentation link at the top
<bialix> sivang: no, James Black no more participate in Bazaar project
<bialix> now Ian Clatworthy is our champion
<jsmith23> is there a way to shelve all changes? instead of going through one by one?
<gioele> jsmith23: bzr shelve --all
<smartgpx> bzr shelve --all ?  (bzr help shelve)
<jsmith23> gioele: smartgpx: sure enough, first line of the help
<jsmith23> thank you
<gioele> does anybody use Eclipse to develop bzr?
<gioele> how come the launchpad plugin now uses launchpad_username instead of [Launchpad] inside authentication.conf?
<bialix> gioele: I think it uses both
<gioele> bialix: it just complained that the login name was not set (it has been in auth.conf since ages). Using "bzr launchpad-login gioele" created a brand new entry in bazaar.conf (my ~/.bazaar/ is bzr-managed ;))
<bialix> without looking into lp code I'd say entry in bazaar.conf used as flag
<bialix> or maybe for lp: access?
<gioele> I found some off-by-one whitespace problems in builtins.py, should I correct them and send a patch?
<gioele> is there a way in bzrlib to send a message to the user? I'd like to ask her "Are you sure to continue? [Y/n]"
<bialix_> gioele: see ui package
<bialix_> there is ask_boolean
<gioele> bialix: thank you! (get_boolean, btw)
<bialix> my memory as sieve, silly me!
<maxb> Is there any programmatic way to query the format of a *remote* branch?
<beuno> maxb, via http you can get it, so I expect you need to look at a specific file
<LarstiQ> maxb: `bzr info remote` or use BzrDir
<maxb> LarstiQ: bzr info lp:bzr, for example, just says format: unnamed
<beuno> maxb, because it goes via bzr+ssh
<beuno> if you use http:..
<beuno> it will tell you the truth
<beuno> it;s something about the smart server
<maxb> hm
<LarstiQ> maxb: how about -v?
<maxb> LarstiQ: Just says the format is a remote one
<maxb> Is there any way to override ~/.bazaar/bazaar.conf settings on the command line?
<beuno> you need to fallback to vfs to read it
<beuno> maybe you can specify that in the API call
<maxb> Hmm. HOME=/dev/null bzr info lp:bzr
<maxb> hacky, but works
<maxb> Is is a shame there isn't a lphttp:
<fullermd> You can use nosmart+bzr+ssh (and I think nosmart+lp too), which falls back to VFS methods.
<fullermd> Yeah, nosmart+lp expands through to nosmart+bzr+ssh
<maxb> fullermd: yay, that's exactly what I need, thanks :-)
<Shirik> Hello all. I have a question: I have a situation where I just finished merging in some changes from what we will call our "trunk" into a development branch. I went to push it to that branch and got an error. After investigation, I determined someone already tried to make the same change to the branch. So I pulled and got diverging branches as expected, but what I want to do is
<Shirik> drop everything that is not mine, rather than merge
<Shirik> Is there a way I can do this?
<Shirik> I know that's the correct solution, I'm just not sure how exactly to go about doing it
<Shirik> Basically I have diverging branches and I just want to kill one of the branches
<Shirik> So currently I have a revision showing up as "missing" and I just want to kill that revision so it never gets merged in, I guess that's what I want to do
<bialix> Shirik: push --overwrite
<bialix> or uncommit
<Shirik> that worked, thanks
<thumper> if 2.1.0b2 is gold, why isn't it in the bzr-beta-ppa?
<thumper> also the bzr nightlies don't seem to be building either
<gioele> I'm writing a test for a little addition I made to cmd_commit. I expect bzr to ask me a question via get_boolean. How can I check that?
<lifeless> gioele: there is a testing UI factory
<thumper> lifeless: hi
<lifeless> gioele: where you can supply the inputs it gets
<thumper> lifeless: who is responsible for the PPAs?
<lifeless> spyuz
<lifeless> spyuz
<lifeless> bah
<lifeless> soyuz
<thumper> lifeless: who uploads the bzr stuff to the ppa?
<thumper> as the daily and beta are out of date
<thumper> and I've been bitten by a bug that jam has fixed
<thumper> bzr keeps crashing on me
<thumper> is very frustrating
<lifeless> jamesw  does the daily, johnf is working on fixing the beta, currently sorting out a bunch of packaging differences to make it more scriptable
<lifeless> jamesw is on leave
<thumper> I may just grab bzr.dev and use that
<thumper> for now
<thumper> :(
<thumper> not done that yet on this computer
<thumper> lifeless: what dependancies to I need to build bzr.dev fully?
<lifeless> apt-get build-dep bzr
<lifeless> + python-pyrex
<lifeless> bbiab
<gioele> lifeless: I had a look around that but I could not find method of TestCommit that I could use to assert "now this question is asked and a Y/n prompt is presented to the user"
<thumper> lifeless: poos
<thumper> lifeless: my crash is still in bzr.dev
<lifeless> thumper: whiss
<thumper> lifeless: I'm getting something like bug 461643
<ubottu> Launchpad bug 461643 in bzr "Can't commit, StaticTuple is not a tuple" [Undecided,Invalid] https://launchpad.net/bugs/461643
<thumper> lifeless: but this is with a clean bzr.dev and I ran make
 * thumper files a bug anyway
<thumper> WTF???
<thumper> lifeless: I thought I was running my new bzr.dev, but it seems it isn't
<thumper> g'ah
<thumper> ok, is fixed in dev
 * thumper needs new deb badly
<lifeless> gioele: I will try to look it up for you, at a meeting at the moment
<gioele> lifeless: thank you
<gioele> lifeless: anyway, I'm leaving but I sent a RFC on a tiny patch on the mailing list; I asked the same question in that mail
* lifeless changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b2 have gone gold! time to build those installers|  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Current pilot: -coming soon-
<taxilian> morning all
<taxilian> I have a plea for help =]
<taxilian> Long story short, a local branch got accidently bound to a remote branch, and then updated; all the changes in the local branch were lost
<taxilian> the local branch was in a shared repository, so hypothetically the data should still be in there somewhere
<taxilian> does anyone know how I could find/get to it?
<fullermd> They're there whether it's a shared repo or not.
<fullermd> You can probably use the heads plugin to take a guess at the revid.
<taxilian> even though the branch itself is now bound to a different branch?  and updated?
<taxilian> *looking for heads plugin*
<fullermd> And then use pull to set that as the head (after unbinding of course)
<fullermd> If you bound and update'd, but then didn't revert or anything, it's actually sitting right there as a merge rev, but there's no way to sweet-talk the UI into telling you that revid.
<taxilian> the plugin is called "heads"?
<fullermd> It's included in bzrtools these days.
<taxilian> ahh; I see it.  running it now.
<taxilian> thank you
<taxilian> I think I found the revision I need; how do I get to it now?  using bzr pull?
<taxilian> actually, no, it isn't listed there
<taxilian> none of the heads I need are listed :-(
<taxilian> rather none of the listed heads are the one I need
<fullermd> Are you running head --dead-only?
#bzr 2009-11-12
<taxilian> I wasn't; I tried --all, and it didn't show up there either
<fullermd> Well, if it doesn't show up in --all, it's not a dead; it's an ancestor of some other rev.
<fullermd> Did you commit after that update?
<taxilian> I did
<taxilian> because it still showed the change packages
<taxilian> so I thought they were still there
<fullermd> Well, then that's why it's not a head   :p
<taxilian> ok; is there still a way to fix it?
<fullermd> Well, they ARE there.
<taxilian> I know what the comments are, or at least some specific keys in them
<taxilian> would that help?
<fullermd> So, let's step back; what state of affairs do you want to end up with, and why is that different from the current?
<taxilian> I want to end up with the branch I had before I: bound to another branch, updated, and committed
<taxilian> and the reason it's different is that the branch I had had some new changes that should have been pushed to the branch I accidently bound to
<fullermd> OK, well they're there now.  Does it matter that they're there via a merge rather than pushed onto the lefthand ancestry?
<taxilian> but that's just it; they aren't there
<taxilian> bzr status -v lists all the "pending merges", but none of the changes are there
<taxilian> the new files are missing, the changes are reverted
<taxilian> no backups
<taxilian> this represents 4 days of work; you can understand why I'm a little agitated about it =]
<fullermd> ....
<fullermd> Something doesn't add up.
<taxilian> that's what I thought
<fullermd> If you commit'd, there won't be pending merges sitting around, because they won't be pending any more (being committed)
<taxilian> I uncommitted
<fullermd> Before or after you unbound?
<taxilian> but that is why I committed; I thought that even though I bound to another branch (the one I branched off of) and updated, that the changes would still be there, just waiting to be committed
<taxilian> here, let me tell you the whole sequence:
<fullermd> They would be.
<taxilian> bzr branch <remote branch>
<taxilian> bzr unbind
<taxilian> <change a bunch of stuff, work for 4 days>
<taxilian> bzr commit
<taxilian> bzr merge <remote branch>
<taxilian> bzr bind <remote branch>
<taxilian> bzr update
<taxilian> bzr status -v (at this point, files are gone, but still shows the pending merges)
<taxilian> <panic>
<taxilian> bzr commit (thinking that since the pending merges show, the files are still there)
<taxilian> <panic more> (they aren't)
<taxilian> bzr unbind
<taxilian> bzr uncommit
<taxilian> there I stand
<fullermd> So, the remote end still has that commit you made?
<taxilian> yes
<taxilian> presently
<fullermd> Which has all those revs in its ancestry.
<taxilian> the local should have all the revs in ancestry, since I was unbound when I did them
<taxilian> the remote does not
<fullermd> The remote does if you committed a merge of them while you were bound to it.
<taxilian> but that commit doesn't seem to have sent any files
<taxilian> because when I updated, the files and changes all magically disappeared
<fullermd> Stipulating that, it will still have sent the revs.
<taxilian> I'll check the remote log
<fullermd> You can't (barring minor magic) stuff around a rev without stuffing around its ancestors.
<taxilian> let us hope that I am no magician; give me a sec to dig a bit
<fullermd> Unless you tried to (which means at the least you dug up and did the push via writing code against bzrlib), you didn't.
<taxilian> nope; it acts as if the commit I made (Despite the claimed "pending merges") was a no-file merge
<fullermd> Forget files.  Look at the revs.
<taxilian> it's as if the update erased all my changes, but somehow didn't erase the "pending merges"
<taxilian> I'm looking at revs
<fullermd> Are you using -n0 on log?
<taxilian> there is a rev with the message I used on the commit, but none of the other ones are there
<taxilian> I am not
<taxilian> one sec
<taxilian> ahh, that looks more promising
<taxilian> give me a sec to try a revert
<fullermd> So you can use that to find the revid, and use pull to swap yourself around to that state.
<fullermd> I'm a bit suspicious of ending up with no files changes though.  Barring big bugs, merge wouldn't quietly do that given reasonable assumptions about prior states.
<taxilian> I will try that
<taxilian> thank you
<taxilian> yeah; that's why I'm so confused
<taxilian> I thought I'd tried this before and it worked as I expected
<fullermd> Generally, either suggesting the merge you did earlier was botched, or you ran something like 'revert .' after the update.
<taxilian> I can guarantee that was not the case; I built after the merge, and then I did a bind and an update; all the changes went away
<taxilian> this is bzr 1.18.1, incidently
<fullermd> I don't suppose it's a public branch?
<taxilian> it isn't
<fullermd> If you can pastebin a 'log -vn0' from before the point where you initally branch'd up through that last commit, we may be able to make some guesses as to what happened when.
<fullermd> But that may expose more info than you want.  Probably doesn't matter in itself, would just be informative.
<taxilian> give me a few minutes; I did find the files I need (thank you!) and I need to restore the branch so someone else can use it
<fullermd> I'd do 3 times:
<fullermd> 1) Preserve the existing (broken in aggregate, but containing all necessary pieces) state of the main branch by branch'ing it somewhere local
<fullermd> 2) 'fix' it by using pull/push/something to reset its head to the state prior to that (poking at log should reveal it to you)
<fullermd> 3) Do the same to 'your' branch
<fullermd> Then you're in a state to move forward, and you have a copy of the b0rkenness for analysis.
<taxilian> I'm just going to revert and then commit
<taxilian> so the history is intact
<fullermd> That...  doesn't some like what you want at all.
<fullermd> sound
<taxilian> ... it gets all my files back where I want them;
<taxilian> why is it not what I want?
<fullermd> Well, it leaves a big ugly lump in your history, for one.
<fullermd> And are you sure what you're reverting to is what you should be?  The weird state you ended up in suggests things awry.
<taxilian> I'm testing the build, but it looks like it is all restored
<taxilian> there is just one extra revision that somehow reverts it all back to before my work
<taxilian> if I revert back one sub-revision, it works fine
<fullermd> Well, it's your codebase.
<taxilian> hehe
<fullermd> From where I sit, there are only two states I'm confident are good: the remote branch before it got hit with the commit of that update pivot, and your local branch before your merge of the remote.
<fullermd> Everything after that, I question.  So if it were me, I'd back up to those two places and try going forward from there again.
<fullermd> You're sitting in front of more info about the code than I am, so if you're confident in that first merge, you can try going forward from there instead.
<taxilian> yeah, I'm looking over a full diff to make sure
<fullermd> I'd be very down on going forward from after that second merge though; just reverting the files and commiting a new rev on top will lose any annotations at the least.
<fullermd> Anyway, I must off.  I'm on serious plus time for sleep.
<taxilian> I appreciate your help
<taxilian> it was a lifesaver
<RenatoSilva> verterok: hi
<poolie> kfogel: i really wasn't feeling guilty
<poolie> i was just saying thanks
<kfogel> poolie: oh, I know; my first line there was just a joke.  I knew you'd already seen the joke, but this is open source, so there's always more audience for the same joke :-).
<poolie> Year of the Linux Desktop ;-)
<RenatoSilva> verterok: hi
<verterok> RenatoSilva: hi
<verterok> RenatoSilva: your patch for redstone xmlrpc is already fixed in 1.1.1 :)
<RenatoSilva> verterok: did you see my comments to you here yesterday?
<verterok> RenatoSilva: nope, crappy network connection
<RenatoSilva> verterok: you mean redstone guys have applied the fix? I see no status change in SF
<RenatoSilva> verterok: I think you have heard of the blackout here, that's why I was disconnected
<verterok> RenatoSilva: a different patch, but the same fix
<RenatoSilva> verterok: I saw you have merged the changes, with them I could run all the tests successfully (0 errors/failures) in mvn, eclipse and in hudson
<RenatoSilva> verterok: 1.1.1 is the version in the winXP repo here (I'm in Ubuntu now), but isn't it the same version since we beginned to work on this?
<RenatoSilva> verterok: I mean, I've got the impression that 1.1.1 is the unpatched version
<verterok> RenatoSilva: I did checjkut from their svn
<verterok> *checkout
<RenatoSilva> verterok: ok so it's not 1.1.1 right. I was testing yesterday: the 1.1.1 version causes test errors, when I replace it with the patched version, the errors dissapear
<RenatoSilva> verterok: it's weird but I was testing a few minutes ago, and now I'm getting errors (1 or 2) in winXP regarding file access/permission, both in eclipse and mvn
<verterok> RenatoSilva: I think that's my fault
<verterok> I changed a call from getCanonicalPath to getPath in the TestsConfig class
<RenatoSilva> verterok: that is, no errors/failures yesterday, but one or two errors today :( One thing different I've done is that I've updated bzr-xmloutput with the latest version from trunk (I think it was in rev 101 and I pulled 6 revs or so). Would that be the cause?
<RenatoSilva> verterok: hm, I don't remember if the test success was with the getPath stuff merged
<verterok> RenatoSilva: it's one line change, revert it ;)
<RenatoSilva> verterok: I was trying now to run the tests in Ubuntu, but I can't. The deb package from apt repo is 0.8.3, but I get errors with that version
<verterok> RenatoSilva: yes, it's quite old
<RenatoSilva> verterok: I tried to replace it with trunk, but failed. It's easy in windows, you just replace/update the xmloutput folder.  Here in Ubuntu it's not, can't get the plugin loaded by bzr, it seems that there are external metadata invloved. I tried to install the deb, and replace the dir with trunk, but didn't work either :(
<RenatoSilva> verterok: so you have uncommitted the getPath change?
<RenatoSilva> verterok: it is still there: I've done
<verterok> RenatoSilva: not yet
<RenatoSilva> s/I've done/http://bazaar.launchpad.net/~verterok/bzr-java-lib/encoding-and-test-fixes/revision/215
<RenatoSilva> you'll have to uncommit twice right? that will break my branch , right? (because I've merged that revision)
<verterok> no, I already merged your branch
<RenatoSilva> but my branch have merged yours
<verterok> RenatoSilva: I'll resolve the conflict :)
<RenatoSilva> hum, to undo the chnage you won't uncommit it, you'll do a new commit to get back to getCanonicalPath(), right?
<verterok> RenatoSilva: I changed that because I'm having probles with a path containing: Ã³
<verterok> RenatoSilva: right
 * RenatoSilva suffers of the uncommit syndrome
<RenatoSilva> verterok: let me go back to windows, I'll change that line and see if the tests pass. I'll rollback the xmloutput too
<RenatoSilva> verterok: back in winxp
<RenatoSilva> verterok: yesterday: http://img195.imageshack.us/img195/2136/testsok.png
<RenatoSilva> verterok: when I go back to getCanonicalPath, I get 5 errors
<verterok> ouch
<RenatoSilva> verterok: if I keep getPath, I get only 1 error
<verterok> RenatoSilva: I'm getting errors in linux with getPath
<RenatoSilva> verterok: this one? http://steppenwolf.selfip.net/hudson/job/bzr-java-lib%20%28encoding%20and%20tests%20fixes%29/org.vcs.bazaar.client$bzr-java-lib/16/testReport/org.vcs.bazaar.client/BazaarClientTest/testAnnotate/?
<verterok> RenatoSilva: yeap
<RenatoSilva> it's the same string except for the leading /home in the actual version
<RenatoSilva> verterok: do you know how to install the trunk version of bzr-xmloutput in Ubuntu? That way I could also run the tests in *nix, and check the errors
<RenatoSilva> so simple in win, but not in linux
<verterok> RenatoSilva: first unintall the package
<RenatoSilva> already unisntalled it
<verterok> RenatoSilva: and after that: mkdir ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr branch lp:bzr-xmloutput xmloutput
<RenatoSilva> verterok: nice! I'll try that
<RenatoSilva> verterok: I've continuously uncommitting the recent changes in xmloutput's trunk
<RenatoSilva> verterok: getting different ammount of errors on each
<verterok> RenatoSilva: the hudson instance is using xmloutput trunk
 * RenatoSilva uncommitting till find any working rev
<verterok> RenatoSilva: what errors are you getting?
<RenatoSilva> verterok: reverted a few changes and didn't get it working, let me go back to tip and show you the error
<lifeless> verterok: why don't you use subunit2junitxml in http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/lastBuild/testReport/
<verterok> lifeless: good point, actually the bzr-xmloutput job isn't configure yet, I was trying to use pyjunitxml
<RenatoSilva> verterok: you're using xmloutput trunk in hudson? then it may something with my local machine, just passed all tests there: http://steppenwolf.selfip.net/hudson/job/bzr-java-lib-xp%20%28encoding%20and%20tests%20fixes%29/21/
<lifeless> verterok: bzr selftest xmloutput --subunit | subunit2junitxml -o tests.xml
<verterok> lifeless: oohhh, nice!
 * verterok update the job config
<lifeless> you'll need python-junitxml, subunit-0.0.1 installed
<verterok> lifeless: is there a package/ppa?
<lifeless> its all in karmic
<lifeless> and yes, there is a usbunit ppa or two
<verterok> even better! :)
<RenatoSilva> verterok: with mvn I get 1 error: http://pastie.org/694861.txt
<verterok> lifeless: I can't find pyjunitxml :/
<RenatoSilva> verterok: O arquivo j\xe1 est\xe1 sendo usado por outro processo. == the file is already being used for another project
<RenatoSilva> verterok: * by another proecess
<verterok> RenatoSilva: yes, that's weird..the same test fails all the time?
<RenatoSilva> verterok: let me run again
<lifeless> verterok: apt-get install python-junitxml
<verterok> lifeless: yes, it can't find it
<lifeless> checking
<lifeless> I may not have managed to get it synced to ubuntu before release
<RenatoSilva> verterok: different error now! org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: Permission denied: "C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests658081888924229416/working_copies/unknowns/.bzr/branch/lock/held": [Error 5] Acesso negado
<verterok> lifeless: oh, ok. I can use the debian deb :)
<verterok> RenatoSilva: yes, looks like a race condition...but we don't use threads..so this is weird
<lifeless> verterok: do you hold open multiple locks?
<verterok> lifeless: I don't open locks :)
<verterok> lifeless: xmloutput starts a long running xmlrpc service, and bzr-java-lib sends requests (commands) to it
<verterok> lifeless: plain bzr CLI commands
<verterok> lifeless: the xmlrpc service just use some hacks to get the output but it basically calls run_bzr
<RenatoSilva> verterok: man, that's crazzy, it was working perfectly yesteday. What I did to cause this?
<RenatoSilva> verterok: tested the getPath, and xmloutput, didn't work
<verterok> RenatoSilva: did you updated bzr/xmloutput/python/anything? :)
<RenatoSilva> verterok: well I've installed AVG9, can't see anything else new I've done
<RenatoSilva> verterok: as I said I've pulled the latest changes (5 or 6 revs) from trunk in xmloutput
<verterok> RenatoSilva: what's AVG9? :)
<RenatoSilva> verterok: but I uncommitted them till get to the latest merge you did from my fixes, and I get errors still
<RenatoSilva> verterok: anti-virus :)
<verterok> RenatoSilva: I think there are some issues with anti-virus and bzr...but I'm not sure
<RenatoSilva> verterok: man, the errors are random
<verterok> lifeless: do you know? ^
<RenatoSilva> verterok: I'm running  in eclipse, I had 1 error, now I have 3 errors
<lifeless> antivirus does ten to interfere
<RenatoSilva> verterok: des any process (bzr/python) is started with another user by any chance?
<verterok> RenatoSilva: nope
<RenatoSilva> oh, can't turn AVG off :(
<lifeless> verterok: did you get that deb?
<verterok> lifeless: I'm waiting the upgrade to finish
<lifeless> :P
<lifeless> verterok: yeah, it didn't hit ubuntu for some reason. its in unstable and testing
<RenatoSilva> verterok: deactivated AVG and win firewall, but still getting erros :(
<RenatoSilva> verterok: random errors :(
<verterok> hmm, that's weird
<verterok> :(
<RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: unknown command "C:\Arquivos de programas\Bazaar\bzr.exe"
<RenatoSilva> verterok: also access denied
<RenatoSilva> how can it tell C:\Arquivos de programas\Bazaar\bzr.exe is unknown, but just sometimes
<_Andrew> heya
<lifeless> verterok: still failing :P
<lifeless> _Andrew: hai
<verterok> lifeless: yeap
<verterok> lifeless: https://pastebin.canonical.com/24652/
<verterok> ooops, wrong pastebin, sorry
<verterok> lifeless: http://pastebin.ubuntu.com/316584/
<lifeless> verterok: I can read both :P
<verterok> lifeless: I know...but you know, I should use public pastebin :)
<lifeless> verterok: can you branch lp:pyjunitxml
<verterok> sure
<lifeless> and run python -m subunit.run junitxml.test_suite | subunit-stats
<verterok> lifeless: all good
<lifeless> bahhhh
 * lifeless hates datetime
<verterok> lifeless: the utcnow() is the offending bit :)
<lifeless> well
<lifeless> subunit should be calling time()
<lifeless> what subunit version did you end up with ?
<lifeless> actually, do this:
<verterok> lifeless: 0.0.2-1
<lifeless> bzr selftest --subunit xmloutput | grep -v 'time:' | subunit2junitxml -o tests.xml
<verterok> ok
<lifeless> if that fixes it, please file a bug on pyjunitxml
<verterok> lifeless: yeap, it worked now
<lifeless> so subunit in bzr generates Zulu timestamps
<lifeless> utc == zulu, but python is DAFT
<lifeless> verterok: \o/ looks nice
<verterok> :)
<verterok> lifeless: thanks!
<lifeless> anytime ;)
<lifeless> show the u1 folk:P
<verterok> lifeless: already did it to lucio ;)
<_Andrew> I want to know if it's possible to force people to update for the the repo they cloned from. The reason I ask this is because we want "trunk" and then "live" branches but we want people contributing to trunk in a centralized fashion
<lifeless> verterok: heh, I didn't see it on the channel ;P
<verterok> lifeless: a while back :)
<lifeless> _Andrew: update for ?
<_Andrew> ah sorry
<verterok> lifeless: Bug #481119
<ubottu> Launchpad bug 481119 in pyjunitxml "TypeError while running bzr selftest --subunit | subunit2junitxml" [Undecided,New] https://launchpad.net/bugs/481119
<_Andrew> I meant when people push to trunk force them to update first?
<lifeless> verterok: yes but it wasn't working before ;)
<verterok> good point :)
<lifeless> _Andrew: set the append_revisions_only config setting
<_Andrew> ok
<_Andrew> Sorry I'm confused about this option
<_Andrew> When I init with it in "trunk" and 2 people clone trunk
<_Andrew> person one pushes to trunk, and then person 2 does the same thing..
<_Andrew> Does that mean person 2 will be forced to update first?
<lifeless> yes
<_Andrew> sweet
<lifeless> mwhudson_: http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/
<_Andrew> That's exactly what I need
<lifeless> mwhudson_: you can click on the test grapho too, to get details
<verterok> lifeless: I'm adding pylint ;)
<lifeless> is there a lugin, or just via shell commands?
<verterok> lifeless: via shell, but there is the Violations plugin, that knows how to read pylint output
<RenatoSilva> verterok: maybe the errors are because of the branch format of xmloutput you've upgraded to?
<RenatoSilva> I'm afraid of installing bzr 2. Should I?
<RenatoSilva> does bzr 2 work just fine with old branch formats?
<verterok> RenatoSilva: yes, you should :) using 2a is a pleasure
<verterok> RenatoSilva: yes
<RenatoSilva> verterok: I've installed xmloutput 0.8.4 using the installer, checking if the errros are at least constant
<RenatoSilva> verterok: what is better in the new format? just faster?
<verterok> RenatoSilva: speed is one of bug advantages
<verterok> *big
<RenatoSilva> what other advantages? did you get any trouble after upgrading?
<RenatoSilva> the errors here are still random, but not the same errors I had before
<verterok> RenatoSilva: no, I'm using it in every new project..and plan to move bzr-eclipse/java-lib to it in the near future
<RenatoSilva> verterok: I get an error when branching ~/bzr-xmloutput/encoding-fixes-388300 :( because of the branch format. It is a stacked branch :(
<verterok> RenatoSilva: yes, you need to use the new format, or avoid stacking
<RenatoSilva> maybe that error should not happen
<RenatoSilva> I don't know how to avoid stacking
<RenatoSilva> or migrate a stacked branch
<verterok> RenatoSilva: neither me, I never did it :/
<RenatoSilva> verterok: afaik you just can't
<RenatoSilva> avoid stacking
<verterok> RenatoSilva: I can put a tarball somewhere if you need to get trunk
<RenatoSilva> guys, if I create a stackied branch and the main one gets upgrated to the new format, is it possible to recover the stacked branch?
<RenatoSilva> verterok: I want to get my old branch, it's totally broken now :(
<RenatoSilva> verterok: not sure why but I can bzr branch trunk
<RenatoSilva> just like bzr 1.18 can handle the new format
<verterok> RenatoSilva: did you tried doing the upgrade in lp?
<RenatoSilva> can it?
<verterok> RenatoSilva: bzr upgrade --2a lp:~/bzr-xmloutput/encoding-fixes-388300
<RenatoSilva> verterok: you mean a command pointing directly to the lp copy?
<verterok> RenatoSilva: I upgraded xmloutput, bzr-hudson/jira like that
<RenatoSilva> verterok: but 2a is availablr only in bzr 2 right? will install and try. What I don't understand is why we can branch the 2a branch with bzr 1.18, I tought it would not be possible
<verterok> RenatoSilva: bzr upgrade --help
<verterok> that should show you the supported formats
<RenatoSilva> 2a is there, weird
<RenatoSilva> if 1.18 already supports 2a, then what's the point of bzr 2?
<RenatoSilva> I thought it was just the branch format
<RenatoSilva> verterok: installed bzr 2, it comes with xmloutput 0.8.5, but where is the SimpleXMLRPCServer.py?
<verterok> RenatoSilva: it should be included...right?
<verterok> RenatoSilva: I don't know much about the win-installers
<RenatoSilva> it's not there, let me run the tests
 * verterok heads to bed
<verterok> RenatoSilva: if SimpleXMLRPCServer.py is missing, please file a bug in bzr about the broken xmloutput in the installer
<RenatoSilva> ok, see you, I'll try to fix things here
<verterok> RenatoSilva: I need to sleep a few hours, seeya later!
<RAOF> RenatoSilva: bzr 2 changed the default format to 2a; 2a was supported for a while before bzr 2.0
<RenatoSilva> see you :) thanks
<RenatoSilva> RAOF: ok
<verterok> later all!
<verterok> lifeless: http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/violations/
<lifeless> james_w: btw, upgrade bzr-build* to 2a :)
<_Andrew> um
<_Andrew> When I use  --append-revisions-only  to init a branch and then clone it to branch1 and branch2. If I push a change up to trunk in branch1 and then do to same in branch2 it complains that the branches have diverged rather then force me to update
<_Andrew> Is there anyway to prevent the branches from diverging due to users forgetting to update beforehand ?
<RenatoSilva> Anyone has any idea of what could be causing these errors? http://pastie.org/694933.txt
<RenatoSilva> unknown command "c:\Arquivos de programas\Bazaar\bzr.exe"  ???
<RenatoSilva> Access denied ???
<lifeless> _Andrew: no, people can do strange things ;)
<lifeless> verterok: the pylint output is harsh
<lifeless> pyflakes with the  lazy imprt patch would be better
<_Andrew> There's no way to do that you mean?
<_Andrew> because it's creating problems in the office
<mwhudson> pylint is really great at producing masses of output
<bob2> yay for pyflakes
<RenatoSilva> anyone invoved with win installers? where is xmloutput/SimpleXMLRpcServer?
<_Andrew> ah...
<_Andrew> so I figured I am doing this wrong
<_Andrew> My developers need to do bzr checkout... not bzr branch or clone
<bob2> maybe
<bob2> that has potential pitfalls of its own
<_Andrew> That way they can't screw up and make their own branches that need merging
<_Andrew> oh really?
<bob2> merging isn't a bad thing
<_Andrew> What are the problems?
<bob2> imvho the result of doing 'bzr up' in a bound branch with local changes is a bit confusing
<_Andrew> ah
<_Andrew> The problem is that we need to do this way otherwise people keep screwing up the trunk branch
<_Andrew> They try to push without updating then get confused with the merge process
<_Andrew> Then there are tons of conflicts
<bob2> well, if they ever do a "commit --local", they'll have the same problem
<bob2> and those conflicts can occur with 'bzr up', too
<_Andrew> you're right about that
 * RenatoSilva is grrrrrrr with random test errors
<RenatoSilva> anyone with bzr + mvn+ up-to-date winXP?
<RenatoSilva> I would like some help with testing a LP branch
<poolie1> RenatoSilva: what particular problem?
<RenatoSilva> poolie1: do you have the logs there? I pasted some links. Basically  --random-- errors when testing bzr-java-lib
<poolie1> what do you mean by testing the branch?
<RenatoSilva> poolie1: errors about access denied, bzr.exe not found (showing the correct path)
<poolie1> i didn't see the logs
<RenatoSilva> poolie1: unit testing
<poolie1> running tests located in that branch?
<RenatoSilva> poolie1: you'd have to branch bzr-java-lib
<poolie1> what's the url?
<RenatoSilva> poolie1: lp:~verterok/bzr-java-lib/encoding-and-test-fixes
<RenatoSilva> poolie1: no
<RenatoSilva> poolie1: ~renatosilva/bzr-java-lib/encoding-fixes
<RenatoSilva> they're almost the same
<RenatoSilva> poolie1: I've got one specific test method running, and randomly failing/passing
<RenatoSilva> poolie1: then I've got the .bzr.log for each case separately
<poolie1> paste the log url again pls?
<RenatoSilva> poolie1: the only relevant diff is that the success log has new lines, no error info in the failing log
<RenatoSilva> poolie1: http://pastie.org/695026.txt
<poolie1> sorry i really have no idea about this
<poolie1> better ask gg or someone
<RenatoSilva> poolie1: the bzr log there is the success log, with the new lines that are supressed when the test fails (see the '>>>>>>>>>')
<RenatoSilva> poolie1: ok will show that to Guillermo
<RenatoSilva> poolie1: but did you get the branch?
<RenatoSilva> would appreciate if someone could test bzr-java-lib
<RenatoSilva> in winxp
<RenatoSilva> poolie1: the only thing I can think of is that the win updates have introduced the problem
<RenatoSilva> poolie1: it was working yesterday! http://img195.imageshack.us/img195/2136/testsok.png
<RenatoSilva> what I think is so weird is: how can I get access denied errors?
<RenatoSilva> I wonder if it's rather related to the new 2a format
<quicksilver> ooh scary : bzr: ERROR: exceptions.KeyError
<poolie1> jam i don't understand the cover letter of https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-update-by-delta-bug/+merge/14628
<bialix> quicksilver: LOL
<poolie1> good night all
<poolie1> lotzman, hey?
<poolie1> i'd almost rename the role but it might be too obscure
<bialix> poolie: ooh, I've lost your joke. Night.
 * bialix interesting why poolie joking from me?
<bialix> hi GaryvdM
<GaryvdM> Hi
<GaryvdM> I'm working on the qrevert changes - I found a few other issues.
<GaryvdM> bialix: I just experienced the qadd/select all bug, but I have not looked into it yet.
<bialix> GaryvdM: ok
<bialix> GaryvdM: re qrevert changes: I think "Forget pending merges" will be good label, is not?
<bialix> GaryvdM: I'm planning to finish off encoding patch from naoki
<GaryvdM> I don't know. I've not thought about, I'm just looking at the behaviour side of the design
<GaryvdM> bialix: cool
<bialix> that's ok, we can polish labels later
<bialix> I found interesting bug with our qsubprocess last night
<bialix> it's related to get_boolean
<bialix> I've already committed fix, but it seems we should be aware about the places where we trying to send strings with \n inside
<GaryvdM> ok
<bialix> GaryvdM: I want to move cmd_qsubprocess to subprocess.py
<bialix> they are closely related and depend each from other
<gioele> can I raise an exception "softer" than BzrCommandError? BzrCommandError says "bzr: ERROR: Commit cancelled", given that the user cancelled the commit, I don't see that as an ERROR, just a message
<_Andrew> anyone know why my "trunk" doesn't update when I commit changes to it?
<gioele> _Andrew: what do you mean with "update"?
<_Andrew> eh, sorry. I mean doesn't show files I add
<_Andrew> say I bzr init trunk
<_Andrew> then bzr checkout
<_Andrew> If I change files in my checkout and commit it doesn't update the files in the trunk dir?
<fullermd> If the trunk is across a remote protocol, it won't.  Remote protocols don't touch the working tree.
<gioele> _Andrew: if you commit in a bound checkout the changes will go back to the bound branch, but you will not see those changes in the other working trees, including the one you checked out from. Try to update the trunk
<_Andrew> what if multiple people update the trunk?
<_Andrew> Will that screw it up with different users doing bzr update on the same folder?
<fullermd> Perhaps the better question is whether you really need a WT with that branch.
<_Andrew> I think this plugin does what I want. https://code.launchpad.net/~bzr/bzr-push-and-update/trunk
<fullermd> That just automates running the update.
<_Andrew> Can't I just add a hook script then?
<fullermd> That's what push-and-update is   :p
<_Andrew> ah
<_Andrew> That's what I thought
<_Andrew> Then I should use that
<fullermd> Generally, though, I'd tend toward just whacking the WT in the first place.  No reason to have it there.
<_Andrew> WT?
<knielsen> hi, I'm using bzr 2.0.2. One of the repos I'm using at Launchpad switched to format 2a, so I think I need a new shared repo with this format. I'm trying both bzr upgrade and (on another box) bzr init-repo --2a and new branching. But I'm having some problems
<fullermd> _Andrew: Working Tree.
<knielsen> I'm using the MySQL and MariaDB trees, and both new bzr branch lp:maria and convert of old shared repo is impossibly slow. Running for > 4 hours now and only 20000/59443 revisions transfered
<_Andrew> ah
<fullermd> knielsen: I'm pretty sure MySQL isn't in 2a yet, so if you're branching it into a 2a repository it's going to convert on the fly.  Which takes a long time.
<knielsen> any suggestions for a better way to be able to access format 2a branches from the same shared repo as MySQL/MariaDB? Or do I just need to let it run for however many hours?
<fullermd> knielsen: (and will probably make you incompatible with upstream, as I don't think they're using rich-root repos)
<fullermd> Why do you want to share a repo across projects without any common history anyway?  Seems kinda pointless.
<knielsen> fullermd: hm, bummer. So I'll need to use two different shared repos then it seems? One for projects with old format and one for new format?
<fullermd> Well, I generally just use a different shared repo for each project.  There's no gain in it when there's no history to share.
<maxb> Hi, I am struggling to decide whether I should recommend Bazaar or Mercurial to my workplace - can anyone point me to anything they think I should read?
<knielsen> problem is that then you have to work in completely different subtrees... but ok, I can probably manage thanks for suggestion
<fullermd> Well, I do anyway.  There's ~/work/projfoo and ~/work/projbar and so on...
<_Andrew> Where do I put hooks on the server side?
<_Andrew> in the .bzr dir in a working copy?
<_Andrew> .bzr/plugins ?
<fullermd> No, plugins either get installed in the system-wide lib dir or per-user ~/.bazaar/plugins/
<fullermd> Some may have to be enabled in branch.conf, some don't.
<fullermd> But in the case of push-and-update, server side is irrelevant; it runs from the client side.
<_Andrew> Everyone is has their own branch on one machine
<_Andrew> on**
<_Andrew> maybe I can just enable the plugin system wide?
<GaryvdM> maxb: http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html
<maxb> hmm, Bazaar Explorer looks nice.... not for me, but could be a great selling point for the less technical Windows users
<bialix> maxb: what's most important for your workplace?
<maxb> hmm, many things. I care most about having a vcs with good support for a code-reviewing feature-branch based workflow
<bialix> that's very broad
<bialix> hg" all branches in one repo
<bialix> bzr: every branch in separate directory
<bialix> for many people this is show stopper
<bialix> code review: depends on the system you will use
<bialix> it seems like Review Board supporting both hg and bzr
<bialix> retvield? maybe supports bzr, I've commented on the patch for bzr support while ago, but hg should be there already 'cause it's google choice
<maxb> hg can be used in a very bzr-like manner too - you just treat every hg repository like you would a bzr branch
<bialix> Windows users? TortoiseHg rules out bzr
<bialix> unless you see Bazaar Explorer as better tool
<bialix> maxb: hg can be as bzr, but bzr cannot be as hg with branches
<bialix> unless you *call* Bazaar Explorer as better tool
<maxb> Indeed, one of my concerns about bzr is what to do with branches whose fate is never to be merged into trunk, but whose history must be kept
<maxb> (e.g. mainenance / cherry pick / failed feature branches)
<bialix> maxb: recently on SO was question about such branches, hg book seems to suggest keep such branches in separate repos
<maxb> SO ?
<bialix> stackoverflow
 * maxb googles
<bialix> maxb: http://stackoverflow.com/questions/1672487/mercurial-why-would-you-maintain-separate-branches-versions-of-software-in-separ
<maxb> Indeed. At which point Mercurial's "advantage" of being able to stash such things in a single repository then evaporates
<bialix> maxb: even if you don't need Bazaar Explorer there is still hidden power ready for you: QBzr
<maxb> On the other hand, hgwebdir rather beats loggerhead in good listing of many branches
<bialix> it seems so
<bialix> every tool has it's power and lower
<maxb> I'm surprised at the bzr benchmarks in GaryvdM's links, I thought hg was faster
<bialix> maxb: although I'm addicted to bzr, I can't say honestly that bzr is much greater than hg. There is places where hg clearly better, and there is places where bzr is clearly better. It depends what is most important for you, that's what I think about bzr vs hg comparison
 * maxb ponders attempting to bzr->hg the launchpad repository for a subjective speed test
<bialix> maxb: actually there is no big and comprehensive benchmarks for bzr 2a format
<bialix> yet
<maxb> http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html claims to be benchmarking the firefox repository under bzr 2.0.0
<bialix> I can't comment those numbers, maybe igc can
<_Andrew> can anyone point me in the direction of a simple post commit hook script?
<awilkins> stackoverflow guy is wrong  ; SVN uses branches to define tags, not the other way
<awilkins> Branching is cheap in SVN so they overloaded it's use to create tags instead of doing it the way CVS does
<awilkins> DVCS systems actually go back to the CVS way of labelling a specific revision albeit on a global basis and not per-file
<awilkins> I would say that the folder-per-branch vs one-folder-with-all-branches thing is only a showstopper for those people who don't bother thinking about things...
<bialix> awilkins: you're right, but many people don't bother even thinking
<bialix> _Andrew: in which sense?
<_Andrew> oh geeze nevermind
<GaryvdM> Grr @ _Andrew
<Tak> has nobody noticed that the guy-with-hat avatar in the bzr docs is extremely phallic?
<bialix> Tak: hmm, what about bzr logo then?
<fullermd> Well, if that's phallic, it's a phallus in need of some corrective surgery...
<GaryvdM> bailix: http://bazaar-vcs.org/stuart
<GaryvdM> oh - know - that must be something else
<bialix> GaryvdM: :-)
<bialix> tortoise in attack?
<bialix> GaryvdM: it seems I'm missing your joke
<GaryvdM> No - joke, I was confused
<GaryvdM> tak: who are you talking about?
<bialix> GaryvdM: perhaps http://doc.bazaar-vcs.org/bzr.2.0.2/en/user-guide/using_gatekeepers.html
<bialix> gatekeeper in the brown hat
<GaryvdM> Oh - ok
<Tak> yes, that
<bialix> GaryvdM: thanks
<Tak> "We have .NET and Objective-C bindings in progress" <= anyone know where I can find more info?
<bialix> Tak: Objective-C I believe it's what pilky doing
<Tak> and the other? ;-)
<bialix> bzr gui from mac
<bialix> .NET?
<bialix> I dunno
<bialix> it should be something about integration of bzr into MS Visual Studio'
<bialix> or maybe what Martin (rar?) doing
<bialix> Martin's work on Iropython and jython
<Pilky> someone called?
<Pilky> Tak: where's that quote from?
<GaryvdM_> bialix: Re: bug 481254 - I think we will have to try just reproduce it our selfs.
<ubottu> Launchpad bug 481254 in qbzr "qdiff failed with "out of memory" error while processing 73 MB file" [Medium,Confirmed] https://launchpad.net/bugs/481254
<GaryvdM_> bialix: Re: bug 481254 - I think we will have to try just reproduce it our selfs.
<ubottu> Launchpad bug 481254 in qbzr "qdiff failed with "out of memory" error while processing 73 MB file" [Medium,Confirmed] https://launchpad.net/bugs/481254
<bialix> GaryvdM_: feel free to ask more questions, I can work as translator proxy
<bialix> Vologymyr (Casufi) is not very good in English
<GaryvdM_> bialix: no more questions to the user - I'm sure that it is not to hard to reproduce, and to fix, I will need to reproduce it my self.
<GaryvdM_> bialix: just need time...
<bialix> as usual :-)
<bialix> GaryvdM_: ping
<bialix> any idea what's this: QLayout: Attempting to add QLayout "" to QWidget "", which already has a layout
<bialix> got while testing naoki's patch
<Lo-lan-do> Hi all
<Lo-lan-do> I'm having problems using basic auth over https, when the same branch accessed over http works fine with the same authentication.conf
<Lo-lan-do> Any hints?
<GaryvdM_> bialix: When you init a layout, you pass it a parent widget. This sets the widgets layout to the layout you just init__ed
<GaryvdM_> bialix: you can't do that more than once.
<bialix> GaryvdM_: I see
 * GaryvdM_ => tv
<bialix> GaryvdM_: QtGui.HBoxLayout() w/o parameters fix this
<bialix> naoki: ping
<phinze> question from our sysadmin: "can I just add two random files into a bzr branch on VPR09 which having any checkout"
<phinze> "I just have one file I need to add from a random server"
<phinze> sans VPR09, heh
<phinze> $REMOTE_SERVER more like
<GaryvdM_> phinze: I think you are asking if you can add a file to a branch, without that branch having a checkout/working directory?
<GaryvdM_> No
<phinze> GaryvdM_: -nod-
<phinze> yeah i thought that was the case... figured it was worth a double-check though
<phinze> thx
<Tak> Pilky: it's from http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html#plugins-and-bzrlib
<Tak> (sorry, called away)
<GaryvdM_> bialix: I want to write a pyqt like interface for source-highlight-qt. (http://srchiliteqt.sourceforge.net/)
<GaryvdM_> oh bialix not here :-(
<vxnick> hi all - I'm trying to break a lock on Launchpad, but bzr is giving me this: bzr: ERROR: Unsupported protocol for url "lp-46125520:///~sitecmd-developers/sitecmd/trunk/.bzr/branch/lock"
<vxnick> not to worry, fixed by removing the numbers and :/// from that
<GaryvdM_> vxnick: Thats a known bug. Rather do this: bzr breaklock lp:~sitecmd-developers/sitecmd/trunk
<vxnick> GaryvdM_: thanks, figured that out eventually :)
<lifeless> jml: I'm popping over to the coffee shop for brekkie, if you want to join me Ihave some testtools refactoring to show & tell on.
<mkanat> I just tried to do a merge with 1.18.1 and got: bzr: ERROR: bzrlib.errors.ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked
<mkanat> This is a merge from a remote pack repo into a local pack repo.
<lifeless> mkanat: fixed in 2.0.1 I think.
<lifeless> spiv: ^
<mkanat> lifeless: Yeah, upgrading fixed it, thanks.
<fullermd> It sure does get peaceful 'round here when everybody's off sprinting   :p
<mkanat> I was wondering. :-)
<spiv> mkanat, lifeless: I certainly fixed a bug like that, not sure if it includes that case or not.
<mkanat> spiv: It seems to have fixed that case.
<spiv> Cool.
<fullermd> spiv: He said upgrading fixed it!  Take the credit!
<fullermd> "Oh, yeah, I totally fixed that.  In my sleep.  Drugged up on morphine."
<mkanat> lol
#bzr 2009-11-13
<RenatoSilva> verterok: hi
<RenatoSilva> what is the .bzr/repository/lock/held file/dir?
<RenatoSilva> what could cause access denied errors in this object?
<RenatoSilva> what's the meaning of this log entry? can it cause access denied errors? Using fetch logic to copy between
<RenatoSilva> CHKInventoryRepository('file:///C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests1963719442832723916/working_copies/default_branch/.bzr/repository/')(<RepositoryFormat2a>)  and
<RenatoSilva> CHKInventoryRepository('file:///C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests1963719442832723916/working_copies/MessageVariantsCommit/.bzr/repository/')(<RepositoryFormat2a>)
<Peng> RenatoSilva: It says it's fetching revisions from one 2a repo to another, and gives their paths. From the paths, perhaps it's from the test suite?
<RenatoSilva> Peng: yes from the test suite, right after this line I get return code 0 , along with a test fail. When the test passes, and that's --random--, I get a lot of output after that same line and only then return code 0
<RenatoSilva> I thought it could be something with the paths, so moved from C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests1963719442832723916 to c:/bzr_tests, didn't work
<RenatoSilva> created a separate user, but and tried in that user, but didn't work either, although I've noted that the errors were less than current user (but same kind, access denied, unkonw cmd bzr.exe)
<RenatoSilva> can anyone please bzr branch lp:~renatosilva/bzr-java-lin/encoding-fixes && mvn -o test ?
<RenatoSilva> in Windows!
<RenatoSilva> it seems soemthing regarding locking
<jml> mwhudson_, btw, we're not going to do a bzr-builder session
<mwhudson_> jml: that would have been more useful if my laptop hadn't still been in the other room :-)
<jml> mwhudson_, heh
<keithy> nothing works
<keithy> I just upgraded to 2.
<GaryvdM> keithy: "nothing works" does not help us help you
<keithy> it was just the general status report
<GaryvdM> keithy: please give us more details.
<keithy> I am getting "unexpected end of message"
<keithy> when remotely checking out
<keithy> bzr+ssh
<GaryvdM> keithy: What command did you run/what button did you click on to get that error?
<GaryvdM> keithy: Is that the whole err, or have you shortened it. bzr errors normally start with "bzr: ERROR: "
<spiv> keithy: which version, exactly?  2.0.2?
<keithy> 2.0.1  on mac os x
<keithy> and 2.0.2 on windows
<keithy> I have to vnc to the windows machine to perform the check out as a pull
<keithy> so it is hard to c & p errors/commands
<spiv> pastebin the entire error text?
<spiv> what SSH client do you use on Windows?
<spiv> Note that since 2.0 bzr will not use plink.exe by default anymore, perhaps that's your issue?
<keithy> could be
<keithy> I have no idea what is on windows, it was plink
<spiv> You can set BZR_SSH=plink in your environment to force that.
<keithy> what will it use?
<spiv> By default, on Windows, it will use paramiko, which is bundled in the installer.
<keithy> ah ok
<spiv> But perhaps it isn't finding your SSH keys
<keithy> it gets as far as opening the channel
<keithy> and asking for a password
<spiv> Basically, there are two likely problems I can guess: it is failing to authenticate to the SSH server, or it is failing to run bzr on the server after logging iin.
<keithy> authentication is succeeding
<spiv> But i'But it's hardt to tell whithout more information.
<keithy> any debug flags I can turn on?
<keithy> ERROR: connection closed: unexpected end of message check permissions and connectivity
<keithy> sftp seems to gt further
<keithy> error file exists .... branchdirectory/.bzr
<keithy> but I just deleted branchdirectory
<keithy> I am doing a checkout --lightweight
<keithy> i give up manual copy it is
<Enisseo> hi everyone!
<GaryvdM> Hi Enisseo
<Enisseo> I made a bad mv, how can I cancel it?
<GaryvdM> Enisseo: have you commited it yet?
<Enisseo> no
<GaryvdM> bzr revert filename
<GaryvdM> I'm not sure if you give it the old name or then new name
<Enisseo> I tried with both
<Enisseo> and it prints an error
<GaryvdM> Enisseo: let me check quickly
<Enisseo> but in my case, maybe what's even worse is that I mv a folder into a file :S
<Enisseo> bzr mv --after myFolder myFile
<Enisseo> (instead of bzr mv --after myFolder myOtherFolder)
<GaryvdM> Enisseo: Now I'n not sure about what you are trying to do.
<Enisseo> just trying to mv a folder to another one
<Enisseo> but the autocompletion made me mv to a file
<Enisseo> (yes, that's a very bad mv I did :S)
<GaryvdM> Ok - Could you please pastebin bzr status
<Enisseo> GaryvdM: http://pastebin.com/m1b35fada
<Enisseo> I accidently typed "mv install .buildpath" instead of "mv install _install"
<GaryvdM> Enisseo: Are there any changes to files that you have made, if not, do bzr revert, and start again.
<Enisseo> I made some other changes (I cleaned the bzr status before posting it)
<GaryvdM> Enisseo: Ok - if there are no changes to .buildpath, then do bzr revert .buildpath
<Enisseo> bzr: ERROR
<Enisseo> :S
<GaryvdM> What was the error?
<Enisseo> A big one, starting with bzr: ERROR: The file id "1.2.0.7.sql-20091113082822-lh720xwrl1jupng4-1710" is not present in the tree <Inventory object at 1797e70, contents=".......
<lifeless> poolie: bug 407834
<ubottu> Launchpad bug 407834 in bzr "fetching from pack to 2a format is slow" [Undecided,Incomplete] https://launchpad.net/bugs/407834
<distatica> how do I find out what files bzr ignored on bzr add ?
<Lo-lan-do> "bzr ignored"
<Enisseo> GaryvdM: solved! I launched a "bzr mv --auto" and it repaired everything :)
<distatica> thank you Lo-lan-do
<GaryvdM> Enisseo: Cool - I learn't something new :-)
<Enisseo> Me too :)
<Enisseo> Thank you for your time
<Enisseo> bye everyone!
<naoki> Hello.
<naoki> One Japanese translator would like to translate bzr's help messages.
<naoki> I found this page: http://bazaar-vcs.org/DraftSpecs/I18nSupport
<naoki> Any progress for i18n?
<GaryvdM> naoki: looking at the history of that doc, it was written by bialix. So he would be the best person to ask
<GaryvdM> naoki: He's not here at the moment.
<naoki> OK, I'll ask him. Thank you.
<maxb> Is retrieving file content from bzr packs a really cpu intensive operation?
<maxb> I'm running a bzr fastexport | hg fastimport, and the export can't generate the stream anywhere near as fast as the import can consume it
<mwhudson> maxb: what format is is the bzr branch?
<maxb> 2a (It's launchpad)
<mwhudson> i see
<mwhudson> generating content should be pretty fast
<mwhudson> but only in a very general way
<maxb> strace says bzr keeps open-fstat-fstat-lseek-mmap-lseek-read-close-munmap -ing the pack and index files repeatedly
<poolie> hello GaryvdM
<poolie> hello maxb et al
<GaryvdM> Hi poolie
<poolie> naoki: the core is not i18n; the concern is that would make startup of the command line slow(er)
<lifeless> maxb: is the source branch local?
<maxb> yes
<lifeless> maxb: and fastexport probably isn't tuned at all
<maxb> It seems to have gotten a lot slower over the course of the import, too. It was running at ~700 commits/minute near the beginning, now it's almost hung
<GaryvdM> lifeless: I'd like to chat about some bzr-search ideas. I now a ok time?
<GaryvdM> lifeless, Someone was asking for bzr-search to only search changed text, not all text. I'm going to have a go at it.
<GaryvdM> lifeless, Should we have a config option to choose whether or not it does this?
<lifeless> GaryvdM: bzr-search only searches diffs
<lifeless> GaryvdM: but you need trunk, it was fixed in my stuff lasst week
<lifeless> it was *reporting* way too much; however I'm being sociable right now, so now isn't a good time to chat
<GaryvdM> lifeless: Oh cool - I'll let the person was asking for it know.
<GaryvdM> It was RenatoSilva
<thrope> hi, *.o in .bzrignore seems to matching files.so as well - unless .so are ignored by detault?
<LarstiQ> both are ignored by default
<LarstiQ> thrope: at least in my ~/.bazaar/ignore
<thrope> oh
<thrope> ok that explains it
<thrope> ah yes mine too
<smartgpx> Hi all. I'm a Win32 user of the setup.exe installer which gives a 'standalone' bzr.exe version of Bazaar without Python installed 'natively' on the machine.
<smartgpx> In that scenario, is there a way of adding extra Python libraries (such as Paste and XMLBuild) such that the bzr.exe can find and use them?
<smartgpx> Does bzr.exe have some equivalent of PYTHONPATH where extras should be installed?
<LarstiQ> smartgpx: afaik, no
<smartgpx> Thanks Wouter. I was looking at the thread bzr-git on Windows on the bzr ml which seemed to suggest it might be possible to get access to Dulwich this way - is that different? (I'll ask Jelmer directly next time he's online.)
<LarstiQ> Dulwich is a Python git implementation
<LarstiQ> smartgpx: do we know each other, or are you bandying whois information around willy-nilly? ;p
<LarstiQ> smartgpx: maybe things have changed, but it used to be that the way to use other libraries was to not use the standalone bzr.exe
<smartgpx> If that's poor nettique I apologise. It seemed more humane.
<smartgpx> And not whois - IrcNicks instead.
<LarstiQ> smartgpx: it's ok, I just hardly ever use that name online
<LarstiQ> smartgpx: ah :)
<servilio> Hi! In a local checkout I have made some local commits, but after updating it the changes I've commited before aren't there anymore, though bzr status -v shows them in a list of pending merges, but when I try to commit it tries to commit them all together
<servilio> is there a way to commit them individually?
<LarstiQ> servilio: you already did
<LarstiQ> servilio: if you commit the merge, `bzr log -n0` will show you the separate commits merged in the last commit
<servilio> LarstiQ, before doing the updated to pull changes upstream
<LarstiQ> servilio: yes, those commits still exist and are now pending a merge
<servilio> LarstiQ, upstream is a svn repo, if I then commit without --local will they show as individual changes in that repo?
<servilio> because right now is asking for a commit message
<LarstiQ> ah
<servilio> like it would commit all at once
<servilio> even with --local
<LarstiQ> if it's svn, then doing it that way isn't too handy
<servilio> LarstiQ: what would you recommend doing?
<LarstiQ> servilio: not using --local
<LarstiQ> but that's too late right now, so
<servilio> LarstiQ, but it will commit directly.... ooops
<servilio> so no way to recommit them separately now?
<LarstiQ> servilio: you can rebase them
<LarstiQ> but I'd unbind first
<servilio> hmmm
<LarstiQ> and if the result is correct, push it, and rebind
<servilio> so, first "bzr unbind", then "bzr rebase"?
<LarstiQ> servilio: bzr unbind; then I guess bzr commit for ease of reference; and rebase
<servilio> LarstiQ: unbound the working dir already, but bzr commit created only one entry
<LarstiQ> servilio: as it should
<LarstiQ> servilio: `bzr log -n0`
<LarstiQ> the other entries already exist, it need not create them again
<LarstiQ> however, you want to have them linearly appended after the history in svn, that is what we're going to use rebase for
<servilio> LarstiQ, oh, ok
<servilio> so, commit, then rebase?
<LarstiQ> servilio: yeah, you'll need to give rebase some options I think
<LarstiQ> servilio: that will take some experimenting, so I'd first `bzr branch` of what you've got now
<LarstiQ> servilio: or find someone who knows rebase better ;)
<servilio> LarstiQ, the relevant option looks to be --pending-merges
<LarstiQ> oh!
<LarstiQ> that's a new one
<servilio> LarstiQ, YES! it did it! :D
<servilio> LarstiQ, that option rebased the pending merges as well
<servilio> LarstiQ: thanks a lot!
<LarstiQ> servilio: good :) checking, what does `bzr missing` think of the difference between your branch and svn?
<servilio> LarstiQ: did not remember 'bzr missing', but it shows the three uncommitted changes I have locally
<servilio> just as expected
<LarstiQ> servilio: good, next step: `bzr push` back to svn, and then bind to it again
<servilio> LarstiQ: just in the push'ing, but had to make some remembering for my password :)
<servilio> LarstiQ: I think I will just do 'bzr push --remember' and leave the local working copy unbound
<LarstiQ> servilio: that's cool too :)
<servilio> LarstiQ: and actually what I wanted from the beginning, but didn't pay close attention to the difference between checkout and branch
<servilio> LarstiQ: it would be nice that when doing an unbind the source repository would be recorded as the --remember for push/pull/missing
<LarstiQ> servilio: if not already set, I guess
<LarstiQ> servilio: file a bug, maybe the developers agree :)
<servilio> LarstiQ: will do
<lifeless> moin
<gioele> is it me or UIFactory.show_{message,warning} are underused by bzrlib?
<gioele> there are no uses of show_warning or show_message in bzrlib/*
<servilio> is there a way to reference the origin branch once the source tree is unbound? something like :origin, or :branch?
<LarstiQ> :parent
<LarstiQ> that isn't populated for a checkout usually though
<LarstiQ> pull --remember will set it
<servilio> LarstiQ, any way to consult its value?
<servilio> other than issuing a pull or similar command
<LarstiQ> servilio: `bzr info`
<LarstiQ> maybe -v
<servilio> it shows the push branch, but I've already set that one
<LarstiQ> then parent is not set
<gioele> how come BzrEclipse has no "Diff" operation?
<fullermd> There's a :bound alias.  I'm not sure whether it still exists when the branch is unbound (but still remembering its previously-bound location), though.
<mkanat> So, any thoughts on whether or not tags that look like revision numbers are bad?
<mkanat> That is, if I have a tag "3.2.4" (which could theoretically be a revision number) am I going to have some troubles?
<LarstiQ> mkanat: hmm, it's bad practise
<mkanat> LarstiQ: So you have any particular reasons why? I had a gut feeling it might be, but just wasn't sure.
<lifeless> mkanat: it should be fine
<gioele> LarstiQ: why bad practices?
<mkanat> lifeless: Okay. Because I always have to specify tag: anyway, right?
<lifeless> mkanat: you may ned to say -r tag:3.2.4 if you have a revno 3.2.4
<lifeless> mkanat: there is a patch coming to search for tags if a thing isn't found in a revno
<mkanat> lifeless: Ahh....
<mkanat> lifeless: My concern is that things be as easy as possible for our users.
<mkanat> lifeless: A lot of people customize Bugzilla and currently check it out via CVS, so there's going to be a lot of new bzr users. :-)
<lifeless> mkanat: are you migrating bugzilla upstream to bzr ?
<mkanat> lifeless: Yep!
<lifeless> woo!
<mkanat> :-)
<lifeless> say hi to dave
<mkanat> lifeless: Miller? :-)
<fullermd> It certainly shouldn't be a *tool* problem.  It could be a *social* source of confusion.
<lifeless> uhm so - tagging should be fine. In your docs say '-r tag:3.2.4'
<lifeless> mkanat: yup
<mkanat> lifeless: Ah, okay. :-) Yeah, talk to him every day, since he's theoretically the Project Leader of Bugzilla. :-)
<mkanat> lifeless: Would it be easier if I just made them all "v3.2.4" though?
<lifeless> mkanat: I would however encourage you to have a 3.2 releases branch, with a commit to it on each release
<lifeless> or something like that
<lifeless> mkanat: yeah, I worked with him some years back :)
<mkanat> lifeless: Ah! Was that when he was at Canonical?
<lifeless> yep
<mkanat> lifeless: Ah, right, he was employee #1, as I recall. Hahaha. :-)
<LarstiQ> mkanat: 3.2.4 of _what_? As fullermd says, not a tool problem.
<mkanat> lifeless: Currently we're going to have a 3.2 branch that has tags for each release.
<mkanat> lifeless: Although your idea of having a release branch might be better.
<LarstiQ> mkanat: but maybe I'm too much cvs influenced
<mkanat> lifeless: Though we also plan to have a "stable" tag on the branch, though.
<lifeless> mkanat: sure.
<mkanat> lifeless: So people could update to that if they wanted.
<lifeless> mkanat: so - play a bit, find what works, document it thoroughly
<lifeless> we've changed how we do releases a fair bit over the years. we add tags, but we don't give people instructions to *grab* a tag
 * mkanat nods.
<mkanat> lifeless: Would "v3.2.4" be a better tag, do you think?
<lifeless> mkanat: it would avoid collisions with revnos
<lifeless> I'd say perhaps release-3.2.4
<lifeless> bzr's tags are just version numbers I think, but as I say we don't need them to get releases as we make branches
 * mkanat nods.
<mkanat> lifeless: What's the advantage of "release-" over "v"?
 * mkanat is just wondering if there's a technical difference.
<lifeless> clarity
<mkanat> I can see that.
<lifeless> plane catchin' time
<lifeless> ciao
<mkanat> Ciao!
<lifeless> or I guess to be precise; food; bus to airport. WAIT. plane.
<lifeless> I maybe back @ the airport :P
<LarstiQ> :)
<LarstiQ> mkanat: I wasn't very clear, what I would do is '$project-$version'
<mkanat> LarstiQ: Hmm. I'd think that would be fairly clear given the branch nickname, but I suppose maybe it's less clear with merged branches?
<LarstiQ> mkanat: maybe I'm old and biased ;)
 * mkanat shrugs. :-)
<hsn> there there any plans for cherrypick with history?
<fullermd> An advantage of that is that it makes the tag name more likely to be universally unique.  That can be an advantage if it ever gets imported into a situation where tags from multiple projects have to coexist.
<LarstiQ> mkanat: tags are stored per branch right now, but I myself won't depend on that fact
<LarstiQ> mkanat: what happens if you join two branches together, or with fast-export/import?
<mkanat> LarstiQ: Oh, true.
<RenatoSilva> verterok: hi
<phcoder> Hello, all. Is there a way to unmerge branches while still allowing them to be merged on a later date?
<fullermd> Funny.  There's a thread about committer/reviewer resources going on on the Postgres lists right now   :p
<verterok> RenatoSilva: hi
<RenatoSilva> verterok: hi. I did more tests
<RenatoSilva> verterok: I've isolated one specific test that randomly fails/passes.
<RenatoSilva> verterok: here is the stack trace with the error message, and below the bzr log on fail/pass. The only diff in bzr log between fail/pass is that when passing, there are more lines, there's no error message in bzr log! http://pastie.org/695026.txt
<RenatoSilva> verterok: tried cerating anotehr windows user, but same errors, although seems less ones
<verterok> RenatoSilva: yes, the extra lines are the branch setup for the test
<RenatoSilva> verterok: I've also run the tests in Ubuntu, and they passed!
<RenatoSilva> verterok: does the url give you any clue on what's wrong?
<verterok> RenatoSilva: looks like the lock isn't released, which is weird, as there is a single client running for th tests
<verterok> *the
<RenatoSilva> verterok: yes I've noted the access denied are about lock files
<RenatoSilva> verterok: doesn't junit use thread when running the tests?
<RenatoSilva> *threads
<verterok> RenatoSilva: hmm, no. at least not by default
<RenatoSilva> verterok: do you have winxp to test it? about linux, the tests fails for non-ascii paths, for example /I/am/in/maÃ§Ã£$mvn test --> fails
<verterok> RenatoSilva: yes, it's down currently, need to get home to test in win xp
<RenatoSilva> verterok: ok, thanks if you can. Do you usually update winXP?
<verterok> RenatoSilva: no, it's an old version...I think SP1
<RenatoSilva> verterok: ok...your vm in hudson too?
<verterok> RenatoSilva: that's the only winxp I have :)
<RenatoSilva> verterok: ahahah ok
<RenatoSilva> verterok: I need to find someone with winxp sp3 + mvn + bzr
<RenatoSilva> verterok: I'm lazy to create a win vm here
<RenatoSilva> verterok: but about Linux, something seems wrong with your linux in hudson
<RenatoSilva> verterok: just ran the tests on a virtualized kubuntu here, all successfull too
<verterok> RenatoSilva: why? it's just a stock karmic install
<RenatoSilva> verterok: I don't know why, I just know it's working here :D
<verterok> jej :)
<RenatoSilva> jej?
<verterok> RenatoSilva: heh?
<verterok> RenatoSilva: same as :-)
<RenatoSilva> verterok: ah ok, never saw that, thought it was another irc acronym
<RenatoSilva> verterok: I would like to help you solve the failures in linux, but the only thing I know is that they don't happen here in ubuntu and kubuntu
<verterok> RenatoSilva: thanks, I'll try to take a closer look later, at home
<RenatoSilva> ok
<RenatoSilva> I think I'll file a bug about the WinXP for at least finding out the root cause
#bzr 2009-11-14
<dOxxx> Good evening. Anybody on that knows something about the StringIOWrapper used in bzrlib.tests?
<fax8> Hi, I setup some bzr instructions to send patches for a project I maintain.. instructions are here http://www.varesano.net/contents/projects/firefox%202%20theme%20firefox%203x#Development
<fax8> Today a user just sent me a patch.. but it's basically useless as it breaks each newline in the modified file making it unusable..
<fax8> any idea what could have gone wrong?
<fax8> please note that my project has been created on Linux, while the user probably modified that on Win
<LarstiQ> fax8: sounds like a windows editor
<fax8> LarstiQ: so you think that the editor broke that? not bazaar?
<LarstiQ> fax8: absolutely. However, Bazaar has functionality to combat that behaviour.
<fax8> LarstiQ: sounds good, can you elaborate or point to relevant docs?
<LarstiQ> fax8: http://doc.bazaar-vcs.org/bzr.2.0/en/user-reference/index.html?highlight=eol#end-of-line-conversion
<fax8> LarstiQ: thanks!
<LarstiQ> fax8: personally I tell my editor (vim) to never write windows style line endings, but not every editor can do that, and not every user has their editor configured that way
<LarstiQ> (or editors not changing line ending style would work too)
<thrope> i see bzr-git doesn't support push... is there anyway workflow for working on a git-repo with bazaar?
<thrope> could I pull from git and branch from that... do my work, then serve my work in my bazaar branch with git-serve and merge it back into a git branch?
<bob2> dpush should work
<bob2> but I thought push did, too
<thrope> bob2: do you know how I could branch my github repo git@github.com:user/test.git doesn't work and git://github.com/user/test.git is read only
<bob2> read only?
<thrope> bob2: it is the public url... don't know how to log in to it
<bob2> ssh://?
<thrope> bzr: ERROR: Unsupported protocol for url : bzr supports bzr+ssh to operate over ssh
<bob2> or git+ssh
<thrope> Permission denied (publickey).
<bob2> does git clone ssh:// work?
<thrope> no
<thrope> with git I use git@github.com:user/test.git
<thrope> oh got it ssh://git@github.com/user/test.git
<thrope> git+ssh works with that, thanks
<thrope> ah dpush works, but I get a message "No new revisions to push. " - but it did work ... thanks a lot
<bob2> just be careful that you find out what dpush does
<bob2> it might not do what you expect
<thrope> hmm - I have my bzr-git branch... I branched it in bzr... made some changes in git and pushed, made some changes in the 2nd bazaar branch. now I try to merge the changes... so I updated the original bzr-git branch... thinking i would merge in the second bzr branch and then dpush
<thrope> but merge says nothing to do.
<thrope> oh never mind i forgot to commit
<piem> hi all. i'm trying to sort out some bugs with trac-bzr. maybe someone here could help. i'm hit by lp#349212 and lp#264734 mostly
 * piem waves at Kinnison :)
<gioele> ubottu: bug #349212
<ubottu> Launchpad bug 349212 in trac-bzr "Browse source produce traceback with GraphCycleError: Cycle in graph [...]" [Undecided,New] https://launchpad.net/bugs/349212
<piem> right. fyi, lp:~jlgeering/trac-bzr/experimental fixes both lp#349212 and lp#264734
<RenatoSilva> verterok: hi. I'm watching your builds in hudson, the one in linux just worked :)
<verterok> RenatoSilva: hi :)
<verterok> RenatoSilva: the problem was that /tmp is a symlink and the test suite isn't resolving the link :/
<RenatoSilva> verterok: and rev 217 was the solution?
<verterok> RenatoSilva: yes, I just set the java.io.tmpdir property to the real directory :p
<RenatoSilva> verterok: ok will install vbox to test in my linux here, brb
<RenatoSilva> verterok: I've got the tests passing here in XP after reverting the system to a previous state (and fixing all the problems it caused)
<RenatoSilva> verterok: but shi***, the problem is back again
<verterok> RenatoSilva: cool, just merged both branches in trunk :)
<RenatoSilva> verterok: permission denied... the only thing I note to have done is that I have canceled mv -o test with ctrl+c
<RenatoSilva> does anyone know how to solve this permission denied error? When you ctrl+c some bzr operation and you try again, you get a similar error, but bzr gives you a command to release the lock
<RenatoSilva> I think I need to release some lock here, just like something is stuck in bzr user dara, not branch data
<dOxxx> what's the exact error message?
<RenatoSilva> dOxxx: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: Permission denied: "C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests4776816157272306423/working_copies/bind/.bzr/branch/lock/held": [Error 5] Acesso negado
<dOxxx> is this during bzr selftest?
<RenatoSilva> ...
<RenatoSilva> during bzr-java-lib JUnit tests
<RenatoSilva> after ctrl+c a mvn test
<dOxxx> oh, sorry, I missed the first part of the conversation :)
 * RenatoSilva sighs
<verterok> RenatoSilva: each junit run is executed in a new and clean directory...weird
<RenatoSilva> verterok: now I got some .bat remaining
<RenatoSilva> verterok: man the only thing I can imagine to have caused this was cancelling mvn test
<RenatoSilva> verterok: I've reinistalled AVG, and installed win updates one by one, nothing happened until now
<verterok> RenatoSilva: did you tried uninstalling/turning off AVG?
<RenatoSilva> verterok: yes, previously
<RenatoSilva> verterok: tried turning off AVG and win firewall, tried many things
<RenatoSilva> verterok: I was running mvn test many times after each thing I was doing
<dOxxx> RenatoSilva: at what point in mvn test did you interrupt it?
<dOxxx> I'm tyring to cause the same problem here
 * verterok need to run
<RenatoSilva> dOxxx: did you branch it?
<RenatoSilva> dOxxx: bzr-java-lib?
<dOxxx> yes
<RenatoSilva> verterok: see you
<verterok> RenatoSilva: I just fired a bzr-eclipse build, once it finish, http://steppenwolf.selfip.net/hudson/job/bzr-eclipse/lastSuccessfulBuild/artifact/headless-build/eclipse.build/update-site-1.1.1.214.zip ;)
<verterok> RenatoSilva: thanks! seeya later!
<RenatoSilva> verterok: ok thanks
 * RenatoSilva is absolutely bored with this problem
<dOxxx> I don't know if I can help you solve it, but I'm willing to try. You say you ran mvn test, interrupted it at some point and now you get Access Denied errors when running it again?
<RenatoSilva> running the tests
<RenatoSilva> with or without mvn
<RenatoSilva> dOxxx: are you in WinXP?
<dOxxx> Vista 64
<dOxxx> At what point in the tests do you press Ctrl-C?
<dOxxx> I want to try doing the same here and see if I get the problem
<RenatoSilva> dOxxx: no idea, in the beginning
<RenatoSilva> dOxxx: mvn -o test
<RenatoSilva> dOxxx: I'm in winXP SP3 updated
 * RenatoSilva will use system restore again :(
<dOxxx> RenatoSilva: I"m not getting the access denied error :( Tried interrupt it a few times in different places and then letting it run uninterrupted to completion.
<RenatoSilva> dOxxx: maybe because it's a winXP issue
<dOxxx> RenatoSilva: Ah, sorry, I didn't know it was platform specific.
<RenatoSilva> dOxxx: no one knows the root cause of this
<dOxxx> RenatoSilva: What's the canonical form of C:/DOCUME~1/renato/CONFIG~1 ?
<dOxxx> RenatoSilva: Basically, I'm wondering if it's creating the temp files in a weird location that's causing you problems
<RenatoSilva> Documents and Settings/Renato/ConfiguraÃ§Ãµes Locais
<RenatoSilva> dOxxx: no it's not the path
<RenatoSilva> dOxxx: at least not the tmp dirt itself, how would it work before?
<dOxxx> hmm true
<RenatoSilva> dOxxx: anyway I tried before to move the temp dir to c:
<dOxxx> also, what JDK version are you using?
<RenatoSilva> 1.6.0_16
<verterok> RenatoSilva: try using: mvn -Djava.io.tmpdir=C:/mvn_temp -o test
<dOxxx> verterok: btw, I'm getting test failures on windows vista 64 with bzr 2.0.1 installed from the windows installer. Should I be reporting these or is this not a supported combination?
<verterok> dOxxx: what version of xmloutput do you have installed?
<dOxxx> 0.8.5
<dOxxx> stock version that comes with the windows installer for bzr 2.0.1
<RenatoSilva> verterok: worked the 2 or 3 times, but failed now: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: Permission denied: "C:/mvn_temp/bazaar_client_tests8667854772094938709/working_copies/Diff/.bzr/repository/lock/held": [Error 5] Acesso negado
<dOxxx> RenatoSilva: does that file still exist? can you check the permissions on it?
<verterok> dOxxx: could you pastebin the failures?
<RenatoSilva> verterok: not sure, but I guess it may be something related to simply running the tests again and again, maybe JUnit or whatever get stressed and stop working
<root> hello
<dOxxx> verterok: first one: http://pastebin.com/d64c9f883
<Guest21213> anyone know how to fix the no suck launchpad account for branching?
<Guest21213> such*
<dOxxx> Guest21213: what's the url you're trying to branch?
<RenatoSilva> dOxxx: update your xmloutput to dev version
<verterok> dOxxx: revno 207 of bzr-java-lib?
<Guest21213> bzr branch lp:~name/trunk
<RenatoSilva> dOxxx: remove your 0.8.5 and branch from lp
<dOxxx> revno 205 of bzr-java-lib, branched about an hour or so ago
<RenatoSilva> dOxxx: update both bzr-java-lib and xmloutput
<RenatoSilva> Guest21213: bzr branch lp:~name/project/trunk
<dOxxx> Guest21213: if name is the project name, try lp:name/trunk
<Guest21213> bzr branch lp:~name/project/trunk doesnt work
<RenatoSilva> Guest21213: of course, because name should be replaced with the real user name, and so forth
<dOxxx> Guest21213: can you give us the exact url?
<RenatoSilva> Guest21213: give more details
<RenatoSilva> verterok: mvn -Djava.io.tmpdir=C:/mvn_temp -o test doesn't work at all :(
<verterok> Guest21213: lp:<project name> is usually enough
<verterok> RenatoSilva: huh, weird...what's the error?
<RenatoSilva> verterok: the same
<verterok> RenatoSilva: oh, ok
<dOxxx> verterok: tests succeed now :)
<RenatoSilva> dOxxx: :(
<dOxxx> RenatoSilva: sorry dude :(
<verterok> dOxxx: :)
<dOxxx> any idea how the bzr4idea project is going?
<verterok> RenatoSilva: so, it's something that changed in the last few days :(
<dOxxx> I looked at it a little while ago but it wasn't compatible with the latest IDEA9 community edition
<RenatoSilva> verterok: no, it's something that changed --now--, a few minutes ago :(
<verterok> oh
<RenatoSilva> verterok: I passed a few hours running the tests after each stuff I did and succeeding all the time
<RenatoSilva> verterok: while I was here talking to you, it started failing :(
<RenatoSilva> verterok: and the only I can notice that has changed is that canceled mvn -o test, and I suspect it may have broken something
<RenatoSilva> *only thing
<verterok> dOxxx: no idea about bzr4idea status
<verterok> RenatoSilva: check if you have a xmlrpc service running?
<Guest21213> verterok: get same error doing lp:(project name) seems like some settings went off
<verterok> Guest21213: what's the project?
<Guest21213> all :P
<dOxxx> oh wait...
<verterok> Guest21213: and what's the error? :)
<dOxxx> have you done bzr lp-login username?
<Guest21213> No such Launchpad account
<Guest21213> no
<RenatoSilva> verterok: already checked before, bzr start-xmlrpc works and responds just fine
<dOxxx> Guest21213: do you have a lp account?
<Guest21213> need login to download a branch? wtf
<dOxxx> no just asking
<RenatoSilva> Guest21213: why don't you just give the name of the project and all data?
<Guest21213> cuz its irrelevant
<verterok> Guest21213: could you pastebin the error?
<dOxxx> Guest21213: what's the output of 'bzr lp-login' ?
<RenatoSilva> Guest21213: bzr branch https://code.launchpad.net/~user/project/series
<Guest21213> ok thanks
<RenatoSilva> verterok: hum other thing has changed... xmlrpc-client-1.1.1!
<Guest21213> I thought lp was a shortcut for that :P
<verterok> RenatoSilva: hmm, change it back to 1.1 in the pom ;)
<RenatoSilva> Guest21213: create a system var $lp
<RenatoSilva> verterok: redefining permissions of C:/Program, Files
<RenatoSilva> verterok: sorry what's the arg for setting the tmp dir?
<verterok> RenatoSilva:  -Djava.io.tmpdir=<tmp dir>
<RenatoSilva> ok thanks
<dOxxx> On windows it's probably taking it from a env variable like TMP or TEMP or something like that
<dOxxx> i.e. the java.io.tmpdir is initialized by default to the contents of the TEMP env var
<dOxxx> *sigh* looks like bzr4idea is pretty dead
#bzr 2009-11-15
<dOxxx> verterok: what would you say the state of bzr-java-lib is? Enough to create a bzr client for an IDE?
<RenatoSilva> dOxxx: don't you like eclipse?
<verterok> dOxxx: it should be enough :) and if it's not is a bug ;-)
<verterok> dOxxx: there is a lot of room ofr improvements
<verterok> *for
<dOxxx> RenatoSilva: nope, I've been using IDEA for a very long time. I've tried Eclipse a few times and I've never liked it. No offense intended, it just doesn't suit me I guess :)
<dOxxx> verterok: cool. maybe I can massage bzr4idea into a working state. haha.
<verterok> heh, cool! :-D
<RenatoSilva> dOxxx: I like eclipse very much
<dOxxx> RenatoSilva: Each to his own :)
<dOxxx> hopefully we can both use bzr with our favourite IDE
<RenatoSilva> verterok: didn't work changing the permissions :(
<RenatoSilva> verterok: didn't work changing redstone to 1.1 :(
<verterok> RenatoSilva: :(
<RenatoSilva> I'm getting now org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: unknown command "C:\Arquivos de programas\Bazaar\bzr.exe"
<verterok> don't make any sense :(
<dOxxx> I got that one a few times when I was running mvn test repeatedly
<RenatoSilva> If the errors were not random, I would be able to debug it in eclipse at least :(
<dOxxx> before I updated my local branch and xmloutput plugin
<RenatoSilva> I just branched a new copy of java lib, and xmloutput is up-to-date
<dOxxx> weird
 * RenatoSilva is crying
<RenatoSilva> when you do any bzr operation, does any file involved is OUT of the branch?
<RenatoSilva> for example, does bzr create a lock file in tmp dir or user's profile, rather than inside the branch?
<lifeless> no
<RenatoSilva> I suspect some lock is lost somewhere, even in Windows registry
<RenatoSilva> verterok: permission r/w to all in mvn dir, c:/mt (temp), and c:/bzr-java-lib, still failing
<dOxxx> verterok: any idea what happened to CygwinFilePathAdapter?
<dOxxx> what date format does IBazaarAnnotation return from getDate(linenumber)?
<RenatoSilva> verterok: oh that patch for redstone wasn't necessary, the dev version fixed that in 2007 http://xmlrpc.svn.sourceforge.net/viewvc/xmlrpc/trunk/source/redstone/xmlrpc/XmlRpcClient.java?r1=28&r2=32
<RenatoSilva> and didn't release it since that o.O
<dOxxx> bah... looks like bzr4idea was using a forked version of bzr-java-lib :P
<dOxxx> it's referencing stuff that's never existed
<wgrant> Java developers love to do that :(
<dOxxx> I'll be damned if I can find it.
<dOxxx> aha
<verterok> dOxxx: if the changes are good, I'll be happy to merge them in bzr-java-lib, I'll take a look to their branch
<verterok> RenatoSilva: thanks for the bug triage ;-)
<dOxxx> verterok: the branch is lp:~bzr4idea/bzr-java-lib/trunk. I merged trunk into my localy copy of it and there are a few conflicts but I think I sorted them out. The changes seem to be mostly minor adjustments of the interface to suit the bzr4idea developer
<RenatoSilva> verterok: np, btw can't find any reference to redstone.xmlrpc in bzr-java-lib/bzr-eclipse, just like it's not used o.O
<dOxxx> verterok: although, there is one fix to the Ls command for a bug in xmlls, which when given the parameters "." and "--non-recursive" returns an empty list
<dOxxx> well, workaround, not fix :)
<dOxxx> and I checked, the bug still exists in 2.0.1
<RenatoSilva> dOxxx: be careful to not make it compatible with idea, but break eclipse :)
<verterok> dOxxx: and in bzr-xmloutput trunk I assume :)
<dOxxx> RenatoSilva: nah, the changes aren't that major.
<verterok> RenatoSilva: from the top of my head: XMLRPCCommandRunner
<dOxxx> verterok: oh, yeah, since I just checked using my normal bzr install with the xmloutput trunk I installed earlier this evening
<RenatoSilva> verterok: yeah, just found it :)
<dOxxx> verterok: basically, the following command returns an empty list: bzr xmlls . --non-recursive
<RenatoSilva> verterok: I wanted to know if bzr-eclipse itself also used redstone lib, but no it doesn't
<verterok> RenatoSilva: no, bzr-eclipse only uses bzr-java-lib...or should :)
<verterok> dOxxx: oh, ok. sounds like a bug :)
<verterok> RenatoSilva: as I merged your encoding-fixes branch in trunk, it's ok to delete the jobs from hudson?
<RenatoSilva> verterok: ok
<dOxxx> verterok: yes, I think it's a bug in the underlying bzr ls though, which is just reflected in xmlls
<verterok> dOxxx: oh, that's bad...but good catch :)
<dOxxx> verterok: well, I think :)
<dOxxx> hmm
<dOxxx> "bzr ls ." works
<dOxxx> there is no --non-recursive option for bzr ls
<dOxxx> so maybe it is specific to xmlls
<verterok> dOxxx: probably the option name changed, and xmloutput is still using the old name
<dOxxx> aha: https://bugs.launchpad.net/bzr/+bug/158690
<ubottu> Launchpad bug 158690 in bzr "ls --non-recursive PATH : no list" [Medium,Triaged]
<verterok> RenatoSilva: if you need to run a new branch on hudson, just create a new job, but copying bzr-java-lib[-xp] job and change the branch url ;)
<dOxxx> so it looks like that bug was "solved" by removing the option :P
<verterok> dOxxx: heh, looking a the bzr code, ls changed a lot since I worked on xmlls, probably I introduced that bug :)
<RenatoSilva> verterok: ok thanks
<dOxxx> verterok: it happens :) I'm filing a bug on xmloutput now
<verterok> dOxxx: ok, thanks!
<dOxxx> verterok: https://bugs.launchpad.net/bzr-xmloutput/+bug/482901
<ubottu> Launchpad bug 482901 in bzr-xmloutput ""xmlls --non-recursive ." returns empty list" [Undecided,New]
<verterok> dOxxx: I "think" I have a fix :)
<verterok> but no tests :/
<dOxxx> woot :)
<RenatoSilva> verterok: from where did you take xmlrpc 1.1.1, and even 1.1? didn't find it in SF
<RenatoSilva> verterok: latest release there is 1.0 I think
<dOxxx> verterok: should be simple enough to write a test for it, if you have a framework for creating a temp branch with some files
<verterok> RenatoSilva: 1.1 from the redstone page, 1.1.1 build it myself from a svn checkout
<verterok> dOxxx: bzr test framework! ;-)
<dOxxx> aha!
<dOxxx> if you want, I can take a crack at writing the test
<dOxxx> I have a little experience with the bzr test framework
<verterok> dOxxx: be my guest, and to get the fix too ;)
<dOxxx> verterok: have you already made the fix? or can you send me a patch?
<RenatoSilva> verterok: ah ok, just a suggestion, instead of 1.1.1, use 1.1_custom0, or 1.1_verterok0 etc... (not sure if mvn can deal with that though)
<verterok> RenatoSilva: but it's 1.1.1, they tagged/commited the version bump
<RenatoSilva> verterok: ah ok
<verterok> RenatoSilva: but I can change it to 1.1.1-dev or something
<verterok> RenatoSilva: I pushed the xmlrpc-1.1.1 to my maven repo @ verterok.com.ar
<RenatoSilva> verterok: ok, just a suggestion to clearly identify that 1.1.1 is not released yet :)
<verterok> RenatoSilva: yeap, good point :)
<verterok> dOxxx: sort of a fix, mostly a hack...gimme 1' and I'll pastebin it
<dOxxx> k
<verterok> dOxxx: also, xmlls is one of the xml commands that don't have tests :/
<dOxxx> verterok: I see.
<dOxxx> verterok: maybe I can steal the bzr ls tests :)
<verterok> dOxxx: I did that for most of the xml* commands :)
<verterok> dOxxx: http://pastebin.ubuntu.com/319005/
<verterok> ok, guys, I need to leave for a while. see you later!
<verterok> dOxxx: thanks for taking that bug ;)
<verterok> RenatoSilva: apologize the delay to get the encoding fix merged, thanks a lot for getting it done and poking me :)
<dOxxx> seeya verterok
 * verterok away not here right now
<verterok> ooops, wrong command :p
 * RenatoSilva just had a big battle with a roach
<dOxxx> RenatoSilva: bug "fixing" ? ;)
<RenatoSilva> no, a real roach
<RenatoSilva> I could kill it, but not the tests bug :(
<dOxxx> :(
<dOxxx> Hmmm... I'm getting a popup dialog when running bzr selftest which says "This application has failed to start because QtHelp4.dll was not found." I wasn't getting this earlier...
<bob2> --no-plugins
<dOxxx> yeah except I'm tyring to test a plugin :)
<dOxxx> oh well, it's not stopping the tests from running, it's just annoying
<RenatoSilva> dOxxx: you created a patch for the test failure I've reported? nice :)
<RenatoSilva> verterok: when you are back here, the update site didn't work in galileo. I've extracted features and plugins, it works nice, but the build does not contain the redstone patch
<dOxxx> RenatoSilva: yeah, it was pretty simple as far as I could see
<RenatoSilva> verterok: by work nice I mean no error in log view when opening eclipse
<seiflotfy> hey guys
<seiflotfy> quick question
<seiflotfy> i uncommited and unreverted locally
<seiflotfy> not i want to change the state of trunk on launchpad
<seiflotfy> to the old state
<beuno> seiflotfy, you want Launchpad's branch to have the same state as you do locally?
<seiflotfy> yeah
<beuno> seiflotfy, bzr push --overwrite
<seiflotfy> the branch on launchpad had 1292
<seiflotfy> and i want it back on 1278
<beuno> seiflotfy, bzr push --overwrite will do it
<seiflotfy> thx
<seiflotfy> worked
<thrope> hi - when using bzr-git is there a way to specify the remote git branch to use for pull or dpush (or the original branch)
<dOxxx> Good morning.
<maxb> I would like to learn more about the bzrlib python api ... is there a good place to get started? Perhaps some pointers to key concepts / methods to look at first?
<dOxxx> maxb: try having a look at bzrlib/builtins.py. It contains all the bzr commands and should give you a general idea of where to go for a specific feature.
<maxb> thanks
<maxb> When 'bzr rebase' drops you back to the shell for conflict resolution, is there any way to find out which revision it dropped you at?
<dOxxx> maxb: I'm just guessing here, but try 'bzr revno' ?
<maxb> dOxxx: This seems to tell you about the last revision that completed rebasing. That's not really all that helpful unless the history is non-branchy *and* you know it well.
<dOxxx> maxb: ah, sorry, was just a guess. I'm fairly new to bzr myself.
<maxb> No problem. It seems that bzr-rebase needs a bit of work to bring it up to the standards of hg's offering
<dOxxx> it's a plugin, not a core command, so it may not be receiving the same level of attention
<dOxxx> however, if you file bugs or ask a question at the project page (https://answers.launchpad.net/bzr-rewrite/+addquestion) you may get a better reply than mine :)
<dOxxx> asking on the bazaar mailing list may also work
<LarstiQ> maxb: all I know is bzr-rebase has been renamed bzr-rewrite
<maxb> LarstiQ: Indeed. A bit odd. Especially since it still needs to be imported as 'rebase'
<jelmer> maxb, It's slowly being renamed
<maxb> jelmer: Hi. Would you happen to know why rebase attempts to only rebase a left-most path of revisions? That seems fundamentally incorrect to me
<jelmer> maxb, I've just replied to your email
<maxb> ah, thanks :-)
<jelmer> maxb: Basically bzr-rebase was written as a tool to rebase a small local branch on top of an upstream bzr-svn branch
<jelmer> maxb: not really as a suisse army knive to do large-scale history rewriting
<jelmer> maxb: Not that I object to improvements of course :-)
<jelmer> some of the other commands in bzr-rebase do rewrite more (e.g. rebase-foreign)
 * maxb will wait for your respose to percolate through the internet and read that first
<Xello> Hello
<Xello> How would I change a file to say its rev 39?
<Xello> and then I could comit the changes
<maxb> You wish to alter a file to be the same as it was in a previous revision and then commit that as a change?
<maxb> bzr revert
<Xello> Well I made changes to a file over many commits
<Xello> Then I realized the way I was doing it was correct
<Xello> so I would like to replace the file thats there with rev 39 of that file
<Xello> then make changes and / or commit
<LarstiQ> Xello: bzr revert -r 39 <file>
<Xello> cool
<Xello> LarstiQ: Thanks
<LarstiQ> Xello: don't forget to thank maxb too :)
<Xello> whops im an ass
<Xello> maxb: Thanks for the help
<Xello> Yes! it worked
<Xello> I <3 bzr
<Xello> In celebration I give to you all a link to some music
<Xello> http://www.jamendo.com/en/album/44337
<LarstiQ> Xello: heh, thank you :)
<Xello> its free and legal (creative commons)
<Xello> I like to feel like I'm an adventure movie when I'm coding sometimes
<theAdib_> I want to see what is the last commit message. bzr log gives me everything. How can I limit bzr log to only give me the very last one?
<dOxxx> bzr log -r-1
<theAdib_> dOxxx, ah thx. (I tried bzr log -1 with no success)
<dOxxx> np
<eMerzh> what is the best way to nest an external svn tree into a bzr branch? ... i've checkout my svn tree into a branch A and joined it into my main branch ...
<jelmer> eMerzh: Ideally the solution would be nested tree support in bazaar
<eMerzh> is there a way to do it without the branch 'A' ?
<jelmer> until then there are a couple of 3rd-party solutions
<jelmer> using e.g. config-manager, scmproj or bzr-externals
<eMerzh> what are the pbm with join ?
<jelmer> eMerzh, join basically merges in the svn tree
<jelmer> meaning your local repository would basically include the contents of the svn one
<eMerzh> ok jelmer... thanks
<jelmer> you can then do merges from the svn branch whenever you need to update it
<eMerzh> ok.. dumb question but.. is there a plan (date?) to support Real nested tree so?
<jelmer> eMerzh: I'm not aware of any specific plans
<spiv> Good morning.
<jelmer> hi spiv
* spiv changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b2 have gone gold! time to build those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Current pilot: spiv
<igc1> medical stuff for a few hours - bbl
#bzr 2010-11-15
<KombuchaKip> I just pushed to my launchpad bzr repo after initializing it. I am now about to make a commit after binding to the remote repo. I am prompted with "Unknown files exist in the working tree. Commit anyway?". What does this mean?
<spiv> poolie: that sounds likely
<spiv> mgz: I'll poke my branch
<maxb> KombuchaKip: It is questioning whether you forgot to 'bzr add' or 'bzr ignore' some files
<KombuchaKip> maxb: Yeah, I see it just means there are some files in the repo that aren't under source control. Is there a way to see that besizes running bzr status, via nautilus plugin?
<maxb> I do not know if there is nautilus integration for bzr
<spiv> mgz: hmm
<spiv> mgz: the web page seemed already up to date for me, but I poked my branch anyway
<spiv> mgz: I think the "hasn't twigged" issue it because lp has started tracking which rev was approved
<spiv> mgz: so post-review commits mean the mp is not marked merged, maybe?  Hmm, that doesn't sound right.
<mgz> spiv: https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev <- what's the latest rev number under 'Recent revisions' for you?
<spiv> Oh, of bzr.dev itself.
<spiv> Yeah, I think it's fallout from the codehosting issues earlier.
<spiv> The "please scan this branch" request from codehosting to the rest of LP got lost due to a timeout.
<mgz> so I should wait and not worry?
<spiv> The next time someone lands something it should sort itself out.
<spiv> +1 for wait and not worry
<mgz> was a bit concerned as I did a merge with pqm and thought everything was fine as I got the all-ok email... but then the website stayed as it was.
<spiv> (I think the goal is to rescan all the branches touched during the troubled period)
<mwhudson> poolie: yes, seems very likely
<eric_f> having trouble getting loggerhead to start up on 10.04 installed via apt-get
<eric_f> it seems the conf file has changed with the init.d script now running serve-branches instead of start-loggerhead
<eric_f> any place I to find good info about setting up loggerhead?
<maxb> here? :-)
<maxb> start/stop-loggerhead are officially deprecated, and actually deleted in trunk
<eric_f> okay, so is there no more /etc/loggerhead.conf file then too?
<eric_f> â¦I'm migrating our old 8.04 server to 10.04 and we have lighttpd running on the old server as the proxy for which loggerhead was going through
<eric_f> so looking to have that same setup, just now how to setup loggerhead in the newer way?
<maxb> Hmm, IIUC there is no more loggerhead.conf in the serve-branches world
<maxb> all config is supplied as command line options
<maxb> hmm, or perhaps I am misunderstanding
 * maxb attempts to figure out what the code is doign
<eric_f> maxb: okay, looks like I got loggerhead to come up and its serving through lighty, any idea where there would be good docs for describing the options for serve-branches?
<maxb> hmm, I am leaning towards my original assertion: the config file is completely deprecated
<eric_f> well /etc/serve-branches.conf isnt
<maxb> eric_f: ./serve-branches --help ?
<poolie> hi maxb
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie! | Release Manager: vila | 2.3b3 has been released
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie! | Release Manager: vila | Hooray for jelmer
<eric_f> maxb: yeah, looking for something a tad more detailed I guessâ¦
<maxb> hi poolie
<maxb> eric_f: Anything specific that seems unclear?
<maxb> jam: Hi. I'm looking at loggerhead, and it looks to me like loggerhead.conf.example and loggerhead/apps/config.py are yet more stuff only used by the deceased start-loggerhead
<eric_f> maxb: well after reading this I figured out how to hide certain branches: http://theoryl1.wordpress.com/2010/05/22/bazaar-loggerhead-on-ubuntu-10-04/
<eric_f> but now I looking at the loggerhead pages in the browser the JS is 404ing
<eric_f> :-/
<maxb> ah, hm. Appears serve-branches.conf is a debian invention
<eric_f> yeah and doesn't include all the available options :-(
<maxb> eric_f: Well, it's just a convenience for injecting some values into the command line used in /etc/init.d/loggerhead
<maxb> You can always tweak the init.d script directly
<maxb> and the JS is 404ing for me too
<eric_f> also looks like the protocol (http) is hard-coded because I am serving over https so all the links are broken :-(
<eric_f> maxb: maybe I should be on 1.18 or something, 1.17 seems like it has a lot of issuesâ¦
<maxb> I think that last is fixed in 1.18
<maxb> And the YUI breakage appears to be wholly Debian's fault
<eric_f> well I just set it to use the Yahoo CDN to fix that for now
<eric_f> I found this patch http://launchpadlibrarian.net/23586834/relative-url.diff via https://bugs.launchpad.net/loggerhead/+bug/260547 but not sure where that branch.py file would exist on my system?
<ubot5> Launchpad bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option (affected: 0, heat: 0)" [Medium,Fix released]
<maxb> I wonder if you'd do better to just abandoned the packaged version and take 1.18 from upstream
<maxb> I'll try to get 1.18 into the ~bzr PPA at some point soonish
<eric_f> maxb: sounds good, for now I want to see if I can just patch 1.17 and wait for the PPA for 1.18. Do you know where the .py files for loggerhead go when installing from the PPA?
<maxb> dpkg -L loggerhead
<eric_f> thanks
<Odd_Bloke> Is http://webapps.ubuntu.com/employment/canonical_BSE/ the job that Jelmer just got?
<thomi_> Hi, I'm trying to work out if it is possible, using python-bzrlib to plug in a custom bzr authentication scheme? The docs seem to suggest not, but I'd like to make sure. Any ideas?
<jam> maxb: I'm not sure about the details. but I know the loggerhead codebase has been pretty confused as to whether it was a standalone app, or a plugin
<jam> and yes, some code paths seemed to invoke different methods of configuration, etc.
<vila> hi all
 * gthorslund yawns: morning vila!
<GaryvdM> Hi all
<mtaylor> esoteric bzr question - I'm wanting to grep contents of a merge for a token, and if it's found print out the filename it was found in
<mtaylor> but I only want to print it out if that token was in the text that was modified
<mtaylor> other than writing a plugin - is there a sensible way to do this?
<spiv> mtaylor: bzr merge --preview | grepdiff ...  ?
<mtaylor> spiv: aha! grepdiff == friend!
<vila> jelmer: _o/
<jelmer> vila: good morning!
<vila> jelmer: good morning to you too !
<peitschie_> hiya vila :)
<peitschie_> hi jelmer
<vila> peitschie_: hi
<jelmer> 'evening (?) peitschie
<peitschie_> it is indeed :)... about 8:30 atm actually
<peitschie_> >.<... and still my fingers feel like coding
<hulei> hello,everyone
<peitschie_> hi hulei
<jml> mgz: fwiw, mumak.net:8080/hudson has a builder for 2.4, 2.5, 2.6, 2.7 and 3.0
<jml> but for some reason it's not updating
<rjek> Morning.  I'm trying to create a bzr branch that "embeds" a branch from elsewhere, so my project can have its own local copy with my patches applied to it, and so I can easily pull from the embedded branch's upstream and merge changes (ie, so I can track it)
<rjek> For extra excitement, this upstream is in subversion, and uses subversion externals to bring in its own embedded stuff.
<rjek> I've tried branching it, and then using bzr join to additionally branch its externals, and then branching the result of that into my project.
<rjek> But I get a weird error I cannot fathom.  Complete process, with version numbers, here: http://pastebin.com/GkPUbAmN
<rjek> Am I going about this the right way, or is the extra mess caused by it being in subversion just too much?
<mgz> jml: see you've got Python 2.4 results working -> http://mumak.net:8080/job/testtools/42/testReport/
<mgz> I'm out now, but should have some time later to do fixes for some of the new issues I filed
<mgz> part of the problem seems to be subunit isn't Python 3 source compat -> http://mumak.net:8080/job/testtools/42/console
<jml> mgz: ahh yes
<jml> mgz: that's definitely an issue that I remember but couldn't be arsed solving at the time
<lifeless> life is short
<lifeless> python is hard
<lifeless> lets drink beer
<rjek> Or explain my error message to me!  That's almost as good as beer! >:)
<gthorslund> rjek: I've got no experience of svn with bzr, but if you're lucky it might be possible to clean of some dust from jelmer ;-)
<jelmer> rjek: the "working tree is out of date" warning seems odd
<rjek> jelmer: Nod.
 * maxb ponders this Savannah request. On the one hand, I've never *yet* set up an actual non-trivial Loggerhead install. On the other, I really want to do so at $work anyway.
<rjek> jelmer: Are you able to replicate the issue?
<rjek> maxb: Last time I looked at Loggerhead, I ran away screaming at the complexity.
<maxb> huh, really? It's actually surprisingly little code
<rjek> At the complexity of setting it up.
<rjek> Dependancy madness.
<rjek> Although this was /ages/ ago.
<maxb> jelmer: Ah, I had a question for you. I want to prepare a loggerhead package for 1.18, but the complexity is that the current packaging branch already contains revisions from trunk that are not on the 1.18 branch. So I need to back them out. I was planning on doing a separate commit of 'bzr merge -r 429..420' and then merging that into the packaging branch. Sound sane?
<maxb> Also, I need to figure out the stupid situation with YUI - it's excluded from the Debian package, but a suitable Debian packaged equivalent is *NOT* provided instead. Which is just ridiculous
<GaryvdM> maxb: there is a option in loggerhead to make it link to yui from a yahoo server. Maybe you could exclude yui from the package, and turn on that option.
 * GaryvdM tries to find the option.
<maxb> GaryvdM: I see the option. I reject it as a kludgy unnecessary solution
<GaryvdM> ok
<maxb> Plus Yahoo might take issue with every Debian installation of loggerhead deciding to use their servers
<maxb> I think the right solution is just to let YUI 3 be embedded in the loggerhead package until someone wants to fully maintain it in Debian
<maxb> I'm not sure whether that'll offend Debian purists though
<jelmer> rjek: I haven't tried replicating the issue yet.
<GaryvdM> Any one here know much about zope page templates (SimpleTLS.) I'm trying to add a xmlns prefix for svg, but it excludes it from the rendered page. Any ideas how to make it not?
<GaryvdM> For loggerhead
<jelmer> rjek: can you perhaps file a bug against bzr about it?
<jelmer> maxb: Hi
<jelmer> maxb: That sounds reasonable. Alternatively, you could just create a branch that was based off an older version of the packaging.
<jelmer> maxb: I also think it's reasonable to just include YUI3 in the package for the moment. Including it could certainly be considered a bug if other Debian packages (which ones?) also include it, but we can fix that some other time.
<rjek> jelmer: Which would be the most appropriate BTS for me to suffer?
<jelmer> rjek: filing it upstream in Launchpad is probably the best idea
<rjek> jelmer: https://bugs.launchpad.net/bzr/+bug/675561
<ubot5> Launchpad bug 675561 in Bazaar "Bizarre behaviour when joining branches sourced from Subversion (affected: 1, heat: 6)" [Undecided,New]
<maxb> jelmer: the reason for not basing on an older version of the packaging is then I'd have to push --overwrite to alioth, which feels nasty
<jelmer> maxb: Hmm, the current branch should probably be pushed to experimental/, anyway.
<jelmer> rjek: Actually, this might be related to the fact that the 0 revision is special in a lot of ways.
<rjek> jelmer: Ah, I've hit a bug that you said would rarely happen back in 2008 :)
 * rjek tries to work out with bzr init && bzr ci -m "Create empty branch" --unchanged
<jam> morning all
<GaryvdM> Hi jam
<Buttons840> i'm currently on revision 7, is it possible to go back and combine revision 2 and 3 into a single revision?
<LeoNerd> Explain why you believe you want to perform such an action
<rjek> Why would you ever want to do such a thing?
<exarkun> One might be using the history of a bzr branch as progressive steps in an educational tool
<dash> exarkun: i was gonna do that
<exarkun> dash: Me too
<dash> but i was going to start over from the beginning and do it right
<Buttons840> i don't know if i'll actually make the change or not; i'm just currious how it would be acheived?  is it possible?
<dash> Buttons840: no.
<exarkun> dash: I think I decided looms are a better fit, except actually using looms is a huge pain in the butt.
<maxb> Buttons840: General rule: Rewriting any part of history also requires rewriting all history after that point.
<Buttons840> right, but you could uncommit back to the revision of concern and then rebuild the remaining revisions -- probably not worth the effort, but possible still?
<GaryvdM> Buttons840: Maybe you can do it with then replay command from the bzr-rewrite.
<exarkun> maxb: Or finding hash collisions?
<dash> Buttons840: that's the same as branching at that point.
<GaryvdM> ... plugin.
<maxb> Buttons840: Yes, entirely possible - *if* you are willing to do all that and have the history then be diverged from any other branches that may exist
<maxb> exarkun: hash collisions? bzr revision-ids are not hash based
<exarkun> maxb: Oh.  What are they based on?
<maxb> Essentially timestamp + sufficient randomness to ensure that all revisions committed at the same time are still globally unique
<maxb> The committer id is included too, serving the dual purpose of making the id more human friendly and further guaranteeing uniqueness
<exarkun> Why can't you change the contents of a revision then?
<maxb> Because if anyone else has a copy of the old revision, they'll keep that
<maxb> And if the way it was changed happens to result in inconsistencies in future revisions, you have a snowballing problem of subtle data corruption
<Buttons840> am i correct in my understanding that a revision is never deleted, even in an uncommit?   if so, how can i see all revisions
<maxb> An uncommit does not delete a revision. It just moves the branch's pointer to tip revision of the branch
<maxb> The uncommitted revision persists on disk, but is no longer copied elsewhere during push / branch / etc. operations
<GaryvdM> Buttons840: You see tips that are not ancestors of any branches in a repo with bzr heads --dead
<Buttons840> GaryvdM: how does the --dead switch differ from a regular heads call?
<GaryvdM> Buttons840: bzr heads shows head of branches
<GaryvdM> Buttons840: bzr heads --dead show ones that are not
<GaryvdM> bzr heads --dead has to load every revision in the repo to find them, so it is much slower.
<Ghost101> I need some help guys.
<Ghost101> LoadLibrary(pythondll) failedInvalid access to memory location.
<Ghost101> C:\Program Files\Bazaar\PYTHON26.DLL
<Ghost101> C:\Program Files\Bazaar>bzr lp:atrinik
<Ghost101> LoadLibrary(pythondll) failedInvalid access to memory location.
<Ghost101> C:\Program Files\Bazaar\PYTHON26.DLL
<Ghost101> C:\Program Files\Bazaar>
<GaryvdM> Ghost101: What version of the installer did you use?
<Ghost101> 2.2.1-3
<Ghost101> the setup file name is: bzr-2.2.1-3-setup
<Ghost101> I think the installer is the 2.2.1 standalone
<GaryvdM> Ok
<GaryvdM> Ghost101: I'm not sure - I would try uninstall, and reinstall.
<Ghost101> Idk either.
<MTecknology> Any ideas what's up with this?...  bzr: ERROR: KnitPackRepository('lp-56956304:///~canonical-isd-hackers/drupal-teams/5.x-trunk/.bzr/repository') is not compatible with    CHKInventoryRepository('lp-56956304:///~ubuntu-drupal-devs/drupal-teams/7.x-dev/.bzr/repository') different rich-root support
<dash> MTecknology: those repos have incompatible storage formats.
<dash> probably a result of using experimental formats for svn exports to bzr, long ago.
<MTecknology> dash: oh.. can I push them unstacked?
<maxb> MTecknology: There is no way to ask bzr to ignore a server side stacking policy on first push, but, IIRC, after the first failure, things are left in such a state that if you reattempt the push, the right thing will happen
<maxb> Of course, the real question here is why does the project have a dev focus branch with different rich-root support to what you're working on?
<MTecknology> maxb: the current focus is for Drupal 5.x; I'm reworking it for Drupal 7.x. I was able to push again
<Buttons840> http://codepad.org/WmMMrWX0   what would explain this diff; there appears to be nothing different?
<Buttons840> like "- hello\n+ hello"
<spiv> Buttons840: different line endings, perhaps.
<soren> Or if you're merging from somewhere else that had independently added an identical file?
<spiv> soren: assuming that diff was generated by "bzr diff", no, because it says "modified file" rather than showing a whole file being deleted then a whole new file being added.
<spiv> I think..
<soren> spiv: Ah, yes, merging moved the conflicting file out of the way.
<soren> Hmm..
<soren> In that case, line endings are probably it.
<Adam|Lunch> Whats the easiest way to get a list of Revision # and the matching commit message from the CLI?
<bob2> bzr log?
<Adam|Lunch> ooh nice
#bzr 2010-11-16
<blueglasses> I already have a branch called testingbzr. How do I create a new branch to put the real code?
<blueglasses> I use launchpad btw
<blueglasses> anyone?
<spiv> blueglasses: you have a branch locally already?
<spiv> blueglasses: if so, just push it to where you want it to be on launchpad, e.g. "bzr push lp:~username/projectname/new-branch"
<blueglasses> i dont think so, let me check
<spiv> Well, perhaps I'm misunderstanding what you're asking.
<spiv> What do you mean by "create a new branch"?  You mean start a new branch from scratch, with no prior history?
<blueglasses> locally i have /home/user/python/projectname/files
<spiv> And is that directory already versioned in bzr?
<blueglasses> i think so
<spiv> "bzr info" or "bzr log" or whatever would confirm that if you like.
<blueglasses> i'm not a native english speaker sorry for my delay
<spiv> That's fine!
<spiv> I can only speak one language, so I'm already impressed :)
<blueglasses> I'm trying to use bazaar explorer
<blueglasses> how do I create a new branch... I might have done something wrong
<blueglasses> my project name in lauchpad is "story"
<spiv> Ok.  I don't know explorer well, but you should be able to do something like "bzr commit" to make a new commit, and then "bzr push" to publish those changes.
<blueglasses> that far i have done already
<blueglasses> but I'm commiting to a branch called bzrtesting
<spiv> I see, you have lp:~lapisdecor/story/testingbzr already.
<spiv> Oh, when you commit the changes are automatically going to lp:~lapisdecor/story/testingbzr ?
<blueglasses> yes
<blueglasses> and I wanted a new branch to put the real code (when it will come done)
<spiv> Ok, you have what we call a 'checkout' rather than a 'branch'.  It's really just a local branch configured to automatically update a remote branch at the same time.
<blueglasses> I have to push after commit
<blueglasses> to get the stuff there
<spiv> Oh, then it's not a checkout, just a branch.
<spiv> Which is fine.
<blueglasses> actually I just dont like the name 'testingbzr'
<spiv> Ok, you can rename that.
<blueglasses> i would like to keep it to learn bzr but i would like a new branch to put the real code
<spiv> If you go to https://code.launchpad.net/~lapisdecor/story/testingbzr/+edit you can change the name.
<spiv> Or you can ignore that old branch on Launchpad and tell bzr explorer to push to a new location with the name you want.
<blueglasses> that one sounded better
<spiv> (To create a new branch on Launchpad you simply push to it.  There's no need to register it or initialise it first.)
<blueglasses> cool
<blueglasses> so I can call it main
<blueglasses> ok I will try to make some code and then push it to a new branch
<blueglasses> thank you so much for the help, still a noob here, but with good heart :-)
<blueglasses> time to bed now
<spiv> blueglasses: good night
<blueglasses> good night
<poolie> hi all
<GaryvdM> Hi all
<vila> hi all !
<vila> hi GaryvdM , poolie
<vila> poolie: feeling better ? Still here ?
 * GaryvdM _o/ @ vila
<vila> :)
<vila> GaryvdM: I wonder whether you're creative in online glyphs or starting coding in perl :)
<GaryvdM> Huh?
<vila> _o/ @ sounds like noise, aka perl code from the pov of people unaware about perl conciseness ;)
<poolie> hi vila, i am better now
<GaryvdM> vila: ah :-)
<poolie> it does look like perl, or haskell
<vila> cool
<GaryvdM> Hi vila
<GaryvdM> Hi poolie
<poolie> hi gary
<spiv> mgz: yep, landing something on trunk sorted out the merge proposals that lp hadn't yet noticed were merged.
<jelmer> hey GaryvdM, poolie, vila, spiv
<vila> jelmer: hi !
<vila> spiv: wanna talk about https://code.edge.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406 ? Or should we do that earlier tomorrow ?
<vila> jelmer: any feedback about the above ?
<jelmer> vila: you mean the checkout tags propagation?
<jelmer> Ah, I guess so.
<vila> jelmer: yup, the impact of bzr-svn or other foreign plugins in particular, the mp is targeted at lp:bzr/2.2
 * jelmer has a quick look
<vila> s/impact of/impact on/
<jelmer> vila: The way backwards compatibility is handled looks reasonable to me; I can do some testing later today if that would be useful.
<vila> jelmer: yes it would and would be appreciated ;)
<mandel> Hello, quick question, what does bzr do with illegal chars in filenames on windows, example, on linux I use 'stupid: name' what would happen on windows?
<rjek> Excitement!
<beuno> hello hello
<beuno> any bzr devs around?
 * beuno stares at vila 
<vila> hooo  beuno !
<vila> forgive me I was having a small lunch, just back :)
<beuno> hai vila!
<beuno> how's it going?
<vila> better :)
<beuno> I have this horrible bzr traceback: https://pastebin.canonical.com/39793/
<beuno> but other than that, good
<beuno> better than who?  :)
<vila> that, my friend, is very bad (the traceback)
<vila> better than me yesterday :)
<vila> I was already good yesterday :)
<beuno> you been sick?
<vila> beuno: what bzr version are you using (packaged ? from sources ?)
<vila> beuno: no no, just getting better every day :)
<beuno> vila, stock maverick
<beuno> no funny business
<vila> ok
<vila> hmm
<vila> bzr info -v
<vila> trying to find progressive checks
<vila> bzr check (this one could take time)
<vila> branching from the revision just before the commit
<GaryvdM> Hi beuno - How come not a public traceback pastebin?
<lifeless> beuno: fs fail?
<lifeless> bzr: ERROR: zlib.error: Error -3 while decompressing data: invalid distance too far back
<beuno> lifeless, no visible fs failures that I know of
<GaryvdM> Thanks lifeless
<beuno> hi GaryvdM, it's a private branch, so was lazy and pasted it in private instead of making sure I wasn't leaking anything  :)
<beuno> sorry about that
<GaryvdM> beuno: np
<vila> beuno: number and size of pack files
<beuno> vila, http://paste.ubuntu.com/532994/
<vila> beuno: I should have started with: this is gzip telling us that the data is corrupted which is unseen so far except when related to fs failue
<vila> failure
<beuno> vila, http://paste.ubuntu.com/532995/
<beuno> ah
<beuno> I have plenty of space
<vila> beuno: then start with a backup
<beuno> 467 Nov 16 09:25:17 beuno-laptop kernel: [1497398.983861] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=600
<vila> beuno: at least the repo (which should be enough)
<beuno> 468 Nov 16 09:25:31 beuno-laptop kernel: [1497412.578739] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
<beuno> that's the only thing I see
<lifeless> beuno: it might not be this boot
<lifeless> beuno: there are a few options :
<lifeless>  - corrupt disk
<lifeless>  - memory bit error
<lifeless> beuno: md5sum your packs
<lifeless> and check the sums match the pack names
<vila> we really should have that in core
 * beuno checks
<beuno> lifeless, they all match
<lifeless> oh, my bad
<lifeless> its in an index.
<beuno> http://paste.ubuntu.com/532998/
<lifeless> one of your indices is naffed
<beuno> so, these *.six/tix/rix?
<lifeless> voidspace: yes
<lifeless> bah
<lifeless> beuno: yes
<vila> lifeless: so 'bzr pack' time ? Or do we use the indices for that ?
<beuno> vila, lifeless, so, do I have a way out of this?
<vila> beuno: if you did a backup, try 'bzr pack;
<vila> beuno: if you did a backup, try 'bzr pack'
<beuno> I'll backup now
<beuno> vila, packing!
<beuno> vila, same tb
<vila> wow
<beuno> vila, http://paste.ubuntu.com/533014/
<vila> ah, during the pack
<lifeless> to be expected
<lifeless> pack has to read data :)
<lifeless> bzr dump-btree can help you find the damaged index
<vila> yeah, I expected he could rebould the indices from the packs :-/
<vila> s/expected/hoped/
<vila> which is what we need
<lifeless> no
<vila> oh good
<beuno> so, run bzr dump-btree?
<vila> beuno: yes, starting with the .cix indices as they seem to be the ones causing problem (from the tb)
<vila> lifeless: you still haven't elaborate on this 'no'
<lifeless> vila: the indices have unique data
<vila> urgh, still ?
<lifeless> vila: until we fix it
<beuno> vila, so run that command against each .cix?
<vila> yes
<vila> beuno: quick check: you don't have *empty* indices right ?
<beuno> vila, let me look
<vila> lifeless: but then there is probably no escape for beuno other than recreating its repo from scratch (or almost) ?
<lifeless> indeed
<beuno> vila, all of them ahve more than zero bytes
<beuno> ah
<beuno> ok
<beuno> that sounds fun
<vila> :-/
<beuno> I guess I can re-branch from launchpad
<lifeless> restore from backup :)
<beuno> do you want this bug reported?
<beuno> it's a few hundred mb, so not terrible
<lifeless> you've had a fs glitch, for sure.
<lifeless> its not a sync-crash, or you'd have an empty index.
<beuno> okk
<lifeless> you've either got a bad memory dimm - in which case rebooting may fix this.
<vila> beuno: let see if we can isolate which index is the culprit
<beuno> so maybe I need to run fsck
<beuno> vila, sure
<lifeless> or you've got a bad block which lost data
 * beuno nods
<beuno> I can try rebooting
<beuno> I haven't done that in a few weeks
<lifeless> note that if reboot does not fix it, it doesn't mean that the block is bad - a bad dimm that results in a bad write is indistinguishable (except via disk read stats)
<beuno> ok, I'll let you know in 2 minutes
<beuno> re-packing...
<beuno> 3/7
<vila> beuno: you've connected from another pc ?
<vila> s/'ve/'re/
<maxb> IRC proxies ftw :-)
<beuno> vila, no, irss + ssd disk
<beuno> reboot in 12 seconds
<beuno> 4/7
<beuno> I think ti's fixed
<beuno> because it's way further than before
<vila> let's wait
<beuno> 6/7
<beuno> vila, lifeless, reboot made pack work
<beuno> so thank you  :)
<vila> beuno: retry commit now
<lifeless> beuno: replace your memory.
<beuno> vila, commit worked
<vila> beuno: I won't feel secure *at all* if I were you :-/
<beuno> lifeless, remote hardware diagnosing, this is a new one for me!
<beuno> vila, I should be able to replace the ram fairly quickly
<beuno> 99% of what I care about is on the interwebs
<beuno> so i'll backup the remaining 1% and turn on paranoid mode
<vila> ha, I feel better then :)
<beuno> thank you much!
<jam1> morning all
<GaryvdM> Hi jam!
<jam> hi GaryvdM
<txdv> is there to way to merge 2 commits seperated by other commits?
<txdv> i got c1,c2,c3,c4/head, where cX stands for commit with number X and head for the tip or whatever you bzr guys calls
<txdv> call*
<txdv> i want to somehow put the changes from  c4 into c1
<Odd_Bloke> txdv: It doesn't make sense to talk about putting changes from one commit "into" another commit.  What would you expect it to look like?
<txdv> well i got a fucking commit nazi in my work force
<txdv> and whenever there is an additional empty line added by accident
<txdv> he forces me to rewrite the complete history
<txdv> So let's just pick a scenario like, i need to remove a simple line in a past commit
<txdv> adding just another commit fixing exactly that issue won't help
<Odd_Bloke> txdv: Sounds like you want rebase...
<dash> or a tire iron
<txdv> Odd_Bloke: this scenario doesn't include diverged trees at all
<txdv> Or can you explain how to incorporate the changes from c4 into c1 with rebase?
<vila> txdv: wow, I feel your pain (I do a a lot of typos and my histories are nothing close to linear)
<vila> txdv: so roughly you wan to cherry-pick and may be with luck use a bit of rebase
<vila> txdv: so you start with a "clean" branch
<vila> txdv: then you cherry-pick 'bzr merge ../dirty -c<1>' 'bzr merge -c<4>'
<vila> txdv: -c<4> is a shortcut for -r3..4
<vila> txdv: and rebase should do for 2 and 3
<vila> txdv: 'bzr revert --forget-merges' if for whatever reason you need to commit changes without tracking where they come from
<txdv> awesome
<vila> txdv: ... or may be you just do a single big commit with the --forget-merges trick above, after all if "he" doesn't care about history "he" may even prefer that :-/
<txdv> that motherfucker is uncommiting shit from trunk all the time because of the history
<txdv> even his own commits
<vila> right, but let's just try to watch our language here :-D You're welcome to express your pain otherwise ;)
<vila> txdv: may be 'bzr merge --interactive' can help you too ?
<txdv> ill look into it
<txdv> the checkout the cherry picking first
<txdv> thanks again
<vila> anytime ;)
<txdv> this dude is ridicolous
<txdv> he forces me to rewrite the history on my branch
<txdv> yet he puses right away to the trunk and uncommits it after a while
<vila> the uncommit is very damaging if the branch is shared :-/
<GaryvdM> txdv: You can turn on append-revisions-only so that he can't uncommit.
<txdv> O i already spent 2 hours of debugging stuff because i thought my merge messed up, while he uncomited his bad commit meanwhile
<vila> txdv: may be you should start using qlog and its ability to hide lower level commits (have a look at the bzr history)
<txdv> GaryvdM: on launchpad too?
<GaryvdM> txdv: Yes - easy with the new bzr config command, with out, you need to modify the branch config with sftp
<vila> GaryvdM: wow, I didn't thought about using 'bzr config' for that ! Did you try it ? (/me frantically notes to add tests for remote branches)
<GaryvdM> vila: no - I just assumed. Will test now.
<vila> GaryvdM: I'm just silly, I made sure you can *read* remote configs and then totally forget you can update them too :)
<txdv> where can i get this qlog?
<vila> txdv: it's part of the qbzr plugin
<GaryvdM> txdv: it's part of the qbzr plugin. What os are you using?
<vila> txdv: what OS/distro version are you...
<vila> damn GaryvdM
<vila> :)
<txdv> y i already got it installed
<txdv> debian i am using: apt-get install qbzr
* You're now known as ubuntulog
<vila> txdv: less than one minute between 'where can i get' and 'got it installed'...
<txdv> i did a 'aptitude search qlog' after you mentioned qlog
<txdv> couldn't find it, therefore i thought it was not in the deb repos
<vila> still, I'm always amazed by how easy it can be to get the right tools...
<txdv> not with windows
<txdv> windows is a timewaste
<txdv> 2hours in order to install visual studio on a brand new machine
<vila> right, you need a good packaging community, that was my point ;)
<txdv> actually im not too happy with the unix way of directory structure
<txdv> the only thing that you should do in order to install a programm is to unzip it in a directory
<txdv> or untar
<vila> but they tried that with SunOS and you end up with nightmearish PATH MANPATH LD_LIBRARY_PATH and so on
<vila> and that doesn't even start addressing compatibility and dependencies...
<dash> OSX did it
<dash> sort of kind of.
<vila> right, but user-facing apps only
<txdv> the problem with linux is the compatibility
<vila> yeah, agree, sort of kind of, the .app is very nice, don't get me wrong though
<txdv> everything changesi n the system
<dash> vila: can't say i'm a fan, really
<GaryvdM> Yhea - That's one of the things that bugs me with windows, is adding to PATH, and adding to PATH, and adding to PATH....
<txdv> they should automatically check programm\*\bin
<txdv> why path?
<vila> dash: it's pretty cool to be able to test an app and throw it away without worrying about hidden dependencies though (I know, I know there are exceptions)
<txdv> vila: CDE enables one to build and run standalone apps with all dependencies
<vila> CDE, you mean the CDE in Solaris or something else ?
<vila> but anyway, the problem starts when you want to share libraries
<vila> or any other kind of resources
<txdv> http://goo.gl/h6IP3
<Odd_Bloke> Sounds like a guaranteed way to mean you don't have to write portable code, and a huge resource waste.
<Odd_Bloke> N.B. Not portable code is probably bad code.
<txdv> if you just want to get shit running on an old machine it is good enough
<vila> hehe, right, but I like my machines to be lean and clean ;)
<Odd_Bloke> So's Debian. :p
* You're now known as ubuntulog_
<vila> note the 'S' here, I think I'm currently maintaining ~5 physical and ~15 virtual machines and I don't want to *debug* them :)
* You're now known as ubuntulog
<fullermd> Of course not.  When you need to, you just bug me   :p
<vila> hehe, I wish I can do that for all of them ;)
<fullermd> Oh, you totally can.  "I found the problem with this one, it's running a weird OS..."
<vila> lol, yeah *that* will apply to *all* of them :)
 * fullermd wonders if you have the test suite running on Plan 9...
 * vila searches for a Plan9.iso
<vila> there is one ! :D
<fullermd> I wonder if anybody's ever tried using bzr on it.
<vila> is there a python there to start with ?
<fullermd> No idea.
<fullermd> I'd assume it's popular enough (and near enough to POSIX in various ways) that perl and python both exist on it.
<fullermd> But I've been wrong before.  Occasionally.  And after I killed all the witnesses, it never REALLY happened...
<SimonK> ?
<jelmer> hi SimonK
<GaryvdM> Hi SimonK
<jelmer> hey Gary
<GaryvdM> Hi jelmer
<GaryvdM> ubot: tell me about bug #647204
<ubot5> Launchpad bug 647204 in QBzr "qbrowse show log crashes: AttributeError: 'BzrBranch7' object has no attribute 'startswith' (affected: 3, heat: 26)" [High,Confirmed] https://launchpad.net/bugs/647204
<GaryvdM> SimonK: Ok - I don'
<LeoNerd> bzr: ERROR: Unsupported protocol for url "git://perl5.git.perl.org/perl.git    <==  Did I do something wrong, or is it not supported?
<GaryvdM> SimonK: Ok - I don't like it when the bug just goes away, so I'll try reproduce it in older revisions.
<GaryvdM> SimonK: Thanks for testing.
<maxb> LeoNerd: no, that works
<maxb> LeoNerd: oh, and we're thinking thursday in the office here
<LeoNerd> Righty.. I'm busy this end Thursday I think.. :/ but never mind...
<LeoNerd> maxb: Well, it doesn't work for me.. ;)
<maxb> I assume you just don't have bzr-git and/or dulwich installed
<LeoNerd> Oh. Duh! I was sure I had installed it :p
<LeoNerd> EWRONGMACHINE
<maxb> Hmm, what's Wednesday like for you, we are vacillating as usual
 * LeoNerd admits user error, returns to lurking in the shadows
<LeoNerd> Oh... OK... now dulwich won't install... massive "SyntaxError" complaints
<maxb> !
<maxb> pastebin?
<LeoNerd> http://paste.leonerd.org.uk/?show=1135
<maxb> erm, eek
 * maxb reads in detail
<jelmer> we don't support python 2.3
<LeoNerd> OK... So... Why's it trying to run it?
<jelmer> I guess we don't have that declared in debian/control
<LeoNerd> Anything I can do to fix it?
<maxb> Why on earth do you even have python 2.1, 2.2, 2.3 installed on a squeeze machine? :-)
<LeoNerd> No idea
<LeoNerd> Probably never removed them
<jelmer> uninstall python2.3 ?
<LeoNerd> OK..
<jelmer> I'll fix the package to add >= 2.4
<LeoNerd> Riiiighty... Having done that, it's now running nicely smooth.. thanks.
<maxb> LeoNerd: :-) ... and Wednesday?
<LeoNerd> Probably busy then also...
<maxb> k
<LeoNerd> Don't worry this week
<LeoNerd> Hah... ENOSPC
<LeoNerd> guess I'd better grow my home then.. :/
<SimonK> GaryvdM: I've got a pending update for BzrExplorer that populates %%selected in tool definitions with what is selected in the working tree browser.  How do you completely cancel a selection in the qbzr working tree browser?
<GaryvdM> Um..
<GaryvdM> I'm sure it's fine to just do treewidget.selectionModel().clear() -http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qitemselectionmodel.html#clear
<SimonK> GaryvdM: Ah but how does the user do it?
<GaryvdM> Oh
 * GaryvdM goes to look at the mp
<GaryvdM> SimonK: If you have 1 item selected, and you ctrl+click on it, then you have no selection.
<GaryvdM> SimonK: then you need to use the context menu key on your keyboard, cause when you right click, you get a selected item.
<SimonK> GaryvdM: Thanks
<SimonK> GaryvdM: While on the subject, should I update it to support %selected in 'shell' tools?
<GaryvdM> SimonK: I'm not sure what that is. I've never used the tools utility in bzr-exporer. If it would be usefull to you, then yes I guess.
<SimonK> GaryvdM: It's not particularly useful - I just thought it would be more consistent
<mtaylor> you know what would be great? if there were a url shortcut which expanded to my username...
<mtaylor> so that instead of doing bzr push lp:~my-long-ass-username/drizzle/branchname, I could do: bzr push lp:~/drizzle/branchname or something
<GaryvdM> mtaylor: I think jam recently fixed that for lp.
<GaryvdM> mtaylor: It previously work for other urls, e.g. sftp://server/~/mybranch
<mtaylor> GaryvdM: wow. I llove it when I request something and it just happens :)
<poolie> hello
<GaryvdM> Hi poolie
<GaryvdM> mtaylor: I just checked, it was added in 2.3b1
<mtaylor> GaryvdM: excellent. I'm excited to use that when 2.3 lands!
<poolie> hi monty
<poolie> jam, hi?
<poolie> mtaylor: i think you only need 2.3b1 (or now b2?) on the client to use it
<poolie> so you're waiting for that in... maverick-updates?
<maxb> No, maverick is in 2.2.x
<maxb> s/in/on/
<poolie> oh of course
<poolie> so you'd need to use the ppa, or wait for natty
<poolie> it's early :)
<poolie> GaryvdM: i think it's quite likely that fixing 483388 would fix 588698
<poolie> which i guess is the real test for whether they are a dupe
<poolie> and of course it has a good simple reproduction case
<poolie> hullo?
<fullermd> Shhh.  I'm hunting wabbits.
<SimonK> exit
<GaryvdM> poolie: I agree (sorry - did not think it was a question.)
<txdv> i am the ruler of the worlds
<poolie> anyhow, if you want to talk about it more, i'll be around, otherwise just go for it
<GaryvdM> Ok
<jam> hi poolie
<poolie> hi there, shall we have a talk?
<jam> poolie: sure
<poolie> skype or pots?
<jam> poolie: skype is easy
<homeasvs> Hi.  I have a local branch that I want to now merge onto an lp branch.  BOth are the same up to revision 23
<homeasvs> however, the public branch has a revision 24, while the local branch has 24-30
<homeasvs> I am trying to merge all of 24-30 onto 23, but keep the separate commits
<homeasvs> I started by doing merge -r 24 my/local/branch
<homeasvs> that applies revision 24 of the local branch
<homeasvs> when I do commit, it says that I have a pending merge, the same as the one I just tried to merge
<dash> homeasvs: you shouldn't have to specify the revision at all
<homeasvs> is that normal? How can I commit exactly revision 24 of the local branch onto my public checkout, keeping the commit message?
<homeasvs> dash, if I don't specify anything, it just merges all changes at once it seems
<homeasvs> dash, 'squashing' the 6 commits into one as it were
<homeasvs> unless I'm missing something?
<dash> homeasvs: it doesn't squash them, it nests them. :)
<homeasvs> how can I convince myself it nests them ?
<homeasvs> and how can I mark the one commit that had a conflict as 'this one goes separate, but let all others pass through as separate commits' ?
<dash> homeasvs: so 'bzr log' shows the merge commit as a single commit - but 'bzr log -n0' shows the nested subcommits
<homeasvs> dash, my local branch is a mistake and I don't want a record of it later
<homeasvs> ie i'd prefer to cherrypick all but one revision and commit them as unnested.  is that possible?
<dash> anything's possible, i'm sure
<homeasvs> heh
<maxb> homeasvs: OK, so it sounds like bzr merge -c is what you want
<maxb> So, you'd freshly branch the public branch to a new local work area, then you would 'bzr merge -c 24 ../mistake-branch', 'bzr commit'
<maxb> and then you would repeat for each revision of mistake you actually wanted to keep
<homeasvs> maxb, yeah, tried that, but it still records the fact that it's a merge from some other branch
<homeasvs> I bruteforced it by creating 6 diffs, one for each rev, and applying them manually
<maxb> oh, I see
<maxb> bzr merge -c will only record the merge if you are actually merging the 'next' revision, without skipping any
<dash> homeasvs: i believe the 'rewrite' plugin is for these situations
<maxb> if you really really do want to throw away that info, 'bzr revert --forget-merges' before committing
<maxb> rewrite could have partially applied here, but I don't believe it allows you to drop a revision
<mgz> that's not the right answer to the question posed by homeasvs
<seiflotfy> is poolie around
<poolie> seiflotfy: hi, i am, but i'm on the phone right now
<mgz> the right answer is "it's okay branches have different revision 24s, and it's okay that when you merge your revisions 24-30 become part of a new revision 25"
<mgz> the log doesn't need to be a line with dvcs, it can have branchy bits.
<mgz> going straight to bzr-rewrite with that kind on query is leading people down the wrong path.
<homeasvs> mgz, in this particular case I specifically do not want this to show up as a merge from a branch
<maxb> That's true, but homeasvs also mentioned omitting one of the revisions from the existing branch
<homeasvs> mgz, so I do think that a rewrite would have been the right case here
<maxb> homeasvs: Of course, another very relevant question is: Why do you care about it not showing as a merge?
<mgz> you need to justify why you need that to be the case
<homeasvs> because the branch was wrong ? it was a cleanup of some work I did a long time ago and part of that work I already did publically apparently
<homeasvs> not sure why I need to 'justify'  though :)
<mgz> if you want to revert a wrong revision that's publicly available, you merge -rN..N-1
<mgz> s/justify/explain/ if you like.
<mgz> if it's a revision you've not shared yet, uncommit.
<homeasvs> uncommit seems to completely lose the work that was in the commit though
<GaryvdM> homeasvs: uncommit dose not revert. It goes back to were you were before the commit.
<mgz> generally just reverting bad revisons in a seperate commit with a "I screwed up" commit message is what you want when there's enough history to be worth preserving
<mgz> either you care about the history, of which your screwup was a possibly-significant-later part, or you don't and may as well just commit the diff as one revision
<mgz> am interested what you actually ended up doing homeasvs
<homeasvs> mgz, like I said above, just generate a patch for each revision, then apply the ones I wanted by hand
<GaryvdM> poolie: ah - ok - after further investigating I see that 588698 and the initial example given in 483388 are in fact different.
<poolie> k
<mgz> homeasvs: can use uncommit and shelve to do similar thing with marginally less labour for future note.
<homeasvs> mgz, will keep that in mind, thanks for the tip
<poolie> mgz, hello
<poolie> spiv, good morning?
<StuartPB> How do I make a new version of a branch where one file doesn't exist in the history?
<poolie> StuartPB: you want to pretend it never happened?
<poolie> i think bzr-rewrite can do that
<StuartPB> how do I use it
<StuartPB> is it in the default bzr windows install
<spiv> poolie: good morning
<mgz> 33 failures... 5 failures...
#bzr 2010-11-17
<poolie> hi spiv, how are you? and what fabulous adventures will you have today?
<spiv> poolie: working towards bug 309682; I have a patch that works, but polishing all the little issues the patch glosses over is surprisingly involved.
<ubot5> Launchpad bug 309682 in Bazaar "tags are copied but their revisions may not be (affected: 0, heat: 10)" [Low,In progress] https://launchpad.net/bugs/309682
<poolie> how about a catch up call in a few minutes?
<spiv> Sure
<vila> hi all !
<GaryvdM> Hi vila, Hi all
<vila> GaryvdM: hey !
<GaryvdM> vila: I hope you don't mind me asking about test writing a test. For bug 588698. The current tests that deal with merging merging new roots, crisscross merges, etc only check the shape of the graph after the merge. There are no asserts on the state of the files in the wt. This is done in other test that don't look at the shape of the graph. Would it be ok if my test for this bug did both?
<ubot5> Launchpad bug 588698 in Bazaar ""bzr merge" fails "Branches have no common ancestor" (affected: 1, heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/588698
<vila> GaryvdM: if you feel the need then go for it
<vila> there is no absolute rules about what a test *must* check
<GaryvdM> Ok
<vila> too little is as bad as too much but this can be rather subjective at times
<GaryvdM> I would like to do both, because I'm not sure exactly it should work, and I would like to define it in a test.
<vila> GaryvdM: may be two tests then ?
<vila> GaryvdM: or more :)
<vila> GaryvdM: ideally a test should check one thing to enhance the overall defect localization
<GaryvdM> vila: But the actions that the 2 test would perform would overlap 95%
<vila> GaryvdM: that is, a single defect is caught by at least one test which makes it obvious what the defect is or at least narrow down the code that needs to be investigated
<vila> GaryvdM: it's hard for me to judge without concrete examples, but sometimes this indicates tests that are too high-level
<vila> GaryvdM: in this case drilling down to get closer to the code you want to test avoid the duplication
<vila> GaryvdM: in some cases though, due to some bad layering, you just can't avoid it so just go for the duplication but add comments or FIXME explaining the issue
<GaryvdM> Ok
<vila> GaryvdM: feel free to submit early versions for feedback, MPs can be used for that too (if properly explained)
<spiv> GaryvdM: the first thing to optimise for in a test is clarity
<spiv> GaryvdM: refactoring to reduce duplication is often helpful for that goal of course :)
<poolie> hello vila
<vila> poolie: hey !
<spiv> GaryvdM: but it's important that the *intent* of a test is clear: if it's not, then when it fails, or when it needs to be updated for API or behaviour changes, then it's unclear what should be done.
<vila> poolie: dear PP, I havean MP approved but its pre-requisite, could you help me ? https://code.edge.launchpad.net/~vila/bzr/671050-config-policy/+merge/40343
<vila> s/but its/but not its/
<spiv> GaryvdM: so if there are multiple aspects you want to verify it can be clearest to make multiple tests, so that each can have one explicit purpose.
<GaryvdM> ok
<spiv> GaryvdM: where I find it gets tricky is when I'm not sure yet what the behaviour should be, and I'm writing the test to help me discover that... :)
<GaryvdM> spiv: And that is the case here...
<spiv> But I guess it's like any other sort of authoring: you just keep revising till it makes good sense.
<poolie> vila, done, thanks for asking
<spiv> GaryvdM: so it's fine to start with an exploratory test (or tests) that probably do too much, so long as you are aware that once you've explored and hopefully understood the new territory it's probably worth reviewing the tests.
<spiv> GaryvdM: (yes that sentence has lots of qualifiers, I'm not sure these are hard-and-fast rules...)
<vila> poolie: great ! I'll tweak the comment, that's a point with quite deep implications that should be better addressed with the new config scheme but some parts are still unclear in my mind, so yes, a FIXME is appropriate
<vila> spiv: should we talk about https://code.edge.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406 ?
<spiv> vila: I chatted with poolie about it a bit
<spiv> vila: on one hand, I'm pretty confident about the backwards compat stuff... but on the other the bug report has been pretty quiet, so the urgency for getting it in 2.2 is low.  So I'll just land it in 2.3 for now.
<spiv> vila: (if later we decide it might be good to have in 2.2 after all... well, we know where to find the patch!)
<spiv> vila: thanks for the review
<vila> spiv: ha great, I feel relieved :)
<poolie> yay :)
<poolie> i had such a good day of mgmt today
<poolie> (imho :-)
<vila> poolie: way to go :)
<vila> poolie: mgmt taks are the hardest to quantify which is a source of frustration when you try to summarize: "what the hell did I do today/this week/this month" :D
<poolie> yep
<vila> AAAARGH, I hate vbox when is starts to randomly generates mouse clicks all over the place !
<poolie> !
<poolie> that's what cats are for :)
<poolie> ok i think that's enough fun for today
<vila> hehe
<awilkins> Hi, I'm running bzr 2.3b3 on CentOS 5 (python2.4), bzr-svn 0.7.5, subvertpy 1.0.4 and getting 'function' object has no attribute 'decode' when trying to pull svn branches ; stack trace http://pastebin.ubuntu.com/533419/
<vila> awilkins: bzr-svn bug, try trunk ?
<vila> awilkins: file a bug otherwise
<spiv> awilkins: I agree with vila
<awilkins> Looks like it's passing a generator to a function that expects a string
<awilkins> Going to try it with 2.2.1
<awilkins> Ah, well that produces a different error, so that's progress. I think the previous thing is a change to the API in 2.3 vs 2.2 ; the contructor in 2.2 expects a generator function, in 2.3 it expects a string
<awilkins> Now it's a 2.5-ism I think ; 2.4 has no "any() " function, right?
<vila> hmm, 2.2 was expecting a callable not a generator but yes, that's the offending change
<vila> but where is any() involved ?
<awilkins> vila, The calling code calls it a generator ... I'm not very pythonic I'm afraid
<awilkins> any() is in bzr-svn
<awilkins> logwalker.py
<awilkins> Just patching it
<awilkins> Grr. qbzr needs more context menus. Just want to be able to blame something and do a switch -b from the log menu
<awilkins> jelmer, Looks like you already noticed that logwalker.py python2.4 bug :-)
<GaryvdM> awilkins: Noted
<vila> mgz: testtools-0.9.6 has been installed on pqm
<vila> mgz: don't rejoice too fast though, we lost subunit in the process :-}
<vila> mgz: this was an announce from the be-ready-but-not-too-fast dept
<hangfire> I'm mainly an svn user, and I want to get a checkout from bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth . I've tried bzr co, bzr pull, bzr branch, and I get errors saying "not a branch". bzr init says that it's a "Shared repository". How can I get a copy?
<jelmer> hey hangfire
<hangfire> jelmer: hey
<jelmer> hangfire: you'd want bzr branch or bzr co, but to check out an individual branch rather than the full repository
<hangfire> jelmer: How can I get a list of branch nameS?
<Odd_Bloke> hangfire: There should branches underneath that repository, and those are what you deal with/check out in bzr.
<Odd_Bloke> jelmer's clearly on it. :)
<jelmer> hangfire: Actually, looking at this again, is there any reason you're using bzr:// rather than http:// ?
<jelmer> Odd_Bloke: hey! long time no see :-)
<hangfire> jelmer: That's what's listed on sf.net :P
<Odd_Bloke> jelmer: Indeed.
<Odd_Bloke> jelmer: I've been hanging around a bit more because I heard there was a job going. ;)
<hangfire> jelmer: ah! got it. Thanks
<hangfire> Odd_Bloke: thanks too!
<jelmer> Odd_Bloke: Ah, right, that one :-)
<Odd_Bloke> jelmer: Congratulations on that, by the way. :)
<Odd_Bloke> Since I was really spending time contributing to bzr (and other FS projects) I've gained both a job and a girlfriend, so my time is considerably more scarce than it was.
<jelmer> Odd_Bloke: Thanks!
<jelmer> Odd_Bloke: Ahh! I wondered what had happened to you.
<Odd_Bloke> The job is with credativ, who work with free software, so it's not all bad.
<Odd_Bloke> I'm just spending my time working on business logic stuff like OpenERP.
<Odd_Bloke> And sysadmin stuff, and some website work in Django.
<jelmer> Odd_Bloke: Ah, cool. Wasn't Chris or Johnny working there as well?
<Odd_Bloke> jelmer: jonnylamb works as Collabora.
<Odd_Bloke> Or at least did.
<Odd_Bloke> Which may be where you're thinking of.
<jelmer> I'm pretty sure I met another friend of yours who worked there, perhaps somebody other than Johnny or Chris.
<fullermd> Well, that's hardly fair.  Messing with bzr hasn't gotten me a job or a girlfriend   :(
<Odd_Bloke> jelmer: Tim Retout?
<Odd_Bloke> Brad Smith, and Chris Halls are the other DDs who do/have worked here.
<Odd_Bloke> And I assume you only know DDs. :p
<jelmer> Odd_Bloke: I think so.
<Odd_Bloke> fullermd: Waaah. :p
<jelmer> Odd_Bloke: (-:
<Odd_Bloke> OpenERP, which I spend most of my time working on, has a pretty lame upstream, I should probably get back into spending some spare time doing FS stuff.
<jelmer> I vaguely recall seeing something about openerp and bzr recently
<jelmer> somebody wanting to extend bzr-stats
<Odd_Bloke> They do use Launchpad.
<Odd_Bloke> At least for interfacing with contributors/users who are external to their partner programme.
<jelmer> ah, cool
<smoser> wonder if anyone can help. i think i'm not sure if i'm using import-upstream correctly or not.
<smoser> $ bzr branch lp:ubuntu/natty/euca2ools natty.dist
<smoser> $ cd natty.dist
<smoser> $ bzr import-upstream 1.3.1 ../dl/euca2ools-1.3.1.tar.gz
<smoser> results in http://paste.ubuntu.com/533507/
<smoser> i'm on natty, but i think i'd seen this before
<maxb> smoser: I believe you need to add --version before the 1.3.1
<smoser> no. you do for merge-upstream, import-upstream wants it that way
<maxb> Also, isn't it merge-upstream
<smoser> (at least per its usage)
<maxb> oh. ETOOMANYCOMMANDS
<smoser> i actually want the import-upstream rather than merge-upstream. i just want the upstream pulled in, and then will merge it manually (basically dropping all ubuntu changes and patching in)
<smoser> merge-upstream just leaves me with dozens of conflicts
<smoser> james_w, ^ you have thoughts on above ?
<maxb> smoser: is the debian/watch screwed up or is euca2ools-1.3.1-src-deps.tar.gz the right thing?
<smoser> maxb, i'm not sure. i didnt' even look at the watch. silly me. probably should have looked there first.
<james_w> smoser, please file a bug
<maxb> I think the watchfile is erroneously too permissive
<smoser> james_w, ok
<maxb> smoser: fwiw, commenting out the line it breaks on appears to allow it to function correctly
<maxb> it would appear to simply be a missing "if upstream is not None:"
<james_w> smoser, lp:bzr-builddeb should have a quick fix for that problem
<james_w> maxb, indeed
<salgado> does anybody know why lazr.uri is not included in the OSX bundle (http://wiki.bazaar.canonical.com/MacOSXBundle/SnowLeopard)?  it's needed by lp-propose
<james_w> salgado, does lp-propose depend on launchpadlib, or just lazr.uri?
<salgado> james_w, probably launchpadlib
<salgado> haven't checked, but it didn't work for martohls because lazr.uri was missing
<james_w> salgado, right, I'm wondering if launchpadlib is bundled, or it's just reporting the first of a few missing dependencies
<james_w> I don't know who builds the bundle though
<salgado> launchpadlib is not included in the bundle listing on the wiki
<maxb> james_w: Oh, btw, remember I said I was going to fix the missing tags issues blocking UDD imports?  Well, just so you know, I fixed one locally and then found the importer did all kinds of bizarre stuff with parallel importing into squeeze and sid, so I got blocked on having time to dig into that weirdness.
<james_w> maxb, bizarre how?
<maxb> Importing the same upstream version multiple times was the most obviously wrong thing that I recall
<smoser> bugger. i had opened a bug. but it appears launchpad isn't wanting me to do that now
<maxb> Also doing history-diverged distinct imports of the same debian version number on the squeeze and sid branches
<vila> jam1: ping
<james_w> maxb, the latter is intentional if the branches have previously diverged
<jam> hi vila
<vila> jam: how are things going ?
<jam> pretty good today. how about you?
<vila> jam: testtools-0.9.6 has been installed on pqm BUT subunit has been removed
<vila> jam: mthaddon is adding subunit-0.0.6 from our stable ppa again, but the build is still ongoing
<jam> sigh
<vila> jam: since I will EOD soon, it would be nice if you could check how it goes
<vila> jam: I'm not asking for landing my stuff, just make sure we *can* land something :-/
<jam> sure
<mgz> ha, upgrading testtools broke landing?
<vila> jam: what are you working on these days ? hpss on lp ?
<vila> mgz: AIUI testtools requires some version of subunit which wasn't the one installed
<vila> mgz: my previous ping was to warn you that we *should* be able to finally land your branches so you may want to refresh them
<mgz> ah. it... shouldn't work like that, subunit depends on testtools not visa versa, but I can imagine something broke.
<mgz> vila: well, they'll need to head merged, they predate the NEWS split.
<vila> mgz: yeah, so that may means shuffling the news entries anyway
<jam> vila: so what's up with the 'temp-commit-file' being sent every hour or so? Is this just PQM fallout?
<jam> and is there an RT for the breakage that I should be following?
<jam> vila: I'm planning on sending a mail to the list about some possible "next things" for me. Commit to stacked branch, Branch.open() round trips over hpss, etc.
<vila> jam: yup, pqm fallout
<vila> jam: yes, 41340, it has been closed while testtools was installed but I think it's the one to re-open
<vila> jam: commit to stacked branches would be nice, AIUI, some udd devs prefer checkouts
<vila> jam: and on lp that means stacked right ?
<jam> vila: well, it can mean stacked, yes
<jam> I think really what they want is shallow
<jam> which is something I poked at a while ago, which could really use a good hpss verb for it
<awilkins> I'm now getting "Connection closed: Unexpected end of message" when trying to use bzr+ssh ... sftp works for the same branch
<awilkins> The server logs the startup of the remote bzr instance...
<jam> awilkins: can you try running with -Dhpss ?
<awilkins> HPSS calls: 2 (1 vfs) SmartSSHClientMedium(bzr+ssh://None@cu013/)
<smoser> james_w, bug 676606
<ubot5> Launchpad bug 676606 in bzr-builddeb (Ubuntu) "import-upstream stack traces without upstream repository (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/676606
<exarkun> Why did this start happening?  http://buildbot.twistedmatrix.com/builders/hardy64-py2.5-select/builds/448/steps/bzr/logs/stdio
<jam> awilkins: there will be some information in ~/.bzr.log indicating what requests were done, etc.
<awilkins> And the full log : http://pastebin.ubuntu.com/533527/ ; nothing unordinary on the server I can see
<james_w> smoser, thanks
<james_w> smoser, did you try the fix?
<smoser> just getting there.
<jam> awilkins: so on the client side, it looks like we sent a request and got back no content in return
<jam> "buf[:10]=''"
<jam> means that there was no content in the reply
<awilkins> jam, this is through an ssh tunnel ; I have a shell open on the same connection which works fine, as does SFTP.
<awilkins> So there is a server though which tunnels are established to get access to the servers inside
<jam> awilkins: sure, is it ssh inside the tunnel as well?
<jam> or is it raw bzr:// ?
<jam> etc
<awilkins> jam, It's bzr+ssh:// through the same tunnel that the ssh shell connection is working through.
<jam> These lines are a bit surprising, too:
<jam> 0.152  ssh implementation is OpenSSH 0.974     result:   ('ReadError', 'home/awilkins/ace/.repo/workbench/trunk')
<smoser> james_w, fix seems to work.
<awilkins> jam, The version, or the lack of / on the front of the path?
<jam> (it actually looks like we got an earlier failure, and are trying to continue working, when we shouldn't)
<jam> awilkins: try this: "echo hello | ssh <that host over there> bzr serve --inet"
<jam> the full string we are sending is "bzr serve --inet --directory=/ --allow-writes" in case that matters (it shouldn't)
<jam> looks like "cu013" is <that host over there>
<awilkins> jam, this is an instance of bzr in my home folder on the server and is being accessed via setting BZR_REMOTE_PATH, not via the normal PATH
<jam> That *should" return "ok\x012\n"
<jam> awilkins: well, then try that first
<awilkins> jam, returns ok
<jam> awilkins: you are setting BZR_REMOTE_PATH and not via config, right?
<jam> another thing to check is that the remote bzr is executable, but you seem to have validated that with the "echo hello" check
<jam> you could try:
<awilkins> jam, setting it on the same command line - without, you get a command not found form the server
<jam> echo hello | ssh cu013 $BZR_REMOTE_PATH serve --inet
<jam> to make sure you have the remote path set correctly
<jam> awilkins: I think you might have a username set wrong:
<jam> [ 9024] 2010-11-17 17:27:21.522 INFO: HPSS calls: 2 (1 vfs) SmartSSHClientMedium(bzr+ssh://None@cu013/)
<jam> None@ ?
<jam> (we may just be displaying it when we shouldn't, because it is using the default)
<vila> jam: I see that almost everytime
<vila> jam: exactly
<awilkins> jam, That's just the parameter in the stack trace ; I've been using this config for ages though
<awilkins> jam, It works fine
<awilkins> (for ssh)
<awilkins> It previously worked fine for a similar server
<james_w> smoser, excellent, thanks for testing
<smoser> so, now for the general bzr education
<awilkins> But had to start using a different one in the same cluster (it's CentOS 5 in a collabnet cluster)
<smoser> i did the above, and imported upstream tarball
<smoser> and i can bzr diff -r tag:upstream-1.3.1
<smoser> but in bzr tags output i see:
<smoser> upstream-1.3.1       ?
<maxb> I believe that is expected, because whilst you have imported the revision, it is not (yet) in the ancestry of your current branch, so cannot be given a revno
<smoser> why is that? and what is the repercussion of it.
<smoser> hm.. so maybe import-upstream isnt what i want then?
<maxb> Well, at this point you are free to 'bzr merge -r upstream-1.3.1 .'
<awilkins> jam, I think I might just be being an idiot about how to set an env variable
<james_w> smoser, import-upstream is only a building block for whatever you want to do
<james_w> smoser, so maxb is right that a merge is one of the possible next steps
<smoser> yeah. ok. i think i'm set now.
<jam> awilkins: what shell are you using?
<smoser> maxb, regarding the watch file, it does seem its incorrect. it gets a -src-deps download. i'll fix that.
<jam> though if it is changing from "not found" to actually reporting something, that seems like progress
<jam> (export BZR_REMOTE_PATH=...) seems like it should work for "bash"s, "set BZR_REMOTE_PATH=..." I think is tcsh.
<awilkins> jam,  I'm using bash locally and on the sever
<jam> awilkins: fwiw it seems to be failing at the first RPC, so I'm not sure yet that bzr is able to start the remote bzr correctly.
<awilkins> was using  #  BZR_REMOTE_PATH="/home/awilkins/bin/bzr" bzr pull bzr+ssh://<url>
<awilkins> Without the first part it complains about not finding bzr, but produces the same error
<awilkins> With it, it doesn't
<awilkins> (complain about not finding the command)
<awilkins> I know it's running on the server because the logs are showing up the serve --inet --directory=/ commands
<awilkins> jam, Hmm, the serve attempts that respond to the "hello" command have a return code 0, the others have no return code.
<jam> awilkins: you pretty much have to have a return code...
<jam> ah, you mean on the server it doesn't show as returning?
<jam> that sounds like it might be segfaulting
<jam> how did you install the code there?
<jam> (did you compile extensions on a different platform, and then copy it?)
<awilkins> jam, Yes, but they are not logging it - gets as far as "bzr-svn: using Subversion 1.4.2 ()" then stops
<awilkins> jam, compiled in the same folder it's running in
<jam> awilkins: using "make" ?
<awilkins> jam, yes
<awilkins> jam, bzr 2.2.1 using the tarball and building from the included c files
<jam> awilkins: so one quick check, try going to the server, and using ~/bin/bzr log /home/awilkins/ace/.repo/workbench/trunk
<jam> in case that segfaults for some unknown reason
<jam> and how is ~/bin/bzr running in the same dir that it was compiled? (just a symlink?)
<awilkins> jam, that runs just fine ; ~bin/bzr is a symlink, but I've tried the direct path as well with the same results
<awilkins> jam, I'll get the server to run the selftests
<jam> and just to be sure "ssh cu013 bzr log /home/awilkins/ace/.repo" also works, right?
<jam> (well, add 'trunk' there)
<awilkins> jam, .repo is actually a standard folder, the subfolders of it are repos
<awilkins> jam, that works... it also works on the server (accidentally put the command there)
<vila> awilkins: I would try 'bzr selftest -s bp.svn' first since you mentioned it
<awilkins> vila, Gah, no testtools
<awilkins> As an aside, I hate CentOS
 * vila suggests >=0.9.6 :)
<awilkins> yum is especially pants
<vila> awilkins: no bzr packaged there ?
<awilkins> vila, Nope
<awilkins> vila, I dare not add too many repositories, because the last time I did it upgraded some component to be inbcompatible with the setup these servers have where they mount your home folder from a SAN somewhere
<vila> weird... I was sure I saw someone mentioning updating bzr for Red Hat with a simple command... where... where did I read that (a bug report ?)
<awilkins> Broken LDAP library or something
<vila> oh
 * awilkins tries yum install bzr
<awilkins> I broke it once like that and they rewarded me by taking away my ability to trash the server image... which seemed odd, because I was going to fix it by trashing the server image...
<awilkins> This is a CollabNet build farm, what do you expect, they are still in love with svn.
<awilkins> I hope it really annoys them that I use my home folder to mirror all the SVN repos in the project as Bazaar branches, but frankly they probably haven;t noticed.
<fullermd> Maybe if you checked that homedir into svn...
<txdv> svn is the best subversioning system, all more advancved once support it, so you can easily use git/bzr/hg insteand of svn
<awilkins> That's ironically "meta". Even more ironic given that the lead "programmer" on this project has actually written a versioned object database that actually stored it's repository (note- repository, not working copy) in an SVN working copy   >-o-<
<awilkins> That's a pinched agony face, by the way, not a goatse-ascii (accidental)
<fullermd> You get extra points if your svn->bzr conversion scripts automatically notice the new stuff in svn, and check out a bzr conversion of your homedir checkin in your homedir...
<awilkins> jam, It is a segfault
<jam> awilkins: well, at least I was right... now to figure out why
<awilkins> jam, Started another port tunnel for plain bzr:// and  ran a server on the remote shell
<awilkins> jam, It's something in bzr-svn
<jam> awilkins: do you need to have bzr-svn available?
<awilkins> jam, start it with --no-plugins and it works just fine
<jam> I guess you were saying everything is running in svn upstream
<awilkins> jam, I need it on the server shell but not when I'm pulling remotely
<awilkins> It's just a staging area to reduce my download bandwidth really - some of these branches are fricking huge
<brianjarita> hey guys... i did an apt-get update  with an apt-get upgrade on hardy and now I get "bzr: ERROR: exceptions.ImportError: ('Unable to load subvertpy extensions: %s', 'No module named client')"
<awilkins> So I can work around it by moving the plugin and putting a BZR_PLUGIN_PATH in the remote script for bzr
<brianjarita> it was fine before I did the update ... I"m running ubuntu 8.04 server
<brianjarita> any ideas on how to fix that?
<awilkins> brianjarita, were any of the components installed manually rather than via apt?
<brianjarita> nope
<brianjarita> i have bzr 2.1.1-1, bzr-svn 1.0.2-2 and bzrtools 2.1.0-1 installed
<vila> awilkins: or use BZR_DISABLE_PLUGINS, bzr help env-variables will tell you if it's available
<awilkins> vila, would that work for the remote server? Does SSH pass those env variables (or just a limited subset like LC)
<awilkins> brianjarita, (I keep wanting to type "brainjar"), those are not the most recent versions of those packages for Hardy in the bzr PPA (I know they're not from the default Hardy repo, because that's still at 1.13)
<brianjarita> i see  2.2.1-0~bazaar1~hardy1
<awilkins> brianjarita, Could you upgrade them to the newest versions in the PPA? (bzr-2.2.1-0~bazaar1~hardy1, bzr-svn-1.0.4-1~bazaar1~hardy1, bzrtools-2.2.0-2~bazaar1~hard1)
<brianjarita> root@dev:~/Source# dpkg --list|grep bzr
<brianjarita> ii  bzr                                   2.2.1-0~bazaar1~hardy1      easy to use distributed version control syst
<brianjarita> ii  bzr-svn                               1.0.4-1~bazaar1~hardy1      Bazaar plugin providing Subversion integrati
<brianjarita> ii  bzrtools                              2.2.0-2~bazaar1~hardy1      Collection of tools for bzr
<awilkins> brianjarita, So why do you have 2.1.1-1 above?
<brianjarita> sorry i was on the wrong terminal
<brianjarita> i was on lucid at 10:24AM
<brianjarita> that last post is hardy
<brianjarita> Linux dev 2.6.24-26-server #1 SMP Tue Dec 1 18:26:43 UTC 2009 x86_64 GNU/Linux
<awilkins> I presume you need bzr-svn :-)
<brianjarita> bzr    2.2.1-0~bazaar1~hardy1, bzr-svn   1.0.4-1~bazaar1~hardy1 and bzrtools 2.2.0-2~bazaar1~hardy1 are all installed
<knittl> 2a format has O(1) access time for text objects?
<jelmer> brianjarita: it looks like you have a broken python-subvertpy
<jam> awilkins: I imagine we only pass a limited subset of env vars, probably just the ones that ssh itself defaults to passing
<jelmer> awilkins: Did you figure out why bzr-svn was breaking your setup?
<jelmer> hey jam!
<jam> knittl: they are stored delta compressed, so not exactly O(1), and the index files are btrees, so looking up the location of the text is more O(log(n))...
<jam> hi jelmer
<brianjarita> python-subvertpy is 0.7.5-1~bazaar1~hardy1
<knittl> jam: is there a reference somewhere?
<jam> knittl: is there a specific question I can help answer?
<awilkins> jelmer, Alas, no, it's segfaulting with no stack trace, I've not got testtools installed yet 'coz I can't find a CentOS package name for it (grr)
<knittl> jam: still writing on my thesis :P
<knittl> and i have a line in it, that says Â»O(1) lookup time for any version of a file \todo{cite,verify}Â«
<knittl> so i came to verify
<jelmer> awilkins: what version of subvertpy?
<jam> IMO O(1) is pretty poorly defined. And usually  means you have to actually find the terms and determine that this part is a minimal part of the overall time, etc.
<awilkins> jelmer, 0.7.5, compiled from tarball. It pulls SVN branches just fine
<knittl> O(1) is generally constant and not depending on number of commits, number of branches, number of files, etc.
<awilkins> jelmer, I may have patched it slightly for that not-importing-pycompat thing
<jam> knittl: I would guess that we aren't strictly O(1). If I would guess, I would at least give it O(log(N)) of "stuff"
<jelmer> awilkins: what are you trying to do ?
<knittl> i need evidence to back that up
<knittl> there are no books on bzr, so bazaar internal documentation/format documentation is best i can get
<jam> knittl: inventories (mapping Revision id => tree => actual file content) is stored as a tree structure, so that is generally a log(N) lookup.
<knittl> what is N in O(log(N))?
<awilkins> jelmer, I'm pulling SVN branches to my home folder on this server (because the SVN repo is in the same server rack and thus it's fast there), then pulling those bzr branches via bzr+ssh:// to my local machine
<jam> knittl: Indices that map from a given text key (file_id, revision_id) to actual file content are btrees, which tends to be log100(N) lookup
<jelmer> awilkins: and pulling the bzr branches over bzr+ssh:// fails?
<knittl> what is N?
<jam> knittl: the raw text content is stored in a group of zlib.compress(lots_of_delta_content)
<jam> which is O(N_in_the_group) which is not strictly bounded, but significatly smaller than the N of all text content
<awilkins> jelmer, Or if you manually configure another tunnel and use plain bzr:// from a server started on the shell ; it segfaults, but not if you use --no-plugins. The only plugin outside the default is bzr-svn
<jam> inventory would be O(log(Num_files_in_the_tree))
<awilkins> jelmer, Ill just be extra thorough and try just disabling bzr-svn
<knittl> i'm still very disappointed by bzr's technical documentation :(
<jam> file_key => pack file is O(log100(Num_all_texts_stored_in_the_repository))
<jelmer> awilkins: I wonder why bzr-svn kicks in at all though
<jam> knittl: it isn't a VCS for Comp Sci majors ...
<jelmer> awilkins: the remote directory doesn't have .svn directories or anything like that?
<knittl> let's say i can ignore compression
<jam> jelmer: we're looking up a branch, that generally involves bzr-svn
<jam> knittl: zlib.decompress is going to be O(size_of_file_content)
<knittl> i said i _can_ ignore it ^^
<jam> and given everything I've stated, is likely to be the dominating factor
<jelmer> jam: but we check for .bzr before checking for .svn, and the .svn check happens using os.path.isdir().
<knittl> why btree and not a hashmap?
<awilkins> jelmer, The remote folder is a bare branch in a bare repository
<awilkins> Sorry, slipping into git-ism - --no-trees
<jam> awilkins: is it a shared repo?
<awilkins> jam, It is
<awilkins> jam, I will try one of the other repos
<awilkins> I have many here
<jam> awilkins: then is is "repo/.bzr repo/branch/.bzr/" which would mean we have to 'search"
<jam> knittl: our keys aren't hashes to start with (vs git)
<jam> and many operations look for "similar" data
<jam> like log going over revisions tends to look at user-2001a, user-2001b, etc
<jam> so you get locality by using a btree vs a hashmap
<jam> same for text content
<knittl> ok
<jam> diff looks for 2 texts of file-id1, rev1, rev2
<awilkins> repo layout is as at http://pastebin.ubuntu.com/533547/
<knittl> jam: so where is documentation that can back up everything you said?
<awilkins> I like this layout because you can do switch -b with ease
<jam> knittl: ultimate documentation is in the code :)
<knittl> i'm afraid IRC will not be allowed as citing source
<jam> look in doc/developers/*
<jam> and bzrlib/btree_index.py and bzrlib/groupcompress.py bzrlib/repofmt/groupcompress_repo.py
<jam> there should be some slightly technical docstrings
<jelmer> jam: but in awilkins situation we'd still not have to check for .svn as we'd find a .bzr controldir in every directory we browse, right?
<jelmer> awilkins: Can you perhaps run your bzr serve process in gdb ?
<knittl> jam: hm. ok
<awilkins> jelmer, I'll see if it's installed
<awilkins> Hooray, something that CentOS actually has
<jam> jelmer: I don't know that we would *have* to, but I'm pretty sure I've always seen bzr-svn get invoked
<jam> when it is present
<maxb> bzr-svn gets involved far too much. Just look at .bzr.log and see it crazily attempt to open the internals of bzrdirs as svn repositories
<knittl> btw, do i still need to sign contributors agreement for my branch? i still don't want to â¦
<jelmer> maxb: how do you mean?
<maxb> 0.480  Unable to open <bzrlib.transport.local.LocalTransport url=file:///home/maxb/wc/bzr/bzr/.bzr/repository/indices/2b60105ff8068389b09d6c735928fddd.six/> with Subversion: Unable to open an ra_local session to URL
<maxb> for example
<jelmer> maxb: that's when running 'bzr branches' ?
<maxb> repeat for every index and pack in the repo
<knittl> jam: i cannot find O(â¦ in the three files you named
<maxb> jelmer: hmm... multi-pull... which probably does exercise that code path
<jelmer> maxb: yep
<awilkins> how do you pass args to a program in gdb?
<jelmer> awilkins: gdb --args /usr/bin/python /usr/bin/bzr serve
 * awilkins is woefully spoiled by IDE attached debuggers
<jelmer> maxb: The probe code (and the branch find code) are in bzr, not bzr-svn.
<jelmer> maxb: we'd be trying to open those files with bzr, git and hg as well (provided you have those plugins installed), they're just a bit less verbose.
<knittl> Â»When referring to revision numbers it is necessary to mention a branch URL as wellÂ« â is that correct?
<maxb> Hmm. I think some rethinking is in order there, but it probably can't be made quicker without also being made less extensible
<awilkins> gdb stack trace at http://pastebin.ubuntu.com/533549/
<jelmer> maxb: It should be possible to make it faster, the new Prober API should make that a bit easier.
<awilkins> Why is it even throwing a SubversionException when serving a pure bzr branch ...
<jelmer> awilkins: can you print the full backtrace ("bt")
<fullermd> knittl: Well, maybe not a URL per se, but a branch one way or another, yes.
<awilkins> jelmer, http://pastebin.ubuntu.com/533550/
<jelmer> awilkins: is the branch tied to a http repository or something like that?
<awilkins> jelmer, the parent branch is an SVN repo over https://
<knittl> fullermd: URL can also be a path
<jelmer> awilkins: can you to frame 3 and print ret->url ?
<awilkins> jelmer, I have a thought - one thing is that these repos don't work with just "https://" you have to use "svn+https://" because they don't like being probed (return 401 errors and the like)
<awilkins> jelmer, it says "no symbol ret in current context"
<brianjarita> you guys were right ..... python-subvertpy is broken in hardy .... i compiled it from source and everything works now
<brianjarita> thanks
<jelmer> awilkins: argh, darn optimizations
<jelmer> brianjarita: are you using the bzr ppa perhaps, or is this "plain" hardy?
<brianjarita> plain hardy
<brianjarita> hardy server 8.04 lts
<brianjarita> right from the live cd from ubuntu
<awilkins> jelmer, he must be using the ppa because he's not on bzr-1.13, he's on 2.2
<brianjarita> yea i'm on 2.2
<brianjarita> my repos are the regular ones
<brianjarita> I didn't add anything to /etc/apt/sources.list
<brianjarita> oh haha ... another IT guy did
<brianjarita> i see     deb http://ppa.launchpad.net/bzr/ppa/ubuntu hardy main
<brianjarita> so yea I'm on ppa
<awilkins> jelmer, How about printing the url from the kwargs, is that hard?
<jelmer> awilkins: should be possible
<jelmer> awilkins: "print PyString_AsString(PyObject_Repr(kwargs))" I think
<jelmer> awilkins: I have to run in a few minutes though
<awilkins> I was trying kwargs[0]-> nut not sure which member to try
<jelmer> awilkins: any luck using "print PyString_AsString(PyObject_Repr(kwargs))" ?
<awilkins> jelmer, nope
<awilkins> $2 = 147905652
<awilkins> jelmer, More coherent results from print kwargs[n], but you just get the refcount and object type
<awilkins> As an integer
<awilkins> jelmer, print (char*) PyString_AsString(PyObject_Repr(kwargs)) seems to work a bit better.. but it;s truncated with an ellipsis
<awilkins> jelmer, the url is 'file://'
<jam> losa ping: Last I heard, bzr's PQM was still broken because of needing the new subunit to be installed. I don't know if that has been addressed or not. vila and mthaddon were working on it, but both are past their EOD
<joey> howdy,
<joey> anyone know how to work around this?
<joey> bzr: ERROR: No such file: u'/home/joey/canonical-docs/.bzr/repository/pack-names': [Errno 2] No such file or directory: u'/home/joey/canonical-docs/.bzr/repository/pack-names'
<joey> I went do to a commit and got that error
<beuno> ouch
<poolie> hi joey, beuno, jam
<poolie> joey: what happened?
<beuno> heya poolie!
<joey> hi poolie!
<joey> bzr: ERROR: No such file: u'/home/joey/canonical-docs/.bzr/repository/pack-names': [Errno 2] No such file or directory: u'/home/joey/canonical-docs/.bzr/repository/pack-names'
<poolie> that's unusual
<joey> I hadn't used that branch in a while and went to do a commit ....
<poolie> did your machine crash recently?
<poolie> ah, or maybe not recently
<joey> status, check, pull, update ...all get the same error
<jam> morning poolie
<poolie> yeah, i'm not surprised
<joey> yeah it has crashed but not in the middle of an update
<poolie> that's a pretty fundamental file to lose
 * joey looks in lost.files
<poolie> jam, thanks for your mail
<joey> lost+found is empty
<joey> I suppose I can just suck down the branch from LP and do a diff
<poolie> so can you file a bug, and then
<poolie> it should not be too hard to recreate the file, but i don't know if there's any command line way
<poolie> bug titled 'pack-names file is missing'
<joey> well I have no idea how it would have happened
<poolie> it's ok
<joey> no idea on how to reproduce it
<poolie> we should still have a way to recover from it
<poolie> 'rm pack-names' will reproduce it adequately :)
<joey> oh hell
<joey> you are NOT going to believe this
<poolie> however, it's probably only about low priority, since if your machine is going to lose files, there's a limit what we can do
<joey> pack-names.u1conflict
<joey> I must have forgotten it was under RCS
<beuno> u1conflict
<beuno> ouch
<joey> the reason I don't use U1 :-)
<beuno> so that was ubuntu one's fault
<beuno> hehe
<joey> I've invited Matt G and few others to my house to help them fix it :-)
<beuno> I have Matt G trapped in my place all week
<jam> beuno, joey: AIUI u1 is not transaction safe wrt what bzr does
<beuno> plus rockstar and others
<jam> we write things in a certain order, but U1 doesn't know that
<joey> ok so renaming that file worked!
<joey> thanks O masters of all things bzr bizarre
<beuno> jam, I thought they had fixed that, bzr was one of the testcases
<jam> so you can get repo level corruption if u1 decides to merge things
<jam> beuno: if I commit here, and you commit there, we end up with 2 different pack files added to pack-names
<jam> which would then conflict (I assume)
<jam> and you need to merge those lines together.
<beuno> ah
<beuno> right
<joey> jam: wc but any idea on how to tell u1 to stop synchronizing?  When I issue it from the gui it just fails silently
<jam> not to mention that you could sync pack-names before you upload the associated .pack files, etc.
<jam> joey: beuno is the one to ask about that
<beuno> joey, so, where is this located on your filesystem?
<jam> beuno: In an eventually-consistent state with a single committer, u1 will probably work
<jam> (for example, you can rsync a live repository, as long as you eventually get a complete snapshot)
<beuno> joey, go to:  https://edge.one.ubuntu.com/files/
<beuno> "stop syncing folder" under the more option
<joey> beuno: that worked. Many thanks.
<beuno> joey, np. I fixed that yesterday  :)
<beuno> sprinting FTW
<poolie> jam, thanks for your mail about lp-serve
<poolie> also i spoke to spiv and he's very keen to work with you on hpss, and he's going to try to wake earlier to overlap more with you
<jam> poolie: francis had a decent response to it
<poolie> jam btw if you're still online, you might want to join #ubuntu-meeting
<spiv> jam: good morning, btw!
<jam> morning sp
<jam> spiv
<spiv> joey: also, perhaps check if there's a pack-names.old file or something in .bzr/repository somewhere.
<spiv> joey: oh, I see you found a file to rename :)
<poolie> spiv, can you join #ubuntu-meeting too?
<jam> spiv: there was a question about https://bugs.launchpad.net/udd/+bug/653307
<ubot5> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 6)" [Critical,In progress]
<peitschie> mornin all :)
<spiv> james_w: see my latest comment on 653307
<james_w> spiv, replied, thanks
#bzr 2010-11-18
<seiflotfy> hey gus
<seiflotfy> guys
<seiflotfy> :)
<seiflotfy> I have been thinking of a way to maybe enhance launchpad experience
<seiflotfy> Using Zeitgeist as a backend in Launchpad will allow users to have a personal timeline of their activities regarding themselves or specific project. This will allow easier trackeing of when things were done commited and view a chronicle of the project in terms of all (blueprints/bugs/etc..) mashed together.
<seiflotfy> Basically what we can provide is a timeline per project/team/individual
<seiflotfy> I think I can get it done
<seiflotfy> imagine a persoal journal for each developer
<seiflotfy> poolie, ?
<seiflotfy> sorry
<seiflotfy> back
<seiflotfy> poolie, did i miss something or is it still silent in here
<poolie> sorry, phone
<poolie> i think it would be a superb idea
<poolie> the big question istm is how, technically, we will get activity data from lp into zeitgeist
<seiflotfy> well it has to be hooked into launchpad
<seiflotfy> :)
<seiflotfy> basically if anything happens on launchpad it has to be forwarded to the zeitgeist running on the server
<seiflotfy> so its basically hooking up into launchpad and listneing ot activities
<poolie> right, that's the key thing
<poolie> actually, i should really have sent you to #launchpad-dev, not here :)
<poolie> do you mind?
<seiflotfy> nope
<seiflotfy> not at all
<_habnabit> So I'm getting an odd error when checking out a bzr branch, but only on windows.
<_habnabit> bzr 2.2.1, I get an error about 'checkout/limbo/new-3' already existing every time.
<_habnabit> Across three different machines.
<_habnabit> Pulling over ssh from a UNIX machine, if that matters.
<_habnabit> I can pastebin the exact error.
<poolie> _habnabit: hm, please search for an existing bug, or file a new one?
<_habnabit> poolie, whoops, I forgot to mention I resolved it.
<poolie> oh, what was it?
<_habnabit> Windows was choking on the filename '. '
<_habnabit> svn did it too, back when we used svn. That's how I recognized the problem!
<vila> hi all
<peitschie> evenin vila :)
<vila> peitschie: ;)
<poolie> hi vila; now i have to run
<poolie> vila, are you on the udd list? you should be
<vila> poolie: hello, bye, any news about pqm ?
<poolie> what about it?
<vila> I think so
<vila> I just upgraded and had to reboot, will look at my mail backlog now, any topic in particular ?
<poolie> you'll see it :) i just sent a bit mail
<poolie> is something wrong with pqm?
<vila> the upgrade to testtools-0.9.6 went wrong leading to no subunit
<vila> i.e. no more landing
<vila> jam was trying to follow yesterday when I EODed, I was just wondering if you heard about it
<poolie> i hadn't even heard that
<poolie> tell the list? chase a losa
<poolie> i haven't tried to land anything today
<poolie> more's the pity
<vila> oh, it's under losa's control, re-building the needed bits was taking a long time and mthaddon also EODed before it was done, so I don't know where it's at but I will ;)
<poolie> k, please send a mail letting us know one way or the other
<vila> k
<vila> poolie: so, yes, I'm subscribed to udd, got your 'udd at uds-n' yesterday
<vila> poolie: and I'm a big fan of the UDD stakeholders meeting minutes for a while ;)
<GaryvdM> Morning all.
<GaryvdM> Bla - I missed poolie.
 * jelmer waves to Gary
<GaryvdM> Hi jelmer
<vila> GaryvdM: hey !
 * jelmer hugs GaryvdM
<GaryvdM> :-)
 * GaryvdM is not sure why
<jelmer> GaryvdM: I noticed your last MP when I was reading my email.
<GaryvdM> Ah :-)
<vila> +1
<vila> GaryvdM: I saw your loggerhead poc the day *after* you mentioned it and was never able to congratulate. Now is the time: very well done ;)
<GaryvdM> vila: thanks
<vila> maxb: ping
<vila> maxb: we are upgrading testtools/subunit on pqm for bzr
<vila> maxb: we used the packages from the stable bzr PPA
<vila> maxb: it turned out that we also needed  python-central-debhelper-sequence-addon provided by the https://launchpad.net/~bzr/+archive/builddeps PPA
<vila> maxb:  so far, so good, except that subunit-stats is nowhere to be found now, does this ring a bell ?
<soren> Is there a way I can trick two branches into having a common ancestry?
<soren> Use case:
<soren> I have a project which has a number of series, each with their own branch.
<soren> I want to put my packaging code (which should apply cleanly to any of these branches) in a separate branch which has nothing but the packaging (contained in a debian/ directory).
<soren> Just creating a new repo doesn't work, because it'll complain about lack of common ancestry.
<maxb> vila: Hello
<soren> I thought I was being clever, and tried "bzr branch -r 0 <one of the upstream branches> packaging" hoping that would give me a branch with a common ancestor (namely some sort of fictional 0th commit)
<maxb> vila: You should only need python-central-debhelper-sequence-addon to build the package, and only on hardy.
<maxb> Is the bzr PQM machine still lagging behind? I thought most of the datacentre wa on lucid now
<vila> maxb: seems like it was required to install subunit :-<
<maxb> wtf?!
<vila> +1
 * maxb fires up a quick cowbuilder chroot
<vila> maxb: we need python-2.4 there to ensure compatibility, it's gone in lucid AFAIK
<maxb> vila: meh. ok
<maxb> vila: I'm still confused, I just ran 'apt-get install python-testtools subunit' in a hardy chroot, WITHOUT bzr/builddeps, and it installed fine
<maxb> Or, it is because the l o s a s want to rebuild the packages in their own archive?
<vila> maxb: exactly
<maxb> Ah, well that's entirely different then.
<maxb> I wish they could be a little more trusting. It's not like PPAs aren't a secured build environment already
<vila> +1 :-}
<vila> well, I can understand them too :-/
<vila> maxb: well, when I said exactly I may not have been correct, I don't really know if they copy the packages or if they rebuild them
<vila> maxb: python-central-debhelper-sequence-addon is from you right ? Can you refresh my memory ? It's a workaround about python-central or ?
<maxb> It's a backport of a single file that was added to python-central after hardy
<vila> ok
<maxb> in fact
<maxb> python-central-debhelper-sequence-addon (0.6.8~bazaar1~hardy1) hardy; urgency=low
<maxb>   * This package takes the python-central debhelper sequence file from
<maxb>     python-central 0.6.8 and repackages it for installation on hardy, whose
<maxb>     python-central ships no debhelper sequence file.
<maxb>  -- Max Bowsher <maxb@f2s.com>   Wed, 01 Sep 2010 02:05:46 +0100
<vila> hence the value of commit messages :)
<vila> or changelogs
<maxb> I mainly did it that way because it seemed nicer than rebuilding a core infrastructural package like python-central just to provide an additional file
<vila> maxb: which sounds perfectly reasonable
<vila> maxb: what I don't understand is why (and where) we lost subunit-stats
<maxb> What is subunit-stats? A binary package that is supposed to be there but is not?
<vila> maxb: when upgrading subunit
<vila> it's a script provided by subunit
<maxb> uh, it exists in *my* package
 * vila cries
<maxb> vila: Do you have (read-only) shell access to the PQM machine?
<vila> maxb: can I ping you back once my losa is back (he said biab less than an hour ago)
<GaryvdM> soren : You can do bzr merge -r 0.. ../packing_branch
<vila> maxb: mwhahahahahahaha
<vila> maxb: does this answer the question ? >-/
<soren> GaryvdM: Yeah, but that's terrible.
<maxb> Not entirely :-)
<GaryvdM> soren: Or use bzr join
<soren> GaryvdM: I have to tell everyone else to do that, not all tools support it (bzr-builder, for one doesn't).
<GaryvdM> soren: Why?
<vila> maxb: my access to pqm is: send submissions, see new revisions on bzr branches when all goes well, see no email when something fail because my ISP, most of the times, consider pqm email as spam
<GaryvdM> Ok - Sorry, I'm not familiar with bzr-builder.
<vila> maxb: oh, and http://pqm.bazaar-vcs.org/ of course
<maxb> Hrm. If there's one thing I think Canonical does poorly, it's this iron curtain between developers and admins
<soren> GaryvdM: Mostly it's because I shouldn't have to.
<fullermd> Well, somebody has to keep vila in his place...
<maxb> Sometimes it just has to be, like where LP is storing proprietary data, but on the bzr PQM machine !?
<vila> well, as long as things works well, they are doing a great job, pqm is the only exception this far
<soren> GaryvdM: Most people want to do this because they want to avoid conflicts between identical files.
<vila> maxb: if I was an admin I would be quite worried to let devs play around with production servers too :)
<soren> GaryvdM: I understand why that happens, and I'm fine with that. I just want to be able to merge two trees that have no files in common.
<vila> maxb: may be the problem here is that we shouldn't use a production server for pqm....
<maxb> vila: I love working in a small (division of a) company. I'm a dev, but I have root@ the production servers for my app
<soren> GaryvdM: ..and I'm actually lucky enough that I get to start one of these from scratch, so I thought I could create the common ancestry this way.
<vila> maxb: who is the official root then ?
<fullermd> Yeah.  It's nice being the dev AND the admin.  I'd go nuts trying to work any other way...
<vila> maxb: as in: who is blamed when things go horribly wrong ?
<vila> fullermd: I am slowly going nuts on this problem :(
<vila> I see fingers all around...
<fullermd> Sounds like a waste of time.  Why not go nuts quickly?  Then you have more time to enjoy it.
<maxb> vila: Whoever broke it :-)
<vila> maxb: Ha ! Easy, if you already know *who* :D
<vila> fullermd: hehe, thanks, feeling better already :D
<fullermd> That's easy to find out.  Just take everyone with root, and lock them in a room with a couple bricks.  Whoever makes it out under their own power is innocent.
<vila> fullermd: yeah, all in the same room, quite tricky in a distributed company :-P
<fullermd> That just means they need bigger bricks   :p
<soren> Does bzr's data model simply not support this or is it just not possible with the current UI?
<vila> soren: #ubuntu-devel should get you better answers, they do that routinely AIUI
<vila> soren: you *can* merge your packaging branch into all your series branches and from there merge the changes in the packaging branches
<vila> but you can't keep them separate and still ask them to have a common ancestry
<maxb> soren: Why do you need a common ancestry at all?
<soren> vila: it's just silly that if I had known from the start that I wanted to do this, I could have created an emtpy revision as my r1, and branch from that.
<soren> maxb: In short: To be able to merge them without having to specify a base revision.
<soren> maxb: I explained the use case 40 minutes ago in this channel.
<maxb> Why do you need to do that? (bzr-builder now supports nest-part for embedding a debian directory)
<soren> maxb: For a couple of reasons, it's more convenient to have the debian/ directory in the bzr repo (and not just the contents of it).
<maxb> Agreed. nest-part was created to allow that layout
<soren> maxb: Er?
 * soren looks at code
<maxb> nest-part allows you to instruct bzr-builder to take the debian directory from your branch and place it into the upstream branch, without it ending up at debian/debian/
<soren> maxb: Oh, cool.
<soren> maxb: That solves the recipe problem, at least.
<soren> maxb: It's just annoying that I have to tell people to do special things to merge this stuff.
<soren> maxb: Especially since a lot of these people are git fanatics, and they get all excited and annoying when these quirks come up.
 * maxb attempts to think how this would work in git
 * maxb fails
<soren> I don't know. I don't really care. :)
<Tak> blargh, I don't know what it is about git that fanaticizes people
<soren> But it's so fast!!!!1!!!!eleven!!!
<mthaddon> vila: howdy - so what do we need to discuss?
<vila> mthaddon: hehe, where did subunit-stats go ?
<mthaddon> vila: how can I help answer that?
<vila> mthaddon: it's part of subunit and that;s what you installed right ? maxb built it and found subunit-stats in his hardy chroot
<mthaddon> maxb: in which file?
<maxb> mthaddon: In the 'subunit' binary package
<maxb> Could you check 'dpkg -L subunit' ?
<mthaddon> maxb: we have python-subunit installed, not subunit
<maxb> Ah. You should also have subunit installed, to provide the command line entry points
<mthaddon> hookay...
 * mthaddon suggests there really should be a bzr-pqm-dependencies package, but feels like he's suggested that before
<mthaddon> and presumably we'll need the version of subunit from the same PPA?
<vila> mthaddon: that's where it's get interesting since the stable bzr PPA provides subunit not python-subunit, so where did you get the later ?
<mthaddon> hmm, interesting - in any case, have subunit ready to install now, one sec
<vila> mthaddon: +1 on bzr-pqm-dependencies package, but isn't it already covered by the PPAs ?
<mthaddon> vila: er, how?
<vila> they provides all the needed packages no ?
<mthaddon> vila: a dependencies package defines all the specific packages and versions - we don't install directly from PPAs
<mthaddon> vila: subunit has now been installed
<vila> mthaddon: how did you use the PPA there ?
<mthaddon> vila: I'm not sure I understand the question
<vila> :)
<vila> You asked me for PPAs but then you say you don't install from them, then what bit do you use ?
<vila> mthaddon: submission set
<vila> sent
<mthaddon> vila: we backport from the PPA, we don't install directly from them, so having packages in a PPA is only part of the puzzle
<vila> what means backport here ?
<vila> You install and repackage ?
<mthaddon> vila: having a dependencies package means you can define exactly which packages need to be installed and what versions, and we know as long as we satisfy that everything will work rather than having to ask about each individual package
<mthaddon> we download the source package from the PPA, verify it, build it and upload it to the admin repos
<vila> ha right, stupid, you can get the source from the ppa
<vila> so if we had this package we can just update it and ask you to update
<mthaddon> yep
<vila> shudder
<vila> it's kind of chicken -and-egg problem, *I* don't know precisely what is used *today* on pqm
<vila> but probably enough to give it a try
<vila> except I have no idea how to write such a package :D
<vila> echo Depends: bzr, subunit, python-testtools > sudo make-me-a-package
<mthaddon> the way to determine if it's correct would be to create a clean install, install the dependencies package, run the test suite, and see what it needs
<mthaddon> should be fairly easy to do
<mthaddon> and we have a ton of dependencies packages that we maintain for other projects, so if you need an example that's easy enough to provide
<vila> mthaddon: deal, you've got my email ?
<vila> mthaddon: I'm sure I won't be able to build a perfect pqm clone but I should be able to mimick the real one close enough (minus email handling, chroot, web report and so on ;)
<mthaddon> vila: you don't need to do a pqm clone at all - just a chroot to run the test suite
<mthaddon> vila: or a vm or whatever
<vila> mthaddon: my crystal ball knows less than you (and I trust you) so it's reporting grey areas, so I will *assume* that running the test suite will be enough but I already have an hardy VM and by *default* python-2.5 is used not python-2.4, such details are so easily missed...
<mthaddon> vila: see https://edge.launchpad.net/~launchpad/+archive/ppa - launchpad-dependencies for an example
<vila> perfect
<mthaddon> vila: you'd need to run the same command we run for PQM - "LANG=en_GB.utf8 make check PYTHON=python2.4"
<vila> en_GB.utf8 ! Of course !
<mgz> ooh, vila has won in the battle against pqm?
<mgz> should I merge up my branches?
<vila> mgz: no, and first you should mthaddon :D
<vila> mgz: I have a test submission running, please don't fill up the queue (yet) :F
<mgz> +thank? +eat? +marry?
<vila> :D
<vila> marry
<vila> err no, thank
<vila> stupid random mouse events doing copy paste now ? What next ?
<mgz> a giant lwn thread!
<fullermd> Iguana invasion?
<GaryvdM> Hi jam
<jam> morning GaryvdM
<GaryvdM> I want to talk to you about bug 153787
<ubot5> Launchpad bug 153787 in Bazaar "annotation is slow in 2a and pack repositories (affected: 0, heat: 3)" [High,Confirmed] https://launchpad.net/bugs/153787
<jam> k
<GaryvdM> I think it would be better to for me to work on a iterative gui annotate.
<GaryvdM> So I guess I'm going to need to add api to the Annotator classes.
<GaryvdM> And plumbing api to the tree objects
<jam> I think that is the route I would go
<jam> note that it turns a lot of the guts of Annotator on its head
<jam> so its a non-trivial change
<jam> I would actually expect in the short-term for annotation to get quite a bit slower, though the tradeoff is that you'll get initial results faster
<jam> command-line annotate would get slower, though
<GaryvdM> Oh - ok. I've read some of the code, but not enough to understand why.
<GaryvdM> I hope that is not the case.
<jam> annotation currently is based around start at the original, and build up to the current
<jam> and it knows when you can release what texts, etc
<jam> based on whether anything needs that in the future
<jam> (simple refcounting, really)
<GaryvdM> Ok - usefull to know
<jam> lots of other differences...
<jam> for example, if you annotate in reverse, can you then save an intermediate step?
<jam> or will reverse annotating break caching?
<jam> will the api depend on incremental updates, what happens if you have a cache and can answer the whole thing right away?
<jam> (just make sure that sending more information than a single step is reasonable, and it should be fine)
<GaryvdM> Ok
<jam> annotating forward, you 'save' each step along the way before you're ready to do the next step
<jam> annotating in reverse, I think you would only tend to save "this is what I know about so far"
<jam> has some benefits
<jam> potentially, you could change the diff matching code to know to not care about certain regions because they "already match"
<jam> but that would be a pretty major change, too
<GaryvdM> Ok.
<GaryvdM> Thanks - Lots of usefull info to think about.
<jam> I think the first thing is to just design an api that can talk about it the way you want
<jam> and then to validate an actual step-by-step produce this
<jam> without worrying about too much caching, etc
<jam> and then see what you get
<GaryvdM> Ok
<jam> also, we may need a new "get_record_stream" verb
<jam> we currently have "topological"
<jam> but this will want "reverse_topological"
<jam> which is *close* to "groupcompress" order, and maybe a good enough approximation, as long as your code could handle things not 100% in order
<GaryvdM> jam: Where would that need to be implemented? VersionFile implementations?
<GaryvdM> reverse_topological ^
<jam> GaryvdM: something like that, yes.
<jam> As mentioned, punt for now, though
<jam> especially since "groupcompress" order is close enough
<GaryvdM> jam: did you start on caching code?
<jam> GaryvdM: I was working on refactoring PackCollection to make it easier to define an arbitrary cache
<jam> but that hasn't fully panned out
<GaryvdM> Ok
<GaryvdM> jam: Thanks for all the info. Let me now try digest all of it :-)
<GaryvdM> And the code.
<jam> vila: your code has landed! Does that mean pqm is working again/
<jam> ?
<hrw> hi
<vila> jam: yeah ! Yes. Hi :)
<GaryvdM> jam: Thanks for the merge review.
<vila> jam: I just followed up on ML, you're too fast :D
<hrw> http://hrw.pastebin.com/erWV8eRM is what I got with bzr-fastexport - any ideas what is wrong?
<GaryvdM> hrw: My initial *guess* is that you maybe have a old version of python-fastimport.
<hrw> GaryvdM: python-fastimport 0.9.0~bzr293-1, bzr-fastimport 0.9.0+bzr279-1
<hrw> GaryvdM: natty packages
<GaryvdM> Ok
<hrw> bzr 2.3.0-beta2
<hrw> GaryvdM: I do not know - maybe they should match
<hrw> hi zyga
<zyga> hrw, hi
<zyga> hrw, ask :)
<GaryvdM> hrw: The bzr rev numbers? I dough it.
<hrw> zyga: if you want... http://hrw.pastebin.com/erWV8eRM is what I got with bzr-fastexport - any ideas what is wrong?
<GaryvdM> *doubt
<zyga> hrw, from the top of my head, either bzr or git/python wrapper version mismatch
<hrw> GaryvdM: I think I found. need to check a bit more first
<hrw> rev279 moved lot of code to python-fastimport from bzr-fastimport
<GaryvdM> hrw: I think you may have manually installed a version to /usr/lib/python2.6/dist-packages/bzrlib/plugins/
 * zyga has ath9k issues again :
<GaryvdM> The file that the error occurs in no longer exists (bzr_exporter.py)
<hrw> GaryvdM: http://hrw.pastebin.com/scwJcFU1
<GaryvdM> Sorry - That's is where apt-get put it
<hrw> I am not too familiar with python-support/central and how they handle
<GaryvdM> Yes - Sorry - I was way off
<zyga>  hrw python-support does some things but essentially puts the source in /usr/share/pyshared and byte-compiled version in some other place, per installed and compatible interpreter
<hrw> fixed
<GaryvdM> hrw: It seems like it is fixed in rev 282 of bzr-fastimport.
<GaryvdM> hrw: how?
<hrw> GaryvdM: r282 fixed problem indeed but one more left
<hrw> ah. second is fixed in r384
<hrw> 284
<hrw> GaryvdM: from fastimport import helpers as helpers2
<hrw> and then s/helpers.binary_stream/helpers2.binary_stream
<hrw> and same with helpers.single_plural
<hrw> ok, tomorrow will check bzr fast-import
<hrw> fixes from r282/284 allowed me to do "git bzr clone" - "git bzr push" fails in other way
<hrw> have a nice rest of day
<GaryvdM> Bla - bzr-pipeline,  locations.conf with appendpath policies, and bzr-pqm don't play nicely.
<GaryvdM> Hmm - Not sure why, but my bzr-pqm sends duplicate mails.
<vila> GaryvdM: yeah, just notice that, you were so missing pqm that you had to double submit ? :D
<fullermd> Oh no, vila's talking to nobody again.  Get the straitjacket...
<vila> damn, missed the bear
<vila> nooooo, not a typo for beer
<mgz> rawr.
<jam> GaryvdM: I did a basic review of your loggraphviz branch. Please ignore  the first email, it was sent before I finished the writeup.
<GaryvdM> jam: ok - Thanks
<jam> also, you don't have to take things I've said as "gospel".
<jam> Its meant to be some feedback on how you have things structured, but I'd like it to be more of a conversation.
<poolie> hi jam
<jam> hi poolie
<jam> didn't expect to see you on Sat
<jam> wait, still Fri for you, right?
<poolie> yes, it is
<poolie> pretty sure
<poolie> how are things with you?
<jam> poolie: pretty good. Still a bit unhappy with the lp-serve stuff
<jam> I can't reproduce production locally to make sure I get everything working right
<jam> but tom works on it at 3am my time
<jam> so it is 1 incremental change every 24 hrs
<poolie> yuk
<jam> but, at least it is something
<poolie> why can't we assign someone in your tz?
<poolie> actually shall we take this to lp-dev?
<jam> sure
<jam> -dev or -ops
<poolie> vila: still up?
<GaryvdM> Hi poolie
<peitschie> mornin all
<GaryvdM> Hi peitschie
<peitschie> hi GaryvdM :)
<poolie> hi GaryvdM, peitschie
<peitschie> hi poolie :)
<szim90> Hi. I've been deciding between version control systems (I'm a solo developer that has gotten sick of saving things as rev1,rev2, etc). I've been reading up on the options, and I've narrowed it down to git and bzr. I wanted to ask, are the advantages mentioned on "Why Switch to Bazaar" still valid if I'm comparing a stand alone bzr install to a stand alone git install (speed and efficiency, etc)? Also, does bazaar have anything like svn's missing
<dash> szim90: anything like svn's what?
<maxb> For a solo developer, the choice between git and bzr will mainly rest on which philsophy and UI you prefer
<szim90> dash: svn's obliterate feature (it's something they say they have been working on for ever - it enable you to undo a commit completely, so if you accidentally included proprietary information, or (in my case), a 120mb binary, you can remove it without taking down the entire database and filtering manually).
<exarkun> If you're like most normal human beings, you'll probably prefer bzr's UI though, at least while you're climbing the learning curve.
<exarkun> (but gosh git is fast)
<szim90> maxb: I suppose I can test the UIs, but how would you describe the differences in philosophy.
<maxb> Well, one interesting point is that Bazaar tracks the identity of files - so if you rename/move one, it stores that directly.
<dash> szim90: right, bzr doesn't have that either
<maxb> Whereas git tracks content, and guesses file moves based on seeing blocks of content move from one file to another
<dash> szim90: like exarkun, i think git's user interface is more than a little confusing. :)
<maxb> Me three.
<szim90> Well, since it's more for personal use, less confusing is definitely good! Regarding files, though, I remember reading that git trees are stored as data in .git and as data themselves (so when you clone, you then have to check out your own database to regen files). Does bzr work like this, or is it more like svn where files act like real files?
<maxb> szim90: Erm, I'm afraid I understand git and svn and bzr really quite well, but I really don't understand your question.
<szim90> Fair enough, I really could have worded that better. What I meant was, I was told that if I wanted to copy a git tree (like a local directory with project data), the copy action wouldn't copy files, just the database. So I would have to checkout files after making a copy.
<maxb> That depends on what you mean by 'copy'
<maxb> Obviously if you copy a git or bzr tree with OS tools, you end up with the same files in the destination as the source.
<maxb> It's possible what was meant was that if you push a git or bzr tree over the git or bzr wire protocols, that does not create a working tree on the server
<szim90> yes. That's what I wanted to check. My concern is that if I transfer a bzr tree to another server over ssh (something I read bzr was capable of doing), and the other system did not have bzr, then I would be stuck without a working tree on the server unless I transfered the files manually.
<maxb> well, yes?
<dash> szim90: sure. for that you want to use tar or rsync or something
<dash> there's an 'rspush' bzr plugin that will do that.
<mwhudson> or bzr upload, for a different kind of use case
<dash> that one i haven't seen
<szim90> Perfect! Thanks. I just need to make sure the work is accessible in the event I end up on a work station that isn't mine. I believe that answers all my questions. Thanks you for all of your help; I'll try bzr out when I get back to my system.
#bzr 2010-11-19
<poolie> hi maxb
<maxb> hello
<KombuchaKip> I just ran bzr sign-my-commits in my local working copy. I was prompted to sign previous unsigned revisions and did so. Now when I run bzr status, I don't see anything changed or new to commit to the repository. How do I commit the signed aspect of the revisions?
<fullermd> You don't.  Signatures aren't committed things.
<KombuchaKip> fullermd: Then how can others verify that someone else's commit is genuine?
<fullermd> EBADCOMMUNICATION.  By making a signature, it's in the repo.  Signatures aren't something you commit, they're their own thing that making puts in the VCS storage, like tags.
<KombuchaKip> fullermd: So if you don't commit them, how are they sent to the repository so others can verify the revision's authenticity?
<fullermd> Same way the commits are; they get pushed/pulled around.
<KombuchaKip> fullermd: I am using centralized model. How do I send my signature?
<fullermd> Dunno.  In a Proper World(tm), making the signature automatically would propagate it upstream when you're using a checkout.
 * KombuchaKip is very confused
<fullermd> In the current mishmash, I'm not sure.  Maybe it goes as a side effect next time you commit something.
<KombuchaKip> fullermd: It should really show something in status, at least a separate category for tags / metadata that changed.
<fullermd> That's not what status does though.  Status talks about changes between revisions.
<fullermd> Signatures (and tags, for that matter) aren't part of revisions.  They're a separate dimension.
<KombuchaKip> fullermd: So then there should be a status for repository, in addition to one for revisions.
<fullermd> Well, the bugs that cause it to be needed in this case should be fixed   :)
<KombuchaKip> fullermd: When I click on the "signature" button in the nautilus bzr GUI, it just locks up every time.
<fullermd> I'd guess that's something to do with it trying to read a passphrase from the terminal.
<KombuchaKip> fullermd: Dunno. Not a very good design. seahorse-daemon just sits there spinning the clock.
<fullermd> Hey, don't look at me.  I've never even seen the nautilus bzr GUI.  Or nautilus, for that matter   :)
 * KombuchaKip visualized fullermd with a Lemote, virtual console, and X uninstalled.
<fullermd> Ehhwut?  Sorry, I couldn't hear you over the clattering of my teletype.
<KombuchaKip> fullermd: lol
<poolie> thanks for all the patches, gary
<mwhudson> what's the incantation to force bzrlib to use openssh as its ssh transport?
<mwhudson> i thought it was BZR_SSH=openssh
<fullermd> Accords with the docs...
<mwhudson> i guess https://bugs.launchpad.net/bzr/+bug/677305 isn't going to make spiv feel any better when he gets back to work
<ubot5> Launchpad bug 677305 in Bazaar "disconnecting the sftp transport hangs (affected: 1, heat: 6)" [Undecided,New]
<maxb> ooh
<maxb> I think I may have fixed that bug
<lifeless> maxb: its what killed the importds :)
<maxb> I'm kinda surprised no-one noticed - I guess no one actually uses sftp:// much
<maxb> I only noticed because dput uses bzrlib for sftp
<mwhudson> maxb: it seems that you can bzr branch sftp:// fine, i guess the __del__ method doesn't get called somehow then
<lifeless> we nuke the interpreter, don't we?
<mwhudson> oh right yes
<mwhudson> so very unlikely that __del__ runs then :_)
<_habnabit> Does anyone know offhand if a merge with conflicts will return a >0 status code?
<poolie> _habnabit: yes, it should
<_habnabit> Okay.
<vila> hi all !
<poolie> hi vila
<poolie> i have to confess i am an awful patch pilot :/
<vila> poolie: for your sin you will do it again next week :-D
<vila> kidding
<poolie> hm actually maybe i should
<poolie> but, my turn will come around again soon
<vila> Instead, you should feel very gulty so you'll be better next time
<vila> still kidding
<poolie> i'll try to do some next week without wearing the hat
<poolie> i see john did some recently
<vila> yeah, nice ones, good to see them again :D
<vila> regarding pqm, it works again
<vila> I haven't summarized the root causes yet, but briefly, we need to define the dependencies in a package that losas can use as a spec
<vila> I'll try to work on this today
<vila> This doesn't mean we don't need a backup plan, but this should severely reduce the occurrences of what we went through lately
<poolie> i think there's a bug asking for that?
<poolie> essentially a binary package that defines the dependencies even before such a bzr package exists?
<vila> ECANTPARSE 'even before such a bzr' :-/
<vila> a package with a Depends clause in the debian/control listing subunut, python-testtools and such (python-docutils ?)
<vila> named bzr-check-dependencies or something
<poolie> that's what i mean
<vila> or bzr-pqm-dependencies (I'm still not sure if we will have variations on this theme like bzr-dev-dependencies or bzr-doc-dependencies for docutils/sphinx switch)
<vila> ok
<poolie> normally these would be stated as the build dependencies of bzr 2.3.something
<poolie> however, there is no package of that name yet, because we can't commit the changes to upstream until we have installed the necessary dependencies into the chroot
<vila> ha build, hmm
<vila> meh, you lost me here :(
<vila> lack of chroot practice probably
<poolie> what packages will be depended-upon by tomorrow's bzr?
<poolie> you can't look at the metadata of tomorrow's deb package of bzr to find out, because it doesn't exist yet
<poolie> one solution to this bootstrapping problem is to have a second deb that just says what depedencies we want to have in the chroot
<poolie> is that clearer?
<vila> yup
<vila> Once it exists, this package will be in the BuildDepends for bzr itself, is that it ?
<vila> (since there is no TestDepends but we want to run tests during build this workaround this lack :)
<vila> back to bug #676608 and 17 may not enough at http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html
<ubot5> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/676608)
<ubot5> Launchpad bug 17 in Launchpad Translations "System error (affected: 2, heat: 0)" [High,Fix released] https://launchpad.net/bugs/17
<vila> s/and 17/and why 17/ for the ob tyop on my jokes
<vila> meh, thanks too much ubot
<poolie> almost: it won't be in the builddepends because we only need this is the special case of pqm
<poolie> regular debian or ubuntu builds can just declare their build depedencies in the usual way
<poolie> heh :)
<vila> but they will define the same dependencies no ? May be I should not care about that for now though...
<vila> poolie: those are just details, I got your points
<vila> 18. Even when you get it right, you're wrong
<poolie> :)
<vila> The sad thing is that I just tweak my fix because even if all the tests (including the one failing without the fix) were passing *even* if my fix was wrong (and I'm fed up enough to not try to write a test to prove this because.... I'm not even sure I can :-/)
<vila> So subtly wrong it looked right, but still :(
<GaryvdM> Good morning all.
<vila> Good Morning GaryvdM !
<vila> err, I meant Goooood Morning GaryvdM
<GaryvdM> Ha ha
<poolie> good night, vila, gary
<GaryvdM> Good night
<vila> poolie: enjoy your week-end
<poolie> GaryvdM: are you ok on those bugs? maybe vila can help if you need a buddy
<GaryvdM> I'm ok - I started looking at doing a incremental annotate last night
<GaryvdM> poolie: I spoke to jam about it
<poolie> that would be great
<vila> GaryvdM: feel free to ping
<GaryvdM> poolie: for bug 153787
<ubot5> Launchpad bug 153787 in Bazaar "annotation is slow in 2a and pack repositories (affected: 0, heat: 3)" [High,Confirmed] https://launchpad.net/bugs/153787
<GaryvdM> poolie: I know that it won't help for command line annotate - So I hope that will be ok for them.
<GaryvdM> But doing a incremental annotate in a gui is more suited to my skills than implementing a cache.
<GaryvdM> vila: Thanks
<poolie> doing an incremental annotate in a gui would be superb
<poolie> iwbn if it could also feed out incremental data to emacs or loggerhead (over ajax)
<GaryvdM> vila: how would it be possible to do that with emacs?
<vila> yup. exactly what poolie said, try to keep it in mind even if you start with a qbzr version (but I'm sure you thought about it)
<vila> GaryvdM: emacs can communicate with an asynchronous  subprocess
<vila> GaryvdM: so in theory it can update the display when the subprocess returns more precise annotations
<vila> GaryvdM: but as jam told you, you need first to revert the whole way the annotations are processed today starting with 'I have no idea where its coming from' to 'this line comes from this revision' via 'this line comes from a revision older than this one'
<GaryvdM> vila: re emacs: using something like curses?
<vila> GaryvdM: additional bonus if you managed to somehow restrict that to a window of lines currently displayed
<GaryvdM> vila: I can't see that that would make it faster.
<vila> well, emacs works from a tty to X11 displays and OSX graphic lib and Windows graphic lib, you shouldn't care about what it uses, just give him (line number, revision)
<vila> or (line start, line end, revision) tuples
<GaryvdM> vila: Is there a defined protocol for this?
<vila> GaryvdM: none that I know of
<vila> another additional bonus would be an option to limit the age of annotations as in: "Don't tell me about revisions older than 6 months"
<GaryvdM> vila: so we would need to write something that runs in emacs that parses this data, and displays it?
<GaryvdM> vila: re date limit: that would be easy. :-)
<vila> GaryvdM: yes, some emacs code should be written
<GaryvdM> ok
<vila> GaryvdM: this may even be a f.. good idea to be your buddy on the emacs side...
<vila> nothing beats parallel clients to debug a common implementation...
<GaryvdM> A curses version would also be nice. I also have been dreaming of a curses version of qlog :-)
<vila> clog then :)
<vila> ... of course I didn't realized that clog is a valid English word...
<guilhembi> GaryvdM: hello! Thanks for your reply on
<guilhembi> https://bugs.launchpad.net/bugs/588698
<ubot5> Launchpad bug 588698 in Bazaar ""bzr merge" fails "Branches have no common ancestor" (affected: 1, heat: 8)" [Medium,Fix released]
<GaryvdM> Hi guilhembi!
<guilhembi> GaryvdM: do I interpret correctly that you mean "all is normal"?
<GaryvdM> guilhembi: It's unfortunate that that merge conflicts. I did user tests for other examples of that situation, and the conflicts when using --weave were minimal.
<guilhembi> GaryvdM: to be sure: you mean the high number of conflicts is normal? You can say "yes" (I will then study this more in depth).
<GaryvdM> guilhembi: The conflicts happen because storage/innobase was added by 2 different people, not because of the shape of the rev graph.
<guilhembi> GaryvdM: so they are normal?
<guilhembi> i.e. expected, not a bug?
<GaryvdM> Yes
<guilhembi> GaryvdM: thanks. I'll look into the history to see how this mess happened.
<GaryvdM> guilhembi: I did a bzr log storage/innobase for both the jp and mm branches
<GaryvdM> jp: http://paste.ubuntu.com/534208/
<GaryvdM> mm http://paste.ubuntu.com/534209/
<GaryvdM> If you take a look - you will see that they have different histories.
<hrw> hi
<jelmer> hey hrw
<hrw> I have a problem. as "git bzr push" does not want to work and I have no time to dig in code to find out why I need to import ~10 patches into bzr (exported by "git format-patch"). how to make it without having to go by "patch <0001;bzr add -r .;bzr commit"?
<jelmer> hrw: do you know what about "git bzr push" doesn't work, it isn't an easy patch?
<jelmer> hrw: Alternatively you could try bzr-git's pull
<hrw> jelmer: http://pastebin.com/YVmSr4Cu
<hrw> bzr-git sounds worth to check
<Tak> whoa, there's a git bzr now?
<hrw> Tak: few plugins exists - none of them works perfectly
<hrw> Tak: I use git-bzr-ng one and it is fine for "git bzr clone" but "git bzr push" fails.
<hrw> Tak: ah.. and in natty even clone does not work but thats a matter of waiting for new bzr-fastimport package release (r282/284 fixed two bugs)
<hrw> jelmer: thx for bzr-git hint
<Tak> does bzr-git support push/dpush now?
<hrw> now only need to wait till LP will scan new branch and can request review
 * Ng cries at another -ng project ;)
<hrw> Tak: I only needed import
<Tak> no, that was a question for my own curiosity :-)
<Ng> however, I was just thinking about popping over to #bzr with a suggestion, so the highlight is a welcome reminder :)
<hrw> Tak: I use git for managing trees and bzr only to push to lp
<hrw> Ng: ;D
 * Ng wondered if it's possible to (globally) uniquely identify the ultimate root parent of any branch
<Ng> I sometimes go to pull from launchpad and find that the branch has disappeared because someone renamed a team or something - would be cute if LP could respond with "404, but here's a list of branches you could switch to or merge from"
<jelmer> Tak: it supports dpush, not yet dpush.
 * Tak segfault
<jelmer> Ng: Yeah, I agree that would be useful. Just a simple test search would help a lot I think. Keeping the history of names around explicitly would probably be harder.
<jelmer> Tak: argh, you caught me pre-coffee
<jelmer> Tak: it supports dpush, not yet push
<Ng> jelmer: is it worth me filing a wishlist bug?
<jelmer> Ng: please do
<Tak> ok - I would mainly want dpush anyway ;-)
<Tak> I'd offer you a coffee, but our machine is broken (again)
<Ng> jelmer: k, thanks :)
<jelmer> Tak: :-) Thanks anyway
<Tak> we do, however, have a wide selection of teas
<ssandberg> hi #bzr! is there a way to set per-file commit messages on the command line? perhaps there is a plugin?
<jelmer> hi ssandberg
<jelmer> ssandberg: There isn't one at the moment as far as I know.
<ssandberg> jelmer, ok. any idea how easy/hard it would be to write one? i suppose it would need one new command, and also it would need to modify the commit command so that it uses the global and per-file messages
<jelmer> ssandberg: do you want to do this the proper way or just a quick hack?
<jelmer> ssandberg: doing it properly would mean moving the current per-file commit backend code from bzr-gtk into bzrlib.
<jelmer> ssandberg: and then adding a UI for it (either in a plugin or in bzr core)
<ssandberg> jelmer, right. i see there is a https://bugs.launchpad.net/bzr/+bug/185224 for this
<ubot5> Launchpad bug 185224 in Bazaar "per-file message support into server: common config check {patch} (affected: 0, heat: 1)" [Medium,Confirmed]
<jelmer> it'd be very useful to have that in core (also so e.g. qbzr can easily use it)
<ssandberg> jelmer, i agree, would be great to have this bug fixed
<ssandberg> jelmer, i can't spend too much time on this myself though... i have a perl script that copies per-file comments from one place to another, which is sufficient for what i need except i have to go through the gui when i commit
<ssandberg> jelmer, so if it's not too much work i could create a hack that modifies the commit command to take the per-file messages into account. sorry i can't help more...
<jelmer> ssandberg: you could probably do a quick hack based on the existing code in bzr-gtk
<ssandberg> jelmer, ok. i'll look at that
<ssandberg> jelmer, thank you!
<speakman> hi folks
<speakman> can I check out just the source files from a bzr repo, without the .bzr dir?
<speakman> I just want a "snapshot" of the source tree for e.g. specified date
<jpds> speakman: bzr checkout --lightweight ... ?
<speakman> Will it ignore commit history and such?
<jelmer> speakman: bzr export
<speakman> jelmer: thanks!
<lvh> Hi!
<lvh> Is this the right place to ask about bzr-hg?
<lvh> I accidentally made the mistake of assuming hg's svn interop was good. I now have a directory Twisted-hgsvninteropdisaster.
<lvh> The last three revisions are changes I'd like to get out. How do I do that?
<lvh> (I could just use hg and get a diff of the last three and then apply that, of course.)
<james_w> lvh, if you have bzr-hg installed you may be able to "bzr diff" in there
<james_w> I'm not sure quite what you want to achieve though
<lvh> james_w: Okay, so the fourth last revision applied a patch (in hg): I also have a bzr repo at that point.
<lvh> james_w: Then I committed some changesets in hg.
<lvh> I'd like to take those changesets and apply them to the bzr branch instead.
<james_w> ah, I assumed you were targeting svn
<james_w> "bzr pull" might work for you
<james_w> "bzr pull ../Twisted-hgsvninteropdisaster" in your bzr bracnh
<lvh> Nah, they're different: the bzr branch has the original development, in the hg branch I just applied a patch
<lvh> I'll go with bzr diff
<vila> jam: about readability, note that the comment was saying: """Return true if any of the trans_ids, will have contents.""" which is highly ambiguous when all we want to know is: do we need to refuse to unversion/delete this directory
<jam> vila: I didn't think it was ambiguous at all. If any have contents, then it returns true
<jam> the comma shouldn't be there
<vila> jam: *I* find it ambiguous: which content ? Versioned ? Not versioned ?
<vila> jam: what's the difference between _removed_contents and _removed_ids ? Can a key be present in the latter but not in the former ?
<jam> I won't say the internals of TT aren't confusing at times. But the function _any_contents does what it says
<vila> hehe, but that doesn't answer my question when I was reading it: what's content ?
<vila> s/doesn't/didn't/
<vila> Oh, and the special casing was for final_kind() (Added a comment to the review)
<vila> jam: weird, you voted 'needs information' then 'approve' and your reviewer status on the mp page is still needs information...
<jam> vila: email landed into launchpad after I went to the webpage to see if I had an out-of-date diff
<jam> so probably the "first" vote was handled second and took priority
<vila> but is still displayed first... weird, n obig deal anyway, just mentioning
<vila> jam: thanks for the review !
<glyph> so we're talkin' about bzr bugs in #twisted again
<glyph> last time I came in here I had a problem with an svn branch whose history started before the first revision of trunk which included bzr-svn metadata
<glyph> that looked like it came from an alternate history
<glyph> (because the bzr-svn metadata in question was v3, and I was using a version of bzr-svn that used v4, so trunk and the branch disagreed as to how revisions were identified)
<glyph> I am pretty sure this is a known / existing bug, but I can't find it
<glyph> can someone toss me a link?
<jelmer> glyph: bug 332116?
<ubot5> Launchpad bug 332116 in Bazaar Subversion Plugin "different branches are using different ID mappings (affected: 0, heat: 0)" [Low,Triaged] https://launchpad.net/bugs/332116
<glyph> hey, do you guys still support hardy?  because if so, https://bugs.launchpad.net/bzr/+bug/677655
<ubot5> Launchpad bug 677655 in Bazaar "subvertpy traceback when using bzr from ppa on a hardy machine, even if I'm not invoking a bzr-svn command (affected: 1, heat: 6)" [Undecided,New]
<spiv> glyph: we do
<jam> hey spiv, feeling better?
<glyph> spiv: all my hardy machines with bzr-svn installed are now unusable for all bzr operations, so that one would be a good one to fix :)
<glyph> I guess it must have snuck in in the last update?
<spiv> jam: almost!
<jam> glyph: sounds like you got an updated bzr-svn but not an updated subvertpy
<glyph> jam: all I did was 'apt-get upgrade'
<glyph> jam: you can see my policy settings on the bug, I'll adjust them if something's wrong
<jelmer> glyph, jam: That looks like a broken subvertpy package.
<jelmer> newer bzr-svn versions should generally work with older versions of subvertpy
#bzr 2010-11-20
<maxb> glyph: Hrm, that looks like a bug caused by subvertpy converting from python-central to python-suppor
<maxb> glyph: the weird thing is, I tested the upgrade in a hardy chroot, and it did not experience the problem
<glyph> maxb: well, thanks for testing, at least :)
<glyph> maxb: I can give you SSH access to this machine, if can't reproduce on your own hardy box and you want to see what it looks like
<Kamping_Kaiser> naw, i made dulwitch explode
<MvG> Hi! I feel trac-bzr bug #675014 is actually a bzr bug. Do you agree that the following command should work?
<MvG> env -i PATH=/bin:/usr/bin python -c 'from bzrlib import bzrdir, transport; print bzrdir.BzrDir.open_containing_from_transport(transport.get_transport(".").clone("./t%C3%A4st"))'
<ubot5> Launchpad bug 675014 in Trac-Bzr "InvalidURL: URL was not a plain ASCII url (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/675014
<MvG> bzrlib.transport.local.LocalTransport.abspath has some comments about url escaping that probably affect this issue here.
<maxb> glyph: Did you see the my comment on the bug? Unfortunately I'm not sure that SSH access to a machine would actually tell me how it got into that state.
<maxb> MvG: Succeeds for me running bzr.dev
<MvG> maxb: strange. How do you tell python to use bzr.dev? Does PYTHONPATH=. do the trick?
<MvG> maxb: Still can reproduce here. This is on Gentoo Linux. What OS are you on?
<maxb> ah, not actually bzr.dev, but 2.3b3 release as it turns out. Installed as a system packaged, on Ubuntu maverick.
<maxb> though it also works with bzr.dev when I remember to set PYTHONPATH
<MvG> Also fails with 2.3b3 for me.
 * MvG scratches his head
<MvG> Can reproduce on a different system, a 1.3.1-1ubuntu0.1 on Ubuntu hardy.
<MvG> maxb: You sure you copied the "env -i" along with the rest?
<maxb> *oh*
<maxb> Now I get
<maxb>     return osutils.open_file(path, 'rb')
<maxb> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 16: ordinal not in range(128)
<MvG> It seems important that bzrlib has no knowledge of your locale, and therefore relies on ascii as the only safe thing.
<maxb> which I would describe as correct behaviour, if a little unfriendly
<MvG> If this is correct behaviour, is there an equally correct way to determine the branch and location within the branch if all one has is a transport at the root of hierarchy with several branches, and if one does not know the location where the branch-location part of the url stops and the within-branch part starts?
<MvG> Should I combine the URL myself and rely on open_containing instead of open_containing_from_transport?
<maxb> erm, something feels wrong about this question
<maxb> if all one has is what you said, you don't have anything specifying a single branch
<maxb> and I don't see how using transport-based vs url-based APIs would affect things
<maxb> MvG: Fundamentally, if you deprive bzr of locale information you make it impossible to map unicode strings onto filesystem objects outside the realm of ASCII
<MvG> Scenario is this: trac-bzr has one base location configured for the whole setup. All paths are expected to be relative to that. There are usually branches under it, so when users ask for object branch/dir/file, then trac-bzr should open base/branch, because it is the nearest parent of base/branch/dir/file that does exist and contain a .bzr control dir. It should also return dir/file as the path within that branch, for further processing.
<maxb> sounds like exactly what open_containing is for/
<maxb> ?
<MvG> Well, some operations use several branches, and base might be a remote URL. In that case, I assume that clone() might be a lot more efficient than creating a new transport from scratch for every such item.
<MvG> I assume that was the original intent behind using clone there, although I didn't write that code.
<MvG> The fact that open_containing_from_transport exists suggests that a transport might refer to stuff within a branch as well as the branch root. And having that part rely on locale feels bad.
<maxb> If any of the branches are named with non-ASCII, trac-bzr will and should have proper locale information
<maxb> Though it is unpleasant, only the locale defines the charset to be used in file/directory names, on common Linux filesystems, as far as I know
<MvG> The branches are all ascii, it's files within them which cause trouble. Those aren't even present in the filesystem, as the branches aren't checked out.
<maxb> OK, that is less nice
<maxb> I expect that part of open_containing involves probing whether they do or don't exist, which means bzr still needs to figure out what they would be called on disk if they did exist
<MvG> Probably.
<spiv> MvG: well, open_containing takes an optional possible_transports kwarg
<MvG> spiv: That does sound good!
<spiv> MvG: so it too can avoid constructing transports from scratch
<maxb> Incidentally, are the semantics of possible_transports documented anywhere?
<MvG> spiv: possible_transports is a list?
<spiv> Yes.
<spiv> maxb: heh, almost
<MvG> By the way, how can I ensure to jail all access to some root transport? I.e. forbid access to branches that aren't below that root?
<spiv> maxb: see 'pydoc bzrlib.transport.get_transport', except it gives the param the wrong name...
<vila> spiv: urgh, ugly, shoot the culprit ;)
<vila> err, no , wait, I meant bb:approve ! :D
<spiv> vila: if it weren't zzz-o'clock on a Saturday, I might even do it...
<ambv> hi there. I found a bug in 2.2.1, could anyone confirm whether it's still there on the latest trunk?
<maxb> WHat's the bug?
<ambv> one of your favourite UnicodeDecodeError kind
<ambv> 1. branch out with a name using some Unicode characters
<ambv> 2. commits work, log works, merging works
<ambv> 3. but version-info raises UnicodeDecodeError
<spiv> ambv: with LANG=C and a UTF-8 branch name I get a UnicodeDecodeError traceback, yes.
<spiv> ambv: please file a bug.
<ambv> spiv: great, I can present you with a patch as well.
<spiv> ambv: doubly good!
<spiv> ambv: any traceback from the CLI is a bug
<spiv> ambv: so don't be afraid to file them if you see them :)
<ambv> spiv: yeah but I don't want just to file bugs
<ambv> recently I have been closing CPython bugs that were there since like 2004 or so
<ambv> painful job since some of them very fairly trivial
<spiv> ambv: well, if you want to fix them too that's awesome :)
<ambv> yeah, that would at least be of some utility
<ambv> what kind of worries me though is that the number of UCDEs on the tracker is kind of high:
<ambv> https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=UnicodeDecodeError&orderby=-importance
<spiv> Yeah.
<ambv> (there's not mine there yet)
<spiv> Some/many may turn out to have common causes, or even have been fixed already.
<ambv> spiv: did you confirm the bug on the trunk though>
<spiv> ambv: yes
<ambv> great.
<ambv> so you're a core bzr dev?
<spiv> Yeah.
<ambv> nice to meet you, the product is fantastic.
<spiv> Also, I'm due to be asleep :)
<spiv> Thanks!
<ambv> so, sleep well spiv
<spiv> I will now :)
<ambv> it's 2 PM where I'm now
<ambv> haha
<vila> ambv: there are several people working on Unicode errors in the community so +1 on spiv's "file bugs"
<vila> ambv: there are also patches ready to land that are related (from mgz)
<vila> mgz: by the way, is there anything retaining you to land those branches ?
<vila> mgz: there are still enough time before 2.3b4 for this kind of stuff (says the RM ;)
<meeto> hi
<meeto> is anyone interested in a small QA (Paid) to setup an IIS server with BZR?
 * maxb ponders the need to set up a hardy VM to debug 677655
<Guest90193> bug 677655 ?
<ubot5> Launchpad bug 677655 in Bazaar "subvertpy traceback when using bzr from ppa on a hardy machine, even if I'm not invoking a bzr-svn command (affected: 2, heat: 12)" [Undecided,New] https://launchpad.net/bugs/677655
<mgz> <ambv> 3. but version-info raises UnicodeDecodeError <- sounds like bug 518609 which should mangle the name rather than raise on trunk
<ubot5> Launchpad bug 518609 in Bazaar "Unicode exception occurs by "version-info" (affected: 4, heat: 20)" [Medium,Fix released] https://launchpad.net/bugs/518609
<mgz> it's a problem with how version-info is specified.
<mgz> (or rather the default 'rio' format)
<ambv> mgz: yes.
<ambv> rio.
<ambv> this is why I asked if it's still the case on trunk.
<ambv> spiv told me it is.
<ambv> mgz: can you confirm or deny this? :)
<mgz> it should be 'fixed' on trunk, where fixed means it doesn't throw an exception any more but mangles the text instead.
<ambv> mgz: why would it mange?
<ambv> *mangle
<ambv> I mean, I know why --format python would
<ambv> but the text format?
<ambv> bzr log works
<mgz> well, read the bug, but basically because the claim is rio is a binary format that happens to be utf-8, not text
<mgz> this is a dumb design, but means printing to a non-utf8 terminal results in unreadable output
<ambv> mgz: then again, I do have an UTF-8 term.
<mgz> then I'm suprised it ever raised an error for you, what's your LANG setting? or are you on a mac?
<ambv> Mac
<mgz> okay, that'd be it.
<ambv> why?
<ambv> default encoding?
<mgz> locale works slightly differently there. anyway, the trunk fix should be fine for you.
<ambv> great.
<mgz> do file any other non-ascii bugs you find, just keep in mind bug 172383 which will probably cover many of them.
<ubot5> Launchpad bug 172383 in Bazaar "[master] can't cope with NFD Unicode normalization on Mac OS X (affected: 11, heat: 100)" [Medium,Confirmed] https://launchpad.net/bugs/172383
<ambv> mgz: I will. it is to be expected that Linux will be the main platform here. I mean Canonical, etc. and this being a GNU project. so I will try to test the hell out of it on the Mac.
<lvh> Hi!
<lvh> Is there a guide for serving bzr with access control?
<lvh> I basically want private access only (both for reading and writing).
<lifeless> install bzr on the server, use bzr+ssh urls.
<lifeless> done :)
<lvh> lifeless: Aha, okay, so just make plain user accounts for everyone
<lvh> lifeless: Thanks
<lvh> lifeless: Is there some kind of convention for storing stuff? /var? I assume everyone needs write access.
<lvh> (Although I'll just use the bookmarks plugin to make that a non-issue)
<fullermd> I imagine that's more site-ish than bzr-ish...
<fullermd> Our 'central' stuff at work is under /home/cvs/ for instance.
<lvh> fullermd: I was thinking of an analogy with /var/ww
<lvh> w
<fullermd> (originally for consistency with our CVS stuff; now to keep people on their toes ;)
#bzr 2010-11-21
<thumper> hi guys
<thumper> what causes bzr to core?
<thumper> when branching from lp:project I'm seeing a core dump on someone elses machine
<thumper> but branching from bzr+ssh://... was ok
<thumper> so perhaps it is just the xmlrpc launchpad lookup
<thumper> but I'm at a bit of a loss
<Peng> Betcha curl could do it.
<Peng> But does anybody still use curl...?
<thumper> how would I tell?
<thumper> it appears to have just started in the last hour
<thumper> and not much has changed
<thumper> it is very weird
<Peng> Erm. .bzr.log should say. Anyway, it's just a shot in the dark. You're probably not using curl.
<Peng> I'm not sure if it's even enabled at all anymore...
<fullermd> Actually, I think it's still the default if present.
<Peng> Not for HTTPS, though, right?
<fullermd> For any HTTP.
<fullermd> Well, maybe vila made it do HTPPS instead   ;>
<Peng> @_@
<thumper> bzr.log says absolutely nothing helpful
<thumper> fullermd: how do I tell if he has curl installed?
<Peng> bzr.log should say what HTTP implementation is being used.
<lifeless> thumper: coring? really? - often curl, sometimes we have bugs in our C extensions.
<thumper> lifeless: yeah Seg fault
<lifeless> for the former, if pycurl can be imported, it will be used (on http)
<thumper> well... there is no core file
<thumper> just a seg fault
<lifeless> for the latter, remove the .so files for bzr
<lifeless> [these are workaround]
<lifeless> you can run under gdb or valgrind to find out the actual segfault details and file a bug
<thumper> it was in ssh connections
<lifeless> could be pycrypto I guess
<lifeless> gdb is probably the best bet
<timeless_mbp> i'd like to perform a histedit operation, either stripping tip or doing something quilty to tip
<spiv> timeless_mbp: see 'bzr uncommit', or the bzr-rewrite plugin, or the bzr-loom plugin, or the bzr-pipelines plugin, or even the bzr-fastimport plugin (it has options for filtering the fastimport/export dumps).
 * spiv -> zzz
<timeless_mbp> thanks
<seiflotfy_> hey guys
<seiflotfy_> is there a way to find out how many commits some1 made
<seiflotfy_> ?
<timeless_mbp> use ohloh.net ;-)
<timeless_mbp> (it kinda depends on what you mean)
<seiflotfy_> i mean code commits
<timeless_mbp> if someone commits as -u "jo@shmo" and -u "jane@doe"
<timeless_mbp> or "j@doe"
<timeless_mbp> do you want to count them as the same person? :)
<vila> seiflotfy_: bzr stats (from bzr lp:bzr-stats plugin)
<vila> the plugin use some tricks to recognize synonyms, not perfect but quite good
<timeless_mbp> generally for open source stuff, letting ohloh do your counting is a better choice
<seiflotfy_> nah
<seiflotfy_> i just want for one account
<timeless_mbp> in DVCS you also have serious issues w/ branch commits
<timeless_mbp> for that, i'd just use bzr log --authors=...
<timeless_mbp> but i'm a lazy hacker :)
<seiflotfy_> i want to know for a launchpad account
<timeless_mbp> on just one bzr repo or in the lp: world? :)
<seiflotfy_> one repo
<vila> well, ohloh is telling me that the next update will join two users, but it's doing so for... 4 ? 6 months ?
<vila> from which I can of deduce that there have been no update since then ?
<seiflotfy_> timeless_mbp, is there a way to list the different contributors to a branch
<seiflotfy_> and when they contributed
<vila> or that the user joining is broken
<vila> seiflotfy_: bzr-stats is a pretty small plugin the option you're asking for doesn't exist (AFAIK) but shouldn't be hard to implement either
<seiflotfy_> ok
<seiflotfy_> got it
<seiflotfy_> how cna i use it
<seiflotfy_> i installed
<seiflotfy_> but cant use it
<vila> I can tell you how to use it but people will say I'm talking to myself again...
<lifeless> :)
<djanko> hey
<djanko> is there any way to check out only part of a branch into a particular location?
<djanko> eg I have app/static and app/scripts - they need to be in separate locations on my live webserver, but I want to be able to commit both of them atomically on my local dev machine
<bob2> easiest way is to have your web server do the mapping
<maxb> or symlinks
<lifeless> djanko: 'views'
<lifeless> djanko: will do that for you
<djanko> thx!
<spiv> Good morning.
<jelmer> hi Spiv :-)
<lifeless> spiv: the fetch primitives improvements... will you be fixing up loom to use it?
<poolie> hi spiv!
<poolie> gosh, it's early :)
<poolie> are you feeling better?
<spiv> lifeless: probably easy to do when they're ready, give me a prod if I forget about updating loom!
<spiv> Yes, finally.
<spiv> Was still a little bit off yesterday even, but appears back to normal in time for Monday morning :)
<peitschie> mornin every1 :)
<poolie> hi there peitschie
<peitschie> hiya poolie
#bzr 2011-11-14
<poolie> jam, hi?
<poolie> lifeless, hi?
<poolie> spiv, hi?
<lifeless> poolie: ?
<vila> hi all !
<poolie> hi there vila
<poolie> vila: ah, more free advice :)
<vila> ? oom thread ? (catching up with mail)
<poolie> on what beta means
<vila> oh, my take on that is to stop using 'gold' and just say 'source released' which is what we do anyway
<poolie> yep
<poolie> i think that's the only change
<vila> oh, great to see we agree ;)
<vila> as for beta/snapshot... I don't have a strong opinion either way
<Merwin> hi
<poolie> i don't see much point in changing
<poolie> vila, so basically i'm going to try inserting a layer that spills out big strings to temp files
<poolie> i think it will be at least tolerably clean
<vila> hmm, I was wondering about that but couldn't decide if that would be enough, good to try anyway
<poolie> i think it's worth a try, yeah
<poolie> vila re detecting lp being down
<poolie> mm
<poolie> i think some of that should go in lazr.restful
<poolie> then we need to release and deploy it
<poolie> another thing we really need to do is to finish jam's patches
<vila> lazr.restful, right, but I'm not sure all of them can go there and I need a solution *now*
<poolie> :)
<vila> I've seen some 502 bad gateway which probably need to be reported when they are valid errors
<vila> and deciding if they are valid or not seem... untractable(sp?)  ;)
<vila> re-connection patches... as mentioned, I'm worried we need to address some pre-requisites first or run into an endless whack-a-mole game
<lifeless> poolie: you pinged ?
<poolie> yep, unping
<vila> we went down a road hoping to fix fallouts on the basis that they were no race, reality disagreed
<vila> there is still a tough call about using an external server or not
<vila> I call it tough as I'm not sure anymore that it will be enough to avoid the race(s)
<vila> I *thought* it was the way to go, I'm not sure anymore
<poolie> external server for what?
<vila> test server
<vila> as opposed to test server in the same process
<poolie> oh i see i thought you were still talking about udd
<poolie> what's the down side?
<vila> the whole 'race chasing' saga has revealed many races were really about running the client and the server in the same process, but the late issues have a different smell
<vila> down side of using an external server ?
<vila> for one it requires up-front work to make sure it works,
<vila> then, if the race is not caused by using an internal one, it's useless to use an external one :)
<poolie> hm
<poolie> it does not seem like it will often make things much worse
<poolie> i thought we already did the work to run it externalyl?
<vila> for other kinds of server, yes, I did wrote a plugin, and internally I think there are tests that runs it externally in an ad-hoc way
<vila> but I was about to mention that I didn't look too closely to the code itself yet, my last work was to triage the failures on babune to get an overview
<vila> from there I concluded that we really have a race (it happens on all platforms which rules out a kernel issue and also probably rules out a python issue)
<vila> the question, to me, now boils down to: is this (or these) race(s) caused by running an internal server OR do we have a genuine bug in the smart server
<poolie> :/
<poolie> and they're all intermittent?
<poolie> and they don't show up if you run the tests repeatedly locally?
<vila> yup
<vila> i.e. we're in a pretty bad situation were we can suddenly see failures to land valid stuff
<poolie> i have never seen these hangs or failures
<poolie> i don't think i've seen them on pqm either
<poolie> therefore they don't exist
<poolie> jk
<vila> hehe
<poolie> no, but seriously
<poolie> it's specific to running under jenkins, or on those vms?
<vila> mgz and I have been unfortunate enough to encounter them while submitting to pqm ;)
<poolie> ah
<poolie> vila, so
<poolie> what's next?
<vila> hmm
<vila> so, I identified one race and have a patch for it against 2.4. I ran into conflicts trying to merge up to trunk
<vila> and these conflicts are (unsurprisingly) in the test servers
<vila> which means reworking a bunch of later submissions
<vila> but that's only one race and I'm far from sure it's the only one
<vila> and, so far, I didn't want to switch from other stuff I'm already working on :-}
<poolie> ok
<vila> in summary: those failures are bad but not critical (and hopefully will stay spurious, avoiding a total pqm hang), we probably want to fix them before reviewing/landing the reconnection stuff (to avoid more work)
<vila> this hasn't reach the top of my TODO list yet to avoid losing steam in other areas
<vila> oh, and jelmer encountered one of them too during an armel build IIRC
<spiv> poolie: I'm around for a bit now
<poolie> hey
<poolie> i was going to talk about some memory stuff but it's ok now
<poolie> i wouldn't mind taking up your lunch offer some itme
<mgz> morning all
<poolie> hi there
<poolie> thanks for the review jam
<jam> np
<spiv> poolie: sure, how about Wednesday?
<poolie> wfm
<mgz> re races earlier, they're less obvious on PQM mostly because we do far fewer runs there than across all of babune
<mgz> I've had both of the two main flavours on pqm though, and one of the bugs was filed by jelmer because it happened on a buildd
<_arch> hi
<poolie> night all
<poolie> i'll be out tomorrow
<mgz> have fun at the races!
<poolie> thanks
<_arch> I have a question concerning symbolic links in bazaar
<poolie> no actual races
<_arch> I have a working tree that contains a lot of subdirectories that contain a bunch of files. I need to create symbolic links from these files to other subdirectories, and my colleagues need to be able to use these files just by pulling from our repo
<_arch> any ideas how to accomplish this?
<mgz> I don't understand the problem statement.
<_arch> perhaps it's not very clear :)
<mgz> it sounds like you're trying to version references to thinks outside the tree, then want people to get your branch and somehow be able to resolve the links?
<mgz> that's clearly not going to work.
<jam> _arch: Assuming it is something like "bzr init work"; work/files/a; work/links/to_a
<mgz> s/thinks/things/
<jam> bzr will be able to track them appropriately, as long as you use relative symlinks
<_arch> great
<_arch> problem solved :)
<jam> eg cd work/links, ln -s ../files/a to_a
<jam> not full paths
<jam> cd work/links
<jam> ln -s /home/_arch/path/to/work/files/a
<jam> however, it all needs to be in one tree if you want 'bzr pull' to just work
<jam> if you have >1 tree, then they'll at least have to pull in each tree
<_arch> I must have created my links improperly. Thanks a lot
<mgz> bzr could probably complain if you try and version symlinks with absolute paths
<mgz> as that's generally going to be a mistake
<jam> mgz: not really, just a different use case. "bzr init x; mkdir bin; cd bin; ln -s /usr/bin/python py"
<mgz> huh.
<jam> or maybe /etc/alternatives ?
<jelmer> the daily builds now have translations enabled
<jelmer> gwenhwyvar:~% LANGUAGE=es_ES bzr rocks
<jelmer> Â¡Seguro que no!
<vila> I don't speak spanish but this sounds like a little joke :)
<vila> shouldn't that be s/no/si/ ?
<jelmer> vila: yeah :)
<Pegasus_RPG> Hello. I just set up a BZR repo on my web server using SFTP/SSH and test-committed a change from my local checkout. The commit worked fine but the file hasn't changed. How can I find out what is going on?
<jelmer> Pegasus_RPG: bzr doesn't update remote working trees (push should warn you about this)
<jelmer> Pegasus_RPG: you can use the push-and-update plugin to ssh into the server to update the working tree
<Pegasus_RPG> jelmer: But I initially pushed using sftp
<Pegasus_RPG> then made a checkout (I like checkouts better)
<Pegasus_RPG> then made a change, then committed
<jelmer> Pegasus_RPG: bzr won't update the checkout, just the branch, over sftp
<Pegasus_RPG> I need bzr+ssh://  ?
<jelmer> Pegasus_RPG: no, you'll need something like the push-and-update plugint to update the remote working tree
<Pegasus_RPG> so how does a commit work with launchpad then?
<Pegasus_RPG> I've been doing that for years
<jam> jelmer, mgz, vila: Has there been a qbzr *release* to correlate with the Unicode encoding problem, or is 2.5b3 supposed to include qbzr trunk?
<jelmer> jam: I'm not sure, I'm having trouble finding the unicode bug at the moment
<jam> bug #889208
<ubot5> Launchpad bug 872616 in QBzr "duplicate for #889208 TypeError on all commands that get progress report from subprocess" [Critical,Fix released] https://launchpad.net/bugs/872616
<jam> well, 872616 I guess
<vila> installers for betas are supposed to carry tips unless specifically told otherwise no ?
<jelmer> jam: I suspect you'll need trunk as (as far as I can tell) qbzr hasn't done a release since that bug was reported
<jam> vila: nope
<jam> vila: at least, the last 99 windows installers didn't
<jam> perhaps I've just been doing them all wrong
<vila> too bad, that's what OSX installers do :-/
<vila> they switch to official releases or specific revisions when .0 is reached
<vila> the idea being to give some exposure to plugins during the betas and give some incentive to plugin authors to do some official releases
<Pegasus_RPG> jelmer: I'm confused...how does Bazaar accomplish it's main function if users can't update the server's repo by default?
<jelmer> Pegasus_RPG: it can update the repository, but it doesn't update the files in the working tree
<jelmer> Pegasus_RPG: you'll notice that if you run "bzr up" in the remote repository it will create those files
<jam> vila: it seems a bit odd to expose trunk's tip, and then revert it to a released version if the plugin doesn't actually make a release.
<Pegasus_RPG> jelmer: actually, it complains   bzr: ERROR: No WorkingTree exists for "file:///var/www/Browns/OperationsSystem/.bzr/checkout/".
<vila> jam: which is why I said "or specific revisions"
<jam> vila: sure. Though IMO it isn't the packager's decision what version of X should be released to the world, but up to upstream. Again, people can certainly have different opinions.
<jam> we can certainly change the release process, the build tool is capable of releasing from tip or from explicit versions
<jam> I'm certainly not planning on running that debate ATM
<jelmer> Pegasus_RPG: hmm, I'm not sure I understand what you're asking in that case
<jam> I just noticed 'mgz' saying "wait for the next release", and noticing that it wouldn't actually have the fix
<jam> qbzr specifically used to make monthly releases to coincide even with bzr betas.
<vila> jam: then you know better than me :)
<vila> jam: ask the qbzr maintainers maybe ?
<jam> vila: bialix and garyvdm aren't in the channel, mgz made the fix but hasn't responded (is he off today?)
<Pegasus_RPG> jelmer: OK... I want to convert an existing static directory on a web server into a bzr repo so I can make a local checkout, work on it, then commit the changes to the live server. How do I do that?
<mgz> jam: you're right it's odd, but you do need qbzr trunk currently
<Pegasus_RPG> jelmer: So far, I installed bzr locally, straight-copied the static web server files to a local directory, bzr init'ed it, then bzr push --use-existing-dir   to the exising server directory.
<jelmer> Pegasus_RPG: ahh
<jelmer> Pegasus_RPG: you want to add all the files to the repository - try "bzr add ." followed by "bzr commit"
<jelmer> Pegasus_RPG: to upload the files to the remote location, you probably want to use "bzr upload" rather than "bzr push"
<jelmer> Pegasus_RPG: ("bzr push" only updates the remote bzr repository, and doesn't update a checkout if it exists there)
<Pegasus_RPG> jelmer: ok, so use bzr upload all the time or just the first time?
<jelmer> Pegasus_RPG: all the time
<Pegasus_RPG> ok. (I still wonder how LaunchPad repos work. There, I can make a local checkout, work on it, then bzr commit and the changes are up on the server for all to soo.)
<Pegasus_RPG> jelmer: erm, Bazaar 2.1.2 doesn't know "upload"
<vila> Pegasus_RPG: there is no working trees on launchpad
<jelmer> Pegasus_RPG: it's a plugin
<mgz> initing bzrlib in a script is still a pain
<vila> what could make it less painful ?
<mgz> not having to know which other random things don't get called in initialize and need to be done seperately
<mgz> in this case, I needed commands._register_builtin_commands() and plugin.load_plugins() and commands.install_bzr_command_hooks()
<jelmer> mgz: I think we should have a load_plugins=bool argument for bzrlib.intiialize
<mgz> vila: do you have a lot of plugins in you base setup?
<mgz> jelmer: hooks are also an issue it seems
<mgz> vila: can you run lp:~gz/+junk/list_global_options and pastebin the results?
<vila> mgz: 28 plugins
<mgz> I'm on a minor yak mission.
<vila> http://paste.ubuntu.com/738202/
<vila> mgz: ^
<jelmer> hmm, 48 plugins here..
<mgz> do you get anything more running the script jelmer?
<jelmer> mgz: Global options used by plugins: ['change', 'directory', 'force', 'merge-type', 'overwrite', 'remember', 'reprocess', 'revision', 'show-ids', 'timezone', 'verbose']
<mgz> force and reprocess
<mgz> cool, thanks!
<jelmer> pipeline uses reprocess
<mgz> force is a bit funky, doesn't come with help
<mgz> all the bzrlib commands that want --force supply an option so you know what's being forced
<GRiD> jam, thanks for analysis on bug 720853
<ubot5> Launchpad bug 720853 in Bazaar "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [Medium,In progress] https://launchpad.net/bugs/720853
<DeafFish> When will the nested tree feature be released?
<jelmer> DeafFish: hi
<DeafFish> Hi
<jelmer> DeafFish: there is some basic support for nested trees in the experimental 'development-subtree' format in current versions of bzr
<DeafFish> Ah, ok
<jelmer> DeafFish: finishing nested trees and adding support for it to the stable format is on our list of things to work on
<DeafFish> Any word on when it will move into stable?
<jelmer> DeafFish: not really, sorry
<DeafFish> No worries
<DeafFish> As of right now it isn't a problem
<DeafFish> Thanks!
<glyph> hello bzr
<glyph> https://bugs.launchpad.net/bzr/+bug/890373
<ubot5> Ubuntu bug 890373 in Bazaar "can't get a launchpad branch into a shared repository" [Undecided,New]
<glyph> once again Twisted development is thwarted by trying to use bzr :(
<jelmer> hi glyph
<glyph> hi jelmer
<mgz> looks like bug 806348
<ubot5> Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348
<mgz> though I thought it was one exarkun had already reported
<glyph> mgz: we run into it every so often
<glyph> at inconvenient times
<jelmer> mgz: I've marked it as a dupe
<glyph> I can send you my shared repo if that would help
<jelmer> now that bzr-svn passes all the main bzr tests I'm pretty sure it no longmer creates revisions with this issue
<jelmer> but there are probably still revisions out there in the wild that were created with older versions of bzr-svn
<glyph> jelmer: is there a way to fix it?
<glyph> jelmer: we have an official bzr mirror, and we're trying to migrate slowly to bzr rather than svn, these periodic disasters notwithstanding
<glyph> jelmer: but throwing out our repository and breaking all clients every time we discover a wayward revision is not really an attractive option :-\
<mgz> glyph: as with this other things you guys have reported, looks like we just need to fix the bug
<glyph> mgz: yes please
<jelmer> glyph: there are two things - 1) updating your mirror to have the right representation of those svn revisions (created with bzr-svn 1.1.1) will make sure you don't hit this bug, and 2) bzr should be able to cope with this situation (perhaps warn, because it is after all slightly different metadata) but not fail
<glyph> jelmer: oh
<glyph> jelmer: looks like I'm still on 1.0.5dev
<glyph> jelmer: has 1.1.1 made it into a mac installer yet?
<jelmer> glyph: no, it looks like it's a fair few revisions behind
<jelmer> doxx isn't around at the moment, I'll submit an MP
<jelmer> glyph: submitted an updated for the 2.4 mac installers, hopefully doxx will merge that for the next one
<jelmer> back later
<glyph> so speaking of things which don't work right
<glyph> what's the status of bzr-git?  can one maintain a git mirror of a bzr repository yet?
<jelmer> glyph: no, but we're getting there
<jdobrien> hi all... a while ago someone was telling me about an alternative to using repo when you have a number of consecutive branches to work on...any help/reminders would be appreciated
<jelmer> glyph: bug #544776 is the main bug to track
<ubot5> Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,In progress] https://launchpad.net/bugs/544776
<jelmer> jdobrien: hi
<jelmer> jdobrien: colocated branches perhaps?
<glyph> jelmer: thanks.  I know it's kinda ridiculous to even ask, but: do you have an ETA?
<glyph> (how come launchpad doesn't track effort estimates)
<jdobrien> jelmer: that's it :)
<jelmer> glyph: so, in its most simple form (maintaining an incremental git mirror of the bzr branch, no merging back into bzr), it apparently already works
<jelmer> glyph: somebody is using that to maintain a git mirror of mysql
<jelmer> glyph: that said, the format is still experimental and there are still a lot of tests that need fixing - I'm not going to enable this until that happens
<glyph> jelmer: I'll just bug Twisted people who want us to move to bzr to start clicking on that bug :)
<jelmer> glyph: (I don't really want to end up with bugs similar to bug 806348, but for bzr-git)
<ubot5> Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348
<jelmer> glyph: it is one of the things I'm working on though, and we have made some big improvements towards bug 544776 in the last few months
<ubot5> Error: Could not gather data from Launchpad for bug #544776 (https://launchpad.net/bugs/544776). The error has been logged
<glyph> jelmer: is there a way to fix the shared repository with the buggy revisions yet without re-importing it from scratch?
<jdobrien> jelmer: if I am starting with an empty directory (not bzr'd) and a project in launchpad and i want to use colo, what do i do? I'm following the tutorial and it's not making sense
<jelmer> jdobrien: sorry, I don't actually have any experience with bzr-colo myself
<jdobrien> jelmer: ok
<jelmer> glyph: re-importing from scratch is the only way I'm aware of. fixing the bzr side of things (not error out so badly, but coping with the inconsistent metadata) would also work around it of course
<glyph> jelmer: what about lp:twisted
<glyph> jelmer: will that automatically re-run its import at some point?
<jelmer> glyph: that's a good point, I'll look into it
#bzr 2011-11-15
<mgz> gra, this is more of a mess than I thought
<mgz> we have bug 485601 and one against bzr-svn
<ubot5> Launchpad bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [Critical,Fix released] https://launchpad.net/bugs/485601
<mgz> and dupes of each of those from both glyph and exarkun
<mgz> sorry for the tag spam, should save searching by bug filer in future
<mgz> the good news is we've fixed about half the found by twisted bugs
<mgz> the bad news is the other half still has a lot of scary bugs in it
<jelmer> https://bugs.launchpad.net/bazaar/+bugs?field.tag=affects-twisted
<jdobrien> hello all. I am trying to use colo and pipelines together, I have a branch with a few pipelines and I would like to push on of them to launchpad and propose it for merging, but I'm missing something... my typical bzr push is not working with this scenario
<jo-erlend_> what am I doing wrong? bzr branch bzr+ssh:jo-erlend@desktop.local:/devel/project
<jo-erlend_> bzr: ERROR: Unsupported protocol for url "bzr+ssh:jo-erlend@desktop.local:/home/jo-erlend/devel/project"
<vila> jo-erlend_: bzr+ssh://user@host/path , check your '/' and ':'
<vila> mailto:bzr+ssh:jo-erlend@desktop.local:/devel/project
<vila> grrr
<vila> bzr+ssh://jo-erlend@desktop.local/devel/project is probably what you want
<vila> hey guys, I encounter wm issues there bbiab
<mgz> morning!
<vila> mgz: pool time !
<vila> err, sry wrong time frame ;)
<mgz> :)
<mgz> what's that tool jam and others were using to simulate a slow network for testing?
<jam> mgz: the command is 'tc' let me poke at it, just a sec
<jam> mgz: doc/developers/testing.txt
<vila> mgz: see testing.txt in doc/developers
<jam> "simulating slow networks"
<vila> :)
<mgz> ta.
<vila> mgz, jelmer: standup ?
<mgz> tis time.
<vila> jelmer: pingeling
<mgz> precise babune eh.
<vila> hpmf, no way to prepare surprises :)
<vila> started on the wrong foot but successful at the second run, not that bad
<mgz> okay, woho, with the right bits installed I can reproduce some of these failures
<vila> for which value of 'these' ?
<mgz> the url normalisation regressions that broke the windows buildbot
<vila> \o/
<mgz> ...and the sftp tests leak threads
<mgz> the isolation failure ones are drive name specific
<mgz> but the tilde handling is a general issue
<vila> ouch, for these ones, reproducing is far away from fixing (IIRC paramiko just won't let you wrap the thread creations)
<mgz> Gio also fails some tests
<vila> gio ? on windows ?
<mgz> no, I haven't got windows here
<mgz> which is a bit daft, because three of the things I need to finish from last week could do with being tested there
<vila> o.O
<mgz> anyway, this:
<mgz> `mkdir /tmp/tilde~ && TEMP=/tmp/tilde~ ./bzr selftest -s bt.per_transport SFTP`
<mgz> works to get 4 of the failures from babune
<vila> oooh
<vila> urgh
<mgz> regression from r6079 see bug 842223
<ubot5> Launchpad bug 842223 in Bazaar "Change to tilde escaping causes test failures" [Medium,Confirmed] https://launchpad.net/bugs/842223
<vila> yeah, but I haven't realized it could be triggered that easily..
<mgz> I can probably write a specific test here now, which will mean I can fix (or at least fiddle with till that test passes) the handling
<mgz> the url code makes me unhappy
<mgz> we still have the other windows babune issue, which is the failure to remove shell script thing
<vila> forget about that one, too obscure to diagnose and probably involve both vbox and jenkins and the phase of the moon
<vila> well, it may also just be a hang :)
<vila> ... that leads to a vm being killed which itself forbids jenkins to remove a file from a dead host
<mgz> yeah.
<hrw> hi
<hrw> how to commit 2 lines from file with other changes? 'bzr commit --interactive' operates on diff hunks which are too big in this case
<mgz> hrw: shelve everything you don't want to commit right now
<hrw> mgz: ok, so other option then revert edits
<mgz> if you set a change editor, you can pick out which parts to shelve on a sub-hunk basis
<samebchase> Hi, I'm unable to do: bzr launchpad-login
<samebchase> I am behind a proxy
<samebchase> The error message I get is: bzr: ERROR: Connection error: Couldn't resolve host 'launchpad.net' [Errno -2] Name or service not known
<samebchase> Can someone please advise me as to what I should be doing?
<mgz> samebchase: can you ssh to arbitrary servers?
<samebchase> mgz: yeah
<samebchase> In the meantime, however
<samebchase> I've been able to bzr branch a repo
<mgz> then you can do everything you really need, just set launchpad_username by editing ~/.bazaar/bazaar.conf
<samebchase> mgz: oh. let me try that
<samebchase> Did what was told here:  http://www.omappedia.org/wiki/Using_bzr_and_launchpad_behind_a_proxy
<mgz> otherwise you'll be able to branch (anonymously) over http, but not push
<samebchase> hmm
<mgz> okay, if you followed that you'll be okay
<mgz> just need to set username, and give launchpad your public key if you've not already
<mgz> then can try pushing something to lp:~/+junk/testbranch
<mgz> may need ~yourusername if you've got an older bzr version
<samebchase> I've added launchpad_username = samebchase
<samebchase> I've already added my public key
<mgz> if your test branch was using bzr+ssh: as per that page rather than lp: then you're probably all done
<samebchase> mgz: Thanks a lot for your help. I've got to go out now, sorry!
<samebchase> mgz: will have to figure out the rest later tonight
<samebchase> mgz: thanks!
<jelmer> grmbl, clearly this is not my day
 * mgz gives jelmer a cupcake
 * jelmer has been fighting with bzr-builddeb code all morning
<jelmer> thanks mgz :)
 * vila offers a coffee ;)
<vila> jelmer, mgz: should we do the standup now ?
<jelmer> vila: might as well
<jelmer> vila, mgz: 13:30 UTC ?
<vila> jelmer: cool, feel free to vent if it helps ;)
<vila> 10 mins from now is good for me
<mgz> there was talk of lunch heree, but I have a feeling it's still a way off
<mgz> lets do it, I can eat later
<jo-erlend> where does bazaar explorer store its bookmarks?
<webm0nk3y> I'm having trouble in a colocated branch. I started a new branch and now I have a bunch of conflicts from work in another branch
<jelmer> jo-erlend: my guess is somewhere in .bzr/branch/branch.conf ?
<jelmer> webm0nk3y: hi
<webm0nk3y> jelmer: hi
<psusi> bzr doesn't have any cherry pick tracking?  Is that a feature that is coming any time soon? ;)
<jelmer> webm0nk3y: can you provide a bit more background?
<webm0nk3y> jelmer: sure
<webm0nk3y> jelmer: actually I think I goofed up
<webm0nk3y> jelmer: I did bzr colo-branch <new branch>
<webm0nk3y> jelmer: then started hacking
<jelmer> psusi: no, there is no cherry picking tracking at the moment. we have some ideas about it, but it's hard to implement cherrypicking tracking in a way that doesn't impact merge
<jelmer> psusi: *merge performance
<psusi> drat... I'm trying to find a way to give two branches a common ancestor that don't already have one ( because one is built from tarball release )... was hoping cherry picking could do it... oh well...
<jelmer> psusi: you can do that without cherrypicking
<jelmer> psusi: "bzr merge -r0..-1 <other-branch>"
<psusi> revision -1?
<jelmer> psusi: it works like in python. -1 is the last revision
<jelmer> "bzr merge-r0.. <other-branch>" would work too
<psusi> won't that result in all kinds of conflicts as merge tries to pull in changes that already exist here?
<jelmer> psusi: you can revert the changes afterwards ("bzr revert .") to only add the new parent
<psusi> hrm... so in other words, it will make a mess, but I can just sweep it all under the rug, and when I commit the merge, the history will be knit together?
<jelmer> psusi: sortof :)
<psusi> as long as the rev I'm merging from actually is common between the two branches then it should work out... hrm...
<psusi> so let me see if I've got this... what I'm trying to solve is that the ubuntu package merges from the debian package... the debian package merges from what it calls 'upstream' but is really just a branch they unpack the upstream release tarball into...
<jelmer> ah
<jelmer> I'm not really sure if the "merge -r0..-1" trick will really be useful in that case
<jelmer> you can stitch the history together but the file ids will still be different
<psusi> if I find the correct upstream revision that the tarball came from, I can take the debian branch, and do a full merge from that upstream revision, revert the conflicts, and after commit, the debian branch will have a common ancestor with upstream, allowing merge from upstream into the debian branch, or the ubuntu branch ( after it merges from debian )
<psusi> so that should be ok as long as debian starts merging from upstream instead of tarballing it, but if they keep tarballing, it will make for messy conflicts?
<jelmer> what is upstream in?
<psusi> ultimately, git.kernel.org... but lp is auto importing that into a bzr branch
<jelmer> ah, hmm
<jelmer> this is the "parallel import" use case
<psusi> I guess so?  debian pulls from upstream but via tarball... I'd like to pull from upstream properly... two paths for upstream to get into our repository...
<jelmer> psusi: in order for bzr to be able to deal with that properly it has to somehow know that a particular upstream revision and a particular revision from debian should be considered the same
<jelmer> psusi: we don't have a mechanism that does that yet
<psusi> jelmer: isn't that what you would get by doing that merge, revert conflicts, commit dance?
<jelmer> psusi: no, that will stitch the history together but won't actually make bzr consider two revisions the same
<psusi> jelmer: isn't that enough?  why does it need to consider them to be the same?
<Noldorin> why do the windows releases for bzr beta always come latest?
<vila> Noldorin: hear hear ! We have a new volunteer to build the installers :)
<Noldorin> you guys do know windows has far many more bzr users than Mac? :-P
<Noldorin> and probably most linux distros
<Noldorin> ha
<Noldorin> vila, nah just questioning priorities. it's too hard for me ;-)
<vila> ... but far less volunteers, yeah, that's the key :-/
<Noldorin> vila, i tried before and failed miserably.
<vila> :-(
<Noldorin> vila, if you want to help me get the installer building here, i would consider it though.
<vila> Noldorin: try pinging jam and/or mgz, windows is out of my league (not to mention my plate ;)
<Noldorin> hah ok
<Noldorin> vila, you're a core dev eh?
<Noldorin> jam, mgz hi
 * vila nods
<Noldorin> vila, while you're hear...will co-located branches make it into bzr-core for 2.5 final?
<vila> there are strong hopes for that yes
<Noldorin> cool
<jelmer> psusi: it needs to stitch the individual file histories together for that as well
<mgz> jelmer: updates to info-empty-controlir and verify-remote-signatures look good, but have conflicts to sort out before landing
<Noldorin> vila, and will the URL format improve? i mean something more like url,colo-branch instead of url,branch=colo-branch
<vila> It is still planned AIUI
<mgz> Noldorin: yes, the setup needed for windows installers is a little out of most people's reach currently
<Noldorin> hmm
<Noldorin> mgz, don't you guys have a build server? :-)
<Noldorin> vila, AIUI?
<vila> As I Understand It
<Noldorin> ok
<Noldorin> vila, so posibly by final release...
<vila> yup
<mgz> there are a lot of manual things to do, that aren't easy to automate
<Noldorin> :-)
<Noldorin> vila, good work on all the rest, i do say. very happy with the beta so far
<vila> thanks, very much appreciated, will repeat it to responsible parties ;)
<Noldorin> vila, it makes me glad because i can still resist the Git movement heh ;-)
<jelmer> mgz: thanks
<vila> resistance is not futile :)
<Noldorin> mgz, ah okay. just thought the bzr guys, being such proponents of agile/iterative dev and all, would have a CI server up. but fair enough
<Noldorin> what sort of environment does it require?
<vila> there *is* a CI server, it's used for tests so far ;)
<vila> http://babune.ladeuil.net:24842/
<Noldorin> vila, indeed. my minimalist attitude won't let me use git. bzr if i can, hg if i have to
<Noldorin> vila, oh ok :-)
<Noldorin> that's a good start
<Noldorin> Jenkins looks pretty nice. plan on using it for my own projs
<Noldorin> vila, mgz in fact i will be setting up my personal bulid server later this week. perhaps we can talk about setting up a Windows installer build then
<Noldorin> brb
<vila> Noldorin: that would rock !
<Noldorin> vila, yeah, will get back to you soon about it i hope :-)
<jelmer> mgz: any chance of an update to the MPs?
<mgz> jelmer: done
<jelmer> mgz: thanks!
<mgz> okay, confusing bug state again.
<mgz> fullermd's bug is actually fixed, and is basically the cause of the current complaint.
<mgz> so in other words, it's his fault.
<vila> mgz: and ? You're surprised ???
<vila> :-D
 * vila is not even here
<Noldorin> back
<mgz> Noldorin: your step one should be just running `bzr selftest` locally and seing if you have any issues.
<fullermd> Hmmwhut?  I didn't do it.  I was never even in that warehouse, and where would I get that much napalm anyway?
<Noldorin> mgz, once i get the build server up and running you mean? :-)
<mgz> bug 148030 fullermd :)
<ubot5> Launchpad bug 148030 in Bazaar "Heavy checkouts don't inherit nick" [High,Fix released] https://launchpad.net/bugs/148030
<mgz> Noldorin: well, I imagine those tasks could be parallelised if you're using bzr on your local machine too :)
<fullermd> Oh.  I didn't _want_ to file that.  vila made me do it.  So it's really his fault.
<Noldorin> mgz, yeah, although i'm using the exe rather than py version on my laptop so that i get tortoisebzr support
<fullermd> That's probably why he's trying so hard to pin it on me above.  The very nerve!
<vila> fullermd: me ? I don't even know what a lightweight checkout is ! You're the #1 on the list of people talking the most about them  !
<fullermd> You sure do seem to know a lot about who talks about them.  SUSPICIOUSLY a lot, one might say...
<mgz> vila: did anyone send the standup notes to the list?
<mgz> and can you tell me what bugs I said I was working on this week...
<mgz> okay, bug 842223 is this one
<ubot5> Launchpad bug 842223 in Bazaar "Change to tilde escaping causes test failures" [Medium,Confirmed] https://launchpad.net/bugs/842223
<mgz> I'll post the standup notes for today to the list.
<glyph> jelmer: hey
<glyph> jelmer: are you around?
<glyph> I'd like to fix Twisted's broken revisions
<glyph> My understanding is that if we update the official Bazaar mirror to bzr-svn 1.1.1, then delete and re-generate everything, and tell everyone to stop pulling from svn and pull only from bzr-svn
<glyph> that we will be okay
<glyph> I am starting to think that the reason we were seeing that problem recently is that Launchpad's mirror has effectively done this already, so maybe we can save some time and pull from Launchpad's mirror rather than from svn
<jelmer> 'evening
<jelmer> glyph: hi
<poolie> hi jelmer
<Noldorin> hi jelmer
<Noldorin> hmm...why does bzr not like symlink dirs in sitepackages?
<jelmer> hi poolie, Noldorin
<peitschie> hi jelmer :)
<peitschie> and the rest :D
<poolie> Noldorin, what do you mean?
<jelmer> Noldorin: I think we just rely on Python there
<jelmer> poolie: it looks like launchpad-buildd 95 worked, but 97 broke all recipe builds because it no longer installs apt_pkg
<Noldorin> poolie, jelmer a symlink dir (on windows) in site-packages doesn't get picked up
<Noldorin> whereas a real dir does
<jelmer> poolie: oh, I see you're already talking in #-ops
<poolie> yep
<poolie> i'm uploading a fix now
<jelmer> cool
<Noldorin> jelmer, poolie not sure what bzr is doing to miss it
<Noldorin> using the bundled win32 dist here
<Noldorin> win7, x64
<jelmer> Noldorin: does python work with a symlink dir?
<Noldorin> jelmer, apparently so
<Noldorin> jelmer, was just enquiring about that, but it seems it does
#bzr 2011-11-16
<jelmer> Noldorin: how is it failing exactly?
<glyph> jelmer: was my earlier summary accurate
<Noldorin> jelmer, it doesn't import the module from site-packages
<jelmer> glyph: yes, although I should note that only newer twisted revisions were imported with newer versions of bzr-svn on launchpad
<jelmer> Noldorin: what module is it failing to import?
<jelmer> Noldorin: and how is it doing that, do you have a traceback?
<glyph> jelmer: hrm
<jelmer> glyph: so perhaps it's better to be safe than sorry and redo the launchpad imports
<glyph> jelmer: is there a way to explicitly refresh that?
<glyph> and is launchpad on bzr-svn 1.1.1 yet?
<Noldorin> jelmer, nothing. just says "cannot importy module"
<Noldorin> no traceback sorry
<jelmer> Noldorin: .bzr.log should have a traceback
<jelmer> glyph: yes, it's post-1.1.1
<Noldorin> jelmer, okay just a sec
<glyph> jelmer: I guess the way to fix it is just to do the re-import somewhere else, then 'bzr push --overwrite lp:twisted'?
<spiv> jelmer: +1 to getting launchpad to redo that import
<jelmer> glyph: we'll have to do it via Launchpad, as import branches are only writable by the importds
<jelmer> glyph: I can look into getting that done
<glyph> jelmer: so there's no button for me to press, then
<jelmer> Noldorin: any luck?
<jo-erlend> in my Python script, I'd like to check the status of a given folder, such as if there are uncommitted changes, unknown files, etc. What is the best way to do that?
<jo-erlend> I've been told there are bzr tools for Python, and that sounds nice. If anyone has a link to docs, I'd appreciate it.
<jelmer> jo-erlend: you probably want to use the working tree
<jo-erlend> jelmer, I don't understand what you mean by that.
<jelmer> jo-erlend: from bzrlib.workingtree import WorkingTree; w = WorkingTree.open("."); print bool(wt.changes_from(wt.basis_tree()))
<jo-erlend> sounds nice. Any docs for it?
<jelmer> jo-erlend: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.workingtree.WorkingTree.html
<jo-erlend> I guess I'll just run bzr st and check the status myself. I don't even understand how to begin using that stuff, and the only thing I need is to see if a folder has any changes. I don't need to do anything about it.
<jelmer> jo-erlend: the fragment I pasted earlier should give you a boolean that indicates whether anything has changed
<jo-erlend> oh. That was easier than it looked. :)
<jo-erlend> thanks. :)
<Noldorin> jelmer, yeah just testing
<jo-erlend> jelmer, that feature isn't documented, though?
<jo-erlend> I can do w.unknowns to get unversioned files, but I don't understand how I can see if files are modified. I also can't figure out how to find out what WorkingTree.changes_from does.
<Noldorin> jelmer, what's an easy way to check if bzr-git has loaded correctly?
<jelmer> jo-erlend: the fragment I posted should tell you if there are any modifications since the last commit
<Darxus> "bzr: ERROR: No module named apt_pkg" - https://launchpadlibrarian.net/85223456/buildlog.txt.gz
<Darxus> From https://code.launchpad.net/~spamassassin/+recipe/spamassassin-daily
<Darxus> Bulding is failing again....
<jo-erlend> jelmer, yes, I understand that. I'm having difficulty finding out how to see if I already know that a file is unversioned or not, for instance.
<jelmer> Darxus: there is work going on to fix that
<Darxus> jelmer: Thanks.
<jelmer> jo-erlend: it will only return versioned files, so only files that are not in .unknowns()
<Noldorin> jelmer, ?
<jo-erlend> oh, I see. Thanks.
<jelmer> jo-erlend: See Tree.changes_from() for the documentation ("pydoc bzrlib.tree.Tree.changes_from")
<jelmer> Noldorin: "bzr plugins"
<Noldorin> jelmer, that displays fine even if dependent modules didn't load though
<jelmer> Noldorin: it means the basic bits of bzr-git have loaded though
<jelmer> Noldorin: if you want to make sure *all* of bzr-git works, run the bzr-git testsuite
<Noldorin> jelmer, yes but it won't tell me if dulwich loaded
<Noldorin> jelmer, which is what i want to find out
<Noldorin> very simply
<jelmer> Noldorin: any sort of operation involving a git repository should load dulwich
<Noldorin> got it
<Noldorin> jelmer, here's the error:
<Noldorin> bzr: ERROR: Unsupported protocol for url "git://": Unable to import library "dulwich": bzr-git: Plea
<Noldorin> se install dulwich, https://launchpad.net/dulwich
<Noldorin> jelmer, when dulwich is a symlinkd rather than real dir in site-packages/
<Noldorin> that happens
<jelmer> Noldorin: right, but what about the traceback (in ~/.bzr.log) ?
<jelmer> Noldorin: we just use "import" from python to load dulwich, so that's all inside of Python itself
<Noldorin> oooh
<Noldorin> i see
<Noldorin> got it
<Noldorin> jelmer, http://pastebin.com/cXdaVkpL
<jelmer> hmm, that's masking the actual error
<Noldorin> jelmer,yeah...
<jelmer> Noldorin: can you try adding "import dulwich" to bzr-git's __init__.py ?
<Noldorin> jelmer, same
<jelmer> Noldorin: the traceback in ~/.bzr.log should be different
<Noldorin> oh yes
<Noldorin> jelmer, http://pastie.org/2870011
<jelmer> Noldorin: right, python's import doesn't find dulwich
<Noldorin> yeah
<Noldorin> so python's import doesn't like symlink dirs basically?
<Noldorin> because it finds it fine when it's a normal dir
<jelmer> Noldorin: it seems happy with symlinks on Unix, perhaps it's different on Windows?
<Noldorin> jelmer, perhaps
<Noldorin> i've updated the python bug i submitted about it
<Noldorin> originally i was confused about what i tested
<Noldorin> http://bugs.python.org/issue13412?@ok_message=msg%20147744%20created%3Cbr%3Eissue%2013412%20message_count%2C%20messages%20edited%20ok&@template=item
<Noldorin> jelmer, ^
<Noldorin> jelmer, i'm off now, but feel free to investigate it more and ping me later :-)
<Noldorin> ciao
<jelmer> Noldorin: sorry, I'll leave that up to the Python folks
<Noldorin> jelmer, that's fine. i only said that in case you thought it might be something specific about bzr :-P
<Noldorin> jelmer, if you think it's a generic issue, my bug should take care of it
<Noldorin> ta ta
<poolie> hi vila?
<vila> poolie: hey !
<jam> morning all
<poolie> hi jam
<jam> hi poolie
<jam> you've been quite active on email after being gone :)
<poolie> oh, really?
<poolie> i was only gone for a day
<poolie> i do feel like i've been having a good few weeks though
<poolie> jam anyhow i battled with buildds and ec2 today
<poolie> and i haven't actually touched memory usage :/
<poolie> so i don't have much to say
<poolie> other than that i'm glad i was heading in the direction you described
<jelmer> 'morning
<mgz> morning all
<poolie> hi mgz, jelmer
<jo-erlend> when I branch from some place, work on my new branch and commit to it before merging with the branch I branched from ... Will the details of the commits to my branch be visible in the other one, or will it be treated as a single commit?
<bob2> yes and no, though bzr log will by default only show the merge
<mgz> you get the best of both worlds :)
<jo-erlend> what exactly does that mean?
<bob2> yes the data of every commit ever is visible
<mgz> the information is kept, but the default view only shows the 'mainline'
<bob2> no by default 'bzr log' will not show the branch merged in, just the merge commit
<jo-erlend> oh, ok. I'll need to consider my personal comments, then :)
<mgz> that's good general advice :)
<mgz> weird failures ;_;
<mgz> the problem with the windows bot being red for so long is I have no idea which of these are due to path escaping changes
<vila> mgz :-/
<mgz> vila: just posted summary in bug 842223 mp
<ubot5> Launchpad bug 842223 in Bazaar "Change to tilde escaping causes test failures" [High,In progress] https://launchpad.net/bugs/842223
<mgz> maybe just something went wrong with the building of extensions on babune?
<mgz> I don't think I caused them at any rate, so this branch can probably still land
<mgz> and the last main windows babune build got through without bailing trying to remove a shell script, which is great
 * vila reads
<vila> so, summary, this should land and I should check the extensions build on babune right ?
<mgz> I think so.
<mgz> this was using /debug/ not /Windows/
<mgz> and we've not touched debug in a while.
<vila> right, but the /debug/ job rebuilt some extensions, nothing suspicious there
<vila> or is it ?
<vila> mgz: ^ ?
<mgz> the rebuild in itself isn't suspicious, I started at an older revision, so there were pyrex source updates in between
 * mgz downloads the log to have a look too
<vila> which are indirectly reflected by the compilations
<mgz> there's an error from make saying format incorrect de paramÃ©tre
<mgz> probably not relevent
<vila> yeah, bogus mount, spurious AFAICT
 * mgz notes for future reference, altgr+; e
<vila> hehe, no, that's an agrave accent not an acute one ;)
<mgz> dammit, I had that first
<mgz> altgr+#, e -> Ã¨ then
<vila> yup
<mgz> and the mystery of the vanishing bug 842233 failures is resolved
<ubot5> Launchpad bug 842233 in Bazaar "InvalidURL from tests for local_path_from_url on windows" [Medium,Confirmed] https://launchpad.net/bugs/842233
<mgz> the end of the log is "lost connection"
<vila> I've lost altgr on my keyboard long ago anyway so feel free to not type accents ;)
<mgz> so they weren't run
<vila> ha
<vila> good ? :D
<mgz> would be nice if babune clearly distinguished between "all tests run, some failed"
<mgz> and "stuff went seriously wrong"
<vila> shouldn't subunit handle that ? 'lost connection' comes from there no ?
<mgz> I never remember to look at the test count, and it's not immediately obvious
<mgz> well, subunit doesn't help, certainly.
<mgz> Ã¦Ã¦ÃÃÃ°Ã°Aaaseaphews
<mgz> I see why you removed altgr now
<mgz> I just got stuck in an alternate land where my input made only funky characters
<vila> hehe, I *lost* it and since I use it very rarely I didn't notice ;)
<vila> it seems to be bound to alt now
<poolie> :)
<poolie> i like the cÃ¸mpose key
<vila> right, that the one I should use :)
<jo-erlend> are commit messages used for anything other than telling other humans about a project? I've noticed that some people seem to use a very formal commit "format", whereas I just write the stuff I've done.
<vila> jo-erlend: some humans use conventions to communicate ;) But really they are just conventions. Unless a project use higher level tools to process these commit messages, they are just strings as far as bzr is concerned
<mgz> jo-erlend: it's a social issue, generally you want to fit in with what the project you're contributing to does, or if its your own project make up the rules
<mgz> for instance, in bzr itself,
<mgz> people do commit messages in feature branches however they want,
<mgz> but then when our automated lander merges the feature to the main branch it adds the committer and proposer to the commit message which by convention is a one sentence overview
<mgz> using the structured stuff for commit like --fixes and --author is better than munging those into the message
<mgz> if you're writing "patch from X fixing bug N" then you're doing something wrong in my view :)
<jo-erlend> is fixes just a label, or is it linked to a bug tracker?
<mgz> it's stored as aURL
<jo-erlend> oh, ok.
<jo-erlend> but I guess it has better understanding for bugs stored in launchpad?
<jelmer> mgz: hi
<jelmer> mgz: just looking at your recent comment
<jelmer> mgz: the new behaviour seems right to me
<mgz> jelmer: yeah, but does show that I didn't succeed in getting the exact tilde handling as before
<mgz> only having to change one test isn't too bad, I just fear other fallout
<mgz> jo-erlend: launchpad itself has some special integration, and I think some other bug tracker software has some too
<mgz> eheh, jam's comment on pylzma is funny
<vila> mgz: I've seen cases where tests were *enforcing* a bug
<jam> mgz: well, you've submitted 3+ times now I think, and nobody gets a failure message :)
<mgz> I seem to have accidentally broken the access restrictions on my home bzr+http server
<mgz> not a bad thing right now, as I wanted to test against a remote http repo
<jelmer> mgz: I've updated switch-colocated to include tests for unicode colocated and other branches
<jelmer> that also involved using "real" branch names rather than url encoding for the "sibling" branch support in switch
<jelmer> vila: any plans for Branch._get_store() ? :)
<vila> huh ? Shouldn't be needed, what's the use case ?
<jelmer> vila: ah, hmm. I guess Branch._get_config_stack() then?
<jelmer> or Branch.get_config_stack()
<vila> we already landed that no ? :)
<jelmer> right :)
<jelmer> I guess we'll just need a custom RemoteBranch.get_config_stack() implementation which uses RemoteBranchStore or something similar
<vila> right, there is already a RemoteBranchStack
<vila> jelmer: do you encounter a issues with it ?
<jelmer> I'm seeing VFS access over HPSS from BranchStore
<jelmer> vila: RemoteBranch.get_config_stack() returns _mod_config.BranchStack(self)
<vila> right, RemoteBranchStack is a bit hackish, let me find the relevant comment
<jelmer> vila: also, RemoteBranchStack still uses BranchStore so presumably will involve VFS calls too
<vila> if you use the old config scheme you also trigger VFS calls
<vila> this should be better once http://pad.lv/832042 is fixed
<ubot5> Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress]
<vila> +# Needed for 'stacked_on_location' *only* which use a hack that could be
<vila> +# removed when each config file is read only once. This stack is not yet used
<vila> +# in branch.py -- vila 2011-09-06
<jelmer> ah, thanks
<jelmer> vila: btw, that bug is in progress but not assigned?
<vila> hehe, I was angry :)
<vila> jelmer: fixed (or rather assigned ;)
<jelmer> vila: :)
<vila> not sure yet if I should finish migration options before or after fixing it
<vila> s/migration/migrating/
<jelmer> vila: after, IMO. we shouldn't really be adding more VFS calls
<vila> I don't think we added some so far ?
<jelmer> vila: Branch.get_config() doesn't use VFS calls AFAIK, but Branch.get_config_stack() does
<vila> but the remote config stuff is one of the most confusing so I may have miss a case
<jelmer> vila: also, it's nice to have the design (including lokcing, etc) of the config stacks finished before we start using it in anger
<vila> locking should be ok
<vila> ha, looking at remote.py, right, not a VFS but still a request so in the end, it will be a single VFS instead of at least one request per option
<jelmer> vila: I mean locking in combination with not reading/writing config files for every option touched
<jelmer> vila: plus the overhead of enabling VFS mode
<vila> oh, that, right
<vila> if I'm not mistaken, the actual behavior for remote objects is to query the config for each option (without caching it) so doing a single VFS call will be a win
<vila> as for locking, we are already under a branch lock so we reuse it
<vila> i.e. at worst, even today, we do one VFS call instead of a query and in the end, we'll get rid of the queries
<jelmer> vila: but we should be moving away from VFS calls, not introducing new ones
<vila> one step at a time :)
<vila> once we know which VFS calls are still needed, we can turn them into queries
<jelmer> vila: sure; I'm just saying I don't think we should be switching to config stacks while they're introducing more VFS calls
<vila> or reuse the existing ones (but that sounded too hairy last time I looked)
<vila> jelmer: what do you propose then ?
<jelmer> vila: adding a HPSS call for branch stores
<vila> premature design, the needed calls will be fully defined when all the options are migrated
<vila> and *requiring* HPSS calls will break backward compatibility with older servers
<jelmer> vila: that means introducing more VFS calls until all options are migrated, I really think that's a bad idea.
<jelmer> vila: I didn't say anything about requiring HPSS calls. Just about not relying on VFS calls.
<vila> *one* VFS call by store instead of one query by option
<jelmer> vila: who says we can't have a VFS call for retrieving the stack contents?
<jelmer> s/VFS/HPSS/
<vila> the point is to reduce the queries, VFS or not
<vila> backward compatibility for older servers
<vila> you can't switch to stacks using HPSS calls *only*
<jelmer> sure, either way we'll still support falling back to VFS if the serve doesn't support newer calls like we do with all HPSS calls
<jelmer> *server
<vila> HPSS calls are worth only if they replace *several* VFS calls, it doesn't matter here
<jelmer> vila: eventually we want to get to a VFS-free HPSS server
<vila> sure
<vila> but I'd rather to an HPSS call that also returns the branch store when opening the branch then...
<vila> s/rather/rather add/
<vila> in that case that would mean one less roundtrip
<vila> but just adding an HPSS call to replace a single VFS call ? What's the gain ?
<jelmer> vila: it's not tied to the underlying file format
<jelmer> vila: wouldn't the config be read each time the branch is read locked?
<vila> jelmer: it depends on whether the config file is always read when a branch is read locked :)
<vila> but it may be a win anyway if it avoids a roundtrip in most cases
<jelmer> vila: anyway, my point really was about fixing when we read and write config files first
<jelmer> so that we have a stable config stack/store API to rely on
<jelmer> vila: I think the HPSS thing matters too, but that should be a lot easier to fix (and not have any impact on callers)
<vila> you totally lost me
<jelmer> vila: I think we should fix bug 832042 before using config stacks/stores in anger, because it probably will impact API users
<ubot5> Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042
<vila> jelmer: if you find a way to fix it without a new config scheme, please go ahead, I bang head for a long time before reaching the conclusion that the new design was the best way to achieve that :)
<jelmer> vila: I think we should fix it *in config stacks/stores* before we start switching options over
<vila> jelmer: wrong idea, that would multiply the potential issues
<jelmer> vila: if we don't then I think we probably will have to fix callers of the stack/store API when bug 832042 gets fixed.
<ubot5> Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042
<vila> chicken-and-egg
<vila> I did propose a stack registry to make sure stack/store acquisition could be controlled
<vila> this was pushed because there was no clear need
<vila> I'm now working to make the needs clearer
<jelmer> Sorry, but I don't see how a stack registry is relevant here.
<vila> I know :)
<jelmer> as a caller, I want to know when my changes get written to disk if I do: Branch.get_config_stack().set("foo", "bar")
<vila> today: during the call, tomorrow: when you release the branch write lock
<jelmer> vila: it would be nice ot state that in bug 832042 at least
<ubot5> Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042
<jelmer> at the moment it's very vague about that
<vila> devnotes/configuration.txt has a more precise definition and refers to bug #832042
<vila> but still a bit hand-wavy
<jelmer> vila: I don't see any references to 832042 in configuration.txt
<jelmer> is this your private notes?
<vila> grr doc.bazaar.canonical.com is down ??
<vila> ha right, the bug reference is a local edit, I was referring to the last section 'Why and when locking config files matter'
<jelmer> vila: doc/developers/configuration.txt in lp:bzr ?
<vila> no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt
<vila> no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt#L760 even
<jelmer> ah, ok
<jelmer> vila: thanks
<jelmer> I'll paste the relevant bits into the bug
<jelmer> (it's really confusing to have two documents about this btw, I don't really see the point of lp:bzr/devnotes)
<vila> not implemented yet stuff
<jelmer> right, but that's true for doc/developers in lp:bzr too
<vila> err, no, the later is targeted at developers and refers to internals as they work today (at least that's my understanding)
<jelmer> vila: I've landed several specs there before they were implemented, plans.txt was created specifically for that purpose
<vila> really ?
<vila> there is no plans.txt right now though
<jelmer> vila: there is, doc/developers/plans.txt in lp:bzr
 * vila blinks
<jelmer> my understanding of devnotes was that it was just a place to stow random notes from sprints, I don't think I've looked at it since Barcelona
<jelmer> anyway, the configuration.txt in there is a good read
<vila> the devnotes one you mean ?
<jelmer> I think you sent me a copy of it earlier, I didn't realize it was in there
<jelmer> vila: yeah
<vila> Ha, you read it at least once, I was scared for a second :)
<vila> jelmer: if you want more read on config, enjoy https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 ;)
<jelmer> vila: sure, I'll have a look
<jelmer> vila: https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 now includes aliases too, is that intentional?
<jelmer> vila: http://pastebin.ubuntu.com/740351/
<vila> wow, nice catch, no it's not
<vila> or is it...
<vila> errr
<vila> no not intentional
<vila> but is it such a bad idea ? Yes, probably
<vila> jelmer: fix pushed and comment added to the mp explaining the root issue
 * jelmer looks
<jelmer> vila: wouldn't this break "bzr config" for people who currently don't have a [DEFAULT] header set?
<vila> I don't think we really support having a no-name section in bazaar.conf, some tests were relying on this assumption but  IIRC bazaar.conf is created with the DEFAULT section (and documented as such)
<jelmer> ok
<vila> the old code is pretty blurry around this specific issue
<jelmer> yeah
<mgz> jelmer: reviewed some of your updated branches, just a few little things
<jelmer> mgz: thanks
<jelmer> vila: it looks a bit odd that list option values are in quotes
<jelmer> vila: I know why, but still
<jelmer> anyway, MP looks good otherwise
<vila> jelmer: yup, the issue is that we don't rely on the store to automaGically interpolate lists, we *can* do either (depending on option registration), we default to not.
<vila> jelmer: regarding the HPSS call, I agree it can and should be done,
<vila> jelmer: but it doesn't have to be done before or after $this, it can be done in parallel
<vila> jelmer: and indeed, some _get_store is needed ;)
<vila> jelmer: I had to re-think our discussion backwards, but I've connected the dots :-)
<jelmer> vila: ah, ok
<jelmer> vila: I'm still working on Andrew's HPSS branch, I might have a stab at the config store one too
<mgz> hpss still scares me...
<jelmer> mgz: it scared me too, but I found it quite reasonable once I dug into it. The main thing that makes it hard to work with is that the code is so scattered across different bits of bzrlib.
<mgz> yeah, finding which bits are actually still live can be a bit of a challenge, and understanding the naming
<jelmer> vila: FWIW, "bzr config -d lp:..." is 11 HPSS calls before your change, 25 after (13 VFS)
<vila> jelmer: (not here) can you paste that with a full (reproducing) url as a comment in the mp ?
<glyph> If I want to run a command after a particular branch gets a new HEAD revision, where do I put that hook?
<jelmer> vila: done
<jelmer> glyph: a bzr plugin which installs a post_tip_change hook. I believe we have examples somewhere, hang on..
<glyph> jelmer: actually maybe I'm saying this wrong
<glyph> I want to install this on the server side of things
<glyph> the branch that gets pushed to
<jelmer> glyph: in both cases, the pre_change_branch_tip / post_change_branch_tip hooks should work
<jelmer> glyph: see lp:bzr-testrunner for an example of a plugin which uses the pre_change_branch_tip hook
<GRiD> jelmer, i'm trying to make a blackbox test to reproduce bug 889872. since the simple tests in test_pack don't fail, i assume there needs to be a certain amount of data available. any idea how much that might be, based on the failures you saw?
<ubot5> Launchpad bug 889872 in Bazaar "not a valid key error" [Critical,Confirmed] https://launchpad.net/bugs/889872
<jelmer> GRiD: hi
<jelmer> GRiD: no idea, sorry - it happened on my bzr and samba repositories, both of which are pretty big
<GRiD> right ok. is there a way to generate a test repo during a blackbox test with that kind of data, or no?
<GRiD> even if there was, i assume it would be slow.
<jelmer> GRiD: perhaps there are other parameters you can tweak to make it happen earlier?
<jelmer> GRiD: I'm not really familiar with the index code unfortunately
<GRiD> jelmer, ok thanks. i'll play with it.
<GRiD> well i've duplicated it on a repack of bzr at least.
<poolie> hi all
<poolie> hi grid, jelmer,
<jelmer> hi poolie
<GRiD> hi poolie
<Noldorin> hi hi
<peitschie> mornin everyone :)
#bzr 2011-11-17
<mwhudson> root@shard:~# bzr branch lp:lava-deployment-script
<mwhudson> You have not informed bzr of your Launchpad ID, and you must do this to
<mwhudson> write to Launchpad or access private data.  See "bzr help launchpad-login".
<mwhudson> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/lava-deployment-script": no supported schemes
<mwhudson> is this just me being stupid?
<mwhudson> it seems a little strange
<poolie> that looks odd
<poolie> i guess that means 'there is no trunk registered'
<poolie> there is no project of that name at all
<poolie> obviously it's a crappy error message
<zyga-afk> mwhudson, you are silly
<zyga-afk> mwhudson, s/script/tool/
<mwhudson> zyga-afk: ah ofc
<mwhudson> poolie: oh right, because lp lookup is unauthenticated, i _might_ be referring to a private project, not one that does not exist
<mwhudson> hnnngh
<mwhudson> maybe i'll do some launchpad hacking tonight...
<wgz> back home
<lifeless> mwhudson: :)
<poolie> mwhudson, if you use a sufficiently new bzr it will not be doing a separate lookup
<poolie> the fact that it got the +branch url seems to indicate
<poolie> that the problem was later on
<mwhudson> poolie: even if there is no username set?
<mwhudson> i thought in that case it did
<mwhudson> (coz +branch urls don't work over http)
<poolie> ah you're correct
<poolie> :/
<mwhudson> i have this branch that does anonymous ssh though...........
<mwhudson> (if i do do some hacking tonight, it will be to make that branch check a ff)
<wgz> is staging.launchpad.net no longer updated? what's the current site for breaking stuff without bothering real people?
<lifeless> staging and or qastaging
<wgz> (staging says r11151 and main is r1429)
<lifeless> they are different branches
<wgz> * r14291
<lifeless> different mainlines even - they don't get pulled between
<wgz> ah, and qastaging is even newer, cool.
<wgz> okay, time to test idea quickly
<poolie> hi wgz
<poolie> lunch time
<GungaDin> How do I do bzr patch on Windows?
<jo-erlend> GungaDin :)
<jo-erlend> I was wondering if there is a way to see when a certain line in a source file was last changed somehow?
<spiv> bzr annotate
<jo-erlend> spiv?
<spiv> jo-erlend: http://doc.bazaar.canonical.com/bzr.2.4/en/user-reference/annotate-help.html
<spiv> And the GUI versions in bzr-gtk/qbzr (bzr gannotate/bzr qannotate) are quite nice.
<jo-erlend> spiv, nice! Thank you :)
<jo-erlend> I do my main development on my desktop. I push to launchpad. But I also have a laptop where I often do offline work. What's the best way to keep the laptop and desktop in sync?
<vila> jelmer: rough analysis posted for the 'bzr config' proposal: tl;dr: the old code wasn't checking the lock which was a bug
<vila> wgz: tell mgz: \o/ windows slave down to 11 failures !
<vila> wgz: I'm sure you will love to fix the 3 TestTreeTransform ones :-D
<mgz> morning all
<Sindikat> hi all! i and my co-worker want to work on our code using bzr. we don't want to have parent repos, but instead pull commits from each other. what's the best way to do that?
<vila> mgz: \o/ windows slave down to 11 failures !
<vila> mgz: I'm sure you will love to fix the 3 TestTreeTransform ones :-D
<vila> Sindikat: you will both need to read from each other with whatever protocol you want (ssh is preferred as it also allows writes)
<Sindikat> using 'bzr pull' or 'bzr push'?
<mgz> Sindikat: even with only two people, having one 'main' branch then both of you doing changes in feature branches is a reasonable way of working
<jelmer> vila: cool, I'll have another look
<vila> Sindikat: from there, it's easier if you use a specific branch as the one that is shared between both of you so all your merges will happen there
<mgz> vila: yup, getting there
<Sindikat> vila: it's not that distributed then
<vila> Sindikat: it's as distributed as any other workflow ;) It will allow a clearer sharing, but feel free to mirror each other branch if you're more comfortable with that
<Sindikat> i'm just not experienced with VCS :)
<vila> Sindikat: distributed imho mainly matters when it comes to being able to work offline, how source is shared (and how the shared history is handled) is more relevant
<vila> Sindikat: have a look at http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html
<mgz> hey, launchpad now has a cute(ish) down page
<Sindikat> i went thru tutorials, but smth isn't clear. i've did 'bzr init-repo project', in which i did 'bzr init trunk' on some server. now i want to download this trunk branch from server to my local computer. what should i do?
<mgz> Sindikat: once you've committed something to trunk, you just do `bzr branch .../server/path .../local/path`
<Sindikat> mgz: thanks! i'm currently going thru the guide, so i think i'll find out how to use bzr ;)
<mgz> how are you accessing the server currently?
<mgz> you want ssh set up for both of you for write access ideally.
<Sindikat> ssh
<mgz> cool.
<Sindikat> mgz: currently i already have a branch on server, but don't know how to get pushing to server working
<vila> mgz: hehe, yeah seen it, liked it :)
<mgz> Sindikat: once you have a repo like you can access via bzr+ssh://host/path/to/branch you pass that to any commands
<mgz> and bzr will remember the push and pull locations, so you can easily have a local mirror
<wgz> why is there a module-locale dict of handles in bzrlib.transport...
<wgz> vila: so, the bad news is all but the two already reported windows failures are basically random (but likely) races involving sftp
<wgz> the good news is I can actually repo them here from time to time
<wgz> oh, and the bt.test_transform ones are just exception stringifying
<wgz> but eg. bb.test_branch.TestRemoteBranch.test_branch_remote_remote was failing from time to time even before the big location handling regression
<wgz> <http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/503/> <- moment of boom
 * vila nods
<vila> module-locale dict of what ?
<wgz> vila: see <http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/593/testReport/bzrlib.tests.per_branch.test_stacking/TestStackingConnections/test_open_stacked_RemoteBranchFormat_default_/>
<wgz> I've caught that in pdb, and there's no .pack file, and the dict of streams is empty
<vila> yeah, this permissiondenied on .pack files never made sense to me
<vila> oh, you mean the _file_streams dict ?
<wgz> it's a race, I'm pretty sure, PermissionDenied is "other worker hasn't closed file yet", and this KeyError looks like "other worker didn't create/already deleted file"
<vila> someone loved globals...
<vila> hmm, so the cure may just be to catch/ignore that error ?
<wgz> I don't seem to have an open bug for this though
<wgz> <http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/593/testReport/junit/bzrlib.tests.blackbox.test_branch/TestRemoteBranch/test_branch_remote_remote/history/?start=100>
<wgz> or ?start=80 is better
<wgz> shows it went from randomly failing to always.
<wgz> vila: the races certainly seem to be hit much more often now, which isn't the location handling change
<wgz> and the path is certainly wrong in these cases
<wgz> but I think that's just cosmetic
<wgz> man, r6124 is a mess.
<vila> wgz: pqm switch :-/
<wgz> what tag did we say we'd use for test failures?
<wgz> 'test-falure' seems to be what you used last vila :)
 * wgz corrects the spelling
<vila> yup test-failure, keeping selftest for bugs related to the command itself
<vila> I don't tyops when typing tags, lp procides completion, yet another fullermd hoax
<vila> *provides
<vila> :)
<fullermd> I would never dream of trying to pin such a falure on you...
<jelmer> vila: so, I don't really want to block ~vila/bzr/config-command
<jelmer> vila: but I do think that the increased number of roundtrips is an issue we should fix
<jelmer> and the fact that this introduces VFS calls where previously they weren't necessary
<vila> well, it is probably more correct to say that these calls were not done at all and that was a bug
<vila> `bzr config` wasn't intended to work for remote branches in its first incarnation, the fact that it worked was lucky at best, buggy at worst
<jelmer> hmm
<vila> I think the *result* is now correct, don't let the better be the enemy of the good...
<jelmer> so I guess this is a fundamental issue with branch stacks/stores at the moment
<jelmer> not specific to this branch
 * jelmer ponders
<jelmer> vila: r=me, I'll work on a branch that fixes the VFS use for branch stacks
<vila> jelmer: thanks !
<vila> jelmer: hold on, on a second look, there is no lock involved there 8-/
<vila> jelmer: what triggers the additional calls is 'self.transport = branch.control_transport' which is a property for remote branches and accessing it triggers an ensure_real call ...
<vila> jelmer: talk about black magic...
<wgz> jelmer may be just the person to resolve that :)
<jelmer> vila: accessing any transport triggers _ensure_real I think
<vila> yeah, it seems :-/
<vila> jelmer: I'm looking at it, I'll let you know how it goes
<wgz> good job GRiD.
<vila> jelmer: but by the look of it, all remote branch usages seem to be impacted (I thought only `bzr config` was)
<vila> the cat being already out, better fix it asap
<wgz> GRiD: will try and suggest a less hairy bug next time
<wgz> :)
<vila> jelmer: crap, I remember now, RemoteConfig implements get_config_file but neither remove_option nor set_config_file,
<vila> jelmer: I'll file bugs for the missing ones and still look at plugging get_config_file
<jelmer> vila: I'm working on RemoteBranchStore at the moment
<vila> jelmer: ghaaa, there are Branch.get_config_file *and* BzrDir.get_config_file 8-( More code duplication ahead :-/
<vila> jelmer: you'll need a RemoteControlDirStore too...
<vila> jelmer: only load and save should need to be smartified, the IniFileStore.__init__ may need some massaging... It's a shame there is no easier way
<vila> bah, and external_url
<jelmer> vila: yeah, the fact that it takes a transport is an issue
<jelmer> vila: I'm wondering whether to add another subclass
<vila> The issue
<vila> _load_content and _save_content may be extracted from load/save, that's the part that needs a transport
<vila> I'd rather not duplicate nor change the logic around that
<jelmer> ok
<jelmer> class IniTransportStore(IniFileStore) ?
<vila> that leaves external_url but it should be trivial to re-implement so duplicating it is good enough
<vila> and then IniSmartStore ?
<jelmer> yeah, which also derives from IniFileStore
<GRiD> wgz :) no worries, i learned some internals which was the goal. admittedly at the expensive of my hacking time for my main os project
<vila> jelmer: sounds good
<vila> jelmer: it doesn't make a lot of sense that a *single* get_bytes() requires >10 hpss pre-requisite calls...
<vila> jelmer: there may be a simpler approach,
<vila> hmm, almost, nm
<nmb> I'm trying to work with the new colocated branches support, but I'm running into lots of UI bugs.
<nmb> Should I keep filing different bugs for everything I find?  Or is that just wasting Jelmer's time?
<wgz> if you're now on the latest bzr.dev rev, keep filing bugs.
<jelmer> nmb: you might want to wait until my current set of colocated branch MPs lands
<wgz> ah, there are a few more to go through, that's right
 * wgz needs to look at one of the reviews again
<nmb> I'm on the latest bzr.dev now, but I can certainly wait for MPs to land.
<wgz> nmb: if you could think/document the user side as you go, that would also be really helpful
<nmb> Perhaps I should be reviewing colocated proposals
<wgz> and any other thoughts about interface and so on.
<nmb> I would love to look into the documentation stuff
<nmb> switch is an interface I'm wondering about now
<wgz> nmb: <https://code.launchpad.net/~jelmer/bzr/switch-colocated/+merge/82340> :)
<nmb> Do we need "bzr switch file:,branch=other" or can we DWIM it to mean "bzr switch other"
<jelmer> nmb: see the link wgz just posted
<wgz> using -b will do the right thing when that change lands.
<nmb> Got it.  Very nice.
<nmb> If I were reviewing that MP, I'd like to see an updated docstring for "bzr switch" in the same revision
<wgz> hm, I'm torn on that.
<wgz> Currently `bzr help switch` does cover various subcases, but I think we tend to put too much of that in the main command help currently.
<wgz> ...and I once again spend too long typing my sentence
<wgz> and thus start and and with the same word...
<wgz> *and end
<nmb> I think that's going to be a generic issue with the overall program of integrating colocated branches...
<jelmer> nmb: just reported bug 891671 which you seem to be hitting as well
<ubot5> Launchpad bug 891671 in Bazaar "active colocated branch when it is being created in empty bzrdir" [High,Triaged] https://launchpad.net/bugs/891671
<nmb> Do we mention them in every docstring?
<wgz> yeah.
<nmb> Yep, your 891671 is something I was about to file on.  See also 891667 for a separate UI bug.
<nmb> I've got to run, but let me say that the reason I'm running into these bugs now is because I'm trying to make bzr-colo work in native colocated workspaces...
<jelmer> nmb: cool!
<nmb> I'll be working more on that later today, but if I should wait for some more particular branches to land, then I can wait.
<jelmer> with a bit of luck those branches will have landed by then
<jelmer> wgz: did you see my reply on https://code.launchpad.net/~jelmer/bzr/branch-url-identifies-branch/+merge/82341 ?
<wgz> jelmer: yes, that's what was refering to earlier
<wgz> the main remaining confusion, if you're saying segement parameters are (percent escaped) url path sections
<wgz> is that bzrdir is still dealing in utf-8 'branch names'
<wgz> it's unclear where the lines are drawn in the code between:
<wgz> * unicode branch name from user input
<wgz> * ???
<wgz> * url encoded segment parameter value
<jelmer> wgz: bzrdir deals with unicode branch names in its public API
<wgz> the colo switch mp is nice because it's clear where transition happens, and it's all in one place
<jelmer> wgz: only its helper for reading the branch-list file uses utf8
<wgz> but really utf-8 and not %-encoding?
<jelmer> yes
<jelmer> wgz: I can change that to be unicode too, but that would mean needlessly decoding/encoding the branch names there
<wgz> we do a lot of that currently. :)
<jelmer> wgz: not a good reason to add more..
<jelmer> especially as this is all implementation-specific, it's not exposed in the API
<wgz> so, ideally when reading code anywhere in bzrlib it should be clear what type of the variable is
<wgz> having names of things sometimes unicode, sometimes utf-8 bytes, sometimes url sections, is bad
<wgz> which is an existing problem. _read_branch_list/_write_branch_list is pretty localised at least, it's just a pain for callers to have to worry about encoding
<jelmer> wgz: I can at least at comments about it in the docstring I guess..
<wgz> I think all your bits are now correctly documented at least.
<wgz> okay, you now have like, five things to land. go nuts (in the correct order :)
<jelmer> \o/
 * jelmer goes wild
<jelmer> wgz: thanks again for the reviews
<wgz> ...and five new hpss branches needing review... >_<
<jelmer> wgz: btw, are you still in a weekend mood or something?
<nmb> wgz: and you're not even the PP ;)
<vila> nmb: he;s warming up for next week ;)
<wgz> have been trying to resolve babune issues today, and 'w' doubles up as 'windows'
<nmb> I'll stick to filing mountains of bugs
<jelmer> wgz: ah :-)
<nmb> jelmer: what is the way to find out the current checked out branch?  My abstraction in bzr-colo needs access to that.
<jelmer> nmb: BzrDir.get_branch_reference()
<jelmer> nmb: BzrDir.get_branch_reference(name=None)
<nmb> jelmer: Is that a URL or a branch object?
<jelmer> nmb: it returns a URL
<wgz> dammit, we *did* have one already, bug 788130, how did I miss that vila...
<ubot5> Launchpad bug 788130 in Bazaar "Intermittent test_branch_local_remote failure on windows: permission denied on .pack file" [High,Confirmed] https://launchpad.net/bugs/788130
<vila> wgz: you even commented on it ;)
<vila> this rules out any path mangling right ?
<wgz> and referenced it from my mp...
<vila> well, at least related to the big boom you referred to earlier
<wgz> yeah, this is a pre-existing issue, but something have made it much more prevelent
<wgz> like not the path changes, but the other server stuff that landed subsequently (while the path changes were masking everything)
<wgz> *likely
<vila> :-/
<wgz> jelmer: in the tests for splitting segments, can you explain these assertions to me?
<wgz> <http://paste.ubuntu.com/741413/>
<wgz> I've got a fix for bug 842233 that I think preserves your intentions, but doesn't pass those checks
<ubot5> Launchpad bug 842233 in Bazaar "InvalidURL from tests for local_path_from_url on windows" [Medium,Confirmed] https://launchpad.net/bugs/842233
 * jelmer looks
<jelmer> wgz: it looks like an artefact of the way split/join are used in split_segment_parameters
<jelmer> wgz: and I can't think of a reason why that slash would be necessary
<wgz> cool.
<wgz> don't think we didn't see you sneaking up the HPSS calls count there jelmer :P
<jelmer> wgz: (-:
<jelmer> wgz: fortunately rmbranch-colo failed in pqm
<wgz> yeah, I saw it was going to and put some more comments in the mp
<wgz> same basic confusion
<wgz> strip_trailing_slash operates on urls, local_path_from_url returns a path, therefore:
<wgz> strip_trailing_slash(local_path_from_url(path))
<wgz> is invalid.
<wgz> the tests also break on windows, file:///a isn't valid.
<wgz> but something like this is needed, otherwise I get failing tests due to urls like:
<wgz> chroot-13432:///,key=val/
<wgz> because some other parts of url handling are *adding* a trailing slash, which then changes the meaning of urls with segments smuggled on the end
<wgz> it's messy.
<wgz> the boundaries between local paths, urls, and urls-plus-segments just aren't clear enough
<jelmer> wgz: my changing of strip_trailing_slash was just moving it up the call stack one level IIRC
<jelmer> and just used for the file part of urls IIRC
<wgz> it moved it from inside to outside
<wgz> was file_relpath(strip_trailing_slash(url_base), strip_trailing_slash(url))
<wgz> became strip_trailing_slash(local_path_from_url(url_base)) ...etc
<wgz> just switching that back means your test_remove_colo fails again though.
<wgz> strip_trailing_slash needs to be read as 'strip_trailing_slash_FROM_URL'
<jelmer> wgz: I'm not sure I follow - aren't the bits we're looking at only used for the file path of URLs?
<bignose> in Debian's âbzr-gtkâ source package version 0.100.0+bzr737-2.1 the ânautilus-bzrâ package has been dropped
<bignose> because Debian's Nautilus is now GNOME 3
<bignose> does that mean the Nautilus integration is now gone? can we expect it to return soon?
<bignose> <URL:http://bugs.debian.org/644689>
<ubot5> Debian bug 644689 in nautilus-bzr "nautilus-bzr: Please transition to nautilus 3 and GObject introspection" [Serious,Fixed]
<jelmer> bignose: hi
<jelmer> bignose: somebody needs to update it; it's on my list of things to do, but not very high
<bignose> jelmer: howdy
<bignose> an earlier changelog entry explicitly logs the change âSupport nautilus 3.0.â, so why did the NMU remove the package for not supporting Nautilus 3?
<jelmer> bignose: it's not just nautilus 3, it's also moving to pygi instead of pygtk
<jelmer> hmm, though it looks like that porting work has in theory also been done
<jelmer> either way, somebody needs to test nautilus-bzr with nautilus 3, fix where necessary and reupload
<jelmer> the removal of nautilus-bzr was done by the GNOME team, not by the bzr maintainers
<bignose> jelmer: but they were correct to do so, yes?
<jelmer> bignose: yes, that was before we had switch bzr-gtk in unstable to the gtk3 version
<MrSmile> Hi people! I am facing a small problem in python with bzr.
<MrSmile> which class and method I have to call to create a workingTree is not avaiolable through python?
<MrSmile> any ideas?!
<wgz> MrSmile: see doc/developers/overview.txt then the relevent docstrings, and referring to bzrlib/builtins.py for what the bzr script commands do can also be useful
<wgz> otherwise, you'll need to ask a more specific question, ideally saying what you're actually trying to do and what code you've got currently
<MrSmile> yes, if I use the bzr script commands, I will have to change the working directory of python, which I really don't want.
<MrSmile> So far I get everything handled.
<MrSmile> I wrote a try, catch routine that if I receive the exception "errors.NotBranchError", that I create there the workingDirectory throuh python with the bzrlibs.
<MrSmile> this is all about.
<wgz> jelmer: I'm not completely clear what you mean, but we're not just dealing with urls here, file_relpath converts the url to a filesystem path
<MrSmile> i mean, path
<MrSmile> filesystem path, sorry.
<wgz> MrSmile: post your code? I don't understand what you're actually trying to do :)
<MrSmile> okay, I do it now.
<wgz> (reading the docs for the basics is a good start regardless though)
<MrSmile> http://pastebin.com/raw.php?i=sYSxUqtC
<MrSmile> I want in the Exception Block, to create the branch branch in the desired directory in the filesystem.
<MrSmile> this is my main problem.
<wgz> okay, "open" is for existing branches.
<MrSmile> exaclty!
<MrSmile> this is a routine, that if one exists, I can work further.
<MrSmile> now, it is like the 1st run, if there is no branch in that directoy.
<MrSmile> i want python with the bzrlib to create one for me in this directory, in the exception block.
<MrSmile> which I did manually by calling through python the console application "bzr init", which is not the clean and nice way.
<MrSmile> any idea to make the "bzr init" command, through the bzrlib ?!
<wgz> okay, you have two options.
<MrSmile> yes, please
<wgz> both of which involve you looking at cmd_init in bzrlib/builtins.py so I suggest you do that now
<wgz> the first is calling using the cmd_init class
<MrSmile> where is the class?!
<wgz> the second is going through the steps it does yourself, which basically involves getting a bzrdir then calling create_branch (and then create_tree)
<wgz> ^line 1864, use your text editor's find
<MrSmile> okay
<ccxCZ> jelmer: ping
<ccxCZ> or jam, I have few questions about bzr-service
<MrSmile> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.bzrdir.html is a module
<MrSmile> and BzrDir want's paramters, like transport...
<MrSmile> have a nice day.
<MrSmile> bye
<wgz> hm, the bzrlib api claims another victim.
<wgz> should have just said "pass the dir as the third param to the subprocess call"
<wgz> using bzrlib at all requires a level of ability in python, and there are pointless speedhumps still
<jelmer> ccxCZ: hi
<ccxCZ> hello
<poolie> hi jelmer
<poolie> wgz, another victim trying to write a hook?
<poolie> we should really do a general mapping to shell things
<ccxCZ> I'm quite interested in in bzr-service as bzr startup is insanely slow (about a second) to be used to decorate a prompt
<ccxCZ> but I don't see the protocol documented anywhere
<poolie> i suspect only in the code
<poolie> for that plugin
<wgz> no, he just wanted something nicer than subprocess.call(["bzr", "init"]) but nothing any more complex
<poolie> you can talk to jam on here who wrote it
<jelmer> ccxCZ: one second is quite slow though
<poolie> ah
<poolie> an intermediate command layer wbn
<ccxCZ> yeah, called three times to get all info I need
<wgz> apart from several quirks using cmd instances could work.
<ccxCZ> and bzr shell insists on connecting to remote server when ran on bound branch
<wgz> and at least is then a path to taking those abstrations out so there's less reopening and reclosing and relocking and so on
<jelmer> ccxCZ: jam is indeed the person to talk to. I've run bzr-service a couple of times in the past but am not familiar wiht its internals
<ccxCZ> how do you use it then? it needs some other endpoint to talk to
<poolie> wgz, i think perhaps something a bit separate than command instances
<poolie> since they have a fair bit of commandline stuff
<poolie> possibly a good way to tackle it is to start writing tests at this level
<jelmer> ccxCZ: "bzr start-service"
<ccxCZ> hmm, I see the C client, but since my shell can talk to tcp & unix sockets I'd rather avoid unnecessary exec()s
<ccxCZ> no usage instructions in the client either
<wgz> poolie: <lp:~gz/+junk/call_bzr_init> is as simple as I can make using a cmd instance
<jelmer> ccxCZ: it's probably best to talk to jam
<jelmer> ccxCZ: it's been a long time since I touched bzr-service, and that was only briefly
<ccxCZ> okay
<jelmer> ccxCZ: there are some alternatives, if you're interested in hearing about those..
<ccxCZ> indeed
<ccxCZ> go on
<jelmer> ccxCZ: you could write a trivial bzr plugin that does the three things you need at once, and then exits
<jelmer> ccxCZ: without loading plugins the overhead of running "bzr ls" is 0.2 seconds here
<jelmer> ccxCZ: what version of bzr are you using, and what plugins?
<jelmer> and what exactly do you need for your prompt?
<ccxCZ> info, revno, stat
<poolie> gz wow i wish it was faster to get to just seeing the code in the web ui
<ccxCZ> the thing is the behavior is dependent on the output of info (if the branch is standalone, bound or lightweight co)
<ccxCZ> http://paste.pocoo.org/show/509443/
<jelmer> ccxCZ: do you have an example of what your prompt looks like?
<wgz> poolie: I should have just given my local sever url, lack of syntax highlighting and all :)
<poolie> so...
<poolie> some of that i blame python :)
<poolie> __main__ dance etc
<ccxCZ> it's styleable, I wrote the bzr version vcs_info that is now bundled with zsh
<ccxCZ> poolie: I believe most of it will be python
<poolie> but we could move some more of that into initialize() and
<wgz> poolie: yes, our fault is really the with block, but that's pretty bad
<poolie> i think probably we want bzrlib.midlevel.init(argv[1])
<poolie> something like that
<jelmer> ccxCZ: ah, so I guess a plugin won't really work for you then?
<wgz> having to call builtin_command_names() for the side effect of calling the (private) _register_builtin_commands() is particularly good.
<ccxCZ> it would help, but I think using resident process would be much neater
<ccxCZ> it could also speed up regular zsh work
<ccxCZ> jelmer: basically the thing is that I have home under bzr, and I want my prompt scream at me if I have uncommitted changes
<ccxCZ> but I have to first check that I don't call stat on lw checkout that is networked
<ccxCZ> the current vcs_info _could_ be rewritten as a bzr plugin, though I anticipate some resistance depending upon unofficial plugin in a script bundled with zsh
<ccxCZ> resistance to*
<poolie> perhaps you can merge it to bzr
<ccxCZ> that would be great
 * ccxCZ reads what the vcs_info script actually does
<ccxCZ> I think an info-like command that prints data according to supplied template would work, if one can supply conditionals so we can eliminate connecting to remote repositories
<ccxCZ> here's the zsh script btw http://wpr.cz/ccx/paste/2011-11-17/0.html
<ccxCZ> or maybe do it the other way around, is there way to tell branch type without executing bzr?
<poolie> yeah, you can just look in .bzr
<poolie> for example
<poolie> is there a .bzr/repository?
<poolie> is there a .bzr/branch
<poolie> is there a .bzr/branch/location
<poolie> that may be faster than starting python
<poolie> and pretty feasible to do in zsh
<ccxCZ> indeed, but I haven't seen any comprehensive documentation on the layout of .bzr, so if you point me to one I can implement that
<ccxCZ> btw I timed python and bzr startup
<ccxCZ> time: 0.17s user 0.03s system 98% cpu 0.208 total  python -c 'print "hello"'
<ccxCZ> time: 0.75s user 0.15s system 98% cpu 0.909 total  bzr --version
<poolie> sure
<poolie> we can cut it down more
<ccxCZ> if we implement bzr info in shell I already got 30% speedup
<ccxCZ> so that's definitely worth it
<poolie> ccxCZ, if you want just the same output probably the best thing is to look at the info code
<poolie> but basically
<poolie> .bzr/checkout - there is a working tree
<poolie> .bzr/branch - there is a branch here
<poolie> .bzr/repository - a repository
<poolie> .bzr/branch/location - bound to a branch stored elsewhere
<ccxCZ> so lightweight checkout <=> !.bzr/branch && .bzr/branch/location
<ccxCZ> wait
<ccxCZ> that does not make sense
<poolie> [-f .bzr/branch/location && ! -d .bzr/repository]
<ccxCZ> okay
<ccxCZ> that should be all the info I need
<ccxCZ> is revno easilly reachable?
<ccxCZ> .bzr/branch/last-revision it seems
<ccxCZ> which is missing in bound branches
<fullermd> It should be present in bound branches.  It would be missing in light checkouts.
<jelmer> ccxCZ: newer versions of bzr will be even quicker
<ccxCZ> fullermd: you are correct
<jelmer> bzr --version  0.25s user 0.03s system 89% cpu 0.310 total
#bzr 2011-11-18
<poolie> hi?
<poolie> i wonder if pqm is just not sending error messages at all
<poolie> ooh, or maybe there is a size limit
<vila> hi all !
<poolie> hi there vila
<poolie> i liked your option expansion patch
 * vila happily shudders :)
<vila> the HPSS glitch found by jelmer is a serious (and depressing) issue which was well hidden behind a @property that took me off-guard
<vila> hopefully it can addressed with some additional store classes (jelmer said he was looking at it)
<vila> s/can/can be/
<vila> ha ! pylzma fmp finally landed, poolie, what was the issue ?
<poolie> i think it made every test fail in the original version
<poolie> and that was so much bad news the mta dropped it
<vila> hehe
<mgz> morning all
<vila> mgz: hey !
<deni> hi everyone
<deni> i have a question about chmod and bazaar
<deni> afaik when i change the file permissions bazaar lists that as a change
<deni> is there any way to avoid this? to tell bazaar to ignore file permissions changes
<deni> ?
<mgz> bzr only tracks the excecutable bit
<mgz> you can either just not worry about bzr telling you that has changed, or er...
<poolie> o/ mgz
<mgz> there were some bugs involving windows/cygwin where the excecutability was changing all the time, but most things shouldn't be changing it
 * mgz waves at vila and poolie
<vila> pqm failure on bzrlib.tests.test_test_server.TestTCPServerInAThread.test_handle_request_closes_if_it_doesnt_process(TestingTCPServer) :-) :-/ :-(
<poolie> so new buildd stuff is almost but not actually deployde
<mgz> it's teasing everyone :)
<deni> mgz: yeah i just found that bug
<mgz> deni: ah, is that what you were running into? have you got the bug number and done +affectsmeto as well?
<poolie> incidentally my affects count across dupes is now live
<poolie> the data is a bit more representative
<mgz> that's good, had wondered why it didn't seem to do that.
<deni> mgz: i'm still investigating what's actually going on
<mgz> deni: do report when you find out.
<vila> pfew, finally, sanity restored in mail inboxes
<deni> mgz: fixed the issue...it was an error on out part...seems unrelated to that bug
<mgz> deni: cool. I'm still curious about the details :)
<mgz> argh, transports are a mess.
<vila> mgz: as far as path encodings are concerned you mean ?
<mgz> the url handling is all over the place.
<mgz> they all do their own things with string parsing, and randomly add and remove trailing forward slashes
<vila> yeah :)
<vila> some tests may also enforce some bugs here
<mgz> must resist the urge to rewrite, and just fix the current bug first
<vila> well, bugs, practices at least
<mgz> certainly bugs too.
<mgz> okay, done PathFilteringTransport, LocalTransport, ConnectedTransport... next failure is MemoryTransport
<vila> what's your current bug ?
<mgz> bug 842233 / landing jelmer's rmbranch-colo mp
<ubot5> Launchpad bug 842233 in Bazaar "InvalidURL from tests for local_path_from_url on windows" [Medium,In progress] https://launchpad.net/bugs/842233
<mgz> basically the logic is bogus but happens to mostly work
<vila> yeah, there is a pattern there: one feature implemented in many different places, mostly tested instead of one feature implemented in a single place, fully tested
<mgz> it's really just existing debt from all the different quirks to url handling
<mgz> in some ways it's better to land a change that needs it cleaned up and break things, so it's clearer what the requirements for the refactoring are
<vila> same thing :) The debt grows because it's in many different places and the short term gains reinforce the pattern
<deni> mgz: what can i tell...user error! :) naturally i jumped to conclusions and blamed bzr instead of my collegue :)
<vila> deni: no worries, but understanding what happened and why bzr presented a confusing output is what we're trying to understand ;)
<vila> bah, mgz syndrom... understanding at both start and end of the sentence...
<mgz> :D
<vila> slangasek: ping, I like to make sure I understand when do-po-merges is used, do you have a few minutes for me ?
<deni> vila: he chmoded the whole directory manually, and that is fine, i mean it's fine that bzr tracks that/
<deni> i was thinking that it had something to do with the windows clients when bzr showed him that he has over 2000 filed modified :)
<vila> deni: ha ok, great, that all I wanted to know
<deni> :D
<deni> sorry for the hastle
<deni> still i would be interested to know is there a feature planned that would disable file permission changes?
<deni> *disable the tracking of
<vila> not that I know of
<vila> from a high level, bzr tracks only the executable bit because it's the only that really makes sense from a VCS point of view
<vila> and has a meaning on all platforms
<vila> the other bits are the job of install scripts generally not the VCS
<deni> i have a lot of .bat and .sh files.....windows doesnt care about +x on bat files
<deni> afaik
<deni> but yeah, i get your point
<mgz> okay, lame fix now done.
<mgz> I just need to go out briefly, will propose when I return.
<vila> Riddell: ping
<vila> Riddell: does 'po4a' rings a bell ? What's the relationship with a 'doc/po4a' dir and the 'po' dir in the same package ?
<Riddell> vila: nope, don't think I've herad of it
<Riddell> heard
<vila> k, thanks
<Riddell> seems like po4a has tools for converting other file formats into po
<deni> ah....the latest xkcd....so true
<deni> :)
<Darxus> Launchpad just emailed me that a build failed with "bzr: ERROR: no such option: --allow-fallback-to-native" - https://launchpadlibrarian.net/85424088/buildlog.txt.gz
<Leon_Nardella> Is it appropriate to discuess bzr-builder issues here?
<PsyberS> is there a way to 'undo' a bzr unshelve? aka move the state back to how it was before that command?
<PsyberS> i apparently had a modified file, unshelved, it failed to merge *some* parts into that file but merged others and now im quite lost as to what was what
<wgz> Leon_Nardella: yes
<wgz> PsyberS: unfortunately not
<wgz> merges with conflicts should make a .OTHER file, not sure if unshelve also does
<PsyberS> wgz: it doesnt, that i can see but it did leave the old shelf backup file .~1~ there, so at least i can see what the shelved version looked like (and the current) and figure it out manually
<Leon_Nardella> wgz, I have a recipe in Launchpad that won't build. In the build log there's an error message saying that {git-commit-id}, which I'd like to use in the deb-version, couldn't be expanded. Any ideas?
<wgz> ah, I see you filed bug 892358
<ubot5> Launchpad bug 892358 in bzr-builder "Bzr-builder doesn't expand {git-commit}" [Undecided,New] https://launchpad.net/bugs/892358
<wgz> bug 891880 also seems relevent
<ubot5> Launchpad bug 891880 in Bazaar "mentions new substitution variables even when recipe format doesn't support them" [Medium,Triaged] https://launchpad.net/bugs/891880
 * Leon_Nardella taking a look at 891880
<Leon_Nardella> Yup, seems relevant.
<Leon_Nardella> I tried changing the format to 0.4, but Lauchpad didn't accept it.
<wgz> also this thread on the udd list:
<wgz> <https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2011-November/000981.html>
<wgz> particularly <https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2011-November/000995.html>
<wgz> so, I think the state from this morning, was poolie said the new builders are nearly but not quite deployed now
<wgz> and I guess your error stems from that
<Leon_Nardella> Hmm.. Guess I should just relax and wait a bit?
<wgz> so... with luck it'll work on monday :D
<Leon_Nardella> Cool. :)
<wgz> right, dinner for me.
<Leon_Nardella> See ya
#bzr 2011-11-19
<slangasek> vila: strange, I completely missed your ping before.  Did my answer on the bug suffice?
<vila> slangasek: good enough for now, I'll prototype something and we can discuss refinements from there
<slangasek> vila: ok, cheers :)
<sanbar> I have the the directory structure /code, /code/language1, /code/language1/project1, /code/language/project2, etc.  I wish to create a repository in /code, so I used init-repository on /code
<sanbar> However, I wish to create my branches in the project directories - do I use init-repository on /code/language, or init (to create a branch on it)?
<sanbar> /code/language1*
<sanbar> ie, can you have repositories within repositories?
<jelmer> hi sanbar
<jelmer> sanbar: you can nest repositories, but only the "closest" repository will be used
<jelmer> i.e. if you create a repository in /code and a repository in /code/language1, and then create a branch in /code/language1/project1
<jelmer> then all revisions will be stored in /code/language1
<sanbar> does it do any good to have nested repositories then at all?
<sanbar> jelmer: ^
<sanbar> (they do seem to be "browsable" using the gui utils, so maybe that is the only benefit?
<sanbar> Oh, I get it - you can mix branches/repositories in the "parent" repository.  That would be the benefit, then ...
<sanbar> (since it would be "closest" for a branch immediately underneath it ...)
<sanbar> jelmer: ^
<jelmer> sanbar: sorry, was away for a bit
<jelmer> sanbar: no, there isn't much use in having nested repositories
#bzr 2011-11-20
<Noldorin> hey folks
<Noldorin> jelmer
<alansaul> Hey guys, I've got a problem, I pushed a branch onto my main trunk repo, overwriting the entire revision history of the trunk
<alansaul> How can I get this back? My trunk is now has the same revision history as my branch! Bzr push doesnt seem to be incremental!
<alansaul> Anyone any ideas?
<alansaul> :( I don't want to develop anymore incase I can get it back somehow!
<alansaul> seems really flakey if there is no way to get it back!
<beuno> alansaul, hi
<beuno> you did push --overwrite?
<alansaul> beuno: Hey :)
<alansaul> Ermm, no, unless that is the default
<beuno> it isn't
<alansaul> I had a branch say x
<alansaul> of trunk
<alansaul> made lots of changes
<beuno> so you went from revision 120 to revision 2
<beuno> something like that, yes?
<alansaul> merged trunk into x to make sure there was no conflicts
<alansaul> and then did bzr push x serverrepo/trunk
<alansaul> beuno: yeah
<beuno> right
<beuno> so here's what happenes
<beuno> *happened
<beuno> trunk was at revno 120 (lets pretend that's the revno)
<alansaul> yep
<beuno> your local branch was at revno 10
<alansaul> yep
<beuno> you merged in trunk, so you got revision 11
<beuno> and pushed that
<alansaul> yep
<beuno> which made trunk 11
<alansaul> yep
<beuno> in order to prevent that in the future
<beuno> what you do is have a mirror of trunk locally
<beuno> and merge your branch into trunk
<beuno> and not the other way around
<beuno> and then push that
<alansaul> beuno: Yeah i realise that now :)
<beuno> there's also a config value that will prevent revisions to be removed
<beuno> so
<alansaul> or merge trunk into x, then x into trunk
<alansaul> then push
<beuno> if you do a "bzr uncommit" on trunk, I think that'll bring it back to the previous state
<alansaul> oooo
<alansaul> hmmm its asking if I want to remove the revision 11
<beuno> yes
<alansaul> hmmm, my local trunk isnt up to date with my server trunk
<alansaul> should i update first yeah?
<beuno> sure, get them both in the same state
<alansaul> (just don't wanna mess this up to some sort of irreversable state!)
<beuno> right
<beuno> I'd back up everything
<beuno> just in case  :)
<alansaul> hmmm
<beuno> just copy over the folders
<alansaul> okay so make a copy of my local trunk and branches just somewhere else locally?
<beuno> yes
<alansaul> okie
<alansaul> okay whilst its copying, ill ask a few questions :P
<alansaul> so uncommit will remove commit 11? and will go back to 120?
<fullermd> I'm not sure uncommit is really what you want...
<alansaul> Oop... holding
<beuno> fullermd, no?  unless he has a previous copy of trunk, un-mangled, not sure how else to get there
<fullermd> You can just make one.
<fullermd> uncommit would just back you up to the rev before you merged trunk.
<fullermd> Poke at log to find the previous head rev, make a new branch from that, push (--overwrite) over trunk, then go back to the question of merging in the local branch.
<alansaul> I want to bring the trunk back to how it was before it was pushed ontop of
<fullermd> (previous _trunk_ head rev that is)
<alansaul> fullermd: Hmm think you lost me there
<fullermd> (sorry, I'm in the middle of some stuff ATM...   don't have time for details for a bit  :|  )
<alansaul> Aww
<alansaul> my bzr log has branch nick: trunk up to 18 then branch-x from 18 to 24
<alansaul> But my trunk was on commit 48 or something before i pushed ontop of it
<fullermd> Important thing is: Don't Panic.  As long as push didn't require --overwrite, you've never lost anything.  It's just been rearranged.
<alansaul> Hmm, well that sounds promising! I just cant find anywhere in any logs which have a revno of 48
<fullermd> 'll have time in 15 or 20 minutes or something if nobody else elaborates before then.
<alansaul> fullermd: Sweet, I can wait
<alansaul> fullermd: Thanks :)
<fullermd> If you're bored 'till then, reading http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering and http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevHandling may help you understand what's happening.
<alansaul> Working on it :)
 * jelmer waves
<thomi|work> Hi - does anyone have any more information on bug #820805 ? I have run into this issue on a workmate's laptop and can't seem to work around it with any of the fixes mentioned in the bug report.
<ubot5> Launchpad bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Confirmed] https://launchpad.net/bugs/820805
<alansaul> fullermd: Okay read them :) Let me know when your back :)
<jelmer> thomi|work: mgz has done some research into those bugs
<jelmer> thomi|work: he posted a summary to the list a week or so ago
<wgz> I've got a patch for pageant to send as well, the pain is I'm struggling to test it
<wgz> as much as I dislike unix permissions, windows security things are far more painful.
<thomi|work> wgz: I don't suppose you have a replacement .exe I could test for you?
<thomi|work> I gotta skip out for lunch, but If there's anything I can do to help I'll give it a go.
<wgz> I do, it's 32 bit though.
<wgz> thomi|work: http://float.endofinternet.org/temp/pageant_dbg.zip
<wgz> it's built with the debug stuff enabled so pops up a console with info
<wgz> if you need a 64 bit version I'll look at cross compiling, but can also cc you on the patch (their list doesn't seem to be public)
<Noldorin> hi poolie
<poolie> hi Noldorin
<fullermd> alansaul:  OK, yeah, that was sorta like 15 or 20 minutes...
<alansaul> fullermd: Lol thats cool thanks for coming back :)
<Noldorin> poolie, saw your response to my bug (suggestion) about download types, etc. happy to talk about it here if you like
<alansaul> I have to go reasonably soon though!
<fullermd> So, did that reading illuminate anything for you?
<alansaul> so I need to find the revid that relates to revno 48 and revert back to that?
<alansaul> its still there somewhere
<fullermd> Yah.  Or the new revno, even.
<fullermd> Look at `bzr log -n0`.  Your latest rev is the one that merged trunk, right?
<fullermd> So the old head of trunk would be the first indented rev under that.  It'll have a dotted revno of some sort.
<alansaul> naw the last one isnt the merge
<alansaul> I have a revno: 16.2.1 [merge] though
<alansaul> but its a few revisions behind, im on revision 24
<alansaul> If I can get this trunk back to the state before though, I can merge in the changes i made in the branch properly
<fullermd> Well, wherever it was.  You merged in trunk, before pushing over it.
<fullermd> I'm presuming you haven't done anything on trunk since (nor anybody else); in that case things get messier.
<alansaul> I don't think so no
<fullermd> So whichever your 'merge in trunk' rev is, the first rev indented under that is the rev that was at the time the head of trunk.
<alansaul> my branch x is basically a more up to date version than the trunk, but i just want to merge it into the trunk without losing all the revision history the trunk had
<fullermd> Mmm.  Well, let's glance back a moment.  It's not lost, it's just not on the mainline (so log won't show it unless you use -n0).  Does that matter?
<alansaul> I think I want to revert back to revno: 16.2.1 [merge]
<fullermd> Only thing that gives me pause there is that that revno implies that it was only a single rev merged (e.g., trunk had only grown one new thing).  Is that right?
<alansaul> Ummm im not sure what you mean?
<alansaul> There is a further indented bit
<alansaul> revno: 16.1.29
<fullermd> Mmm.  Is this something you can share?
<alansaul> My revno: 16.2.1 [merge] has a commit comment of Merged data model with trunk, only one failing test (due to users not being implemented yet)
<fullermd> i.e., a public branch I can clone and look at?  Or a log you can substantially pastebin?
<jelmer> hmm, I think I got carried away by the awesomeness of HPSS there for a second..
 * jelmer goes back to spiv's branch
<jelmer> (I'm not sure what made my inexplicably scared of the HPSS subsystem earlier, but it's really nice once you get used to it)
<jelmer> s/my/me/
<wgz> yeah, going a bit overboard jelmer :)
<wgz> one complaint, adding more things that bz2 on the fly is kinda ugh
<jelmer> wgz: what would you like to do instead?
<wgz> practically, or ideally? :)
<wgz> I'd like to see numbers for size/performance vs zlib
<jelmer> both :)
<wgz> ideally, sendfile.
<jelmer> wgz: sendfile doesn't seem ideal bandwidth-wise
<jelmer> wgz: you have a point bout zlib vs bz2 though
<jelmer> *about
<poolie> hi all
<poolie> jelmer, i like seeing all those patches
<poolie> you should run it under Judge :)
<poolie> you might need to patch it to add some more options, like for the number of times
<poolie> to run the test
<poolie> i really hope to go back to memory consumption soon
<poolie> i did some fun lp hacks on the weekend though
<wgz> at least for initial branching, I've measured smaller transfer, and smaller resource usage with dumb transports over smart ones, because of the recompression/overhead
<wgz> being able to pick out just the latest changes is something where smart and recompress does do better than splatting bytes, but wanting to get a whole repo isn't uncommon either
<jelmer> hi poolie
<jelmer> poolie: Yeah, I should give that a try, at least for some of the methods where performance is relevant.
<jelmer> wgz: at least for the things I've tried adding smart methods had a significant impact. I haven't compared with zlib though
<spiv> jelmer: :)
<poolie> hi spiv
<jelmer> poolie: btw, thanks for being so persistent in trying to separate launchpad-buildd from its big siamese twin :)
<jelmer> hey spiv
<poolie> it's kinda funny
<poolie> just when you think it's deleted it rises back up like a zombie
<poolie> do you guys really like the subunit test output?
<poolie> i'm not finding it very easy to deal with
<wgz> it makes a massive difference for anything doing operations on a remote repo
<jelmer> poolie: :)
<poolie> eg subunit crashed filtering this failure
<jelmer> poolie: I think the old subunit stuff was kinda nice to read. The new bits (with mime encoding) are harder to read, but alright after applying a filter. Also, testrepository ftw :)
<wgz> but for mirroring the data it can be suprisingly poor
<wgz> poolie: not much. are we talking pqm or in general?
<wgz> it has definite robustness issues.
#bzr 2012-11-12
<lolek> hello all
<mgz> morning!
<lolek> erm... guys... i'm a bit confused... few days ago we're looking for some new versioning system. The problem was that one of the developers is using M$ platform. From what i've read bzr has got better support for m$ than for example git, but after few days i see that: bzr-eclipse plugin is... not maintained since 2008 o.O!, bzr-svn plugin doesn't have maintainer also... and my question is ... what's up...? is bazaar really a good alternative for versioning s
<mgz> lolek: you hit the length limit
<lolek> mgz: erm.. what was the last word you got ?
<mgz> it was probably the last bit, "for versioning s"
<mgz> anyway, in my experience, yes, it is, but not all plugins are as well maintained as others (bzr-svn is actually pretty well cared for, jelmer has just switched job recently)
<mgz> and the future is a little uncertain, but people do care about bzr
<lolek> ok here is the last part
<lolek> system for commercial usage ? i know.. i see it's working ok for canonical, but for me ok.. bzr-svn i can live without that, but bzr-eclipse ?
<mgz> so, people have very different attitudes to ide intergration
<mgz> the basic issue there is you need someone who uses that ide to work on the plugin, it's not something someone else can easilly pick up
<lolek> well i understand that
<lolek> what i can say now, that the bzr-eclipse plugin is missing just one thing for me/us... the compare to specific revision/url
<lolek> that's all
<mgz> lolek: then it's really worth looking at just adding that
<mgz> I'd be happy to assist if you have questions, but don't use eclipse
<lolek> well ok
<lolek> but i don't thing that my skill will allow me to add that functionality ;)
<lolek> s/skill/skills
<venefyxatu> I've recently learned about mercurial queues, and now that I'm using it to work on several different changesets within one branch, move them around, reorder, apply/unapply as necessary I'm beginning to really love it - is there something like this available for bzr?
<venefyxatu> (sort of like shelve on steroids, I believe)
<lolek> guys, i've hitted something like: http://pastebin.com/7RhxJbiM, it's error from bzr-notify...
<lolek> any idea what could be wrong.. it's ubuntu 12.04/amd64
<mgz> lolek: just disable bzr-notify, see bug 998994
<ubot5> Launchpad bug 998994 in Bazaar GTK+ Frontends "bzr-notify: add_action() takes exactly 6 arguments (5 given)" [High,Triaged] https://launchpad.net/bugs/998994
<lolek> :/
<mgz> it's not used for anything significant is bzr-gtk
<lolek> hmm don't get it ?
<mgz> lolek: see the linked merge proposal, the code has been removed in newer versions of bzr-gtk
<lolek> oh
<lolek> hmm, so bzr-notify is no longer available ? i.e. it will be removed ?
<mgz> lolek: are you actually using it, or did you just notice it breaking?
<lolek> well i was trying to use it :)
<lolek> i saw how this is working at my friends desk, and it's nice tool
<lolek> and the funiest thing is he also have ubu 12.04 but .. he is using unity, and i'm using gnome-shell
<jelmer> lolek: bzr-notify has been removed in bzr-gtk trunk
<lolek> well that's not good
<jelmer> lolek: mostly since there were a fair number of issues like the one you hit, and they'd been open for quite some time
<lolek> hmm
<lolek> and.. do You plane to give some other app for the same functionality ?
<jelmer> lolek: perhaps if somebody steps up to do so. nobody was taking care of bzr-notify, that was one of the reasons we decided to eventually remove it.
<lolek> :/
<lolek> jelmer: well i've made one thing, added the missing argument as: None and.. bzr-notify is working
<jelmer> lolek: ah, nice
<lolek> but there is one problem
<lolek> notification is working i see the popup with two buttons: Inspect and Branch... neither of them is working... what should the buttons ?
<lolek> *what the buttons should do ?
<jelmer> what their labels say :-)
<lolek> Inspect / Branch
<jelmer> Inspect used to open a particular revision in "bzr viz"
<jelmer> and Branch launches the clone window
<lolek> hmm ok
<lolek> so both are not working ;d
<lolek> and i dunno why :]
<lolek> anyway i see tha problem
<lolek> it's related to gnome-shell vs unity .. the way that they use the notification, i.e. unity doesn't allow to place buttons in notifications, while gnome-shell do... maybe there would be a possibility to, create bzr-notify as systray app, after that we could show notifications for both gnome-shell and unity  in the same way, and add to that tray options: (inspect last commit/branch last commit) ?
<lolek> thanks to that the bzr-notify will work as usually, and both worlds would be happy
<lolek> jelmer: what do You think about that ?
<jelmer> lolek: that's what bzr-notify did - it supported both the appindicator API for unity and the regular systray stuff for GNOME2
<lolek> well yeah but from what i saw on the launchpad it seems that bzr-notify will be removed.. and that's said... :(
<jelmer> lolek: it's already been removed
<lolek> hmm
<lolek> bzr uncommit ?:D
<jelmer> lolek: as I said, it hadn't been maintained in a while and there were a number of open issues with it; I don't think bringing it back without addressing that would be a good idea.
<lolek> i can agree
<lolek> but.. if so.. is there any replacement for that ?
<jelmer> lolek: no, there's nothing that does anything similar at the moment
<lolek> hmm
<lolek> ok, be back tomorrow, bye
<evillyEvil> How do I revert all files EXCEPT some certain files in a project to the last commit state?
<evillyEvil> or is that even possible?
<fullermd> Not as a single step.
<fullermd> You could do some dancing around sh-ery with status and revert.  You could shelve the changes you want, revert, then unshelve 'em.
<dpb___> I have a weird bzr symlink-shared-repo problem.  I wrote a test case.  Should this just be a bug, or is there something I'm doing wrong?  http://pastebin.ubuntu.com/1354131/
<dpb___> note: the fact that the symlink points higher up in the chain is meaningless, it just needs to point somewhere outside the shared repo.
<fullermd> It's probably another incidence of https://bugs.launchpad.net/bzr/+bug/995055
<ubot5> Ubuntu bug 995055 in Bazaar "find_bzrdirs shouldn't follow symlinks" [Low,Confirmed]
<dpb___> fullermd: thanks.  We have a workaround for it in our narrow case. (unwind the symlink before handing it to bzr).
<thumper> abentley: ping
<abentley> thumper: pong
<thumper> abentley: I have a pipeline question for you
<abentley> Sure, what's the question?
<thumper> abentley: I managed to get some fucked up situation in my current checkout, so I moved it and re checked out trunk
<thumper> abentley: went into that directory and did 'bzr pipes' expecting only trunk
<thumper> abentley: but it had the other branch there too
<thumper> abentley: why?
<abentley> thumper: The pipeline data is associated with the branches, not the checkout.  It is stored in .bzr/branch/branch.conf.
<thumper> ok
<thumper> ta
<abentley> np
<thumper> abentley: that was simple wasn't it?
<abentley> :-)
<thumper> btw, still using pipelines daily
<abentley> Glad to hear it.
<felipec> what should I use instead of ControlDir.open(url) in older versions of bzr?
<jelmer> felipec: BzrDir.open(url)
<felipec> jelmer: cool
<felipec> that should be OK for newer versions as well, right?
<jelmer> felipec: I had plans to deprecate BzrDir.open because of ControlDir.open, but that hasn't happened yet
<jelmer> s/yet//
<felipec> all right
<felipec> jelmer: what about this error? http://pastie.org/5368946
<felipec> er, last line: TypeError: __init__() got an unexpected keyword argument 'help'
<jelmer> felipec: what's the actual exception?
#bzr 2012-11-13
<felipec> jelmer: weird thing is that if the install fails at build_mo, it works
<jelmer> felipec: seems like the (bundled) plugin is being loaded by an incompatible version of bzr
<jelmer> anyway, it's time for me to get some sleep..
<felipec> jelmer: yeah, but that's not the problem
<felipec> I just removed the bzr from my system
<felipec> still the same problem
<felipec> no, wait... yeah, that was it
<felipec> hmm, bzrlib.initialize() is not there in older versions
<lolek> hello all
<lolek> jelmer: are You here,
<lolek> jelmer: i've got one question on pm if You don't mind...
<jelmer> lolek: hi
<jelmer> lolek: sure
<lolek> hi hi ;)
<lolek> ok
<didrocks> hey
<didrocks> when trying to bzr lp-propose on bamf, I'm getting this error: bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/bamf/" and relative path "../../../~anjali-team/anjali/bamf/"
<didrocks> do you have any idea how I can start debugging?
<didrocks> I'm running something like: bzr lp-propose lp:bamf -m "foo"
<didrocks> (and the bamf trunk is ~unity-team/bamf/trunk, not anymore the anjali-something)
<jam> didrocks: so the issue is that lp:bamf has a parent set to another branch on Launchpad, but it isn't actually accessible. I don't actually know why lp-propose is trying to access the parent, but maybe it is trying to figure out what branch you want to submit to?
<jam> But I guess that is what you are supplying.
<jam> you can try -Derror and get a traceback to see where bzr is trying to access it.
<didrocks> jam: exactly, I'm supplying the branch I want to push at
<jam> bzr lp-propose lp:bamf -m "foo" -Derror
<didrocks> ok, one sec :)
<didrocks> jam: http://paste.ubuntu.com/1355044/
<didrocks> indeed, you're right, it's trying to get the parent of lp:bamf
<didrocks> but shouldn't it just use the url I provide and don't try to look for any parent?
<didrocks> (I confirm the bamf branch is removed from https://code.launchpad.net/~anjali-team)
<didrocks> I wonder where in launchpad it's trying to get it, I don't see it in the bamf project configuration
<jam> didrocks: as a 'parent' it means someone did "bzr branch ~anjali-team/... ~unity-team/..."
<didrocks> jam: yeah, the trunk was there a long time ago
<didrocks> then, it's now under ~unity-team and lp:bamf moved to it
<didrocks> but I guess bazaar has still its internal parent in bzr info
<didrocks> any idea how we can fix it?
<jam> didrocks: it is easy enough to remove it, it looks like lp_api is trying to find things that might be the public url for a branch before it settles on 'bzr_branch.base'
<jam> You could probably do something to set "bzr_branch.get_public_branch" and it would pick that up first, but it might also be easier to just remove the parent location.
<jam> didrocks: first, we should file a bug against bzr that lp-propose fails if the target branch has an inaccessible parent branch.
<jam> (we should be catching it and just skipping that one)
<didrocks> ok, let me file it
<didrocks> jam: here it is: bug #1078205
<ubot5> Launchpad bug 1078205 in bzr (Ubuntu) "lp-propose fails if the target branch has an inaccessible parent branch" [Undecided,New] https://launchpad.net/bugs/1078205
<jam> didrocks: thanks.
<jam> You should be able to do this in a python session: http://paste.ubuntu.com/1355063/
<jam> That should set the parent of the Launchpad branch to empty, provided you have access to write there.
<didrocks> jam: excellent, makes sense, let me try it :)
<jelmer> 'morning didrocks, jam
<jam> hey jelmer, good to see you around
<didrocks> jam: excellent! works fine :)
<didrocks> good morning jelmer ;)
<didrocks> jam: ah, however
<didrocks> jam: if I want to bzr lp-propose lp:~unity-team/bamf/bamf-0.3
<didrocks> (which isn't lp:bamf)
<didrocks> it's still proposing to lp:bamf
<didrocks> I guess because it's looking at the parent
<jam> didrocks: which seems odd, I'm really surprised that the code picks parent over self.
<jam> You can also config a 'public_location' for things
<jam> I think often people propose against a local branch which is a mirror of the actual public branch
<jam> was the thought process behind it.
<didrocks> jam: yeah, but when you explicitely put it on the command line, it should just obey to whatever your proposed against :)
<jam> didrocks: right, but you can do "bzr lp-propose ../bamf"
<didrocks> jam: I can't really have a configuration, I'm using this to have automated daily upload for the whole PS stack to ubuntu
<jam> where ../bamf is a branch from trunk
<didrocks> right, I didn't understand the parameter that way
<didrocks> but it can makes sense
<jam> So I would recommend setting the 'public_branch' information which it will always take first.
<didrocks> should it have another parameter to specify explicitely the branch to submit?
<didrocks> how do you set it?
<jam> I think you can do that with "bzr config -d lp:bamf public_branch=lp:bamf"
<didrocks> jam: hum, but this config will be system-wide, not local to a branch?
<didrocks> jam: we are on vm that are shared with other projects
<jam> I think it is set for the user, not for the team.
<didrocks> so writing in ~/.bazaarâ¦
<jam> correct ~/.bazaar/locations.conf I believe.
<jam> though maybe you could write it to bzr+ssh://bazaar.launchpad.net/.../.bzr/branch.conf
<didrocks> hum, not really handy for so many projects (~100)
<didrocks> let me try to see if I can automate setting it
<jam> didrocks: you can set a path based approach in ~/.bazaar/locations.conf
<jam> something like:
<jam> [bzr+ssh://bazaar.launchpad.net]
<jam> public_branch=bzr+ssh://bazaar.launchpad.net
<jam> public_branch:policy=appendpath
<jam> So stuff accessed under bazaar.launchpad.net/... should get themselves as the public location.
<didrocks> jam: I'm afraid I can't really do that due to jenkins having random workspace path, and the dir path doesn't necessarily reflect where I need to push
<didrocks> that's why I though bzr lp-propose <explicit> was good :)
<didrocks> hum, do you think "bzr config â¦" is process safe?
<didrocks> like, if it's called in parallel (the stack to upload are concurrent jobs), there is no issue?
<jam> didrocks: it should be taking a write lock on the config directory and either waiting or aborting if it fails to do so.
<didrocks> ok, so should be fine
<jam> didrocks: that is only in 'newer' bzr versions, but I'm not sure when it landed.
<didrocks> ahâ¦
<jam> didrocks: looks like bzr-2.3 is new enough
<didrocks> excellent, it's in precise :)
<jam> yeah, new enough is something like 1-2years old.
<AfC> 2.5 is in precise
<didrocks> jam: so, I tried:
<didrocks> bzr config -d lp:bamf lp:bamf
<didrocks> and then:
<fullermd> Nah, it's just approximate, not imprecise   ;p
<didrocks> bzr config -d lp:~unity-team/bamf/bamf-0.3 public_branch=lp:~unity-team/bamf/bamf-0.3
<didrocks> what I see in .bazaar/locations.conf:
<didrocks> [lp:bamflp:bamf]
<didrocks> public_branch = lp:bamf
<jam> didrocks: http://bazaar.launchpad.net/~unity-team/bamf/bamf-0.3/.bzr/branch/branch.conf
<jam> using -d lp: sets it in the actual branch on LP
<jam> Now the one problem is you *might* need the public_url to be a real url like http:// or bzr+ssh:// rather than lp:b
<didrocks> ah, it's in the repo itself
<didrocks> not local
<jam> didrocks: right
<jam> that is what the '-d' does
<jam> you can use --scope= to set it to be configured elsewhere, I believe.
<didrocks> jam: I'm fine by having it in the repo
<didrocks> I just need to note that down somewhere :)
<didrocks> let me try the automated lp-propose now
<jam> --scope='branch' is the default, --scope=locations will put it in ~/.bazaar/locations.conf
<didrocks> jam: better to be in the main branch scope as it's globale :)
<jam> didrocks: yeah
<didrocks> jam: ok, seems that it answered all my questions, thanks a lot jam ;)
<jam> didrocks: np, sorry it didn't just work in the first place.
<didrocks> jam: no worry, I can understand why it's that way, I just thought the option was for something else :)
<jam> didrocks: I also submitted https://bugs.launchpad.net/bzr/+bug/1078211 for you
<ubot5> Ubuntu bug 1078211 in Bazaar "lp-propose $BRANCH always prefers the parent branch" [Low,Confirmed]
<didrocks> jam: sounds good, thanks :)
<mgz> morning
<lolek> ahoy
<lolek> jelmer: hi, are You here ?
#bzr 2012-11-14
<mgz> morning!
<jelmer> mgz!
<quicksilver> it's a shame that bound offline commits *always* come through as a merge
<quicksilver> if there have been no intervening commits to the bound branch they could just be pushed up.
<jelmer> quicksilver: indeed
<quicksilver> doesn't matter much but makes the log slightly fiddlier to read than perhaps it needs to me
<quicksilver> and makes me choose between using "offline merge" as the commit message and forcing people to read the sub logs, or copying out the salient details.
<delinquentme> Ok so I've got a project I've started locally ...  I want to *create* a remote repo which has this code with the  --no-trees option
<mgz> delinquentme: what transports can you access remote with?
<jelmer> delinquentme: you can just use the same command you would use locally
<mgz> pretty much what jelmer said, unless you've only got http :)
<mgz> jelmer: are you in our green and pleasant land yet?
<delinquentme> jelmer, but bzr init-repo --no-trees /some/remote/server
<delinquentme> how does bzr know whether im making a empty repo ... or whether i've got code that belongs in it?
<jelmer> mgz: are you quoting "Jerusalem"?
<mgz> delinquentme: right, but sftp://some/remote/server etc
<mgz> always been a fan of blake.
<jelmer> delinquentme: you would create the repo first, then push code into it
<jelmer> mgz: :)
<jelmer> mgz: I'm sitting in the train in Brussels, waiting for it to leave
<mgz> ...and have been all day? :/
<mgz> at least belgian trains are well connected I guess
<mgz> or for the benefit of vila, in france, even the wifi would be on strike!
<delinquentme> jelmer, does that automatically make the remote repo the parent?  IE will I have the expected   $ bzr push :parent and $ bzr pull :parent operations  ... that Im familiar with in projects that I've branched instead of initiated ?
<jelmer> delinquentme: :parent is simply an alias setup in .bzr/branch/branch.conf, by default it gets set to the URL you cloned from
<delinquentme> jelmer, so since im not cloning then I'll need to set that up right?
<jelmer> delinquentme: well, if you want the local branch to consider the remote one as parent
<jelmer> but, yes
<delinquentme> jelmer, check!
<delinquentme> bzr: ERROR: Cannot lock LockDir(file:///home/thrive/rails_projects/ghgvc/GHGVC_RoR/trial/.bzr/branch/lock): Permission denied: "/home/thrive/rails_projects/ghgvc/GHGVC_RoR/trial/.bzr/branch/lock/pncf1lmgu4.tmp": [Errno 13] Permission denied: '/home/thrive/rails_projects/ghgvc/GHGVC_RoR/trial/.bzr/branch/lock/pncf1lmgu4.tmp'
<delinquentme> this a permissions error?
<delinquentme> i guess bzr needs write permissions?  .. and is there a bzr user?
<delinquentme> jelmer, I think this is a really simple chmod issue no?
<JPeterson> how do i disable tbzrcache?
#bzr 2012-11-15
<mgz> morning!
<jelmer> mgz!
<mgz> jelmer! did you make it to the y-uk?
<jelmer> mgz: I did! Sitting somewhere by the Thames at the moment (-:
<fullermd> You gotta be more careful about your geography.
<fullermd> I mean, King John once decided to just wander off and sit "somewhere" by the Thames, and look what happened to him.
<jelmer> fullermd: He became King John just because he sat by the Thames? I wouldn't mind being King Jelmer.
<jelmer> fullermd: Maybe I'm just not up-to-date on my British history.
<fullermd> Nah, he ended up having to put his seal on some lot of nonsense that gave a bunch of losers immunity against his powers.
<jelmer> I would never do that.
<fullermd> Oh, sure, they all say that, but you march one little army into London...
<delinquentme> OK. so I've got files that I added to .bzrignore ...
<delinquentme> and they're somehow not being ignored ...
<delinquentme> SO for things listed in .bzrignore ... does bzr read this file every time I run a $ bzr status   ??
<delinquentme> because I've committed the files I'd like ignored to .bzrignore in revno 154 ... but when i bzr status .. they still show up as modified
<delinquentme> Shitbags...
<delinquentme> I cant have a file in the repo which is listed in .bzrignore??
<MANISHRW> Has anyone setup bazar on windows using python ??
<MANISHRW> anyone ???
<jelmer> MANISHRW: hi
<jelmer> yes, there are installers for it
<MANISHRW> hey jelmer, i installed it
<MANISHRW> and i'm getting error when i'm trying to get new branch
<MANISHRW> this is the error - "No valid trusted SSL CA certificates file set. See 'bzr help ssl.ca_certs' for more information on setting trusted CAs."
<MANISHRW> any idea what should i do next ?
<jelmer> MANISHRW: have you checked that help page?
<MANISHRW> which help page ?
<ScottK> 'bzr help ssl.ca_certs'
<MANISHRW> i entered it
<MANISHRW> it showed this
<MANISHRW> Path to certification authority certificates to trust.
<MANISHRW> This should be a valid path to a bundle containing all root Certificate
<MANISHRW> Authorities used to verify an https server certificate.
<MANISHRW> Use ssl.cert_reqs=none to disable certificate verification.
<mortrca> I do not want search engines indexing my loggerhead site. Is it possible to drop a robots.txt file somewhere where loggerhead will include it in the web root?
<MANISHRW> can anyone help me out
<mortrca> Anyone know how this can be done?
<mortrca> Or if it can be?
<LarstiQ> mortrca: just a sec
<LarstiQ> mortrca: I don't know how you have set things up, but for my trac on Apache site I do <LocationMatch "^/(?!trac/|robots.txt|custom.css)">
<LarstiQ> mortrca: and then have a robots.txt in the DocumentRoot
<LarstiQ> mortrca: so with loggerhead something like that would be the first thing I try, have the webserver serve up content for /robots.txt instead of directing to loggerhead
<MANISHRW> how do i make ssl.cert_reqs to none
<MANISHRW> help please
#bzr 2012-11-16
<mortrca> LarstiQ: Thanks, that looks like it'll do what I want, if I can figure out how to write a regex that matches everything except "robots.txt", but regex has never been my forte. Do you know how to do that?
<mgz> morning!
<lifeless> mgz: o/
<jelmer> anybody seen Vila?
<mgz> as in, on irc?
<mgz> he joined this morning shortly after I did
<mgz> ...but left shortly after
<mgz> have you got a phone number for him that works in the UK?
<jelmer> I only have his home phone #
<mgz> and he doesn't have yours?
<mgz> try email just in case?
<jelmer> already did :)
<hasselmm> mgz, is there any kind of reverse shelve mode?
<hasselmm> ...that is pick the good changes and hide all the other mess?
<mgz> hasselmm: you mean apart from reversing 'n' and 'y' to shelve?
<hasselmm> mgz, yes. reversing 'n' and 'y' would be a start. constantly getting confused in the middle of a shelve
<hasselmm> too much git in me, i fear
<mgz> that's the way round I normally use shelve, read it as "No, I want to keep this in the tree" and "Yes, this is mess I want to go away"
<hasselmm> mgz, try the same. and from the perspective of generating a compilable workdir this all make sense. still i am constantly failing.
<mgz> shelve having a "whoops, I'm an idiot, ask me that last one again" key would help
<hasselmm> mgz: :-)
<hasselmm> ...indeed
#bzr 2012-11-17
<delinquentme> I have a file under VC... which I deleted... but the right version was there in the last commit
<delinquentme> at current $bzr status ... its listed under removed
<delinquentme> how can I get it back
<Guest1177> delinquentme: try 'bzr revert FILE'
<delinquentme> yeah got it
<delinquentme> so do I have to commit changes to .bzrignore before they're reflected in bzr status?
 * Guest1177 has only very basic knowledge about Bazaar
<jelmer> delinquentme: no
<jelmer> delinquentme: .bzrignore isn't used if you explicitly specify a filename to 'bzr add' or 'bzr revert'
<jelmer> it's just used by 'bzr status' to determine what files to list as unknown, and by 'bzr add' (without arguments) to determine what files to add
<delinquentme> bzr shelve ... how get the total number of shelve operations shelved
<jelmer> delinquentme: bzr shelf list
<LarstiQ> mortrca: exaxt regex syntax also depends on the engine. Apache uses pcre, and then something like '/(?!robots.txt)' would work
<LarstiQ> mortrca: ?! comes from "negative assertion" in `man pcrepattern`
<mortrca> LarstiQ: Do you mean like this?
<mortrca> <LocationMatch "/(?!robots.txt)">
<mortrca>   ProxyPass http://127.0.0.1:8080/
<mortrca>   ProxyPassReverse http://127.0.0.1:8080/
<mortrca> </LocationMatch>
<mortrca> That is what I have currently, but it isn't passing any requests to 127.0.0.1:8080
<delinquentme> removing a file from bzr version control... but NOT deleteing it?
<lifeless> delinquentme: bzr rm --keep
#bzr 2012-11-18
<Prodi> i'm trying to figure out why i'm getting some weird conflicts when merge a branch back into the "trunk"
<Prodi> and how to avoid getting them in the future, since this should be a conflict, as it's a straight file modification
<Prodi> i branched my trunk into "branch"
<Prodi> added file to branch
<Prodi> merged back into trunk, worked fine
<Prodi> modified that file on branch
<Prodi> merged back into trunk, but the trunk "bzr log" doesn't seem to think i got the change from the branch, it thinks i made it locally
<Prodi> new change to the file on the branch, trying to merge it in, and now i'm getting a file and file.moved as a conflict
<Prod[a]> anyone know how to check the file-id of a file on the working tree?
<fullermd> ls has a --show-ids
<Prod[a]> cool thanks
<Prod[a]> i'm trying to clean up these two trees i'm merging still
<Prod[a]> and it seems that some of the files didn't get merged properly
<Prod[a]> they were there in my original "trunk"
<Prod[a]> and they're there in the branch
<Prod[a]> but after the merge, the files have disappeared
#bzr 2013-11-11
<sbbrtn> I would like to clone a repo from a launchpad project and modify some of the code.  Eventually I want to upload the changed code to a new branch my launchpad account.  Can someone please help me with this?
<jam> mgz: poke
<mgz> jam: hey
<jam> mgz: 1:1 ?
<mgz> jam: mumble?
<jam> mgz: sure, though we have the standup right after :)
<DarkLinkXXXX> FATAL ERROR: Disconnected: No supported authentication methods available (server sent: publickey)
<DarkLinkXXXX> Why is it doing this, and how can I fix it? I googled it and found nothing.
#bzr 2013-11-12
<Wiz_KeeD> hello guys
<Wiz_KeeD> I have a directory that is owned by www-data and www-data group, how do I manage a bzr branch when new files are constantly being generated and I cannot be expected to chmod g+w ./* -R every time
<Wiz_KeeD> guys, how does one update thew working tree?
<jelmer> Wiz_KeeD: "bzr update"
<Wiz_KeeD> I tried that it does not update the working tree, still empty
<Wiz_KeeD> I moved everything out and did revert -r latest_revision
<Wiz_KeeD> and it worked
<jelmer> so it does depend on what you mean by "update"
<Wiz_KeeD> update the working tree precisely to what the revision has
<jelmer> just "bzr revert" should do that
<Wiz_KeeD> with --no-backup so i don't have a lot of crap to deal with?
<jelmer> it should only create backup files for files that have actually changed
<Wiz_KeeD> yeah they would be a lot
<jfcaron> Is there a way to set something in bazaar.conf (or elsewhere) that makes "bzr diff" automatically do the same thing as "bzr cdiff"?  cdiff isn't intuitive enough for me.
<jfcaron> "bzr diff" is apparently not an allowed bash alias name because of the space.
<jelmer> jfcaron: yes, add an alias for 'diff' to 'diff --color'
<jelmer> jfcaron: a bzr alias, rather than a bash alias
<jfcaron> What's the difference between diff --color and cdiff?
<jelmer> they should be the same thing
<jelmer> you can create an alias to cdiff too
<jfcaron> Cool, thanks.
<jfcaron> And it's a global setting in my bazaar.conf, as I wanted.
#bzr 2013-11-13
<osfd> Hi there, how do you download a former branch ?
<osfd> I know bzr update
<osfd> to get the last version
<LeoNerd> What do you mean "former branch"?
<LeoNerd> Perhaps you wanted  bzr up -r123  ?
<osfd> say the actual tree is 4462, I wanna go to 4460
<osfd> LeoNerd: so I want to go to an older branch
<osfd> or lower if you prefer
<LeoNerd>  Okder revision of the same branch
<LeoNerd> So, yeah,  bzr up -r4460
<osfd> yes
<osfd> I did that, I test to see if that work
<osfd> LeoNerd: thank you
<osfd> LeoNerd: and yes I meant version, not branch, sorry
<vedu> hello. how to activate bzr autocomplete
<Wiz_KeeD> hey guys
<Wiz_KeeD> how do I delete a directory from a bzr repo and leave the actual tree untouched
<Wiz_KeeD> --no-backup cfreates those ~1~ thing right?
<Wiz_KeeD> ah I think it's keep
<CcxCZ> how do I actually use a mergetool such as http://sjl.bitbucket.org/splice.vim/ from command line?
<CcxCZ> I tried  bzr remerge --merge-type splice  which looked like logical place for it but that doesn't work (bzr-2.5.1 btw)
<vila> CcxCZ: bzr remerge --help will tell you that it's not logical ;) Adn the page you linked above even mention how to do that for bazaar
<yooozy> hello
<yooozy> hepl please! I want to install bzr  to control my site on server then clone it locally to modify it  then merge
<yooozy> helloOo
<yooozy> anyone?
#bzr 2013-11-14
<CcxCZ> vila: it tells me how to configure it, not how to invoke it
<CcxCZ> none of the bzr commands I've looked at take a mergetool as an argument
<vila> CcxCZ: let see, if it's *configured* that may be because you don't have to specify it as an argument. Could it be that merge*tool* implies that it's invoked by... merge ? Just guessing after looking at the *first* link in the page you linked, the video
<vila> CcxCZ: not to mention the first text in that page: "Splice is a Vim plugin for resolving conflicts during three-way merges. "
<vila> *during* merges
<CcxCZ> well, what's the point of having a named list of mergetools, beside the default one then?
<CcxCZ> vila: so there is no way to select a mergetool except changing the default in the config file? that was my original question. (vimeo is strangely broken for me atm)
<vila> CcxCZ: evry bzr option is available from the command line with -O, so bzr merge -Obzr.default_mergetool=whatever if you want to override your config file
<CcxCZ> ah, thanks :)
<yooozy> I need help, anyone?
<yooozy> bgardner, hello
<bgardner> yooozy: Morning
<yooozy> bgardner, )
<bgardner> yooozy: Go ahead and ask, but I'm not a bzr expert so be prepared for puzzled looks.
<yooozy> bgardner, I made a local branch  to my live site folder so that I can edit and upload files  and commit changes then push, the problem is that the local branch is not pulling data project
<yooozy> *project data
<bgardner> yooozy: You mean there the branch isn't complete?  Not sure how you meant that it isn't pulling.
<yooozy> bgardner, let me show you what I did, one moment
<fullermd> "project data" sounds like something that wouldn't be under version control, so it would be unsurprising that a VCS wouldn't transfer it...
<yooozy> bgardner, "aziz@aziz-HP$ bzr init ftp://user@example.com/public_html/forums " then "aziz@aziz-HP$ bzr init ftp://user@example.com/public_html/forumsaziz@aziz-HP$ bzr branch ftp://user@example.com/public_html/forums"
<fullermd> OK, that is definitely not going to do anything too helpful  :)
<yooozy> fullermd, you mean than bzr should be installed in server?
<fullermd> (also, FTP is the devil)
<bgardner> fullermd: +1
<fullermd> If you're going to want to have bzr actually do stuff with the files on the server, yes (and FTP access wouldn't be sufficient for that; you'd need ssh and shell and such)
<fullermd> What you did there was just create a new empty branch at that location, then made a local copy of the empty branch.  Which is technically _valid_, of course, but probably not too efficacious   :)
<fullermd> On the first hand, you presumably want a branch with all those files in it, which would mean you'd either need a real shell on the server where you could bzr add ; bzr ci the files, or to manually copy them all down locally to do the same there.
<fullermd> And on the second, if you're wanting to use bzr to copy later changes up to the server, you'd also need a real shell (well, technically not quite absolutely, but near enough for now) and bzr installed to do it; push over a remote protocol isn't going to touch the remote files, just the internal history.
<yooozy> fullermd, I used bzr upload plugin it worked
<fullermd> (in the abstract, a VCS is neither a file transfer app, nor a site deployment app.  A lot of people try to use it as such, with sometimes decent success, and sometimes utter failure; usually somewhere in between)
<fullermd> 'k, that's another different thing.  It doesn't (AFAIK; never used it) maintain any actual bzr-history-stuff like a branch on the server, it's just sorta a conceptual wrapper around FTP'ing the individual working files up.
<yooozy> fullermd, suppose I have shell access, what is the scheme to achieve the same?
<fullermd> Well, you could init / add / ci the files; then you'd have a branch you could branch down locally and have the stuff to work with.
<fullermd> (though it's likely a little more involved than that, in that there are probably files there you wouldn't want in version control, blah blah.  But in concept...)
<fullermd> Then you could make local changes, use push to update them into the remote side branch, and login to the server to do a local update to bring them out into that WT.
<fullermd> Or there's a push-and-update plugin, which basically just automates "ssh $server ; bzr up"
<yooozy> got it
<yooozy> fullermd, thank you so much
<fullermd> If you wanted to use 'upload', it would be more like copy files down ; init/add/etc all your branch stuff locally ; upload when appropriate, and not have a branch on the server side at all.
<fullermd> (or possibly push it somewhere else on the server, to have as backup etc)
<fullermd> Or possibly not; somebody else can probably tell you more about upload.  I just know what I've seen from other people talking about it.
<yooozy> that's what I'm going to do for the moment but I will use launchpad as a backup
<fullermd> That could work too, assuming you're OK with it being public.  Or you have the semi-mythical private commercial launchpad account thingy.
<yooozy> but why not having  a branch at server?
<fullermd> Since upload doesn't interact with a branch at the upload location, I'd recommend not also pushing a branch to the same place, just to avoid possible confusion.
<fullermd> Either having the files "owned" by a branch there and managed via local 'update' etc, or owned by upload with no branch at the same place.
<fullermd> Not that I think it would _break_ anything in itself, just minimizing possible confusion or human-caused conflicts down the line.
<yooozy> I guess it's simpler than I thought
<yooozy> so basically I just download files manullay, bzr them... and upload...but I have to ignore some files isn't it?
<fullermd> I wouldn't think upload would mess with files it doesn't know anything about one way or the other, so just bringing down and bzr'ing the files you care about managing should leave the other files on the server untouched.
#bzr 2013-11-16
<mark06> when bzr commit opens the text editor for getting the commit message, it is opening notepad.exe
<mark06> is it possible to make it use another text editor?
<Peng> I'm almost certain you can set an editor in the configuration file.
<mark06> ok will look further later, thanks!
<Peng> >_>
#bzr 2014-11-10
<c0okie> Hi
#bzr 2014-11-14
<aquarius> I'd like to do the equivalent of bzr cat from a Python script -- that is, write a function which takes an lp URL for a file and returns the content of that file. Is the best approach to call the bzr cat command object and give it a StringIO to output into (which I can't work out how to do), or to do the things that the command object *does* myself?
<aquarius> I *think* the way to do it is this:
<aquarius> from bzrlib.plugin import load_plugins;load_plugins();from bzrlib.branch import Branch;remote_branch_url = 'lp:~sil/+junk/ucs-demo-app';b = Branch.open(remote_branch_url); tree=b.basis_tree(); file_id=tree.path2id('ubuntu_component_store.json'); print tree.get_file_text(file_id)
<james_w> aquarius: that looks about right
<aquarius> cool, I'm not doing anything insane, then :)
<aquarius> am I better to check the file exists with tree.has_id first, or do I end up hitting the network twice then and so I should just catch exceptions on tree.path2id?
<james_w> aquarius: catching an exception makes more sense I thinnk
<james_w> aquarius: or I think it returns None in fact
<aquarius> cool, then I'll just do it and check :)
#bzr 2015-11-10
<chris2> abentley: hi. i
<chris2> i'm curious if the code to http://code.aaronbentley.com/weavediff is still online somewhere?
<abentley> chris2: It's been a very long time.  I'm sure whether I implemented it.
<chris2> there is a link on your homepage, but broken :)
<chris2> but if you dont find it, not problem
<chris2> i wonder if its possible to store a new revision without extracting the last one first?
<abentley> Sorry, I can't find easily.
<chris2> ok, no problem
<chris2> i'll try to do it myself :)
<abentley> chris2: You don't have to extract the last version first.  As part of extracting the current version, you'll need to fill in holes in the current version with lines from the previous version.  As part of reconstructing those segments of the previous version, you'll need to fill in holes with an even earlier version, and so on until you've found all the lines that appear in the current version.
<abentley> chris2: Best case, all lines in the current version are new, and you can stop right away.  Worst case, there's one line in the current version that was introduced in the very first version...
<chris2> that's what i thought, but i think there are counterexamples where you need a real lcs?
<chris2> if you try to insert changed lines into the first possible position, the weave can become bigger than it needs no?
<chris2> need to contemplate about that :)
#bzr 2015-11-11
<chris2> abentley: i think we talked past each other... i was talking about storing a new revision. i need to compute a lcs-linewise-diff against the previous revision first, no?
<abentley> chris2: Yes, in order to store a new revision, you'd need to reconstruct the previous.
<abentley> chris2: Unless you want to do it inefficiently.
<chris2> i know how to checkout a revision, i think :)
<chris2> but when i want to store a minimal delta, i need to have both contents beforehand i guess
<abentley> chris2: You might be able to treat the instructions for constructing the old revision as if they were instructions for creating the new revision, correct them, and then use the corrections to generate instructions for generating the new revision.  That's hypothetical.
<chris2> that's what i was playing at
<abentley> chris2: May I ask why you're interested in weavediffs?
<chris2> sure. i'm thinking about a new vcs and wondered if sccs-style weave wouldnt be a good storage for text files
<chris2> but i wanted append-only
<chris2> otoh git-style packfiles seem to solve the issue easily and more generally with brute force :)
<chris2> and i currently dont really care for merging, so...
<fullermd> Wasn't the knit format sorta reminiscent of an append-only weave?
<chris2> its the evolution of weavediff afaiu
<chris2> but i couldnt find details on how it works :)
<fullermd> Probably aren't many, outside of the code...   Of course, an alternate answer would be "poorly enough that they were superceded for a reason"   ;)
<chris2> needing to read the file backwards probably is not nice for rotating disks
<fullermd> Eh, for reasonable sizes files, you probably just slurp up the whole thing anyway.  Heck, for files up to a certain size, that probably happens between hardware and OS prefetch whether you try to or not.
<chris2> if you have one weavediff per file, yearh
<fullermd> Not so much if it's a hundred megs, to be sure.  But then (unless the reconstructed file is most of that anyway) you're probably gonna hit some of the nasty weave cases trying to work with it anyway.
<chris2> a naive weave needs linear time to extract, i guess i want to avoid that anywayt
<chris2> so you need to store snapshots somehow
<abentley> chris2: So there were two advantages of weaves: 1. weave merging, 2. annotation.  Knits provided annotation, and we actually found three-way merge worked very well most of the time.  These days, with pack files, we do annotation the expensive way, but it's cheap enough if you'd doing it locally.
<fullermd> Yeah, experience hasn't been kind to weaves.  Seems like they have great properties in reasoning and performance for the things you hardly ever do, while being difficult and compoundingly expensive for the things you wind up doing all the time.
<chris2> i mostly have git experience. and annotation is slowish, but usually good enough
<chris2> but the store is one of the fastest and most compact i know
<chris2> and 3-way-merge works Good Enough, exactly
<fullermd> bzr knit formats were certainly a lot better than weave (my daily bzr.dev 'pull's took >20 minutes with weaves), but they still lost the race by a long way...
<chris2> so what does bzr use currently? this 2a format? is it explained somewhere?
<fullermd> It was once called something like "brisbane-core" while it was in dev.  I know there were a number of docs written under that name at the time.
<abentley> fullermd: I think my weavediffs would have been better than weaves, but likely worse than knits.
<chris2> how does it compare to git packs?
<fullermd> I vaguely recall that git uses xdelta or something?
<chris2> yeah
<chris2> git is sorting all blobs by size and then by date i think, and then doing xdelta chains
<abentley> fullermd: I don't think it uses an existing delta format.  I remember lifeless invented it on the plane because he didn't have internet access.
<fullermd> I think bzr packs are moderately different in implementation, using something more like straight entropy coding, though there's some deltaing on top?
<fullermd> Or underneath.  Whichever.
<fullermd> But that's way out of my depth.  I just commit and log stuff   :p
<chris2> :)
<fullermd> There may be some comments in the code giving an overview.
<chris2> i'll have a look
<fullermd> groupcompress.py is probably the place to start.
<abentley> chris2: You also might want to look at docs/groupcompress-design.txt
<chris2> very good. thanks
#bzr 2016-11-16
<bignose> vale, lifeless.
<bignose> thanks for all the great work and advocacy for Bazaar.
<bignose> <URL: http://www.europython-society.org/post/153253946400/farewell-to-rob-collins>
<Peng> Oh no!
<bignose> hmm, my apologies. not the same person. Robert âlifelessâ Collins, developer of Bazaar, is not the same person in that obituary.
<Peng> O_O
