| === mw is now known as mw|out | ||
| === spiv_ is now known as spiv | ||
| === cprov is now known as cprov-out | ||
| emgent | heya | 12:34 |
|---|---|---|
| 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 | 13:09 |
| ubotu | New bug: #222540 in bzr-gtk "Add a tags page to the revision view" [Undecided,New] https://launchpad.net/bugs/222540 | 15:01 |
| === rockstar` is now known as rockstar_ | ||
| 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:36 |
| 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:39 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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 | 15:55 |
| jelmer | mathrick: pong | 17:41 |
| mathrick | jelmer: hi, read my request? | 17:42 |
| mathrick | how hard would it be to hack that in? | 17:42 |
| jelmer | mathrick: not sure I understand what you mean exactly | 17:43 |
| mathrick | jelmer: do you know how git rebase can reshape patches? | 17:43 |
| jelmer | mathrick: you mean the interactive stuff? | 17:44 |
| mathrick | jelmer: yeah | 17:45 |
| jelmer | mathrick: I guess it shouldn't be too hard to do something like that | 17:45 |
| jelmer | although it doesn't really require any code in the rebase plugin | 17:46 |
| 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:47 |
| jelmer | I wouldn't mind having an extra command in the rebase plugin for this | 17:49 |
| jelmer | patches welcome :-) | 17:51 |
| mathrick | jelmer: well, yes, but noticed the bit in which I ask for assistance? :) | 18:28 |
| 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:40 |
| Odd_Bloke | cr3: What files are missing? | 18:48 |
| cr3 | Odd_Bloke: lots of directories under src/zope | 18:50 |
| Odd_Bloke | cr3: I don't know how bzr-svn deals with externals... | 18:51 |
| Odd_Bloke | jelmer: ^ ? | 18:51 |
| cr3 | Odd_Bloke: good point, src/zope/.svn/dir-prop-base lists a bunch of externals which don't happen to be downloaded | 18:52 |
| 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... | 18:55 |
| 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:01 |
| 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:02 |
| cr3 | or, store the whole svn co (include .svn directories) into my bzr project :) | 19:04 |
| cr3 | david allouche might have something for me, his svn2bzr seems to support svn repo to bzr conversion | 19:10 |
| === wildfire` is now known as wildfire | ||
| 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:36 |
| LaserJock | cr3: I thought bzr+ssh used sftp, but I could be wrong | 20:37 |
| cr3 | LaserJock: that would be strange considering the significant performance difference between using sftp and bzr+ssh | 20:38 |
| 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 | 20:39 |
| 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 | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!