| mlh | pattern: you're not alone in avoiding cvs; I preferred rcs to cvs | 00:00 |
|---|---|---|
| mlh | for my simple needs | 00:00 |
| pattern | i just asked on #cvs about tools to convert RCS to CVS | 00:01 |
| pattern | <pattern> are there any tools that i could use to migrate my RCS project to CVS ? | 00:01 |
| pattern | <lynx> none needed | 00:01 |
| pattern | <lynx> cvs uses rcs format for storage | 00:01 |
| pattern | lynx> just do a 'cvs init' to create a repository, then move the ,v files in there | 00:01 |
| mlh | yep | 00:01 |
| pattern | well, that's simple enough :) | 00:02 |
| mlh | I've heard it's even simpler than that | 00:09 |
| === mw is now known as mw|out | ||
| hendrixski | hey, my friend and I are tinkering with bzr... and we both downloaded a branch from an FTP thing... and we want to merge each others stuff between our computers without having to upload to a server. Is that possible? | 00:17 |
| bialix | yes, you can use merge via emails | 00:17 |
| hendrixski | bialix, merge via email? that's awesome is there a manual you can point me about that? | 00:17 |
| bialix | look at 'send' command | 00:17 |
| mlh | bialix: your bzr win 0.92 is 'not found' -- there is a exe.part | 00:18 |
| Odd_Bloke | hendrixski: Or you could look at 'bzr serve', if you're on the same network. | 00:18 |
| mlh | oh never mind, you were uploading. I was too quick | 00:18 |
| hendrixski | wow | 00:18 |
| ddaa | I think there's even a plugin somewhere for zeroconf discovery | 00:20 |
| * hendrixski doesn't see send in the man page | 00:21 | |
| ddaa | bzr help send | 00:21 |
| ddaa | bzr is self-documenting | 00:21 |
| ddaa | the man page is just to make Debian packagers happy ;) | 00:22 |
| mlh | is there a tags command for python? | 00:22 |
| ddaa | etags works fine with python | 00:23 |
| ddaa | ctags probably too | 00:23 |
| bialix | ctags rocks | 00:23 |
| ddaa | pah, vi user ;) | 00:23 |
| mlh | thanks, I didn't match python in the man page, but ctags --list-languages lists it. Sorry for wasting your time :-) | 00:23 |
| bialix | no, FTE | 00:23 |
| mlh | FTE? | 00:23 |
| bialix | yep | 00:24 |
| bialix | fte.sf.net | 00:24 |
| mlh | oh yeah | 00:24 |
| pattern | where can i download cvsps-import ? | 00:27 |
| lifeless | ddaa: bzr-avahi | 00:28 |
| lifeless | pattern: the bzr plugins page has a link I think | 00:28 |
| bialix | lifeless: your patch have landed | 00:28 |
| bialix | night all | 00:28 |
| pattern | the link from the bzr plugins page pointed me to: https://launchpad.net/bzr-cvsps-import | 00:30 |
| lifeless | right | 00:30 |
| pattern | and from there i clicked on "Download project files" | 00:30 |
| lifeless | oh, I don't think John has uploaded a tarball | 00:30 |
| pattern | and it tells me "No download files are linked to this series." | 00:30 |
| lifeless | try the devel link | 00:30 |
| pattern | i don't see one | 00:31 |
| lifeless | timeline - trunk | 00:31 |
| pattern | ah | 00:31 |
| pattern | well hidden :) | 00:31 |
| pattern | that gives me a "Download URL" of http://bazaar.launchpad.net/~bzr/bzr-cvsps-import/trunk | 00:32 |
| pattern | which is a broken link | 00:32 |
| lifeless | see the word 'example' below it ? | 00:32 |
| pattern | ah, yes | 00:32 |
| lifeless | thats a bzr command line to download it | 00:32 |
| pattern | ok, that worked | 00:32 |
| pattern | thanks for holding my hand through this :) | 00:33 |
| lifeless | n | 00:33 |
| lifeless | np | 00:33 |
| pattern | ok.. so, next question... now that i've downloaded the plugin, where do i put it? | 00:34 |
| pattern | should i just copy the entire directory to /usr/lib64/python2.4/site-packages/bzrlib/plugins ? | 00:34 |
| pattern | there are no installation instructions in the README | 00:34 |
| AfC | eeep | 00:37 |
| hendrixski | and... publishing is atomic right? so if two people are publishing (to ftp let's say) it won't confuse both of them? | 00:37 |
| AfC | UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 7: ordinal not in range(128) | 00:37 |
| lifeless | pattern: hmm, I thought we had generic instructions | 00:37 |
| AfC | bzr commit --author 'Emrah Ünal <eunall@gmail.com>' | 00:37 |
| lifeless | pattern: just link ~/.bazaar/plugins/cvsps to the directory you downloaded. | 00:37 |
| ddaa | pattern: btw, "bzr branch https://launchpad.net/bzr-cvsps-import" works too | 00:37 |
| pattern | i just found http://bazaar-vcs.org/UsingPlugins | 00:37 |
| * AfC has been trying all morning to give credit to the guy who wrote the software that I just happen to be sticking into a repository | 00:38 | |
| ddaa | AfC: if that guy has a profile in Launchpad (there are a bunch of automatically created profiles, for packagers or translators) | 00:38 |
| ddaa | you can set the "Author" of the branch | 00:39 |
| poolie | AfC, i think your $LANG must be set to something that uses ascii | 00:39 |
| lifeless | AfC: what bzr version do you have ? | 00:39 |
| lifeless | I have a vague memory of a recent bug in the -- author support | 00:40 |
| ddaa | Here he is https://edge.launchpad.net/~eunall | 00:41 |
| ddaa | he's actually a real lp user :) | 00:41 |
| hunmonk | can anybody tell me the current version of bzr that's in the ubuntu packaging system?? | 00:42 |
| hunmonk | can't seem to find that info | 00:42 |
| poolie | packages.ubuntu.com/bzr | 00:43 |
| lifeless | 0.91 | 00:43 |
| poolie | in hardy; 0.90 in gutsy | 00:43 |
| hunmonk | colossus$~/bzr: bzr --version | 00:44 |
| hunmonk | Bazaar (bzr) 0.17.0 | 00:44 |
| hunmonk | i guess it's safe to say i'm a bit behind?? ;) | 00:44 |
| poolie | try 'apt-cache madison bzr' | 00:44 |
| igc | morning all | 00:45 |
| poolie | hi ian | 00:45 |
| hunmonk | poolie: oh i'm on a mac. i was checking for somebody else who's on ubuntu | 00:45 |
| * hunmonk examines fink... | 00:45 | |
| igc | poolie: can we chat about the --experimental name? I'd like ot change it before 0.92 | 00:45 |
| poolie | me too | 00:45 |
| poolie | i think 'experimental' is more an attribute of formats than a name for them | 00:46 |
| igc | I think knit-pack or something like that is far better | 00:46 |
| poolie | agree | 00:46 |
| Peng | Are packs still to be considered experimental? | 00:46 |
| lifeless | ell | 00:46 |
| lifeless | well | 00:46 |
| AfC | poolie: I just went through the exercise of [re]setting my terminal to take UTF-8 characters. | 00:46 |
| lifeless | they are not a consideration-free improvement | 00:46 |
| lifeless | so I think calling them experimental in 0.92 is fine | 00:46 |
| igc | agreed | 00:46 |
| AfC | and I can compose them into the command line. LANG=en_CA.UTF-8 | 00:47 |
| AfC | lifeless: bzr 0.91 | 00:47 |
| poolie | did you do 'export LANG'? | 00:47 |
| * poolie reads the delete performance patch | 00:47 | |
| hendrixski | do you need to run a bazaar server on your computer if you want to merge across a network? we're having some problems figuring this out? | 00:47 |
| AfC | It's set desktop wide on login by gdm et al | 00:47 |
| igc | lifeless: can we compromise on experimental-pack say? | 00:48 |
| igc | my fear with just plain experimental ... | 00:48 |
| igc | is that it's way too generic | 00:48 |
| igc | and another one called that in 2 years say ... | 00:48 |
| poolie | sure, you might want to use that name for something else in future | 00:48 |
| poolie | spiv, ping? | 00:48 |
| igc | could cause confusion and breakage ... | 00:48 |
| igc | given the name with start to appear in blogs, etc. | 00:49 |
| igc | s/with/will/ | 00:49 |
| hendrixski | to send across a network, do you need a bzr server running on your computer? | 00:49 |
| AfC | Try try again | 00:49 |
| lifeless | igc: yes we can | 00:49 |
| poolie | afc, i'll try it | 00:49 |
| igc | thanks | 00:49 |
| poolie | igc, what are you up to today - would you like to do a patch for format naming? | 00:50 |
| igc | I can | 00:50 |
| poolie | my idea would be something like this | 00:50 |
| poolie | it's accessed by --format knitpack | 00:50 |
| poolie | the help says it's experimental - indeed maybe there's an attribute on the format object that says it's experimental | 00:51 |
| poolie | the format string changes | 00:51 |
| poolie | as a straw man, maybe you should have to say eg | 00:51 |
| poolie | bzr init-repo --format knitpack --enable-experimental | 00:51 |
| poolie | that may be overdoing it | 00:51 |
| poolie | or alternatively maybe it should give a notice when one is created | 00:51 |
| lifeless | poolie: I think thats overdoing it | 00:52 |
| igc | hmm | 00:52 |
| lifeless | poolie: I think that just changing the text and label is sufficient for now | 00:52 |
| lifeless | poolie: a link to the doc.bazaar-vcs.org copy of the pack repo doco in the help for it | 00:52 |
| igc | is the idea of pack-0.92 dead? | 00:52 |
| pattern | do i need to run "bzr init ." and/or "bzr add" before running "bzr cvsps-import" ? | 00:52 |
| poolie | the user-orientted docs | 00:52 |
| lifeless | poolie: yes, based on my how to dogfood mails | 00:53 |
| igc | lifeless: what impact will changing the name have on existing dogfooders? | 00:54 |
| lifeless | igc: zip | 00:54 |
| poolie | pattern, i doubt you need to run add | 00:54 |
| lifeless | igc: change their scripts is all | 00:54 |
| igc | really? it's that clean? | 00:54 |
| poolie | you may need to run init - try without and see if it gives an error | 00:54 |
| lifeless | pattern: bzr help cvsps-import should be useful | 00:54 |
| lifeless | igc: I'm not talking about changing the disk format label, only the user visible label | 00:55 |
| igc | ah | 00:55 |
| lifeless | igc: the disk format is 'Bazaar Experimental no-subtrees\n' | 00:55 |
| poolie | i think we should change the disk format | 00:56 |
| lifeless | if we change that, existing dogfooders need to edit .bzr/repository/format | 00:56 |
| lifeless | but that is quite easy to do. | 00:56 |
| poolie | and today, so that only a few people are disrupted | 00:56 |
| lifeless | sure | 00:56 |
| pattern | lifeless: thanks, but that help says nothing about what other commands i should run | 00:56 |
| igc | poolie, lifeless: so I'm happy to put the patch up re renaming formats | 00:57 |
| lifeless | jam-laptop: perhaps you can spare a minute to help pattern | 00:57 |
| poolie | ok | 00:57 |
| lifeless | jam-laptop: pattern is having some trouble figuring out cvsps-import | 00:57 |
| pattern | i just tried running "bzr cvsps-import /path/to/my/CVSROOT myfile.c output" and got an error | 00:57 |
| poolie | maybe you could also collect robert's notes on how to try them out | 00:57 |
| poolie | it needs to go into some kind of extended release note i think | 00:57 |
| igc | agreed | 00:58 |
| igc | abentley: ping | 00:58 |
| pattern | "Processed 0 patches (0 new, 0 existing) on 0 branches (0 tags) in 0.1s (0.00 patch/s)" | 00:58 |
| pattern | "bzr: ERROR: cvsps did not return successfully. return code: -11 for command cvsps --cvs-direct -A -u -q --root /path/to/my/CVSROOT/myfile.c" | 00:58 |
| abentley | Pong | 00:58 |
| igc | abentley: any further thoughts re 'merge directive' to 'merge recipe'? | 00:59 |
| igc | I'd like to do it | 00:59 |
| pattern | maybe this is because i just imported my RCS project to CVS by runing "cvs init" and copying "myfile.c,v" from my RCS repository in to my CVSROOT | 00:59 |
| igc | as a doc change as least | 00:59 |
| lifeless | pattern: bzr doesn't version single files, only full trees. | 01:00 |
| pattern | ah | 01:00 |
| lifeless | pattern: try 'bzr cvsps-import . output' | 01:00 |
| pattern | ok | 01:00 |
| abentley | igc: It's my favourite out of the things we discussed. | 01:00 |
| igc | it's good I think ... | 01:00 |
| lifeless | pattern: also, you need cvsps installed | 01:00 |
| abentley | I wouldn't change the default format marker. | 01:00 |
| igc | like a normnal recipe, the 'diff' is a picture of the end result. :-) | 01:00 |
| pattern | cool, that seems to have worked | 01:00 |
| pattern | yeah, i installed cvsps | 01:01 |
| igc | abentley: agreed | 01:01 |
| lifeless | abentley: default format marker ? | 01:01 |
| igc | just the external name as the plan | 01:01 |
| igc | s/as/was/ | 01:01 |
| abentley | lifeless: The format marker used for merge directives. | 01:01 |
| pattern | ok, now that i've seemed to have successfully imported my old RCS project, on to actually learning bazaar! | 01:01 |
| pattern | thanks everyone! | 01:01 |
| abentley | I wouldn't change it to use the string "merge recipe" instead. | 01:01 |
| abentley | But I would consider adding non-default support for that. | 01:02 |
| igc | I was planning to leave the old merge-directive cmd untouched as well | 01:02 |
| pattern | and, btw, the command had to be "bzr cvsps-import /path/to/my/CVSROOT . output" | 01:02 |
| abentley | igc: Yes, that makes sense. | 01:02 |
| igc | poolie, lifeless, jam-laptop: any objections to renaming 'merge directive' to 'merge recipe' at the UI level (bar the old cmd) ? | 01:03 |
| igc | I want to stop talking about bundles | 01:04 |
| poolie | hm | 01:04 |
| igc | and say 'merge recipe' instead | 01:04 |
| poolie | i agree a better name would be better | 01:04 |
| poolie | i'm not 100% happy with 'merge recipe' for two reasons | 01:04 |
| poolie | - it's maybe still a bit cute | 01:04 |
| poolie | - more important, it suggests it's going to be just "merge $chocolate into $bowl" whereas in fact it normally carries the revisions with it | 01:05 |
| poolie | though i guess aaron's framework does allow it to be just the instructions | 01:05 |
| igc | the metaphor of a pre-mix cake isn't far off | 01:06 |
| poolie | indeed - recipe plus ingredients | 01:06 |
| igc | you get the recipe and the ingredients | 01:06 |
| poolie | and a mediocre-to-ok cake :) | 01:06 |
| igc | but only the recipe is mandatory | 01:06 |
| igc | so that's why I favour 'merge recipe' over 'merge pack' say | 01:07 |
| lifeless | I'm nonplussed by all this | 01:09 |
| lifeless | cart is looking quite nice | 01:10 |
| lifeless | I think its great to have an answer to trac for bzr projects that don't want to use lp | 01:10 |
| poolie | is that a sequiter or not? | 01:11 |
| lifeless | non | 01:11 |
| poolie | is 'merge request' already struck out? | 01:11 |
| hunmonk | quick question: my version of bzr is using knits. is there a newer branch format now? | 01:12 |
| lifeless | I'm not going to enter into the discussion other than to note that 'merge directive' works fine for me and I've not seen anyone confused by it | 01:12 |
| pattern | ok.. more stupid questions... "bzr cvsps-import /path/to/my/CVSROOT . output" created an "output" directory (with "bzr" and "staging" as subdirs)... so, what do i do with this output directory to get bzr to recognize it as a repository? where do i put it? do i need to cd in to it to use it? | 01:13 |
| poolie | hunmonk, there is a new experimental repository format, 'packs' | 01:13 |
| poolie | it is in bzr.dev and will be in 0.92 | 01:13 |
| poolie | if you'd like to try it and give feedback that would be great | 01:14 |
| hunmonk | poolie: will it be the default in 0.92 | 01:14 |
| hunmonk | ? | 01:14 |
| poolie | not in 0.92 | 01:14 |
| hunmonk | hm. fink is still at 0.18-1... | 01:14 |
| lifeless | pattern: you can cd into it | 01:15 |
| lifeless | pattern: if your files are not present in the output dir, its a tree-less repository, try 'bzr checkout .' | 01:16 |
| lifeless | pattern: or it may be that the cvsps-import wants modules, in which case doing 'mkdir project && mv myfile.c,v project' in your CVS repo and converting via | 01:17 |
| pattern | would i type "bzr checkout ." while i'm cd'ed in to "output" ? | 01:17 |
| lifeless | cvsps-import ...CVSROOT project output | 01:17 |
| lifeless | pattern: yes, I think so | 01:17 |
| pattern | bzr: ERROR: Not a branch: "/path/to/output" | 01:18 |
| pattern | that's from "bzr checkout ." | 01:19 |
| pattern | earlier i had copied myfile.c,v to /path/to/my/CVSROOT before running "bzr cvsps-import /path/to/my/CVSROOT . output" | 01:20 |
| poolie | abentley, the cart site looks really nice | 01:20 |
| abentley | Thanks, poolie. | 01:20 |
| poolie | though http://cart.aaronbentley.com/issue/26 does remind me, in the fondest way, of C64 BASIC line-renumbering tools | 01:20 |
| pattern | which told me "Creating cvsps dump file: output/staging/ROOT.dump" and "Read 4 patchsets (string cache hits: 0, total: 25)" "Processed 4 patches (4 new, 0 existing) on 0 branches (1 tags) in 0.3s (14.40 patch/s)" | 01:20 |
| abentley | poolie: Yeah, that's actually what I'm working on now. | 01:21 |
| poolie | but i kind of wish launchpad had something like that - just 'importance' is a bit coarse | 01:21 |
| poolie | is the frontpage just static text? | 01:21 |
| abentley | I *think* this is a clear way of providing priority ranking. The alternative would be a linked list. | 01:22 |
| abentley | The front page is rendered from a ReST file and shoved into a template. So the *file* is static, if that's what you mean. | 01:23 |
| lifeless | 10:10 < lifeless> cart is looking quite nice | 01:23 |
| lifeless | 10:10 < lifeless> I think its great to have an answer to trac for bzr projects that don't want to use lp | 01:23 |
| abentley | But it's actually dynamically generated. | 01:23 |
| lifeless | abentley: ^ ;) | 01:23 |
| abentley | lifeless: Coolness. | 01:24 |
| abentley | poolie: the argument against "merge request" was that a merge request is actually the email that you send to the list, not the attachment the email contains. But I suppose we could use that... | 01:27 |
| spiv | poolie, lifeless: just sent a bundle for 155730 to the list. | 01:30 |
| poolie | abentley, well, it would be neat if you could just drag them around in the browser... | 01:37 |
| abentley | poolie: Yeah, I want to support that too. | 01:37 |
| poolie | gah | 01:44 |
| poolie | it's pretty annoying that there are several similar implementations of, say, unlock in remote.py :-/ | 01:44 |
| spiv | Yeah :/ | 01:45 |
| poolie | spiv, lifeless: so, remoterepsoitoyr.unlock | 01:54 |
| igc | lifeless: just confirming, experimental supports tags doesn't it? | 01:54 |
| lifeless | igc: different layers | 01:54 |
| igc | let me ask differently ... | 01:54 |
| poolie | (igc, but yes, it does) | 01:54 |
| igc | compatible with dirstate-tags? | 01:54 |
| poolie | rr.unlock does the unlocking twice: once at the vfs level, once at the rpc level | 01:54 |
| lifeless | igc: yes, the branch format referred to by the experimental label is the tags format. | 01:55 |
| igc | that's how I remembered it from the review. Thanks | 01:55 |
| poolie | at present, if the vfs unlock fails, the rpc unlock is not done - this seems strange to me | 01:56 |
| poolie | any comments? | 01:56 |
| spiv | Hmm. | 01:56 |
| * spiv looks | 01:56 | |
| poolie | about line 500 | 01:57 |
| spiv | Yeah, that is a little weird I guess. | 02:01 |
| spiv | I guess ideally the self._real_repository unlock shouldn't be able to fail, we're only invoking it to keep the state of the self._real_repository object in sync with the state in RemoteRepo. | 02:02 |
| spiv | We don't expect _real_repository.unlock() to actually remove the lock, because we acquired it with a lock_token. And we're about to try the real unlock via a remote method. | 02:03 |
| pattern | when i type "bzr checkout ." in /path/to/output i get an error: "bzr: ERROR: Not a branch: "/path/to/output"" | 02:03 |
| pattern | how would i list the branches bzr knows about? | 02:03 |
| spiv | So letting _real_repository.unlock() do any work at all is just inviting failures (and roundtrips) for no real benefit. (except for the benefit of leaving the locking API unchanged...) | 02:04 |
| AfC | pattern: branches are all peers and independent. When a branch has a relationship to another you can see it with `bzr info` | 02:08 |
| poolie | pattern, you need to cd into one of the branch directories | 02:10 |
| poolie | or run 'bzr info BRANCH_DIR' | 02:10 |
| poolie | spiv, ok, so now that we have write groups | 02:10 |
| poolie | it can fail, if for example the write group is not finished | 02:11 |
| poolie | and, in general, you know it is a method that can fail | 02:11 |
| poolie | and there are the round trips as you say | 02:11 |
| spiv | poolie: but it's still correct to say that any failure that would happen would also happen on the RemoteRepository._unlock() instead? | 02:13 |
| poolie | spiv, well, no, it currently delegates its write groups entirely to the real repository | 02:14 |
| lifeless | so | 02:14 |
| lifeless | write groups are not something that should cross the wire IMO | 02:15 |
| lifeless | we should 'buffer' the data and do a single insert over the wire | 02:15 |
| lifeless | where buffer currently is 'write to the remote location an upload pack', but could mean 'buffer in /tmp' | 02:16 |
| poolie | "not cross the wire" in the sense of there's no write-group related rpc | 02:16 |
| poolie | i agree | 02:16 |
| lifeless | right | 02:17 |
| poolie | hm | 02:17 |
| poolie | spiv, when you say that real_repository.unlock shouldn't touch the lock | 02:17 |
| poolie | hm | 02:17 |
| spiv | Well, _real_repository.unlock should leave the lock in place. | 02:18 |
| poolie | is that because the lock will ultimately be removed by the _unlock call being passed to the server and releasing it there | 02:18 |
| spiv | Because a lock_token was passed to _real_repository.lock_write | 02:18 |
| spiv | Right. | 02:18 |
| spiv | We only call lock_write/unlock on _real_repository to keep its knowledge of the lock state in sync with what's happened at the RPC layer. | 02:19 |
| poolie | hm | 02:19 |
| poolie | maybe we could arrange for them to share a lock object or something | 02:19 |
| poolie | not right now | 02:20 |
| spiv | So that it won't e.g. try to acquire a new lock for the repo when the repo is already locked by RPC. | 02:20 |
| lifeless | poolie: they are sharing a lock object - thats the lock token concept | 02:21 |
| lifeless | poolie: its a shared lock across the wire | 02:21 |
| poolie | sure | 02:22 |
| poolie | my point is, unlock() has several effects | 02:22 |
| poolie | so it's a bit of a blunt instrument for telling the vfs repo "be aware i've unlocked you" | 02:22 |
| spiv | Well, my reconcile fix completes on bzr.dev without blowing up, that's a good sign... | 02:22 |
| lifeless | spiv: can you: init --experimental foo; cd foo; bzr pull ../reconciled-bzr.dev; bzr push ../new-dir | 02:23 |
| lifeless | spiv: where foo is *not* within a shared repo | 02:23 |
| spiv | lifeless: Will do. | 02:23 |
| spiv | I've just verified that the relevant kndx now has a fulltext for that record. | 02:23 |
| spiv | (And now has only 2 versions of that file; the other 10 were never referenced by anything and so the new reconcile removes them. Brings du -hs .bzr/repository down from 73M to 71M, even with the extra fulltexts.) | 02:24 |
| spiv | lifeless: it'd be nice if push actually gave a progress bar... | 02:28 |
| lifeless | spiv: yes, but its so fast who cares? :] | 02:29 |
| spiv | lifeless: well, here's the funny thing... it isn't. | 02:29 |
| lifeless | spiv: initial local branch spends a lot of time ungzipping | 02:30 |
| spiv | lifeless: 2m 42s real, mostly spent on CPU... | 02:30 |
| spiv | Ah. | 02:30 |
| spiv | I was starting to wonder if my reconciled repo had sent it off into an infinite loop somehow. | 02:30 |
| spiv | lifeless: so, those commands all appeared to work. | 02:31 |
| lifeless | cool | 02:31 |
| lifeless | thats the acid test | 02:31 |
| spiv | lifeless: I have 61M of repo data according to du -hs, and all appears to be well. | 02:32 |
| spiv | (I guess the 10M reduction is partly due to the lack of annotations?) | 02:32 |
| lifeless | yes | 02:32 |
| pattern | ok, well, looks like cvsps-import isn't working for me, so i'm giving tailor a try | 02:43 |
| pattern | but tailor tells me "Common base for tailor exceptions: 'bzr' is not a known VCS kind: cannot import name compare_trees" | 02:44 |
| pattern | the only thing i could find through google on this error says it could be due to using python 2.3 instead of 2.4, but i'm definitely using 2.4 | 02:45 |
| pattern | 2.4.4, to be exact | 02:45 |
| === kiko is now known as kiko-zzz | ||
| pattern | ok... a completely unrelated question... | 02:52 |
| pattern | when i do a "bzr init", is all the data that bzr needs stored in the "./.bzr" directory? | 02:52 |
| jam-laptop | pattern: I just came back, I can try and help you with cvsps-import | 02:54 |
| jam-laptop | (I would generally recommend it over tailor) | 02:54 |
| pattern | or does "bzr init" modify data elsewhere on my filesystem (as in somewhere around where it was installed, for example in "/usr/lib64/python2.4/site-packages/bzrlib") ? | 02:54 |
| pattern | ok, cool | 02:54 |
| jam-laptop | pattern: generally we only store data in .bzr/* | 02:54 |
| pattern | great | 02:54 |
| jam-laptop | pattern: so what are you trying to do? | 02:54 |
| jam-laptop | the only other place might be $HOME/.bazaar/* | 02:54 |
| jam-laptop | for your configuration files, etc. | 02:54 |
| pattern | well, i'm trying to migrate my RCS repository to bazaar | 02:54 |
| jam-laptop | RCS or CVS? | 02:55 |
| pattern | RCS | 02:55 |
| jam-laptop | hmm... | 02:55 |
| pattern | someone on #cvs told me all i had to do was do a "cvs init" and then copy my ,v files from RCS in to my CVSROOT directory for me to migrate from RCS to CVS | 02:55 |
| pattern | which is what i did | 02:55 |
| jam-laptop | pattern: does "cvs -d CVSROOT rlog", etc work? | 02:56 |
| jam-laptop | (I can see that it could, but I'd check that first) | 02:56 |
| pattern | yes, it works | 02:57 |
| pattern | rlog does, anyway | 02:57 |
| jam-laptop | ok, and do you have "cvsps" installed? | 02:57 |
| pattern | yep | 02:57 |
| pattern | and the first time i tried cvsps-import, it actually didn't give me an error, and seemed to work... and i got an output directory | 02:58 |
| jam-laptop | And you have cvsps-import installed ~/.bazaar/plugins/ | 02:58 |
| jam-laptop | as something like | 02:58 |
| pattern | but then i couldn't get bzr to work with it | 02:58 |
| jam-laptop | "cvsps_import" | 02:58 |
| jam-laptop | ok, the output directory should have several things going on | 02:58 |
| pattern | and now i've deleted and recreated my output and CVS directories a million times, trying to get this to work, and now i always get errors from cvsps-import | 02:58 |
| pattern | yes, i have the plugin installed in ~/.bazaar/plugins | 02:59 |
| pattern | and bzr recognizes the command, and runs it | 02:59 |
| jam-laptop | give me a couple of seconds to remember all about cvsps-import. | 02:59 |
| jam-laptop | But I'm guessing you were trying to do something with the top-level | 02:59 |
| jam-laptop | when the actual data is lower down | 02:59 |
| jam-laptop | I split the target directory into 2 paths | 03:00 |
| jam-laptop | one is for the conversion data | 03:00 |
| jam-laptop | (stuff cvsps needs to keep track of, but you don't need after the conversion) | 03:00 |
| jam-laptop | well, cvsps-import needs to keep track of | 03:00 |
| jam-laptop | also, if you are messing with your cvs repo | 03:00 |
| jam-laptop | you should delete the cvsps cache | 03:00 |
| jam-laptop | in ~/.cvsps | 03:00 |
| pattern | ah! | 03:01 |
| pattern | i knew there must have been something cached somewhere | 03:01 |
| jam-laptop | So when you run the conversion, there will be a bzr repository in "OUTPUT/bzr" | 03:01 |
| pattern | ok.. this might work better now | 03:01 |
| jam-laptop | and individual branches in | 03:01 |
| jam-laptop | OUTPUT/bzr/branches/ | 03:01 |
| jam-laptop | the important one being | 03:01 |
| jam-laptop | OUTPUT/bzr/branches/HEAD | 03:01 |
| pattern | ok, great, no errors now | 03:01 |
| jam-laptop | oh, sorry | 03:01 |
| jam-laptop | OUTPUT/bzr/MODULE/branches/HEAD | 03:02 |
| jam-laptop | the repository is at OUTPUT/bzr/MODULE | 03:02 |
| jam-laptop | you should be able to | 03:02 |
| pattern | i just did "bzr cvsps-import /path/to/CVSROOT . output", so i have "output/bzr/branches" | 03:03 |
| jam-laptop | bzr checkout --lightweight OUTPUT/bzr/MODULE/branches/HEAD my-project | 03:03 |
| jam-laptop | so that would be | 03:03 |
| jam-laptop | or at least do | 03:03 |
| jam-laptop | bzr log output/bzr/branches/HEAD | 03:03 |
| jam-laptop | lifeless: I see you went with the tree of dicts, have you had nDuff play with it to see if it fixed his problem? | 03:04 |
| pattern | from "bzr log output/bzr/branches/HEAD" i get "bzr: ERROR: Not a branch: "/FULLPATH/output/bzr/.bzr/branch/" | 03:04 |
| jam-laptop | hmm.. I wouldn't expect output/ to be considered a branch | 03:05 |
| pattern | where "/FULLPATH/output" is the full path to the "output" directory | 03:05 |
| jam-laptop | sure | 03:05 |
| jam-laptop | what does the output of | 03:05 |
| jam-laptop | ls -al output/bzr/branches give? | 03:05 |
| jam-laptop | (It seems like it isn't finding a branch at .../branches/HEAD) | 03:06 |
| pattern | oops, i just noticed that when i ran "bzr log output/bzr/branches/HEAD" i was already in "output/bzr" :) | 03:06 |
| pattern | sorry | 03:06 |
| pattern | now when i'm in the parent directory of "output" it works | 03:07 |
| pattern | you still there, jam? | 03:08 |
| jam-laptop | yeah, just had to do something real quickx | 03:08 |
| pattern | no problem | 03:09 |
| jam-laptop | so, it sounds like it worked just fine, we just need to explain how things are laid out | 03:09 |
| pattern | so, since it seems to work, where should i put these bzr files? | 03:09 |
| jam-laptop | to start with, bzr branches are always referenced by path | 03:09 |
| pattern | i don't need the output/staging stuff | 03:09 |
| jam-laptop | right | 03:09 |
| jam-laptop | all you need is the bzr/* stuff | 03:09 |
| pattern | ok | 03:09 |
| pattern | so should i put that in ./.bzr ? | 03:09 |
| jam-laptop | can you confirm that there is output/bzr/.bzr/repo | 03:10 |
| jam-laptop | output/bzr/.bzr/repository | 03:10 |
| pattern | output/bzr/.bzr/repository exists | 03:10 |
| jam-laptop | pattern: ok, that is your Bazaar "shared repository" | 03:10 |
| jam-laptop | So I would usually do something like | 03:10 |
| jam-laptop | mv output/bzr /srv/project-repository | 03:11 |
| jam-laptop | well, I would call it "project-repo" or something like that | 03:11 |
| pattern | hmm... well, it's just me here.. so my machine is my server... | 03:11 |
| pattern | so you recommend creating a central repository for all of my projects? | 03:11 |
| jam-laptop | I recommend it, but it certainly isn't required | 03:12 |
| jam-laptop | You might want to read a bit about what Bazaar lets you do | 03:12 |
| pattern | i'll definitely go by the recommended way, at least while i'm learning :) | 03:12 |
| jam-laptop | http://bazaar-vcs.org/Workflows has a few hints | 03:12 |
| pattern | cool | 03:12 |
| jam-laptop | because there isn't a one-size fits all | 03:12 |
| pattern | so, could you tell me how the ./.bzr directory relates to the central repository? | 03:12 |
| pattern | i'll definitely check out the link too, btw | 03:13 |
| pattern | i've already started reading the user guide | 03:13 |
| jam-laptop | So in Bazaar you have 3 basic objects | 03:13 |
| jam-laptop | Repository, Branch, WorkingTree | 03:13 |
| pattern | right, i remember that from one of the tutorials | 03:14 |
| jam-laptop | a Repository is where the bulk of the history data is stored (all the different versions of the file texts, etc) | 03:14 |
| jam-laptop | In your conversion | 03:14 |
| jam-laptop | that is the "bzr/.bzr/repository" | 03:14 |
| jam-laptop | well "output/bzr/.bzr/repository" | 03:14 |
| jam-laptop | though you would reference it by "output/bzr" | 03:14 |
| pattern | ok | 03:14 |
| jam-laptop | Then you have branches, which are pointers into this repository | 03:14 |
| jam-laptop | which are in "output/bzr/branches/*" | 03:14 |
| jam-laptop | The converter doesn't actually create a WorkingTree | 03:15 |
| jam-laptop | Because it just extracts things into memory and writes them out. | 03:15 |
| pattern | so the WOrkingTree isn't the directory you're working in? | 03:15 |
| jam-laptop | So at this point, you want to create one | 03:15 |
| jam-laptop | pattern: it is the directory you *will* be working in | 03:15 |
| jam-laptop | where you see all of your projects files | 03:15 |
| jam-laptop | If you want the simple way, I would do | 03:16 |
| pattern | just one project's files? or all the project's files? | 03:16 |
| pattern | i mean | 03:16 |
| jam-laptop | well, if you converted from the top, then you get all projects | 03:16 |
| jam-laptop | in 1 bazaar project | 03:16 |
| jam-laptop | you may want to convert module by module | 03:16 |
| pattern | one project's files, or all the projects' files? | 03:16 |
| pattern | :) | 03:16 |
| jam-laptop | You converted the "." module | 03:17 |
| jam-laptop | which is the whole cvs repository | 03:17 |
| pattern | right | 03:17 |
| pattern | and that makes up one project | 03:17 |
| pattern | so in my WorkingTree i'll get everything in that project, right? | 03:17 |
| jam-laptop | correct | 03:17 |
| pattern | but if i check in more projects... | 03:17 |
| pattern | then will i get all the projects' files in my WorkingTree? | 03:17 |
| jam-laptop | pattern: so generally projects are separated at the "Branch" level | 03:18 |
| pattern | or will i have a separate WorkingTree for each project? | 03:18 |
| jam-laptop | And you would have a separate WorkingTree for each | 03:18 |
| pattern | so there's a single repository, but many branches (one for each project) ? | 03:18 |
| jam-laptop | pattern: as many branches as you want for each project | 03:18 |
| jam-laptop | as many projects as you want in the repository | 03:18 |
| pattern | ah, ok | 03:19 |
| jam-laptop | some people prefer to create a separate repository for each project | 03:19 |
| pattern | so a WorkingTree for each branch | 03:19 |
| jam-laptop | *I* tend to mix and match | 03:19 |
| jam-laptop | unrelated projects get separate repositories, related projects share repositories | 03:19 |
| pattern | hmm | 03:19 |
| pattern | could i migrate branches from repository to repository? | 03:19 |
| jam-laptop | pattern: it is just a "bzr branch repo1/branch repo2/branch" | 03:20 |
| jam-laptop | pattern: branches float from repo to repo all the time | 03:20 |
| pattern | and will i ever check out entire repositories? or do people generally check out just a single branch at a time? | 03:20 |
| jam-laptop | just a single branch at a time (at the moment) | 03:20 |
| pattern | ok, so the choice of whether to have separate repositories or not is simply a matter of how you want to organize your data | 03:21 |
| jam-laptop | (we are working on ways to make one branch reference another, so checking out one, checks out others.) | 03:21 |
| jam-laptop | pattern: exactly | 03:21 |
| pattern | kind of like directories on a regular file system | 03:21 |
| jam-laptop | very much like directories on a filesystem | 03:21 |
| jam-laptop | http://bazaar-vcs.org/SharedRepositoryLayouts | 03:21 |
| pattern | cool | 03:21 |
| jam-laptop | Some "recommended" layouts | 03:21 |
| pattern | ok... back to the output directory, for a second | 03:22 |
| jam-laptop | k | 03:22 |
| pattern | let me just get this all in my head... | 03:22 |
| pattern | so the output/bzr directory is a repository, right? | 03:22 |
| jam-laptop | correct | 03:22 |
| pattern | and ./.bzr is what? | 03:22 |
| jam-laptop | I don't know what is in ./.bzr, did you do "bzr init" manually? | 03:22 |
| pattern | yeah | 03:23 |
| jam-laptop | ok, you just created what we call a "standalone branch" | 03:23 |
| jam-laptop | which is a Branch, WorkingTree, and Repository all in the same location | 03:23 |
| pattern | interesting | 03:23 |
| jam-laptop | at this point you could just rm -rf ./.bzr/ | 03:23 |
| pattern | ok | 03:23 |
| jam-laptop | but if you want to poke at it | 03:23 |
| jam-laptop | you can ls .bzr/ | 03:23 |
| jam-laptop | and you should see a "repository" | 03:23 |
| jam-laptop | and a "checkout" | 03:23 |
| jam-laptop | and a "branch" | 03:23 |
| jam-laptop | subdirectory | 03:23 |
| pattern | so, say i "mv output/bzr /path/to/my/brand/new/central/repository" | 03:24 |
| jam-laptop | k | 03:24 |
| pattern | i suppose once i set some environment variable, bzr will know to look there for its files | 03:24 |
| jam-laptop | actually, we generally always use full paths | 03:24 |
| pattern | and then i can just check in new projects as usual? | 03:24 |
| jam-laptop | (we don't have a repository env var, because you usually have many of them) | 03:24 |
| jam-laptop | So the big difference is doing | 03:25 |
| jam-laptop | bzr checkout /path/to/repository/foo | 03:25 |
| jam-laptop | rather than "bzr -d/path/to/repository checkout foo" | 03:25 |
| pattern | but that could be an alias, i guess | 03:25 |
| jam-laptop | pattern: sure, you can use "bzr checkout $REPO/foo | 03:25 |
| pattern | or "alias XYZcheckout='bzr checkout /path/to/repo'" | 03:26 |
| pattern | but, my main question is whether i can just use the output/bzr repository as my central repository | 03:26 |
| jam-laptop | sure | 03:26 |
| pattern | cool | 03:26 |
| pattern | so new projects can be checked in to there? | 03:27 |
| jam-laptop | just that "output/bzr" is probably not the optimal name for it :) | 03:27 |
| jam-laptop | pattern: yep | 03:27 |
| pattern | great | 03:27 |
| pattern | earlier you had me do "bzr log output/bzr/branches/HEAD" | 03:27 |
| jam-laptop | right | 03:27 |
| pattern | is there a way to specify that i just want the log for a given project? | 03:27 |
| pattern | or a given file? | 03:28 |
| jam-laptop | ... isn't that for the project? | 03:28 |
| pattern | well, it's not called "HEAD" | 03:28 |
| pattern | :) | 03:28 |
| jam-laptop | You can do "bzr log output/bzr/branches/HEAD/filename" | 03:28 |
| pattern | ah, i see | 03:28 |
| jam-laptop | HEAD is the name of the branch of your project | 03:28 |
| jam-laptop | That is CVS's terminology | 03:28 |
| pattern | ah | 03:28 |
| jam-laptop | you can "mv HEAD project" | 03:28 |
| jam-laptop | if you prefer | 03:28 |
| pattern | wonderful | 03:28 |
| pattern | ok, this is making much more sense now | 03:28 |
| jam-laptop | As long as you keep the branch inside it's repository | 03:29 |
| pattern | thank you, jam | 03:29 |
| jam-laptop | you can rename it to whatever you want | 03:29 |
| jam-laptop | so you can move the branches, etc around | 03:29 |
| jam-laptop | so that they make sense to you | 03:29 |
| pattern | and no metadata changes needed to inform bzr of my name change? | 03:29 |
| jam-laptop | correct | 03:29 |
| pattern | awesome | 03:29 |
| pattern | so, i think i'm going to go and read up some more on how bzr works | 03:29 |
| pattern | thanks again! | 03:29 |
| jam-laptop | pattern: happy to help | 03:30 |
| jam-laptop | Feel free to stop by when you have questions | 03:31 |
| jam-laptop | someone is usually around :) | 03:31 |
| pattern | oh, and by the way, the "Download project files" link on https://launchpad.net/bzr-cvsps-import says "No download files are linked to this series." | 03:31 |
| Odd_Bloke | I wonder if LP's error message would be better pointing people to available branches/project home pages... | 03:32 |
| pattern | it turned out i had to click on the "trunk" link in the bottom of the main page, under "Timeline" | 03:32 |
| pattern | and then click on "Main development branch of cvsps import" | 03:32 |
| igc | poolie, lifeless: pack renaming patch send to the ML | 03:33 |
| igc | s/send/sent/ | 03:33 |
| * igc food | 03:33 | |
| pattern | and then use the command listed in "Example" to download cvsps-import | 03:33 |
| pattern | which isn't very intuitive | 03:33 |
| pattern | if i didn't have help from this channel, i don't think i would have figured it out on my own before i gave up in frustration | 03:34 |
| poolie | igc, thanks | 03:34 |
| pattern | and the other thing is that the README file does not contain installation instructions | 03:34 |
| poolie | pattern, well, i'm glad you could get help here | 03:34 |
| poolie | the download files feature is still new and i agree it's not very obvious yet | 03:35 |
| poolie | in fact i have a bug open ... | 03:35 |
| pattern | i had to move "trunk" to ~/.bzr/plugins/cvsps" | 03:35 |
| pattern | poolie: yeah, the help in here is fantastic | 03:36 |
| pattern | i really appreciate it | 03:36 |
| poolie | see bug 139052 | 03:36 |
| ubotu | Launchpad bug 139052 in launchpad "link to project downloads from the project home page" [High,Confirmed] https://launchpad.net/bugs/139052 | 03:36 |
| pattern | any bug for detailed installation instructions? :) | 03:37 |
| pattern | might save you some work explaining this all over again to the next guy who tries to install cvsps-import | 03:37 |
| * Odd_Bloke has also just filed Bug #156919. | 03:39 | |
| ubotu | Launchpad bug 156919 in launchpad "More information on where to download files needed" [Undecided,New] https://launchpad.net/bugs/156919 | 03:39 |
| pattern | not just where to download them, but a couple of simple things like: "To install, 'mv trunk $HOME/.bzr/plugins/cvsps" | 03:40 |
| pattern | and "'output/bzr' will be your repository. you can access it by, for example, typing 'bzr log output/bzr/branches/HEAD'" | 03:41 |
| pattern | oh yeah, and maybe a suggestion to delete the cvsps cache ($HOME/.cvsps) if you run in to problems | 03:42 |
| Odd_Bloke | Heh, poolie in before my suggesting a bug report. Bug #156920. | 03:43 |
| ubotu | Launchpad bug 156920 in bzr-cvsps-import "cvsps-import readme needs install instructions" [Undecided,New] https://launchpad.net/bugs/156920 | 03:43 |
| pattern | ok... i think i'm done suggesting :) | 03:44 |
| pattern | thanks for writing a useful tool | 03:44 |
| pattern | and for the great support | 03:44 |
| poolie | you're welcome | 03:47 |
| poolie | tell your friends! :) | 03:47 |
| pattern | i will! | 03:47 |
| poolie | off for lunch and pre-trip foo | 03:47 |
| jam-laptop | poolie: you leave tomorrow, right? | 03:48 |
| jam-laptop | poolie: good luck | 03:48 |
| poolie | yeah, i'll be at the airport this time tomorrow | 03:48 |
| poolie | thanks | 03:48 |
| jam-laptop | have a safe and restful flight :) | 03:48 |
| poolie | thanks | 03:48 |
| jam-laptop | We missed our call this week, but I think it's not a big deal | 03:49 |
| poolie | yeah, we talked friday? | 03:49 |
| jam-laptop | sounds right | 03:49 |
| poolie | how's stuff? i've seen you posting more again | 03:49 |
| jam-laptop | things are going pretty well | 03:49 |
| jam-laptop | just working on going through the critical bugs | 03:49 |
| jam-laptop | and fixing that old dirstate bug | 03:49 |
| jam-laptop | fullermd sure likes to do crazy stuff | 03:50 |
| ubotu | New bug: #156920 in bzr-cvsps-import "cvsps-import readme needs install instructions" [Undecided,New] https://launchpad.net/bugs/156920 | 03:50 |
| Odd_Bloke | ubotu: ORLY? | 03:52 |
| ubotu | Sorry, I don't know anything about orly? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 03:52 |
| Odd_Bloke | ¬.¬ | 03:52 |
| poolie | jam-laptop, i think when andrew's reconcile patch and igc's format name patch are in we can do an rc | 03:53 |
| poolie | anyhow, i should really go | 03:53 |
| poolie | have a good night, talk to you next week | 03:53 |
| lifeless | jam-laptop: he hasn't played with it yet AFAIK | 04:06 |
| lifeless | nDuff: ping | 04:07 |
| fullermd | It's not my fault. The Internet made me do it. | 04:41 |
| igc | lifeless: re your idea re referring to the pack doc in the help, what name do you think that doc ought to have? | 04:56 |
| igc | e.g. .. | 04:56 |
| igc | NEWS.0.92 | 04:56 |
| igc | Using Packs | 04:56 |
| igc | en/user-guide/using-packs.html? | 04:57 |
| igc | other??? | 04:57 |
| igc | I could just say the -using-packs help topic and ... | 04:58 |
| === mthaddon changed the topic of #bzr to: LP going down in 15 mins for approx 1 hour for update - The Bazaar Version Control System | http://bazaar-vcs.org/ | The packs have landed | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d | ||
| igc | extend help to lookup unknown topics in en/user-guide? | 04:58 |
| igc | I like that idea myself by YMMV for others | 05:00 |
| lifeless | igc: http://doc.bazaar-vcs.org/... | 05:06 |
| lifeless | igc: for now the reference packs doc that already exists is good; thats the one that I think the how to dogfood stuff should go in | 05:07 |
| lifeless | igc: help is planned to support references to the docs. e.g. 'seealso= ['userguide/foo.txt']' already works. | 05:08 |
| igc | lifeless: developers/knitpack.txt you mean? | 05:08 |
| lifeless | igc: right, so http://doc.bazaar-vcs.org/en/latest/developers/knitpack.txt | 05:08 |
| lifeless | or whatever it is | 05:08 |
| igc | cool | 05:08 |
| igc | thanks | 05:08 |
| lifeless | mthaddon: why the topix change? Its not really relevant here is it ? | 05:09 |
| mthaddon | lifeless, if you're not interested I'll take it off the list for next time - I can change it back if you like | 05:09 |
| lifeless | well, if poolie hasn't asked for it, I would say we're not that interested | 05:09 |
| mthaddon | (I mean if it's not relevant to this channel) | 05:09 |
| mthaddon | ok, fair enough - thx | 05:10 |
| lifeless | not that we don't use launchpad, but checking #launchpad is really quite easy | 05:10 |
| === mthaddon changed the topic of #bzr to: The Bazaar Version Control System | http://bazaar-vcs.org/ | The packs have landed | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d | ||
| mthaddon | cool, thx | 05:10 |
| mthaddon | one less thing for me to remember to change back afterwards :) | 05:10 |
| === n2diy_ is now known as n2diy | ||
| pattern | when i type "bzr status foo" then bzr returns without any output | 06:00 |
| pattern | foo is an existing file which i checked in via cvsps-import | 06:00 |
| pattern | shouldn't "bzr status foo" tell me that foo was added? | 06:01 |
| nDuff | lifeless: I'm still not seeing anything newer than 2852 in the knits-based tree. | 06:02 |
| spiv | pattern: if there's no output, then that file hasn't changed since the last commit. | 06:02 |
| spiv | pattern: i.e. that version of foo is already committed | 06:03 |
| pattern | is there a way to see what files are versioned in a given branch? | 06:04 |
| lifeless | nDuff: hmm, let me check | 06:05 |
| Odd_Bloke | pattern: bzr ls --versioned | 06:05 |
| lifeless | nDuff: 2856 is there; perhaps you have an aggressive cache ? | 06:05 |
| lifeless | pack-repository.knits $ bzr revno | 06:06 |
| lifeless | 2856 | 06:06 |
| pattern | cool | 06:06 |
| pattern | thanks | 06:06 |
| pattern | hmm... i have a directory "CVSROOT" which i wanted to remove from bzr, so i typed "bzr remove CVSROOT" | 06:09 |
| pattern | and it said it deleted that directory and all the files in it | 06:10 |
| pattern | but when i do "bzr checkout ~/bzr/branches/myproject", it still checks out CVSROOT and all the files in that directory | 06:10 |
| poolie | (back) | 06:10 |
| pattern | oops, i mean "bzr checkout ~/bzr/branches/myproject ." | 06:10 |
| spiv | pattern: did you commit after your removed CVSROOT? | 06:12 |
| pattern | ah | 06:12 |
| pattern | nope | 06:12 |
| pattern | alright.. that works now :) | 06:14 |
| pattern | groovy | 06:14 |
| pattern | i like this system already | 06:14 |
| pattern | nice and simple | 06:14 |
| pattern | intuitive | 06:14 |
| pattern | command line drive | 06:14 |
| pattern | driven | 06:14 |
| poolie | igc, lifeless, i'd expected the commandline name for the format would not say '-experimental' | 06:15 |
| poolie | so that it would be stable once it is released | 06:15 |
| poolie | i mean, once it is nonexperimental | 06:15 |
| igc | well, I had that in my 1st patch and ... | 06:16 |
| poolie | i saw, robert objected | 06:16 |
| poolie | i'll just reply by mail | 06:16 |
| poolie | i don't want to flap about it | 06:16 |
| igc | I agree with lifeless that it's proably safer to name it -experimental in 0.92 | 06:16 |
| poolie | ok | 06:16 |
| nDuff | lifeless: oh -- forgot that I unbound. | 06:16 |
| * nDuff does a pull rather than an update, and all's well. | 06:18 | |
| lifeless | poolie: we can remove -experimental from the human name in 0.93 | 06:19 |
| lifeless | poolie: and the disk format does not say experimental | 06:19 |
| poolie | it's ok | 06:21 |
| poolie | >>Launchpad is offline for scheduled maintenance. We should be back soon. | 06:22 |
| poolie | feh | 06:22 |
| lifeless | oh btw | 06:22 |
| lifeless | mthaddon updated the topic here,w hich I thought was fairly uninteresting for bzr folk | 06:22 |
| lifeless | conversation should be in your scrollback | 06:22 |
| pattern | RCS has a feature where you can write "$Revision: $" and "$Date: $" anywhere in a file, and when you check out that file, RCS will automatically insert the version and date before the last "$" in the respective parts of the file | 06:33 |
| pattern | is there anything like that in bzr? | 06:33 |
| pattern | or, bazaar, rather :) | 06:35 |
| spiv | pattern: no, we don't have keyword substitution, although it gets discussed from time to time. (e.g. at http://bazaar-vcs.org/KeywordExpansion) | 06:35 |
| pattern | ah, ok | 06:35 |
| pattern | i guess i can live without it :) | 06:35 |
| pattern | but would be nice | 06:36 |
| pattern | looks like there's a plugin to do the version, though | 06:37 |
| pattern | i'll try it | 06:37 |
| lifeless | pattern: its in core | 06:39 |
| lifeless | pattern: bzr version-info | 06:39 |
| pattern | oh, it is | 06:42 |
| pattern | i see it's not quite the same, though | 06:42 |
| pattern | it doesn't actually modify the file in question | 06:42 |
| Odd_Bloke | poolie: When LP's back up (which it partially is now) throw me a link to the bug in question. | 06:43 |
| pattern | it just outputs version information, and it's up to you to do what you want with it | 06:43 |
| Odd_Bloke | pattern: Potentially you could use that and a commit hook, but I expect it would be complex. | 06:43 |
| pattern | just a bit of keyword substitution | 06:44 |
| pattern | or just run m4 on it | 06:44 |
| pattern | not that i know m4 | 06:44 |
| pattern | but it can't be that hard | 06:44 |
| pattern | anyway, that's a project for another day | 06:45 |
| pattern | i'm still learning basic bazaar... don't want to jump in to writing commit hooks already | 06:45 |
| pattern | thanks for the suggestion, though :) | 06:45 |
| igc | poolie: abentley feels pretty strongly about keeping the subtrees stuff pretty hidden for now | 06:46 |
| igc | are you sure you want knitpack-subtrees-experimental mentioned in NEWS? | 06:47 |
| lifeless | nDuff: how does it perform now ? | 06:48 |
| igc | poolie: in case you missed my Q ... | 06:49 |
| igc | abentley feels pretty strongly about keeping the subtrees stuff pretty hidden for now | 06:49 |
| igc | are you sure you want knitpack-subtrees-experimental mentioned in NEWS? | 06:49 |
| poolie_ | igc, it can be mentioned as "for people who are testing the prototype subtree support, you can test xxxx" | 06:50 |
| igc | ok | 06:50 |
| poolie_ | put as many warnings on it as you/abentley feel is appropriate | 06:51 |
| poolie_ | do you think he'd disagree with this? | 06:51 |
| abentley | It is okay | 06:52 |
| igc | thanks | 06:52 |
| igc | the main user base seems to be bzr-svn users right now | 06:52 |
| lifeless | btw, abentley igc jam-laptop poolie_ - I've written a possibly inventory serialisation change proposal to the list | 06:52 |
| poolie_ | lifeless, i'm reading it | 06:52 |
| lifeless | input/critique valued | 06:52 |
| poolie_ | it's interesting | 06:52 |
| fullermd | pattern: You probably shouldn't hvae had the CVSROOT dir in the conversion in the first place... | 06:53 |
| poolie_ | i probably should not spend as much time on it as it deserves, so as to review anything else for .92 | 06:53 |
| igc | saw that lifeless - shall get to it soon :-) | 06:53 |
| lifeless | read it on the plane :) | 06:53 |
| lifeless | it's probably not something I'll get off the plane with. | 06:53 |
| lifeless | it might be a tad big. Or maybe not. | 06:53 |
| poolie_ | i was a bit worried about a fait accompli | 06:53 |
| poolie_ | :) | 06:53 |
| poolie_ | well, 'worried' is not quite right | 06:54 |
| lifeless | hey, we have a review process :) | 06:54 |
| pattern | fullermd: yeah, i agree... i think i got via cvsps-import because i had done a "cvs init" | 06:57 |
| lifeless | poolie_: hopeful would be a good word :) | 06:58 |
| pattern | fullermd: maybe if i just deleted the "CVSROOT" subdirectory out of my $CVSROOT directory before doing the cvsps-import, then i wouldn't have it in my branch | 06:58 |
| lifeless | pattern: I think making a subdir will work | 06:58 |
| lifeless | pattern: in the dir that CVSROOT is in, mkdir 'project' | 06:59 |
| lifeless | pattern: then move your ,v files into project | 06:59 |
| lifeless | pattern: and import again, passing 'project' rather than '.' | 06:59 |
| lifeless | pattern: also, please file a bug :) | 06:59 |
| pattern | yeah, i had tried that before.. and thought it didn't work, but at the time i didn't know how to really check if it worked properly | 06:59 |
| pattern | so that may well work.. and i might try it again | 07:00 |
| pattern | i will file the import of the CVSROOT directory as a bug | 07:02 |
| fullermd | Well, if you delete CVSROOT, it's not a CVS repo anymore. | 07:02 |
| fullermd | Only way I could imagine getting it in the conversion would be if you tried to convert the root of the repo into a bzr branch, though. And that would be nonsensical. | 07:03 |
| lifeless | fullermd: thats what he did | 07:03 |
| lifeless | fullermd: and it makes perfect sense; modules are convention in cvs | 07:03 |
| fullermd | You'd really only want to import a module (or part of a module). Of course, if you never made the RCS->CVS jump, that sounds gibberish... | 07:03 |
| lifeless | fullermd: having a cvs repo that has one module '' is fine, works well. | 07:04 |
| fullermd | Well, yes, but it's an awful strong convention (made only stronger by the fact that CVSROOT is one of them) | 07:04 |
| fullermd | "one module" != "files in the root". | 07:05 |
| fullermd | Dealing with files outside of a module in CVS is rushing in where angels fear to tread. I don't think you CAN do it at all without at least some initial hand-hackery. | 07:06 |
| lifeless | fullermd: dude its totally trivial | 07:06 |
| lifeless | fullermd: it is in fact the defalt mode of operation | 07:06 |
| pattern | well, what i did was "export CVSROOT=/path/to/myproject/CVS ; mkdir $CVSROOT ; cvs init ; cp /path/to/myproject/RCS/*,v $CVSROOT ; bzr cvs-import $CVSROOT . output" | 07:06 |
| lifeless | fullermd: 'cvs -d ...ROOT co . project' | 07:07 |
| fullermd | trivial doesn't mean sensible. Any setup which ends up with CVSROOT as a directory in your branch along side your working files I'm willing to declare insensible in the absence of extraordinary evidence that it's intended. | 07:07 |
| lifeless | fullermd: :) | 07:07 |
| pattern | so, after "cvs init ; cp /path/to/myproject/RCS/*,v $CVSROOT" the contents of $CVSROOT were my RCS/*,v files and the "CVSROOT" directory | 07:07 |
| fullermd | pattern: Right. In the CVS idiom, those ,v files would actually all be in $CVSROOT/myproject (or some similar name) | 07:08 |
| pattern | so why import $CVSROOT/CVSROOT ? | 07:08 |
| fullermd | You wouldn't. It's just part of the structure of a CVS repo. | 07:09 |
| fullermd | (well, I can conceive of cases where someone _might_, but they're really wacko, and _you_ wouldn't) | 07:09 |
| pattern | so couldn't cvsps-import just ignore it and not import it? | 07:09 |
| fullermd | You'd import $CVSROOT/myproject into a bzr branch. | 07:09 |
| pattern | yep | 07:09 |
| fullermd | That would probably be over-smartness on its part. You could have a dir called CVSROOT inside your project, for instance. | 07:10 |
| lifeless | bleh | 07:10 |
| lifeless | file a bug | 07:10 |
| fullermd | (unrelated to a CVS repo's CVSROOT magic dir) | 07:10 |
| lifeless | let john worry | 07:10 |
| pattern | well, aren't there some special files in CVSROOT that only CVS puts there? | 07:10 |
| pattern | a whole bunch of files, actually | 07:10 |
| pattern | and they're pretty standard for CVS | 07:11 |
| pattern | so, if they're in there, and nothing else is there, then i'd say it's safe to delete the directory | 07:11 |
| pattern | but i think odds are no one's going to have a CVSROOT directory in their $CVSROOT unless it was put there by CVS | 07:11 |
| fullermd | They are. But I'd consider magically seeing files with those names in that directory way too DWIMish for something as important as a conversion (unlikely as the trigger case may be) | 07:11 |
| pattern | in which case, it's safe to delete it | 07:11 |
| pattern | no, not just names, you could check contents too | 07:12 |
| pattern | but even the names would be enough | 07:12 |
| pattern | it's almost like an md5 :) | 07:12 |
| fullermd | Really, I think the bug is "cvsps-import shouldn't allow importing the root of a repo" | 07:12 |
| pattern | what are the odds of having 20 files with the exact name that CVS uses in a directory called CVSROOT and not have them be put there by CVS ? | 07:12 |
| lifeless | fullermd: actually, cvsps-import should be easier to use | 07:12 |
| lifeless | guys, this is a non argument. | 07:12 |
| fullermd | I can conceive of cases where I'd have something looking exactly like a real CVSROOT in a tree, and I'd be royally honked off if a VCS imported dropped my data on the floor because of a heuristic like that. | 07:12 |
| pattern | i guess that's concievable | 07:13 |
| lifeless | fullermd: OTOH the only reason you'd do that is to cause trouble. | 07:13 |
| pattern | but it's even more conceivable that you wind up importing junk 99.99999% of users don't need | 07:13 |
| fullermd | lifeless: Well, that's my specialty, isn't it? :p | 07:13 |
| lifeless | fullermd: because, by definition, CVS will consider that to be a repository itself. | 07:13 |
| fullermd | Not really, because You-the-CVS-user wouldn't want to import the root of a repo as a branch, so... | 07:14 |
| pattern | that's true | 07:14 |
| fullermd | At least, not without --force or something, in which case You(tm) presumably _would_ want the CVSROOT versioned. | 07:14 |
| pattern | but you'd still want to ignore CVSROOT | 07:15 |
| fullermd | I'm willing to demote the "I want to convert the root of my repo into one branch, EXCEPT not CVSROOT" case into some rebase-with-filter territory. | 07:15 |
| fullermd | I know I've occasionally made CVS commits spanning modules, but I'm pretty sure I've never done it for a good reason that should be preserved. | 07:16 |
| === abentle1 is now known as abentley | ||
| pattern | well, what you do with files in the root of $CVSROOT is a separate issue from what gets done with $CVSROOT/CVSROOT | 07:17 |
| fullermd | But to drag back to something remotely topical, I have a number of CVS repos around that started their lives in RCS, and just copying the files into a module always came off without a hitch (and I may have cvsps-imported one or two of them once, not sure) | 07:18 |
| pattern | that sounds like the right way to do things | 07:18 |
| pattern | when i dumped my RCS/*,v files in to $CVSROOT i was just following the instructions of someone on #cvs | 07:19 |
| fullermd | Yah. It's dangerous to say "no CVS user ever would XYZ", 'cuz I KNOW some of the wake-up-screaming things CVS users have done. But I would say the case of having files directly in $CVSROOT is vanishingly rare, and probably a bad idea where it does exist. | 07:19 |
| poolie_ | spiv, hi? | 07:20 |
| spiv | poolie_: hello | 07:23 |
| pattern | ok... i just created myself a brand spanking new launchpad account... | 07:25 |
| pattern | so... should i file a bug for cvsps-import to not import $CVSROOT/CVSROOT or not? | 07:25 |
| * fullermd shrugs. | 07:27 | |
| fullermd | _I_ don't think that's a/the bug. But I can just file a comment on it and move on. | 07:27 |
| pattern | ok, then i'll file it | 07:27 |
| pattern | for the record | 07:27 |
| poolie_ | pattern, i have not followed the whole thread | 07:27 |
| lifeless | nDuff: ? | 07:27 |
| pattern | and let the winds blow where they may | 07:27 |
| poolie_ | but it seems like it could be a useful option | 07:28 |
| === poolie_ is now known as poolie | ||
| pattern | poolie_: cvsps-import imports $CVSROOT/CVSROOT | 07:28 |
| fullermd | Yah. Paper trails are good. At least, until the grand jury convenes. | 07:28 |
| pattern | where i think it should only import $CVSROOT (or possibly just the rest of the directories under $CVSROOT) but not $CVSROOT/CVSROOT | 07:29 |
| pattern | as that's a directory full of CVS metadata that bazaar has no use for | 07:29 |
| indu | hi all | 07:29 |
| pattern | at least that's my understanding of it | 07:29 |
| indu | i have installed bazaar and loggerhead, both are well working | 07:29 |
| pattern | as i'm not a CVS user | 07:29 |
| pattern | but fullermd thinks there are corner cases where $CVSROOT/CVSROOT might have data the user wants to keep | 07:30 |
| indu | but i am wondering how i can acess it remotely, as it uses apache web server, it should be able to access using the ipaddress | 07:30 |
| indu | but when i tried to access my loggerhead gui from a remote system, using my system ip address, it couldnt' fetch it | 07:30 |
| indu | could some one tell me, how to do it | 07:30 |
| Odd_Bloke | indu: Can you access other things via that IP address? | 07:34 |
| AfC | pattern: yes, go ahead and file the bug. The powers that be can make their mind up about how to deal with such a corner case if it actually exists. | 07:35 |
| indu | Odd_Bloke, yes | 07:35 |
| Odd_Bloke | indu: Can you access other Apache-served things via that IP address? | 07:36 |
| poolie | pattern, it's possible that it has hook scripts you might want to keep for historical interest | 07:36 |
| poolie | or just to be completest | 07:36 |
| poolie | ist? | 07:36 |
| indu | Odd_Bloke, yes i am able to access | 07:36 |
| poolie | lifeless, were you wanting "thousands of deletes" for 0.92 | 07:36 |
| Odd_Bloke | indu: Are you running it on a different port? | 07:36 |
| indu | Odd_Bloke, yes, logggerhead is running in port 8220 | 07:37 |
| lifeless | poolie: I think its small and safe; | 07:37 |
| indu | and apache in 8080 | 07:37 |
| fullermd | I expect you could use .bzrignore (probably only in the form of ~/.bazaar/ignore) to ignore CVSROOT in a given case if you wanted to. | 07:37 |
| Odd_Bloke | indu: Any chance that 8220 is blocked somewhere? | 07:37 |
| lifeless | poolie: until nDuff reports on performance I don't know if its enough or not, but I think it probably is. | 07:37 |
| poolie | spiv, igc, could either of you read that patch if you're free? | 07:37 |
| indu | Odd_Bloke, no, this is a simple lan that i am checking in | 07:38 |
| poolie | igc, did you do some user docs for packs, or is that what you're doing now? | 07:38 |
| indu | Odd_Bloke, is it possible to make loggerhead and apache to use the same port | 07:38 |
| igc | doing now | 07:38 |
| poolie | cool | 07:38 |
| indu | as this port blocking problem may come when i implement it for internet access | 07:38 |
| igc | also tweaks to bzr+sssh patch | 07:38 |
| Odd_Bloke | indu: I don't know, that's the extent of my ideas/knowledge on the subject. :p | 07:38 |
| igc | poolie, lifeless: pack renaming patch sent to pqm 10 minutes back | 07:39 |
| pattern | poolie, i guess that's possible... in which case you could just rename it to something else | 07:39 |
| pattern | perhaps cvsps-import could ask the user whether to delete $CVSROOT/CVSROOT, with a default of yes | 07:39 |
| Odd_Bloke | A switch to the call would be better, to avoid breaking automation. | 07:40 |
| spiv | igc: I'm really happy to see that bzr+ssh bug fixed, btw. | 07:40 |
| poolie | me too | 07:40 |
| igc | spiv: any feedback on the tests? | 07:40 |
| spiv | igc: I'll take a closer look now and let you know. | 07:40 |
| igc | poolie thought you might have some | 07:40 |
| poolie | some? | 07:41 |
| * poolie reparses | 07:41 | |
| poolie | oh, right | 07:41 |
| pattern | yeah, you could have a switch too... and something in the README warning that $CVSROOT/CVSROOT will be deleted by default | 07:41 |
| poolie | igc, i meant to say, a better way to test the exceptions would be | 07:41 |
| poolie | take the return code from assertRaises, which is the exception object | 07:41 |
| poolie | coerce it to a string and check it's reasonable | 07:42 |
| igc | ah - ok | 07:42 |
| poolie | this gives better coverage - makes sure it's constructed the right way in the place it's raised | 07:42 |
| poolie | (this is an enhancement to assertRaises in bzrlib, it's useful) | 07:42 |
| igc | yeah | 07:42 |
| igc | poolie: instead of 'connection timeout', is 'connection closed' clear enough? | 07:43 |
| poolie | yes | 07:43 |
| spiv | igc: +1 for 'connection closed' | 07:43 |
| indu | mwhudson, hi, this is indraveni | 07:44 |
| igc | and is a case for setting orig_error to something while construction those exceptions? | 07:44 |
| igc | s/is/is there/ | 07:44 |
| pattern | ok... i'm going to sleep... thanks for your help everyone! | 07:48 |
| pattern | bug filed | 07:48 |
| ubotu | New bug: #156974 in bzr "cvsps-import imports $CVSROOT/CVSROOT" [Undecided,New] https://launchpad.net/bugs/156974 | 07:56 |
| lifeless | poolie: replied to you | 07:58 |
| spiv | igc: I have some comments; I'm sending them to the list. | 08:00 |
| igc | thanks spiv | 08:00 |
| igc | lifeless: can you please do an email to everyone re changing the file on disk once the rename patch lands? | 08:08 |
| igc | you know exactly what to say ... | 08:08 |
| igc | and the masses will most likely expect it from you rather than me | 08:08 |
| mdke | morning all. I'm looking for some tips on setting up a shared repository to manage history for a number of branches which I'd like to bind to launchpad | 08:08 |
| mdke | I tried the command in the CentralizedWorkflows page and then "bzr branch" and received this error: | 08:09 |
| igc | in particular, the timing is important I guess: pull bzr.dev, then edit the file? | 08:09 |
| mdke | bzr: ERROR: Repository KnitRepository('file:///home/matt/ubuntu/ubuntu-doc/.bzr/') is not compatible with repository KnitRepository3('http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/.bzr/') | 08:09 |
| mdke | oh, it's just a stupid command, I apologise | 08:11 |
| mdke | damn, I still get it | 08:12 |
| Odd_Bloke | mdke: What command are you running? | 08:13 |
| mdke | Odd_Bloke: http://paste.ubuntu-nl.org/42052/ | 08:13 |
| fullermd | It's -with-subtrees, you're not. | 08:14 |
| mdke | fullermd: how can I fix that? | 08:15 |
| fullermd | Well, you can upgrade your existing repo (I'd be leery of that if you have other branches in it, though), or create a new one in -with-subtrees format. | 08:15 |
| spiv | igc: sent. | 08:16 |
| igc | thanks | 08:16 |
| mdke | there aren't any other branches, I just created the repo in the line above (see pastebin) | 08:16 |
| fullermd | Well, then just upgrade --format=dirstate-with-subtrees should do it. | 08:17 |
| mdke | is there a way to do that when creating the repo in the first place? | 08:18 |
| fullermd | init-repo has a --format option too. | 08:18 |
| mdke | ok. Would it be useful to add this information to SharedRepositoryTutorial, do you think? | 08:19 |
| mdke | hmm. bzr: ERROR: Bad value "dirstate-with-subtrees" for option "format". | 08:19 |
| fullermd | Maybe it's singular 'subtree'... | 08:19 |
| * fullermd quickly looks aroudn to see if abentley is lurking, ready to pounce... | 08:20 | |
| mwhudson | it's singular yes | 08:20 |
| mwhudson | i always make that mistake | 08:20 |
| mdke | morning mwhudson :) | 08:20 |
| * mwhudson rubs his bleary eyes | 08:20 | |
| fullermd | We really want to keep -with-subtree in the closet... | 08:20 |
| mdke | mwhudson: you and me both | 08:20 |
| mdke | fullermd: it works now, thanks | 08:20 |
| mdke | but I'd like to recommend to the whole team to use a shared repository when getting these branches because they are so similar, so I'll need to remember that command | 08:21 |
| fullermd | Well, you'd want to give that in your instructions, yah. | 08:23 |
| fullermd | But putting it up on the official docs would... well, it would be a good way to attract attention to yourself :] | 08:23 |
| fullermd | See enthusiastic discussion last week on bug 131667 | 08:24 |
| ubotu | Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667 | 08:24 |
| * mdke looks | 08:25 | |
| mdke | ah, that's why it is enabled in the LP branch, because it was created with bzr-svn | 08:26 |
| mdke | fullermd: would it have been better to remove it from the branch than to add it to the repository? if it is experimental? | 08:26 |
| fullermd | Well, you can't [readily] remove it from the branch. That's the biggest "oomph" with the format; it's a 1-way change. | 08:27 |
| mdke | damn | 08:28 |
| mdke | "the format enables dangerous | 08:28 |
| mdke | behavior | 08:28 |
| mdke | " | 08:28 |
| * mdke is scared | 08:28 | |
| fullermd | I'd try not to get TOO freaked out over that. It can do "dangerous" and scary and undocumented things, but it won't turn your code into midget donkey pr0n. | 08:29 |
| fullermd | At least, not overnight. | 08:29 |
| mdke | what sort of things? | 08:29 |
| fullermd | Mmm. Now you're pushing the edge of my knowledge. It can end up creating by-reference nested trees sometimes. Maybe if an 'add' in one branch hits another branch underneath? | 08:29 |
| fullermd | And there's no commands or UI to do things with those trees, so I think you can end up in somewhat sticky situations. | 08:30 |
| fullermd | There's probably other stuff along similar lines. | 08:30 |
| mdke | if it's dangerous, I think what we would consider doing is deleting those branches and importing them in some other way than by using bzr-svn | 08:30 |
| fullermd | I _think_ if you don't put one tree inside another, there shouldn't be any other surprising side effects. But I don't really know. | 08:30 |
| mdke | mwhudson: got any tips about this issue? | 08:30 |
| mwhudson | mdke: sorry, not been tracking this conversation, can you summarize? | 08:31 |
| Odd_Bloke | jelmer: The above conversation would seem to be relevant to your interests. | 08:31 |
| spiv | mwhudson: bzr-svn requires a repository format that is marked experimental. | 08:31 |
| fullermd | abentley would be the best one to ask about it. I think LarstiQ knows the code a bit too, but he's not very around lately. jelmer might be able to tell you more too. | 08:32 |
| mwhudson | oh that | 08:32 |
| mwhudson | mdke: i don't really have any deep insight here | 08:32 |
| mwhudson | i've been using -with-subtree branches for a few things and they haven't eaten any babies or anything | 08:33 |
| Odd_Bloke | fullermd: I didn't want to ping abentley in case I had to face his nested-tree-related wrath. :p | 08:33 |
| fullermd | Odd_Bloke: That's why you do it now; it's the middle of the night for him. You can get him all wound up, and have time to get out of the country before he springs out ;) | 08:33 |
| spiv | mdke: basically, at the moment that repo format is a requirement for using bzr-svn | 08:33 |
| spiv | mdke: bzr-svn isn't exactly 1.0 software either ;) | 08:34 |
| spiv | mdke: so I wouldn't worry about it any more than I'd worry about using bzr-svn anyway. Just take care not to accidentally use that repository for other things. | 08:34 |
| mdke | spiv: what I'm slightly concerned about is starting out on the wrong foot. if in the long term this will all straighten itself out, then fine. If I can sidestep any future issues by using another tool to import the svn revisions, then I'd rather do that now than later because it won't be possible later | 08:36 |
| mdke | does that make sense? | 08:36 |
| spiv | mdke: Personally, I'd stick with bzr-svn. jelmer has done a good job so far of making sure that upgrades to newer versions of bzr-svn go smoothly, even as the new versions change how stuff is stored. | 08:37 |
| fullermd | mdke: As I said above, I _think_ if you avoid putting one branch inside another in your fs (or checkouts of the branches), none of the scary/automatic behavior will come into play. | 08:37 |
| mdke | i.e. if in 3 months the -subtree format is likely to be no longer experimental, then I'm happy | 08:37 |
| mdke | spiv / fullermd - ok, I'll take the advice, thanks | 08:38 |
| lifeless | igc: its 'edit .bzr/repository/format and put the text in there' | 08:42 |
| igc | lifeless: and timing? | 08:43 |
| lifeless | igc: I'm on the way out to a last night @ home dinner | 08:43 |
| igc | sure | 08:43 |
| lifeless | igc: well, pull the latest code first | 08:43 |
| igc | thanks | 08:43 |
| lifeless | so you have it on disk. Also note that *my* repository branch doesn't have this yet, so they need to pull/merge bzr.dev. | 08:43 |
| igc | have fun - see you next Wed | 08:43 |
| lifeless | my branches will be done late tonight, real early tomorrow morning | 08:43 |
| igc | ok | 08:43 |
| LarstiQ | mdke: I wouldn't be too worried. | 09:06 |
| poolie | igc, did you send the ssh fix? | 09:11 |
| igc | not yet - still making spiv's tweaks | 09:12 |
| Kinnison | Morning | 09:22 |
| indu | mwhudson, hi | 09:23 |
| mwhudson | indu: hello | 09:23 |
| indu | mwhudson, this is indraveni | 09:23 |
| indu | mwhudson, i am able to create much more branches and view through the loggerhead | 09:24 |
| indu | mwhudson, but now the problem is, remotely i am not able to see | 09:24 |
| indu | if i am using my system ip in the url, its not woring | 09:24 |
| indu | *working | 09:24 |
| mwhudson | this is probably mostly a question about apache | 09:24 |
| indu | mwhudson, in the loggerhead conf file, it should be always localhost or any | 09:25 |
| mwhudson | the server.webpath entry? | 09:25 |
| indu | yes its apache question, but ther sites in this apache server, are well accessed remotely except the loggerhead | 09:25 |
| igc | poolie: just retesting that bzr+ssh change now | 09:25 |
| indu | mwhudson, yes | 09:26 |
| poolie | spiv, i'm reading the reconcile patch | 09:26 |
| mwhudson | indu: it should be the url you use to access loggerhead | 09:26 |
| mwhudson | indu: the "outside name", that is | 09:26 |
| indu | mwhudson, ip address:port? | 09:26 |
| mwhudson | indu: probably | 09:27 |
| indu | mwhudson, and what about the other url's in the [project] and[[branch]] section ? | 09:27 |
| mwhudson | those are cosmetic only | 09:27 |
| indu | mwhudson, i have edited the server.webpath value but it doesn't seem to work | 09:28 |
| mwhudson | as i think i said several times yesterday | 09:28 |
| mwhudson | indu: have you read "how to ask smart questions" ? | 09:28 |
| indu | no | 09:28 |
| mwhudson | indu: could i ask you, politely, to be a little more respectful of my time? | 09:29 |
| mwhudson | so: "it doesn't work" --> bad | 09:29 |
| * igc food | 09:29 | |
| indu | mwhudson,sorry for that | 09:29 |
| mwhudson | "i can see the list of branches but clicking on a link to a branch gives a 404" --> better | 09:30 |
| indu | mwhudson, ok. i made my server.webpath value to ip:port what about my apache conf, is the conf here correct ? http://pastebin.ca/748903 | 09:31 |
| * Lo-lan-do thinks it might be interesting to put something in branches without trees, so directory listings aren't empty | 09:32 | |
| Lo-lan-do | Something like an empty file called "this-is-a-bzr-branch.txt" | 09:33 |
| poolie | agree | 09:34 |
| Lo-lan-do | Or maybe not an empty file, but one which contains a minimalist explanation. | 09:34 |
| indu | mwhudson, in my loggerhead.conf fle, except the server.webpath value all others are localhost | 09:35 |
| Lo-lan-do | "This directory may look empty, especially if you look at it from the web, but you can still use it for "bzr branch http://..." operations" | 09:35 |
| Odd_Bloke | indu: You might want to try playing around with those values to find out if they do anything, rather than bothering mwhudson. | 09:36 |
| mwhudson | indu: ProxyPass http://localhost/ | 09:39 |
| mwhudson | you need the port number loggerhead is running on here | 09:39 |
| indu | mwhudson, and is that port in vhost is ok? its the port used by loggerhead and not apache | 09:42 |
| indu | so do i need to have port in line NameVirtualhost *:8220 and <VirtualHost *:8220> | 09:43 |
| mwhudson | oh, no, that should be the port apache listens on | 09:46 |
| indu | mwhudson, i have changed the necesasry values, but the error message saying, Page not found is displayed in the browser | 09:53 |
| indu | and the log says, internal dunny connection | 09:53 |
| mwhudson | "internal dunny connection" ? | 09:54 |
| indu | mwhudson i dont think that error is related to this, let us leave that point | 09:55 |
| indu | mwhudson, my loggerhead.conf file and apache configuration part is here http://pastebin.ca/748920 | 09:55 |
| indu | mwhudson, am i bothering u much ? if so very sorry for it | 09:55 |
| mwhudson | indu: well, you're reaching the limits of what i can help with | 09:57 |
| mwhudson | indu: i don't know that much about apache | 09:57 |
| mwhudson | indu: i can usually get it to work with enough fiddling, but that doesn't help get it set up on your machine | 09:57 |
| indu | mwhudson, which is ur OS ? | 10:00 |
| mwhudson | ubuntu] | 10:03 |
| indu | mwhudson, ubuntu and debian are same i think then there should notbe any problem with aoache confs, | 10:05 |
| indu | ur confs should wrok for me also | 10:05 |
| indu | which port is ur loggerhead using mwhudson | 10:06 |
| mwhudson | 8080 | 10:06 |
| indu | mwhudson, and ur apache ? | 10:06 |
| mwhudson | 80 | 10:06 |
| mwhudson | our configs are more complicated though, for reasons that aren't relevant here | 10:07 |
| indu | mwhudson, can u send me ur apache conf file, | 10:28 |
| mwhudson | indu: no. sorry | 10:28 |
| mwhudson | as i said, it's way more complicated than you need | 10:28 |
| indu | mwhudson, ok | 10:29 |
| fullermd | Oh joy, another round of the VCS discussion for pgsql. | 10:39 |
| weigon_ | jelmer: I ran into a new issue with bzr-svn: bzr: ERROR: changing lhs branch history not possible on repository root | 11:08 |
| weigon_ | on bzr push to the svn-repo | 11:08 |
| gabe | does bzr create a .bzrignore file in every branch? I thought it was only supposed to in the home folder | 11:18 |
| spiv | gabe: you can define ignore patterns in a branch, as well as specifying ignore patterns per user. | 11:19 |
| gabe | oh | 11:19 |
| gabe | right | 11:19 |
| spiv | gabe: e.g. if a branch has a Makefile that produces .o files, you probably want a *.o ignore in that branch (although that's in the default patterns). | 11:20 |
| gabe | and it seems bzr wants to keep .bzrignore in the branches under revision control too | 11:20 |
| gabe | yeah | 11:20 |
| gabe | well i version control websites | 11:20 |
| gabe | they have folders called /upload/ which don't need versioning | 11:20 |
| gabe | so i think i need to edit bzrignore in my home | 11:20 |
| spiv | gabe: and if as a user I have an editor that makes *.BACKUP files or something, then that'd probably belong in my per-user ignores, rather than in the branch ignores. | 11:20 |
| spiv | Right, .bzrignore is versioned. | 11:21 |
| gabe | would I just write "upload" in to .bzrignore? | 11:21 |
| mwhudson | yay for 2942 | 11:22 |
| spiv | Being versioned like any other file makes dealing with merges (and conflicts) of changes straightforward to understand. | 11:23 |
| spiv | gabe: see "bzr help ignore" | 11:24 |
| mwhudson | spiv: can i talk to you about smart server terminology for a bit? | 11:24 |
| gabe | spiv: thanks very much | 11:25 |
| Kamping_Kaiser | hi all. i'm having trouble checking a project out of launchpad. i'm running bzr 0.18 (from backports.org) the error i get is this: | 11:34 |
| Kamping_Kaiser | kgoetz@wesnoth:~/public_html$ bzr branch http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/edubuntu-hardy | 11:34 |
| Kamping_Kaiser | bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/edubuntu-hardy/.bzr/repository/inventory.knit: Bad status line received | 11:34 |
| mwhudson | ouch | 11:36 |
| mwhudson | Kamping_Kaiser: does it fail quickly? | 11:38 |
| Kamping_Kaiser | mwhudson, no, but i'm downloading. i can stop the download and try again if it will help | 11:38 |
| mwhudson | Kamping_Kaiser: let me try it | 11:38 |
| spiv | mwhudson: ok | 11:38 |
| spiv | Kamping_Kaiser: do you have an HTTP proxy? | 11:39 |
| Kamping_Kaiser | spiv, yes | 11:39 |
| Kamping_Kaiser | dont know if bzr is using it or not | 11:39 |
| mwhudson | spiv: i've just found that bzrlib.smart has lots of docstrings :) | 11:39 |
| spiv | Kamping_Kaiser: it's quite possibly the HTTP proxy not liking the Range: request bzr sends. | 11:39 |
| spiv | mwhudson: hooray :) | 11:39 |
| mwhudson | spiv: so i should probably read those first | 11:39 |
| spiv | mwhudson: are they any good? ;) | 11:39 |
| mwhudson | spiv: dunno, the first one is broken reST | 11:40 |
| Kamping_Kaiser | spiv, is there a way i can test wether bzr goes through the proxy? | 11:40 |
| mwhudson | so i'll fix that, at least... | 11:40 |
| spiv | Kamping_Kaiser: I think new bzr's might detect that problem and fallback to a safer method, so you could try upgrading. | 11:40 |
| spiv | Kamping_Kaiser: vila would know more, if he were around... | 11:40 |
| mwhudson | spiv: the grammar is iffy | 11:40 |
| spiv | Kamping_Kaiser: I'm fairly sure bzr respects the http_proxy environment variable. | 11:41 |
| Kamping_Kaiser | spiv, i dont see any bzr hits in the proxy cache | 11:41 |
| Kamping_Kaiser | dont think its set | 11:41 |
| Kamping_Kaiser | hm. $http_proxy is set, but i dont see anything for 'bazaar.launchpad' in my proxy cache | 11:42 |
| spiv | mwhudson: is this bzrlib/smart/__init__.py? That docstring is one of those "braindumps that got tidied a bit" docstrings. | 11:43 |
| Kamping_Kaiser | i'm sorry, i stand corrected. bzr connects are being intercepted by http-replicator. (checked the log). | 11:43 |
| mwhudson | spiv: yes | 11:43 |
| * Kamping_Kaiser hangs around incase vila shows up | 11:44 | |
| mwhudson | spiv: i'm in one of those situations where the code changes i want took me, ooh, 15 minutes | 11:44 |
| mwhudson | spiv: and working out where to plug in the tests has taken over a day so far :) | 11:44 |
| spiv | Heh. | 11:44 |
| mwhudson | spiv: this is for https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/93606 | 11:45 |
| ubotu | Launchpad bug 93606 in launchpad-bazaar "Better reporting of codeshosting permission errors" [High,Confirmed] | 11:45 |
| spiv | mwhudson: if it weren't dinner time, I'd be more inclined to talk it over ;) | 11:45 |
| mwhudson | spiv: fair enough | 11:45 |
| mwhudson | spiv: i can beat the details out of jml and you in person soon enough | 11:45 |
| mwhudson | spiv: quickly: | 11:46 |
| spiv | mwhudson: part of the difficulty here is that ideally we'd rework the error handling significantly. | 11:46 |
| spiv | mwhudson: poolie filed a bug outlining the basic plan; at the moment the error serialisation/deserialisation is a bit ad hoc. | 11:46 |
| mwhudson | spiv: is the an overview document of the architecture of launchpad's codehosting service | 11:46 |
| mwhudson | spiv: at the moment in my branch this is what the user sees https://pastebin.canonical.com/716/ :) | 11:47 |
| mwhudson | (apologies for the private url) | 11:47 |
| spiv | mwhudson: not that I know of. There are various half-formed specs around, of varying obsoleteness ;) | 11:47 |
| mwhudson | spiv: hooray | 11:47 |
| spiv | mwhudson: ugh | 11:47 |
| spiv | mwhudson: it would be good to improve that error :) | 11:48 |
| * spiv -> food | 11:48 | |
| mwhudson | bzr: ERROR: Generic bzr smart protocol error: Permission denied: 'ERROR: new row for relation ...' possibly is over it's colon quota | 11:48 |
| mwhudson | spiv: it beats <Fault 8002 ''> | 11:48 |
| mwhudson | spiv: enjoy your food | 11:48 |
| jelmer | weigon_: That is intended behaviour | 11:49 |
| jelmer | weigon_: you can't push changes that change the lhs revision history to the root of the subversion repository | 11:50 |
| weigon_ | was this the rebase ? | 11:50 |
| jelmer | weigon_: As a workaround, you can use either rebase or push to a path that is not the root, such as /trunk | 11:51 |
| weigon_ | how can I see which changeset it is complaining about ? | 11:52 |
| weigon_ | $ bzr push --verbose doesn't add anything extra | 11:52 |
| jelmer | I'll make it a bit more verbose, one sec | 12:00 |
| ubotu | New bug: #157017 in bzr-eclipse "steppenwolf.selfip.net down -> -install eclipse plugin" [Undecided,New] https://launchpad.net/bugs/157017 | 12:00 |
| === kiko-zzz is now known as kiko | ||
| eoin | Hello all; I'm trying to track down some strange behaviour that I suspect is being caused by my web server: I've pushed a branch to a remote server via sftp, this branch is then served publicly. When I try to branch locally from this remote version bzr complains the checkout/format is being being redirected. There is no checkout on the server. My question is; does bzr check for the presence of this file as part of the branching process? | 12:11 |
| eoin | i.e. if my webserver was sending a 404 for the request of checkout/format, does bzr interpret this as a treeless branch? | 12:12 |
| spiv | eoin: right, if there's no checkout, then .bzr/checkout/format should not be there, which in HTTP terms means 404. | 12:13 |
| spiv | eoin: although I wouldn't expect "bzr branch" to care if there's a checkout or not though. | 12:14 |
| fullermd | Certainly not over sftp. | 12:16 |
| fullermd | I didn't think it even checked for a tree. | 12:16 |
| eoin | The exact error I see is as a result of "bzr branch http://example.org/bzr/project" is: "bzr: ERROR: http://example.org/bzr/project/.bzr/checkout/format is permanently redirected to /bzr/project/.bzr/". | 12:17 |
| eoin | My webserver is indeed redirecting instead of sending a 404 (I'm using cherokee). | 12:17 |
| eoin | Time to try apache methinks | 12:18 |
| eoin | This is bzr version 0.90.0 | 12:18 |
| fullermd | I hate servers that do that... | 12:19 |
| eoin | Yeah, it's pretty annoying. | 12:20 |
| ubotu | New bug: #157026 in bzr "bzr log --short/--line does not show committer if it has only e-mail" [Undecided,New] https://launchpad.net/bugs/157026 | 12:21 |
| jelmer | mdke: Fixed | 12:22 |
| ubotu | New bug: #157027 in bzr "bzr push/pull/missing: branches are diverged message should be improved for completely unrelated branches" [Low,Confirmed] https://launchpad.net/bugs/157027 | 12:26 |
| jelmer | s/mdke/weigon_/ | 12:32 |
| weigon_ | I'll bzr up and try again | 12:32 |
| igc | night all | 12:34 |
| weigon_ | bzr: ERROR: Unable to push revision 'jan@kneschke.de-20071023184229-d6h68lxxdgjxv6jj' because it would change the ordering of existing revisions on the Subversion repository root. Use rebase and try again or push to a non-root path ... looks better | 12:34 |
| weigon_ | jelmer: new problem :) | 12:40 |
| weigon_ | basicly it is the old problem again | 12:41 |
| jelmer | weigon_: what, the error message you mean? | 12:41 |
| jelmer | I've just clarified it | 12:41 |
| weigon_ | bzr: ERROR: libsvn._core.SubversionException: ("File already exists: filesystem '/svnroot/mysql-proxy/db', transaction '269-1', path '/trunk/tests/suite/base/r/query_analizer1.result'", 160020) | 12:41 |
| weigon_ | after the rebasing the svn-bzr tree, I could push again and it gave me this errormsg | 12:41 |
| weigon_ | is latest bzr-svn | 12:42 |
| jelmer | was this the same tree you had problems with earlier, pushing? | 12:42 |
| weigon_ | yes | 12:42 |
| weigon_ | r269 is not marked as "missing" in $ bzr missing --show-ids anymore | 12:43 |
| weigon_ | let me paste the backtrace | 12:44 |
| weigon_ | jelmer: http://p.caboo.se/110758 | 12:44 |
| Kamping_Kaiser | spiv, i set the http_proxy to '' for this run of bzr, and its working, so its definiately somethign to do with the proxy | 12:48 |
| jaavaaguru | Hi. We're trialling using Bazaar in place of SVN at work, and some people are asking about diff utility support on Windows | 12:48 |
| jaavaaguru | Can anyone recommend a graphical diff program that works on WIndows and with Bazaar? | 12:49 |
| jaavaaguru | We use CruiseControl.NET, and I have written a plugin for it which allows Bazaar to work with CC.NET: http://www.sorn.net/projects/bazaar-ccnet/ | 12:50 |
| jaavaaguru | There is a launchpad project linked from there if anyone's interested | 12:50 |
| spiv | jaavaaguru: I think the bzr-gtk plugin has a graphical diff in it | 12:52 |
| jaavaaguru | spiv: that only appears to be able to diff between the working tree and the branch you're on | 12:52 |
| spiv | Kamping_Kaiser: Interesting. I guess you can workaround it. | 12:52 |
| Kamping_Kaiser | spiv, yeah. is it a bug in bzr or the proxy? i'm guessing the proxy? | 12:53 |
| jaavaaguru | We have bzr-gtk running on a few machines here and being able to diff things other people have committed or merged would be handy | 12:53 |
| spiv | jaavaaguru: I use "bzr viz" for that sort of thing sometimes (also part of bzr-gtk) | 12:53 |
| spiv | Kamping_Kaiser: a bit of both, iirc ;) | 12:54 |
| jaavaaguru | thanks, I'll have a look at that | 12:54 |
| Kamping_Kaiser | spiv, ok :) | 12:54 |
| spiv | Kamping_Kaiser: The proxy is rejecting a perfectly reasonable HTTP request, but rejecting it is possibly reasonable too... I'm not an HTTP guru. | 12:54 |
| Kamping_Kaiser | spiv, ok. not my area (TM) | 12:55 |
| spiv | Kamping_Kaiser: but I believe newer versions of bzr gracefully notice that error and fallback to a method that should always work. | 12:55 |
| Kamping_Kaiser | spiv, guess i'll use work arounds until the updated versions hit debian backports | 12:56 |
| spiv | Kamping_Kaiser: hmm, although I according to the NEWS file, the fix I'm thinking of was in 0.18rc1 | 12:56 |
| jaavaaguru | spiv: viz seems more of a graphical log/branch viewer than a tool for viewing differences between revisions, unless I'm missing something | 12:56 |
| spiv | Kamping_Kaiser: and you're running 0.18, I think? | 12:56 |
| Kamping_Kaiser | spiv, i belive so. | 12:56 |
| spiv | jaavaaguru: it can show you the differences between revisions. | 12:56 |
| spiv | jaavaaguru: but only between direct parents atm, I think :/ | 12:57 |
| Kamping_Kaiser | spiv, Bazaar (bzr) 0.91.0 (so bzr in backports has been updated in the last 30~ hours) | 12:57 |
| spiv | jaavaaguru: there's probably a feature request worth making there... ;) | 12:57 |
| jaavaaguru | aha | 12:57 |
| jaavaaguru | I'll play around with it and see how I get on... may make a feature request later | 12:58 |
| spiv | jaavaaguru: and obviously it's not so helpful for comparing two diverged branches, but if you've already merged something in and just want to examine the history, it's a very good start. | 12:58 |
| fullermd | bzr-gtk has a 'gdiff'... | 12:58 |
| fullermd | It takes a -r which I presume works just like diff's -r. | 12:58 |
| jaavaaguru | it does seem quite handy. Is there a way to let it use an external diff tool? | 12:59 |
| jaavaaguru | Also, being a mixed linux/solaris/windows team, we're having issues with line endings being a mixture of \r\n and \n... merging doesn't handle this too well... is that worth a feature request too? | 13:00 |
| lifeless | jaavaaguru: cool that you've done a plugin for cc.net | 13:00 |
| weigon_ | jelmer: I just uncommitted all the broken revisions and will merge them again | 13:03 |
| jelmer | weigon_: merging won't help, you'll have to recommit them | 13:06 |
| mwhudson | bzr send is nice | 13:13 |
| mwhudson | fullermd: what's "SS" ? | 13:14 |
| mwhudson | smart server? | 13:14 |
| fullermd | Yah. | 13:14 |
| weigon_ | jelmer: what shall I do ? | 13:18 |
| weigon_ | I somehow have to get over this hump | 13:18 |
| jelmer | weigon_: Yes, indeed. How much revisions do you have after r269? | 13:18 |
| weigon_ | I uncommitted them in the bzr-svn branch and its related bzr branch, but still have them available in the other child to recommit | 13:19 |
| jelmer | weigon_: If you now create a clean copy of the svn branch (different repository), you should be able to commit and push them again | 13:20 |
| jelmer | without merging/pulling from the original branch | 13:20 |
| weigon_ | jelmer: stupid question: I just check out the svn tree with bzr branch ... mysql-proxy-svn-2 or shall I move the old tree away instead ? | 13:44 |
| weigon_ | jelmer: I wonder about how the other related branches will get aware of the new branch otherwise | 13:44 |
| jelmer | weigon_: No, they all contain the same data | 13:45 |
| jelmer | weigon_: so how you call it shouldn't be relevant | 13:45 |
| weigon_ | just that $ bzr info on the child-branches points to the broken branch | 13:46 |
| weigon_ | is there a bzr switch or something like that ? | 13:46 |
| weigon_ | or just pull --remember on the child branch ? | 13:47 |
| fullermd | I occasionally wish to be able to do that without it actually trying to pull. I usually fake it by sticking my grubby fingers in the branch.conf and doing it manually... | 13:49 |
| weigon_ | jelmer: trying to branch, but now it the clean branching breaks with: bzr: ERROR: exceptions.StopIteration: ... | 14:02 |
| weigon_ | jelmer: http://p.caboo.se/110773 | 14:03 |
| === bigdo1 is now known as bigdog_ | ||
| === bigdog is now known as bigdog1 | ||
| === bigdog1 is now known as bigdog | ||
| spiv | mwhudson: thanks for the docstring patch | 14:44 |
| mwhudson | spiv: np | 14:45 |
| mwhudson | spiv: thanks for the docstrings in the first place :) | 14:45 |
| mwhudson | spiv: my next trick is working what lp's bzr+ssh does differently :) | 14:46 |
| mwhudson | s/working/working out/ | 14:46 |
| === mthaddon_ is now known as mthaddon | ||
| === cprov is now known as cprov-lunch | ||
| === mrevell is now known as mrevell-biab | ||
| === mrevell-biab is now known as mrevell | ||
| gabe | hi all | 16:31 |
| gabe | there is a file that was delete from my bzr branch several revisions ago, how might i go about recovering it? | 16:31 |
| jam-laptop | bzr revert -r -10 filename | 16:32 |
| gabe | ohhh | 16:33 |
| gabe | is there a way of browsing what files existed at a certain revision? | 16:33 |
| gabe | or do i need to checkout that revision to browse them? | 16:33 |
| jam-laptop | bzr inventory -r XXX | 16:33 |
| jam-laptop | or bzr ls | 16:33 |
| uws | bzr help inventory | 16:33 |
| gabe | ha! | 16:33 |
| jam-laptop | but I'm not sure if ls supports --revision | 16:33 |
| gabe | wow | 16:33 |
| gabe | didn't know about this one | 16:33 |
| uws | jam-laptop: what is exactly the difference between inventory and ls? | 16:34 |
| jam-laptop | uws: 'ls' is meant to be "the way of the future" :) | 16:35 |
| jam-laptop | At the moment it supports a few more arguments that are helpful when scripting | 16:35 |
| jam-laptop | like "bzr ls --null" | 16:35 |
| jam-laptop | bzr ls --null | xargs -0 ... | 16:35 |
| gabe | how does one use the --kind switch for bzr inventory? | 16:43 |
| jam-laptop | bzr inventory --kind=file | 16:43 |
| jam-laptop | bzr inventory --kind=directory | 16:43 |
| jam-laptop | bzr inventory --kind=symlink | 16:43 |
| gabe | ahhh | 16:43 |
| jam-laptop | (print out all files, all directories, all symlinks, respectively) | 16:43 |
| gabe | and how could you make it show only the items from the pwd rather than recursively? | 16:44 |
| jam-laptop | I don't think inventory has that switch | 16:44 |
| jam-laptop | 'bzr ls' does | 16:44 |
| fullermd | --kind is easy; it's --sadistic and --short-tempered that get tough to manage. | 16:44 |
| gabe | mm | 16:44 |
| jam-laptop | You might try "bzr inventory ." | 16:44 |
| jam-laptop | gabe: "." does it | 16:45 |
| gabe | aha bzr ls | 16:45 |
| gabe | jam-laptop: that did it but recursively from the pw | 16:45 |
| gabe | PWD | 16:45 |
| gabe | perhaps bzr ls is better | 16:45 |
| jam-laptop | ah, rather than recursively | 16:45 |
| jam-laptop | bzr inventory . | grep -v "/" | 16:46 |
| gabe | but | 16:46 |
| jam-laptop | :) | 16:46 |
| gabe | bzr ls | 16:46 |
| gabe | says it has an option for non-recursive | 16:46 |
| jam-laptop | gabe: correct, "bzr ls --non-recursive" only prints out the entries in the current directory | 16:46 |
| jam-laptop | at least, it works that way here | 16:46 |
| gabe | yup | 16:46 |
| gabe | and here | 16:47 |
| gabe | i knew I could use grep | 16:47 |
| gabe | but that seemed a bit hackish | 16:47 |
| gabe | if bzr had it internally | 16:47 |
| jam-laptop | well, there is the Unix philosophy of having tools do limited things individually, but do more when combined. | 17:00 |
| jam-laptop | But there is usually a balance to be struck | 17:01 |
| jam-laptop | Obviously we struck it differently for "bzr inventory" versus "bzr ls" :) | 17:01 |
| luks | which doesn't work well if you are not on unix :) | 17:01 |
| gabe | mmm | 17:01 |
| gabe | bzr ls is gorgeous | 17:01 |
| gabe | like timemachine for leopard | 17:01 |
| gabe | but with a CLUI | 17:02 |
| uws | We should have a bzr-fuse fs | 17:11 |
| uws | with read-only revision-123 directories and such ;) | 17:11 |
| === cprov-lunch is now known as cprov | ||
| gabe | wow | 17:13 |
| gabe | when is that set to become available? | 17:13 |
| uws | gabe: never? ;) | 17:26 |
| gabe | gah | 17:26 |
| gabe | mmm | 17:26 |
| jam-laptop | gabe: whenever someone decides to write it. I don't know of anything in the works. | 17:26 |
| jam-laptop | And *I* don't know Fuse :) | 17:27 |
| gabe | i might be able to hack out a simple ruby script to do something similar | 17:27 |
| gabe | but not using fuse | 17:27 |
| jam-laptop | You would probably find doing it in python easier, just because we have a very rich bzrlib there. | 17:27 |
| gabe | prob | 17:27 |
| gabe | but i can't use python | 17:27 |
| gabe | i just don't get along with it | 17:27 |
| Alien_Freak | does bzr have an equivalent to svn's hooks, mostly just care about email commit logs to list | 17:38 |
| fullermd | Alien_Freak: There are hooks that can be run at commit time. They currently only run locally, though; not on the server, if you're working like that. | 17:40 |
| === mw|out is now known as mw | ||
| Alien_Freak | hmm.. but then each client would need either to bind to an smtp server or have their own mailserv... well, still haven't hammered down our layout for bzr yet.. so not sure yet | 17:41 |
| fullermd | Somebody wrote a hookless-mail thing. I think it sits around getting run via cron and sending out mails for stuff it hasn't seen yet. That may work. | 17:42 |
| jelmer | re | 18:09 |
| jelmer | weigon_, You need the patch I posted to the bzr mailing list today | 18:09 |
| jelmer | weigon_: sorry about that | 18:10 |
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| ubotu | New bug: #157145 in bzr-eclipse "Dont check untracked files in commit window by default" [Undecided,New] https://launchpad.net/bugs/157145 | 18:16 |
| besonen_pidgin | is there a portable version of bazaar for windows available? | 18:25 |
| jelmer | besonen_pidgin, yes, it should be linked from the website | 18:25 |
| besonen_pidgin | thanks jelmer, i'll take a look. | 18:28 |
| rif_ | hi, guys how can I apply a bundle? | 19:16 |
| luks | bzr pull or bzr merge | 19:17 |
| rif_ | ok, thanks it worked | 19:20 |
| rif_ | I hava 0.90 but help merge did not mentioned anything about it | 19:20 |
| lifeless | pyfuse is kindof nice | 19:27 |
| jam-laptop | lifeless: don't you ever sleep? | 19:38 |
| jam-laptop | (Are you getting ready for flying, or is poolie leaving before you) | 19:38 |
| === mrevell is now known as mrevell-dinner | ||
| besonen_pidgin | jelmer: the closest thing to portable installer i could find was a "stand-alone" installer at http://bazaar-vcs.org/WindowsDownloads | 20:08 |
| jelmer | besonen_pidgin: what exactly do you mean by portable? | 20:08 |
| besonen_pidgin | jelmer: meaning it can be installed on removeable media and used on any computer. like these apps: http://portableapps.com/ | 20:10 |
| jelmer | besonen_pidgin: The resulting directory of any of the installers should be portable afaik | 20:10 |
| jam-laptop | jelmer: well, if you use the python installer, you have to have python installed. | 20:10 |
| jam-laptop | The Standalone one should be fully portable, afaik | 20:10 |
| jam-laptop | once it is installed | 20:11 |
| lifeless | jam-laptop: I leave here in 50 minutes | 20:11 |
| luks | but the config can be only in the home dir, no? | 20:11 |
| jam-laptop | luks: you can set BZR_HOME if you want it somewhere else | 20:11 |
| luks | oh | 20:11 |
| jam-laptop | lifeless: have a safe trip, I look forward to whatever you manage to hack up | 20:12 |
| lifeless | jam-laptop: also, 'sleep is for the weak' | 20:12 |
| jam-laptop | Sometimes I think you travel internationally just for the hacking time. :) | 20:12 |
| lifeless | :) | 20:13 |
| lifeless | in the journalled inv thread | 20:13 |
| nDuff | lifeless: now at 4m25s for the first incremental commit (vs 1m29s on recommit). | 20:13 |
| lifeless | nDuff: ok, so theres still a glitch | 20:14 |
| lifeless | nDuff: another callgrind please :) | 20:14 |
| lifeless | nDuff: I think the different is that when you uncommit the working tree is not being reset, so it knows that the deletes have already occured. | 20:14 |
| lifeless | nDuff: what would a 'good time' be for you for the incremental commit? Obviously we'll keep addressing the problem, but I'm curious when it moves from 'damn' to 'ok' for you | 20:15 |
| nDuff | lifeless: I think it's already done that, really. | 20:16 |
| besonen_pidgin | thanks jelmer and jam-laptop | 20:16 |
| lifeless | nDuff: oh wow, cool. | 20:16 |
| lifeless | nDuff: anyhow, I'm on a plane for the next 24 hours or so | 20:17 |
| lifeless | nDuff: but drop me a callgrind of it and I'll see what I can do once I'm back on the ground | 20:17 |
| jam-laptop | nDuff: so is that 4m25 down from 15m? | 20:17 |
| nDuff | jam-laptop: yes. | 20:18 |
| jam-laptop | nDuff: care to CC me on the callgrind? | 20:18 |
| nDuff | jam-laptop: sure. | 20:18 |
| james_w | I'm hacking on bzr-git some more, I have tried to fix the repo copy code to copy the file texts. However there is still a problem. | 20:19 |
| james_w | The last commit in git is a merge commit (I'm not sure if that is significant), and when it tries to build the working tree after copying it dies as the knit for a file doesn't include an entry for the last commit's id. | 20:20 |
| === AnMaster_ is now known as AnMaster | ||
| lifeless | james_w: have you looked at bzr-hg ? | 20:20 |
| james_w | I though that the file knits were only supposed to get an entry when the file was modified. | 20:21 |
| lifeless | james_w: have a look at repository.py, record_entry_contents in bzr.dev | 20:21 |
| jam-laptop | james_w: It is whenever metadata changes as well | 20:21 |
| jam-laptop | so if you have 2 branches which both modified a file | 20:21 |
| jam-laptop | then when it is merged, there should be an update | 20:21 |
| jam-laptop | (if 1 branch changes it, but not both, then there should not be a new entry) | 20:21 |
| lifeless | nDuff: I've just pulled across the latest code, this changes the disk label for packs. | 20:22 |
| lifeless | nDuff: well, its annotating now. give it a few secs | 20:22 |
| lifeless | theres a mail on the list from Ian about this | 20:22 |
| lifeless | or you can just nuke your test repositories. Also its now --knitpack-experimental | 20:22 |
| lifeless | though I'm not sure why it has the word knit in it. | 20:22 |
| james_w | jam-laptop: it is modified in the LCA and in the left hnd ancestor of the merge, but not in the right hand side or the merge itself. | 20:24 |
| jam-laptop | lifeless: presumably because we may have xdelta packs in the future | 20:24 |
| jam-laptop | or something other than knit-format deltas, etc. | 20:24 |
| lifeless | jam-laptop: well, sure, just shrug. | 20:24 |
| jam-laptop | I agree 'knit' may not be the best word, but we didn't have any other name for it | 20:25 |
| jam-laptop | I don't really like "knitpack" either | 20:25 |
| jam-laptop | but I don't have anything better | 20:25 |
| lifeless | '1' | 20:25 |
| lifeless | pack1-experimental | 20:25 |
| jam-laptop | Yeah, 'pack1-experimental' for nwo | 20:25 |
| jam-laptop | now | 20:25 |
| lifeless | care to mail the list and propose that? The disk format does not say knit, so this is purely ui | 20:25 |
| jam-laptop | I'll mention it at least | 20:25 |
| lifeless | thanks! | 20:26 |
| james_w | ah, so ie.revision should be an older revision if you are stealing that version's text? | 20:29 |
| james_w | that makes sense. | 20:29 |
| nDuff | lifeless: ...so do you want me to wait for that update, or send a callgrind against r2856? | 20:30 |
| jam-laptop | I don't think there were code optimizations for 2856, were there? | 20:32 |
| jam-laptop | just the format string change | 20:32 |
| lifeless | nDuff: callgrind now is fine | 20:32 |
| lifeless | jam-laptop: its against my repository branch | 20:32 |
| lifeless | nDuff: but 2857 is there now | 20:33 |
| lifeless | james_w: so - any mod to a file == new version in the knit per-file graph. | 20:34 |
| lifeless | james_w: if two versions of a file are merged == new version, even if its not a content change | 20:34 |
| lifeless | james_w: but if two versions are merged and and there is only one head, == not a new version | 20:34 |
| lifeless | james_w: which is why I suggested you read record_entry_contents, this is tricky to 'get' from just text, and the code is pretty clear | 20:35 |
| james_w | lifeless: yeah, that helped thanks. | 20:35 |
| james_w | it works no though, woo. | 20:35 |
| jam-laptop | lifeless: yeah, I'm just saying that 2857 in your repository branch doesn't add any performance changes | 20:36 |
| lifeless | ok, my pulblic pack repo is now in bzr.dev's pack disk format | 20:36 |
| jam-laptop | as it sounded like you had already merged all of them. | 20:36 |
| lifeless | yup | 20:36 |
| lifeless | I was just being clear | 20:37 |
| pattern | since bzr will not do keyword substitution within source files as they're committed, what's the right way to have a single source file (say, a one-file perl program) print out its version information to the user? | 20:46 |
| jam-laptop | bzr version-info --format=XXX > file.txt | 20:46 |
| jam-laptop | We have format=python | 20:47 |
| pattern | right | 20:47 |
| jam-laptop | and =rio | 20:47 |
| pattern | but i'd like to type "foo.pl --version" and get the version info | 20:47 |
| pattern | and that "foo.pl" file is just a single file | 20:47 |
| pattern | that would be copied to /usr/local/bin or whatever | 20:47 |
| pattern | it would be distributed with no other files | 20:47 |
| jam-laptop | foo.pl is the whole app? | 20:47 |
| pattern | yep | 20:47 |
| fullermd | You'd have to do some sed'ery in your distribution to cram the values into the script. | 20:47 |
| jam-laptop | I can imagine doing some perl hackery to get it to work | 20:48 |
| jam-laptop | Such as having a variable defined at the top | 20:48 |
| jam-laptop | which gets redefined at the bottom as part of a "make" step | 20:48 |
| pattern | but there is no make | 20:48 |
| jam-laptop | That is a bit ugly | 20:48 |
| pattern | still, i get the point | 20:48 |
| jam-laptop | pattern: well, as any sort of "build the final file" step | 20:48 |
| pattern | there's no way to do it with bazaar | 20:48 |
| jam-laptop | I'm sure it would be easier to do in Perl than in Makefile | 20:49 |
| jam-laptop | pattern: I can give you the whole discussion for why we don't support keyword expansion yet | 20:49 |
| pattern | yeah, i just read the thread on the list | 20:49 |
| jam-laptop | but generally the way CVS does it is *really* broken especially as you get into a distributed system | 20:49 |
| jam-laptop | SVN is significantly better in that regard | 20:49 |
| fullermd | The way CVS does it is really broken even for CVS. 's why my commit scripts collapse down the keywords on the way in. | 20:50 |
| mwhudson | subversion is still broken though | 20:50 |
| jam-laptop | mwhudson: I won't say SVN is perfect, just better than CVS :) | 20:50 |
| LeoNerd | That's debatable | 20:50 |
| jam-laptop | fullermd: oh definitely, I've done branch to branch merges with CVS, and it is pretty awful if you have any auto keywords | 20:50 |
| LeoNerd | I like the fact that branches and tags _actually_ exist in CVS | 20:50 |
| jam-laptop | LeoNerd: I was talking strictly about keyword expansion | 20:50 |
| LeoNerd | Ahh.. | 20:51 |
| jam-laptop | The branch and tag is probably the big complaint about svn versus cvs | 20:51 |
| jam-laptop | since they abuse a namespace | 20:51 |
| jam-laptop | rather than creating an orthogonal one | 20:51 |
| jam-laptop | for some it is more obvious | 20:51 |
| jam-laptop | for others more confusing | 20:51 |
| mwhudson | http://subversion.tigris.org/issues/show_bug.cgi?id=2783 | 20:51 |
| LeoNerd | It means you can't ask questions you'd like to | 20:52 |
| LeoNerd | "Who else has branched this?" | 20:52 |
| nDuff | okay, that's odd. | 20:52 |
| LeoNerd | "When's the latest RC tag on this file?" | 20:52 |
| pattern | anyway, i'd just like to make clear why automatic keyword substitution within source files would be useful | 20:52 |
| jam-laptop | nDuff: ?? | 20:52 |
| jam-laptop | mwhudson: oooh. | 20:52 |
| pattern | i write lots of (relatively) small, one-file scripts that i keep under version control | 20:52 |
| nDuff | on r2857, I just got 1m35s *with lsprof enabled* for that initial commit. | 20:52 |
| jam-laptop | mwhudson: But considering I can do "svn commit" and someone else can do "svn update" and get a different tree | 20:53 |
| jam-laptop | It seems $Id$ is a lot less of an issue :) | 20:53 |
| pattern | and it would just be nice to know what version a given script is, once it's out in the wild | 20:53 |
| jam-laptop | pattern: well, you have 1 advantage in that we have a revision id which is globally unique | 20:53 |
| jam-laptop | so you *can* embed that | 20:53 |
| jam-laptop | Just we don't prefer to munge your files in place | 20:53 |
| mwhudson | jam-laptop: well, maybe | 20:53 |
| mwhudson | i was still surprised by that one | 20:54 |
| jam-laptop | mwhudson: I actually remember discussing that one a long time ago. | 20:54 |
| jam-laptop | What was the specific reason? | 20:54 |
| mwhudson | it broke an import on launchpad | 20:54 |
| pattern | i understand (at least some of) the arguments for not having bazaar doing automatic keyword substitution | 20:54 |
| jam-laptop | Was it that files that didn't change on one side would get $3064$ | 20:55 |
| jam-laptop | and the other would get $3061$ (because they weren't updated) | 20:55 |
| pattern | but i think some users will lose out in terms of convenience and simplicity, when they actually do need keyword substitution | 20:55 |
| fullermd | pattern: I think the general concensus is "Yes, we'll do some variant of it, but not any time soon" | 20:55 |
| pattern | and there are certain situations, like mine, where keyword substitution is a valid need, imo | 20:55 |
| fullermd | At least, I hope that's still the general feel, 'cuz I'm too tired to run that argument again. | 20:56 |
| jam-laptop | fullermd: well, I get that feeling from: http://bazaar-vcs.org/KeywordExpansion | 20:57 |
| pattern | hey, i know, i'll just run bzr and RCS at the same time | 20:57 |
| pattern | and whenever i check in a file via bazaar, i'll also check it in via RCS | 20:57 |
| pattern | and then i'll get my version info :) | 20:57 |
| * fullermd bursts into tears. | 20:58 | |
| fullermd | I'm gonna have nightmares for a week just from reading that :( | 20:58 |
| LeoNerd | I have dual Arch/CVS trees at wrok | 20:58 |
| LeoNerd | *work | 20:58 |
| jam-laptop | LeoNerd: I had that, too | 20:58 |
| LeoNerd | I even use it to maintain two parallel sets of code | 20:58 |
| jam-laptop | But more so *I* could use one | 20:58 |
| lifeless | see some of you on the flip side | 20:58 |
| LeoNerd | CVS -> arch -> arch (different branch) -> CVS (different repo) | 20:58 |
| jam-laptop | and "upstream" used the other | 20:58 |
| * lifeless waves | 20:58 | |
| jam-laptop | lifeless: have a good trip | 20:59 |
| LeoNerd | It's fun having to move it back again | 20:59 |
| jam-laptop | lifeless: see you F2F real soon :) | 20:59 |
| lifeless | jam-laptop: cool! | 20:59 |
| jam-laptop | LeoNerd: ooh, multiple cvs repos even | 20:59 |
| jam-laptop | I haven't done that | 20:59 |
| LeoNerd | Well, same repo but different modules | 20:59 |
| LeoNerd | It's "old" vs. "new" code | 20:59 |
| jam-laptop | I did have 2 Arch branches (one for the exact upstream CVS, and the other for my changes, etc.) | 20:59 |
| LeoNerd | "old" is maintained on the live boxes, "new" is some stuff in development | 20:59 |
| LeoNerd | In CVS they're totally unrelated | 20:59 |
| LeoNerd | I use arch to backport new changes on dev into live, or bugfixes from live back to dev | 21:00 |
| jam-laptop | I guess Arch would handle cherry picking a bit better | 21:00 |
| jam-laptop | lifeless: well, I won't see you until next week, but still fairly soon | 21:02 |
| jam-laptop | :) | 21:02 |
| LeoNerd | Yeah.. I use the cherrypick a lot | 21:02 |
| LeoNerd | Occasional dev->live moves, but not all of it | 21:02 |
| LeoNerd | Which is largely the reason I'm not doing it in bzr | 21:02 |
| jelmer | g | 21:02 |
| james_w | bye lifeless. | 21:03 |
| jam-laptop | nDuff: do you have the callgrind file? | 21:40 |
| nDuff | jam-laptop: haven't been able to reproduce against r2857. | 21:49 |
| jam-laptop | I wonder if it was actually an incremental and you didn't realize it | 21:49 |
| nDuff | jam-laptop: It was explicitly an incremental ("<nDuff> lifeless: now at 4m25s for the first incremental commit (vs 1m29s on recommit).") | 21:51 |
| jam-laptop | nDuff: "nDuff: on r2857, I just got 1m35s *with lsprof enabled* for that initial commit." | 21:52 |
| nDuff | oops. | 21:52 |
| jam-laptop | maybe you meant incremental | 21:52 |
| nDuff | yes, I did. | 21:52 |
| nDuff | (mean "incremental" rather than "initial") | 21:53 |
| jajmon | hi, how do i start eclipse with -clean switch on mac osx (and what does it do?) | 21:56 |
| jajmon | (trying to get the bzr plugin to work) | 21:57 |
| beuno | jajmon, Verterok, the plugin developer isn't around right now | 22:08 |
| beuno | he's usually here a few hours ahead | 22:09 |
| beuno | you might want to file a bug or a question in Launchpad | 22:09 |
| weigon_ | jelmer: is the patch committed already ? | 22:09 |
| jelmer | weigon_: it's being processed for inclusion in bzr.dev right now (see http://pqm.bazaar-vcs.org/) | 22:10 |
| === kiko is now known as kiko-fud | ||
| === cprov is now known as cprov-afk | ||
| hunmonk | does anybody have an idea if/when the fink repository will be updated to the latest version of bzr? it has 0.18 right now | 22:18 |
| gotgenes | How does bzr svn-import work? | 22:26 |
| gotgenes | Do I need to have already done a bzr co of the SVN repo? | 22:27 |
| jam-laptop | gotgenes: I don't believe so | 22:35 |
| jam-laptop | I think you can just give it the svn url | 22:35 |
| jam-laptop | but I haven't done it myself | 22:35 |
| fullermd | I think if you've done a bzr co of the SVN repo, you don't need bzr svn-import ;] | 22:35 |
| jam-laptop | fullermd: well, svn-import can import all branches | 22:35 |
| jam-laptop | And I think it can work from an svn dump | 22:36 |
| jelmer | gotgenes: you can either give it a SVN repository URL or a dump file | 22:36 |
| jam-laptop | (though it does so by creating an svn repo, and loading the dump into it) | 22:36 |
| keir | abentley, ping | 22:41 |
| jam-laptop | mwhudson: ping | 22:55 |
| mwhudson | jam-laptop: pong-ish | 23:08 |
| jam-laptop | mwhudson: nm, I got my question answered on #launchpad | 23:10 |
| jam-laptop | Though I guess if you are here... | 23:10 |
| jam-laptop | Is it a really bad idea to upload a 400MB tarball as a project file? | 23:10 |
| jam-laptop | I'm trying to get a dev snapshot of a big repository uploaded | 23:10 |
| jam-laptop | so people don't have to download the 600+ MB of revision data | 23:10 |
| jam-laptop | (they can bootstrap from a shared repo) | 23:10 |
| mwhudson | jam-laptop: no idea, sorry | 23:12 |
| jam-laptop | np | 23:12 |
| cr3 | I'm getting the following error, what does it mean: bzr: ERROR: parent_id {main-20070417180124-c9x1bsweu2uhbgcr-86} not in inventory | 23:13 |
| abentley | keir: pong | 23:14 |
| keir | abentley, i'm trying to get cart going | 23:15 |
| keir | abentley, but i think there are some sqlalchemy 0.40 issues | 23:15 |
| abentley | I haven't tried it with 4. | 23:15 |
| cr3 | by the way, I'm using Bazaar (bzr) 0.17.0 | 23:15 |
| keir | abentley, i mailed you at panoramicfeedback.com | 23:15 |
| keir | abentley, basically, easy_install cheerfully installs 0.4.0, which is incompatible with the version of elixer that's installed. supposedly you need trunk elixir. so i got that, but there's still issues | 23:16 |
| abentley | I see it. Thanks. | 23:16 |
| cr3 | apparently, this happens for selective commits. so, I guess I won't do selective commits anymore | 23:17 |
| abentley | keir: Would you like a Cart account so that you can post bug reports directly? | 23:17 |
| keir | abentley, yes | 23:17 |
| abentley | What password would you like? | 23:18 |
| keir | abentley, user keir if possible | 23:18 |
| abentley | keir: It is done. | 23:19 |
| keir | abentley, great | 23:19 |
| abentley | cr3: A lot of work has been done to fix problems like that in recent releases. | 23:20 |
| keir | abentley, is it possible with setuptools to 'bake' a set of deps? the most annoying thing i find with the python web stuff is the tangle of dependencies | 23:21 |
| abentley | I'm not sure what you mean by bake. You can control versions pretty strictly, and you can provide your own copies of dependencies. | 23:24 |
| keir | abentley, yes, providing our own copy would be nice | 23:24 |
| keir | abentley, anyway, that's for later | 23:25 |
| keir | abentley, login with mierle@gmail.com? or keir? neither is working | 23:25 |
| abentley | keir | 23:25 |
| gotgenes | Is there any way to use bzr-svn when the SVN operations require a username and password? | 23:25 |
| abentley | I just tried it and it worked. | 23:26 |
| keir | oh weird | 23:26 |
| keir | i didn't see the login button | 23:27 |
| keir | so i clicked 'accounts' then 'keir mierle' | 23:27 |
| keir | it wanted me to login | 23:27 |
| keir | so i did | 23:27 |
| keir | it said 'bad login/pw' | 23:27 |
| keir | but if i nav back to main cart, i'm logged in (or so it says in the top corner) | 23:27 |
| keir | this is repeatable | 23:28 |
| keir | abentley, i have to run. i'll be back later. | 23:28 |
| abentley | keir: I should hide accounts if you don't have privs. | 23:29 |
| jelmer | gotgenes: Yes, connect to the repository first with the native svn client | 23:30 |
| igc | morning | 23:30 |
| gotgenes | jelmer: Thanks. Worked well. | 23:31 |
| gotgenes | jelmer: when I do an svn-import of the repo from the URL, it creates a directory within called trunk, but that directory is empty | 23:33 |
| gotgenes | except for a .bzr file | 23:33 |
| jelmer | gotgenes: that's right, it doesn't create working trees by default | 23:33 |
| jelmer | you can run "bzr checkout" in that directory to create it | 23:34 |
| gotgenes | jelmer: oh | 23:34 |
| gotgenes | jelmer: well how about that | 23:34 |
| jelmer | gotgenes: or specify the --trees argument to svn-import | 23:34 |
| gotgenes | so this would be a... hmm, would this be called a bare bzr repo? | 23:34 |
| jelmer | yes, that'd be the git term for it I guess | 23:35 |
| gotgenes | something meant to sit on a remote server and get pushed to | 23:35 |
| jelmer | in this case, it's being done to prevent you from running out of disk space | 23:35 |
| gotgenes | jelmer: ah, okay | 23:35 |
| igc | the patch for adding some user doc for knitpack has just been submitted to PQM now | 23:47 |
| * igc breakfast - bbiab | 23:48 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!