[03:21] * bitmonk wonders if anyone can point at RPMs for bzr that work on RHEL4 [03:22] the fc7/8/9 stuff all wants python 2.5 and glibc 2.4 or newer [11:17] Hi, is it normal that I can't branch a bzr-svn repo (rich-root format) to a branch in a shared repo with pack-0.92 format? [11:18] minghua: yes [11:18] yes [11:18] use --rich-root-pack [11:18] luks: Not --rich-root? [11:18] depends if you want to use packs or not [11:19] but you said pack-0.92, so the equivalent is rich-root-pack [11:19] Or you mean "bzr branch --rich-root-pack ..."? Let me read the man page... [11:19] no, the repository must be in the rich-root-pack format [11:19] you can upgrade it [11:19] but it will break backward compatiblity with <1.0 clients [11:20] Oh, I see. So a repository initiated with --rich-root will also work? [11:20] yes [11:20] I don't mind re-creating the repository. [11:23] luks: Thanks a lot for the help. [11:23] can anyone help me with some config-manager difficulty? I'd like to cherry-pick dirs from CVS repos, but cm doesn't seem to be able to do that: https://bugs.edge.launchpad.net/bugs/178073 [11:24] Launchpad bug 178073 in config-manager "Support cherry-picking subtrees from a CVS repo" [Undecided,New] [13:27] http://pastebin.ca/828424 <--- what went wrong? [13:29] missing ssl certificates probably, I think it's fixed in newer versions [13:29] you can try urllib+https://... to workaround it [13:29] actually, https+urllib://... [13:30] oops, link was wrong [13:30] stupid me [13:38] what's the fastest way to push a new repo to a remote server? [13:38] actually, the way that uses the least bandwidth [13:49] anyone? [13:49] make a tarball, scp it? [13:50] well, .tar.bz2 [13:52] hmm [13:53] isn't bzr+ssh faster? [14:00] Stavros: i can't see how it can be faster than bzr+ssh for a new repo [14:06] aadis: i don't really know what bzr+ssh does, i assume it sends the (compressed) changesets? [14:06] for a new repo, i don't see how that's going to be more efficient than just bzipping the repo [14:07] makes sense for an ongoing transfer. prolly tar+bz2 can extract better compression even [14:07] the main thing there is roundtrips, really [14:08] scp'ing a tar.bz2 is pretty much the definition of "wire speed" used around here. Robert usually compares against it. [14:09] .tar would be "wire speed" [14:09] Stavros: I have used rsync very successfully in the past for this sort of thing, but now I just rely on bzr to do the right thing. [14:09] I said "around here" [14:09] bzr repository has a lot of compressible data that are not compressed [14:09] so bzip2 -9 could help a bit [14:10] luks: that's not correct. Bazaar employs compression quite heavily. [14:10] (at least, Robert's new code does) [14:11] AfC: indexes are not compressed [14:11] Oh, sure [14:11] But one doesn't ship indexes when shipping revisions, does one? [14:11] My understanding was that they were a branch-by-branch artifact [14:12] (Huh. But, of course, if you rsync / scp a branch across raw, then you will drag all that crap with you) [14:13] (So you could just send the revisions directory... but then, well, you're more or less using packs :)) [14:13] * AfC looks at the time and realizes he should be asleep [14:14] AfC: one does [14:14] knits nor packs are not standalone [14:18] can someone help me lay out a repo? I'm trying to use a centralised bzr repo for managing and updating drupal sites [14:18] but each site will have a different collection of modules [14:18] does anyone remember how i can copy all *.py files recursively from a directory to another? [14:19] if drupal was available by svn, I'd check it out with svn and use svn:externals, but that's obviously not an option [14:19] Stavros: same dir structure? or in the same dir? [14:19] aadis: i'm copying my working copy files to the directory with the bzr repo, so exact same structure [14:19] i.e. copy workingcopy/*.py workingcopy_bzr/ [14:19] Stavros: no clean way comes to find, except perhaps using tar! [14:20] hmm, interesting [14:20] Stavros: hang on, I'm sure I can think of something [14:20] tar can do anything! [14:20] tar should work [14:20] Stavros: you could use rsync [14:20] aha, yes [14:20] even better [14:21] rsync -av source/ dest/ --include '*.py' --exclude '*.pyc' [14:22] or cp -a source/ dest; find -type f -a ! -name '*.py' -exec rm {} \; [14:22] ^ lazy method [14:22] aw man [14:22] that rsync line copied everything :/ [14:22] * tumbleweed was excluiding pyc [14:22] you'd have to exclude every extension you don't want, individually [14:23] oh [14:23] hmm [14:23] which sucks, but rsync doesn't have an option to include directories [14:23] i'd think "include py" would exclude everything else [14:23] it's ok, i'll just have bzr clean it up [14:23] no, it doesn't [14:23] thanks a lot! [14:23] Stavros: use find to clean it up [14:24] anyway, I was asking about lay outs, would this make sense?: [14:24] repo/drupal (drupal tree) [14:24] repo/modules/foo (each module) [14:25] any idea how to delete all .svn folders under my tree? :/ [14:26] Stavros: find . -name '*.svn' -print0 | xargs -0 rm -rf [14:26] thanks [14:26] Stavros: find . -name '.svn' -print0 | xargs -0 rm -rf [14:26] whoops [14:26] not *.svn [14:26] indeed, thanks [14:28] * tumbleweed can't think straight in this heat [14:31] Stavros: re your copying problem [14:31] you could do rsync -av source/ dest/ --include '*.py' --exclude '*.*' [14:31] assuming all files have extensions [14:34] not --exclude '*'? [14:38] tumbleweed: ah, that worked, thanks [14:48] bob2: exclude * would exclude everything [14:48] bob2: including directories that form part of the parent tree to your .py files [14:48] it's a yucky solution, but it works [14:51] now that my head is working on this, here is a good, and correct solution: find . -name '*.py' -exec cp --parents {} ../destination/ \; [15:00] ah, thanks [15:00] trying to migrate to bzr :/ [15:01] Stavros: how big is your repo that you don't want to just `bzr push` all your branches? [15:03] tumbleweed: afaict include is applied after exclude, so it does work [15:03] LarstiQ: it's not large, but the production server has a few lines different from dev [15:04] and i'm trying to reconcile things [15:04] so i have to get that working copy, diff it, etc etc [15:04] bob2: includes and excludes are applied in the order specified [15:05] bob2: but rsync won't copy a file unless it copies it's parent directories, too (not necessarily contents of them, though) [15:05] Stavros: aah [15:06] LarstiQ: yes, it's proving rather hard :/ [15:06] oh wait [15:06] i'm just stupid [15:06] gah, i should just delete the .bzr dir and copy everything else [15:13] anyone know how to cause an external HDD to spin down in linux, like windows' unmount does? [15:13] (i'm way off topic now) [15:14] hdparm -y /dev/foo [15:15] ah, thanks [15:15] y or Y? [15:15] I think Y is a deeper sleep than y [15:15] but why do you want to do this? [15:16] oh, external [15:16] yes, i'm not sure if it parks the head otherwise [15:16] I'd assume it does, but don't know [15:16] I think drives park their heads as the power is lost [15:17] that sounds reasonable... i wouldn't want to risk it, though [15:31] i have two working copies that diverged from the same revision, how can i merge them? [15:32] i committed one and am trying to merge the other, but merge says there's nothing to do [15:33] Stavros: You generally merge branches, not working copies. Merge only works on commits, unless you use --uncommitted to try and bring over working copy changes. [15:33] But you probably want to commit, then merge. [15:34] hmm, it's a bit messed up now, because i'm trying to migrate, so they're both in the same directory [15:34] i.e. i took the original revision, made some changes, committed [15:34] then i took the other working copy and i want to merge the changes i had done [15:35] i don't know if i'm making sense [15:35] if i commit now, i'll revert all the changes i last committed [15:35] i want to merge the last commit with the working copy (it has a bug fix) [15:36] Oh, yeah, that doesn't make sense. [15:36] hmm [15:36] What you want to do is branch the rev before that, that both were based on, commit in that's tree, then merge them. [15:36] aha [15:36] that makes sense then, yes [15:36] thanks [15:38] how do i push some changes to another local branch without changing the working copy? [15:43] Mmm. Not sure that makes much sense either. [15:43] I guess you could act remote (use sftp:// localhost or something) and update the branch without touching the tree. [15:43] ah, never mind, it doesn't do it if they've diverged [15:43] if they haven't, one could just revert to the committed revision [15:44] Yeah, that'd stop it there. [15:44] A branch can only have one head rev, so you'd have to merge them to get them together again. [15:50] hi [15:51] is there some equivalent of mercurials mq or gits stgit for Bazaar available? [15:56] or what is the preferred way in bazaar to track patches which are supposed to be send via mail when they are done? [15:56] i did a "bind" and a "push" but the push is not pushing where i bound,what do i do? [16:00] Stavros: if you bind, you don't need to push [16:00] Stavros: commits will automatically be pushed [16:00] push defaults to its own location, different from bind. [16:01] I cannot use bzr diff while writing a commit message :( [16:01] bad usability, imho [16:01] Leonidas: with a branch? [16:01] mgedmin: It's generally considered a bug. [16:01] mgedmin: I've found that annoying too [16:02] radix: imagine the following setup: there is an remote repository to which I have no access. Now, I cloned it and want to make some improvements to the code. So, what would be "the Bazaar way" of doing this? [16:04] Leonidas: The normal way would just be to go ahead and work on it and commit in your branch. [16:04] I thought I heard of somebody some months ago looking at making mq work with bzr, but I may be imagining it. I don't think anybody's come out and declared success with it. [16:06] sorry, connection problem. === Leonidas_ is now known as Leonidas [16:06] fullermd: ok, but what would happen on merges? [16:07] hmm, I think I really should try it out myself, instead of aksing stupid questions [16:08] But at least I know how to handle it with bzr [16:10] Well, merges would just be merges. [16:13] Leonidas: so, you might have many local branches [16:13] Leonidas: you might branch the upstream to "upstream", then branch *that* to "fix-for-my-bug" [16:13] Leonidas: in other words, you should represent distinct change sets as distinct branches [16:14] (I use the word "change sets" loosely -- a fix for a bug or a new feature) [16:14] radix: but when I update the upstream branch I would need to update every single branch, right? [16:14] Leonidas: well, hopefully you'll get those other branches merged quickly. [16:15] Leonidas: And it's ok if it gets a little bit out of date; as long as no conflicting changes are made, it'll still be mergable. [16:15] well, of course it'll be mergeable in any case, but the conflicts will need to be resolved after the merge. [16:16] fine :) [17:10] odd question: but do anyone know of there's a package out there that provides more or less "bzr shelve" but for subversion? [17:11] jrydberg_: not directly, but I'd try quilt [17:12] * mgedmin always used svn diff > my.diff; less my.diff; svn revert -R [17:13] mgedmin: that is an option :) [17:18] darn, so i have to port shelve to subversion. hehe [17:21] does "pull" update the working copy if it hasn't diverged? [17:22] Actually, pull tries to update the working copy even if it is diverged. [17:24] hmm, how does it do that? [17:24] I thought pull doesn't do anything if the branches have diverged. [17:25] Well, I mean the WT diverged; local uncommitted changes. [17:25] oh. I see. [17:25] If the branches are diverged of course it just says "No way" [17:25] how does it update the working copy if it diverged? [17:26] Pretty much the same was 'cvs up' will try to merge in local uncommitted changes. [17:27] ah [17:27] what's the difference between a bound branch and doing "push" after "commit"? [17:28] The bound branch won't let you commit if you're out of date. [17:29] It's not a bound branch, it's a checkout. [17:29] ah, so it has to communicate to the server at all times [17:29] like a centralized vcs [17:29] When you commit, certainly. [17:29] Yeah, that's the workflow. [17:29] aha, thanks [17:39] hey it seems trac-bzr is broken with trac 0.11 [17:40] in #trac they said it was a problem in the plugin and iirc that means I got to ask in this channel [17:40] http://rafb.net/p/TNLFPz34.html [17:41] does that plugin generally work well? [17:42] yes it worked with 0.10.4 [17:43] aha, i must try it [17:44] Stavros, however completely broken with 0.11, tried all the branches at launchpad [17:44] and no recent development [17:49] hmm :/ [17:51] AnMaster: I fixed (it's only a workaround) to work with 0.11ç [17:51] Verterok_, how? [17:51] * Verterok_ searching for the url to the branch [17:56] Verterok_, ? [17:57] brb phone, will check it when I get back [17:57] AnMaster: I'm on it... === Verterok_ is now known as Verterok [17:58] AnMaster: https://code.launchpad.net/~guillo.gonzo/trac-bzr/trac-0.11dev [17:59] AnMaster: I'm running a trac instance with that plugin for bzr-eclipse (but I'm moving it to launchpad) [18:02] AnMaster: don't know if it still work for the current trunk of trac :P [18:04] Verterok, tried it, didn't work [18:04] and I'm using pre-release 0.11b1 [18:04] so not trunk [18:04] beta1 [18:09] jrydberg_: shelve probably works with the bzr-svn plugin :-) [18:10] AnMaster: I'l take a look and see if I can fix it [18:11] mgedmin: There is the --show-diff commit option, which will allow you to see the diff. [18:11] yay, good [18:12] now I need to make some changes to see the diff :) [18:17] mhm, no short version of --show-diff... [18:17] vim doesn't know how to syntax-highlight diffs in the commit message [18:17] mgedmin: http://chistera.yi.org/~adeodato/code/bzr/bzr-vim/ [18:18] I should really try to get my version to replace or enhance the current one bundled with vim [18:18] thanks [18:48] abentley: hehe [18:48] abentley: anyhow, i ripped out the shelf parts from bzrtools and wrote a patchsource for subversion. easy as 1 2 3. [18:48] Ah, cool. [18:49] os.popen('svn diff') :) [18:49] I think it would be nice if bzr was a good svn client. [19:04] that reminds me [19:04] last time I tried, it wasn't [19:04] it's time to try again [19:09] AnMaster: I just get a trac-0.11b1 running with timhatch branch: https://code.launchpad.net/~timhatch/trac-bzr/thatch-dev [19:10] Verterok, odd, I tried that here without success [19:10] did you do anything special? [19:10] Verterok, and did you try to enter plugin page in webadmin ui (where I got the error) [19:11] AnMaster: no just borowse source, let's try [19:11] AnMaster: I need to setup an admin user, right? [19:12] yes, someone with TRAC_ADMIN iirc [19:13] ok [19:14] is there a way to get a passwordless login with a paramiko public key (sftp) in Windows? [19:14] dennda: hast du grad noch nen moment zeit? [19:14] oh, sorry, wrong channel [19:14] :) [19:15] Peaker_, well use ssh keys? [19:15] AnMaster, I know how to do that with ssh, but how to do it with paramiko? [19:15] AnMaster, How do I know what the public key is to add it to authorized_keys2? [19:15] hm it doesn't make use of putty? [19:16] AFAIK, it used paramiko only, but I do have putty here [19:16] * AnMaster is a linux/freebsd user [19:16] since 5 years [19:16] AnMaster, me too, I'm visiting my folks and they use Windows :-( [19:16] Maybe I'll just install Ubuntu here somewhere... [19:17] well iirc putty got some ssh-agent thingy [19:17] and paramiko (or whatever) does use ssh-agent on linux at least [19:20] I haven't told it about putty's existence, so I'm guessing paramiko uses its own/pycrypto implementation [19:20] I found how to create a key pair with paramiko, but not sure how to get bzr to use that key [19:24] Verterok, result? [19:24] same error [19:25] but I think I'm close to find the cause :) [19:26] ouch [19:26] 21578 mg 18 0 1162m 861m 3456 R 67 43.4 12:01.54 bzr [19:27] that's me attempting to bzr co svn+ssh from a repo with 5620 revisions [19:27] and it fails with bzr: ERROR: mismatched lock context and write group after 18 minutes [19:28] a gig of ram is a bit excessive for < 30 megs of source code [19:28] fwiw git-svn is also unable to cope with this repo, if that's any consolation [19:30] mgedmin: http://subversion.tigris.org/issues/show_bug.cgi?id=3052 [19:33] fixed 3 days ago, yay [19:34] mgedmin: and possibly in 1.4.7 [19:34] gutsy has 1.4.4dfsg1-1ubuntu3 [19:34] mgedmin: 1.4.7 is still in the release process [19:36] mgedmin, LarstiQ: jelmer commited to bzr-svn code to workaround a memory leak in the bindings (see r806). maybe just running bzr-svn from the branch will help. [19:36] which branch? [19:37] AnMaster: I just find workaround for the erro ;) [19:37] mgedmin: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ [19:37] Verterok, you found one? [19:37] mgedmin: cd ~/.bazaar/plugins && bzr get http://people.samba.org/bzr/jelmer/bzr-svn/0.4 svn [19:38] The workaround in bzr-svn itself only works around the main memory leak [19:38] aha [19:38] the fix in subversion upstream fixes all leaks [19:38] is there more than one? [19:38] sounds fun [19:38] AnMaster: in backend.py add define a top level/global variable: version = '0.2' [19:38] AnMaster: that should do the trick :) [19:38] * mgedmin upgraded ram to 2 gigs just last week [19:38] I will try it shortly, got some telephone calls to make and such [19:38] however, you probably won't notice the others leaks because they're quite small [19:39] ok [20:05] 16 minutes and BAM! [20:05] bzr: ERROR: exceptions.TypeError: int argument required [20:08] https://bugs.launchpad.net/bzr/+bug/178149 [20:08] Launchpad bug 178149 in bzr "bzr co svn+ssh:/// gets a TypeError" [Undecided,New] [20:12] that looks like a bug in bzr-svn, not bzr [20:12] mgedmin, yeah, I just reassigned [20:13] sorry, I just clicked on the "please report this bug here" link [20:13] without paying much attention [20:13] no worries [20:13] mgedmin, Any chance you can run it again with BZR_PDB=1 set? [20:13] sure [20:14] that was quick [20:14] bzr: ERROR: File exists: u'/home/mg/tmp/trunk/.bzr' [20:14] heh, I typed du when I meant rm -rf [20:15] (fwiw the old checkout left after the crash was 48 megs) [20:15] I probably shouldn't say checkout given that it's a full-fledged bzr branch, no? [20:15] wait, I did bzr co, not bzr get [20:15] checkout is the appropriate term [20:15] the other thing is "lightweight checkout" which is just a working tree [20:16] without a full-fledged branch [20:16] mgedmin: Are you using the 0.4 branch? [20:16] late saturday evening -> brain not at its best [20:16] yes, 0.4 branch [20:16] bzr revno says 822 [20:19] yep, that's the latest [20:33] (Pdb) [20:33] /usr/lib/python2.5/site-packages/bzrlib/xml5.py(216)write_inventory() [20:33] ie.text_size is None [20:34] which seems interesting to me [20:34] ie is an InventoryFile, and it seems to be a symlink in subversion [20:35] yep, that revision added a symlink to the svn repo [20:35] does bzr-svn support symlinks? [20:35] ie.kind == 'file' [20:36] was this a revision pushed by bzr-svn ? [20:37] no [20:37] but I've had trouble with symlinks in that svn repo before [20:37] symlinks suddenly becoming plain files with 'link ../../lalala' inside [20:37] and svn st not noticing anything strange [20:37] svn revert failing to fix the problem [20:38] but rm'ing and svn up'ing would fix the problem [20:38] in the end I removed all symlinks and replaced them with copies [20:39] Symlinks in Subversion are basically regular files with "link ../foo" inside [20:39] and a special property "svn:special" set to "*" [20:39] and a special property [20:39] yes [20:39] svn proplist -r url-to-that-file gives me an empty list [20:39] weird [20:40] are you still in the debugger? [20:40] can you paste the contents of ie? [20:40] yes [20:40] InventoryFile('6777@1f28630d-58db-0310-90fc-ab02c05bae6f:trunk:team%2Fbrowser%2Ftexts%2Fspelling.tt', u'spelling.tt', parent_id='1990@1f28630d-58db-0310-90fc-ab02c05bae6f:trunk:team%2Fbrowser%2Ftexts', sha1=None, len=None) [20:41] and ie.kind == 'file' ? [20:41] yes [20:41] aha [20:41] svn log on that file gives me two revisions: [20:42] 6777 where I added the symlink [20:42] and 6779 where I manually set svn:special to "*" [20:42] because svn proplist in my working directory showed it [20:42] but svn proplist in a fresh checkout didn't [20:42] ah [20:43] I don't know how I managed to convince svn to commit it this way to the repo [20:43] IIRC I once spent an afternoon trying to recreate any of my symlink problems with svn so I could file a proper bug report [20:44] what does "svn cat -r6779 " show? [20:44] but I failed at that [20:44] svn cat of both 6779 and 6777 show "link ../../../threesixty/browser/texts/spelling.tt" (no trailing newline) [20:46] I think I know what the problem is [20:46] bzr-svn supports changing the kind of a file [20:46] but only if the contents of that file also change [20:47] heh [20:47] that usually always happens, because you don't tend to have files that contain "link .../..," that you then turn into a symlink [20:47] not by choice, no [20:47] * jelmer sees if he can reproduce in a bzr-svn testcase [20:48] Ah, heh. Tricky. [20:48] I had to deal with that issue when writing _iter_changes, too. [20:59] yeah, these are really funny corner cases [20:59] it looks like subversion doesn't allow kind changes in general, it just requires you to delete and re-add [20:59] however, Marius somehow seems to've worked around their usual checks :-) [21:02] mgedmin, the patch at http://samba.org/~jelmer/bzr-svn-ensure-kind.diff may help [21:02] * mgedmin whistles nonchalantly [21:02] it's untested as I haven't found a way to make svn stop complaining about changes to svn:special [21:03] if you still remember how you managed that, I'm interested to hear about it :-) [21:03] I can't remember what I don't know :/ [21:07] it's somewhat unfair how bugs in svn make bzr-svn look bad [21:08] heh, yeah [21:16] As others have pointed out in stronger terms, I’m not a physicist. (On the other hand, the gentleman linked to in the previous sentence is not correct about my being paid by the NSA to discredit Canadian quantum computing efforts: it’s actually the GCHQ and the Mossad.) [21:16] -- http://scottaaronson.com/blog/ [21:24] jelmer: nope, that patch doesn't fix the problem [21:25] same error in same place [21:26] I'll try to create a small svn repo with the same sort of kind change [21:26] are you sure? I just reproduced the problem here and the patch seems to fix the problem [21:26] if I feel bored during the holidays [21:26] * mgedmin is staring at the pdb prompt [21:27] * mgedmin runs bzr diff in ~/.bazaar/plugins/svn [21:28] now also committed as 823 [21:30] * mgedmin runs bzr pull [21:30] yep, I had that patch applied, and bzr pull merged it cleanly [21:31] yet ie.kind == 'file' [21:31] nm, it's not like it's an urgent problem for me [21:31] for a while yet I've been investigating bzr and bzr-svn, waiting until switching to it becomes pain-free [21:32] this was just another of those idle curiosity attempts [21:34] mgedmin: well, it'd be nice to get a testcase done now [21:39] * mgedmin wrestles with svnadmin dump [21:41] I don't get it [21:41] rev 6777 was a tiny one that added 4 lines to one text file and added one symlink [21:42] yet svnadmin dump -r 6777 produces who-knows-what [21:42] oh, right [21:42] I forgot the --incremental [21:43] here's what svnadmin dump says: http://bzr.pastey.net/79411 [21:43] Node-action: replace [21:43] no properties [21:44] haha [21:45] re [21:45]