[03:21]  * bitmonk wonders if anyone can point at RPMs for bzr that work on RHEL4
[03:22] <bitmonk> the fc7/8/9 stuff all wants python 2.5 and glibc 2.4 or newer
[11:17] <minghua> 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] <dato> minghua: yes
[11:18] <luks> yes
[11:18] <luks> use --rich-root-pack
[11:18] <minghua> luks: Not --rich-root?
[11:18] <luks> depends if you want to use packs or not
[11:19] <luks> but you said pack-0.92, so the equivalent is rich-root-pack
[11:19] <minghua> Or you mean "bzr branch --rich-root-pack ..."?  Let me read the man page...
[11:19] <luks> no, the repository must be in the rich-root-pack format
[11:19] <luks> you can upgrade it
[11:19] <luks> but it will break backward compatiblity with <1.0 clients
[11:20] <minghua> Oh, I see.  So a repository initiated with --rich-root will also work?
[11:20] <luks> yes
[11:20] <minghua> I don't mind re-creating the repository.
[11:23] <minghua> luks: Thanks a lot for the help.
[11:23] <tumbleweed> 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] <ubotu> Launchpad bug 178073 in config-manager "Support cherry-picking subtrees from a CVS repo" [Undecided,New]
[13:27] <dennda> http://pastebin.ca/828424 <--- what went wrong?
[13:29] <luks> missing ssl certificates probably, I think it's fixed in newer versions
[13:29] <luks> you can try urllib+https://... to workaround it
[13:29] <luks> actually, https+urllib://...
[13:30] <dennda> oops, link was wrong
[13:30] <dennda> stupid me
[13:38] <Stavros> what's the fastest way to push a new repo to a remote server?
[13:38] <Stavros> actually, the way that uses the least bandwidth
[13:49] <Stavros> anyone?
[13:49] <mwhudson> make a tarball, scp it?
[13:50] <mwhudson> well, .tar.bz2
[13:52] <Stavros> hmm
[13:53] <Stavros> isn't bzr+ssh faster?
[14:00] <aadis> Stavros: i can't see how it can be faster than bzr+ssh for a new repo
[14:06] <Stavros> aadis: i don't really know what bzr+ssh does, i assume it sends the (compressed) changesets?
[14:06] <aadis> for a new repo, i don't see how that's going to be more efficient than just bzipping the repo
[14:07] <aadis> makes sense for an ongoing transfer. prolly tar+bz2 can extract better compression even
[14:07] <LarstiQ> the main thing there is roundtrips, really
[14:08] <AfC> scp'ing a tar.bz2 is pretty much the definition of "wire speed" used around here. Robert usually compares against it.
[14:09] <luks> .tar would be "wire speed"
[14:09] <AfC> 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] <AfC> I said "around here"
[14:09] <luks> bzr repository has a lot of compressible data that are not compressed
[14:09] <luks> so bzip2 -9 could help a bit
[14:10] <AfC> luks: that's not correct. Bazaar employs compression quite heavily.
[14:10] <AfC> (at least, Robert's new code does)
[14:11] <luks> AfC: indexes are not compressed
[14:11] <AfC> Oh, sure
[14:11] <AfC> But one doesn't ship indexes when shipping revisions, does one?
[14:11] <AfC> My understanding was that they were a branch-by-branch artifact
[14:12] <AfC> (Huh. But, of course, if you rsync / scp a branch across raw, then you will drag all that crap with you)
[14:13] <AfC> (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] <luks> AfC: one does
[14:14] <luks> knits nor packs are not standalone
[14:18] <tumbleweed> 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] <tumbleweed> but each site will have a different collection of modules
[14:18] <Stavros> does anyone remember how i can copy all *.py files recursively from a directory to another?
[14:19] <tumbleweed> 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] <aadis> Stavros: same dir structure? or in the same dir?
[14:19] <Stavros> aadis: i'm copying my working copy files to the directory with the bzr repo, so exact same structure
[14:19] <Stavros> i.e. copy workingcopy/*.py workingcopy_bzr/
[14:19] <aadis> Stavros: no clean way comes to find, except perhaps using tar!
[14:20] <Stavros> hmm, interesting
[14:20] <tumbleweed> Stavros: hang on, I'm sure I can think of something
[14:20] <aadis> tar can do anything!
[14:20] <Stavros> tar should work
[14:20] <tumbleweed> Stavros: you could use rsync
[14:20] <Stavros> aha, yes
[14:20] <Stavros> even better
[14:21] <tumbleweed> rsync -av source/ dest/ --include '*.py' --exclude '*.pyc'
[14:22] <tumbleweed> or cp -a source/ dest; find -type f -a ! -name '*.py' -exec rm {} \;
[14:22] <tumbleweed> ^ lazy method
[14:22] <Stavros> aw man
[14:22] <Stavros> that rsync line copied everything :/
[14:22]  * tumbleweed was excluiding pyc
[14:22] <tumbleweed> you'd have to exclude every extension you don't want, individually
[14:23] <Stavros> oh
[14:23] <Stavros> hmm
[14:23] <tumbleweed> which sucks, but rsync doesn't have an option to include directories
[14:23] <Stavros> i'd think "include py" would exclude everything else
[14:23] <Stavros> it's ok, i'll just have bzr clean it up
[14:23] <tumbleweed> no, it doesn't
[14:23] <Stavros> thanks a lot!
[14:23] <tumbleweed> Stavros: use find to clean it up
[14:24] <tumbleweed> anyway, I was asking about lay outs, would this make sense?:
[14:24] <tumbleweed> repo/drupal (drupal tree)
[14:24] <tumbleweed> repo/modules/foo (each module)
[14:25] <Stavros> any idea how to delete all .svn folders under my tree? :/
[14:26] <tumbleweed> Stavros: find . -name '*.svn' -print0 | xargs -0 rm -rf
[14:26] <Stavros> thanks
[14:26] <tumbleweed> Stavros: find . -name '.svn' -print0 | xargs -0 rm -rf
[14:26] <tumbleweed> whoops
[14:26] <tumbleweed> not *.svn
[14:26] <Stavros> indeed, thanks
[14:28]  * tumbleweed can't think straight in this heat
[14:31] <tumbleweed> Stavros: re your copying problem
[14:31] <tumbleweed> you could do rsync -av source/ dest/ --include '*.py' --exclude '*.*'
[14:31] <tumbleweed> assuming all files have extensions
[14:34] <bob2> not --exclude '*'?
[14:38] <Stavros> tumbleweed: ah, that worked, thanks
[14:48] <tumbleweed> bob2: exclude * would exclude everything
[14:48] <tumbleweed> bob2: including directories that form part of the parent tree to your .py files
[14:48] <tumbleweed> it's a yucky solution, but it works
[14:51] <tumbleweed> now that my head is working on this, here is a good, and correct solution: find . -name '*.py' -exec cp --parents {} ../destination/ \;
[15:00] <Stavros> ah, thanks
[15:00] <Stavros> trying to migrate to bzr :/
[15:01] <LarstiQ> Stavros: how big is your repo that you don't want to just `bzr push` all your branches?
[15:03] <bob2> tumbleweed: afaict include is applied after exclude, so it does work
[15:03] <Stavros> LarstiQ: it's not large, but the production server has a few lines different from dev
[15:04] <Stavros> and i'm trying to reconcile things
[15:04] <Stavros> so i have to get that working copy, diff it, etc etc
[15:04] <tumbleweed> bob2: includes and excludes are applied in the order specified
[15:05] <tumbleweed> bob2: but rsync won't copy a file unless it copies it's parent directories, too (not necessarily contents of them, though)
[15:05] <LarstiQ> Stavros: aah
[15:06] <Stavros> LarstiQ: yes, it's proving rather hard :/
[15:06] <Stavros> oh wait
[15:06] <Stavros> i'm just stupid
[15:06] <Stavros> gah, i should just delete the .bzr dir and copy everything else
[15:13] <Stavros> anyone know how to cause an external HDD to spin down in linux, like windows' unmount does?
[15:13] <Stavros> (i'm way off topic now)
[15:14] <tumbleweed> hdparm -y /dev/foo
[15:15] <Stavros> ah, thanks
[15:15] <Stavros> y or Y?
[15:15] <tumbleweed> I think Y is a deeper sleep than y
[15:15] <tumbleweed> but why do you want to do this?
[15:16] <tumbleweed> oh, external
[15:16] <Stavros> yes, i'm not sure if it parks the head otherwise
[15:16] <tumbleweed> I'd assume it does, but don't know
[15:16] <tumbleweed> I think drives park their heads as the power is lost
[15:17] <Stavros> that sounds reasonable... i wouldn't want to risk it, though
[15:31] <Stavros> i have two working copies that diverged from the same revision, how can i merge them?
[15:32] <Stavros> i committed one and am trying to merge the other, but merge says there's nothing to do
[15:33] <fullermd> 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] <fullermd> But you probably want to commit, then merge.
[15:34] <Stavros> hmm, it's a bit messed up now, because i'm trying to migrate, so they're both in the same directory
[15:34] <Stavros> i.e. i took the original revision, made some changes, committed
[15:34] <Stavros> then i took the other working copy and i want to merge the changes i had done
[15:35] <Stavros> i don't know if i'm making sense
[15:35] <Stavros> if i commit now, i'll revert all the changes i last committed
[15:35] <Stavros> i want to merge the last commit with the working copy (it has a bug fix)
[15:36] <fullermd> Oh, yeah, that doesn't make sense.
[15:36] <Stavros> hmm
[15:36] <fullermd> 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] <Stavros> aha
[15:36] <Stavros> that makes sense then, yes
[15:36] <Stavros> thanks
[15:38] <Stavros> how do i push some changes to another local branch without changing the working copy?
[15:43] <fullermd> Mmm.  Not sure that makes much sense either.
[15:43] <fullermd> I guess you could act remote (use sftp:// localhost or something) and update the branch without touching the tree.
[15:43] <Stavros> ah, never mind, it doesn't do it if they've diverged
[15:43] <Stavros> if they haven't, one could just revert to the committed revision
[15:44] <fullermd> Yeah, that'd stop it there.
[15:44] <fullermd> A branch can only have one head rev, so you'd have to merge them to get them together again.
[15:50] <Leonidas> hi
[15:51] <Leonidas> is there some equivalent of mercurials mq or gits stgit for Bazaar available?
[15:56] <Leonidas> 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] <Stavros> i did a "bind" and a "push" but the push is not pushing where i bound,what do i do?
[16:00] <radix> Stavros: if you bind, you don't need to push
[16:00] <radix> Stavros: commits will automatically be pushed
[16:00] <fullermd> push defaults to its own location, different from bind.
[16:01] <mgedmin> I cannot use bzr diff while writing a commit message :(
[16:01] <mgedmin> bad usability, imho
[16:01] <radix> Leonidas: with a branch?
[16:01] <fullermd> mgedmin: It's generally considered a bug.
[16:01] <radix> mgedmin: I've found that annoying too
[16:02] <Leonidas> 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] <fullermd> Leonidas: The normal way would just be to go ahead and work on it and commit in your branch.
[16:04] <fullermd> 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] <Leonidas_> sorry, connection problem.
[16:06] <Leonidas> fullermd: ok, but what would happen on merges?
[16:07] <Leonidas> hmm, I think I really should try it out myself, instead of aksing stupid questions
[16:08] <Leonidas> But at least I know how to handle it with bzr
[16:10] <fullermd> Well, merges would just be merges.
[16:13] <radix> Leonidas: so, you might have many local branches
[16:13] <radix> Leonidas: you might branch the upstream to "upstream", then branch *that* to "fix-for-my-bug"
[16:13] <radix> Leonidas: in other words, you should represent distinct change sets as distinct branches
[16:14] <radix> (I use the word "change sets" loosely -- a fix for a bug or a new feature)
[16:14] <Leonidas> radix: but when I update the upstream branch I would need to update every single branch, right?
[16:14] <radix> Leonidas: well, hopefully you'll get those other branches merged quickly.
[16:15] <radix> 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] <radix> well, of course it'll be mergeable in any case, but the conflicts will need to be resolved after the merge.
[16:16] <Leonidas> fine :)
[17:10] <jrydberg_> 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] <LarstiQ> 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] <jrydberg_> mgedmin: that is an option :)
[17:18] <jrydberg_> darn, so i have to port shelve to subversion. hehe
[17:21] <Stavros> does "pull" update the working copy if it hasn't diverged?
[17:22] <fullermd> Actually, pull tries to update the working copy even if it is diverged.
[17:24] <Stavros> hmm, how does it do that?
[17:24] <radix> I thought pull doesn't do anything if the branches have diverged.
[17:25] <fullermd> Well, I mean the WT diverged; local uncommitted changes.
[17:25] <radix> oh. I see.
[17:25] <fullermd> If the branches are diverged of course it just says "No way"
[17:25] <Stavros> how does it update the working copy if it diverged?
[17:26] <fullermd> Pretty much the same was 'cvs up' will try to merge in local uncommitted changes.
[17:27] <Stavros> ah
[17:27] <Stavros> what's the difference between a bound branch and doing "push" after "commit"?
[17:28] <fullermd> The bound branch won't let you commit if you're out of date.
[17:29] <fullermd> It's not a bound branch, it's a checkout.
[17:29] <Stavros> ah, so it has to communicate to the server at all times
[17:29] <Stavros> like a centralized vcs
[17:29] <fullermd> When you commit, certainly.
[17:29] <fullermd> Yeah, that's the workflow.
[17:29] <Stavros> aha, thanks
[17:39] <AnMaster> hey it seems trac-bzr is broken with trac 0.11
[17:40] <AnMaster> in #trac they said it was a problem in the plugin and iirc that means I got to ask in this channel
[17:40] <AnMaster> http://rafb.net/p/TNLFPz34.html
[17:41] <Stavros> does that plugin generally work well?
[17:42] <AnMaster> yes it worked with 0.10.4
[17:43] <Stavros> aha, i must try it
[17:44] <AnMaster> Stavros, however completely broken with 0.11, tried all the branches at launchpad
[17:44] <AnMaster> and no recent development
[17:49] <Stavros> hmm :/
[17:51] <Verterok_> AnMaster: I fixed (it's only a workaround) to work with 0.11ç
[17:51] <AnMaster> Verterok_, how?
[17:51]  * Verterok_ searching for the url to the branch
[17:56] <AnMaster> Verterok_, ?
[17:57] <AnMaster> brb phone, will check it when I get back
[17:57] <Verterok_> AnMaster: I'm on it...
[17:58] <Verterok> AnMaster: https://code.launchpad.net/~guillo.gonzo/trac-bzr/trac-0.11dev
[17:59] <Verterok> AnMaster: I'm running a trac instance with that plugin for bzr-eclipse (but I'm moving it to launchpad)
[18:02] <Verterok> AnMaster: don't know if it still work for the current trunk of trac :P
[18:04] <AnMaster> Verterok, tried it, didn't work
[18:04] <AnMaster> and I'm using pre-release 0.11b1
[18:04] <AnMaster> so not trunk
[18:04] <AnMaster> beta1
[18:09] <abentley> jrydberg_: shelve probably works with the bzr-svn plugin :-)
[18:10] <Verterok> AnMaster: I'l take a look and see if I can fix it
[18:11] <abentley> mgedmin: There is the --show-diff commit option, which will allow you to see the diff.
[18:11] <mgedmin> yay, good
[18:12] <mgedmin> now I need to make some changes to see the diff :)
[18:17] <mgedmin> mhm, no short version of --show-diff...
[18:17] <mgedmin> vim doesn't know how to syntax-highlight diffs in the commit message
[18:17] <dato> mgedmin: http://chistera.yi.org/~adeodato/code/bzr/bzr-vim/
[18:18] <dato> I should really try to get my version to replace or enhance the current one bundled with vim
[18:18] <mgedmin> thanks
[18:48] <jrydberg_> abentley: hehe
[18:48] <jrydberg_> abentley: anyhow, i ripped out the shelf parts from bzrtools and wrote a patchsource for subversion.  easy as 1 2 3.
[18:48] <abentley> Ah, cool.
[18:49] <jrydberg_> os.popen('svn diff') :)
[18:49] <abentley> I think it would be nice if bzr was a good svn client.
[19:04] <mgedmin> that reminds me
[19:04] <mgedmin> last time I tried, it wasn't
[19:04] <mgedmin> it's time to try again
[19:09] <Verterok> AnMaster: I just get a trac-0.11b1 running with timhatch branch: https://code.launchpad.net/~timhatch/trac-bzr/thatch-dev
[19:10] <AnMaster> Verterok, odd, I tried that here without success
[19:10] <AnMaster> did you do anything special?
[19:10] <AnMaster> Verterok, and did you try to enter plugin page in webadmin ui (where I got the error)
[19:11] <Verterok> AnMaster: no just borowse source, let's try
[19:11] <Verterok> AnMaster: I need to setup an admin user, right?
[19:12] <AnMaster> yes, someone with TRAC_ADMIN iirc
[19:13] <Verterok> ok
[19:14] <Peaker_> is there a way to get a passwordless login with a paramiko public key (sftp) in Windows?
[19:14] <Leonidas> dennda: hast du grad noch nen moment zeit?
[19:14] <Leonidas> oh, sorry, wrong channel
[19:14] <dennda> :)
[19:15] <AnMaster> Peaker_, well use ssh keys?
[19:15] <Peaker_> AnMaster, I know how to do that with ssh, but how to do it with paramiko?
[19:15] <Peaker_> AnMaster, How do I know what the public key is to add it to authorized_keys2?
[19:15] <AnMaster> hm it doesn't make use of putty?
[19:16] <Peaker_> AFAIK, it used paramiko only, but I do have putty here
[19:16]  * AnMaster is a linux/freebsd user
[19:16] <AnMaster> since 5 years
[19:16] <Peaker_> AnMaster, me too, I'm visiting my folks and they use Windows :-(
[19:16] <Peaker_> Maybe I'll just install Ubuntu here somewhere...
[19:17] <AnMaster> well iirc putty got some ssh-agent thingy
[19:17] <AnMaster> and paramiko (or whatever) does use ssh-agent on linux at least
[19:20] <Peaker_> I haven't told it about putty's existence, so I'm guessing paramiko uses its own/pycrypto implementation
[19:20] <Peaker_> I found how to create a key pair with paramiko, but not sure how to get bzr to use that key
[19:24] <AnMaster> Verterok, result?
[19:24] <Verterok> same error
[19:25] <Verterok> but I think I'm close to find the cause :)
[19:26] <mgedmin> ouch
[19:26] <mgedmin> 21578 mg        18   0 1162m 861m 3456 R   67 43.4  12:01.54 bzr
[19:27] <mgedmin> that's me attempting to bzr co svn+ssh from a repo with 5620 revisions
[19:27] <mgedmin> and it fails with bzr: ERROR: mismatched lock context and write group after 18 minutes
[19:28] <mgedmin> a gig of ram is a bit excessive for < 30 megs of source code
[19:28] <mgedmin> fwiw git-svn is also unable to cope with this repo, if that's any consolation
[19:30] <LarstiQ> mgedmin: http://subversion.tigris.org/issues/show_bug.cgi?id=3052
[19:33] <mgedmin> fixed 3 days ago, yay
[19:34] <LarstiQ> mgedmin: and possibly in 1.4.7
[19:34] <mgedmin> gutsy has 1.4.4dfsg1-1ubuntu3
[19:34] <LarstiQ> mgedmin: 1.4.7 is still in the release process
[19:36] <dato> 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] <mgedmin> which branch?
[19:37] <Verterok> AnMaster: I just find  workaround for the erro ;)
[19:37] <dato> mgedmin: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
[19:37] <AnMaster> Verterok, you found one?
[19:37] <dato> mgedmin: cd ~/.bazaar/plugins && bzr get http://people.samba.org/bzr/jelmer/bzr-svn/0.4 svn
[19:38] <jelmer> The workaround in bzr-svn itself only works around the main memory leak
[19:38] <dato> aha
[19:38] <jelmer> the fix in subversion upstream fixes all leaks
[19:38] <mgedmin> is there more than one?
[19:38] <mgedmin> sounds fun
[19:38] <Verterok> AnMaster: in backend.py add define a top level/global variable: version = '0.2'
[19:38] <Verterok> AnMaster: that should do the trick :)
[19:38]  * mgedmin upgraded ram to 2 gigs just last week
[19:38] <AnMaster> I will try it shortly, got some telephone calls to make and such
[19:38] <jelmer> however, you probably won't notice the others leaks because they're quite small
[19:39] <Verterok> ok
[20:05] <mgedmin> 16 minutes and BAM!
[20:05] <mgedmin> bzr: ERROR: exceptions.TypeError: int argument required
[20:08] <mgedmin> https://bugs.launchpad.net/bzr/+bug/178149
[20:08] <ubotu> Launchpad bug 178149 in bzr "bzr co svn+ssh:/// gets a TypeError" [Undecided,New]
[20:12] <luks> that looks like a bug in bzr-svn, not bzr
[20:12] <jelmer> mgedmin, yeah, I just reassigned
[20:13] <mgedmin> sorry, I just clicked on the "please report this bug here" link
[20:13] <mgedmin> without paying much attention
[20:13] <jelmer> no worries
[20:13] <jelmer> mgedmin, Any chance you can run it again with BZR_PDB=1 set?
[20:13] <mgedmin> sure
[20:14] <mgedmin> that was quick
[20:14] <mgedmin> bzr: ERROR: File exists: u'/home/mg/tmp/trunk/.bzr'
[20:14] <mgedmin> heh, I typed du when I meant rm -rf
[20:15] <mgedmin> (fwiw the old checkout left after the crash was 48 megs)
[20:15] <mgedmin> I probably shouldn't say checkout given that it's a full-fledged bzr branch, no?
[20:15] <mgedmin> wait, I did bzr co, not bzr get
[20:15] <jelmer> checkout is the appropriate term
[20:15] <jelmer> the other thing is "lightweight checkout" which is just a working tree
[20:16] <jelmer> without a full-fledged branch
[20:16] <jelmer> mgedmin: Are you using the 0.4 branch?
[20:16] <mgedmin> late saturday evening -> brain not at its best
[20:16] <mgedmin> yes, 0.4 branch
[20:16] <mgedmin> bzr revno says 822
[20:19] <jelmer> yep, that's the latest
[20:33] <mgedmin> (Pdb)
[20:33] <mgedmin> /usr/lib/python2.5/site-packages/bzrlib/xml5.py(216)write_inventory()
[20:33] <mgedmin> ie.text_size is None
[20:34] <mgedmin> which seems interesting to me
[20:34] <mgedmin> ie is an InventoryFile, and it seems to be a symlink in subversion
[20:35] <mgedmin> yep, that revision added a symlink to the svn repo
[20:35] <mgedmin> does bzr-svn support symlinks?
[20:35] <mgedmin> ie.kind == 'file'
[20:36] <jelmer> was this a revision pushed by bzr-svn ?
[20:37] <mgedmin> no
[20:37] <mgedmin> but I've had trouble with symlinks in that svn repo before
[20:37] <mgedmin> symlinks suddenly becoming plain files with 'link ../../lalala' inside
[20:37] <mgedmin> and svn st not noticing anything strange
[20:37] <mgedmin> svn revert failing to fix the problem
[20:38] <mgedmin> but rm'ing and svn up'ing would fix the problem
[20:38] <mgedmin> in the end I removed all symlinks and replaced them with copies
[20:39] <jelmer> Symlinks in Subversion are basically regular files with "link ../foo" inside
[20:39] <jelmer> and a special property "svn:special" set to "*"
[20:39] <mgedmin> and a special property
[20:39] <mgedmin> yes
[20:39] <mgedmin> svn proplist -r url-to-that-file gives me an empty list
[20:39] <mgedmin> weird
[20:40] <jelmer> are you still in the debugger?
[20:40] <jelmer> can you paste the contents of ie?
[20:40] <mgedmin> yes
[20:40] <mgedmin> 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] <jelmer> and ie.kind == 'file' ?
[20:41] <mgedmin> yes
[20:41] <mgedmin> aha
[20:41] <mgedmin> svn log on that file gives me two revisions:
[20:42] <mgedmin> 6777 where I added the symlink
[20:42] <mgedmin> and 6779 where I manually set svn:special to "*"
[20:42] <mgedmin> because svn proplist in my working directory showed it
[20:42] <mgedmin> but svn proplist in a fresh checkout didn't
[20:42] <jelmer> ah
[20:43] <mgedmin> I don't know how I managed to convince svn to commit it this way to the repo
[20:43] <mgedmin> 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] <jelmer> what does "svn cat -r6779 <that-file>" show?
[20:44] <mgedmin> but I failed at that
[20:44] <mgedmin> svn cat of both 6779 and 6777 show "link ../../../threesixty/browser/texts/spelling.tt" (no trailing newline)
[20:46] <jelmer> I think I know what the problem is
[20:46] <jelmer> bzr-svn supports changing the kind of a file
[20:46] <jelmer> but only if the contents of that file also change
[20:47] <mgedmin> heh
[20:47] <jelmer> that usually always happens,  because you don't tend to have files that contain "link .../..," that you then turn into a symlink
[20:47] <mgedmin> not by choice, no
[20:47]  * jelmer sees if he can reproduce in a bzr-svn testcase
[20:48] <abentley> Ah, heh.  Tricky.
[20:48] <abentley> I had to deal with that issue when writing _iter_changes, too.
[20:59] <jelmer> yeah, these are really funny corner cases
[20:59] <jelmer> it looks like subversion doesn't allow kind changes in general, it just requires you to delete and re-add
[20:59] <jelmer> however, Marius somehow seems to've worked around their usual checks :-)
[21:02] <jelmer> mgedmin, the patch at http://samba.org/~jelmer/bzr-svn-ensure-kind.diff may help
[21:02]  * mgedmin whistles nonchalantly
[21:02] <jelmer> it's untested as I haven't found a way to make svn stop complaining about changes to svn:special
[21:03] <jelmer> if you still remember how you managed that, I'm interested to hear about it :-)
[21:03] <mgedmin> I can't remember what I don't know :/
[21:07] <mgedmin> it's somewhat unfair how bugs in svn make bzr-svn look bad
[21:08] <jelmer> heh, yeah
[21:16] <mgedmin> 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] <mgedmin>     -- http://scottaaronson.com/blog/
[21:24] <mgedmin> jelmer: nope, that patch doesn't fix the problem
[21:25] <mgedmin> same error in same place
[21:26] <mgedmin> I'll try to create a small svn repo with the same sort of kind change
[21:26] <jelmer> are you sure? I just reproduced the problem here and the patch seems to fix the problem
[21:26] <mgedmin> 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] <jelmer> now also committed as 823
[21:30]  * mgedmin runs bzr pull
[21:30] <mgedmin> yep, I had that patch applied, and bzr pull merged it cleanly
[21:31] <mgedmin> yet ie.kind == 'file'
[21:31] <mgedmin> nm, it's not like it's an urgent problem for me
[21:31] <mgedmin> for a while yet I've been investigating bzr and bzr-svn, waiting until switching to it becomes pain-free
[21:32] <mgedmin> this was just another of those idle curiosity attempts
[21:34] <jelmer> mgedmin: well, it'd be nice to get a testcase done now
[21:39]  * mgedmin wrestles with svnadmin dump
[21:41] <mgedmin> I don't get it
[21:41] <mgedmin> rev 6777 was a tiny one that added 4 lines to one text file and added one symlink
[21:42] <mgedmin> yet svnadmin dump -r 6777 produces who-knows-what
[21:42] <mgedmin> oh, right
[21:42] <mgedmin> I forgot the --incremental
[21:43] <mgedmin> here's what svnadmin dump says: http://bzr.pastey.net/79411
[21:43] <mgedmin> Node-action: replace
[21:43] <mgedmin> no properties
[21:44] <mgedmin> haha
[21:45] <jelmer> re
[21:45] <mgedmin> I know how I replaced that file:
[21:45] <mgedmin> cd workingdir; svn rm regularfile; ln -s target regularfile; svn add regularfile; svn ci -m "replace file with symlink"
[21:46] <mgedmin> hm, but it works fine when I try it today
[21:47] <mgedmin> the original commit was on 2007-11-20, so I used the same version of svn then (the one in gutsy)
[21:48] <mgedmin> weird
[21:48] <jelmer> hmm, so the new file that replaced the original didn't actually have svn:special set?
[21:48] <mgedmin> in the real repo -- didn't
[21:48] <mgedmin> in my test repo -- did
[21:52] <jelmer> did r6778?
[21:53] <mgedmin> http://bzr.pastey.net/79412
[21:54] <mgedmin> 6778 changed two unrelated files
[21:54] <mgedmin> 6779 changed just the svn props
[21:54] <mgedmin> fwiw the repository is version '3'
[21:54] <mgedmin> while svn 1.4 introduced version '5'
[21:54] <mgedmin> I never did the dump/reload to convert it
[21:54] <jelmer> the <...> in the bit you just pasted were the contents of the file?
[21:55] <mgedmin> no, that was the commit message and unrelated metadata
[21:56] <mgedmin> it's possible that I did the svn propset svn:special '*' with a svn 1.3 client (on ubuntu dapper)
[21:56] <mgedmin> svn 1.4 from ubuntu gutsy refuses to commit that propset
[21:56] <mgedmin> sadly svn metadata doesn't record the client version or the hostname
[21:57] <jelmer> you may be able to make a change using a svndump
[21:58] <mgedmin> I suppose so
[21:59] <mgedmin> but "don't fix what ain't broke" applies here -- svn seems to work fine with it
[21:59] <mgedmin> it'll be something to keep in mind when we eventually decide to migrate to another tool
[22:04] <jelmer> mgedmin, any chance you can paste the relevant bit of the svndump from 6777?
[22:05] <mgedmin> what is the relevant bit?
[22:05] <mgedmin> I already pasted  http://bzr.pastey.net/79411
[22:05] <mgedmin> it's from 6777
[22:05] <jelmer> ah, thanks
[22:08] <jelmer> and 6778 didn't change this file?
[22:10] <mgedmin> no
[22:10] <mgedmin> but a later revision did
[22:11] <mgedmin> no, actually not
[22:11] <mgedmin> I thought I replaced that symlink with a regular file
[22:11] <mgedmin> I didn't
[22:11] <mgedmin> it's still a symlink
[22:11] <mgedmin> svn log on it shows only two revisions
[22:12] <mgedmin> forget whatever I said about svn rm regularfile; ln -s; svn add regularfile ---- that was a completely different one in another part of the source tree
[22:12] <mgedmin> it is possible though that I svn added a regular file, and then changed my mind and silently replaced it with a symlink before committing
[22:13] <jelmer> ah, ok
[22:14] <jelmer> mgedmin: Btw, when you retried with the patch, did you blow away the bzr repository you were fetching into?
[22:14] <mgedmin> yes
[22:14] <mgedmin> bzr aborts very early if I don't do that anyway
[22:15] <mgedmin> what, bzr-svn won't allow me to check out a subtree?
[22:15] <mgedmin> how un-svn-like
[22:15] <mgedmin> I wanted to try again without waiting for 15 minutes
[22:15] <jelmer> try removing ~/.bazaar/subversion.conf and trying again
[22:16] <jelmer> that's a bit of a hack, as bzr doesn't have much of a ui for checking out subtrees yet
[22:16] <mgedmin> 33 revisions, 9 seconds, no errors
[22:16] <jelmer> and that included the problematic file?
[22:16] <mgedmin> yes
[22:17] <mgedmin> it's a broken symlink
[22:17] <mgedmin> but if I try to do that with the parent directory, boom
[22:17] <mgedmin> same error after 16 seconds
[22:18] <mgedmin> interesting, isn't it?
[22:18] <mgedmin> bzr co svn+ssh://.../trunk/team/browser/texts succeeds
[22:18] <mgedmin> bzr co svn+ssh://.../trunk/team/browser fails
[22:18] <jelmer> yeah, that's really odd
[22:18] <mgedmin> the inventory file object on the failure refers to trunk/team/browser/texts/spelling.tt
[22:19] <mgedmin> wait, this is interesting
[22:19] <mgedmin> ah, no it isn't
[22:19] <mgedmin> I just saw a : instead of a %2F
[22:19] <mgedmin> and then realized it's how bzr replaces the branch name from the directory name
[22:19] <mgedmin> s/replaces/separates/
[22:19] <mgedmin> s/realized/guessed/
[22:21] <``Cube> hello
[22:21] <``Cube> im a tango artist
[22:21] <``Cube> a long time ago, someone from you asked me to create some icons
[22:21] <``Cube> I created some, but they, (sorry for that languaged) sucked
[22:21] <``Cube> now, I'd like to retry
[22:22] <jelmer> hi ``Cube
[22:22] <``Cube> hello jelmer
[22:22] <jelmer> ``Cube: do you remember who you had contact with earlier?
[22:22] <``Cube> well
[22:22]  * mgedmin sometimes dreams about asking a tango artist to create some icons for gtimelog
[22:22] <``Cube> ill look
[22:22] <``Cube> gtimelog?
[22:22] <``Cube> tell me what icons you need!
[22:22] <mgedmin> http://mg.pov.lt/gtimelog/
[22:23] <``Cube> yep
[22:23] <``Cube> got him
[22:23] <mgedmin> an application icon would be enough
[22:23] <``Cube> (mgedmin, later, ok?)
[22:23] <``Cube> oh, I love making app icons
[22:23] <mgedmin> sure
[22:23] <``Cube> ill do that
[22:23] <mgedmin> I wish I had talent for making icons...
[22:23] <``Cube> but for now, first id like to finish this ok?
[22:23] <``Cube> :P
[22:23] <mgedmin> sure
[22:23] <``Cube> I don't even know if I have, we will see :P
[22:23] <``Cube> ill add you...
[22:24] <``Cube> ok
[22:24] <``Cube> jelmer: Daniel Schierbek
[22:24] <``Cube> *Schierbeck
[22:24] <jelmer> ah, ok
[22:24] <``Cube> know him, right?
[22:24] <jelmer> yep
[22:24] <jelmer> He's asked about bzr-gtk I presume?
[22:24] <``Cube> I don't know
[22:24] <``Cube> its a long time ago now
[22:24] <``Cube> tell him these icons were really bad
[22:24] <``Cube> I had actually no tango skill yet
[22:25] <``Cube> I hope I have now :P
[22:25] <``Cube> we will see
[22:25] <``Cube> I need a list of icons and what sizes you need
[22:25] <jelmer> Having better icons would be very nice! :-)
[22:25]  * mgedmin checks whether his email is on that page... yep, it's there at the bottom
[22:25] <``Cube> and I'd love to be the author of 'em
[22:26] <jelmer> ``Cube: Do you need the list right now? It would be nice to bring up on the bzr-gtk mailing list
[22:26] <``Cube> sure
[22:26] <``Cube> well :D
[22:26] <``Cube> I reinstalled my os today
[22:26] <``Cube> have no mail app installed yet
[22:27] <``Cube> I don't need the list right now, but having it would be nice
[22:27] <``Cube> so, if I can't start with bazaar now
[22:28] <``Cube> mgedmin: it's time for you!
[22:28] <mgedmin> uh oh
[22:28] <``Cube> hehe ;)
[22:29] <``Cube> ah I see you're the author
[22:29] <``Cube> do you already have an idea for the icon?
[22:29] <``Cube> something with a clock?
[22:29] <``Cube> maybe a list with a clock?
[22:29] <mgedmin> yes, currently I stol^H^H^H *borrowed* one of the GNOME icons that had a clock in it
[22:29] <``Cube> I think this is the main idea of the program -> to track (~list) your time?
[22:29] <mgedmin> yes
[22:30] <``Cube> would that be a good idea?
[22:30] <mgedmin> yes
[22:30] <mgedmin> oh, my, it's past midnight
[22:30] <mgedmin> time to go home
[22:30]  * mgedmin at work, but not precisely working ;)
[22:30] <``Cube> ;)
[22:30]  * ``Cube asks where there will be a windows version of your program?
[22:30] <mgedmin> many thanks for your kind offer
[22:30] <``Cube> uh
[22:31] <mgedmin> it's written in python, and works on windows
[22:31] <``Cube> don't thank to early, maybe the icon will SUCK
[22:31] <``Cube> oh, cool
[22:31] <mgedmin> but there's no convenient installer right now
[22:31] <mgedmin> so you have to download python and pygtk manually
[22:31] <``Cube> hmm ok
[22:31] <mgedmin> maybe one day I'll figure out how to use py2exe
[22:31] <``Cube> is there any alternative to your program?
[22:31] <mgedmin> lots
[22:31] <``Cube> oh :D
[22:31] <mgedmin> :)
[22:32] <``Cube> any example?
[22:32] <mgedmin> but when I was looking for some, I was looking for linux ones
[22:32] <mgedmin> so if you want a windows one, I can't help you
[22:32] <``Cube> a nice, open source, well designed one
[22:32] <``Cube> oh yes, sure
[22:32] <``Cube> I mean, your if nice of course too
[22:32] <TFKyle> hmm, that reminds me, need to figure out how to extend py2exe so it gets the newest gtk runtime automatically
[22:32] <``Cube> just asking
[22:32] <``Cube> ok
[22:32] <``Cube> im gona start desning
[22:32] <``Cube> are you gonna stay long here, mgedmin?
[22:32] <mgedmin> hm does bzr-gtk have a convenient windows installer?
[22:33] <mgedmin> I might want to steal some ideas
[22:33] <mgedmin> ``Cube: not really
[22:33] <``Cube> hmm ok
[22:33]  * mgedmin a bit sleepy
[22:33] <jelmer> hmm
[22:33]  * ``Cube too
[22:33]  * jelmer gives gtimelog a try
[22:33] <jelmer> I've actually been looking for something like this
[22:34]  * ``Cube also thinks gtimelog ain't a bad idea
[22:34] <jelmer> strange way to come across it now :-)
[22:34]  * ``Cube is going to use it maybe...
[22:34] <``Cube> but first icon!
[22:34] <mgedmin> I've heard some people at canonical are using it
[22:34]  * fullermd will stick with vi and flat-files   :p
[22:34] <mgedmin> it's a bit ironic that I stopped using it myself
[22:34] <mgedmin> (low productivity -> sad-looking reports -> depression -> even lower productivity)
[22:34] <``Cube> juhu! 30 minutes and its my birthday!
[22:34] <mgedmin> (bad vicious cycle)
[22:35] <mgedmin> ``Cube: congratulations!
[22:35] <``Cube> :P thanks
[22:36] <jelmer> mgedmin: Thanks for the help tracking down at least one bug in bzr-svn
[22:36] <mgedmin> any time you want a broken svn repo, come to me
[22:36] <mgedmin> have I told about the one (a repo of my home directory) that made svn loop forever eating more and more memory?
[22:36] <mgedmin> ah, that was fun
[22:36] <jelmer> wow
[22:37] <jelmer> How did you manage to get it to do that?
[22:37] <mgedmin> somehow the revision graph became cyclic
[22:37]  * mgedmin just uses stuff, and stuff usually breaks on its own
[22:37] <jelmer> :-)
[22:38] <mgedmin> maybe not the revision graph, just the delta-based storage for the svn:ignore property on /
[22:38] <mgedmin> rev X is rev Y plus this change, while rev Y is rev X plus this other change
[22:38]  * mgedmin had to edit C code to unbreak the repo
[22:38]  * mgedmin converted all his repos from bdb to fsfs the next day
[22:40] <mgedmin> ``Cube: if you ever get bored, http://mg.pov.lt/pyspacewar/ also could use an icon -- and it runs on windows too, if you install pygame
[22:40] <mgedmin> bye, all!
[22:40] <``Cube> see you
[22:40] <jelmer> goodnight Marius
[23:29] <deepjoy> Hi is there anywhere I can see more detailed development targets and status than in launchpad Blueprints?
[23:32] <Verterok> deepjoy: the other place I look for info is http://bazaar-vcs.org/
[23:37] <jelmer> deepjoy: The mailing list should give you some indication of what people are working on
[23:38] <jelmer> deepjoy: Are you looking for development targets in general or rather what the plans are for particular targets?
[23:51] <Verterok> jelmer: do have a minute to chat about: Bug #161830 ?
[23:51] <ubotu> Launchpad bug 161830 in bzr-svn "log should show subversion revision numbers as well as branch/bzr revision info" [Wishlist,Triaged] https://launchpad.net/bugs/161830
[23:52] <jelmer> sure
[23:53] <Verterok> as I have been working a bit with log formatters for the xmloutput plugin
[23:54] <Verterok> a simple solution to that bug could be to add a show_properties function, just like the LogFormatter have a begin_log and end_log functions
[23:56] <Verterok> the only thing I didn't figured out yet is where the call to show_properties should go
[23:56] <jelmer> Verterok: and show_properties() would get a dictionary or something?
[23:57] <Verterok> actually it's a method of LogFormatter so it have access to the revision
[23:57] <Verterok> and to all the properties in it
[23:59] <Verterok> but it should be better that show_propeties get a dict with the right properties. i.e: without branch-nick because log show it later