| 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:21 |
| 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:23 |
| Peaker | cool, thanks | 00:24 |
| Peaker | I love bzr! :-) | 00:28 |
| Peaker | The horror of using svn because of googlecode.. for weeks! | 00:28 |
| arjenAU | Peaker: so access the svn repos from bzr | 00:38 |
| 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:39 |
| 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? | 00:40 |
| === mw is now known as mw|out | ||
| 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:03 |
| 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:04 |
| 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:12 |
| Peaker | fullermd: ah cool thanks | 01:15 |
| Peaker | then it seems I dont have to write a plugin :-) | 01:16 |
| 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:33 |
| 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. | 01:34 |
| Peaker | How do you run "bzr serve" over ssh? How is access control done? | 03:03 |
| 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:06 |
| 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:07 |
| Peaker | (relative would be relative to user's home dir, I'd suppose) | 03:08 |
| 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:11 |
| 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:22 |
| 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:24 |
| Peaker | jelmer: thanks that works :) I wonder if that will piss them off.. heh | 03:27 |
| Peaker | doesn't seem like shell.sf.net is a usable file host for bzr, its taking ages to do anything | 03:30 |
| 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:31 |
| 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:32 |
| 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:34 |
| Peaker | according to the bug I can use sftp to explicitly create repositories | 03:36 |
| jelmer | well, you can on an ordinary sftp server, but not on launchpad | 03:37 |
| Peaker | weird, how does their sftp prevent it? | 03:37 |
| 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:38 |
| Peaker | I see | 03:42 |
| Peaker | can I tell a branch to move its head back without creating a new revision that's identical to previous revisions? | 04:09 |
| Peaker | I could create a new branch but the branch is already there and advertised as a main branch.. | 04:10 |
| 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:11 |
| Peaker | Without bzr diff | patch in-new-branch ? | 04:12 |
| 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:13 |
| Peaker | well actually I made a branch that contains them now, so they wouldn't be ghosts | 04:14 |
| Peaker | does bzr have nested checkouts? (if I want to split my repo into 3 for each of the components) | 05:11 |
| jelmer | Peaker: partially | 08:55 |
| jelmer | Peaker: it's somewhat supported, but still experimental | 08:55 |
| ubotu | New bug: #158596 in bzr "`bzr info -v` is not working if WT4 is locked." [Undecided,New] https://launchpad.net/bugs/158596 | 10:20 |
| === LarstiQ_ is now known as LarstiQ | ||
| === weigon__ is now known as weigon | ||
| 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:36 |
| 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:37 |
| 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:38 |
| jelmer | or lp:bzr-svn | 11:39 |
| mwhudson | ok | 11:39 |
| mwhudson | ah, lovely, a segfault when i C-c-ed the fetching revision info step | 11:50 |
| mwhudson | jelmer: hm, seems to be doing the 'finding branches' thing twice | 11:54 |
| jelmer | hmm, it shouldn't do the finding branches more than once | 11:55 |
| mwhudson | it's doing it a third time now | 11:56 |
| jelmer | this is during a push or a pull? | 11:57 |
| mwhudson | push | 11:57 |
| jelmer | but you've never pulled this particular branch before? | 11:58 |
| 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 | 11:59 |
| 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:00 |
| 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:02 |
| 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:03 |
| 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:06 |
| mwhudson | i have one level less of */ | 12:07 |
| mwhudson | maybe this is because i fed it a bogus url to start with? | 12:07 |
| 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:08 |
| mwhudson | it's a fairly chaotic repo :) | 12:09 |
| jelmer | simply removing "scheme = " from ~/.bazaar/subversion.conf will make it try again | 12:09 |
| jelmer | or rather, set it to "trunk3" | 12:10 |
| mwhudson | ok, i managed to get the branch now | 12:12 |
| mwhudson | pushing is doing the finding branches thing again | 12:14 |
| jelmer | more than once? | 12:15 |
| mwhudson | not yet | 12:16 |
| mwhudson | it's going slowly this time | 12:16 |
| mwhudson | i guess the extra level of */ gives it a lot more locations to consider? | 12:21 |
| mwhudson | jelmer: http://rafb.net/p/9RE7Or87.html | 12:22 |
| 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:24 |
| === mrevell is now known as mrevell-lunch | ||
| mwhudson | jelmer: will let you know :) | 12:27 |
| mwhudson | jelmer: yes, seem reproducible | 12:34 |
| jelmer | mwhudson: ok, guess I have a new bug to work on then.. thanks! | 12:37 |
| 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:38 |
| 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:41 |
| mwhudson | jelmer: yes | 12:42 |
| === mrevell-lunch is now known as mrevell | ||
| schierbeck | jelmer: ping | 13:23 |
| === mw|out is now known as mw | ||
| ubotu | New bug: #158690 in bzr "ls --non-recursive PATH : no list" [Undecided,New] https://launchpad.net/bugs/158690 | 14:15 |
| jelmer | schierbeck: pong | 14:42 |
| vila | lifeless: ping | 14:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:56 | |
| 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:57 |
| 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:58 |
| vila | And the other hand webdav is happy to delete a whole tree, (i.e. the obsolete dir even if not empty) | 14:59 |
| 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:04 |
| vila | permission handling is already messy when using a web server... | 15:06 |
| 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:09 |
| 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:10 |
| 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:11 |
| lifeless | jroes: you don't need to run update for other people to be able to pull from it | 15:12 |
| 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:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| * jroes will grep his .shell_history | 15:18 | |
| vila | lifeless: hehe, sure, pfs_dav.c trivially implemented pfs_directory_files by..... relying on neon :-) | 15:19 |
| lifeless | vila: oops, well. | 15:19 |
| 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:20 |
| * 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| vila | jroes: dont' do that :) We have time to solve our issue | 15:27 |
| gotgenes | lifeless: any chance of a 0.92rc1 deb today? =-) | 15:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| jam-laptop | And locks should automatically be replaced | 15:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:55 |
| 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:56 |
| 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 | 15:58 |
| 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:01 |
| 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:02 |
| 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:03 |
| poolie_ | hm | 16:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| jam-laptop | http://jroes.net/jroes/poundbzr/.bzr/branch-format still shows up | 16:09 |
| 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:10 |
| LarstiQ | jelmer: pong | 16:11 |
| 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:12 |
| jelmer | LarstiQ: Subject contains "Feedback on migration to bzr" | 16:14 |
| 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:15 |
| jam-laptop | pretty good, a little sleep deprived :) | 16:16 |
| jam-laptop | not terribly though | 16:16 |
| jroes | so, it's bad practice to have bzr branches within bzr branches, right? | 16:40 |
| gotgenes | jroes: why would you have a branch within a branch? | 16:41 |
| jroes | I have a src directory branch and then I have a branch for one of the projects | 16:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| lifeless | jam-laptop: so that strawman works for you? | 16:56 |
| schierbeck | jelmer: ping | 17:10 |
| 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:11 |
| jelmer | what tz are you in? | 17:12 |
| schierbeck | +2 | 17:12 |
| schierbeck | copenhagen | 17:12 |
| jelmer | ah, ok - same here | 17:12 |
| james_w | poolie_: the packaging session is at 2 in the room next to the lp room. | 17:26 |
| fullermd | What are they packaging the attendants in, and will there be pictures? ;) | 17:28 |
| lifeless | hi coffeedude | 17:37 |
| 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:38 |
| lifeless | I've just droped about 90% overhead in local pack based merges :) | 17:39 |
| fullermd | Well, only 10% to go! | 17:40 |
| lifeless | 3 seconds to merge trivial change between two python full-history imports | 17:41 |
| fullermd | Nifty. | 17:41 |
| 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:42 |
| lifeless | < 1 second once the journalled inventory/split inventory stuff is done | 17:43 |
| 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:45 |
| lifeless | yes | 17:46 |
| fullermd | Eggselent. | 17:48 |
| ubotu | New bug: #158774 in bzr "no UI for fetching/filling in ghosts" [Undecided,New] https://launchpad.net/bugs/158774 | 17:55 |
| 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:50 |
| 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:51 |
| gotgenes | Can bzr do replacement of variables such as $Revision$ and like SVN? | 18:52 |
| fullermd | gotgenes: Keyword substitution. No. | 18:53 |
| 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:55 |
| 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:56 |
| Alien_Freak | yah,.. i probably should look into that...the whole branching tidbit.. is confusing me somewhat | 18:57 |
| lifeless | Alien_Freak: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html | 19:02 |
| Alien_Freak | is there a book on bzr yet? just curious.. | 19:06 |
| james_w | thanks poolie_. | 19:12 |
| 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:24 |
| jam-laptop | But as an 30-mile view it seems fine. | 19:25 |
| lifeless | oh, I missed that. I was figuring that the replacement delta work would include that | 19:27 |
| 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:28 |
| jam-laptop | keys = ((key,) for key in need_revs) | 19:32 |
| 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:33 |
| 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:34 |
| jam-laptop | lifeless: "the replacement delta work would include that", is that "pack4" then? | 19:35 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| jam-laptop | maybe bzr-gtk has some criss-crosses that are confusing the common ancestor code? | 19:46 |
| jelmer | have you tried merging my bundle against trunk? Does that work better? | 19:47 |
| 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:48 |
| jam-laptop | And it is fully reproducible | 19:49 |
| jam-laptop | really weird | 19:49 |
| lifeless | vila: grep for is_permament in errors.py | 19:55 |
| jelmer | hmm, wouldn't know | 19:56 |
| 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:57 |
| jelmer | jam-laptop: sounds odd though | 19:58 |
| jam-laptop | yeah | 19:58 |
| vila | lifeless: does that answer your ping ? | 19:58 |
| lifeless | vila: well, I think the spelling error should be fixed | 20:04 |
| jam-laptop | jelmer: did you do a cherrypick send? | 20:05 |
| vila | geeee, bloody completion, had to read it 10 times :) | 20:05 |
| 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:06 |
| jam-laptop | jelmer: regular "bzr send" does it too | 20:07 |
| jam-laptop | I think I've worked out the problems | 20:08 |
| jam-laptop | I'll send a bug email | 20:08 |
| jamesh | jam-laptop: by the way, I have a bunch of changes/improvements to bzr-pqm that'd be good to review/merge | 20:11 |
| 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:12 |
| jam-laptop | jamesh: good to hear, thanks for working on it | 20:14 |
| 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:18 |
| 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:19 |
| 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:41 |
| lifeless | wtf is an MD ? | 20:43 |
| jam-laptop | Merge Directive | 20:43 |
| lifeless | oh | 20:43 |
| lifeless | acronyms ftl | 20:43 |
| fullermd | IOTTMCO :p | 20:44 |
| jam-laptop | but of course | 20:44 |
| jam-laptop | fullermd: well, at least with a google search :) | 20:44 |
| 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:45 |
| 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:46 |
| * 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:50 |
| 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:51 |
| jam-laptop | which is a *lot* faster than loading all of the bzr test suite, just to run gtk (bzr selftest gtk) | 20:52 |
| 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:53 |
| 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:56 |
| jelmer | lifeless: what was the url again? | 20:57 |
| lifeless | jelmer: people.ubuntu.com/~robertc/baz2.0/repository | 20:58 |
| 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:28 |
| lifeless | aconbere: not sure if we have that or not; have you looked at the users guide? | 21:35 |
| 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:37 |
| 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:38 |
| lifeless | aconbere: unless is private code on the internet; in which case you probably want https and auth | 21:39 |
| 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:40 |
| aconbere | (extra either snuck in there) | 21:41 |
| * fullermd would just do it over ssh... | 21:43 | |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| === bac_afk_ is now known as bac | ||
| 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:52 |
| jam-laptop | well, you could set up the bzr smart server over https and have it enabled for writing | 21:58 |
| 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 | 21:59 |
| aconbere | fullermd: what does AAA mean? | 22:02 |
| fullermd | Authentication, Authorization, Accounting | 22:03 |
| fullermd | At present, ssh/Apache/firewall handles Authentication, filesystem permissions provide Authorization, and Accounting is mostly done by the transport protocol too. | 22:04 |
| 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:05 |
| jam-laptop | I can say back when I tried to set up svn, it wasn't all that easy to make it writable | 22:06 |
| 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:08 |
| 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:20 |
| 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:21 |
| jelmer | gotgenes: 0.4.4 isn't out yet either | 22:22 |
| 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:23 |
| gotgenes | jelmer: I understand about the API support. I suppose the API will keep changing frequently until bzr v1.0 | 22:24 |
| 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:25 |
| jelmer | gotgenes: 0.4.4 and 0.92 shouldn't be too far off, will both be released within about two weeks | 22:30 |
| 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:36 |
| 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:37 |
| 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:38 |
| jelmer | lifeless: find_ghosts is great | 22:39 |
| lifeless | mm? | 22:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| jelmer | schierbeck: yep, will have a look | 22:46 |
| jelmer | lifeless: I don't tihnk there were any special requirements for bzr-dbus | 23:02 |
| n04m | jelmer: hi, another question/comment | 23:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| n04m | jelmer: ack? | 23:06 |
| jelmer | n04m, see peakers' answer | 23:06 |
| Peaker | I didn't answer anything about bzr progress report I think it could be nice if bzr had one :) | 23:07 |
| 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:12 |
| 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:27 |
| fullermd | Your shell rc file, I presume. | 23:28 |
| fullermd | I'd imagine there's some env variable or other you could trigger off. | 23:29 |
| fullermd | (of course, if this is in a branch, it'll happen by itself) | 23:30 |
| 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:32 |
| 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:33 |
| Peaker | I thought I had the entire hierarchy set to that group, but appearantly I did it too deep | 23:34 |
| fullermd | 27151 inconsistent parents | 23:39 |
| fullermd | 27151 file versions are not referenced by their inventory | 23:39 |
| fullermd | wuff. | 23:39 |
| 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:41 |
| Peaker | so its not the umask - what mode does bzr+ssh:// use for directories it makes? how do I change that? | 23:45 |
| fullermd | Last I checked, it inherited from the dir they went in. | 23:47 |
| fullermd | umask would only come into play when making new directories with no higher power to guide it (like init/new-push) | 23:48 |
| Peaker | the dir its making it in has: drwxrwsr-x but its being made as drwxr-sr-x (umask is 0002) | 23:49 |
| lifeless | jelmer: LanGateway.start does not exist in my bzr-dbus | 23:51 |
| 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:54 |
| 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:57 |
| jelmer | thinking about it | 23:58 |
| jelmer | I think you actually gave +1 for that change in Vilnius | 23:58 |
| jelmer | my branch is also registered now, the launchpad web ui seems to like me better | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!