=== doko_ is now known as doko [00:19] poolie: landline is diverted, ping me I ring you [00:20] hi all, how can I find out what revision a file was added? [00:21] bzr log file [00:22] bzr: ERROR: Path does not have any revision history: PyRSS2Gen.py [00:22] maybe it was never added? [00:22] bzr log --line filename | awk '{print $1}' | sed -e s/:// [00:22] If I put a new file in the directory and do a commit, does it get added automatically? [00:22] chiefinnovator: no [00:22] chiefinnovator: you need to run bzr add [00:23] ohh [00:23] chiefinnovator: you can use --strict on commit to have bzr error if you have un-added files [00:23] perhaps we could have some sort of regexp that designates a "source" file [00:23] and automatically add them [00:23] bob2: hi tom, I see you've changed your nick [00:24] chiefinnovator: or add "[ALIASES]\ncommit = commit --strict" to ~/.bazaar/bazaar.conf [00:24] thanks [00:24] bob2: we don't need an explicit include regexp because we have an explicit exclude one === bob2 is now known as bob2` [00:30] File "/usr/lib/python2.5/site-packages/bzrlib/graph.py", line 48, in [00:30] class DictParentsProvider(object): [00:30] File "/usr/lib/python2.5/site-packages/bzrlib/graph.py", line 56, in DictParentsProvider [00:30] @symbol_versioning.deprecated_method(symbol_versioning.one_one) [00:30] AttributeError: 'module' object has no attribute 'one_one' [00:31] hm [00:31] that's no fun [00:32] nm... I think I know what the problem is... maybe... === bob2` is now known as bob2 [01:31] mtaylor: interesting === kiko-fud is now known as kiko-zzz [01:42] lifeless: so, I got that from having a running bundlebuggy and then upgrading bazaar out from underneath it === poolie_ is now known as pooliex61 [01:49] what is "rich-root" format? [01:50] It emails your credit card number to your sysadmin. [01:50] it stores information about the branch root (.) [01:50] in practice, "it's the branch format you need to use bzr-svn" [02:01] New bug: #187207 in bzr "commit reports error when a file has been moved and then removed in the same revision" [Undecided,New] https://launchpad.net/bugs/187207 [02:02] bob2: danke [02:11] (or rich-root-pack) [02:13] always go for rich-root-pack over rich-root [02:14] both seem a lot slower for pulling from a pack repository than regular pack [02:14] how does one select rich-root-pack over rich-root? [02:14] yup [02:14] different code path [02:15] like orders of magnitude [02:15] bob2: thanks :) [02:15] Solarion: --rich-root vs --rich-root-pack to bzr init-repo/upgrade [02:15] hah [02:15] Solarion: but only use --rich-rooot if you are using bzr-svn [02:15] bob2: I worked quite hard to make packs fast :) [02:16] lifeless: I am indirectly [02:16] this is a branch of my working branch [02:24] lifeless: yeah, I've noticed :) is rich-root-pack going to be able to inherit much of that work? [02:24] Actually, I imagine it does, if it's pulling rrp->rrp. It's p->rrp that doesn't get the benefit. [02:24] hm [02:25] (that's just a guess, of course) [02:32] --rich-root-pack should be as fast as --pack-0.92 I think [02:32] it only uses a slightly different serializer === mw is now known as mw|out [02:33] jelmer: so loggerhead actually already supports file path/revision number based urls [02:33] mwh: oh ok [02:34] mwh: what url format should I use? [02:34] there is no way to know this without reading the source though [02:34] jelmer: i can't remember :/ [02:34] i think you just put the revno where the revid would be [02:34] and append the path [02:34] pulling bzr.dev into a rich-root-pack repo is about 50% slower than into a pack one, and throws a missing revision error [02:34] so it's like http://loggerheadroot/annotate/$revno/file/path [02:35] bob2: Right, I mean from rich-root-pack to rich-root-pack [02:35] jelmer: ah [02:36] bob2: Anything that converts between formats is probably going to be slower (because you need to deserialize and reserialize) [02:37] ah - pack to rich-root is like 50x slower [02:38] pack->knit (which r-r is) is probably real slow, since is has to generate the annotations... [02:38] ahhh [02:50] So what's the point of rich-root and rich-root-pack? [02:51] bob2: don't pull bzr.dev into rich-roots yet anyhow, see the bug on lp about inventory sha corruption [02:51] ah [03:15] is it possible to get bzr log to show diffs? [03:15] or did I imagine that [03:24] hi all [03:25] any idea why ubuntu is shipping an uninstallable version bzr-svn in gutsy? [03:25] skwashd: why is it uninstallable? [03:26] cos it depends on 0.91 yet the version of bzr in gutsy is 1.0.1 [03:26] I think that's the version of bzr from bazaar-vcs.org [03:26] \bzr-svn: Depends: bzr (< 0.91~) but 1.0-1~gutsy1 is to be installed [03:26] gutsy doesn't have 1.0 to the best of my knowledge [03:26] it's in gutsy-backports [03:26] did you add the bazaar-vcs.org apt sources to your sources.list? [03:27] ah [03:27] but an updated bzr-svn is not [03:27] well then. [03:27] * mtaylor recommends the bzr ppa ... but that's not really the question here, so he'll shut up now :) [03:28] mtaylor: ok i will try that [03:28] skwashd: if you can live with older bzr, sudo aptitude install bzr=0.91, or what mtaylor said [03:29] which will give you bzr 1.1.0 [03:31] mtaylor, you're the second person to mention this [03:31] could you file a bug on launchpad please? [03:37] quick question. What is used to output messages with line breaks in bzr? been pokng around but I can't find any examples [03:48] great now i have bzr 1.1 installed [03:48] next issue :) [03:49] i have 2 svn repos ... i want to be able to merge from one to the other ... can bzr handle that? [04:55] bob2: you imagined it, but feel free to make your dreams reality. The API for diffing is pretty straightforward. [04:56] hehe [04:56] bbiab [04:58] fullermd: that's a planned feature, but not here yet. [04:59] abentley: hm, do you think it'd be more reasonable to show diffs for each (nested) revision, or just leaves? [05:01] bob2: I proposed log -vv to do this on the list a week or two ago [05:01] bob2: I use log-format=short, because I don't want to know about nested versions. [05:01] bob2: patches for the win [05:01] ah [05:01] lifeless: hah, missed that, but that's the command I was trying [05:01] log -v -> status [05:01] log -vv -> diffs [05:01] as abentley says, get it working :) [05:01] So I don't know what someone using log-format=long would want. [05:02] If bob2 touches the code, that means he gets all wishlists for the output forever, right? ;) [05:02] for long, I would like to see the diff against each left hand parent [05:02] fullermd: the bikeshed will remain unpainted [05:02] hmm [05:02] or [05:02] possibly better [05:03] Either that, or that shade of puke green that Tom's so fond of. [05:03] the diff against the next output revisions [05:03] abentley: zouch [05:03] haha [05:03] abentley: you should be careful now; as an employee of The Evil Corporation(TM) you are now ripe for abuse and slander [05:03] (I was looking for the diff that showed why bzrlib.fetch.Fetcher was removed and broke the fetch command) [05:04] lifeless: oh fun. [05:04] bob2: actually for diffs its easy: do the same diff that log -v does status off [05:04] s/off/of/ [05:05] bob2: that way, we can just change both at the same time if so desired [05:05] lifeless: +1 [05:07] oh, btw: did BB send you an error message for your bb:discuss-please ? [05:07] yes [05:08] Sorry about that. But I'm glad the error reporting's working. [05:08] oh I was expecting something of the sort :) [05:10] heh, perhaps it is time to remove legacy_lf [05:32] lifeless: I can't quite figure out what you mean by "do the same diff thsat log -v does status off" [05:32] Do the diff relative to the revision that it does the stat relative to for the filenames affected. [05:34] right [05:36] hm [05:50] Oh good grief! I didn't even know we *had* a "get_deltas_for_revisions" method. [06:19] abentley: didn't you add that ? [06:19] abentley: btw, thats the sort of method I expect repo's to specialise :) [06:51] lifeless, i'm off the phone etc, but i guess you'regone [06:52] or anyhow you should go, soon [06:52] heh [06:52] you had a phone day huh? [06:53] yeah [06:53] one more mail, then it's either you or the bike :) [06:54] on your bike [06:54] lets talk tomorrow avo [06:54] 3ish [06:55] fine with me [06:55] * lifeless is about to wow [06:55] enjoy === mrevell_ is now known as mrevell === kiko-zzz is now known as kiko [09:50] New bug: #187267 in bzr "UnicodeDecodeError with non-ASCII character in filename" [Undecided,New] https://launchpad.net/bugs/187267 [10:25] jelmer: ping, got a workaround for the infamous '_' used for gettext in bzr-gtk clashing with bzr selftest [10:41] vila: ah, nice [10:42] vila: any chance you can send an email to the bzr-gtk list? [10:42] jelmer: :) That's the bit I was searching, my last patch to bzr-gtk is so old I can't remember the workflow :) [10:44] jelmer: is there a bug on lp or that ? [10:44] s/or/for/ [10:44] I'm not sure [10:44] it's a bit quiet in bzr-gtk land at the moment [10:55] jelmer: Ok, I'll file one then [10:56] New bug: #187280 in bzr "Running 'bzr -log -r branch:../other_branch' raises ReadOnlyError" [Undecided,New] https://launchpad.net/bugs/187280 [11:00] bzr rocks ^_^ [11:00] * Toksyuryel just wanted to say that [11:00] Toksyuryel: thanks :) [11:05] New bug: #187283 in bzr-gtk "bzr selftest bizarre errors related to '_''s gettext" [Undecided,New] https://launchpad.net/bugs/187283 [11:08] vila: are you going to post the workaround too ? :-) [11:08] jelmer: sure :) Finishing the mail, I needed the bug number before hand :) [11:13] jelmer: sent [11:17] thanks :-) [12:24] The bazaar site has a list of projects that use bazaar http://bazaar-vcs.org/WhoUsesBzr. Is this up to date and does anyone have any other good examples of large projects/companies using bazaar? [13:16] hey folks [13:16] the bzr mac port seems to always be broken [13:17] is there anything that I should know? [13:19] Well, the developers are all goths from Mars. [13:20] * Peng gets booed off the stage. [13:22] Peng, hehehe, it's early/late in the morning/evening for jokes that complex :p [13:22] I reckon they might be. firstly they have a special deb-source for ubuntu. then the ports never work [13:22] ubuntu universe, like the rest of the world uses.. is WAY out of date [13:24] ubotu, last time I heard they had make a dmg for OSX for 1.1 that seemed to work fine. Where are you downloading from? [13:24] argh [13:25] s/ubotu/quik__ [13:25] _quik: I just installed 1.1 on OS X. You have to have xcode installed. Otherwise some of the dependencies crash and burn. [13:25] I just installed leopard and xcode 3.0 on this laptop yesterday [13:26] Not trusting xcode 3.0, I did 2.5. [13:26] did youz try macports? [13:26] it installed a few weeks ago on two other machines that are on the same.. [13:26] yes, always macports [13:26] Me too. [13:27] okay, because that worked for me, though I'll have to stick with tiger and Xcode 2.5 [13:27] You should also uninstalled and clean the dependencies. I did that after it failed. [13:27] Then it worked. [13:28] Too bad xcode isn't available via macports. [13:36] I think apple think that macports is a bastard child that dirty developers use [13:36] I can't understand that its not built into the os or even installed with xcode === mrevell is now known as mrevell-lunch [13:52] Hi! [13:52] I would like to ask something about the smart server! [13:53] I have set up a smart server through inetd with --directory=/home/lala/bzr-repo which is my repository [13:54] So bzr branch bzr://host/branch1, where branch1 a branch in my repo, works ok. [13:54] But trying to push changes through bzr push bzr+ssh://login@host/branch1 throws the following error [13:54] bzr: ERROR: Parent directory of bzr+ssh://login@host/branch1 does not exist [13:55] And I can push only if I give the full path, like: [13:55] bzr push bzr+ssh://login@host/home/lala/bzr-repo/branch1 [13:55] Why I can't just bzr push bzr+ssh://login@host/branch1? [13:57] my guess, because your logging in via ssh you don't use the smartserver from inetd [14:00] Probably you are right, because I also can't branch with bzr branch bzr+ssh://login@host/branch1 [14:00] Yes. [14:00] bzr: ERROR: Not a branch: "bzr+ssh://papadako@groogle.csd.uoc.gr/branch1 [14:00] bzr+ssh sshes in and runs "bzr server". [14:00] And its paths are relative to the root of the server. [14:01] Ok. So I can't do anything about it, right? [14:01] Relative paths are smaller than full paths. [14:02] perhaps a chrooted ssh enviroment could work [14:02] Well, not easily, anyway. [14:03] What he said, or maybe the contrib/bzr_access script, or some sort of ssh configuration. [14:03] Ok. Thank you! [14:04] Well, if you have root access, you can put your repos in /srv/bzr or something. [14:05] Yep, this could also work [14:15] One more question.. [14:15] Related to the webserve. [14:15] Last change for each branch, shows 38 years.... [14:16] See http://groogle.csd.uoc.gr/bzr/ [14:16] Like it does not read info from the branch. [14:23] 38 years ago is 1970, i.e Unix epoch or (time == 0), I'll check file last modification time and time itself on the server... [14:40] Time on the server is fine [14:40] Wed Jan 30 17:20:15 EET 2008 [14:41] http://groogle.csd.uoc.gr/bzr/groogle-2007 for example shows correct info [14:41] It is the main page showing 38 years. [14:41] Also I hit a bug in http://groogle.csd.uoc.gr/bzr/terrier-devel [14:41] : list index out of range args = ('list index out of range',) message = 'list index out of range' 0 [14:42] in templater.py === mrevell-lunch is now known as mrevell === weigon_ is now known as weigon === mw|out is now known as mw === kiko is now known as kiko-fud [15:36] The bzr vs hg page on the wiki mentions bazaar having integration with bugzilla out of the box. Can any one point me in the direction of documentation on this feature? [15:41] muffinresearch: bzr help bugs [15:43] Excellent thanks for that [15:56] New bug: #187330 in bzr "Commit failed with attribute error" [Undecided,New] https://launchpad.net/bugs/187330 [16:40] New bug: #187342 in bzr "'bzr add --verbose' quietly ignores subdirs with their own .bzr" [Undecided,New] https://launchpad.net/bugs/187342 [16:47] hello [16:49] I want to use a shared repository on a remote server to keep configuration files, but I want a process on this server to use this configuration. [16:49] I planned to make a 'rsync in the after commit hook' but I think there is a better solution [16:50] push-and-update ? [16:50] something like that yes [16:50] it doesn't seems to work over sftp :-/ [16:50] debian sid bzr 1.1~rc1-1 [16:51] ok, push-and-update is a plugin [16:52] asabil: thanks, I'll test this, but I wonder if it can works with merge ? [16:55] nebuchadnezzar: If you're doing merges, you should always do them locally anyhow. [16:55] New bug: #187349 in bzr ""bzr branch" throws MemoryError" [Undecided,New] https://launchpad.net/bugs/187349 [16:56] abentley: ok, thanks [16:58] arf, it need bzr on the remote side, ok [18:41] ehlo [18:41] I get a criss-cross merge [18:41] is even bzr merge --weave ../foobar supposed to tell me "criss cross merge encountered"? [18:42] Yes. [18:42] but I can expect that everything is fine?;) [18:43] If you have no conflicts, you can. [18:43] Criss-cross refers to the context in which you're doing the merge. --weave just changes how you do the merge in that context. [18:44] right, I'll just --weave and criss-cross fingers, then;), thanks [18:45] If you've got a recent Bazaar, --lca is faster and should give better results than --weave. [18:47] abentley: thanks, I'll try [18:47] I did a --lca the other day, and it didn't gave me a conflit where I was expeting one [18:47] expecting [18:47] and well, between the two possibilities, it didn't do the one I wanted [18:47] no, I don't have any conflicts; it's just that I read that I might loose some history [18:49] dato: Okay, if you can send me details I'd appreciate it. [18:49] sure, hang on [18:59] abentley: I mailed you a recipe [19:09] dato: Thanks. I've followed it, but NEWS produces conflicts whether I specify --lca or --merge3. The output is identical. [19:10] abentley: I think I said TODO, not NEWS? [19:10] Oh, my bad. [19:10] ok [19:12] Yes, I confirm the difference in TODO. [19:17] However, I'll point out that --weave has the same problem as --lca for cases like this. [19:18] So I still think --lca is better that --weave, it's just not better than merge3 for this case. [19:18] oh, indeed. I couldn've sweared I got a conflict with --weave. [19:18] but you're right [19:19] could've [19:19] I'll see what I can do to ensure conflicts in this case. [19:19] ok, thanks for taking a look [19:20] Thanks for the report. [20:11] moin [20:13] hi lifeless. [20:13] safely back? [20:13] yup [20:18] Safe for who? (ducks) [20:19] :- [21:06] lifeless: ping [21:06] jam: hi [21:06] hi james_w [21:07] jam: I got 550 Administrative prohibition when sending to your email account, did I do something to offend your mail server? [21:07] hmm. I haven't seen Administrative prohibition, I've do have a greylist that asks people to try sending again after a while [21:08] you might just try re-sending your email [21:09] which is usually enough to get past the greylist [21:10] Greylist certainly shouldn't 5xx, though. [21:10] jam: I assume you will get it via the list, so it's no loss. [21:11] I admit to not being a mail guru, but I'm thinking it was giving 4xx [21:11] james_w: well, I have no-dupes turned on, so I may not [21:12] Hate that option. Hate mailing lists that set it by default. [21:12] jam: looking in my logs it seems I also got a 450 Client host rejected: cannot find your hostname, [89.145.97.141] [21:13] why is a reverse dns failure a motive to reject a host ? [21:13] fullermd: it works very well for me [21:13] It's not rejected, it's deferred. [21:13] fullermd: it might be rejected [21:14] I get a lot of spam [21:14] ('course, presumably the sending host will stop trying eventually) [21:14] The grey-list should be asking them to resend later [21:14] but if I can't do a reverse lookup [21:14] it may consider you suspect [21:14] It's still 4xx'ing. It won't get as far as the greylist checking then. [21:14] # Reject sender hostname without DNS A or MX record, permit sasl users, [21:14] # permit $mynetworks, check for permit/reject in /etc/postfix/access. [21:14] # [21:14] smtpd_sender_restrictions = reject_unknown_sender_domain, [21:14] You wouldn't want to 5xx a PTR lookup failure, since that can be transient. [21:15] permit_sasl_authenticated, hash:/etc/postfix/access [21:15] I find it easier to have all my restrictions in _recipient_restrictions; that way I can avoid repeated lookups, and have the precedences all the way I want 'em. [21:15] jam: pong [21:15] (of course, it's also 28 lines long, which may seem excessive...) [21:16] jam: ah, it's a different host that sends the 550 [21:16] m3thos: spammers [21:16] But anyway, that error james_w pasted is from reject_unknown_hostname, not a sender call. [21:16] lifeless: I wanted to pick your brain a bit about bug #187169 [21:16] Launchpad bug 187169 in bzr "Partial commit with mv and rm under breaks dirstate" [Critical,In progress] https://launchpad.net/bugs/187169 [21:16] sure [21:17] it hits your secondary MX for the retry, and get's the 550. [21:17] So the first issue is that we have a rename and a file underneath that directory is deleted [21:17] I checked with the old "knit" format [21:17] and under that condition [21:17] we would get a renamed foo => bar to be committed [21:17] but the delete would still be pending [21:18] bleep [21:18] I think it is arguable which should happen (since the user script deletes it *after* the rename), but we can preserve either behavior [21:19] So the failure of "update_basis_by_delta" is that it expects you wouldn't be renaming a file to a "deleted" target [21:19] it sounds like we are creating an invalid delta? [21:19] * fullermd would absolutely expect the delete to be committed, FWIW. [21:19] lifeless: well, the old code would have created a new record which is marked as already deleted [21:19] (short of a commit --no-recurse or some such option) [21:20] fullermd: there is a small problem in detecting that it happened, but I do understand your point [21:20] I wouldn't expect the order of operations to matter, just the state when you 'commit'. [21:21] fullermd: interesting topic, but orthogonal [21:21] fullermd: sure, it is more that when you delete the file after the rename, the way it is stored makes it a little bit trickier to tell that it should be affected by the partial commit [21:21] fullermd: perhaps we can focus on the bug-in-hand [21:21] lifeless: anyway, the update_basis_by_delta code assumes that the target won't be marked "absent" [21:21] jam: so we have /deleted-path (A, F) [21:22] and we issue a rename in the delta ? /deleted-path -> /renamed-deleted-path [21:22] but rather than getting (A, R(/deleted-path)) [21:23] it borks [21:23] with "invalid ..." [21:23] and then stops processing the delta [21:23] which borks future operations because the rename was only partially applied [21:24] ok [21:24] so lets do two things here [21:24] lets make this transactional [21:24] is bzr-svn able to handle https repos ? [21:24] like google code ? [21:24] mark the dirstate as in-memory-fucked, and refuse to write it out [21:24] asabil: yes [21:24] hmmm then what is wrong : [21:24] asabil: I *think* you have to connect to it with the raw svn client first [21:25] so that it can save the credentials [21:25] Unable to handle http code 401: expected 200 or 404 for full response. [21:25] and then use "svn+https://" [21:25] asabil: thats in the faq I believe [21:25] oh ok thanks [21:25] This may or may not be related to bug 187207, too. The trigger and symtoms are a bit different (not partial, second commit succeeds, stat doesn't fail), but it's a similar dirstate errror. [21:25] Launchpad bug 187207 in bzr "commit reports error when a file has been moved and then removed in the same revision" [Undecided,New] https://launchpad.net/bugs/187207 [21:25] so https is basically "half" supported [21:26] asabil: AFAIK it is a problem with the SVN bindings not exporting the right stuff so that we can handle authentication prompts [21:26] okidoki [21:26] which I think might be fixed in newer python-subversion bindings, which means it is also fixed in newer bzr-svn [21:27] but I'm going from hazy memory of conversations with jelmer [21:27] should work with all versions of python-subversion [21:27] jelmer: I thought you couldn't authenticate to svn+https [21:27] but you may have to prefix the url with "svn+" otherwise bzr-svn never sees the connection [21:27] jam: You can, if you let svn do it for you [21:27] using svn+? [21:27] or you have to connect using svn one time and save the auth [21:27] jam: or with python-subversion 1.5 bzr-svn can prompt you [21:28] jelmer: that is what I thought, which is what I was trying to get across [21:28] jam: sorry, I just read the line that said "jelmer" because that's the bit xchat highlighted [21:28] lifeless: so, back to our thread.... I agree about marking the dirstate as IN_MEMORY_BROKEN [21:32] how would you handle renaming an absent record? [21:32] At first I thought about just skipping the error check [21:32] but it seems to complain later on, too [21:33] so the record is not included in the delta [21:33] erm rephrase [21:33] a delta that has a rename with a child that is absent [21:33] (the first error is when it goes to process the delete side of the rename, it expects the file to have existed, the second error is when it goes to add the record, it expects the target path to already exist) [21:33] [/foo->/bar], and /foo/quux is marked absent [21:33] is that the situation ^ ? [21:34] lifeless: correct [21:34] so expanded we get [/foo/quux, /foo, /bar, /bar/quux] as the order of paths we touch [21:34] or thereabouts [21:35] hmm, so the question is 'is it valid to rename a deleted file' [21:35] if we say 'no' then we have to fix commit to spider out file ids properly [21:36] rather than the current broken code [21:36] this is quite easily actually, with dirstate [21:36] and I think that failing to commit the delete is definately a bug [21:37] I'm curious if there would be another way to trigger this [21:37] such that update_basis_by_delta should really handle it [21:37] but otherwise I agree with you [21:37] I think foxing the corruption is sufficient for now - if another case turns up we'll get a bug report :) [21:38] lifeless: fwiw, I think it should valid to rename a deleted file. TreeTransform is explicitly designed to support that. [21:38] abentley: in terms of historical trees though, this shows up as a rename and no delete [21:39] I would hope it would show up the same way as the reverse order would. [21:39]