[00:00] pattern: you're not alone in avoiding cvs; I preferred rcs to cvs [00:00] for my simple needs [00:01] i just asked on #cvs about tools to convert RCS to CVS [00:01] are there any tools that i could use to migrate my RCS project to CVS ? [00:01] none needed [00:01] cvs uses rcs format for storage [00:01] lynx> just do a 'cvs init' to create a repository, then move the ,v files in there [00:01] yep [00:02] well, that's simple enough :) [00:09] I've heard it's even simpler than that === mw is now known as mw|out [00:17] 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] yes, you can use merge via emails [00:17] bialix, merge via email? that's awesome is there a manual you can point me about that? [00:17] look at 'send' command [00:18] bialix: your bzr win 0.92 is 'not found' -- there is a exe.part [00:18] hendrixski: Or you could look at 'bzr serve', if you're on the same network. [00:18] oh never mind, you were uploading. I was too quick [00:18] wow [00:20] I think there's even a plugin somewhere for zeroconf discovery [00:21] * hendrixski doesn't see send in the man page [00:21] bzr help send [00:21] bzr is self-documenting [00:22] the man page is just to make Debian packagers happy ;) [00:22] is there a tags command for python? [00:23] etags works fine with python [00:23] ctags probably too [00:23] ctags rocks [00:23] pah, vi user ;) [00:23] thanks, I didn't match python in the man page, but ctags --list-languages lists it. Sorry for wasting your time :-) [00:23] no, FTE [00:23] FTE? [00:24] yep [00:24] fte.sf.net [00:24] oh yeah [00:27] where can i download cvsps-import ? [00:28] ddaa: bzr-avahi [00:28] pattern: the bzr plugins page has a link I think [00:28] lifeless: your patch have landed [00:28] night all [00:30] the link from the bzr plugins page pointed me to: https://launchpad.net/bzr-cvsps-import [00:30] right [00:30] and from there i clicked on "Download project files" [00:30] oh, I don't think John has uploaded a tarball [00:30] and it tells me "No download files are linked to this series." [00:30] try the devel link [00:31] i don't see one [00:31] timeline - trunk [00:31] ah [00:31] well hidden :) [00:32] that gives me a "Download URL" of http://bazaar.launchpad.net/~bzr/bzr-cvsps-import/trunk [00:32] which is a broken link [00:32] see the word 'example' below it ? [00:32] ah, yes [00:32] thats a bzr command line to download it [00:32] ok, that worked [00:33] thanks for holding my hand through this :) [00:33] n [00:33] np [00:34] ok.. so, next question... now that i've downloaded the plugin, where do i put it? [00:34] should i just copy the entire directory to /usr/lib64/python2.4/site-packages/bzrlib/plugins ? [00:34] there are no installation instructions in the README [00:37] eeep [00:37] 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] UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 7: ordinal not in range(128) [00:37] pattern: hmm, I thought we had generic instructions [00:37] bzr commit --author 'Emrah Ünal ' [00:37] pattern: just link ~/.bazaar/plugins/cvsps to the directory you downloaded. [00:37] pattern: btw, "bzr branch https://launchpad.net/bzr-cvsps-import" works too [00:37] i just found http://bazaar-vcs.org/UsingPlugins [00:38] * 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] AfC: if that guy has a profile in Launchpad (there are a bunch of automatically created profiles, for packagers or translators) [00:39] you can set the "Author" of the branch [00:39] AfC, i think your $LANG must be set to something that uses ascii [00:39] AfC: what bzr version do you have ? [00:40] I have a vague memory of a recent bug in the -- author support [00:41] Here he is https://edge.launchpad.net/~eunall [00:41] he's actually a real lp user :) [00:42] can anybody tell me the current version of bzr that's in the ubuntu packaging system?? [00:42] can't seem to find that info [00:43] packages.ubuntu.com/bzr [00:43] 0.91 [00:43] in hardy; 0.90 in gutsy [00:44] colossus$~/bzr: bzr --version [00:44] Bazaar (bzr) 0.17.0 [00:44] i guess it's safe to say i'm a bit behind?? ;) [00:44] try 'apt-cache madison bzr' [00:45] morning all [00:45] hi ian [00:45] poolie: oh i'm on a mac. i was checking for somebody else who's on ubuntu [00:45] * hunmonk examines fink... [00:45] poolie: can we chat about the --experimental name? I'd like ot change it before 0.92 [00:45] me too [00:46] i think 'experimental' is more an attribute of formats than a name for them [00:46] I think knit-pack or something like that is far better [00:46] agree [00:46] Are packs still to be considered experimental? [00:46] ell [00:46] well [00:46] poolie: I just went through the exercise of [re]setting my terminal to take UTF-8 characters. [00:46] they are not a consideration-free improvement [00:46] so I think calling them experimental in 0.92 is fine [00:46] agreed [00:47] and I can compose them into the command line. LANG=en_CA.UTF-8 [00:47] lifeless: bzr 0.91 [00:47] did you do 'export LANG'? [00:47] * poolie reads the delete performance patch [00:47] 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] It's set desktop wide on login by gdm et al [00:48] lifeless: can we compromise on experimental-pack say? [00:48] my fear with just plain experimental ... [00:48] is that it's way too generic [00:48] and another one called that in 2 years say ... [00:48] sure, you might want to use that name for something else in future [00:48] spiv, ping? [00:48] could cause confusion and breakage ... [00:49] given the name with start to appear in blogs, etc. [00:49] s/with/will/ [00:49] to send across a network, do you need a bzr server running on your computer? [00:49] Try try again [00:49] igc: yes we can [00:49] afc, i'll try it [00:49] thanks [00:50] igc, what are you up to today - would you like to do a patch for format naming? [00:50] I can [00:50] my idea would be something like this [00:50] it's accessed by --format knitpack [00:51] the help says it's experimental - indeed maybe there's an attribute on the format object that says it's experimental [00:51] the format string changes [00:51] as a straw man, maybe you should have to say eg [00:51] bzr init-repo --format knitpack --enable-experimental [00:51] that may be overdoing it [00:51] or alternatively maybe it should give a notice when one is created [00:52] poolie: I think thats overdoing it [00:52] hmm [00:52] poolie: I think that just changing the text and label is sufficient for now [00:52] poolie: a link to the doc.bazaar-vcs.org copy of the pack repo doco in the help for it [00:52] is the idea of pack-0.92 dead? [00:52] do i need to run "bzr init ." and/or "bzr add" before running "bzr cvsps-import" ? [00:52] the user-orientted docs [00:53] poolie: yes, based on my how to dogfood mails [00:54] lifeless: what impact will changing the name have on existing dogfooders? [00:54] igc: zip [00:54] pattern, i doubt you need to run add [00:54] igc: change their scripts is all [00:54] really? it's that clean? [00:54] you may need to run init - try without and see if it gives an error [00:54] pattern: bzr help cvsps-import should be useful [00:55] igc: I'm not talking about changing the disk format label, only the user visible label [00:55] ah [00:55] igc: the disk format is 'Bazaar Experimental no-subtrees\n' [00:56] i think we should change the disk format [00:56] if we change that, existing dogfooders need to edit .bzr/repository/format [00:56] but that is quite easy to do. [00:56] and today, so that only a few people are disrupted [00:56] sure [00:56] lifeless: thanks, but that help says nothing about what other commands i should run [00:57] poolie, lifeless: so I'm happy to put the patch up re renaming formats [00:57] jam-laptop: perhaps you can spare a minute to help pattern [00:57] ok [00:57] jam-laptop: pattern is having some trouble figuring out cvsps-import [00:57] i just tried running "bzr cvsps-import /path/to/my/CVSROOT myfile.c output" and got an error [00:57] maybe you could also collect robert's notes on how to try them out [00:57] it needs to go into some kind of extended release note i think [00:58] agreed [00:58] abentley: ping [00:58] "Processed 0 patches (0 new, 0 existing) on 0 branches (0 tags) in 0.1s (0.00 patch/s)" [00:58] "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] Pong [00:59] abentley: any further thoughts re 'merge directive' to 'merge recipe'? [00:59] I'd like to do it [00:59] 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] as a doc change as least [01:00] pattern: bzr doesn't version single files, only full trees. [01:00] ah [01:00] pattern: try 'bzr cvsps-import . output' [01:00] ok [01:00] igc: It's my favourite out of the things we discussed. [01:00] it's good I think ... [01:00] pattern: also, you need cvsps installed [01:00] I wouldn't change the default format marker. [01:00] like a normnal recipe, the 'diff' is a picture of the end result. :-) [01:00] cool, that seems to have worked [01:01] yeah, i installed cvsps [01:01] abentley: agreed [01:01] abentley: default format marker ? [01:01] just the external name as the plan [01:01] s/as/was/ [01:01] lifeless: The format marker used for merge directives. [01:01] ok, now that i've seemed to have successfully imported my old RCS project, on to actually learning bazaar! [01:01] thanks everyone! [01:01] I wouldn't change it to use the string "merge recipe" instead. [01:02] But I would consider adding non-default support for that. [01:02] I was planning to leave the old merge-directive cmd untouched as well [01:02] and, btw, the command had to be "bzr cvsps-import /path/to/my/CVSROOT . output" [01:02] igc: Yes, that makes sense. [01:03] poolie, lifeless, jam-laptop: any objections to renaming 'merge directive' to 'merge recipe' at the UI level (bar the old cmd) ? [01:04] I want to stop talking about bundles [01:04] hm [01:04] and say 'merge recipe' instead [01:04] i agree a better name would be better [01:04] i'm not 100% happy with 'merge recipe' for two reasons [01:04] - it's maybe still a bit cute [01:05] - 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] though i guess aaron's framework does allow it to be just the instructions [01:06] the metaphor of a pre-mix cake isn't far off [01:06] indeed - recipe plus ingredients [01:06] you get the recipe and the ingredients [01:06] and a mediocre-to-ok cake :) [01:06] but only the recipe is mandatory [01:07] so that's why I favour 'merge recipe' over 'merge pack' say [01:09] I'm nonplussed by all this [01:10] cart is looking quite nice [01:10] I think its great to have an answer to trac for bzr projects that don't want to use lp [01:11] is that a sequiter or not? [01:11] non [01:11] is 'merge request' already struck out? [01:12] quick question: my version of bzr is using knits. is there a newer branch format now? [01:12] 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:13] 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] hunmonk, there is a new experimental repository format, 'packs' [01:13] it is in bzr.dev and will be in 0.92 [01:14] if you'd like to try it and give feedback that would be great [01:14] poolie: will it be the default in 0.92 [01:14] ? [01:14] not in 0.92 [01:14] hm. fink is still at 0.18-1... [01:15] pattern: you can cd into it [01:16] pattern: if your files are not present in the output dir, its a tree-less repository, try 'bzr checkout .' [01:17] 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] would i type "bzr checkout ." while i'm cd'ed in to "output" ? [01:17] cvsps-import ...CVSROOT project output [01:17] pattern: yes, I think so [01:18] bzr: ERROR: Not a branch: "/path/to/output" [01:19] that's from "bzr checkout ." [01:20] earlier i had copied myfile.c,v to /path/to/my/CVSROOT before running "bzr cvsps-import /path/to/my/CVSROOT . output" [01:20] abentley, the cart site looks really nice [01:20] Thanks, poolie. [01:20] though http://cart.aaronbentley.com/issue/26 does remind me, in the fondest way, of C64 BASIC line-renumbering tools [01:20] 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:21] poolie: Yeah, that's actually what I'm working on now. [01:21] but i kind of wish launchpad had something like that - just 'importance' is a bit coarse [01:21] is the frontpage just static text? [01:22] I *think* this is a clear way of providing priority ranking. The alternative would be a linked list. [01:23] 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] 10:10 < lifeless> cart is looking quite nice [01:23] 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] But it's actually dynamically generated. [01:23] abentley: ^ ;) [01:24] lifeless: Coolness. [01:27] 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:30] poolie, lifeless: just sent a bundle for 155730 to the list. [01:37] abentley, well, it would be neat if you could just drag them around in the browser... [01:37] poolie: Yeah, I want to support that too. [01:44] gah [01:44] it's pretty annoying that there are several similar implementations of, say, unlock in remote.py :-/ [01:45] Yeah :/ [01:54] spiv, lifeless: so, remoterepsoitoyr.unlock [01:54] lifeless: just confirming, experimental supports tags doesn't it? [01:54] igc: different layers [01:54] let me ask differently ... [01:54] (igc, but yes, it does) [01:54] compatible with dirstate-tags? [01:54] rr.unlock does the unlocking twice: once at the vfs level, once at the rpc level [01:55] igc: yes, the branch format referred to by the experimental label is the tags format. [01:55] that's how I remembered it from the review. Thanks [01:56] at present, if the vfs unlock fails, the rpc unlock is not done - this seems strange to me [01:56] any comments? [01:56] Hmm. [01:56] * spiv looks [01:57] about line 500 [02:01] Yeah, that is a little weird I guess. [02:02] 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:03] 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] when i type "bzr checkout ." in /path/to/output i get an error: "bzr: ERROR: Not a branch: "/path/to/output"" [02:03] how would i list the branches bzr knows about? [02:04] 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:08] pattern: branches are all peers and independent. When a branch has a relationship to another you can see it with `bzr info` [02:10] pattern, you need to cd into one of the branch directories [02:10] or run 'bzr info BRANCH_DIR' [02:10] spiv, ok, so now that we have write groups [02:11] it can fail, if for example the write group is not finished [02:11] and, in general, you know it is a method that can fail [02:11] and there are the round trips as you say [02:13] poolie: but it's still correct to say that any failure that would happen would also happen on the RemoteRepository._unlock() instead? [02:14] spiv, well, no, it currently delegates its write groups entirely to the real repository [02:14] so [02:15] write groups are not something that should cross the wire IMO [02:15] we should 'buffer' the data and do a single insert over the wire [02:16] where buffer currently is 'write to the remote location an upload pack', but could mean 'buffer in /tmp' [02:16] "not cross the wire" in the sense of there's no write-group related rpc [02:16] i agree [02:17] right [02:17] hm [02:17] spiv, when you say that real_repository.unlock shouldn't touch the lock [02:17] hm [02:18] Well, _real_repository.unlock should leave the lock in place. [02:18] is that because the lock will ultimately be removed by the _unlock call being passed to the server and releasing it there [02:18] Because a lock_token was passed to _real_repository.lock_write [02:18] Right. [02:19] 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] hm [02:19] maybe we could arrange for them to share a lock object or something [02:20] not right now [02:20] 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:21] poolie: they are sharing a lock object - thats the lock token concept [02:21] poolie: its a shared lock across the wire [02:22] sure [02:22] my point is, unlock() has several effects [02:22] so it's a bit of a blunt instrument for telling the vfs repo "be aware i've unlocked you" [02:22] Well, my reconcile fix completes on bzr.dev without blowing up, that's a good sign... [02:23] spiv: can you: init --experimental foo; cd foo; bzr pull ../reconciled-bzr.dev; bzr push ../new-dir [02:23] spiv: where foo is *not* within a shared repo [02:23] lifeless: Will do. [02:23] I've just verified that the relevant kndx now has a fulltext for that record. [02:24] (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:28] lifeless: it'd be nice if push actually gave a progress bar... [02:29] spiv: yes, but its so fast who cares? :] [02:29] lifeless: well, here's the funny thing... it isn't. [02:30] spiv: initial local branch spends a lot of time ungzipping [02:30] lifeless: 2m 42s real, mostly spent on CPU... [02:30] Ah. [02:30] I was starting to wonder if my reconciled repo had sent it off into an infinite loop somehow. [02:31] lifeless: so, those commands all appeared to work. [02:31] cool [02:31] thats the acid test [02:32] lifeless: I have 61M of repo data according to du -hs, and all appears to be well. [02:32] (I guess the 10M reduction is partly due to the lack of annotations?) [02:32] yes [02:43] ok, well, looks like cvsps-import isn't working for me, so i'm giving tailor a try [02:44] but tailor tells me "Common base for tailor exceptions: 'bzr' is not a known VCS kind: cannot import name compare_trees" [02:45] 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] 2.4.4, to be exact === kiko is now known as kiko-zzz [02:52] ok... a completely unrelated question... [02:52] when i do a "bzr init", is all the data that bzr needs stored in the "./.bzr" directory? [02:54] pattern: I just came back, I can try and help you with cvsps-import [02:54] (I would generally recommend it over tailor) [02:54] 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] ok, cool [02:54] pattern: generally we only store data in .bzr/* [02:54] great [02:54] pattern: so what are you trying to do? [02:54] the only other place might be $HOME/.bazaar/* [02:54] for your configuration files, etc. [02:54] well, i'm trying to migrate my RCS repository to bazaar [02:55] RCS or CVS? [02:55] RCS [02:55] hmm... [02:55] 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] which is what i did [02:56] pattern: does "cvs -d CVSROOT rlog", etc work? [02:56] (I can see that it could, but I'd check that first) [02:57] yes, it works [02:57] rlog does, anyway [02:57] ok, and do you have "cvsps" installed? [02:57] yep [02:58] 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] And you have cvsps-import installed ~/.bazaar/plugins/ [02:58] as something like [02:58] but then i couldn't get bzr to work with it [02:58] "cvsps_import" [02:58] ok, the output directory should have several things going on [02:58] 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:59] yes, i have the plugin installed in ~/.bazaar/plugins [02:59] and bzr recognizes the command, and runs it [02:59] give me a couple of seconds to remember all about cvsps-import. [02:59] But I'm guessing you were trying to do something with the top-level [02:59] when the actual data is lower down [03:00] I split the target directory into 2 paths [03:00] one is for the conversion data [03:00] (stuff cvsps needs to keep track of, but you don't need after the conversion) [03:00] well, cvsps-import needs to keep track of [03:00] also, if you are messing with your cvs repo [03:00] you should delete the cvsps cache [03:00] in ~/.cvsps [03:01] ah! [03:01] i knew there must have been something cached somewhere [03:01] So when you run the conversion, there will be a bzr repository in "OUTPUT/bzr" [03:01] ok.. this might work better now [03:01] and individual branches in [03:01] OUTPUT/bzr/branches/ [03:01] the important one being [03:01] OUTPUT/bzr/branches/HEAD [03:01] ok, great, no errors now [03:01] oh, sorry [03:02] OUTPUT/bzr/MODULE/branches/HEAD [03:02] the repository is at OUTPUT/bzr/MODULE [03:02] you should be able to [03:03] i just did "bzr cvsps-import /path/to/CVSROOT . output", so i have "output/bzr/branches" [03:03] bzr checkout --lightweight OUTPUT/bzr/MODULE/branches/HEAD my-project [03:03] so that would be [03:03] or at least do [03:03] bzr log output/bzr/branches/HEAD [03:04] 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] from "bzr log output/bzr/branches/HEAD" i get "bzr: ERROR: Not a branch: "/FULLPATH/output/bzr/.bzr/branch/" [03:05] hmm.. I wouldn't expect output/ to be considered a branch [03:05] where "/FULLPATH/output" is the full path to the "output" directory [03:05] sure [03:05] what does the output of [03:05] ls -al output/bzr/branches give? [03:06] (It seems like it isn't finding a branch at .../branches/HEAD) [03:06] oops, i just noticed that when i ran "bzr log output/bzr/branches/HEAD" i was already in "output/bzr" :) [03:06]