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