[00:46] jml, interesting: i just did bzr push --remember -Dhpss --stacked bzr+ssh://bazaar.launchpad.net/~bzr/bzr/brisbane-core [00:46] and it made it stacked on the public location of the parent branch, not on lp:bzr as i expected [00:48] poolie1: right. so what I normally do, as advertised on the Launchpad blog, is just bzr push lp:~bzr/bzr/brisbane-core [00:48] poolie1: bazaar's default stacking policy feature takes care of the rest [00:49] poolie1: use --stacked essentially overrides our stacking policy [00:49] s/use/using/ [00:53] interesting [00:53] and bzr now defaults to stacked [00:55] poolie1: only if there's a stacking policy on the other end. [00:55] poolie1: which there is in this case [00:56] that may not be so great til bug 288751 is ixed [00:56] Launchpad bug 288751 in bzr "bzr push returns error Revision not in " [Critical,Triaged] https://launchpad.net/bugs/288751 [01:00] poolie1: then bug 288751 needs to be fixed. [01:00] Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision not in " [Critical,Triaged] https://launchpad.net/bugs/288751 [01:01] indeed [01:01] aaron sent what seemed like a reasonable plan === poolie1 is now known as poolie [01:13] poolie: I'm not actually sure how to tackle 288751. I'm somewhat against disabling the current behaviour, because I suspect there are hundreds or thousands of afflicted branches. [01:15] Hi all! Anyone interested in 'bzr upgrade' failures? [01:16] poolie: I'd rather bless the current behavior. A subsequent format could be stricter. [01:16] rusty, yes [01:16] poolie: A groupcompress format would be stricter anyhow. [01:16] bzr: ERROR: Revision {[('_info.30342-20080814081531-zlq95k6nqflx7n8y-1', 'dinesh@dinesh-laptop-20080814081712-cckpecc9m4vao31v')]} not present in "". [01:17] poolie: 1.6.1 from my upgrade yesterday to 8.10. [01:17] poolie: what do you need? [01:17] rusty: i suspect this is bug 288751 we're just talking about [01:17] Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision not in " [Critical,Triaged] https://launchpad.net/bugs/288751 [01:18] it'd be useful if you add the 'bzr info' results on that to that bug [01:18] Domo aragato, ubottu. [01:19] abentley: do you want to talk here or on mail? [01:19] so the main question is just what server-side autopack should do [01:19] poolie: No, it's larger. [01:20] poolie: The main question is "should we permit text deltas across stacked repositories"? [01:20] so i basically agree with robert that we should not be generating them [01:20] s/basically// [01:20] poolie: bzr info? After failure or before? Output not interesting. [01:20] poolie: There's no server-side autopack involved here. [01:21] does it say it's stacked on something? [01:21] poolie: no... [01:22] poolie: Fine, but we've already generated many stacked branches. They are probably afflicted. How should we deal with them? [01:24] AFAICT, robert wants bzr to fail if it encounters them. I am more inclined to keep existing branches working. [01:26] poolie: It's a very vanilla tree I think. And just not that complicated. [01:26] rusty: i would suggest that you make a backup, run bzr reconcile, bzr check, bzr upgrade [01:27] if that does not fix the problem, file a bug, and if the code is public attach a tarball of it [01:27] poolie: OK, I'll try that now. [01:27] poolie: yes, good news is this is all public. [01:27] insert before those instructions, move backup.bzr back in place [01:28] poolie: woot! I blew up reconcile! Do I get a prize?? [01:28] yes :/ [01:29] abentley: so perhaps we could do a query on lp for branches that are stacked, and then look at if they have text deltas across repositories [01:29] I will report a bug and attach the 4MB tarball of the whole repo. [01:29] thanks [01:29] for reporting it, and sorry for the incovenience [01:29] poolie: heh, I've filed 6 KDE4 bugs in the last 12 hours... this is nothing :) [01:30] poolie: how would that influence the decision? [01:30] heh [01:31] also, we don't record all instances of stacked branches, only branches stacked on other branches also in/mirrored on Launchpad. [01:32] jml: because of the bzr+ssh bug, no one would want to stack their launchpad branches on something else. [01:32] abentley: that's comforting. [01:32] why do I get this with any bzr command? http://paste.ubuntu.com/70759/ [01:32] so if it's only happened on the particular branches were lp recommends stacking, then it's more reasonable to do a one-off fix [01:33] ryanakca: because the gtk plugin (or something related) is assuming you have a desktop running [01:33] but i would guess you're running it from a text or ssh session or similar [01:33] i think this was fixed in a later release [01:34] https://bugs.edge.launchpad.net/bzr-dbus/+bug/199513 [01:34] Launchpad bug 199513 in bzr-gtk "gcommit crashes: ERROR: dbus.exceptions.DBusException" [Low,Fix released] [01:35] poolie: could it be qctBzrPlugin? Its the only one without a description... the rest: http://paste.ubuntu.com/70761/ [01:36] poolie: so, I don't see the # of affected branches as being a factor. [01:37] poolie: either you break them and provide a script (or whatever) to fix them, or you accommodate them and fix the underlying issue in a new format. [01:38] poolie: OK, filed bug 297024. That should keep you off the streets for a bit longer :) [01:38] Launchpad bug 297024 in bzr "bzr reconcile crashes" [Undecided,New] https://launchpad.net/bugs/297024 [01:38] poolie: nevermind, thats what it is... [01:41] jml, that's basically true - if it turned out to be just one or two it would be more reasonable to say 'just remirror them' [01:41] poolie: or what I thought it was. Still there. What can I do? If I go --no-plugins, it disables the svn plugin as well... but I need the svn plugin to checkout / svn->bzr... [01:42] ryanakca: can you upgrade? [01:42] or otherwise remove the gtk or qt plugin [01:43] poolie: I seriously doubt it's 1 or 2 [01:44] poolie: I can't see any of them installed... I removed qct, which is a qt one... but, I still get it... all of my plugins are in the above paste. [01:44] poolie: when spm gets back, he can tell us which branches are stacked. I'll need more bzr expertise to get a test for the other bit. [01:44] ryanakca: reckon the 'dbus' one might have anything to do with it? ;-) [02:08] jml: You should be able to repurpose Packer._check_references to do that. [02:09] abentley: or james-w's script === mw is now known as mw|out [02:13] lifeless: I didn't see that one. [02:20] abentley: its attached to one of the bugs [02:26] abentley: everything about that except the pronoun sounded great :) [02:27] jml: Y'all should be able to repurpose Packer._check_references to do that? [02:27] abentley: "one should be able to..." [02:28] poolie: fwiw, we're looking at 300+ stacked branches on LP [02:57] well, the list of branch ids is at https://pastebin.canonical.com/11067/. Let me know if you need a hand writing the script :) [03:02] Why aren't new branches I push group writable? Am I missing some umask for bzr? [03:03] awmcclain: are you using sftp? [03:04] bzr+ssh [03:05] awmcclain: There's no bzr-specific umask. What does "ssh $HOSTNAME umask" report? [03:07] 0022 [03:07] awmcclain: So your remote host umask is set to disable group write. [03:08] Ah. I figured it was a system configuration. I'll go look up ssh and umask. === sdboyer|class is now known as sdboyer [03:38] what's the easiest way to create a central branch and commit data to it? the user-guide isn't very clear on it === arjenAU2 is now known as arjenAU [04:09] Wait...can anyone log into pastebin.canonical.com? [04:11] Peng_: anyone can authenticate [04:11] Oh. [04:11] adeel: once you have your code locallly; bzr push CENTRAL BRANCH [04:12] adeel: then 'bzr bind CENTRAL_BRANCH' to make that into a checkout, and other people can do 'bzr checkout CENTRAL_BRANCH' [04:12] lifeless, so does that work if the central repo is local to my system? that is, i want the repo to be stored at /foo, but right now, the contents of the files are at /bar [04:13] You're right, I can /authenticate/. I just don't have permission to access anything. ;P [04:15] for some reason bzr builddeb is not following its .bzr-builddeb/local.conf [04:15] adeel: yes [04:16] lifeless, interesting...thanks for the info...and btw, if you know who maintains the user's guide on the bzr website, they might need to update/clarify it [04:17] adeel: file a bug with whats unclear please [04:19] lifeless, sure [04:20] also, what transports are enabled by default for bzr? sftp? http? ssh? etc [04:20] everything that the libraries for are on your system [04:20] there a way to find out which ones are? [04:20] the deb packages depend on enough to have ftp/http(but not webdav)/ssh/bzr/filesystem/sftp work [04:21] adeel: bzr help urlspec [04:21] ah, i'm on gentoo, so the deb packages don't help =cp [04:21] thanks for the tip [04:57] lifeless: what i'm saying is [04:57] if you push to lp/bzr, you may also hit the stacking issue [04:57] oh sure [04:57] but I have ways and means for that "{ [04:57] :P [05:01] poolie: can you do me a favour [05:01] poolie: push to lp:~bzr/bzr/brisbane-core, the branch you have? [05:01] it won't stack [05:06] it's runnig [05:21] http://paste.ubuntu.com/70801/ === jamesh_ is now known as jamesh [06:14] igc: /srv/conversions/manganese on tungsten [06:14] igc: 136Gb, knock yourself out === timchen1` is now known as nasloc__ [06:14] You can't mix manganese and tungsten! [06:15] fullermd: not mixing. layering [06:15] Stacking? ;) [07:09] lifeless: Do you know why pqm would treat bzr+ssh://bazaar.launchpad.net/%7Eabentley/bzr/1.9-launchpad/ as a Baz1 branch? [07:11] abentley: it tends to treat anything it doesn't understand as a Baz1 branch [07:12] i would guess that you've hit 288751 and therefore lp is not republishing it over bzr+ssh [07:12] oh [07:12] in fact, that's the simpler answer, it probably just can't ssh to launchpad [07:12] you need an http url [07:12] poolie: I merged something via SSH yesterday evening. [07:13] poolie: We use PQM with the launchpad codebase and that's confidential, so we use SSH for it. [07:13] ok [07:13] nevermind that then, though i thought it used to fail [07:15] abentley: because it's not a branch? https://code.edge.launchpad.net/~abentley/bzr/1.9-launchpad/ [07:15] i can't access it over ssh eithre [07:16] Random guess: you uploaded in 1.9 format, but Launchpad doesn't understand 1.9 yet. [07:17] spiv: bzr info reports "Standalone branch (format: 1.6)" [07:19] abentley: so then i'd come back to my statement that it's affected by 288751 [07:19] Random and wrong guess :) [07:20] poolie: [07:20] # Performance with commit was profiled extensively, and it found that [07:20] i pasted a reproduction sample to that bug btw [07:20] # using the keys of the Inventory._byid was faster at the time. We [07:20] # want to move away from doing this, but until careful profiling [07:20] # is done, we're preserving the old behaviour. [07:20] # [07:20] abentley: if it can't access the branch it will fall back to considering it a baz branch, which is not as probable [07:21] i'd say "using the keys ... (rather than eg building a set from the key iterator)" [07:21] i think you need to be a bit specific [07:21] otherwise it's like the billboards in qld saying "motorcyclists beware" [07:21] beware what, bats? [07:22] i was also thinking that it might have been better to do a getattr() rather than isinstance [07:22] it's more to the point of what we're trying to switch on [07:22] poolie: That only happens on autopack, but perhaps the mirroring process is autopacking. That would be #280595 actually. [07:23] i posted a reproduction example [07:23] it may be on the wrong bug strictly speaking [07:23] lifeless: So it looks like the failure is because of a problem mirroring it. [07:23] * abentley sells all his computers and buys a spaghetti farm. [07:29] * fullermd will show his support by buying bulk spaghetti. [07:41] night all [08:20] abentley: i have some ideas on 288751, nothing really conclusive yet [08:20] there is a check Packer._check_references that's meant to stop this but does not [08:21] (Pdb) self.source.get_inventory('sp1r-monty@donna.mysql.com-20000829163832-06287')['sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4'] [08:21] InventoryFile('sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4', 'bk.txt', parent_id='sp1d-docs-ncsbsqrhxzflos6d2mrwgql4b7a7gacv', sha1='b5a47ca433f25aac932844515415ef43209ae017', len=3087, revision=sp1r-monty@donna.mysql.com-20000829163832-06287) [08:21] (Pdb) self.target.get_inventory('sp1r-monty@donna.mysql.com-20000829163832-06287')['sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4'] [08:21] *** KeyError: 'sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4' [09:47] seems to be scaling well: [09:47] Commits: 1665 [09:47] Raw % Compressed % Objects [09:47] Revisions: 6202 KiB 0% 1921 KiB 5% 1665 [09:47] Inventories: 27210 KiB 1% 14446 KiB 43% 29953 [09:47] Texts: 1520391 KiB 97% 16477 KiB 50% 11401 [09:48] Signatures: 0 KiB 0% 0 KiB 0% 0 [09:48] Total: 1553804 KiB 100% 32844 KiB 100% 43019 [09:53] looks promising [09:53] the compressed size inventories are still just 'gzip' rather than deltas [09:54] which is why it is ~50% smaller and thats all ;) [09:55] Do you have a feel for how much difference there is to be made there? 'nother factor or 2, or 10? [09:55] well [09:55] we write ~20 nodes per commit [09:56] of those, I guess its one leaf per changed inventory entry at worst [09:56] and a leaf is quite compressible - its 4K of line orientated binary [09:56] foo\x00bar\nquux\x00gam\n [09:58] so, if we change say 200 bytes per 4K page, thats say 300 bytes with headers as a delta, or 150/200 as a gzip delta [09:58] down from 2K [09:58] so yeah, 5% of repo size compressed would be worth aiming for [09:59] Awesome. [09:59] (seeing the inventories compress to just barely smaller than the texts offended my intuition of what relative magnitudes should be. Made me wonder if my intuition was completely cracked.) [10:03] seeing it at 96% offended me [10:04] Well, inventories are important; why shouldn't they get plenty of bytes! [10:05] hi all [10:05] hey asabil [10:07] did anyone write a plugin to submit merge requests directly to bundle buggy ? [10:11] asabil: how do you mean? Afaik bundle buggy only accepts merge requests via the mailing list [10:12] I would like to make my team mate use bundlebuggy [10:12] Well, one could setup BB with a direct mail address, and just make send default to that address. [10:12] but getting them to use a mailing list, and setting their mails would be a big hassle [10:12] I don't remember if there's already support for setting a default send address or not; that make take a little plugin-fu. [10:13] yeah, you can set a default send address [10:13] child_submit_to = [10:13] asabil: they can use `bzr send` [10:13] I am thinking about exposing some rpc over http, and add a bzr command to directly submit a merge request [10:14] yes, but they need to setup a mail program I guess ? [10:14] I thought send could just spawn off an editor and `sendmail`-submit it itself. [10:15] (of course, that assumes the rest of the system is properly setup for mailing, which I always assume but may not be valid in your neighborhood) [10:15] I don't think that's the case unfortunately [10:15] it can also use smtplib iirc, useful for hosts without an mta [10:17] so basically I would just setup bundle buggy, and create an email address for it [10:17] and then configure bzr send to use smtplib ? [10:17] Yah. [AFAIK] it just gets email; seems to usually be done by subscribing it to a ML, but could just as easily be mail sent right at it. [10:19] asabil: yah [10:19] asabil: I'm sure more can be done, but thats the current state-of-play [10:19] okidoki, thanks a lot [10:20] one last question, how do I configure bzr send to use smtplib ? === jszakmeister|awa is now known as jszakmeister [10:22] jelmer: Thanks for taking care of that corruption bug. [10:23] Looks like there's one more with the branch nick stuff... but it sounded like 1.9.1 was going to have a fix for that. [10:23] jszakmeister: yep [10:24] asabil: its in the configuration help === doko_ is now known as doko [10:25] bzr help send | grep smtp gives nothing [10:25] ERROR: Your shelved patch no longer applies cleanly to the working tree! [10:25] now what ? [10:25] I shelved changes in a brach because I selectively patched trunk with some of the changed [10:25] then merged the updated trunk into the branch again [10:25] and now was willing to unshelv, expecting the already-found patches to become non-changes [10:25] but I get that error above... [10:26] strk: that version of shelf works with simple patch(1) behavour [10:26] strk: just supply --force [10:27] bzr's next release has a better shelve that should do what you were expecting [10:28] ok, --force did it, produced some .rej but I'm fine with them, seem to be the patches I didn't want to apply anymore cause already applied in trunk [10:28] how to clean the shelf now ? [10:28] bzr shelf list [10:28] bzr shelf delete (thing to delete) [10:28] great, thanks [10:31] asabil: bzr help configuration [10:34] thanks === strk is now known as strk_away [13:11] any here use cmd-line bzr with emacs? trying to get sensible status info to show up but it seems to be killing emacs === mw|out is now known as mw [13:42] asabil: In terms of receiving patches, bundle buggy just scans a directory containing messages. Whether it's personal mail or from a mailing list shouldn't matter. [13:44] asabil: bzr help send describes the "editor" mail client, which uses smtplib. [13:47] okidoki, thanks for the input abentley === strk_away is now known as strk [14:06] how can I compare two branches ? [14:07] the ideal outpu for me would be the same you'd get with 'status' (a summary of diffs) and the possibility to know more about something [14:11] strk: Try using "-r branch:". [14:11] to status ? [14:12] bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction on KnitPackRepository('file:///home/src/gnash/avm2/.bzr/repository/') [14:12] write ?! it was bzr status -r branch:../bzr/trunk/ [14:13] strk: That sounds wrong. What's in ~/.bzr.log? [14:13] that should be fixed in recent bzr [14:13] That's a long-standing bug. [14:14] Ah, OK, I'd never seen it before. [14:14] 1.8 probably [14:15] this is Bazaar (bzr) 1.3.1 [14:15] https://bugs.launchpad.net/bzr/+bug/144421 [14:15] Launchpad bug 144421 in bzr "Using branch: revspec in stat blows up" [Undecided,Fix released] [14:30] uhm... diff branchA/file1 branchB/file1 # no diffs [14:30] branchA$ merge ../branchB # nothing to do [14:31] branchB$ merge ../branchA # conflicts in file1 [14:31] any idea ? [14:31] seem the real difference in the conflict marker is just the amount of spaces used for indentation [14:32] questions are: 1) why 'diff' doesn't care ? 2) why merge in the two directions is different in catching that ? [14:33] uhm, on a closer look, there's really NO difference in the two files, so diff(1) is right [14:33] why does merge gets that conflict then ? [14:37] Hmm, I seem to have accidentally Planet Bazaar. [14:37] The whole planet. [14:37] "This sentence no verb" [14:38] (http://img165.imageshack.us/img165/189/1218062796760xd1.jpg) [14:40] uhm [14:40] riiiiiight [14:41] lol [14:42] Odd_Bloke: I'm laughing as a kid [14:42] silly stuff [15:01] Odd_Bloke, LOL [15:14] jelmer: hey... when i do a push of a revision back to a svn branch to a repo with 75k revs it does the "determining revisions" dance like 3 times ... each time it takes about 4sec or so [15:19] <_tsatbic_> Hi there ... [15:20] <_tsatbic_> I've got a type in a commit's message, is it possible to rename the message even after several other commits have been made? [15:20] _tsatbic_, no, commits are immutabl [15:21] <_tsatbic_> thanks === kiko__ is now known as kiko === kiko is now known as kiko-fud [16:18] Hello. Does anyone happen to have a buildbot hook for bzr (i.e., one that pings a buildbot master when a change is commited) that they would be willing to share? Neither Google nor buildbot.net seem to show such a beast. [16:19] gary_poster: Hi [16:19] hi jelmer [16:20] Afaik there isn't anything like that yet [16:20] jelmer: ok thanks. here I go then, I guess ;-) === sdboyer is now known as sdboyer|soup === kiko-fud is now known as kiko === strk is now known as strk_away [19:08] is there anyway to get bzr to show me the relative paths of files when doing bzr st instead of the full path? [19:09] (a la git) [19:20] abentley, is a revid usually just -- ? [19:21] rockstar, I think there's a sha1 hash in there somehow [19:21] something related to the actual contents of the revid [19:21] rockstar: Yes, the revids bzr itself generates are that. [19:21] but that may be somewhere else === sdboyer|soup is now known as sdboyer [19:21] beuno: There is nothing related to the actual contents of the committed tree in the revid. [19:21] beuno: You may be thinking of revision testaments, which are used with GPG signing. [19:22] abentley, great. That makes my job so much easier. [19:22] abentley, I'm actually thinking of a hash that makes sure that the revision hasn't been changed [19:22] * rockstar prefers that Old Testaments. No GPG sig, but lots of funny stories. [19:23] rockstar: importers like bzr-svn often do not follow bzr's practice. The only requirement is that they be random. === mw is now known as mw|food [19:23] beuno: That's what testaments are for. There's also a SHA hash in the revision XML. [19:23] but it's a bad idea, and not reliable. [19:24] abentley, the sha is what I was thinking of [19:24] why is it not reliable? [19:24] because of upgrades and such? [19:25] Yes, format upgrades will update the inventory XML without necessarily updating the SHA1. [19:25] gotcha, thanks for the explanation\ [19:26] beuno: Or at least that was the case. It should be fixed in recent bzrs, but old revisions won't be fixed. [19:32] lifeless: ping === sabdfl1 is now known as sabdfl === strk_away is now known as strk [19:51] abentley: just waking up [19:51] abentley: what can I do for you? [19:52] lifeless: What causes PQM to die on "not enough arguments for format string"? [19:52] I think thats a new one [19:55] lifeless: I'm not sure if you're aware, but bzr 1.9 has API changes that are incompatible with loom trunk. Launchpad wants to use bzr 1.9. So I'm trying to land lp:~abentley/bzr-loom/stuff on bzr+ssh://bazaar.launchpad.net/~Elaunchpad-pqm/bzr-loom/trunk [19:56] lifeless: But it died with the aforementioned error. [19:56] lifeless: A silent failure, not an email failure. [19:57] How do I get the config of a branch, if I have a setting for a branch in my bazaar.conf [19:58] rockstar: you mean something like Branch.open(url).get_config() ? [19:58] jelmer, does that return a bzrlib.config.Config object? [19:59] It returns a BranchConfig object, but that's based on a Config object IIUC [19:59] I thought I wanted BzrDirConfig, but BranchConfig looks better. [19:59] BranchConfig reads from .bzr/branch/branch.conf, locations.conf and bazaar.conf (not sure in what order) [20:01] File "/home/pqm/pqm/pqm/__init__.py", line 534, in do_merge [20:01] self.log_with_status(logger, merge_line) [20:01] File "/home/pqm/pqm/pqm/__init__.py", line 428, in log_with_status [20:01] self.branch_spec_handler.status.line(message % args) [20:01] TypeError: not enough arguments for format string [20:01] abentley: its a bug; let me have brekkie and I'll try to track it down [20:04] lifeless: thank you. === mw|food is now known as mw [20:33] :sigh: loggerhead has almost no documentation :| [20:33] it has source! [20:33] python is very readable, that is how I got lh running :) [20:33] I know, I know. [20:33] But I always look for the easy way out. [20:34] *easy way out first :p [20:34] Seems odd that they are pushing to move to serve-branches [20:34] Hmm, is there not an option to create a branch w/o a working copy? [20:34] It seems a lot less flexible than the config file. [20:34] NfNit|oop: bzr branch lp:foo bar [20:34] or you mean create a branch on the server? [20:35] a branch without a checkout. [20:35] it's ok, I'll just branch then remove-tree [20:42] NfNit|oop: if you have repository created with --no-trees, the branch is created without tree [20:43] bah, I can't make heads or tails of how to use --user-dirs with an Apache proxy [20:44] verterok: right, I'm in a shared repo, but I've got trees for some branches, and wanted to create a branch as a sortof temporary tag to compare against some other revision. Didn't really need to create a working tree for it. [20:45] NfNit|oop: I don't think they can be mixed :/ [20:45] NfNit|oop: you can compare against remote branches [20:46] verterok: Well, I just did `bzr remove-tree`... so I hope they can be mixed. :p [20:46] luks: Yeah, but that's slower than doing it locally. :p [20:46] NfNit|oop: sure, but you must do a remove-tree :) [20:47] verterok: mkay, that's fine. :) I was just surprised at its absence. [20:47] NfNit|oop: indeed [20:54] NfNit|oop: If you really want to, you can create the branch over bzr+ssh (or sftp, ftp whatever your workstation has running). Branches created over remote protocols don't get working trees. [21:05] jfroy|work: its less flexible in some ways, but its a lot easier for most folk to deploy [21:05] jfroy|work: the user-dirs thing is instead of using apaches' userdir mapping facility-> if you want host/~foo to be served by loggerhead [21:06] verterok: they should be mxable [21:06] Hi, I'm having problems with the initial brnach setup of Bazaar. Any bored volunteers? [21:06] er branch [21:06] BrentH: sure, whats up [21:06] well, I'll give you the mini-background. [21:07] I've setup a project on Launchpad, and put ateam on the project...the problem is getting the initial code onto Launchpad [21:08] BrentH: what vcs is it in at the moment? [21:08] I'm an IT person, but Bazaar and Launchpad have made me feel really dumb. lol [21:08] it's not - brand new. [21:08] assume that its at /src/foo [21:08] cd /src/foo [21:08] bzr init [21:08] bzr add [21:08] bzr commit [21:09] bzr push lp:~$TEAM/$PROJECT/trunk [21:09] I should clarify - it didn't exist before...right now the initial code is only two files. The code is on a Win installation of Bazaar. [21:09] when I push it, I'm getting "error not a branch" [21:09] BrentH: have you run the commands I listed above? [21:09] yes. all were successful until the push [21:10] are you running push from within the directory? [21:10] lifeless: yes, it's just I expressed it wrong (choosed poorly my words), what I meant was that a share repo can't create branches without tree if it's not a --no-trees repo. [21:10] abentley: I see the issue with pqm I think; the branch has % in it [21:11] ok, 1st problem solved...maybe [21:11] here's the thing... [21:12] I desire a directory under foo called new. So foo/new... [21:12] lifeless: Heh. [21:12] File "/home/pqm/pqm/pqm/__init__.py", line 787, in run [21:12] line='merge %s %s' % (self.from_branch, self.to_branch)) [21:12] File "/home/pqm/pqm/pqm/__init__.py", line 534, in do_merge [21:12] self.log_with_status(logger, merge_line) [21:12] File "/home/pqm/pqm/pqm/__init__.py", line 428, in log_with_status [21:12] self.branch_spec_handler.status.line(message % args) [21:12] does it make a difference where I eventually deploy it? (I want to deploy to a virtual website dir) [21:13] BrentH: 'mkdir new' [21:13] BrentH: 'bzr add' [21:13] BrentH: 'bzr commit' [21:13] lifeless: Looks like some pretty intentional string interpolation to me ;-) [21:13]