[12:34] <emgent> heya
[13:09] <mathrick> hallo
[13:09] <mathrick> how easy is it to use bzr's testing infrastructure for code not strictly in bzr?
[13:09] <mathrick> ie. my repo sync script, which already imports parts of bzrlib
[15:01] <ubotu> New bug: #222540 in bzr-gtk "Add a tags page to the revision view" [Undecided,New] https://launchpad.net/bugs/222540
[15:36] <vaasu>  q: i dont want a binary file to be under a revison control,(maintain its history), so, i put it under .bzrignore, but, now problem is, once this happens, when i push to a remote repo or clone, it does not get copied. any workarounds?
[15:36] <vaasu> all i want is, not to maintain the history of the file, but copy the file on clone/push.
[15:39] <Odd_Bloke> vaasu: bzr will only deal with files that are version controlled, so you'd have to find an external way of doing that.
[15:42] <mathrick> vaasu: you can't have a file in repo and not have its history
[15:42] <mathrick> it's internally inconsistent
[15:42] <vaasu> but sometimes it is sensible isn't it? such as image files.. say maintaining a website
[15:42] <mathrick> a repo is not a set of files, it's a set of tree states
[15:42] <mathrick> vaasu: no, it's completely meaningless
[15:43] <mathrick> ie. there's no interpretation of what you want it to do that would be sensible
[15:43] <vaasu> how can i force a file not in revision control to propagate on push/branching?
[15:43] <mathrick> vaasu: what contents should it have on clone/push?
[15:43] <mathrick> vaasu: write a plugin that does what you want
[15:44] <mathrick> but be aware that the requirements you gave are NOT consistent without further clarification
[15:44] <mathrick> so you have to encode the precise meaning of what you want into the plugin
[15:44] <mathrick> btw, wasn't there a way to drop binary delta into bzr?
[15:45] <mathrick> so that it's efficient even for binary files?
[15:45] <vaasu> mathrick: binary deltas will increase the size of repo to a large extent isn't it?
[15:45] <mathrick> vaasu: no, why?
[15:45] <mathrick> deltas are deltas
[15:46] <mathrick> well, if the changes are huge, so will be the deltas
[15:46] <mathrick> but that holds for any kind of change
[15:46] <mathrick> a binary diff can deal with binary files however, in a way smarter than "uh-oh, this be binary sir"
[15:47] <vaasu> > well, if the changes are huge, so will be the deltas, yes exactly, thats why i dont want to keep history..
[15:47] <mathrick> vaasu: okay, so what you want is not to keep a file sans history in the repo, but to attach a file to the tree without putting it in the repo?
[15:48] <mathrick> I guess that makes sense when specified this way
[15:48] <vaasu> yes.
[15:48] <mathrick> vaasu: write a plugin then, it's not so hard
[15:48] <mathrick> docs are available from the site
[15:48] <mathrick> jelmer: btw, could I get some guidance with bzr-rebase please?
[15:49] <mathrick> specifically, I'd like to add patch reshaping (a'la git rebase's "merge" command)
[15:49] <vaasu> any otherway than writing a plugin... i mean.. plugin is the last resort if i would go..
[15:49] <mathrick> though maybe just merging would be enough for my purposes, can't decide
[15:49] <vaasu> ?
[15:50] <mathrick> vaasu: why is it the last resort?
[15:50] <mathrick> it's neither hard nor non-sensible
[15:50] <vaasu> i am afraid i may write something screwy....
[15:50] <mathrick> it's _the_ way of extending bzr
[15:50] <mathrick> vaasu: and without a plugin you wouldn't
[15:50] <mathrick> ?
[15:51] <vaasu> well i assume..
[15:51] <mathrick> then you're wrong
[15:51] <vaasu> hmm
[15:51] <mathrick> a plugin is just a way to hook a piece of code into bzr automagically
[15:51] <mathrick> it doesn't make the code any more or less correct than it'd be otherwise
[15:51] <mathrick> it just makes it easier to get it right
[15:55] <mathrick> vaasu: btw, you can prototype your code as a separate snippet
[15:55] <mathrick> and make it into a plugin once you're reasonably certain it works
[17:41] <jelmer> mathrick: pong
[17:42] <mathrick> jelmer: hi, read my request?
[17:42] <mathrick> how hard would it be to hack that in?
[17:43] <jelmer> mathrick: not sure I understand what you mean exactly
[17:43] <mathrick> jelmer: do you know how git rebase can reshape patches?
[17:44] <jelmer> mathrick: you mean the interactive stuff?
[17:45] <mathrick> jelmer: yeah
[17:45] <jelmer> mathrick: I guess it shouldn't be too hard to do something like that
[17:46] <jelmer> although it doesn't really require any code in the rebase plugin
[17:47] <jelmer> I think I'd rather see a different plugin for that
[17:47] <mathrick> mhm, it's just that's how git does that I guess
[17:47] <mathrick> though OTOH reshaping the tree and reshaping the patches kinda go togeter
[17:49] <jelmer> I wouldn't mind having an extra command in the rebase plugin for this
[17:51] <jelmer> patches welcome :-)
[18:28] <mathrick> jelmer: well, yes, but noticed the bit in which I ask for assistance? :)
[18:40] <cr3> I just ran the following command and I seem to be missing a bunch of files compared to a svn co: bzr branch svn://svn.zope.org/repos/main/Zope3/trunk
[18:48] <Odd_Bloke> cr3: What files are missing?
[18:50] <cr3> Odd_Bloke: lots of directories under src/zope
[18:51] <Odd_Bloke> cr3: I don't know how bzr-svn deals with externals...
[18:51] <Odd_Bloke> jelmer: ^ ?
[18:52] <cr3> Odd_Bloke: good point, src/zope/.svn/dir-prop-base lists a bunch of externals which don't happen to be downloaded
[18:55] <cr3> Odd_Bloke: README.gz says: 'svn:externals'. Externals should be mapped to Bazaar 'by-reference' nested branches and the other way around. This can't be implemented...
[19:01] <Odd_Bloke> cr3: Sounds like you're out of luck. jelmer would know more.
[19:01] <cr3> hm, so I'm really not sure how to deal with an upstream svn project :(
[19:02] <cr3> I'm thinking of doing some shell magic to grab all the dir-prop-base files and create new bzr branches for each external repo, then create symlinks to those each of those new projects
[19:04] <cr3> or, store the whole svn co (include .svn directories) into my bzr project :)
[19:10] <cr3> david allouche might have something for me, his svn2bzr seems to support svn repo to bzr conversion
[20:36] <cr3> is python-paramiko needed for bzr+ssh or only sftp?
[20:36] <LaserJock> is there anyway to conveniently merge subdirectories of two branches on a regular basis
[20:36] <LaserJock> ?
[20:37] <LaserJock> cr3: I thought bzr+ssh used sftp, but I could be wrong
[20:38] <cr3> LaserJock: that would be strange considering the significant performance difference between using sftp and bzr+ssh
[20:39] <LaserJock> I thought it was due to more efficient use, not particularly changing underlying protocols
[20:39] <LaserJock> but I'm so not a bzr expert
[21:37] <GuyFromHell> Is there a solution for bzr-svn not setting that $Id$ thing in files when checking out a repository with --lightweight?
[21:37] <awilkins> GuyFromHell: No, no keyword expansion in bzr yet
[21:37] <GuyFromHell> awilkins, k, i guess i'll just add it by hand then and trick it :P