[00:21] <Peaker> bzr: ERROR: Repository KnitRepository('file:///.../.bzr/') is not compatible with repository KnitRepository3('file:///..../.bzr/')
[00:21] <Peaker> Does the svnplugin make KnitRepository's instead of KnitRepository3?
[00:23] <jelmer> no, it uses KnitRepository3 but standard bzr uses KnitRepository
[00:23] <Peaker> oh, why is that?
[00:23] <jelmer> you can upgrade a repository to the first by running 'bzr upgrade --dirstate-with-subtree'
[00:23] <jelmer> forward compatibility on bzr-svn's side
[00:24] <Peaker> cool, thanks
[00:28] <Peaker> I love bzr! :-)
[00:28] <Peaker> The horror of using svn because of googlecode.. for weeks!
[00:38] <arjenAU> Peaker: so access the svn repos from bzr
[00:39] <Peaker> arjenAU: What I really wanted was shared branches though, and now I hope to have that with launchpad
[00:39] <Peaker> arjenAU: I want development to go into branches instead of messing up trunk all the time
[00:39] <Peaker> not just by me, but by codevelopers
[00:40] <Peaker> a heavy checkout is really just a repo+branch pulling/pushing from/to another branch on every commit, whereas a light checkout is really just a branch ptr, right?
[01:03] <Peaker> If I just delete the working tree (when it has no uncomitted changes ofcourse), I can just restore it with update, right? So when I'm done with a branch, I can remove the working tree to save some space until I use it again, right?
[01:04] <Peaker> if that is true, I think I might need/write a plugin that verifies there are no uncommitted changes, cleans up and deletes all the files it can restore later
[01:12] <fullermd> You delete the working tree with remove-tree, and recreate it with checkout
[01:12] <fullermd> remove-tree won't remove altered files (or non-versioned files)
[01:15] <Peaker> fullermd: ah cool thanks
[01:16] <Peaker> then it seems I dont have to write a plugin :-)
[01:33] <Peaker> hmm, bzr hosting on launchpad seems to force me to upload the entire repo for each branch I make there. Where do you guys host your bzr branches such that creating a new hosted branch is cheap and doesn't require pushing the entire history?
[01:34] <Peaker> When I C-c (SIGINT) the bzr push to launchpad, I got  TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x89a680c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
[03:03] <Peaker> How do you run "bzr serve" over ssh? How is access control done?
[03:06] <spiv> Peaker: bzr+ssh:// just connects via SSH as normal, and runs the "bzr serve" command (actually it gives it a couple of arguments).
[03:06] <Peaker> spiv: oh, I thought it bzr+ssh connects to an sshd already running
[03:06] <spiv> Peaker: access control is done entirely by the SSH server and filesystem; i.e. normal user accounts.
[03:06] <spiv> (unless you want to write a custom sshd...)
[03:07] <spiv> It's pretty similar to how svn+ssh:// works, AIUI.
[03:07] <Peaker> so the path given to bzr+ssh://path-here  must be absolute, not relative, right?
[03:08] <Peaker> (relative would be relative to user's home dir, I'd suppose)
[03:11] <Peaker> To set up permissions of who can access my bzr repository via bzr+ssh, I'd need root access to create a group I suppose. I hate unix security...
[03:22] <Peaker> do you think if I install a local copy of bzr in my homedir on the sourceforge shell server they'd be mad? :-)
[03:24] <jelmer> Peaker, you can always use sftp
[03:24] <jelmer> that'll be a bit slower, but won't require bzr on the remote side
[03:27] <Peaker> jelmer: thanks that works :)  I wonder if that will piss them off.. heh
[03:30] <Peaker> doesn't seem like shell.sf.net is a usable file host for bzr, its taking ages to do anything
[03:31] <Peaker> where do you guys host your shared branches?
[03:31] <jelmer> sftp is slower than bzr+ssh in any case, unless you use it with packs (new data format in 0.92)
[03:31] <jelmer> I host them on my team's shared server or launchpad
[03:31] <Peaker> my ubuntu is still packaged with 0.90.0
[03:32] <Peaker> jelmer: but if you want to make a new branch on launchpad you have to push the entire history again
[03:32] <jelmer> yes, but I only use launchpad for smaller things
[03:32] <jelmer> how big is your history?
[03:34] <Peaker> there's 40MB in my repository/
[03:34] <Peaker> if that's a good measure
[03:34] <jelmer> but what's the number of revisions?
[03:34] <jelmer> this is bug 41415 in launchpad apparently
[03:34] <Peaker> 452
[03:34] <ubotu> Launchpad bug 41415 in launchpad-bazaar "supermirror sftp server does not support hosting bzr repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/41415
[03:36] <Peaker> according to the bug I can use sftp to explicitly create repositories
[03:37] <jelmer> well, you can on an ordinary sftp server, but not on launchpad
[03:37] <Peaker> weird, how does their sftp prevent it?
[03:38] <jelmer> only allows you to create certain directories
[03:38] <jelmer> to prevent you from using launchpad for general-purpose (non-bzr branches) hosting
[03:42] <Peaker> I see
[04:09] <Peaker> can I tell a branch to move its head back without creating a new revision that's identical to previous revisions?
[04:10] <Peaker> I could create a new branch but the branch is already there and advertised as a main branch..
[04:11] <Peaker> also can I decide that a bunch of changes I've been making should not commit to this branch but instead go to another branch?
[04:12] <Peaker> Without bzr diff | patch in-new-branch ?
[04:13] <spiv> Peaker: "cd ../new-branch; bzr merge --uncommitted ../old-branch"
[04:13] <Peaker> spiv: thanks!
[04:13] <Peaker> no way to get a branch to throw a bunch of the last revisions to become ghosts though?
[04:14] <Peaker> well actually I made a branch that contains them now, so they wouldn't be ghosts
[05:11] <Peaker> does bzr have nested checkouts? (if I want to split my repo into 3 for each of the components)
[08:55] <jelmer> Peaker: partially
[08:55] <jelmer> Peaker: it's somewhat supported, but still experimental
[10:20] <ubotu> New bug: #158596 in bzr "`bzr info -v` is not working if WT4 is locked." [Undecided,New] https://launchpad.net/bugs/158596
[11:36] <jelmer> mwhudson: ping
[11:36] <mwhudson> jelmer: hi
[11:36] <jelmer> mwhudson: Can you please try pushing your pydoctor branch to svn again, using the latest and greatest bzr-svn ?
[11:37] <mwhudson> jelmer: ok
[11:37] <mwhudson> jelmer: should i use bzr.dev?
[11:37] <jelmer> I've reproduce the property bug and fixed it
[11:37] <jelmer> yes, either bzr.dev or 0.92rc1 and bzr-svn's 0.4 branch
[11:38] <mwhudson> what's the url of the bzr-svn branch?
[11:38] <mwhudson> it seems that i haven't installed it again since my hard drive died
[11:38] <jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.4
[11:39] <jelmer> or lp:bzr-svn
[11:39] <mwhudson> ok
[11:50] <mwhudson> ah, lovely, a segfault when i C-c-ed the fetching revision info step
[11:54] <mwhudson> jelmer: hm, seems to be doing the 'finding branches' thing twice
[11:55] <jelmer> hmm, it shouldn't do the finding branches more than once
[11:56] <mwhudson> it's doing it a third time now
[11:57] <jelmer> this is during a push or a pull?
[11:57] <mwhudson> push
[11:58] <jelmer> but you've never pulled this particular branch before?
[11:59] <mwhudson> jelmer: not on this machine no
[11:59] <mwhudson> i can do that first if you like
[11:59] <mwhudson> jelmer: http://rafb.net/p/fVHbyE18.html
[12:00] <mwhudson> and noe
[12:00] <mwhudson> mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr get http://codespeak.net/svn/user/pydoctor/trunk
[12:00] <mwhudson> bzr: ERROR: Not a branch: "http://codespeak.net/svn/user/pydoctor/trunk".
[12:00] <mwhudson> mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr get svn+http://codespeak.net/svn/user/pydoctor/trunk
[12:00] <mwhudson> bzr: ERROR: Not a branch: "svn+http://codespeak.net/svn/user/pydoctor/trunk".
[12:02] <jelmer> what does "bzr svn-branching-scheme http://codespeak.net/svn/user/pydoctor/trunk" say?
[12:02] <mwhudson> oh we
[12:02] <mwhudson> er
[12:02] <mwhudson> wrong svn url
[12:03] <mwhudson> mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr svn-branching-scheme http://codespeak.net/svn/user/mwh/pydoctor/trunk
[12:03] <mwhudson> bzr: ERROR: No repository present: "http://codespeak.net/svn/user/mwh/pydoctor/trunk/"
[12:06] <jelmer> try:
[12:06] <jelmer> bzr svn-branching-scheme http://codespeak.net/svn/
[12:06] <jelmer> here it says:
[12:06] <jelmer> */*/*/trunk
[12:06] <jelmer> */*/*/branches/*
[12:06] <jelmer> */*/*/tags/*
[12:07] <mwhudson> i have one level less of */
[12:07] <mwhudson> maybe this is because i fed it a bogus url to start with?
[12:08] <jelmer> ah, yeah, that may've confused it if there are also branche swith just two levels of parent directories
[12:08] <mwhudson> probably
[12:09] <mwhudson> it's a fairly chaotic repo :)
[12:09] <jelmer> simply removing "scheme = " from ~/.bazaar/subversion.conf will make it try again
[12:10] <jelmer> or rather, set it to "trunk3"
[12:12] <mwhudson> ok, i managed to get the branch now
[12:14] <mwhudson> pushing is doing the finding branches thing again
[12:15] <jelmer> more than once?
[12:16] <mwhudson> not yet
[12:16] <mwhudson> it's going slowly this time
[12:21] <mwhudson> i guess the extra level of */ gives it a lot more locations to consider?
[12:22] <mwhudson> jelmer: http://rafb.net/p/9RE7Or87.html
[12:24] <jelmer> mwhudson: yeah, it's very inefficient for your sort of repository
[12:24] <jelmer> mwhudson: does it break like in a reproducible way?
[12:27] <mwhudson> jelmer: will let you know :)
[12:34] <mwhudson> jelmer: yes, seem reproducible
[12:37] <jelmer> mwhudson: ok, guess I have a new bug to work on then.. thanks!
[12:38] <mwhudson> jelmer: i guess this is some kind of corruption in the repository
[12:38] <mwhudson> jelmer: but it ought to be possible to ignore stuff over in other parts of the tree from where i want to work?
[12:41] <jelmer> mwhudson: corruption in the svn repository you mean?
[12:41] <jelmer> mwhudson: yes, bzr-svn should be able to ignore that bit but it can't yet
[12:42] <mwhudson> jelmer: yes
[13:23] <schierbeck> jelmer: ping
[14:15] <ubotu> New bug: #158690 in bzr "ls --non-recursive PATH : no list" [Undecided,New] https://launchpad.net/bugs/158690
[14:42] <jelmer> schierbeck: pong
[14:45] <vila> lifeless: ping
[14:46] <lifeless> vila: pong
[14:46] <vila> wow :)
[14:46] <vila> I saw you used transport.list_dir
[14:46] <vila> Can't you avoid it ?
[14:46] <lifeless> yes, in a write operation
[14:47] <vila> (it's in Rev 2949: * Obsolete packs are now cleaned up by pack and autopack operations.)
[14:47] <lifeless> not without more round trips than it's worth.
[14:47] <lifeless> oh,  I know where it is.
[14:47] <vila> that means wedav plugin will never be able to do that :-/
[14:47] <lifeless> webdav supports listing
[14:48] <vila> err, let me check that :-)
[14:48] <lifeless> we used it on tla for writing over webdav
[14:48] <lifeless> IIRC its :search
[14:56] <jroes> has anyone had some weird problem with "cannot access lock file" on win32?
[14:56]  * jroes forgets to just google and find bugs on launchpad
[14:57] <vila> looks like an extension to RFC2518... would be far more work to marshall the request and extract the useful bits in the response... I think the sort tem answer will be to activate directory listing on the http server and lightly parse an index.html (i.e. implement an ad-hoc list_Dit) :-/
[14:57] <vila> s/Dit/dir
[14:58] <vila> I thought that with packs you somehow maintained the list of files created on the server, why can't it be used for obsolete ? Recovery handling ?
[14:59] <vila> And the other hand webdav is happy to delete a whole tree, (i.e. the obsolete dir even if not empty)
[15:04] <lifeless> we shouldn't rm the obsolete dir because that would trash permissions
[15:04] <vila> gee, s/sort tem/short term/ around three lines above
[15:06] <vila> permission handling is already messy when using a web server...
[15:09] <vila> So far, the webdav plugin stay simple because it avoids parsing xml in any response, having to implement list_dir wil kill that, I just have no idea when or even if I will take into account
[15:09] <lifeless> well packs are still experimental
[15:10] <jroes> so, after reading "bzr help working-trees" I'm beginning to have trouble following the point of bzr when you are on a machine that is not running a webserver.  is this the general consensus or am I not understanding right?
[15:10] <vila> Said otherwise, my question is: should I just kill webdav plugin *now* or do you think you can avoid using list_dir ?
[15:10] <lifeless> the tla code for list_dir was pretty darn trivial
[15:10] <vila> lifeless: pointer ? C ? python ?
[15:10] <lifeless> jroes: I think you are not understanding right
[15:10] <lifeless> vila: apt-get source 'bazaar' and look for pfs_http.c
[15:11] <jroes> well, see, if I'm just a developer on my development machine, and I want to have my branch publically accessible for friends/colleagues/the public to branch and merge from, I need to push my changes to a separate machine via SSH
[15:11] <jroes> from what I've read, unless I use a plugin, I have to login to the machine after every `bzr push` and run `bzr update`
[15:12] <lifeless> jroes: you don't need to run update for other people to be able to pull from it
[15:13] <jroes> well, what happens when I commit a new change in my local branch and then I run push again?
[15:13] <lifeless> then bzr updates its metadata, and ifthey do a pull they will getyour commit
[15:15] <jroes> ok, so then the message I am seeing when I push is just a warning, and not an error based on what I'm actually pushing at this point?
[15:15] <lifeless> you're getting the warning because you have a working tree on the remote machine
[15:16] <jroes> "This transport does not update the working tree of: sftp:/etcetcetc/.  See working-trees for more docs"
[15:16] <lifeless> we assume you have some reason for doing that and thus let you know that it will not be updated
[15:16] <lifeless> if you don't need a working tree there, then bzr zap-tree is your friend
[15:16] <jroes> ok, so I must have accidentally done something on the remote box like a bzr commit of some sort?
[15:17] <jroes> I'm trying to figure out what I did to turn it into a working-tree, what kind of operation would do that?
[15:18]  * jroes will grep his .shell_history
[15:19] <vila> lifeless: hehe, sure, pfs_dav.c trivially implemented pfs_directory_files by..... relying on neon :-)
[15:19] <lifeless> vila: oops, well.
[15:20] <Peaker> how can I publish a bzr+ssh branch for all users that has a nice path and not some ://my_comp/var/hosting/bzr/... ?
[15:20] <vila> lifeless: no worries. just wanted to keep you informed, that if you can still avoid it...
[15:20] <jroes> Peaker: maybe you can get symlinks or hardlinks to work.  I don't think I could get symlinks to work, but I might have some permissions problems
[15:20] <vila> lifeless: ... or not avoid it, but knows about the consequences for webdav
[15:21]  * vila back to fixing bugs :)
[15:21] <lifeless> vila: well there are some issues; I will mail the list some thoughts for packs2
[15:21] <vila> ok
[15:22] <jam-laptop> lifeless, vila: what about having a Transport.clean_directory()
[15:22] <jam-laptop> which for most transports is implemented as lifeless  does
[15:22] <jam-laptop> and for webdav could be
[15:22] <jam-laptop> rmtree() + mkdir()
[15:23] <lifeless> jam-laptop: feels a bit bloatwarey
[15:23] <jam-laptop> I agree, but it solves the problem
[15:23] <jam-laptop> It is a fairly specific request
[15:23] <jam-laptop> And means we don't expose 'list_dir()' to higher levels
[15:24] <jam-laptop> Certainly from a smart server perspective we would want it to be done solely on the remote side, though that would be handled by the fetch() logic I presume
[15:25] <lifeless> right
[15:25] <vila> jam-laptop: but doesn't address the permission bit lifeless talked about (I'm still unclear about what you worry though)
[15:25] <jroes> lifeless: where is this zap-tree?  even google only found 3 results (and 2/3 were irc quotes from you)
[15:26] <jroes> :)
[15:26] <jam-laptop> vila: well, as you said, if they are accessing over webdav, then permissions are pretty much just apache:apache
[15:26] <jam-laptop> jroes: "bzr remove-tree"
[15:26] <jam-laptop> zap-tree was an old command
[15:26]  * jroes nods, thanks
[15:26] <jam-laptop> I think you have to be on that machine
[15:26] <jroes> I'll quiet down now since you guys are in heated developer discussion :)
[15:27] <vila> jroes: dont' do that :) We have time to solve our issue
[15:28] <gotgenes> lifeless: any chance of a 0.92rc1 deb today? =-)
[15:29] <vila> jam-laptop, lifeless : I *thought* the list_dir was... hmmm, would be deprecated one day :) But I also had the impression, at London sprint, that implementaing it for http my solve a range of issues
[15:29] <jam-laptop> vila: it is considered unusable for read-only transports
[15:29] <jam-laptop> but lifeless was only doing this during a write operation
[15:29] <lifeless> jroes: remove-machine
[15:29] <jroes> hm.  so on my remote machine I ran a "bzr remove-tree" (which I believe completed successfully, since there were no errors), and then on my local machine I ran a bzr push to the remote machine, got an error about branches diverging, so I ran a bzr merge on my local machine merging from the remote machine, and got a "working tree has uncommitted changes"   I'm not too sure why, but technically if I just want my two branches to be the same, can I just rm-rf the en
[15:29] <lifeless> bleh. ignore me
[15:29] <vila> the problem being that a bit of server-side configuration may be needed and that it kind of make our dumb support support have some limits
[15:30] <jam-laptop> At the moment, all supported writable transports support listdir
[15:30] <vila> jam-laptop: gee, cruel again ;)
[15:30] <jam-laptop> jroes: Well, we are letting you know that there is divergance
[15:30] <jam-laptop> you pushed something earlier that you haven't merged
[15:30] <jam-laptop> and you are trying to merge into an unclean tree
[15:30] <jam-laptop> The recommendation would be
[15:30] <jroes> so, in that case it's telling me my -local- tree is not committed?
[15:31] <jroes> or the remote tree?
[15:31] <jam-laptop> "review changes; bzr commit; bzr merge; bzr commit; bzr push"
[15:31] <jroes> that's what I'm confused about I think :)
[15:31] <jam-laptop> jroes: The "changes in your working tree" is because you have local uncommitted changes
[15:31] <jam-laptop> If you want a big hammer
[15:31] <jam-laptop> you can
[15:31] <jam-laptop> bzr push --overwrite
[15:31] <jroes> right, so, bzr commit shows me "no changes to commit" :)
[15:31] <jam-laptop> And then it will throw away whatever is extra in the server side
[15:31] <jroes> I think I will use overwrite, unless I discovered a bug and you guys want me to preserve this state
[15:32] <jam-laptop> vila: I think it is a little odd to have a filesystem that you can write to, but you cannot see the files
[15:32] <jam-laptop> jroes: well, having merge complain about an unclean tree, but commit say nothing to commit is weird
[15:32] <jam-laptop> jroes: save it for a second
[15:32] <jam-laptop> bbiab
[15:32] <jroes> ok
[15:33] <jroes> too bad this particular local machine is windows, I don't think I have a bash_history here to see what exactly I did to repro :|
[15:33] <jam-laptop> C:\Documents and Settings\<username>\.bzr.log
[15:34] <jam-laptop> Or maybe it is in My Documents?
[15:34] <jam-laptop> I don't quite remember where it gets put
[15:34] <jroes> here's a pastebin so you guys can see what I'm talking about, I'll hunt down the log and see if I can copy the branch around and get the same results http://pastebin.com/m12f743c7
[15:35] <jroes> tbh, I wasn't really having a problem until recently, and I think this has to do with something previous where my repository lock file was unable to be accessed after I failed a merge somehow
[15:35] <jam-laptop> I think we try for "My Documents"
[15:35] <jroes> 'tis in My Documents
[15:36] <jam-laptop> jroes: can you do "bzr status" ?
[15:36] <jam-laptop> Having merge disagree with commit is really weird
[15:36] <jam-laptop> oh, and what "bzr --version" are you using?
[15:37] <jroes> bzr status works, there are a bunch of unknowns and a removed file, and 0.91.0
[15:37] <vila> jam-laptop: sure, but it goes for read-only filesystems too :) I'm a lazy guy, so as long as I could maintain the webdav plugin without list_dir and more importantly without parsing zml, I did, if that chnaged, I'll have to take a tour to the drawing board...
[15:37] <jam-laptop> vila: well, we know for a fact that we have http
[15:37] <jam-laptop> vila: and we aren't trying to get list_dir for readonly
[15:38] <jam-laptop> vila: obviously i don't know the webdav protocol
[15:38] <jam-laptop> I offered a semi-cludgy workaround by customizing it at the Transport layer
[15:38] <jam-laptop> but really, we *do* want to delete those files
[15:38] <jroes> I think all the problems really started when I got "ImmortalLimbo: Unable to delete transform temporary directory ..."
[15:38] <jam-laptop> It might be possible to write our own index of "things we renamed into this directory"
[15:38] <jam-laptop> but that can also get out of sync, etc.
[15:38] <jroes> oh, maybe I should have read "Please read the limbo file" :)
[15:39] <vila> jam-laptop: I understand and don't want to stop bzr going forward, webdav can well be freezed for a while, it's not as if hundreds of projects were using it daily :)
[15:40] <vila> I was just hoping to push it a bit more as soon as I get auth.ring landed and true https support, now I have just another bigger problem :)
[15:41] <jam-laptop> how bad is zml?
[15:41] <jam-laptop> Is it drastically different from XML?
[15:41] <dato> lifeless: your latest commit to bzr.dev has its NEWS entry under the old "IN DEVELOPMENT" (0.92); i don't know if the plan is to merge into 0.92, or a new "IN DEVELOPMENT" should have been created.
[15:41] <lifeless> its the key to the left
[15:42] <jam-laptop> Or is it like XHTML which is XML, but has specific tags you need to understand
[15:42] <mwhudson> ReadonlyTransportDecorator doesn't give wonderfully informative error messages
[15:42] <lifeless> dato: it's slated for 0.92
[15:42] <dato> ok
[15:42] <lifeless> pack disk changes::
[15:42] <lifeless> packs2:
[15:42] <lifeless>  - optional annotation cache
[15:42] <lifeless>  - remove list-dir? discussion needed on race conditions
[15:42] <lifeless>  - drop inventory parents data
[15:42] <lifeless> packs3:
[15:43] <lifeless>  - new inventory format
[15:43] <lifeless>  - arbitrary-parent delta's.
[15:43] <lifeless>  - 'pack' recompresses
[15:43] <lifeless> packs4:
[15:43] <lifeless>  - new delta-compression
[15:43] <lifeless> ---
[15:43] <lifeless> jam-laptop: ^ thats a strawman
[15:44] <jam-laptop> what are you thinking as a timeframe for this?
[15:44] <jam-laptop> 1 per month?
[15:44] <lifeless> yah, one per release
[15:45] <jam-laptop> What is the timeframe for getting retries working?
[15:45] <jam-laptop> As that would be #1 for me
[15:45] <lifeless> soon as you write the code ? :)
[15:45] <lifeless> retries don't need a new disk format...
[15:45] <lifeless> an alternative strategy for handliing old packs may remove the need to do that though
[15:46] <jroes> ok, I see, I hit that ImmortalLimbo error when merging in a branch with a bunch of files, then I just tried merging with the same branch again and I got an "Unable to obtain lock file" for repository/lock.  at which point I panicked (3am), and deleted the repo lock, and subsequently branch lock when I got the same lock error on that as well
[15:46] <jroes> ever since then, I've had that dissonance.  so, can I recreate my locks or is my branch entirely busted now? :)
[15:46] <jam-laptop> (jroes: for future reference you can use "bzr break-lock")
[15:47] <jam-laptop> And locks should automatically be replaced
[15:48] <jroes> hm. hmm
[15:48] <jam-laptop> jroes: had the dissonance that "bzr commit" says nothing to do, but "bzr merge" says there are changes?
[15:48] <jam-laptop> (again what does "bzr status" say?)
[15:49] <jroes> yeah
[15:49] <jam-laptop> lifeless: the "leave them in place but mark them absent in the names index" ?
[15:49] <lifeless> yah
[15:49] <jroes> bzr status right now shows 1 removed file and several unknowns
[15:50] <jroes> in fact, another developer's branch is in this same state now
[15:50] <jam-laptop> I guess I don't understand why "bzr status" would report changes, but "bzr commit" wouldn't commit them....
[15:51] <jam-laptop> You aren't doing anything like a partial commit, right?
[15:51] <jam-laptop> (bzr commit just-this-path)
[15:51] <jroes> I don't even know how to do a partial commit
[15:51] <jroes> but awesome I really wanted to know that last night :)
[15:55] <jam-laptop> lifeless: so I agree that the annotation cache should rate high in priority, especially before we have people start mass conversions from knits, and they lose all that data
[15:56] <jam-laptop> I would like to see the extra knit data added
[15:56] <jam-laptop> so that we can make the indicies fully redundant, and able to be regenerated
[15:56] <jam-laptop> I'm not sure where that fits with "drop inventory parents data"
[15:56] <jam-laptop> (but for that you are talking about the inventory ancestry graph, right?)
[15:58] <jam-laptop> And I assume by "pack recompresses" is that you mostly just want the wiring in place so we can see what layouts we want to use
[16:01] <jroes> hmm, so I tried to push the branch to a new location just for fun to see if you guys would run into the same problems if you did a get, and the push was successful, but when I tried to make a new branch I got a weird error about a directory not being empty  http://pastebin.com/m3783699b
[16:01] <poolie_> hi all
[16:02] <lifeless> jam-laptop: right, I'm talking about have compression info only for inventory storage
[16:02] <poolie_> jroes, could it be you already had a partly-created branch there?
[16:02] <lifeless> jam-laptop: by pack recompresses I mean doing your arbitrary-parent delta logic to get optimal storage.
[16:02] <jroes> I must have really hosed this thing somehow :)   the only other problems I had were sometimes I would do a bzr diff and my machine would practically lock up because it was doing diffs on binary files for some reason
[16:03] <jroes> poolie_: in the new remote location?
[16:03] <jroes> both the remote dir poundbzr and the local dir poundbzr did not exist before those operations
[16:04] <poolie_> hm
[16:05] <jroes> poolie_: let me get you up to date, here's another pastebin from earlier - merge and commit don't agree on my branch: http://pastebin.com/m12f743c7
[16:06] <jroes> theoretically you guys should be able to run "bzr branch http://jroes.net/jroes/poundbzr" in /tmp or wherever you like and get the same error I just got about directories not being empty
[16:06] <jroes> I wish this repo wasn't so large
[16:08] <jroes> but I guess I'm wrong because I just branched successfully :)
[16:08] <jam-laptop> jroes: well the url you just gave is giving me a 404
[16:08] <jam-laptop> Ah, but that is just because you have directory listings turned off
[16:08] <jroes> yeah :)
[16:09] <jam-laptop> http://jroes.net/jroes/poundbzr/.bzr/branch-format still shows up
[16:10] <jroes> ok, so in the parent directory where I did that first bzr branch, I have a .bzr directory, so I must have committed it to something at some point
[16:10] <jroes> which may be the root of all of my problems? :)
[16:10] <jelmer> LarstiQ, pingz0rz
[16:11] <LarstiQ> jelmer: pong
[16:12] <jelmer> LarstiQ, did you see the discussion on knitpack-richroot on the list? Can you perhaps comment on the state of subtrees?
[16:12] <LarstiQ> jelmer: I am not back to reading mail yet, so no. I'll have a look now.
[16:14] <jelmer> LarstiQ: Subject contains "Feedback on migration to bzr"
[16:15] <jam-laptop> hi LarstiQ  good to see you around
[16:15] <LarstiQ> jelmer: thanks
[16:15] <jam-laptop> I hope things are going well for you
[16:15] <LarstiQ> jam-laptop: responding on pings and working my way (slowly) through a bzr.dev merge etc
[16:15] <LarstiQ> jam-laptop: reasonably
[16:15] <LarstiQ> jam-laptop: how are you?
[16:16] <jam-laptop> pretty good, a little sleep deprived :)
[16:16] <jam-laptop> not terribly though
[16:40] <jroes> so, it's bad practice to have bzr branches within bzr branches, right?
[16:41] <gotgenes> jroes: why would you have a branch within a branch?
[16:43] <jroes> I have a src directory branch and then I have a branch for one of the projects
[16:44] <jroes> the src branch is just kind of for keeping track of everything in my src directory for myself, and then the other branches were for the specific projects, but I don't know if this is really necessary :)
[16:45] <gotgenes> jroes: Ah, I see. My understanding of the Bazaar workflow shows that maybe you should break the src up into individual branches, one per project
[16:46] <LarstiQ> jroes: you can do that, but the containing branch will not track the contained ones just yet, you still have to do that manually.
[16:56] <lifeless> jam-laptop: so that strawman works for you?
[17:10] <schierbeck> jelmer: ping
[17:11] <jelmer> schierbeck, pong
[17:11] <schierbeck> have you looked at my latest logview changes?
[17:11] <schierbeck> i think it's turning out pretty good
[17:11] <jelmer> not yet, sorry
[17:11] <schierbeck> :P
[17:11] <jelmer> will have a look this evening
[17:11] <schierbeck> great
[17:12] <jelmer> what tz are you in?
[17:12] <schierbeck> +2
[17:12] <schierbeck> copenhagen
[17:12] <jelmer> ah, ok - same here
[17:26] <james_w> poolie_: the packaging session is at 2 in the room next to the lp room.
[17:28] <fullermd> What are they packaging the attendants in, and will there be pictures?   ;)
[17:37] <lifeless> hi coffeedude
[17:38] <lifeless> welcome to the house of fun :)
[17:38] <lifeless> abentley: ping; I want to express fetch-ghosts in bzr core; do you think an option to pull/push, or a new command is better ?
[17:38] <coffeedude> hey lifeless
[17:39] <lifeless> I've just droped about 90% overhead in local pack based merges :)
[17:40] <fullermd> Well, only 10% to go!
[17:41] <lifeless> 3 seconds to merge trivial change between two python full-history imports
[17:41] <fullermd> Nifty.
[17:42] <lifeless> bit slow still
[17:42] <lifeless> we're still doing an inventory upcast/downcast
[17:42] <lifeless> I think it should be < 2 seconds eventually
[17:43] <lifeless> < 1 second once the journalled inventory/split inventory stuff is done
[17:45] <fullermd> That interests me.  AIUI, that should really help us with broad trees with deep history, to say nothing of the annoying even on small trees "can't log multiple files".
[17:46] <lifeless> yes
[17:48] <fullermd> Eggselent.
[17:55] <ubotu> New bug: #158774 in bzr "no UI for fetching/filling in ghosts" [Undecided,New] https://launchpad.net/bugs/158774
[18:50] <Alien_Freak> so... .. i'm very new at this, but for now, I just want to import my code into an bzr repo that i have on a remote server, I did the init-repo and init and I have a project.stable  which I want to import all the files I currently have in a certain directory....
[18:50] <Alien_Freak> what's my next step? ... check out right?
[18:50] <beuno> Alien_Freak, bzr add
[18:50] <fullermd> Why not just create the branch in place?
[18:50] <fullermd> You can push it off into a repo somewhere else later if you want, but why not keep it simple to start?
[18:51] <Alien_Freak> beuno, I have bzr/project/project.stable as an initialized project on a remote machine... and i have my trunk/ in my home dir... bzr add wont work... unless it knows what repo it needs to add the files too..... at least i think
[18:52] <gotgenes> Can bzr do replacement of variables such as $Revision$ and like SVN?
[18:53] <fullermd> gotgenes: Keyword substitution.  No.
[18:55] <gotgenes> fullermd: :-( Is it a planned feature?
[18:55] <lifeless> somewhat
[18:55] <lifeless> its a bit contentious, have a look at bzr version0info though which may do what you want
[18:55] <lifeless> Alien_Freak: 'bzr init; bzradd; bzr commit'
[18:56] <beuno> Alien_Freak, it adds it to the directory you are currently in recursively
[18:56] <lifeless> Alien_Freak: we have a getting started guide you might find useful
[18:56] <beuno> as fullermd pointed out, it's probably best for you to create it locally and then push it
[18:57] <Alien_Freak> yah,.. i probably should look into that...the whole branching tidbit.. is confusing me somewhat
[19:02] <lifeless> Alien_Freak: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
[19:06] <Alien_Freak> is there a book on bzr yet?  just curious..
[19:12] <james_w> thanks poolie_.
[19:24] <lifeless> jam-laptop: so does that strawman work for you ?
[19:24] <jam-laptop> lifeless: well, you didn't respond to my comments
[19:24] <jam-laptop> Like when putting the extra data into the pack would land
[19:24] <jam-laptop> (extra index data)
[19:25] <jam-laptop> But as an 30-mile view it seems fine.
[19:27] <lifeless> oh, I missed that. I was figuring that the replacement delta work would include that
[19:28] <lifeless> re: the merge/fetch performance fix. I'm confused about where I'm using a generator [in that patch, not in the index layer]
[19:28] <lifeless> jam-laptop: ^
[19:32] <jam-laptop> keys = ((key,) for key in need_revs)
[19:33] <jam-laptop> let me check the exact line
[19:33] <jam-laptop> lifeless: in your commit you changed target_keys =list ((key,) for key in next_revs)
[19:34] <jam-laptop> to target_keys = ((key,) for key in next_revs)
[19:34] <jam-laptop> When I recommended
[19:34] <jam-laptop> target_keys = [(key,) for key in next_revs)
[19:34] <jam-laptop> target_keys = [(key,) for key in next_revs]
[19:35] <jam-laptop> lifeless: "the replacement delta work would include that", is that "pack4" then?
[19:41] <lifeless> yes, pack4
[19:41] <lifeless> jam-laptop: ah, generator there - got you, sure thing.
[19:41] <jam-laptop> It seems a bit more important than waiting that long... but maybe not a big deal.
[19:42] <lifeless> and I've just made revert 10 times faster :)
[19:42] <jam-laptop> jelmer: I'm trying to understand some of your changes to my submission
[19:43] <jelmer> gcommit you mean?
[19:43] <jam-laptop> for example, you seem to have "from bzrlib.plugins.gtk.window import Window"
[19:43] <jam-laptop> but I don't have a window.py file
[19:43] <jam-laptop> jelmer: yes
[19:43] <jelmer> jam-laptop: What upstream branch are you using?
[19:44] <jam-laptop> jelmer: I'm just trying to merge your bundle into my branch
[19:44] <jam-laptop> I'm not using an upstream yet
[19:44] <jelmer> my bundle was against upstream
[19:44] <jelmer> not against your branch
[19:44] <jam-laptop> sure, but it should pull both into my branch
[19:44] <jam-laptop> i'm just doing "bzr merge"
[19:44] <jam-laptop> that is why things are weird
[19:44] <jelmer> and that works without errors?
[19:44] <jam-laptop> it should
[19:44] <jam-laptop> it works with normal branches
[19:45] <jam-laptop> (I had to update my repository to contain the bzr-gtk trunk revisions)
[19:45] <jelmer> it shouldn't contain the upstream revisions
[19:45] <jelmer> ah, ok
[19:45] <jam-laptop> but conceptually it shouldn't change the merge
[19:45] <jam-laptop> Which is sort of weird
[19:45] <jam-laptop> because I got a lot of conflicts
[19:45] <jam-laptop> And if you had merged me
[19:45] <jam-laptop> I would have thought it would pick a common ancestor
[19:45] <jam-laptop> that wouldn't break like this
[19:46] <jam-laptop> maybe bzr-gtk has some criss-crosses that are confusing the common ancestor code?
[19:47] <jelmer> have you tried merging my bundle against trunk? Does that work better?
[19:48] <jam-laptop> now that is weird....
[19:48] <jam-laptop> When I merged the bundle
[19:48] <jam-laptop> I was getting conflicts
[19:48] <jam-laptop> when I create a local branch using "bzr pull --overwrite bundle"
[19:48] <jam-laptop> and then merge
[19:48] <jam-laptop> it goes clean
[19:49] <jam-laptop> And it is fully reproducible
[19:49] <jam-laptop> really weird
[19:55] <lifeless> vila: grep for is_permament in errors.py
[19:56] <jelmer> hmm, wouldn't know
[19:57] <lifeless> jamesh: ^
[19:57] <jam-laptop> jelmer: it seems to be a problem with bzr itself, not related to you
[19:57] <jam-laptop> I'm sending a bug to the ML
[19:57] <vila> lifeless: yes, may not be worth an attribute, worth an additional FIXME in comment as I don't think it will be needed for handling the decorator/redirection bug
[19:58] <jelmer> jam-laptop: sounds odd though
[19:58] <jam-laptop> yeah
[19:58] <vila> lifeless: does that answer  your ping ?
[20:04] <lifeless> vila: well, I think the spelling error should be fixed
[20:05] <jam-laptop> jelmer: did you do a cherrypick send?
[20:05] <vila> geeee, bloody completion, had to read it 10 times :)
[20:06] <vila> at least the user visible part is correct :)
[20:06] <jam-laptop> hmm... probably not
[20:06] <jam-laptop> but I think i figured it out
[20:06] <jelmer> jam-laptop: nope, send with bzr-gtk's trunk as submit branch
[20:06] <jam-laptop> jelmer: I believe the send code is creating a "base_revision_id" which is causing it to force a cherry pick
[20:06] <jelmer> hmm
[20:06] <jelmer> actually
[20:06] <jelmer> I may have used gsend
[20:07] <jam-laptop> jelmer: regular "bzr send" does it too
[20:08] <jam-laptop> I think I've worked out the problems
[20:08] <jam-laptop> I'll send a bug email
[20:11] <jamesh> jam-laptop: by the way, I have a bunch of changes/improvements to bzr-pqm that'd be good to review/merge
[20:12] <jamesh> jam-laptop: as well as cleaning things up, it adds tests
[20:12] <jamesh> and makes it share more bzrlib infrastructure with the merge directive code
[20:14] <jam-laptop> jamesh: good to hear, thanks for working on it
[20:18] <radix> lifeless: !?!?!
[20:18] <radix> bug #152008
[20:18] <ubotu> Launchpad bug 152008 in bzr "Ability to unmerge or revert a merge sensibly" [Wishlist,Fix released] https://launchpad.net/bugs/152008
[20:19] <radix> how's it fixed? I'd really like to use it
[20:19] <lifeless> radix: bzr ervert --forget-merges
[20:19] <lifeless> oh damn, misread the bug
[20:19] <radix> lifeless: erm, that doesn't ...
[20:19] <radix> :)
[20:41] <ubotu> New bug: #158820 in bzr "[BUG] Merging an MD into a different branch causes a cherrypick" [Medium,Triaged] https://launchpad.net/bugs/158820
[20:43] <lifeless> wtf is an MD  ?
[20:43] <jam-laptop> Merge Directive
[20:43] <lifeless> oh
[20:43] <lifeless> acronyms ftl
[20:44] <fullermd> IOTTMCO   :p
[20:44] <jam-laptop> but of course
[20:44] <jam-laptop> fullermd: well, at least with a google search :)
[20:45] <Odd_Bloke> Heh, 'wtf', 'ftl' FTS.
[20:45] <jam-laptop> hmm, my 'wtf' doesn't have IOTTMCO or "FTL"
[20:45] <jam-laptop> maybe I need to update
[20:46] <ubotu> New bug: #158824 in bzr "AssertionError after failure to find host" [Undecided,New] https://launchpad.net/bugs/158824
[20:46] <fullermd> I don't remember where I picked up IOTTMCO.  I've been carting it around since I was a kid.
[20:50]  * beuno googles IOTTMCO and feels stupid
[20:50] <jam-laptop> jelmer: there was a test in "tests/test_viz.py" which was testing "DummyRevision" from viz/linegraph.py
[20:50] <jam-laptop> wait, graph.py
[20:50] <jam-laptop> anyway, there is no DummyRevision anymore
[20:50] <jam-laptop> should the test just be deleted?
[20:51] <jam-laptop> (As it stands, I can't run the test suite)
[20:51] <jam-laptop> Which i think shows that the bzr-gtk folks aren't in the habit of running the test suite before the commit to trunk
[20:51] <jam-laptop> One other thing my patch introduced was
[20:51] <jam-laptop> 'bzr test-gtk'
[20:51] <jam-laptop> which only runs the gtk test suite
[20:52] <jam-laptop> which is a *lot* faster than loading all of the bzr test suite, just to run gtk (bzr selftest gtk)
[20:53] <jelmer> jam-laptop: no, I wrote some initial tests about half a year ago, but nobody has touched it since
[20:53] <jelmer> the test for DummyRevision should probably be removed, indeed
[20:56] <lifeless> jelmer: please try packs with my repository branch again
[20:56] <lifeless> jelmer: commit/branch/push/pull/merge/revert should now me acceptably fast for you
[20:57] <jelmer> lifeless: what was the url again?
[20:58] <lifeless> jelmer: people.ubuntu.com/~robertc/baz2.0/repository
[21:28] <aconbere> does anyone have a link to documentation regarding group or paired use workflow? the documentation have a picture, but doesn't describe how you might want to host the share repository, or how you would resource a users branch and those kinds of actual implimentation details.
[21:35] <lifeless> aconbere: not sure if we have that or not; have you looked at the users guide?
[21:37] <lifeless> jelmer: where is your bzr-dbus branch, for bzr-gtk commit-notify to work
[21:37] <aconbere> lifeless: yeah the user guide helps me figure out how to make branches, and merge, and all the things I already know how to do with svn, but I just don't have any clue how you set up a group work environement
[21:38] <aconbere> I presume doing something like... hosting the main branch in apache, with apache mod auth to protect it?
[21:38] <jelmer> lifeless: that's a good question
[21:38] <lifeless> aconbere: I'm not sure whyt you'd need auth
[21:39] <lifeless> aconbere: unless is private code on the internet; in which case you probably want https and auth
[21:40] <aconbere> lifeless: it's private code for a small group of people
[21:40] <aconbere> but we have to share it somehow over great distances
[21:40] <aconbere> in my experience the way one does this is either through tcp/ip and in general these days using http :)
[21:40] <aconbere> (and yes I would also pass that over https)
[21:41] <aconbere> (extra either snuck in there)
[21:43]  * fullermd would just do it over ssh...
[21:44] <aconbere> that sounds like a terrifying hassle to add new people to the project :P
[21:44] <aconbere> not only that but I would be granting full machine access to every member
[21:45] <aconbere> I mean... maybe this is not a user case that Bazaar was designed for, I can keep using SVN, but I was hoping to get an idea of how to better utilize these tools, and with the way our teams are I think it would make more sense.
[21:46] <lifeless> aconbere: i would just put it on a webserver
[21:46] <lifeless> aconbere: then every team member can pull from it
[21:46] <fullermd> Well, you can give them a restricted shell that only allows running bzr and/or sftp.  Me, I tend to solve that problem via social means (to wit; I know where they live  ;)
[21:46] <lifeless> to get their code back they can send bundles easily
[21:47] <lifeless> bzr+ssh/sftp is nice though because it allows read-*write* access
[21:47] <lifeless> gotta go; ciao
[21:47] <lifeless> jelmer: let me know about bzr-dbus and packs please.
[21:49] <fullermd> The real problem is that the question "how do I set it up" is heavily dependant on the answer to "how do I want to work", which is a terribly unfair question to pose to somebody who doesn't already know bzr well enough to understand the myriad choices.
[21:50] <fullermd> One way is as lifeless said; you just put the branch up on a http server somewhere where everybody [or auth'd to only the somebodies] can read it, then you (or a member of a small group with access) can merge other people's work into and update it.
[21:51] <fullermd> Another way is a shared branch that a bunch of people can write, which mostly means bzr+ssh/sftp, though I think you could do very gross stuff with bzr:// or somewhat less gross stuff with bzr+http:// to open up writability.
[21:52] <fullermd> The difficulty around that is that bzr doesn't have any capability of doing AAA, so the protocol around it has to handle that (which is what's nice about ssh/sftp)
[21:58] <jam-laptop> well, you could set up the bzr smart server over https and have it enabled for writing
[21:59] <jam-laptop> I haven't done it in a while, but it has worked
[21:59] <jam-laptop> as an alternative to giving them ssh accounts
[22:02] <aconbere> fullermd: what does AAA mean?
[22:03] <fullermd> Authentication, Authorization, Accounting
[22:04] <fullermd> At present, ssh/Apache/firewall handles Authentication, filesystem permissions provide Authorization, and Accounting is mostly done by the transport protocol too.
[22:05] <fullermd> jam-laptop: I'm often glad I skipped svn, just for the fact that I don't look at "http://..." and think "Oh, yeah, that's writable"   :p
[22:06] <jam-laptop> I can say back when I tried to set up svn, it wasn't all that easy to make it writable
[22:08] <beuno> jam-laptop, I've tried making bzr smart server provide writing over http a few months ago, and I just kept on running into new problems (that's why I updated documentation on it). At the end, I ran into a brick wall (can't find the bug number)
[22:20] <gotgenes> jelmer: Is v0.4.4 of bzr-svn really incompatible with bzr v0.91?
[22:20] <jelmer> yes
[22:20] <gotgenes> :-(
[22:20] <jam-laptop> beuno: something about the paths not matching, iirc
[22:20] <jelmer> gotgenes: there have been a couple of API changes in 0.92 that bzr-svn had to be fixed for
[22:21] <jam-laptop> I remember spiv looking into it
[22:21] <gotgenes> jelmer: I suppose it couldn't support both APIs.
[22:21] <gotgenes> I have been hoping for the 0.92rc1 debs to hit the bazaar-vcs repos but no luck so far
[22:22] <jelmer> gotgenes: 0.4.4 isn't out yet either
[22:23] <gotgenes> jelmer: I've been pulling from your 0.4 branch as you told me yesterday
[22:23] <jelmer> gotgenes: It could support both API's, but maintaing support for both would be a maintainance hell
[22:23] <jelmer> gotgenes: You should be able to run bzr from bzr.dev as well
[22:23] <beuno> jam-laptop, yup, but the end result was it impossible to push via http. I could give it another try if it needs testing. I gave up on it since no one had time to work on it at the time.
[22:24] <gotgenes> jelmer: I understand about the API support. I suppose the API will keep changing frequently until bzr v1.0
[22:25] <gotgenes> I really prefer debs for system cleanliness
[22:25] <fullermd> gotgenes: You don't have to _install_ it; you can just run it out of the source tree until 0.92 debs show up.
[22:30] <jelmer> gotgenes: 0.4.4 and 0.92 shouldn't be too far off, will both be released within about two weeks
[22:36] <gotgenes> fullermd: what's the best way to use it without installing? place it in /usr/local/lib/python2.5/site-packages/ ?
[22:36] <aconbere> huh
[22:36] <fullermd> Nah, just stick it in your homedir.
[22:37] <fullermd> I run bzr.dev out of ~/src/bzr/bzr.dev, with a shell alias intercepting 'bzr'.
[22:37] <aconbere> I'm not sure I get it how people pass their data around, merge branches with eachother
[22:37] <aconbere> it doesn't seem trvial to share the branches
[22:38] <fullermd> People can do it by putting a branch on a web server somewhere and pointing people at it, or by sending bundles via email.
[22:39] <jelmer> lifeless: find_ghosts is great
[22:39] <lifeless> mm?
[22:40] <jelmer> bzr up/pull for svn branches went from 10 to <1 second
[22:40] <jelmer> (when it's a no-op)
[22:40] <lifeless> nice
[22:40] <schierbeck> jelmer: hello
[22:40] <jelmer> hey schierbeck
[22:40] <schierbeck> i've sent in a version without the changes page
[22:40] <Peaker> hey, me and my friend both have bzr 0.90.0 and when he tries to pull a branch from me into a repo he just init-repo'd he's getting an error about repo format
[22:41] <n04m> bzr: ERROR: Repository KnitRepository('file:///home/noam/enough/bzr/repo/.bzr/') is not compatible with repository KnitRepository3('http://nextflow.dyndns.org/bzr/enough/.bzr/')
[22:41] <n04m> that's the error
[22:41] <Peaker> bzr upgrade --dirstate-tags .   says "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
[22:42] <jelmer> you need "bzr upgrade --dirstate-with-subtree"
[22:42] <jelmer> if the branch you're pulling was created using bzr-svn
[22:42] <n04m> bzr uses a different format when pulling from svn?
[22:43] <jelmer> bzr-svn requires a new bzr disk format
[22:43] <n04m> jelmer: yeah, it works now
[22:43] <Peaker> jelmer: I think that bzr should probably point the user to that command - I thought the --dirstate-tags was the one, but there's really no way for a user to figure it out just from bzr's output
[22:43] <n04m> dirstate-with-subtree is newer than dirstate-tags?
[22:44] <n04m> i agree, besides asking here there's no way we could hav efigured that out
[22:44] <jelmer> Peaker: we're currently discussing that on the development list
[22:44] <Peaker> jelmer: ah, ok, thanks
[22:44] <n04m> jelmer: ok, thank you
[22:44] <jelmer> bzr-svn's FAQ contains it (but will only be included starting 0.4.4)
[22:45] <lifeless> ok, dinner time
[22:45] <schierbeck> jelmer: could i get you to approve the new version? the  i'll merge it right away
[22:45] <fullermd> Shows why I object to rollup format names   :p
[22:46] <jelmer> schierbeck: yep, will have a look
[23:02] <jelmer> lifeless: I don't tihnk there were any special requirements for bzr-dbus
[23:02] <n04m> jelmer: hi, another question/comment
[23:03] <jelmer> lifeless: default trunk doesn't owkr?
[23:03] <n04m> i'm doing a 40MB bzr pull and the progress report is "stuck" for quite a while
[23:03] <mc_> can i tell bzr somehow to remember my password?(using sftp for pulling)
[23:03] <n04m> it would be nice to have some information (such as: bytes downloaded) being updated continuously so i won't worry about something going wrong
[23:04] <Peaker> mc_: I asked the same and someone told me its coming real soon - you can put your public key in the remote ~/.ssh/authorized_keys2
[23:04] <Peaker> mc_: for password-less login
[23:05] <mc_> Peaker: well but that would only work if i would use key authentification instead of passwords i guess?
[23:05] <Peaker> mc_: That's what ~/.ssh/authorized_keys2 is for -- key authentication instead of password auth
[23:06] <n04m> jelmer: ack?
[23:06] <jelmer> n04m, see peakers' answer
[23:07] <Peaker> I didn't answer anything about  bzr progress report   I think it could be nice if bzr had one :)
[23:12] <jelmer> there's been some discussion about improving progress reports as well, not sure what the status on that is
[23:12] <n04m> jelmer: thanks.
[23:27] <Peaker> not really bzr related, but I'd like the umask of bzr+ssh:// dirs created to have g+w, which file would that be on an Ubuntu system?
[23:28] <fullermd> Your shell rc file, I presume.
[23:29] <fullermd> I'd imagine there's some env variable or other you could trigger off.
[23:30] <fullermd> (of course, if this is in a branch, it'll happen by itself)
[23:32] <Peaker> why would push to a remote branch fail with: Generic bzr smart protocol error: Permission denied: u'...../.bzr/repository/lock/8xnfe7p211.tmp': [Errno 13] Permission denied ?
[23:32] <Peaker> fullermd: ah forgot about the versioning of file modes
[23:32] <fullermd> They're not versioned, they're just used as a template.
[23:32] <fullermd> I'll go out on a limb and guess it's cuz permissions were denied   ;)
[23:33] <abentley> Peaker: It's easy to write a shell wrapper around bzr that sets the umask, and use that for ssh.
[23:33] <fullermd> Probably don't have +w on the lock dir.
[23:33] <Peaker> oops I am dumb, sorry :)
[23:34] <Peaker> I thought I had the entire hierarchy set to that group, but appearantly I did it too deep
[23:39] <fullermd>  27151 inconsistent parents
[23:39] <fullermd>  27151 file versions are not referenced by their inventory
[23:39] <fullermd> wuff.
[23:41] <fullermd> Pretty impressive, for a tree with under 400 revisions...
[23:41] <Peaker> hmm all users' umask is now 0002, but the directories created over bzr+ssh://  still have g-w
[23:41] <Peaker> unix permissions are annoying :-)
[23:45] <Peaker> so its not the umask - what mode does bzr+ssh:// use for directories it makes? how do I change that?
[23:47] <fullermd> Last I checked, it inherited from the dir they went in.
[23:48] <fullermd> umask would only come into play when making new directories with no higher power to guide it (like init/new-push)
[23:49] <Peaker> the dir its making it in has:   drwxrwsr-x  but its being made as  drwxr-sr-x  (umask is 0002)
[23:51] <lifeless> jelmer: LanGateway.start does not exist in my bzr-dbus
[23:54] <jelmer> lifeless: looks like I hadn't uploaded it yet, so I just did
[23:54] <jelmer> it's at http://people.samba.org/bzr/jelmer/bzr-dbus/trunk
[23:54] <jelmer> not registered at launchpad, because it seems to be oopsing on me again
[23:54] <lifeless> :(
[23:57] <lifeless> oh heh it was in the dbus trunk on the web
[23:57] <lifeless> I forgot I wasn't the only one pushing there :)
[23:58] <jelmer> thinking about it
[23:58] <jelmer> I think you actually gave +1 for that change in Vilnius
[23:59] <jelmer> my branch is also registered now, the launchpad web ui seems to like me better