[00:03] spiv: Sensible laptop! [00:04] RAOF__: :) === cody-somerville_ is now known as cody-somerville === RAOF__ is now known as RAOF [02:20] * spiv -> lunch [02:22] jelmer: ping [02:22] thumper, pong [02:23] jelmer: how goes the bzr-git import stuff? [02:23] I was just looking at your samba page for dulwich [02:23] thumper, so, dulwich (our underlying git library) has seen a release yesterday [02:23] I knew there would have been a reason for the name of the library [02:23] but I didn't know what it was [02:23] :) [02:24] thumper, :-) [02:24] thumper, I've also frozen the current mappings [02:24] jelmer: have you changed the generated rev ids to use v1 rather than experimental? [02:24] so if you use current bzr-git to do an import it won't break in the future (barring bugs, of course) [02:24] thumper, yep [02:25] cool [02:25] I'll move our plans along then [02:25] has there been a release of bzr-git officially? [02:25] not yet [02:25] planned one? [02:25] there's some regression that broke remote branching that I'm working at fixing at the moment [02:25] * thumper nods [02:26] jelmer: can I get you to email me when you have a release? [02:26] after that I hope to do a 0.1 release [02:26] we'll work on the git imports for LP on that [02:26] thumper, yeah, np - I'll cc you on the announcements [02:26] ta [02:26] fantastic [03:54] hey, I'm very new to versioning clients, I have bzr installled... i'm wondering what approach I should use for making a CMS for users to login and see the files and edit them... Like, do I make a php script/page that connects to the bzr server to modify/update the different files?? [03:55] Because I need some sort of interface for staff members to edit the site, and folks are saying to use subversion for that, but bzr looks less complex.... am I on the right path? [03:57] so you are writing a content management system? [03:57] yeah [03:58] I wrote on in PHP last summer but ran into a roadblock when I was trying to figure out how to let staff members edit differnt files/pages of the website, and now I hear that this is the best approach [03:59] well, bzr is written in python [03:59] so you could either call into python at the system command level... [03:59] or use the python bzrlib somehow [03:59] although from PHP, I don't know how [04:00] well I know some python, and I know how to pass variables between python and PHP [04:00] unless someone has embedded python into PHP recently [04:00] :) [04:00] I just make a simple python socket and have PHP connect to that , kinda like sql [04:00] python socket? [04:00] yeah, a python script that listens on a port and runs on the server [04:01] so the python script could communicate with bzr [04:01] ok, well, you could have your python script accept "commands" with text and have that script use bzrlib [04:02] bzrlib = bzr, right? [04:02] I'm still figuring out bzr :) [04:02] I just wanna make sure I'm approaching this correctly [04:03] bzr is the command line tool [04:03] bzrlib is the python library behind it [04:03] hmm [04:03] bzr comes with bzrlib [04:03] don't you just need the command line, to make any changes?? [04:03] you could do it that way [04:03] but you don't need to [04:04] i see [04:04] to be honest, it may be your quickest way of getting something working [04:04] just using hte command line? [04:04] or the bzrlib [04:04] yes, to start with [04:05] yes commandline [04:05] okay [04:05] What does bzrlib offer that command line doesnt? [04:05] complete program flexability :) [04:06] okay, I'll have to look into that once I get the basics of bzr down and the CMS [04:06] thank you thumper =) [04:06] np [05:02] does LarstiQ around? [05:03] hey guys, when typically LarstiQ hanging there? (timeframe) [05:08] * bialix will try later [06:18] how do I set the email address that shows up with my commits? [06:24] sadmac: "bzr whoami" [06:25] spiv: figured it out. thanks [07:29] hi all [07:33] bonjour [08:06] * thumper looks around for someone to upload bzrtools into the ~bzr PPA [08:36] hi folks! Is there any way to undo a pull, which has screwed up the log? [08:36] speakman: you can pull -r SOME_REV --overwrite [08:36] speakman: but what do you mean by "screwed up the log"? [08:38] it replaced the log mainline with the log of the log of the branch which has some strange merges and stuff [08:38] what I wanted to do was a merge. [08:39] Ok. So yes, bzr pull as I said above to bring the branch back to the point it was at before. [08:41] can I use -r -1 for it? [08:43] speakman: pull -r -1 would be a no-op [08:44] Oh, unless you mean to pull -r -1 of some other copy of the branch onto your copy. That would work. [08:45] But if you don't have another copy, then you'll need to look at the log and and find where the mainline stops being what you wanted (i.e. commits from someone else). That's the point at which the other branch diverged from yours, and so you want to go back to that revision. [08:45] * spiv -> dinner [08:53] It did work, thanks alot. [08:59] speakman: great. glad I could help. === asac_ is now known as asac [10:52] I'm still struggling to find a way to get git and bzr to cooperate... I may be missing something, but I can't seem to get it working. [10:55] Lo-lan-do: ? [10:55] are you playing with bzr-git or something else.. [10:57] I tried bzr-git and git-bzr. [10:58] bzr-git doesnt have push yet, but bzr branch should work against git:// [10:58] i think it can only get the master branch, tho [10:58] i think there is a git-import to get the full repository [10:59] push should come soon. i've been working on some parts of it in dulwich [10:59] I managed a branch, but when I added a commit into the git dir then I couldn't branch it again. [11:00] oh? [11:00] what error? [11:01] File "/home/roland/.bazaar/plugins/git/dulwich/dulwich/repo.py", line 223, in _get_object [11:01] assert len(sha) in (20, 40) [11:01] (AssertionError) [11:01] oh cripes. [11:02] dont suppose the git repo is online somewhere? [11:02] It's a clone of git://git.debian.org/apt-build/apt-build.git [11:02] (I took a random reasonably-sized one :-) [11:02] Then I added a simple commit inside. [11:03] Might be relevant: I upgraded to git 1.6 after the cloning. [11:03] hmm, i cant imagine they changed the object format in 1.6 [11:04] Dunno. When I tried to push (earlier), bzr complained about not finding a .git/inventory file or so. [11:05] yeha, push isn't implemented at all. most of the pieces are there for dpush i think, just need to tie it all together. [11:05] Lo-lan-do: did you do the simple commit with git or bzr? [11:05] git [11:07] hmm [11:07] i can reproduce, at least :] [11:08] Sheesh, get a room. [11:12] I'm off to lunch, but I'll be back soon :-) [11:53] hi guys. I've got an SVN repo with some projects in, and I'd like to create a bzr branch from one of the specific folders in that SVN repo [11:54] any hints on how to do that? I tried bzr branch /srv/svn/myrepo/myclient/project/ but got an error about different rich-root support [11:55] You're trying to branch it into an existing repository, which isn't rich-root capable. [11:56] You need to do it into a new repository (standalone would quality), or change your existing repository to rich-root, which you probably don't want to do since it will shove all the branches in it through the trapdoor. [11:58] what does the rich-root do? [12:09] CaMason: I think it allows bzr to track information on the root directory, whereas non-rich-root formats only track it for the files inside. [12:10] But I'm far from being an expert in these matters. [12:10] Jc2k: Any timeframe for a working push? Weeks? Months? [12:11] Roughly that, yah. [12:12] ok. well, they way I have my folders set up is, I have a shared-repo (no trees) per client [12:12] then there are project folders, then the branches inside of that [12:13] either way, do I need to make a shared repo with rich root support [12:13] Well, you could make a separate shared repo for it, sure. Or you could just make it standalone. [12:14] there's no branches in that particular repo atm [12:14] (probably have to make it elsewhere then move it in place for that; there's no easy way offhand I know of to make it standalone from the start without doing a lot more rather annoying steps along the way) [12:15] Jc2k: By the way, I upgraded the git plugin (and installed dulwich) and the bug seems to have gone away. [12:15] will rich-root cause me any problems with normal bazaar projects? (or other cons?) [12:16] Lo-lan-do: interesting.. [12:16] Lo-lan-do: im just merging head into my branch so i guess it will go away for me in a sec to [12:16] too [12:18] Well, since I'm tracking your branch.... [12:18] I was hopeful when I saw a log message by jelmer stating "Let's implement push", but no such luck. [12:19] that was me in dulwich [12:19] Oh, right, sorry. [12:19] in theory dulwich would support push right now, but the stuff to assemble a push is missing for a git repo and for a bzr repo [12:20] i was working a git implementation in dulwich to make sure the API is up to scratch, then i was going to start on the bzr one. assuming jelmer doesnt beat me to that :) [12:25] hi. is there an easy way to replace the parent location for a number of branches? like, some way to clear it off a branch and specify it in locations.conf [12:26] hey oleavr :) [12:27] morn Jc2k :) how's it going? [12:28] goood thx :) yourself? [12:28] oleavr: http://theironlion.net/blog/2009/01/13/using-bazaar-launchpad-making-pushing-easy/ [12:28] check the bit there about configuring locations [12:29] CaMason: Rich root support is a trapdoor. Revisions made with rich root support can't be used in non-rich-root repositories. So you don't want to move any branch of a project into rich-root unless you're prepared to move EVERY branch of that project (anywhere) into rich root. [12:31] Jc2k: nice :) pretty good. what are you hacking on these days? [12:32] james_w: thanks, but I've tried that already.. 'bzr pull' still pulls from the parent location ('Using saved parent location') [12:32] james_w: so I need some way to clear that remembered value so the one in locations.conf gets used [12:33] oleavr: i've been toying with bzr-git lately (wrote a git server than stores its stuff in bzr) [12:34] oleavr: reading branch.py, looks like there should be a parent file in the .bzr dir for your branch [12:34] Jc2k: awesome! asabil told me about that project. sounds really neat! [12:35] Only if you have a very old branch. [12:35] Jc2k: aha, thanks! *looks* [12:35] otherwise it goes through the normal config stuff [12:35] and i guess there would be a branch.conf too [12:35] /instead/ [12:35] hmm, branch.conf seems to be the culprit [12:37] it looks like you can branch.set_parent_location(None) to unset it [12:37] Jc2k: Could the git server be installed as /usr/bin/git, for remote usage through ssh? [12:37] yay, simply just setting parent_location in locations.conf did the trick (thought I tried that already) [12:37] ah, good. [12:38] Lo-lan-do: bzr-git ships with bzr-receive-pack and bzr-upload-pack scripts to symlink in place of git-receive-pack and git-upload-pack [12:39] Lovely. Do they already work? That would really make my day :-) [12:40] theoretically :) [12:40] * Lo-lan-do gives it a try [12:40] but the mappings need more love before it can handle bzr revisions [12:41] atm it can only handle git revisions [12:41] (its easy to get a sha1 off a git revision, but to get it off the bzr revision i'd have to scan the entire history of that revision) [12:42] Oh, so git→bzr one-way again :-/ [12:42] yeah. [12:44] I'm almost to the point where I'd like to say "We're using bzr. Deal with it." [12:45] Problem is that there are three of us, one a bzr user, one a git user, and one who doesn't care. And I don't have any particular moral authority to impose bzr. [12:45] both should work real soon. [12:46] Nice to know, because we're on a wobbly standing currently, without any public SCM so far. [13:10] is there any way I can make an SVN repo into a bzr branch without rich-root support? [13:12] I don't think so. [13:14] Not with bzr-svn anyway; it uses rich roots. [13:15] not that.. I want to migrate this svn repo branch to a bzr branch [13:15] so I can leave SVN behind [13:15] try bzr-fastimport [13:16] just reading up about that now [13:17] is it a plugin? The docs just say "grab the latest source" [13:19] seems so [13:22] yeah, you can "bzr branch lp:bzr-fastimport ~/.bazaar/plugins/fastimport" [13:23] I can't see any docs on how to use it properly. I'd need to filter the repo as I only want one of the folders inside of it [13:25] well, it has two parts [13:25] svn-fast-export that exports the SVN repo to a text stream [13:25] and then bzr fast-import that imports that stream in to a bzr branch [13:25] you can edit that stream in the middle if you like [13:26] ah right [13:26] bzr help fastimport [13:26] may give some documentation [13:26] yes it does, but it says to check on the web for further docs, which don't exist [13:27] I assume fast-import-filter would be helpful though [13:30] would be good to try exporting to a file first then. I'll see if I can figure how to use fast-export-filter.py [13:30] yup [13:30] fast-export.py sorry [13:42] ok I'm getting there. Getting an error that I'm looking up [13:44] "Can't open file '/srv/svn/clients/db/revs/154': too many open files" [13:48] CaMason, what is the problem with rich roots? [13:49] I don't know, I was told it was a 'trap door'. All I would like to do is create a sole-branch out of a folder in an SVN repo, and keep it as an SVN branch [13:51] CaMason, that's correct - you can't downgrade from rich root to the current default format, but rich root will be the default format at some point in the future [13:51] oh right [13:52] well this bzr repo is empty at the moment, so could I just re-create it as rich-root, then do a bzr-svn branch into there? [13:53] yep [13:55] * CaMason tries that [13:59] * Lo-lan-do cries [14:00] You can track a git branch in bzr with bzr-git, and a bzr branch in git with git-bzr, but when you do a round-trip the revision-ids are different so the branches have no common history :-( [14:01] yes, the two are incompatible [14:03] jelmer: thanks for that, I seem to have imported my svn branch successfully :) [14:03] and it's now a bona-fide bzr project [14:06] no more .svn pollution :) [14:07] And your working copy is smaller while containing your whole history. [14:08] the main thing is I can now work on this project whilst on the train :) [14:08] and I love that about bzr [14:09] svn died on me twice this-morning when I deleted a file manually. It hates that [14:14] jelmer: Is that something that can be fixed with the push support in bzr-git, or will stuff be forever split? [14:16] i'm having trouble with a lock [14:16] when i try to push my branch to launchpad, i get the error "Unable to obtain lock lp-46722000:///~ralf-kistner/pidgin-mxit/main/.bzr/branch/lock" [14:16] locked 67 hours, 23 minutes ago [14:17] Lo-lan-do: bzr-git will eventually have full two-way support, introducing git-bzr is always going to introduce pain tho.. unless we have some kind of 'bzr upgrade' to fix a git-bzr branch.. [14:17] but when i try to break the lock with "bzr break-lock lp-46722000:///~ralf-kistner/pidgin-mxit/main/.bzr/branch/lock" [14:17] Lo-lan-do: i dont know enough about git-bzr, though [14:17] i get the error Could not acquire lock "(remote lock)" [14:17] rkistner: thats a known bug with the error message (fixed recently i think) [14:18] ok [14:18] rkistner: i think you want bzr break-lock lp:~ralk-kistner/pidgin-mxit/main [14:19] thanks, that worked [14:19] what would cause the lock in the first place? [14:19] a write operation that was interrupted [14:20] (i think, not my area of expertise tbh) [14:20] Jc2k: Great, thanks :-) [14:22] svn-upgrade has some code that could be factored out to supported rebasing a git-bzr-based branch on a bzr-git based branch [14:24] Next question... can one (or will one be able to) access other branches than "master" with bzr-git? [14:24] Lo-lan-do, not yet, for this colocated branches in bzr would have to be supported first [14:25] I sent a spec for this to the mailing list a while ago [14:25] Lo-lan-do: the server part can expose multiple branches, tho [14:34] jelmer: Interesting [15:18] Hello, I am helping to solve [Bug 320968] and was asked to do "bzr init -Dtransport" to write a ".bzr.log". I did this but I do not see the log file. Am I doing anything wrong? [15:18] Launchpad bug 320968 in bzr-svn "bzr init in the base of a subversion checkout crashes" [Undecided,New] https://launchpad.net/bugs/320968 [15:19] Goosey, bzr will always be writing this file (every time it runs) but I'm not sure where it's located on Windows [15:19] on Linux it's in your homedir [15:19] Ah ok, i will look where it may be.. [15:19] "bzr version" tells you I thin [15:20] yes it does [15:20] i have it, thanks :) [15:46] My bzr is saying "No handlers could be found for logger "bzr"" all the time. Any changes lately? [15:46] speakman: Do you get it with '--no-plugins'? [15:47] yep [15:47] how do I change the push branch in bzr info? [15:48] speakman: I have no further thoughts on the matter. :p Someone else'll know what's up. [15:48] rbriggsatuiowa: bzr push --remember sftp://new.place.com/somewhere ? [15:48] Odd_Bloke: ok, thanks for trying. This is really annoying though :) [15:48] This = It's [15:51] it's also very verbose, showing every output twice and one of them with both pid, timestamp and debug level: [15:51] [12133] 2009-01-26 16:49:42.154 INFO: added src/pkt.c [15:51] added src/pkt.c [15:53] speakman: thanks [15:53] Odd_Bloke: rm -f ~/.bzr.log* did it [15:54] speakman: Weird. Possibly worth filing a bug. [16:00] there already are a few regarding the same issue, that's where I found the solution. :) [16:03] speakman: Fair enough. :) === dereine[OFF] is now known as dereine [16:35] in the output of bzr info, what's a submit branch? [16:40] Ng, where "bzr send" will compare against [16:40] beuno: has it appeared because I merged at some point? I've never seen it before and never used send [16:40] Ng, yeah, it's usually where you branch from IIRC [16:41] yeah, that one confuses me too. [16:42] fair enough. I tend to merge from branches that only exist for short periods, which is what I found a little confusing [16:42] * Lo-lan-do loves the new branch aliases [16:42] ... branch aliases? [16:42] :bound, :parent and :push [16:42] oh, handy. can we make custom ones? :) [16:42] beuno: thanks :) [16:43] No idea, and they're not even particularly documented anyway. [16:43] But I like to be able to "bzr missing :bound". [16:54] NfNitLoop: no, but there is https://launchpad.net/bzr-bookmarks === _thumper_ is now known as thumper [17:57] Wuff. Unshelve sure doesn't like the new progress bar stuff... [18:06] hello everybody, sorry if now follows a boring question. I got a branch of a projekt from launchpad by using bzr lp:/ and I did some changes in there. What is the right way to commit my changes for my personaly and not to copy them back to LP? [18:07] bzr commit [18:08] so simple? ok and when i want to put my changes up to LP bzr push will be the right? [18:08] right [18:08] thanks [18:09] one thing about bzr that is really buggy me. I want a config file to exist in my repository but I need it to be ignored when i do a checkout as the settings are local [18:09] does *any* VCS have a solution to that? [18:10] so when a new developer does a checkout they need to get the config file but then when they edit the config file it needs to be ignored [18:10] what I normally do is version the default version of a config file [18:10] and the developer has to copy/modify it [18:15] yeah [18:15] but i can't ignore a versioned file [18:15] and then when a do bzr up i get conflicts [18:16] ollie: no, I meant that you version foo.conf.default and ignore foo.conf [18:17] oh i see right that makes sense [18:17] thanks :) === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [19:21] hmm, no bialix === jfroy|work_ is now known as ghost === ghost is now known as Guest14946 === Guest14946 is now known as jfroy|work [20:03] jelmer, ping! [20:03] Goosey, pong [20:04] jelmer, I figured IRC may be more rapid than the buglog whenever you are interested (ref to #320968) [20:05] Goosey, yeah [20:10] * Lo-lan-do discovers bzr-email [20:11] * Lo-lan-do discovers bzr-cia too [20:11] :-) [20:11] Goosey, Did you see my last reply? [20:11] jelmer: You should make a bzr-allplugins package, it'll make life simpler for everyone :-) [20:11] Lo-lan-do, bzr-cia is already packaged [20:12] jelmer, last reply from you I have is your request for the -xml logs on the smaller revision set [20:12] I think you mean bzr-email... I just aptitude-installed -email, but rmadison doesn't mention -cia. [20:12] jelmer, I made a reply to that, but as I said in my reply I don't think I can share those log files directly due to NDA [20:13] Lo-lan-do, it's in cia-clients [20:13] Lo-lan-do, along with the git/svn/etc CIA plugins [20:14] Oh, sorry. [20:21] Goosey, I'm not sure what's going wrong exactly [20:22] Goosey, it looks like a bug in subversion, but I can't really tell [20:22] Goosey, are the subversion you're using directly and the one bzr-svn uses the same? === kiko is now known as kiko-afk [20:22] jelmer, the same repository, you mean? [20:23] Goosey, no, the instance of the subversion libraries that's being used [20:24] jelmer, I am not sure about that. I am using the precompiled 1.11 windows binaries for the bzr-svn side, do you know I command I can use to query the svn version? [20:24] Goosey, bzr-svn will report it in the .bzr.log file [20:28] jelmer, bzr-svn: using Subversion 1.5. and.. 1.5.5 for my direct SVN client [20:32] Goosey, what's the minor version of the svn used by bzr-svn ? [20:33] it should print 3 digits [20:33] jelmer, ah sorry, 1.5.4 [21:13] moin [21:16] moin lifeless === fta_ is now known as fta [21:26] jelmer: ping [21:27] lifeless, pong [21:27] jelmer: dulwich isn't reconstructing texts quite right for me [21:27] oh? [21:27] jelmer: in bzr-compressbench [21:27] jelmer: http://bazaar.launchpad.net/~lifeless/+junk/bzr-compressbench [21:27] grab that [21:28] its got a _very_ minimal versionedfiles implementation for dulwich [21:28] I take a pack repo, fully pack it [21:28] then construct a dulwich.pack.Pack on that pack [21:28] I can get out a plain text [21:29] and maybe a two-or-three delta (not sure where it breaks), but doing a full benchmark run EFAIL [21:29] and this works ok using e.g. git itself? [21:29] yes [21:30] the dulwich VF is subclasses from a 'invoke git as a subprocess' VF [21:30] have a look at the code, its pretty straight forward, and in true benchmark style no tests :P [21:30] What sort of failure do you get? [21:30] keyerror I think [21:31] grab the code, edit the repo reference, run --delta git --delta dulwich --limit 100000000 [21:31] and you'll see [21:31] back shortly, eating [21:50] lifeless, runs fine so far [21:52] jelmer: garh [21:52] jelmer: in which case, you can see how you stack up speed wise :) [21:52] lifeless, yeah, that bit is useful - thanks :-) [21:53] I use git for the compression because I want to see how big it is [21:53] but the git decompression has fork and datastructure warmup overheads, so I wanted to see 'native' decompression and see if it was faster [21:57] morning === igc1 is now known as igc [22:03] i am geting error: Unable to load bzr-svn extensions - did you build it? - bzr1.11 on windows using python installer [22:04] hsn_, did you install bzr-svn manually ? [22:04] jelmer: no. i deleted python and reinstalled python and bazaar again, its fresh install [22:07] there is directory sitepackages\bzrlib\plugins\svn - should i delete it? [22:09] deleting svn directory fixed problem [22:39] jelmer, my repo seems to be cursed. I was messing with Mercurial and after 'hg init' 'hg add' 'hg status' on the root my checkout my montitor started flashing to black [22:39] it is as if a demon was angered. A digital demon. [22:41] Goosey, the only thing I can think of that would explain this is if the svn folks fixed a bug in svn 1.5.5 [22:45] can anyone read http://www.ukr.net/mta/err.html#enduser?62.216.7.157 ? [22:45] * LarstiQ has trouble mailing bialix :( [22:45] LarstiQ, Yes [22:46] LarstiQ, it's Ukranian :-P [22:46] jelmer: :P [22:46] jelmer: so what does it tell me to do mail bialix? hmm? [22:46] LarstiQ, he was asking around for you here this morning I think [22:46] yeah, I noticed, but he wasn't here when I got back [22:46] LarstiQ, have you tried google translate? [22:46] jelmer: he emailed me too [22:46] <_mathrick> hiya [22:47] hi _mathrick [22:47] jelmer: oooh, it does Ukrainian [22:47] <_mathrick> a buglet I just noticed: bzr get bzr+ssh://path/to/a/lightweight-checkout fails because it refers to the parent branch as a plain pathname, which is then interpreted locally [22:48] <_mathrick> known? [22:48] jelmer: aha, it doesn't like my reverse dns [22:53] * LarstiQ sent a message via launchpad and hopes that gets delivered [22:53] and now, to bed [22:53] jelmer: quick update on 0.5, no explosions so far. still watching my steps, but it is promising [22:55] jelmer: can I provide more info on bug 320113? [22:55] Launchpad bug 320113 in bzr-svn "svn-upgrade fails with a KeyError (in rebase generate_transpose_plan)" [Undecided,New] https://launchpad.net/bugs/320113 [22:55] of course :-) [22:55] * LarstiQ rephrases [22:55] jelmer: what needs to happen to move it forward? :) [22:59] LarstiQ: hum, does one need to run that command when moving to 0.5? [23:00] LarstiQ, is there any reason you're using svn-upgrade at all rather than just doing a clean branch ? [23:00] svn-upgrade should only be necessary for branches that are not yet in svn [23:02] jfroy|work: not per se [23:03] jfroy|work: but I want to use the new mappings, and branches based on the old ones don't interact with new ones. Which is very nice in that I can (and already do) have some branches be 0.5 based without biting other 0.4 based ones. [23:04] jfroy|work: however, I'd like to switch some current 0.4 ones if possible, other options would be removing them all, and just branching again [23:04] LarstiQ, ah, that makes sense [23:04] I hadn't considered that use case [23:05] jelmer: which use case? [23:05] jelmer: so it works without crashing for ou [23:06] you? [23:06] * _mathrick regrets there's no way to branch only the history concerning specific files [23:06] So it is actually possible to concurrently use 0.4 and 0.5 on the same svn repository? I assume as long as the same "branch" is not accessed with both. [23:06] jfroy|work: yes, no [23:06] hi all [23:06] jfroy|work: I use 0.5 and 0.4 for different 'branches' in svn, that works fine. [23:06] jfroy|work: I've also used 0.4 and 0.5 on the same branch, that also works. [23:06] LarstiQ: :o [23:06] I am writing a plugin that involves iterating over all the "commits" from an input branch, and reapplying them on another output branch [23:06] jelmer: tip of the hat [23:07] I was worried about that. [23:07] jfroy|work: but then gets me into 320113 if I try to svn-upgrade a 0.4 one [23:07] asabil: isn't that rebase? [23:07] I amnot very familiar with the bzr internals, can someone point me to a starting point please ? [23:07] lifeless: not really, I want to rewrite the whole branch [23:07] jfroy|work: what you can not do, is communicate between the 0.5 and 0.4 branches directly with bzr. The communication has to go through svn. [23:07] asabil: yes, replay (in the rebase plugin) can do that [23:08]