| === beuno_ is now known as beuno | ||
| bob2 | do any dvcses aside from darcs have superfly cherrypicking? | 00:08 |
|---|---|---|
| fullermd | I think arch did OK. | 00:08 |
| fullermd | Probably not as good as darcs though, since it's fundamentally first-class in darcs. | 00:09 |
| ronny | fullermd: last time i checked arch was rather broken | 00:13 |
| ronny | and i dont think it got any better | 00:14 |
| beuno | mwhudson_, any ideas why tests now always fail for me in LH (on all branches, so it's not the broken tests)? | 00:19 |
| beuno | http://paste.ubuntu.com/187005/ | 00:19 |
| beuno | jelmer, hi | 00:19 |
| jelmer | beuno, hello | 00:19 |
| beuno | jelmer, quick question | 00:20 |
| fullermd | Well, AFAIK it's not moving anywhere. But it still sorta cherrypicked OK :p | 00:20 |
| beuno | jelmer, when was bzrlib.foreign introduced in bzr? | 00:20 |
| lifeless | 1.13/1.14 | 00:22 |
| beuno | jelmer, just to figure out if I have to bump the min bzrlib version | 00:22 |
| beuno | ok, I do then | 00:22 |
| beuno | thanks lifeless | 00:22 |
| jelmer | beuno, good question, I think it was 1.11 | 00:22 |
| jelmer | lifeless, that late? | 00:22 |
| igc | morning | 00:25 |
| beuno | hi igc | 00:25 |
| igc | hi beuno | 00:25 |
| beuno | jelmer, I'm not sure what to expose on the UI for this | 00:27 |
| beuno | as in | 00:27 |
| beuno | I have no idea what this is: (('203ae883-c723-44c9-aabd-cb56e4f81c9a', 'trunk', 230), BzrSvnMappingv3(TrunkBranchingScheme(0))) | 00:27 |
| jelmer | beuno, So in that particular case the interesting bit would be "trunk" and 230 | 00:27 |
| beuno | jelmer, so it's not key value pairings, just values with no explanation to them? | 00:28 |
| jelmer | beuno: You can call use the second part of the tuple to get a key/value representation | 00:28 |
| jelmer | What is returned is a tuple with foreign_revid and mapping | 00:28 |
| jelmer | foreign_revid is specific to the foreign vcs | 00:29 |
| beuno | jelmer, could we refactor this so it gives us the key:value entries directly? | 00:29 |
| beuno | that way it's very clear what should be exposed :) | 00:29 |
| jelmer | beuno, mapping.vcs.show_foreign_revid(foreign_revid) will return a dictionary with key/value pairs (all strings) | 00:30 |
| jelmer | that's what's used for "bzr log" | 00:30 |
| jelmer | you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon | 00:30 |
| jml | hey, bzr people. | 00:32 |
| beuno_ | grr | 00:32 |
| jelmer | moin jml | 00:33 |
| jelmer | wb beuno | 00:33 |
| jelmer | beuno, did you see those last few lines? | 00:33 |
| beuno_ | jelmer, saw: 20:30 < jelmer> you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon | 00:34 |
| beuno_ | las | 00:34 |
| beuno_ | last | 00:34 |
| jelmer | beuno_, yeah, that's right | 00:34 |
| beuno_ | jelmer, it's starting to get more complex than exposing it on the UI | 00:35 |
| === beuno_ is now known as beuno | ||
| jelmer | beuno: Perhaps we should focus on just the foreign rev info first, and other fancy stuff like icons later | 00:36 |
| beuno | jelmer, sounds good | 00:41 |
| beuno | can you update the branch to ad that | 00:41 |
| lifeless | jelmer: I was sure it was in by then, and a later than actual answer is still useful :) | 00:44 |
| lifeless | jelmer: $ rmadison subunit | 00:45 |
| lifeless | subunit | 0.0.2~bzr66-1 | karmic/universe | source, all | 00:45 |
| jelmer | lifeless, \o/ | 00:46 |
| jelmer | beuno, will do | 00:46 |
| FurnaceBoy2 | abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563 | 00:48 |
| FurnaceBoy2 | abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563 ; I have committed my changes before this | 00:48 |
| lifeless | FurnaceBoy2: if you want your local branch to overwrite the solaris10-port, add --overwrite to your push command, just once. | 00:50 |
| FurnaceBoy2 | hm, ok. i think i have succeeded by doing that in the past, I wonder why it didn't occur to me this time. | 00:51 |
| * FurnaceBoy2 goes to try | 00:51 | |
| FurnaceBoy2 | ok that certainly pushed. | 00:52 |
| FurnaceBoy2 | thanks | 00:52 |
| jelmer | beuno, sorry, phone call. I'm working on the foreign revid stuff now | 00:53 |
| === abentley1 is now known as abentley | ||
| jelmer | beuno, lp:~jelmer/loggerhead/foreign | 00:58 |
| lifeless | igc: ping | 01:05 |
| beuno | jelmer, thanks, dinner, but will look at it later | 01:05 |
| lifeless | igc: I'd like to try and convince you to change the core iter_changes and put excludes into it too :) | 01:05 |
| beuno | lifeless, your evil plan worked | 01:05 |
| lifeless | beuno: which one was that? | 01:05 |
| jelmer | lifeless: +1 | 01:05 |
| igc | lifeless: I've come to the same conclusion | 01:06 |
| lifeless | \o/ | 01:06 |
| igc | lifeless: trying to do it as a decorator is too fragile w.r.t. locking | 01:06 |
| igc | and consistency | 01:06 |
| lifeless | igc: it will also tend to trigger full inventory scans from dirstate, I suspect | 01:07 |
| igc | its just more work, but hey, that's ife | 01:07 |
| jml | how much memory can I expect bzr 1.14 to use when cloning a 1.2 GB branch stacked on a 450MB branch? | 01:07 |
| lifeless | jml: a few hundred MB probably | 01:07 |
| jml | limited on-production experimentation suggests 4.5GB+ | 01:07 |
| lifeless | jml: bugger a file | 01:07 |
| jml | lifeless: cool. | 01:07 |
| beuno | lifellif"get slightly involved and then get sucked in/obbssessed" | 01:08 |
| jml | lifeless: will do that, but would like to experiment locally first. | 01:08 |
| lifeless | beuno: :) with loggerhead? | 01:08 |
| lifeless | I think it was loggerhead I tried to do that with | 01:09 |
| cody-somerville | jelmer, ping | 01:48 |
| jelmer | cody-somerville, hi | 01:48 |
| cody-somerville | jelmer, using the latest bzr-git, 0.3.2, locally I get a different error | 01:48 |
| cody-somerville | http://pastebin.ubuntu.com/187048/ | 01:48 |
| jelmer | cody-somerville, what git repository was this again? | 01:49 |
| cody-somerville | git://git.debian.net/git/debian-live/live-helper.git | 01:50 |
| jelmer | cody-somerville: Hmm, that looks different indeed. Any chance you can file a bug report? | 01:53 |
| cody-somerville | jelmer, sure. bzr-git on launchpad? | 01:54 |
| jelmer | cody-somerville, yep | 01:55 |
| jam | igc: ping | 01:55 |
| igc | hi jam | 01:55 |
| cody-somerville | jelmer, filed as lp #382993 | 01:57 |
| ubottu | Launchpad bug 382993 in bzr-git "AttributeError: children when performing git-import" [Undecided,New] https://launchpad.net/bugs/382993 | 01:57 |
| jam | igc: I was hoping you would get a chance to run some Usertest stuff on Jelmer's most recent bencode serializer code | 01:58 |
| jam | We really need to come up with a disk format for 2.0 rather soonish | 01:58 |
| igc | jam: that's on my list for today | 01:58 |
| lifeless | I'm still on check FWIW | 01:58 |
| lifeless | spiv: are you copacetic on network deltas? | 01:58 |
| igc | jam: the main thing I need is a patch/branch with all the proposed bits including a placeholder format, e.g. development8-rr | 01:59 |
| igc | jam: jelmer did exactly that fro me to benchmark the rio stuff | 01:59 |
| igc | jam: to test on OOo, I also need 36 hours to generate a repo in the proposed new format | 02:00 |
| jam | igc: I'm pretty sure he had a --dev7-rr format | 02:00 |
| jam | also, I would expect converting from --dev6 => --dev7 would be much faster | 02:00 |
| jam | and it could be mysql, it wouldn't have to be OOo | 02:00 |
| igc | jam: great. I'll take a look at his latest patches | 02:01 |
| igc | yes, mysql would be faster. I don't have it converted to development6 yet though. | 02:01 |
| igc | jam: can you upload a converted repo for me? | 02:01 |
| lifeless | jelmer: I don't see the index problem | 02:07 |
| lifeless | jelmer: care to fix? | 02:07 |
| jelmer | lifeless, I tried, but couldn't easily find out where the unicode objects were being introducecd | 02:08 |
| lifeless | what was their value? | 02:09 |
| kizzo | Is there a way to specify the ssh port to use when pushing something to your private branch? | 02:09 |
| lifeless | bzr+ssh://host:port/... | 02:09 |
| jelmer | lifeless, checking | 02:10 |
| kizzo | So instead of "bzr push lp:~kizzobot/blah/blah", the location would be "bzr+ssh://launchpad.net:22/..."? | 02:11 |
| kizzo | I'll try it out now. | 02:11 |
| lifeless | kizzo: uhm | 02:11 |
| lifeless | kizzo: the default port for lp/bzr+ssh is 22, so it should Just Work | 02:12 |
| lifeless | kizzo: what are you seeing happen? | 02:12 |
| lifeless | (and it would be bzr+ssh://bazaar.launchpad.net:22/~kizzobot/blah/blah) | 02:12 |
| kizzo | My /etc/ssh/ssh_client specifies a default port of NOT 2222. | 02:12 |
| lifeless | interesting | 02:12 |
| lifeless | ok | 02:12 |
| kizzo | Oh wait .. s/NOT// | 02:12 |
| lifeless | so the above should work | 02:13 |
| kizzo | Yeah. | 02:13 |
| lifeless | and please file a bug that lp: isn't forcing the port | 02:13 |
| jelmer | cody-somerville, looks like a symlink target that's been changed to include an extra / | 02:13 |
| kizzo | Yeah I would think so too. | 02:13 |
| kizzo | I think it is actually.. | 02:13 |
| kizzo | kizzo@crashtest:~/work/new-bindings$ bzr push bzr+ssh://code.launchpad.net:22/~kizzobot/+junk/python-bindings | 02:13 |
| lifeless | in fact, bzr+ssh should possibly force the port | 02:13 |
| kizzo | ssh: connect to host bazaar.launchpad.net port 2222: Connection timed out | 02:13 |
| kizzo | hmm | 02:14 |
| lifeless | not code.launchpad.net - bazaar.launchpad.net | 02:14 |
| jelmer | lifeless, a bit related, it also looks like "bzr index" doesn't like ghosts | 02:14 |
| lifeless | redirectors in the middle will give you grief | 02:14 |
| lifeless | kizzo: another thing you could do, in ~/.ssh/config | 02:14 |
| lifeless | Host bazaar.launchpad.net | 02:14 |
| lifeless | port 22 | 02:14 |
| SamB | lifeless: why should it force the port ? | 02:14 |
| cody-somerville | jelmer, does that mean an easy fix? | 02:15 |
| jelmer | lifeless, node is (<bzrlib.btree_index.BTreeBuilder object at 0xa8c528c>, ('1545',), u'p mapping.py') | 02:15 |
| lifeless | SamB: because there is a well known port | 02:15 |
| jelmer | cody-somerville, not sure yet | 02:15 |
| kizzo | lifeless: Oh ok that works - thanks. | 02:15 |
| kizzo | And specifying the port in the URL successfully works. | 02:15 |
| SamB | lifeless: wouldn't that be a major abuse of the URL syntax ? | 02:15 |
| lifeless | SamB: no | 02:15 |
| SamB | it's not necessarily the case that ALL ssh servers run on that port ... | 02:15 |
| lifeless | SamB: naturally | 02:15 |
| SamB | there may be situations where a SINGLE machine has MORE THAN ONE | 02:15 |
| lifeless | SamB: I think you have misinterpreted what I said | 02:16 |
| SamB | lifeless: what did you mean ? | 02:16 |
| lifeless | SamB: If a user tells bzr 'bzr+ssh://host/' bzr should be attempting to connect to port 22 | 02:16 |
| SamB | oh, sure! | 02:16 |
| SamB | that's not forcing, that's defaulting! | 02:16 |
| lifeless | SamB: so it should be forcing the port when it invokes ssh | 02:17 |
| SamB | oh | 02:17 |
| SamB | you mean it should pass the default port on to SSH | 02:17 |
| lifeless | no, I mean it should tell ssh the port to use, always. | 02:17 |
| SamB | instead of just assuming that SSH has the default default? | 02:17 |
| lifeless | right | 02:17 |
| kizzo | SamB: I think lifeless is saying that it would be bad if the bzr tool itself was always forcing the port to be 22, and not letting the user specify another port. | 02:18 |
| lifeless | jelmer: is that a path in your tree? | 02:18 |
| SamB | kizzo: I'm pretty sure that's what I was trying to say to lifeless ... | 02:18 |
| jelmer | lifeless, mapping.py is, not the "p " bit | 02:18 |
| kizzo | Oh nvm haha. | 02:18 |
| lifeless | jelmer: p is path | 02:18 |
| lifeless | jelmer: its the entry type | 02:18 |
| jelmer | lifeless, ah, right | 02:18 |
| lifeless | so | 02:19 |
| lifeless | search should be ghost friendly, as long as the ghosts aren't required to calculate deltas - which they must not be | 02:19 |
| spiv | lifeless: copacetic on network deltas? I only just woke up, so I'm hardly copacetic on anything right atm ;) | 02:20 |
| lifeless | jelmer: what are you indexing? | 02:26 |
| jelmer | lifeless: anything | 02:26 |
| lifeless | jelmer: line 978 of index.py | 02:28 |
| lifeless | can you insert | 02:28 |
| jelmer | lifeless, it's looking very similar to the reconcile text ghost handling bug | 02:28 |
| lifeless | === modified file 'index.py' | 02:29 |
| lifeless | --- index.py 2009-01-21 07:59:57 +0000 | 02:29 |
| lifeless | +++ index.py 2009-06-03 01:29:17 +0000 | 02:29 |
| lifeless | @@ -975,6 +975,9 @@ | 02:29 |
| lifeless | if document_key in self._document_ids: | 02:29 |
| lifeless | return self._document_ids[document_key] | 02:29 |
| lifeless | next_id = str(self.document_index.key_count()) | 02:29 |
| lifeless | + value = "%s %s %s" % document_key | 02:29 |
| lifeless | + if type(value) is unicode: | 02:29 |
| lifeless | + import pdb;pdb.set_trace() | 02:29 |
| jelmer | lifeless, (Pdb) print document_key | 02:34 |
| jelmer | ('p', '', u'mapping.py') | 02:34 |
| kizzo | When you do something like "bzr branch lp:whatever", what is the expanded version of "lp"? | 02:35 |
| moldy | hi | 02:35 |
| moldy | dumb question: how do i restore a deleted file? | 02:35 |
| jelmer | lifeless, unrelated question, could it be that bzr is fixing the formatting of InventoryEntry.symlink_target | 02:36 |
| lifeless | jelmer: peng filed this as a dev6 specific bug | 02:37 |
| jelmer | lifeless, the bzr-search thing you mean? | 02:37 |
| lifeless | jelmer: can you give me the backtrace for that? | 02:37 |
| lifeless | kizzo: its the result of an xmlrpc call | 02:37 |
| moldy | i have committed the deletion and done other changes since then | 02:38 |
| lifeless | moldy: bzr revert -r <rev that had the file> FILENAME | 02:38 |
| jelmer | lifeless, http://pastebin.ubuntu.com/187068/ | 02:38 |
| moldy | lifeless: thanks! is there any better way to find <rev> than to read through the logs? | 02:39 |
| lifeless | moldy: bzr log -v | less , /FILENAME :) | 02:39 |
| lifeless | moldy: (for now) | 02:40 |
| moldy | lifeless: ok, i see. thank you! | 02:41 |
| lifeless | jelmer: pull trunk | 02:41 |
| jelmer | lifeless, I can confirm that works, thanks! | 02:42 |
| jam | igc: lp:///~jameinel/bzr/bencode_serializer | 02:43 |
| jam | That should be the latest version of the serializer, with all the bits sewn together | 02:43 |
| jam | well, once it finishes uploading :) | 02:44 |
| jam | I think the machine with my mysql conversion is offline right now, I'll see what I can do | 02:45 |
| kizzo | Hmm why is "bzr branch lp:~kizzobot/+junk/python-bindings" talking SSH? (I have a packet sniffer running and seeing the traffic). | 02:47 |
| kizzo | I'm under the impression that I'm branching FROM launchpad - why would SSH be involved? | 02:47 |
| Peng_ | kizzo: Why shouldn't it? | 02:47 |
| Peng_ | kizzo: If you've run "bzr launchpad-login", lp: expands to bzr+ssh://bazaar.launchpad.net/ | 02:48 |
| kizzo | Peng_: It's a public branch. Like, anyone should be able to get it. | 02:48 |
| kizzo | hmm | 02:48 |
| lifeless | jelmer: cool | 02:48 |
| Peng_ | kizzo: Anyone can get it. If they haven't logged in, it'll use http. | 02:48 |
| Peng_ | Who what works? | 02:49 |
| igc | jam: thanks | 02:49 |
| jam | igc: just make sure you run 'make' :) | 02:49 |
| igc | jam: and thanks for the reivews as well | 02:49 |
| igc | jam :-) will do | 02:49 |
| igc | the numbers tend to stand out if do forget :-) | 02:49 |
| igc | s/if/if I/ | 02:50 |
| xnevermore | I'm trying to use bzr-svn to create a subversion repo on a remote server and push my bzr branch to it. I tried using "bzr svn-push svn+ssh://server.com/home/username/svnrepos/project", but got "bzr: ERROR: No repository present" | 02:53 |
| jelmer | xnevermore, a repository ahs to alreday exist | 02:54 |
| jelmer | and I need to fix my spelling | 02:54 |
| xnevermore | jelmer: do you know what the svn command for that is? | 02:54 |
| jelmer | xnevermore, on the remote server: svnadmin create /path | 02:55 |
| lifeless | jelmer: bzr init --svn svn+ssh://server.com/home/username/svnrepos/project would be cute :) | 02:55 |
| lifeless | jelmer: and the api definitely supports it:) | 02:56 |
| jelmer | lifeless, the remote one doesn't unfortunately | 02:56 |
| SamB | lifeless: well enough ? | 02:56 |
| lifeless | SamB: EPARSE | 02:56 |
| jelmer | lifeless, locally "bzr init-repo --subversion" already works | 02:56 |
| SamB | the API may believe it supports a thing, but it might not actually be possible to make it work in a real situation ... | 02:56 |
| lifeless | SamB: I don't see why it wouldn't | 02:57 |
| lifeless | SamB: or I wouldn't have said that the api supports it ;) | 02:57 |
| SamB | lifeless: that's usually on account of not having tried and failed ;-) | 02:57 |
| lifeless | SamB: are you arguing hypothetically, or from experience with this particular api ? | 02:58 |
| xnevermore | jelmer: ok, i issued that command, then issued the svn-push command, but got "bzr: ERROR: These branches have diverged. Use the merge command to reconcile them." | 02:58 |
| lifeless | jelmer: how does it fall down for you? | 02:58 |
| SamB | lifeless: hypothetically, I guess | 02:58 |
| SamB | I haven't tried and failed either | 02:58 |
| jelmer | xnevermore, you need to push to somewhere inside of the repository, e.g. URL/trunk | 02:58 |
| lifeless | SamB: 'nuff said | 02:58 |
| SamB | but the way jelmer keeps doing it I wouldn't have been surprised either way | 02:58 |
| jelmer | lifeless, the API for creating a repository requires you to specify a local path | 02:59 |
| lifeless | jelmer: whose api | 02:59 |
| jelmer | lifeless, The SVN one | 02:59 |
| SamB | oooh | 02:59 |
| lifeless | jelmer: I was meaning 'ssh host svnadmin ...' | 02:59 |
| jelmer | lifeless, The only API that works with svn+ssh://, svn:// and http:// doesn't allow creating repositories | 02:59 |
| SamB | for once it's not bzrlib's fault | 02:59 |
| jelmer | lifeless, ahh | 03:00 |
| lifeless | jelmer: which you have enough data to do | 03:00 |
| jelmer | lifeless, Yeah, I guess we could do that | 03:00 |
| SamB | jelmer: certainly it could try | 03:00 |
| SamB | what does svn+ssh need from a remote anyway ? | 03:00 |
| xnevermore | jelmer: cool, thanks. that worked fine | 03:02 |
| lifeless | SamB: it uses libsvn locally with a remote url | 03:03 |
| lifeless | SamB: as opposed to the bzr rpc server | 03:03 |
| SamB | lifeless: I meant, what does libsvn need from the remote ... | 03:03 |
| jelmer | SamB, it needs svnserve present on the remote server | 03:03 |
| lifeless | just like bzr really, except our serve is a subcommand | 03:06 |
| jelmer | svnserve should be an alias for "bzr serve --svn" | 03:10 |
| lifeless | that would be cool in a strange sort of way | 03:18 |
| thumper | jelmer: http://launchpadlibrarian.net/27418534/ubuntu-tweak-master-log.txt | 03:50 |
| thumper | jelmer: still awake? | 03:50 |
| Peng_ | So, um, how do bzr serve --git and --svn work? Do they serve native git/svn branches over the git/svn protocols? Bzr branches? | 04:06 |
| Peng_ | How do you check if a transport is read-only? | 04:07 |
| spiv | Peng_: there's .is_readonly() on the transport object | 04:07 |
| Peng_ | spiv: Oh, that's simple and obvious. Thanks. | 04:08 |
| spiv | Peng_: of course, a transport may think its read-write and then get PermissionDenied from all write ops ;) | 04:08 |
| lifeless | .readonly is a misfeature | 04:08 |
| lifeless | I advise against using it | 04:08 |
| lifeless | it really just reflects that a particular transport will deny *all* write operations, not that *any given* operation will succeed | 04:08 |
| spiv | Peng_: so the reliable way is to actually try writing and be prepared to catch errors :) | 04:08 |
| Peng_ | I'm interested in making sure the transport is read-only, not making sure it's not. :) | 04:09 |
| lifeless | Peng_: context? | 04:10 |
| Peng_ | lifeless: Loggerhead, both in general, and specifically for serving .bzr/smart. | 04:12 |
| lifeless | Peng_: I'm not sure why you would care there? | 04:17 |
| lifeless | is there any reason loggerhead shouldn't be able to write when its serving, just as bzr:// can ? | 04:17 |
| Peng_ | That's a good point. Still, it doesn't allow configuring that (yet), and it should default to read-only. | 04:18 |
| lifeless | sure | 04:18 |
| lifeless | I'd make sure bzr serve's facility for configuring this is reused directly | 04:19 |
| Peng_ | Thanks to how "bzr serve" works, it already is. | 04:20 |
| Peng_ | "bzr serve" passes a transport to Loggerhead; if --allow-writes was not passed, it's read-only. | 04:20 |
| Peng_ | But start-loggerhead and serve-branches are still around, and the latter takes arbitrary URLs. | 04:20 |
| lifeless | jam: ping | 04:34 |
| Peng_ | Making Loggerhead writable is spooky and totally cool. | 04:39 |
| * igc lunch | 04:46 | |
| === abentley1 is now known as abentley | ||
| lifeless | Peng_: for sex, have clients at the trunkof the branch get updates pushed via ajax when someone commits via loggerhead | 04:49 |
| === abentley1 is now known as abentley | ||
| Peng_ | It's totally cool that pushing from a bzr client -> bzr+http server -> bzr server works, right? | 05:01 |
| lifeless | Peng_: yes | 05:01 |
| Peng_ | :) | 05:01 |
| kizzo | lifeless: Thanks. | 05:16 |
| Peng_ | Do you think it's worth running a bzr+http server? | 05:42 |
| Peng_ | Especially since that entails running an old version of bzr that actually works? | 05:42 |
| jml | lifeless: so, regarding the memory thing I mentioned earlier | 05:43 |
| Peng_ | I'm not sure what percentage of that was a serious question and what was whining. | 05:43 |
| jml | lifeless: http://paste.ubuntu.com/187123/ has a traceback I got from doing C-\ while the memory was climbing | 05:43 |
| jml | lifeless: can you please help me file a good bug for this, now that I can reproduce the error locally? | 05:43 |
| lifeless | sure | 05:44 |
| lifeless | let me look | 05:44 |
| spiv | Peng_: yeah, sorry about that, that bug is on my todo list... | 05:44 |
| lifeless | so that particular point is in index processing | 05:44 |
| lifeless | and you don't have the C extensions built | 05:44 |
| lifeless | first thing, see if they make a difference. | 05:45 |
| lifeless | jml: secondly, grab jam's memory profiler tool | 05:46 |
| lifeless | and use it when you break in | 05:46 |
| jml | I wonder why they aren't built. I'm running from the nightly ppa | 05:47 |
| lifeless | jml: I may be wrong | 05:49 |
| lifeless | import bzrlib._btree_serializer_c | 05:49 |
| jml | it's not there. | 05:49 |
| jml | 1.15+4368+109 should be recent enough, right? | 05:50 |
| lifeless | bug in the ppa builds | 05:51 |
| lifeless | I'll file it | 05:51 |
| jml | thanks. | 05:52 |
| Peng_ | spiv: <3 | 05:53 |
| jml | hah, I don't even have pyrex installed. | 05:53 |
| Peng_ | Actually, I wasn't just whining. Branching bzr.dev's entire history over bzr+http would probably make my server catch fire. | 05:54 |
| pygi | Peng_: with what format ?:) | 05:54 |
| Peng_ | pygi: 1.9. | 05:57 |
| pygi | Peng_: try with brisbane? :) | 05:57 |
| Peng_ | pygi: Not possible. If I upgrade my bzr+http server to a version that supports bbc, it'll also suffer from bug 348308. | 05:58 |
| ubottu | Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308 | 05:58 |
| Peng_ | Obviously I could set up two servers, but that'd be a pain. | 05:58 |
| Peng_ | And anyway, trying it means risking an OOM. | 05:59 |
| jml | hmm. rate of climbing seems slower, but it's still over 1g. | 06:04 |
| lifeless | time for the memory profiler | 06:05 |
| jml | hurh, it's not using the c module | 06:06 |
| * jml bangs the box a couple of times. | 06:06 | |
| jml | hmmmmm. | 06:24 |
| jml | now that I'm using C extensions, seems to be capped at ~721MB | 06:24 |
| lifeless | thats still high | 06:25 |
| lifeless | if you could build and use jams profiler that would be good | 06:25 |
| jml | lifeless: sure thing. where does it live? | 06:25 |
| === jfroy is now known as cami | ||
| === cami is now known as jfroy | ||
| lifeless | lol http://mac.wareseeker.com/free-john-arbash-meinel/ | 06:27 |
| lifeless | (spam search hit in google) | 06:28 |
| lifeless | https://lists.ubuntu.com/archives/bazaar/2009q2/056433.html | 06:29 |
| lifeless | ^ jml: | 06:29 |
| jml | ta | 06:29 |
| jml | lifeless: interested at all in the pure python data? | 06:30 |
| lifeless | jml: not really. | 06:31 |
| lifeless | choosing battles etc | 06:31 |
| vila | hi all | 07:18 |
| spiv | Gar, why does PQM not want to send me failure mail... | 07:55 |
| lifeless | No handlers could be found for logger "bzr" | 08:04 |
| lifeless | Permission denied (publickey). | 08:04 |
| lifeless | bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 08:04 |
| spiv | Ah, right. Ok. | 08:12 |
| spiv | I guess the PQM user isn't properly set up to cope with lp: URLs :/ | 08:13 |
| lifeless | spiv: rt it? | 08:46 |
| ronny | jelmer: im kinda missing how i should store objects i created in a dulwich repo, any hints on what im missing? | 08:53 |
| ronny | ah, found my issue | 08:55 |
| ronny | searched the wrong file for that | 08:55 |
| === sabdfl1 is now known as sabdfl | ||
| jml | lifeless: did you go to jkakar's commandant talk? | 10:09 |
| === Kissaki^0ff is now known as Kissaki | ||
| balor | How do I throw out all the changes in my current working directory? i.e. rebase on current HEAD. | 10:59 |
| Peng_ | balor: ..."bzr revert"? | 11:00 |
| balor | Peng_: thanks | 11:01 |
| Peng_ | Oh, good. | 11:01 |
| johnf | I've written an init script for bzr server. Should I submit a patch to bzr or should I just put it in the debian package? | 12:20 |
| === abentley1 is now known as abentley | ||
| === mrevell is now known as mrevell-lunch | ||
| vadi2 | I | 13:24 |
| vadi2 | *I'm trying to setup bzr over svn with bzr-svn, and thought the process was to make a new folder and use bzr-svn import --trees into the new location. But I accidentally did "bzr init" not in the new folder, but in the current svn one. | 13:25 |
| vadi2 | the svn repository is huge and it's doing "something" - is that something wrong and should I cancel? | 13:25 |
| === mrevell-lunch is now known as mrevell | ||
| jelmer | vadi2, hi | 13:32 |
| jelmer | vadi2, init in the svn one? | 13:32 |
| jelmer | vadi2, doesn't sound like what you'd want | 13:32 |
| vadi2 | yeah, after a long while it gave "bzr: ERROR: Already a branch: "."." | 13:32 |
| vadi2 | But I'm having a problem getting it to import into my proper folder now though | 13:33 |
| vadi2 | http://paste.pocoo.org/show/120769/ | 13:33 |
| jelmer | vadi2, You're importing from a svn repo into a svn repo? | 13:34 |
| vadi2 | why's that | 13:34 |
| vadi2 | I did "bzr init" in yorba3 folder | 13:35 |
| jelmer | vadi2: That creates a branch, not a repository | 13:35 |
| jelmer | vadi2: A svn repository contains multiple branches | 13:35 |
| jelmer | you don't need to run "bzr init" before svn-import | 13:35 |
| vadi2 | What would be the proper way? | 13:36 |
| jelmer | vadi2, don't running anything at all | 13:36 |
| jelmer | just "bzr svn-import yorba yorba3" | 13:36 |
| jelmer | or "bzr svn-import --trees yorba yorba3" if you want working trees | 13:37 |
| === beuno_ is now known as beuno | ||
| vadi2 | Sorry. What folder to run that in? | 13:37 |
| vadi2 | http://paste.pocoo.org/show/120770/ | 13:38 |
| jelmer | vadi2, I think you may have a incomplete .bzr directory in Programs/ ? | 13:38 |
| jelmer | It should be run in Programs, ideally yorba3 should not exist yet | 13:38 |
| vadi2 | no, don't have a .bzr in Program | 13:39 |
| vadi2 | *s | 13:39 |
| vadi2 | going to try deleting yorba3 | 13:39 |
| vadi2 | "No repository present: "file:///home/vadi/Programs/"" :/ | 13:40 |
| vadi2 | I'm using the stock jaunty version of bzr-svn though, not the ppa one because bzr-gtk breaks | 13:40 |
| jelmer | maybe try in a different directory | 13:41 |
| jelmer | e.g. bzr svn-import /path/to/yorba /tmp/yorba3 | 13:41 |
| vadi2 | $ bzr svn-import --trees /home/vadi/Programs/yorba /tmp/yorba3 | 13:42 |
| vadi2 | bzr: ERROR: No repository present: "file:///home/vadi/Programs/" | 13:42 |
| vadi2 | there is no repository in 'Programs', that is correct. Not sure why it's not looking at the "yorba" folder | 13:42 |
| jelmer | vadi2, Does yorba actually contain a subversion repository? | 13:43 |
| jelmer | vadi2, is there no .bzr directory in yorba? | 13:44 |
| vadi2 | there is a repository (svn log works) and there is no .bzr | 13:45 |
| vadi2 | maybe I have a broken bzr-svn? getting the proper version installed without upgrading bzr was tricky. | 13:47 |
| jelmer | vadi2, don't know | 13:48 |
| awilkins | vadi2: Perhaps try bzr svn-import svn+file://home/vadi/Programs/yorba yorba3 ? | 13:48 |
| vadi2 | http://paste.pocoo.org/show/120773/ | 13:50 |
| jelmer | vadi2, that suggests there really isn't a svn repo in yorba | 13:52 |
| vadi2 | But I have .svn in it and "svn log", "svn status" work okay | 13:53 |
| jelmer | vadi2: That suggests there's a subversion working tree there, not a repository | 13:53 |
| jelmer | vadi2: I think you want either 'bzr branch yorba yorba3' or 'bzr svn-import url-to-svn-repos yorba3' | 13:53 |
| vadi2 | I'll try the first. It's very big to download again | 13:54 |
| vadi2 | Thanks for your help, I'll try it in a bit. | 13:54 |
| jelmer | vadi2, it won't retain much of the data that 'svn co' downloaded | 13:54 |
| vadi2 | o | 13:54 |
| vadi2 | alright. | 13:54 |
| jelmer | vadi2, bzr downloads all of the history of what you're branching, svn only keeps the last revision | 13:55 |
| vadi2 | right | 13:56 |
| beuno | jelmer, hi! just took another stab at your foreign branch | 14:13 |
| beuno | but it tracebacks | 14:13 |
| beuno | added the tb to the merge proposal | 14:13 |
| beuno | james_w, hi | 14:20 |
| jam | spiv, lifeless: I missed this last night, but PQM fails with both lp: urls and bzr+ssh://bazaar.canonical.com/ ones | 14:22 |
| jam | I think they changed the firewall rules | 14:22 |
| jam | But #is never really came up with an answer | 14:24 |
| jelmer | beuno, that's odd, I can't see how we could get there without setting foreign_revid somehow | 14:25 |
| jam | i just switched to http://bazaar.launchpad.net | 14:25 |
| vila | jam: using http:// urls is the answer | 14:25 |
| vila | jam: and hi :) | 14:25 |
| beuno | jelmer, yeah, I tried to fiddle with the code, but didn't figure it out either | 14:25 |
| jam | hey vila | 14:26 |
| jam | It is *an* answer | 14:26 |
| jam | I don't think it should be *the* answer | 14:26 |
| jam | Perhaps the LOSAs feel differently | 14:26 |
| vila | jam: I agree with you, but it's the only answer that works :) | 14:26 |
| jam | I wonder if they didn't change PQM so that it actually thinks it has a launchpad user account | 14:26 |
| jam | and now it is trying to log in | 14:26 |
| vila | do you mean you used to be able to use lp: URLS ? | 14:26 |
| jam | whereas before lp:/// urls were resolving to http | 14:27 |
| jam | vila: I configured it and had it working for at least 2-3 months | 14:27 |
| vila | jam: that's so unfair ! So I was really the only one hanging pqm while using them :-) | 14:27 |
| jam | vila: I think you hung pqm, then they "fixed" it, so I could use it | 14:30 |
| jam | then they broke it again :) | 14:30 |
| vila | jam: I thought "they" fixed it twice, so I'm more cautious now about that :) | 14:30 |
| moldy | hi | 14:43 |
| moldy | why does bzr st only show directories with status unknown, but not the files inside those directories? | 14:43 |
| stani | how can I retrieve the revision number from python from a bazaar repository | 14:59 |
| stani | ? | 14:59 |
| beuno | stani, you have the revision id? | 15:00 |
| beuno | stani, take a look at: http://bazaar-vcs.org/Integrating_with_Bazaar | 15:00 |
| jelmer | beuno, argh, I'm so stupid | 15:01 |
| stani | I have a path and I want to get the revision number so I can construct a temporary version number for my package: package-0.2.bzr192 | 15:01 |
| jelmer | beuno, fix pushed | 15:01 |
| beuno | jelmer, thanks | 15:02 |
| stani | bueno: thanks, I'll try that | 15:02 |
| beuno | stani, so you need the tip? | 15:02 |
| beuno | it should be explained there | 15:02 |
| stani | bueno: hmmm doesn't seem to work | 15:06 |
| stani | bueno: http://www.pasteall.org/5894/python | 15:06 |
| stani | bueno: I thought afterwards I could do b.revno() | 15:08 |
| beuno | stani, you need to open the branch | 15:08 |
| beuno | Branch.open('.... | 15:09 |
| jam | moldy: we don't recurse into unknown directories because often that would be foolish | 15:09 |
| === You're now known as ubuntulog | ||
| jam | consider a "build" directory with hundreds of unwanted files | 15:09 |
| stani | bueno: thanks, stupid mistake of me | 15:09 |
| moldy | jam: i would like to see that there are hundreds of unwanted files | 15:10 |
| moldy | jam: without having to run ls on every directory with status unknown :) there is no option to request recursion? | 15:11 |
| jam | moldy: it was an explicit design decision, if you can present a use case for changing it, then please describe it to su | 15:11 |
| jam | moldy: bzr ls --recurse | 15:11 |
| jam | sorry "bzr ls --recursive" | 15:11 |
| moldy | "bzr st --recursive" would save me that additional command | 15:12 |
| === `6og is now known as Kamping_Kaiser | ||
| moldy | i might want to add the directory, but not its contents | 15:13 |
| stani | beuno: what is the python equivalent to 'bzr export', it doesn't seem to be mentioned on that page | 15:21 |
| jam | stani: you can generally look in bzrlib/builtins.py to see what a command does, and how to translate that into direct python calls | 15:35 |
| timour | Guys, I need help with BZR 1.15. | 15:45 |
| timour | I have Kubuntu 9.04, fresh install. | 15:46 |
| timour | When I run any BZR command I get: | 15:46 |
| timour | "No handlers could be found for logger "bzr" | 15:46 |
| jelmer | timour, is your ~/.bzr.log writable? | 15:46 |
| timour | jelmer, checking ... | 15:46 |
| timour | jelmer, weird, no, it is: | 15:48 |
| timour | -rw-r--r-- 1 root root 18K 2009-06-03 17:22 .bzr.log | 15:48 |
| timour | jelmer, should I chown it and make it writeable? | 15:49 |
| jelmer | timour, yeah | 15:49 |
| visik7 | does bzr serve implement a wsgi interface ? | 15:50 |
| timour | jelmer, great, it worked, thanks a lot! | 15:51 |
| jelmer | visik7: bzr serve --http uses wsgi internally | 15:51 |
| visik7 | but can I attach bzr serve to mod_wsgi ? | 15:52 |
| jelmer | visik7: You can attach loggerhead to mod_wsgi I *think* | 15:54 |
| visik7 | if setup loggerhead do the server automatically checkout latest revision ? | 16:02 |
| visik7 | or also without loggerhead | 16:03 |
| visik7 | I mean does a non-dumb server provide autocheckout ? | 16:03 |
| jelmer | visik7, not sure I'm following | 16:04 |
| visik7 | I'm referring to http://doc.bazaar-vcs.org/bzr.0.18/server.htm | 16:05 |
| visik7 | if I push using a dumb server the branch is not checked out | 16:05 |
| visik7 | I was asking if with a non dumb server the checkout is performed | 16:05 |
| jelmer | visik7, ah | 16:05 |
| jelmer | visik7, no, that's not the case yet | 16:05 |
| visik7 | :( | 16:05 |
| visik7 | I need a way to auto checkout on push | 16:06 |
| visik7 | and the push-and-update plugin is not a viable solution | 16:06 |
| jelmer | there's a plugin that can do that over ssh | 16:06 |
| jelmer | ah | 16:06 |
| jelmer | visik7, I don't think there's anything that can do that atm | 16:07 |
| jelmer | visik7, Somebody needs to add that feature to the smart server | 16:07 |
| visik7 | smart server ? | 16:07 |
| jelmer | visik7, yeah, what bzr+ssh:// and bzr+http:// use under the covers | 16:07 |
| visik7 | oh the non dumb | 16:08 |
| visik7 | :) | 16:08 |
| visik7 | ok and bzr serve is hookable ? with a custom plugin to get this thing ? | 16:08 |
| jelmer | I don't know | 16:09 |
| visik7 | ok thanks anyway | 16:09 |
| jelmer | lifeless, ping | 16:11 |
| awilkins | I've been trying to get lifeless for days, is he alive? | 16:13 |
| awilkins | (hmm, that was a humourless pun on his name...) | 16:13 |
| beuno | awilkins, he was around yesterday, yes | 16:13 |
| andrew | What do I need to have in order to be able to tab-complete bzr commands? (Ubuntu 9.04) | 16:15 |
| awilkins | andrew: Seems to just work here, I'd never thought about it | 16:16 |
| beuno | andrew, it works by default | 16:16 |
| andrew | For example, if I type in: bzr st[tab], it starts giving me file names | 16:17 |
| beuno | andrew, that's odd. It shouldn't happen | 16:17 |
| andrew | But since it does happen, what can I do to fix it? | 16:19 |
| awilkins | Remove and reinstall the bzr package? | 16:27 |
| * awilkins is embarassed to propose this windows-onian method | 16:27 | |
| andrew | awilkins: tried that, no luck | 16:27 |
| andrew | awilkins: ha, don't be embarassed, I tried that already as it was suggested by somebody else | 16:28 |
| visik7 | how can I run the following command from a python script: bzr update | 16:31 |
| visik7 | = | 16:31 |
| visik7 | ? | 16:31 |
| LarstiQ | andrew: is completion enabled in the shell you're using? | 16:32 |
| LarstiQ | andrew: bash on Debian for instance, has it disabled by default | 16:33 |
| * LarstiQ heads to the dojo | 16:34 | |
| === lamont` is now known as lamont | ||
| andrew | got it fixed thanks to evand. Apprently I didn't have a ~/.bashrc ... | 16:40 |
| * andrew blames likewise-open for that messup | 16:50 | |
| ddaa | Here's an idea for promoting bzr. | 17:18 |
| ddaa | It's the dvcs for test-driven development and continuous integration. | 17:19 |
| ddaa | Write test, write implementation, commit, merge parent, repeat. | 17:19 |
| dash | ddaa: I would like to believe that | 17:19 |
| dash | Hmm. | 17:19 |
| dash | how's that different from the competition | 17:19 |
| ddaa | Other dvcs, with their anemic log functionality discourage frequent commits on feature branches and frequent merges. | 17:20 |
| dash | well, that matches my experience | 17:20 |
| ddaa | Because that creates a lot of very small commits that end up making the mainline log unusable. | 17:20 |
| dash | i specifically picked bzr over hg because of the ability to get a clean trunk log | 17:21 |
| bob2 | eh | 17:21 |
| dash | like i was used to in svn | 17:21 |
| bob2 | bzr and git now have the same log output | 17:21 |
| SamB | bob2: eh? | 17:21 |
| ddaa | bob2: meh? | 17:21 |
| dash | bob2: interesting. | 17:21 |
| ddaa | bob2: you mean hg changed its log output to highlight the mainline? | 17:21 |
| SamB | maybe if you use --first-parent or whatever ... | 17:21 |
| bob2 | no idea what hg does | 17:22 |
| ddaa | Ah, I mean git. | 17:22 |
| ddaa | You mean git log now only shows the mainline? | 17:22 |
| ddaa | and has an option to show a hierarchical log? | 17:22 |
| bob2 | --graph, iirc | 17:23 |
| ddaa | I dunno git, but I know that with hg's "fast forward pull on no divergence", you cannot get a clean mainline even if you want to. | 17:23 |
| ddaa | I know jelmer reported that samba folks asked him to stop frequently merging trunk into his branch because it polluted the log. | 17:24 |
| stani | What is the equivalent of 'bzr export DEST' in python? Is this done with a WorkingTree or a Branch? | 17:24 |
| dash | ddaa: right, that's the key missing feature in hg as far as I can tell | 17:24 |
| dash | I did have an hg user tell me it was possible once | 17:25 |
| dash | but it's not the normal mode of operation | 17:25 |
| ddaa | I'm pretty sure that's not going to change now. | 17:25 |
| dash | sure. | 17:25 |
| === Isaiah1 is now known as Isaiah | ||
| luks | can't you just always fetch+merge? | 17:25 |
| ddaa | Their community is too used to the way it works now to change at this point. | 17:25 |
| dash | luks: not if there's no divergence. | 17:25 |
| luks | hm, interesting | 17:25 |
| SamB | huh, git at least has an option for it! | 17:25 |
| jelmer | SamB, defaults matter unfortunately | 17:26 |
| SamB | jelmer: yes, they do | 17:26 |
| dash | especially unfortunate defaults | 17:26 |
| SamB | but at least with git you CAN do it if you get asked to | 17:26 |
| luks | well, I think git people see the history differently than bzr people | 17:26 |
| ddaa | Anyway, I think that can be a useful sales script. | 17:26 |
| luks | in git it's a set of patches, basically | 17:26 |
| SamB | you know ? | 17:26 |
| ddaa | luks: and they are sooo wrong. | 17:27 |
| luks | but they seem to like it | 17:27 |
| ddaa | but I have yet figured the right arguments to explain it clearly. | 17:27 |
| luks | flat log / rebase / etc. | 17:27 |
| SamB | luks: er, well, it's not a set of patches | 17:27 |
| SamB | but sometimes they use it to store a pile of patches | 17:27 |
| luks | SamB: not technically, but they treat it that way | 17:27 |
| SamB | which it isn't at all good for | 17:27 |
| SamB | really | 17:27 |
| ddaa | luks: I believe git folks like it because either 1. they have hugre trees and require git performance or 2. they do not know any better. | 17:27 |
| SamB | I honestly wish there was some kind of git/darcs hybrid where you could keep that "set of patches" in a darcs-managed area on top of a git-managed history ... | 17:28 |
| Isaiah | ddaa: Or they use github ;) | 17:29 |
| luks | I can see that maintaining a mainline in the kernel wouldn't be easy | 17:29 |
| luks | but I think it would work better for most other projects | 17:29 |
| ddaa | SamB: the mental model of a tool's community is important. It dictactes a lot of the detail choices that form the day to day experience with the tool. | 17:29 |
| ddaa | luks: I believe the kernel has a strong culture of "lines of development", it's just that there are basically two kinds of people: those have the conceptualization skills required to see past git's quirks, and those that don't care. | 17:31 |
| ddaa | Less polarized projects may have more people in the middle area, where they build a workflow and mental model informed by the quirks of git's ui. | 17:31 |
| ddaa | I'm also a bit irked by how hg's documentation confused "changeset" and "revision". | 17:33 |
| SamB | anyway, it isn't always bad if things that were in feature branches end up in the mainline ... | 17:33 |
| ddaa | SamB: explain what you mean. | 17:33 |
| SamB | well, it depends on how noisy they were, mostly ... | 17:34 |
| ddaa | That's my point. | 17:34 |
| ddaa | The DVCS for TDD must support extremely chatty branches. | 17:34 |
| SamB | oh. | 17:34 |
| * SamB wishes the kernel used more TDD | 17:35 | |
| SamB | well, in the sense that tests would be nice | 17:35 |
| SamB | not in the sense that I think anyone should stop trying to think about the correctness of their code ... | 17:35 |
| ddaa | SamB: it's not clear it's at all possible for kernel development. Most of the problems are with hardware quirks. | 17:35 |
| SamB | ddaa: hmm. | 17:35 |
| luks | I imagine testing hardward interaction must be fun | 17:35 |
| SamB | well, it'd still be nice if there were more tests for the things that can be tested, you know? | 17:36 |
| SamB | the kernel isn't ALL drivers | 17:37 |
| SamB | and some of the drivers aren't for devices, even | 17:37 |
| luks | yeah, but that's usually the patch that is broken | 17:37 |
| luks | and should be properly tested | 17:37 |
| luks | er, s/patch/part | 17:37 |
| SamB | it'd be handy to have a provided test harness even without the tests, actually ... | 17:39 |
| ddaa | You need test, otherwise how do you know that your test harness works? :) | 17:40 |
| mthaddon | abentley: so the verdict on nested trees is that it's not in the immediate future - do you know if it'll be in bzr 2.0 and what the timeline for that is? | 17:41 |
| ddaa | For crissakes, can we very much please have it for bzr 2.0? | 17:42 |
| abentley | mthaddon: I don't know whether it'll be in 2.0. | 17:42 |
| SamB | ddaa: well, okay, I meant without many tests | 17:42 |
| abentley | mthaddon: I'm not sure what timeline you mean. | 17:42 |
| ddaa | It's a major differentiating feature, IMO it's worth delaying 2.0 until it's done and stabilized. | 17:42 |
| mthaddon | abentley: I was meaning when 2.0 is expected to be released, but if you're saying it might not be in 2.0, then I guess it's a moot point | 17:43 |
| mthaddon | but fwiw I'd agree with ddaa | 17:43 |
| abentley | ddaa: It's currently in the design stage. | 17:43 |
| abentley | mthaddon: There will be a 1.6 release. 2.0 could be the next release after that. | 17:44 |
| mthaddon | ok, thx | 17:45 |
| abentley | sorry, 1.16, not 1.6 | 17:45 |
| ddaa | abentley: That's good to know, but it does not contradict my position: it's a major differentiating feature, and it's worth delaying 2.0 for it, so it will have the exposure it deserves. | 17:47 |
| ddaa | There's only one shot at 2.0, so you must make it count. | 17:47 |
| abentley | ddaa: All other DVCSes have it, so it can only be a differentiating feature by being awesome. | 17:48 |
| ddaa | if you are referring to hg forests | 17:48 |
| ddaa | (or git equivalent) | 17:48 |
| ddaa | it's about as advanced as config-manager | 17:48 |
| SamB | abentley: what the heck do you mean that all other DVCs have it? | 17:48 |
| ddaa | meaning that IMHO it sucks major balls | 17:48 |
| SamB | and I don't think it's that great in any of them at the moment ... | 17:48 |
| ddaa | the only thing that's close is svn externals, and AFAIK no dvcs is even close to this level of seamlessness. | 17:49 |
| abentley | SamB: Mercurial has the forests extension, Git has submodules. (I shouldn't have said they "all" have it.) | 17:49 |
| SamB | and who uses them ? | 17:49 |
| SamB | especially who uses submodules ? | 17:49 |
| ddaa | But that's a good point. | 17:49 |
| ddaa | "All other dvcs claim to have it, although they have only some half-assed implementation, so the promotion impact of having it in bzr is consideradly lessened". | 17:50 |
| SamB | I remeber once someone actually had a problem while using them and asked a question about it in #git | 17:50 |
| SamB | but I don't remember if the problem was actually related to them or not | 17:51 |
| ddaa | SamB: I'd bet submodules suck, but we're talking perceptions here. | 17:51 |
| ddaa | abentley: OTOH, that means that NOT having nested trees for 2.0 can be a perceived weak point for bzr. | 17:52 |
| SamB | ddaa: perhaps only by someone who hasn't actually heard anything about how git's work ... | 17:53 |
| ddaa | According to this line of though, 2.0 should implement some minimal support for nested trees. | 17:53 |
| bialix | ddaa: do you aware of scmproj? | 17:53 |
| ddaa | SamB: which is the case of essentially anyone who's choosing a new DVCS. | 17:53 |
| ddaa | bialix: nope | 17:53 |
| SamB | ddaa: eh? | 17:53 |
| bialix | this is plugin emulated nested trees | 17:54 |
| ddaa | SamB: most people who are switching their project to a DVCS have only the vaguest ideas of the specifics of each tool. That why they usually end up just picking the fastest, because that's a difference they can measure. | 17:54 |
| bialix | I'd like to reuse some abentley work | 17:54 |
| abentley | ddaa: And *that*'s what 2.0 will address. | 17:55 |
| ddaa | bialix: is it usable in production | 17:55 |
| ddaa | abentley: I know that's the *main* goal of 2.0. | 17:55 |
| bialix | ddaa: nested trees is better | 17:55 |
| ddaa | bialix: abentley just said that nested-trees are "in the design stage" | 17:56 |
| bialix | yes | 17:56 |
| bialix | and this makes nested trees better | 17:56 |
| bialix | scmproj is poor emulation. it works but have some problems | 17:56 |
| ddaa | abentley: but I also think that the 2.0 release should pack the maximum punch possible. | 17:57 |
| ddaa | bialix: I hardly see how "something that's in the design stage" (implicitly, not something that's usable) can be better than something that works today. | 17:57 |
| bialix | git submodules is also work today, altough you guys very hardly on it | 17:59 |
| ddaa | Two different discussions. | 18:00 |
| ddaa | One hand: what's the right way to do it. | 18:00 |
| ddaa | Other hand: perception of potential adopters or switchers. | 18:01 |
| ddaa | As past experience has shown, they have very little overlap. | 18:01 |
| ddaa | Since the perception is that git and hg have a form of nested trees. | 18:01 |
| ddaa | The question is whether scmproj can be used to convincingly argue that bzr has feature parity. | 18:02 |
| bialix | I've designed scmproj based on forest/submodules and past nested trees spec. | 18:02 |
| bialix | but it need more love | 18:03 |
| bialix | I'd say it could be used to check different variants for implememting real nested trees | 18:03 |
| bialix | but I'm not aware someebody is using it aside me and AmanicA | 18:04 |
| bialix | so there is too little user feedback | 18:04 |
| bialix | is it usable? more or less. Could ut be better -- definitely | 18:04 |
| bialix | but all people waiting for real nested trees, so I'm doubt scmproj is vital alternative | 18:05 |
| ddaa | So we're still stuck without a viable conterparts for forests/submodules. | 18:07 |
| cdecarlo | I need to use a non-standard port to connect to my comuper over ssh, how do I use bzr+ssh:// to connect to a different port? | 18:07 |
| ddaa | Which I think should not be the case in 2.0. | 18:07 |
| cdecarlo | *computer | 18:08 |
| bialix | ddaa: we also still don't have versioned properties | 18:08 |
| ddaa | You mean file properties? | 18:10 |
| bialix | today they called rulkes | 18:10 |
| bialix | rules | 18:10 |
| ddaa | I do not know what you are talking about. | 18:11 |
| ddaa | And I like to think I know a thing or two about version control... | 18:11 |
| bialix | abently: does lp:bzr/1.15 is valid submit branch for BB? | 18:11 |
| bialix | ddaa: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#rules | 18:12 |
| ddaa | bialix: so you say this should be supported by metadata (not unlike revision properties) that have versioned text (like source files). | 18:15 |
| bialix | no, I don't say anything | 18:15 |
| bialix | this is not file properties | 18:16 |
| ddaa | I say, let's just stick that in a source file and be done with it. | 18:16 |
| bialix | the problem is these rules currently is not propagated | 18:16 |
| ddaa | It's not ideal, but there's a precedent with .bzrignore | 18:16 |
| bialix | many devs think it's wrong approach | 18:17 |
| ddaa | and the alternative are all pretty bad | 18:17 |
| bialix | and I understand why | 18:17 |
| ddaa | Well, I guess they have thought of an alternative I haven't thought of. | 18:17 |
| bialix | but.. at the end of the day there is still nothing in bzr | 18:17 |
| ddaa | Right. The bzr dev are sometimes too focused on doing the Right Thing, to the point of sometimes not doing anything. | 18:18 |
| bialix | :-/ | 18:18 |
| ddaa | See what happened with tags. | 18:18 |
| bialix | tags are bad | 18:18 |
| ddaa | They are certainly inelegant. | 18:19 |
| bialix | they definitely better than .hgtags | 18:19 |
| ddaa | Do they solve their target use case? | 18:19 |
| ddaa | I think so. | 18:19 |
| dash | huh. why are tags bad? | 18:19 |
| bialix | until you start change tags and merging them | 18:19 |
| ddaa | bialix: the point is that when you start to think about merging tags, you go mad. | 18:20 |
| bialix | today it's nightmare | 18:20 |
| bialix | I wonder how git does tags merge | 18:20 |
| jam | bialix: git has conflicts on tags pretty much the same as us | 18:20 |
| dash | merging tags sounds like a thing that shouldn't work at all | 18:20 |
| jam | dash: it is more the idea that both people have tag "foo" but they disagree on the value | 18:20 |
| jam | how do you resolve that? | 18:20 |
| bialix | jam: in git tags are objects | 18:20 |
| jam | bialix: they are just refs | 18:20 |
| jam | not versioned objects | 18:21 |
| jam | refs/tags/XXX IIRC | 18:21 |
| ddaa | I had the chance to participate in many a restaurant discussions about tags merging with lifeless and the folks, and once you started to think about merging and conflicts it became horrendously tricky in terms of user interface. | 18:21 |
| dash | jam: it would not hurt my feelings if that just failed outright | 18:21 |
| jam | ddaa: of course, then someone wants to delete a tag and have it propagate | 18:21 |
| bialix | ddaa: you know today bzr simply stops | 18:21 |
| bialix | there is absolutely no UI to merge tags | 18:22 |
| jam | I believe the current state for bzr is that you can do "bzr pull" which will keep your local tags and "bzr pull --overwrite" which will use the remote tags | 18:22 |
| jam | but merge doesn't have the same options, etc. | 18:22 |
| ddaa | that's fine | 18:22 |
| ddaa | at least the tags are there, and people no longer obsess about "bzr is missing tags" | 18:22 |
| ddaa | and since nobody has solved the problem any better, it's not net drag on adoption | 18:23 |
| bialix | jam: git's tags has additional metadata: who create tag and when. why bzr don't have it? | 18:23 |
| bialix | ddaa: so, using your classification, bzr has nested tree support today: from scmproj plugin. | 18:25 |
| bialix | it's almost equally ugly as in hg/git and it kinda works | 18:25 |
| ddaa | does it kinda work equally to hg/git? | 18:26 |
| jam | bialix: Because it wasn't part of the requirements that Martin put together when he created basic tag support | 18:26 |
| bialix | ddaa: you can get, update, commit, push easily entire nested construct. and perform more complex actions like in git | 18:26 |
| ddaa | if it's not any worse than hg/git solutions, then I say let's have 2.0 and big partay! | 18:27 |
| bialix | ddaa: other actions require more work | 18:27 |
| jam | bialix: also, git tags don't *always* contain that info | 18:27 |
| jam | I just tested it | 18:27 |
| jam | and I create .git/refs/tags/test-tag which just has a sha1 in it | 18:27 |
| ddaa | BTW, can we have 2.0 partay for DVCS geeks in Paris? | 18:27 |
| ddaa | Or alternately, can I have an invitation? | 18:28 |
| ddaa | I miss having beer with you folks. | 18:28 |
| bialix | jam: I was under impression git tags should have additional metadata. maybe I'm wrong | 18:28 |
| bialix | from some presentation about git. There is 4 basic objects in git: blob, tree, commit and tag | 18:29 |
| * bialix has to go | 18:30 | |
| * bialix waves | 18:30 | |
| cdecarlo | I needed bzr+ssh to use a non-standard port so I created a ~/.bazaar/authenication.conf file and configured the proper settings but I'm not sure if it's reading the file? is there a way to be sure | 18:30 |
| jam | too late, I guess. but git *also* has "signed tags" which *do* have extra meta info | 18:30 |
| * ddaa goes back to his "getting rich by startup founding" business | 18:35 | |
| dash | are you secretly paul graham? | 18:36 |
| ddaa | I wish. | 18:36 |
| ddaa | But if I were I would alread have solved the getting rich part. | 18:36 |
| ddaa | I would probably be working on some unlikely project such as "getting famous by changing how the world does rich text editing". | 18:37 |
| dash | yes please | 18:37 |
| ddaa | dash: for a couple millions euros, I'll happily abandon my current project and start working full time on this. | 18:40 |
| ddaa | one-time expense! | 18:40 |
| cdecarlo | my authentication.conf file isn't being accessed, is there some secret I don't know about? | 18:47 |
| Clint | why am i getting this, and how do i make it better? | 18:55 |
| Clint | bzr: ERROR: The method _generate_inventory is not supported on objects of type KnitPackRepository. | 18:55 |
| * ddaa watches helpless has texmacs is switch to git after the Savannah disaster. | 18:56 | |
| * ddaa watches helpless as texmacs is switching to git after the Savannah disaster. | 18:56 | |
| ddaa | No discussion, request for input, or consideration of alternatives. | 18:57 |
| ddaa | Clint: presumably because you are using some plugin that does not work with your version of bzr. | 18:58 |
| mattl | ddaa: we're moving to bzr after the Savannah problems, so any help you can give Clint on this would be very helpful. | 18:59 |
| Clint | ddaa: i will elaborate then. i did a bzr svn-import, got three "branches" from that, cloned them into subdirs of a --rich-root repo, and tried to join --reference them | 18:59 |
| Clint | the first worked, the second two give me that error | 18:59 |
| ddaa | Please paste the end of your .bzr.log in a pastebin | 19:00 |
| ddaa | I won't be able to solve it for you, but somebody else might. | 19:01 |
| ddaa | But I am questioning the usefulness of your doing join in this case. I doubt this will achieve the result you wish. | 19:01 |
| Clint | ddaa: http://paste.debian.net/37963/ | 19:01 |
| Clint | okay, what am i misunderstanding? | 19:01 |
| ddaa | What do you want to achieve by joining the branches imported from svn? | 19:02 |
| Clint | ddaa: mattl wants to be able to clone the rootdir and get all three | 19:03 |
| ddaa | You should write a small script using the "bzr branches" command. | 19:04 |
| ddaa | from bzrtools | 19:04 |
| mattl | Clint: is this turning into a nightmare? | 19:05 |
| ddaa | Also, I bet the error you have comes from using 'join --reference', nested trees do not really work. | 19:05 |
| mattl | okay. | 19:06 |
| ddaa | They are very experimental stuff. | 19:06 |
| mattl | Clint: let's just have a stable tree, experimental tree and trunk tree. | 19:06 |
| mattl | 3 seperate ones | 19:06 |
| ddaa | They are the equivalent of svn externals. You could use the scmproj plugin for this functionality. | 19:07 |
| mattl | would everyone need that plugin to check out? | 19:07 |
| ddaa | only to checkout the combination | 19:07 |
| ddaa | you do not need it to use branches individually. | 19:08 |
| mattl | yeah, that's too much for people to have to do | 19:09 |
| mattl | individual branches then | 19:09 |
| Clint | done | 19:10 |
| ddaa | sorry about the inconvenience, but you cannot really do partial checkouts or whole repo checkouts (as you do with svn) with any DVCS | 19:10 |
| mattl | yeah, just getting my head around it all. | 19:11 |
| mattl | been in CVS/SVN for about a decade, and used bzr for er.. 48 hours | 19:11 |
| ddaa | hope you'll like it | 19:12 |
| mattl | lots of people telling us to use git and hg | 19:13 |
| mattl | but like bzr, our project is soon going to be a GNU project | 19:13 |
| beuno | mwhudson_, I'd like to unblock my LH reviews today if possible | 19:42 |
| jelmer | beuno: hi | 19:44 |
| beuno | jelmer, hi again | 19:44 |
| jelmer | beuno, if there's anything else I can do to unblock the foreign revid stuff, please let me know | 19:48 |
| beuno | jelmer, I think it's enough for me to tweak and land | 19:49 |
| beuno | will get to it at the end of my day | 19:49 |
| jelmer | beuno: sweet | 19:49 |
| Clint | is the rich-root format mature enough for sanity? | 19:53 |
| jelmer | Clint: Yeah, the 1.9-rich-root format is stable and mature | 19:55 |
| jelmer | Clint, the 2.0 format will be rich root only | 19:55 |
| Clint | jelmer: i seem to have trouble reading it with bzr 1.5 | 19:56 |
| jelmer | Clint, well, yeah, bzr 1.5 doesn't support 1.9-rich-root | 19:56 |
| jelmer | Clint, it should support --rich-root-pack though, which was introduced in bzr 1.0 | 19:56 |
| Clint | jelmer: okay | 19:57 |
| jelmer | Clint, why do you need rich roots though? | 19:58 |
| Clint | jelmer: bzr svn-import; am i able to discard the svn stuff after that to release the rich-root requirement? | 19:59 |
| jelmer | Clint, no, unfortunately not | 19:59 |
| * Clint sighs. | 19:59 | |
| jelmer | Clint: The multiple formats thing is a mess :-( I would recommend using rich-root-pack if you're stuck with 1.5 | 19:59 |
| jelmer | This'll all go away with 2.0, where we'll have a single format | 20:00 |
| jelmer | not that that helps you now | 20:00 |
| * Clint nods. | 20:00 | |
| * SamB wonders how you can be stuck with 1.5 ... then remembers that it doesn't help if *you* have the latest release but none of the people who want to pull from you do ... | 20:01 | |
| Clint | having different trouble with 1.13 instead of 1.5 as well | 20:01 |
| jelmer | SamB, lenny has 1.6 | 20:03 |
| jelmer | s/1.6/1.5 | 20:03 |
| Clint | (and 1.13 in backports.org) | 20:06 |
| SamB | jelmer: oh. you mean people actually run stable? | 20:15 |
| SamB | ... I suppose that might be the case :-( | 20:15 |
| abentley | jelmer: Please stop sending bzr-gtk merge directives with revision serializer format 9. | 20:29 |
| jelmer | abentley, Am I still doing that? | 20:31 |
| jelmer | I'm using the same version of bzr to send bzr-gtk merge requests as I use to send bzr.dev merge requests | 20:32 |
| abentley | jelmer: Yes, you're still doing that. | 20:32 |
| abentley | Your message re: "Use Revision.get_apparent_authors rather than deprecated | 20:32 |
| abentley | Revision.get_apparent_author." does that. | 20:32 |
| abentley | jelmer: Are you storing your bzr-gtk stuff in the same repository as your bzr.dev stuff? | 20:33 |
| jelmer | abentley: Ah, no | 20:34 |
| jelmer | abentley, the bzr-gtk one is a development6 repository | 20:34 |
| jelmer | So I guess I should downgrade that to 1.9-rich-root | 20:34 |
| jelmer | abentley, thanks | 20:34 |
| abentley | jelmer: A real development6? Or your new dev6 with RIO? | 20:35 |
| jelmer | abentley, no, a real development6 repository, at least that's what "bzr info" says | 20:35 |
| jelmer | ("Shared repository with trees (format: development6-rich-root)") | 20:35 |
| jelmer | hmm | 20:36 |
| jelmer | downgrading to 1.9-rich-root fails though, with an error about subtrees | 20:37 |
| abentley | jelmer: http://paste.ubuntu.com/187614/ | 20:40 |
| abentley | jelmer: It's definitely in some wacky format. | 20:40 |
| jelmer | abentley: Hmm | 20:41 |
| jelmer | I haven't done anything special in this repository though, except for upgrading to --development6 | 20:41 |
| jelmer | so I wonder how I ended up with the version 9 revision serializer | 20:41 |
| lamont | gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototy | 20:42 |
| lamont | pes -g -O2 -g -Wall -O2 -fPIC -I/usr/include/python2.6 -c bzrlib/_patiencediff_c | 20:42 |
| lamont | .c -o /build/buildd/bzr-1.15/./build/temp.linux-armv5tel-2.6/bzrlib/_patiencedif | 20:42 |
| lamont | f_c.o | 20:42 |
| lamont | bzrlib/_patiencediff_c.c:28:20: error: Python.h: No such file or directory | 20:42 |
| lamont | interesting | 20:42 |
| lamont | bzr 1.15-1 on armel | 20:42 |
| jam | abentley, jelmer: bzrlib.chk_serializer.CHKSerializer.format_num == '9' | 20:46 |
| jam | At least, that is my guess | 20:46 |
| lamont | hrm.. probably something to do with build-depending on 2.4 and 2.5, while building with 2.6? | 20:46 |
| jelmer | jam: ah, yeah | 20:46 |
| jelmer | lamont, we depend on python-all-dev IIRC | 20:47 |
| lamont | Build-Depends: debhelper, cdbs, quilt, python, python2.5-dev, python2.4-dev, python-central, python-docutils, graphviz, zlib1g-dev | 20:48 |
| lamont | that's 1.15-1~bazaar1~hardy1 (speaking of which, what an ugly versio nmmber) | 20:49 |
| abentley | jam: It looks like it's not registered in serializer.format_registry. | 20:50 |
| cody-somerville | jelmer, any luck with that bzr-git bug? :) | 20:55 |
| jelmer | cody-somerville: It turned out to be less trivial than I had expected, not sure what's causing it exactly yet | 20:55 |
| jszakmeister | So, I think I found an interesting bug (or at least that's the way it appears). | 21:13 |
| jszakmeister | SvnRepository derives from ForeignRepository which derives from Repository | 21:14 |
| jszakmeister | SvnRepository inherits Repository's iter_inventories() method. | 21:14 |
| ddaa | Hey. Got a showstopper problem with trac-bzr. | 21:14 |
| jszakmeister | However, in Repository.iter_inventories() it's calling self._iter_inventories(), which is supposed to call SvnRepository._iter_inventories(), but appears to be calling Repository._iter_inventories() instead. | 21:15 |
| ddaa | Not sure what's going on, but trac crashes when trying to compare a offset-naive datetime with an offset-aware datetime. | 21:16 |
| ddaa | When trying to build the list of change dates. | 21:16 |
| ddaa | Using bzr 1.15, Trac 0.11.4, and trac-bzr tip from launchpad. | 21:17 |
| jszakmeister | It's like the method lookup is failing to find SvnRepositories _iter_inventories method. | 21:17 |
| jszakmeister | It's very weird. | 21:18 |
| ddaa | jszakmeister: usually, when I get this impression with python code, I find that I made myself confused. I suggest you look at it again tomorrow with a fresh mind. | 21:19 |
| jszakmeister | Oh, no I'm not confused. I dumped information from the code object... it's calling the wrong method. | 21:20 |
| ddaa | Python does not do weird mysterious thing, and bzr and bzr-svn do not do inscrutable voodoo hack. It's almost certainly doing the obvious thing. | 21:20 |
| jelmer | jszakmeister, that bugs already been fixed | 21:20 |
| jszakmeister | jelmer: the one I filed or a different one? | 21:20 |
| jelmer | jszakmeister, the one you filed | 21:21 |
| jelmer | its fixed in the main bzr-svn branch | 21:21 |
| jszakmeister | I saw that. I pulled your branch, and now I get a failure elsewhere. | 21:21 |
| jszakmeister | I'm getting this now: 'NoneType' object has no attribute 'get_record_stream' | 21:23 |
| jszakmeister | And it appears it's not entering the right _iter_inventories() method. :-( | 21:24 |
| jelmer | jszakmeister, can you pastebin the traceback? | 21:26 |
| jszakmeister | Sure can. | 21:26 |
| jelmer | jszakmeister, qbrowse works fine for me with the change fwiw | 21:26 |
| jszakmeister | http://pastebin.com/m4d9df712 | 21:28 |
| jszakmeister | jelmer: are you running from a branch? I've been trying to get it to work against a remote repository. | 21:28 |
| jelmer | jszakmeister, against a remote repository | 21:28 |
| jszakmeister | Weird. I wonder what's up with my setup then? | 21:29 |
| jelmer | bzr-svn 3030? | 21:29 |
| jam | abentley: ping | 21:29 |
| jam | Something is a bit funny with the codereview preview | 21:30 |
| jam | namely: https://code.edge.launchpad.net/~jameinel/bzr/1.16-simple-win32/+merge/6984 | 21:30 |
| abentley | jam: pong | 21:30 |
| jam | It is including vincent's changes | 21:30 |
| jam | (Perhaps bzr trunk was not up to date when it generated the diff?) | 21:30 |
| jam | I don't see a way to tell code-review to regenerate the diff | 21:30 |
| jelmer | jszakmeister, ^ | 21:31 |
| jszakmeister | jelmer: 3029 | 21:31 |
| jszakmeister | lemme pull again | 21:31 |
| abentley | jam: Code Review is branch-oriented. If your branch is based on Vincent's, it thinks you're trying to merge the whole thing. | 21:31 |
| jelmer | jszakmeister, 3029 should also include the fix | 21:31 |
| jam | abentley: there is a single revision from my branch that isn't in trunk | 21:31 |
| jam | it was only based on vincent's in that I branched from bzr.dev | 21:32 |
| jelmer | jszakmeister, it looks like you're running an old version somehow | 21:32 |
| jam | it even gets that right in the 'list of revisions' to be merged | 21:32 |
| jam | My guess is that I submitted the request | 21:32 |
| jam | inbetween the time that the mirroring script updated lp:bzr from http://bazaar-vcs.org/bzr/bzr.dev | 21:32 |
| jam | and the time vincent landed his patch | 21:32 |
| jszakmeister | jelmer: I don't believe so... I can see my debug lines in the output | 21:33 |
| jszakmeister | I'll check and see if something else is being picked up though. | 21:33 |
| abentley | jam: I assume you're talking about the review diff, not the preview diff. | 21:33 |
| jam | abentley: sure 'Review diff' | 21:34 |
| abentley | jam: Did you use bzr send? Code Review will take your review diff out of your merge directive verbatim. | 21:34 |
| jam | I don't know what the difference is, specifically | 21:34 |
| jam | abentley: no, I used the web | 21:34 |
| jam | "propose for merge" | 21:34 |
| jszakmeister | jelmer: I think you're right. I have my soft link set up wrong. | 21:35 |
| abentley | jam: A review diff is a diff against the LCA of the tip and the submit branch trunk, as generated by "bzr send" | 21:35 |
| abentley | jam: it's shown at the bottom of the merge proposal. | 21:35 |
| abentley | jam: a preview diff is a diff of the submit branch tip against a submit branch tip with the source branch tip merged into it. | 21:36 |
| jszakmeister | You rock jelmer! | 21:36 |
| abentley | jam: It is generated by MAD and is accessible from the "Diff against target" link. | 21:37 |
| jszakmeister | I though I had another debug statement in bzr-svn, but it was in bzrlib. The one I had in there *wasn't* being printed. | 21:37 |
| jszakmeister | Thank you sir! | 21:37 |
| jelmer | jszakmeister, np | 21:37 |
| abentley | jam: I suspect what happened here is that your review diff was generated before lp's mirror of bzr.dev was updated. | 21:37 |
| jam | abentley: my assumption as well | 21:38 |
| jam | I filed bug #383346 about it | 21:38 |
| ubottu | Launchpad bug 383346 in launchpad "code review has no way to force regenerating Review diff" [Undecided,New] https://launchpad.net/bugs/383346 | 21:38 |
| abentley | jam: You didn't file a bug about it being wrong? | 21:39 |
| jszakmeister | No off to figure out how to teach qbzr not to look at the local repository for revision info, if you happen to be trying to browse an unrelated remote repo. | 21:39 |
| jam | abentley: well that bug mentions that it is wrong, and probably due to the race condition | 21:39 |
| jam | you can change the subject to whatever fits best in your mind | 21:39 |
| abentley | jam: I think it's more important to get it right than to be able to regenerate it. | 21:40 |
| jam | abentley: I don't think you can avoid the race condition | 21:40 |
| jam | Though also in the bug I mentioned the possiblity of detecting it after the fact | 21:40 |
| jam | (revs that were requested for review show up in the merge target) | 21:40 |
| abentley | jam: We can at least perform a mirror immediately before generating the diff. | 21:40 |
| ddaa | FFS, how can the datetime handling in trac-bzr even work with trace 0.11? | 21:41 |
| jam | abentley: that would be possible, but still leaves open the issues with landing pieces of a multi-phase patch | 21:41 |
| ddaa | It's out and out braindead. I cannot imagine how it could have passed even superficial testing. | 21:41 |
| * ddaa blames jelmer | 21:42 | |
| ddaa | actually, bzr blames jelmer | 21:42 |
| abentley | jam: Until there's proper support for base revisions or dependent branches, you can use bzr send for that. | 21:43 |
| jam | abentley: or you could just detect that the set of revisions for review changed... | 21:43 |
| jam | or have something easier than "Resubmit" to regenerate the diff | 21:44 |
| abentley | jam: No, we should not. People who are reviewing something should be reviewing the same thing. Regenerating the diff breaks that, and makes people review the integration, not the change. | 21:44 |
| ddaa | jelmer: dude, revision 60 http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/revision/60#tracbzr/backend.py | 21:45 |
| ddaa | by default, timestamps are offset-naive, not utc! | 21:45 |
| ddaa | jelmer: what were you trying to fix when you made this change? | 21:46 |
| jelmer | ddaa: argh, not sure how that got in | 21:46 |
| ddaa | I'll try reverting that in my trac, see if that makes it happier. | 21:46 |
| ddaa | jelmer: that fixes it for me. | 21:53 |
| ddaa | bzr merge -r60..59 | 21:53 |
| ddaa | jelmer: will you patch mainline for me? | 21:53 |
| dash | oh man =/ | 21:55 |
| dash | i am getting an exciting error message with bzr 1.15 | 21:55 |
| dash | http://paste2.org/p/243728 | 21:55 |
| abentley | dash: It's the loom plugin being out of date. | 21:56 |
| dash | aah. | 21:56 |
| ddaa | abentley: darn, I was hoping it was bzr-svn so I could blame jelmer again ;) | 21:57 |
| abentley | ddaa: We could blame jelmer because bzr-svn doesn't auto-update bzr-loom >:) | 21:57 |
| ddaa | abentley: Deal! | 21:58 |
| ddaa | And next, we'll blame jelmer for war in Palestine. | 21:58 |
| dash | so i guess i get to try to fix it :) | 22:06 |
| fullermd | Oh look, a big long thread of ranting on pgsql-hackers about git's lacking co [--lightweight]... | 22:07 |
| jelmer | ddaa: You're welcome to do that yourself, we need more trac-bzr hackers :-) | 22:09 |
| jelmer | ddaa: Otherwise, I'm happy to do it | 22:09 |
| ddaa | jelmer: okay, sent my team application, approve it and I'll fix your mainline. | 22:12 |
| jelmer | ddaa, welcome | 22:13 |
| fullermd | I really hate launchpad sometimes. | 22:17 |
| ddaa | jelmer: ur maine-coon r a fixed. | 22:19 |
| ddaa | I mean mainline, not maine-coon sorry. I blame my inner lolcat. | 22:19 |
| jelmer | ddaa, kthx! | 22:20 |
| jam | thumper: ping | 22:20 |
| thumper | jam: just on a call right now | 22:20 |
| jam | thumper: np, just though I'd mention that my patches for gc stacking are up for review | 22:21 |
| thumper | jam: excellent, thanks | 22:22 |
| jelmer | jam: I'm wondering if maybe some of my later changes to bencode had an impact on performance | 22:22 |
| jam | jelmer: I should have been using the very lastest version of your code for my testing | 22:22 |
| jelmer | jam: I mean negative impact | 22:22 |
| jam | which changes? | 22:23 |
| jam | stuff like strtol? | 22:23 |
| jam | instead of PyLong_FromString? | 22:23 |
| jelmer | jam: The ones after I put up the patch for review | 22:23 |
| jelmer | jam, yeah, that sort of thing | 22:23 |
| jelmer | well, I would be surprised if strtol would be slower than PyLong_FromString | 22:24 |
| jelmer | but I'm a bit surprised with the current performance given what I saw earlier | 22:24 |
| jml | so, how does one actually _use_ py_memory_dump? | 22:33 |
| LarstiQ | good question, a colleague of mine used it, I should look at how he did that | 22:34 |
| * LarstiQ goes to sleep | 22:35 | |
| ddaa | jelmer: do you know why all the revision names are urlencoded? | 22:35 |
| jam | jml: from memory_dump import scanner; scanner.dump_gc_objects('filename.txt') | 22:35 |
| jam | from memory_dump import loader | 22:35 |
| jam | m = loader.load('filename.txt') | 22:35 |
| jam | etc | 22:36 |
| ddaa | it's very annoying, because it encodes 1. the colon in special revision names 2. the slash name of branches in subdirs. | 22:36 |
| jml | jam: thanks. | 22:36 |
| ddaa | jelmer: I'd hack it away, but I'm afraid of breaking older trac releases. | 22:36 |
| jam | jml: you can do the load in a separate process, in case you are already at, you know, 4.5GB of resident memory :) | 22:36 |
| jam | though that dump will be a bit painful regardless | 22:36 |
| jelmer | ddaa: It's a dvcs, use a separate branch :-) | 22:36 |
| jelmer | the only other release we worry about is 0.10, and the main difference in that is the datetime stuff | 22:37 |
| jelmer | abentley, is bundlebuggy running bzr.dev ? if so, any chance you can update it? The serializer 9 registration patch has landed | 22:48 |
| abentley | jelmer: No, it's not. | 22:54 |
| jelmer | abentley, is there some way I can force the format of the serializer | 22:54 |
| jelmer | used in merge directives? | 22:54 |
| abentley | jelmer: The only way to force the format of the serializer is to change the repository format. Bundle format 4 copies this data verbatim. | 22:55 |
| jelmer | abentley: okay, I'll fall back to manual patches for now then. Thanks | 22:56 |
| abentley | jelmer: I'll upgrade BB to 1.16 when it comes out. | 22:56 |
| salgado | hi there. is it possible to recover from a corrupted .bzr/checkout/dirstate ? | 22:57 |
| Peng_ | salgado: You could just nuke .bzr/checkout and run "bzr checkout". | 22:57 |
| salgado | all of a sudden one of my branches is giving me this whenever I do 'bzr <anything>': bzr: ERROR: The dirstate file (DirState(u'/home/salgado/devel/launchpad/mainline/.bzr/checkout/dirstate')) appears to be corrupt: trailing garbage: 'AAATMUexj0JHsY9' | 22:57 |
| jelmer | abentley: Cool. I can survive with plain patches for a month or so. | 22:57 |
| Peng_ | salgado: (Um, that's assuming you're using a regular branch, not a checkout or something.) | 22:57 |
| salgado | Peng, yes, this is supposed to be a regular branch. will try that, thanks | 22:58 |
| ddaa | jelmer: I savagely removed all the urllib.quote/unquote functionality, and it does not appear to break anything for me | 23:06 |
| ddaa | while at the same time fixing my problems | 23:06 |
| jelmer | ddaa, Yeah, the code badly needs a cleanup | 23:06 |
| jelmer | ddaa, I've mostly been trying to keep it running for bitlbee/ctrlproxy | 23:06 |
| ddaa | the ctrlproxy one is borked | 23:06 |
| jelmer | yeah, I haven't had time for trac-bzr recently | 23:07 |
| ddaa | I don't have time either really. | 23:07 |
| jelmer | unfortunately there aren't a lot of alternatives to trac | 23:07 |
| jelmer | redmine is nice but it's ruby | 23:07 |
| jelmer | and I don't know ruby | 23:07 |
| ddaa | I dunno either trac or redmine | 23:08 |
| jfroy | jelmer: I'm having a weird problem with rebase | 23:08 |
| ddaa | I'll upload my patch in a branch, and I'll let the crowd decide. | 23:08 |
| jelmer | ddaa: did you try running the testsuite? | 23:09 |
| ddaa | nope | 23:09 |
| jelmer | jfroy, ? | 23:09 |
| jfroy | I try to pull from a branch (remote svn branch), get a notice that the branches have diverged. | 23:09 |
| jfroy | I try to rebase on to that same URL, and that does nothing | 23:09 |
| jfroy | unless I forgot how to rebase... | 23:09 |
| ddaa | jelmer: what's the magic command to run the test suite? | 23:09 |
| jelmer | jfroy, are the urls for pull and rebase the same? | 23:09 |
| jfroy | yes | 23:10 |
| jelmer | ddaa: "trial tracbzr" / "nosetests tracbzr" | 23:10 |
| ddaa | jelmer: it fails horribly | 23:11 |
| ddaa | but I cannot be bothered to fix it right now | 23:12 |
| jelmer | ddaa: did you verify that % and : in revision ids still work after removing the urllib.quote/unquote sutff? | 23:12 |
| jelmer | vila, ping | 23:12 |
| ddaa | jelmer: lol | 23:12 |
| ddaa | I'd bet they don't | 23:12 |
| ddaa | but I specifically want "current:" and friends not to be escaped | 23:13 |
| ddaa | and I do not have any such revision handy | 23:13 |
| jfroy | it prints "Started 2 unique searchers for 8 unique revisions" in the trace then exits with 0 | 23:14 |
| jfroy | however bzr missing says I'm missing 3 revisions | 23:15 |
| jfroy | I could try rebase against a fresh local branch of the remote branch | 23:15 |
| jelmer | jfroy, and missing also says that you've got extra revisions? | 23:15 |
| jfroy | correct, 1 extra | 23:16 |
| jfroy | which is actually a merge revision | 23:16 |
| jfroy | yeah, rebase against a local copy of the remote branch yields the same result | 23:17 |
| jfroy | urg, seems I'm hosed :/ | 23:17 |
| jelmer | jfroy, rebase skips merges | 23:18 |
| jelmer | jfroy, known bug | 23:18 |
| jfroy | but shouldn't I pick the 3 revisions I am missing from the remote branch, then rebase the merge on top of that new history? | 23:18 |
| jfroy | *shouldn't it | 23:18 |
| jelmer | jfroy, it's a known bug, it should handle the merge | 23:18 |
| jfroy | I see | 23:18 |
| jfroy | gotcha | 23:18 |
| jfroy | mmm | 23:18 |
| jfroy | I guess I can uncommit | 23:19 |
| jfroy | the merge was clean, easy to re-do | 23:19 |
| jfroy | pretty serious bug though :/ | 23:19 |
| jfroy | mmm | 23:20 |
| jelmer | jfroy, even when it will support merges, they'd be quite prone to conflicts | 23:20 |
| jfroy | uncommit actually puts merges back to pending? | 23:20 |
| jfroy | yeah I guess it would.... | 23:21 |
| jelmer | yeah, it only changes the branch | 23:21 |
| jfroy | need to revert it out | 23:21 |
| jfroy | and then revert --forget-merges (why can't you do both at the same time...) | 23:21 |
| mwhudson_ | i think i want to refactor how loggerhead serves branch content | 23:23 |
| jfroy | and well, would it be that prone to conflicts if the merged branch was orthogonal? | 23:23 |
| jfroy | mmmm | 23:24 |
| jfroy | bzr merge -r foo.. doesn't seem to be doing what I want | 23:24 |
| jfroy | I thought this would mean "cherrypick from revisions foo to tip of branch being merged" | 23:25 |
| jelmer | jfroy, bzr revert with no arguments does both | 23:25 |
| jfroy | but it seems to be picking a lot more revisions than that | 23:25 |
| Peng_ | mwhudson_: Eh? | 23:25 |
| jelmer | mwhudson_, ? | 23:25 |
| jfroy | jelmer: oh? | 23:25 |
| jelmer | mwhudson_, into a separate loggerhead.app thing? | 23:25 |
| jfroy | that's not clear | 23:25 |
| mwhudson_ | Peng_: basically, i think we should always traverse to the branch, then see if the request is for .bzr | 23:26 |
| mwhudson_ | though i guess that doesn't work for repositories | 23:26 |
| mwhudson_ | '/.bzr/' in PATH_INFO is a bit gross | 23:26 |
| jfroy | nevermind, bzr was sane, I was not :/ | 23:29 |
| ddaa | jelmer: here you have my shameless hack. | 23:41 |
| ddaa | https://code.launchpad.net/~ddaa/trac-bzr/trac-bzr.ddaa | 23:41 |
| ddaa | Mh... crap committer name... I'll fix that. | 23:42 |
| dash | bloarg | 23:56 |
| dash | so today my task is to merge some code into an svn repo that was copied out of it a month ago, into a separate svn repo | 23:56 |
| dash | and hacked upon | 23:56 |
| dash | i've got bzr branches of both now via bzr-svn | 23:57 |
| dash | i wonder if it makes sense to try to replay any of the history | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!